Como testar e otimizar quando você não pode reproduzir o ambiente?

No passado, eu trabalhei em uma variedade de ambientes. Aplicativos de desktop, jogos, itens incorporados, serviços da Web, trabalhos de linha de comando, sites, relatórios de banco de dados e assim por diante. Todos esses ambientes compartilhavam a mesma característica: independentemente de sua complexidade, tamanho e tamanho, eu sempre poderia ter um subconjunto ou fatia do aplicativo na minha máquina ou em um ambiente de desenvolvimento para testar.

Hoje eu não. Hoje me encontro em um ambiente cujo foco principal é a escalabilidade. A reprodução do meio ambiente é proibitivamente cara. Tomando uma fatia do ambiente, embora plausível (algumas peças precisariam ser simuladas ou usadas em um modo de instância única para as quais não foram feitas), meio que derrota o objetivo, pois obscurece a simultaneidade e o carregamento que o sistema real encontra. Até um pequeno sistema de "teste" tem suas falhas. As coisas se comportarão de maneira diferente quando você tiver 2 nós e quando você tiver 64 nós.

Minha abordagem usual à otimização (medir, tentar algo, verificar a correção, medir diferenças, repetir) não funciona realmente aqui, pois não consigo executar as etapas 2 e 3 com eficiência nas partes do problema que são importantes (robustez de concorrência e desempenho em carga). Este cenário não parece único. Qual é a abordagem comum para realizar esse tipo de tarefa nesse tipo de ambiente?

Existem algumas perguntas relacionadas:

• esta pergunta tem a ver com hardware (como analisadores de espectro) indisponível, o que pode ser (relativamente) facilmente emulado.
• essa pergunta é sobre rastrear bugs que existem apenas em ambientes de produção, o que é útil - mas com um tipo diferente de atividade.

Na verdade, é difícil, mas tenho certeza de que, em muitas situações comparáveis, é principalmente um problema organizacional. A única abordagem viável é provavelmente uma mistura de medidas combinadas, não apenas "uma bala de prata". Algumas coisas que você pode tentar:

• registro: como já escrevi em um comentário, o registro excessivo de tempo e recursos (que é um tipo de criação de perfil) pode ajudá-lo a identificar os gargalos reais na produção. Isso pode não lhe dizer se uma implementação alternativa funcionará melhor, mas certamente ajudará a evitar a otimização da parte completamente errada do seu aplicativo.

• teste o que você pode testar de antemão - completamente, com muito planejamento inicial. Claro, as coisas terão um comportamento diferente na produção, mas nem todas . A correção de uma implementação diferente geralmente pode ser verificada com antecedência - se uma implementação for bem dimensionada, é uma pergunta diferente. Mas o planejamento pode ajudar muito. Pense bem nos problemas que seu ambiente de teste pode resolver para você e quais não são. Quase sempre há coisas em que você acredita à primeira vista "não pode ser testado de antemão", mas se você pensar duas vezes, geralmente há mais possibilidades.

• Trabalhe em equipe. Ao tentar uma nova abordagem ou idéia, discuta-a com pelo menos uma outra pessoa da sua equipe. Ao implementar um algo diferente, insista em inspeções de código e controle de qualidade. Quanto mais erros e problemas você puder evitar de antemão, menos problemas graves você terá que resolver na produção.

• Como você não pode testar tudo antecipadamente, espere que surjam problemas na produção. Portanto, tente preparar uma estratégia de fallback realmente boa ao inserir um novo código em produção. Quando o seu novo código tiver o risco de ser mais lento que a solução antiga, ou se houver o risco de travar, verifique se você pode mudar para a versão anterior o mais rápido possível. Se houver o risco de destruir dados de produção, verifique se você possui um bom backup / recuperação. E certifique-se de detectar essas falhas adicionando algum mecanismo de validação ao seu sistema.

• mantenha um diário do projeto ou um log de solução - seriamente. Todos os dias você descobre algo novo sobre o meio ambiente, anota - histórias de sucesso e histórias de falhas. Não cometa a mesma falha duas vezes.

Portanto, o essencial é que, quando você não pode usar a tentativa e erro, sua melhor opção são as técnicas conservadoras, clássicas de planejamento antecipado e de controle de qualidade.

Se você não pode reproduzir o ambiente ao vivo, a realidade desconfortável é que, o que você fizer, não terá sido suficientemente testado.

Então o que você pode fazer?

Bem, o que quer que seja escalável, seja um processo, cluster de servidor ou volume de banco de dados, deve ser testado com a regra do zero, um, infinito, para identificar onde estão os possíveis gargalos / limitações: IO, CPUs, carga da CPU, entre outros. processo de comunicação etc.

Depois de ter isso, você deve ter uma idéia de que tipo de teste é afetado. Se for teste de unidade, tradicionalmente fica com o desenvolvedor, se for teste de integração / sistema, pode haver pontos de contato com outras equipes que podem ajudar com conhecimentos adicionais ou, melhor ainda, ferramentas.

Falando em ferramentas, não é realmente tarefa do desenvolvedor carregar um sistema de teste além do que é possível em seu ambiente de desenvolvimento. Isso deve ser enviado ao departamento de teste ou a terceiros.

O elefante na sala, é claro, é que os sistemas nem sempre são dimensionados de maneiras previsíveis!

Em uma vida anterior, eu era um DBA para bancos de dados bancários com bilhões de linhas e armado com planos de execução. Em geral, era possível prever quanto tempo as consultas levariam em um banco de dados ocioso, considerando os volumes de entrada. No entanto, uma vez que esses volumes chegassem a um determinado tamanho, o plano de execução mudaria e o desempenho deterioraria rapidamente, a menos que a consulta / banco de dados fosse ajustada.

Eu sugeriria experimentos.

O registro encontrará gargalos. Você pode tentar uma implementação alternativa em algumas máquinas, ou mesmo em todas as máquinas com uma certa probabilidade ou por um período de tempo limitado. Em seguida, compare os logs novamente para verificar se há melhorias.

É o mesmo ciclo de teoria-experimento-medida que você está acostumado, mas é mais caro de configurar - já que as hipóteses precisam ser executadas na produção - e, dependendo do seu volume, o recebimento de dados significativos da produção também pode ser lento.