Como limitar o efeito das modificações do cliente nos sistemas de produção

Question

Nossa loja desenvolveu algumas soluções WEB/SMS/DB para uma dúzia de instalações de clientes.Os aplicativos têm alguns requisitos de desempenho em tempo real e são bons o suficiente para funcionar corretamente.O problema é que os clientes (donos dos servidores de produção) estão utilizando o mesmo servidor/banco de dados para customizações que estão causando problemas de desempenho das aplicações que criamos e implantamos.

Alguns exemplos de customizações de clientes:

• Adicionando tabelas grandes com muitos tipos de dados de texto para as colunas que são convertidas em outros tipos de dados nas consultas
• Sem chaves primárias, índices ou restrições FK
• Uso de scripts externos que usam count(*) from table where id = x, em um loop do script, para determinar como construir mais consultas posteriormente no mesmo script.(sem ações em massa que o planejador possa otimizar ou apenas fazer tudo de uma só vez)
• Todos os novos arquivos de código no servidor são criados/de propriedade do root, com permissões 0777

Os clientes não aceitam bem sugestões/críticas.Se seguirmos em frente e tentarmos portar/alterar os scripts nós mesmos, o código antigo poderá voltar, prejudicando quaisquer alterações que fizermos!Ou, sem conhecimento limitado de seus casos de uso, quebramos a funcionalidade enquanto tentamos otimizar suas alterações.

Minha pergunta é esta:como podemos limitar os recursos a consultas/aplicativos diferentes daqueles que criamos e implantamos?Existem opções pragmáticas em cenários como este?Orgulhamo-nos de ter uma solução OSS, mas parece que isso se tornou um problema.

Usamos o PG 8.3 rodando em uma variedade de Linux Distos.Os clientes preferem php, mas shell scripts, perl, python e plpgsql são todos usados ​​no sistema de uma forma ou de outra.

Answer 1

Esse problema começou cerca de dois minutos depois que o primeiro cliente recebeu acesso total ao primeiro computador e não desapareceu desde então.Sempre que alguém cujas prioridades são realizar rapidamente um trabalho voltado para os negócios, ele será desleixado e estragará tudo para todos.É assim que as coisas funcionam, porque o design e a implementação adequados são mais difíceis do que hacks baratos.Você não vai resolver esse problema, tudo o que você pode fazer é descobrir como tornar mais fácil para o cliente trabalhar com você do que contra você.Se você fizer isso direito, parecerá um serviço excelente, em vez de irritante.

Primeiro, o lado do banco de dados.Agora existe uma maneira de controlar os recursos de consulta no PostgreSQL.A principal dificuldade é que ferramentas como "nice" controlam o uso da CPU, mas se o banco de dados não couber na RAM, pode muito bem ser o uso de E/S que está matando você.Veja isso mensagem do desenvolvedor resumindo os problemas aqui.

Agora, se de fato é a CPU que os clientes estão queimando, você pode usar duas técnicas para melhorar essa situação:

• Instale uma função C que altera a prioridade do processo (Exemplo 1, exemplo 2) e certifique-se de que sempre que executarem algo, ele será chamado primeiro (talvez coloque-o no arquivo de configuração psql, existem outras maneiras).
• Escreva um script que procure processos postmaster gerados por seu ID de usuário e os renove, faça-o rodar frequentemente no cron ou como um daemon.

Parece que o seu problema não são os processos de consulta específicos que eles estão executando, mas sim outras modificações que estão fazendo na estrutura maior.Só há uma maneira de lidar com isso:você tem que tratar o cliente como se ele fosse um intruso e usar as abordagens dessa parte do campo de segurança do computador para detectar quando ele estraga tudo.Seriamente!Instale um sistema de detecção de intrusão como o Tripwire no servidor (existem ferramentas melhores, esse é apenas o exemplo clássico) e faça com que ele alerte você quando tocarem em alguma coisa.Novo arquivo que é 0777?Deveria saltar direto de um relatório de IDS adequado.

No lado do banco de dados, você não pode detectar diretamente o banco de dados que está sendo modificado de forma útil.Você deve fazer um pg_dump do esquema todos os dias em um arquivo (pg_dumpall -g e pg_dump -s, compare-o com o último que você entregou e alerte-o novamente quando ele for alterado.Se você gerencia isso bem, o contato com o cliente se transforma em "notamos que você mudou no servidor... o que você está tentando realizar com isso?", o que faz você parecer que está realmente prestando atenção neles.Isso pode se transformar em uma oportunidade de vendas, e eles podem parar de mexer nas coisas só de saber que você vai aproveitá-la imediatamente.

A outra coisa que você deve começar a fazer imediatamente é instalar o máximo de software de controle de versão possível em cada caixa do cliente.Você deve ser capaz de fazer login em cada sistema, executar a ferramenta de status/diff apropriada para a instalação e ver o que mudou.Receba isso por correio regularmente também.Novamente, isso funciona melhor se combinado com algo que despeja o esquema como um componente do que ele gerencia.Poucas pessoas usam abordagens sérias de controle de versão no código que reside no banco de dados.

Esse é o principal conjunto de abordagens técnicas úteis aqui.O resto do que você tem é um problema clássico de gerenciamento de clientes de consultoria que é muito mais um problema de pessoas do que de computador.Anime-se, poderia ser pior - o FSM ajuda você se você der a eles acesso ODBC e eles descobrirem que podem escrever suas próprias consultas no Access ou algo simples assim.