Como desenvolvedores, nós temos algumas responsabilidades. Dentre elas, escrever código, estudar novas tecnologias, nos comunicar bem e etc. Além destas, existe uma característica que considero muito importante para um bom desenvolvedor de software, que é a habilidade de fazer um bom troubleshooting. Este nome pode ter diversos significados, mas aqui me refiro a resolução de problemas, sejam eles: bugs, problemas em versões candidatas ou até mesmo incidentes mais graves em produção.
Não importa o quão bom seu time seja, incidentes e bugs em produção sempre irão acontecer, e isso é um fato. Que eles são uma forma de aprendizado muito subestimados, também. Se você nunca teve um problema em produção, parabéns! Ou talvez eu deva recomendar que você melhore seu monitoramento... 😅👀
A verdade é que ninguém gosta de estar responsável por resolver um incidente grave e que pode ter um impacto enorme para o projeto, mas estar on-call, ajuda você ganhar experiência, ao mesmo tempo que te ajuda a conhecer melhor o seu projeto.
Se você é uma pessoa desenvolvedora menos experiente, sem problemas. É importante que alguém mais experiente te auxilie durante os incidentes para resolver tais problemas.
Cada caso é um caso
Com o desenvolvimento das ferramentas e tecnologias, bugs ficam mais complexos e difíceis de identificar e reproduzir.
Por isso, a sequência de passos neste post serve apenas como referência do que eu costumo fazer quando algo grave acontece em um sistema, de forma que a situação tenha o menor impacto possível.
Mas nada impede que outras ações sejam tomadas, dependendo do problema.
0. Documentação
Na verdade, este não deveria ser necessariamente um passo, mas pode acontecer durante todo esse processo que vou detalhar a seguir. É importante registrar as atualizações e descobertas durante todo o processo. De preferência, tudo deve adicionado a um documento de pós incidente (post-mortem).
Se você utiliza as ferramentas da Atlassian, você pode fazer uso de um template que é disponibilizado no Confluence. Se você utiliza outra ferramenta, tudo bem. O importante é que o ocorrido esteja documentado.
Aqui é importante deixar claro:
- O que aconteceu;
- Quando aconteceu;
- E por quê aconteceu.
A ideia aqui não é encontrar culpados para o ocorrido, mas documentar tudo ajuda muito a evitar que o mesmo problema ocorra novamente. Muitas vezes, apontar nomes é interessante para documentar quem participou do processo.
1. Stop the bleeding!
O primeiro passo que costumo aplicar em um momento de incidente é tentar fazer com que o problema pare de ocorrer, ou fazer o que chamamos de parar o sangramento. Fazendo uma analogia com o mundo hospitalar, mesmo que o caso seja mais grave, esse é o momento de aplicar o curativo, não fazer uma cirurgia. Calma, que eu explico.
Muitas vezes a solução para conseguir parar o sangramento não vai ser a mais “bonita”. Ela pode incluir dar rollback, enviar um hotfix para produção, desligar a feature (caso utilize feature flags) ou balancear a carga para redirecionar usuários para outro grupo de servidores. Eu sei, como desenvolvedores queremos pensar na melhor solução logo de cara, a que vai resolver todos os nosso problemas, mas esse não é o momento. Nós teremos tempo pra isso.
Vale lembrar que no momento que a solução paliativa foi aplicada em produção, é importante que os stakeholders sejam comunicados.
2. Investigue e encontre a causa raiz
Pronto, agora você e seu time estão um pouco mais tranquilos para investigar o que realmente ocorreu, entender e documentar os detalhes do que levou o serviços a chegarem naquele incidente.
No mais, continue analisando logs, traces, e tente reproduzir o cenário.
Reproduzir um erro localmente ajuda a detectar a causa raiz do problema e propor uma solução mais rapidamente.
Outra forma de encontrar a causa raiz, é isolando o problema. Aqui cabe remover dependências, testar as credenciais utilizadas em outro servidor ou aplicativo, remover chamadas a APIs de terceiros, chamar métodos diretamente, aplicar a feature em um contexto isolado, e o que mais a sua criatividade sugerir.
Lembre-se de sempre adicionar a solução a documentação ou documento post-moretem.
3. Corrija o problema
Realize a correção, seguindo o processo que seu time utiliza (talvez você precise pular alguns passos aqui 😬), e adicione todos os outros itens que não são urgentes ao backlog para priorização.
Após a correção definitiva, faça questão de adicionar os detalhes a documentação criada no passo 0 e comunicar a todos os envolvidos. Com isso, todo mundo aprende e evita que o problema ocorra novamente.
Dessa forma, você não só resolve o problema imediato, mas também contribui para a melhoria contínua do sistema e do processo de troubleshooting.
4. Monitore a solução
Após realizar a correção do problema, é importante monitorar a solução implementada para garantir que a solução realmente corrigiu o problema. Isso envolve a análise contínua dos logs e métricas relevantes, além de acompanhar o desempenho do sistema e verificar se não há novos problemas surgindo.
É fundamental estabelecer alertas e notificações para identificar qualquer anomalia ou comportamento inesperado. Assim, será possível agir rapidamente caso ocorra algum incidente ou bug em produção novamente.
5. Follow-ups
Após a resolução do problema, é importante realizar follow-ups para garantir que o incidente não ocorra novamente. Follow-ups são aquelas tarefas que podem ser feitas para melhorar o processo como um todo, mas não necessariamente são parte da solução final.
Isso inclui verificar se as medidas corretivas foram eficazes, analisar se há necessidade de melhorias nos processos existentes, analisar se há necessidade de treinamento adicional para a equipe e implementar ações preventivas para evitar problemas semelhantes no futuro.
E aí, existe mais algum passo que você segue ao se deparar com um incidente em produção? Compartilha comigo.
