Entendendo o problema quando as coisas quebram na produção

Cenário:

• Você empurra para a produção
• O empurrão quebrou várias coisas
• Essa mesma construção não quebrou qa ou dev
• Como desenvolvedor, você não tem acesso a produtos.
• Há muita pressão de cima para fazer as coisas funcionarem novamente.

Específicos:

• Aplicativo PHP / MVC orientado por API no Zend.
• Implantado em alguns servidores.

Minha pergunta:

Ao investigar, digamos que tenho um palpite de que algo está errado. Mas não sei ao certo. E, é claro, não posso testar as coisas na produção. Se eu tiver uma correção sugerida com base nesse palpite, seria sensato tentar aplicá-la e verificar se funciona antes de entender qual é o problema?

Obtenha o máximo possível de informações sobre o problema (arquivos de log etc.) e, em seguida, faça o rollback dos servidores de produção para um estado de funcionamento. Isso é uma dor do ponto de vista do desenvolvedor, é claro, mas é provavelmente um dado.

Em seguida, tente e veja se você pode reproduzir o problema em um ambiente de desenvolvimento. Se puder, corrija-o e tente liberar novamente.

Se você não conseguir reproduzi-lo, verifique se pode adicionar mais diagnósticos e liberar em um servidor por um curto período de tempo para obter mais informações sobre o problema.

Se isso não for possível, observe mais de perto as diferenças entre os ambientes de produção e dev / qa e tente tornar um ambiente de desenvolvimento mais próximo da produção.

Como bem você entende o problema? Qual o risco de seu palpite piorar as coisas? É possível voltar e reproduzir o problema nas regiões DEV / QA? O que você pode fazer para sincronizar sua região DEV / QA para se aproximar do PROD? Talvez você precise alterar algumas configurações ambientais ou do banco de dados, talvez precise importar os dados do PROD para DEV, talvez tenha que alterar algumas configurações de depuração.

Em geral, eu não recomendaria empurrar seu palpite de uma solução para o PROD, a menos que você possa confirmar que ela está realmente correta em outra região. Entendo o tipo de problemas que surgem quando um bug ocorre no PROD e não pode ser reproduzido em nenhum outro lugar. É aí que se trata de ver o que mais difere entre DEV / QA e PROD e focar neles. Na minha experiência, geralmente é uma configuração ambiental ou alguma configuração diferente, especificamente para o PROD. E eu sei que há provavelmente um monte de pressão de cima para corrigir isso, então é possível reverter para o anterior de trabalho do estado e, em seguida, tente reproduzir o problema em DEV, chegar a uma correção no DEV, e , em seguida, tentar novamente no PROD? Isso é o que eu sugeriria.

Depende do tipo de correção. Frequentemente, problemas na produção que não aparecem no dev estão relacionados ao conflito no banco de dados. Portanto, aplicar um bug que altera o conteúdo do banco de dados sem ter certeza do que exatamente está "lá fora" pode ser o primeiro passo para um grande desastre. Se você puder recuperar a alteração facilmente, poderá tentar. Mas, em geral, se você não tiver acesso direto, deve haver pelo menos uma cópia do banco de dados ou de todo o servidor para testes. As pessoas com os privilégios certos ainda teriam que executar o novo código, mas pelo menos sem risco de perda de dados. (Mas, às vezes, o tamanho do banco de dados ou a complexidade da infraestrutura proíbe essa configuração)

É realmente difícil, pois existem muitas possibilidades, como diferentes configurações, bibliotecas e versões de software.

Talvez você possa escrever primeiro um trecho de código que avalie com alguma saída de depuração, se o seu palpite para a origem do bug estiver correto e só então aplique a correção de bug real.

Geralmente, são problemas de configuração ou de dados, assumindo que o código e o banco de dados sejam idênticos entre Prod, QA e dev.

Gostaria de olhar primeiro para o seguinte:

• Qualquer dado de registro que seu código tenha.
• Verifique o visualizador de eventos para obter exceções não tratadas.
• Verifique os dados que representam o andamento do seu aplicativo, ele pode estar no banco de dados, nos arquivos etc. Faz sentido ou não? É o que você espera?

Depois de entender o que está acontecendo, é necessário reverter a produção para um estado funcional e trabalhar para corrigir o problema em um ambiente inferior, até que seja corrigido e reimplantado na produção.

Enquanto seu ambiente é PHP, eu fiz uma apresentação sobre como pensar sobre isso em Java: http://www.infoq.com/presentations/maintaining-production-java-apps

Os principais problemas são os mesmos - para entender os possíveis pontos de estrangulamento para solucionar a situação: rede, acesso ao sistema de arquivos, arquivos de log, conflitos, etc. Além disso, para saber como fazer as perguntas certas: "Sistema inoperante" - "O que você especificamente significa: a página da web está lenta, há mensagem de erro específica, há tempo limite ", etc.

Além disso, existem algumas ferramentas para facilitar a solução de problemas: O Wireshark para solução de problemas de rede é o melhor e vale a pena aprender. Outros dependem do sistema operacional que você usa. Para o Windows, qualquer coisa do SysInternal (agora parte da Microsoft) é brilhante. Para Unix / Linux, veja truss / strace.

No acesso à produção, o grupo de operações deve saber como usar essas ferramentas / técnicas ou você tem um caso de negócios para elas (junto com você) para aprender como usá-las. Depois disso, eles precisam de um conjunto específico de protocolos de solução de problemas para executar quando o problema ocorrer, para que você possa fazer sua análise offline.

Resposta curta: Não se você tiver escolha.

Resposta longa: se você não entender o problema, há vários riscos envolvidos nesse patch:

1. Você pode quebrar outra coisa, que pode até ser menos reproduzível.
2. Você poderia apenas mascarar o problema, dificultando a observação e a reprodução (o que piora)
3. Você está jogando fora a experiência doméstica em potencial - experiência que pode torná-lo um programador melhor e, ao mesmo tempo, mais valioso para sua empresa (ou seja, um potencial aumento futuro).

Por outro lado, não vejo mal algum em verificar primeiro se a sua hipótese de correção funciona e se funciona - então vá mais fundo e descubra o motivo real ou outras maneiras possivelmente melhores de resolver o problema.