Sexta-feira, 17:55. Você tá fechando o notebook, já pensando na pizza. E aí: TRIM TRIM, toca o telefone. Se você é dev, já sabe o frio na espinha:
“O que será que deu ruim agora?”
Poucas coisas assustam mais do que uma sala de crise, especialmente numa sexta à noite. E sejamos honestos: quem trabalha com desenvolvimento de software já viveu isso. Eu também. Mais de uma vez. E aprendi algumas lições valiosas (algumas doídas), tanto pelos meus erros quanto observando os vacilos do time.
1. Entrar em pânico
Tá escrito até no “Guia do Mochileiro das Galáxias”: não entre em pânico. E isso serve tanto pra salvar galáxias quanto sistemas em produção.
Durante uma crise, é fácil ser dominado pela ansiedade: mil mensagens no Slack, alertas pipocando, usuários surtando... e o medo de ter quebrado tudo. A tentação de sair clicando desesperadamente, derrubando pods ou alterando configs direto no prod é grande. Só que quase sempre... piora tudo.
Manter a calma não é ignorar o problema, é agir com clareza.
Respira. Reuna o time. Olha os logs. Prioriza. E se der, até dá uma risada (humor também é ferramenta de sobrevivência, como diria o Ford Prefect).
🧠 Pânico gera pressa. Pressa gera erro. E erro... gera mais crise.
2. Tentar resolver sozinho (e no silêncio)
Principalmente no começo da carreira, muita gente tenta “segurar a bronca” sozinha. Por medo de julgamento ou por não ter noção do impacto. Mas o silêncio só faz a crise escalar.
Faça diferente:
- Dê visibilidade para sua liderança sobre o incidente e os impactos no negócio;
- Abra uma sala de guerra (quando necessário) com as pessoas certas;
- Defina um "piloto da crise”, evita conflito de ações e atropelo nas decisões.
3. Procurar culpados no meio do incêndio
Nada trava mais a resolução do que começar uma caça às bruxas no meio do caos.
Troque julgamento por colaboração:
- Foque na solução, não em quem causou.
- Confie que cada pessoa agiu com o conhecimento e contexto que tinha.
- Lembre-se: uma crise raramente acontece por um único erro. São vários elos se rompendo, tipo um acidente aéreo.
4. Buscar a causa raiz antes de estabilizar o sistema
Entrar no modo “Sherlock Holmes” logo de cara? Nem sempre é o melhor caminho.
Primeiro estabiliza, depois investiga.
- Entenda o que está sendo impactado agora;
- Faça um plano de primeira resposta;
- Se precisar reiniciar serviço, aplicar um comando DML no banco ou até colocar um fix rápido no código... faça. Mas trate a causa raiz depois, com calma.
5. Ignorar o postmortem
Crise resolvida? Ótimo. Agora vem a parte mais importante: aprender com ela.
Trate incidentes como acidentes aéreos, não como batida de carro:
- No trânsito, cada um vê seu prejuízo e segue a vida.
- Na aviação, cada fator contribuinte é estudado, documentado e corrigido.
Postmortem é vacina contra bugs reincidentes.
Se ninguém documentar o que rolou, vai acontecer de novo. E de novo...
Checklist para um bom postmortem:
- Como a falha foi identificada? Cliente? Monitoramento?
- Quais foram os impactos reais?
- O que foi feito na primeira resposta?
- Quais fatores contribuíram para o incidente?
- Como evitar que aconteça de novo?
- A observabilidade falhou? Tinha alerta? Dashboard?
👊 Respira. Aprende. Evolui.
Se você tá no meio de uma crise, ou ainda digerindo a última, calma. Todo mundo erra. Mas errar com consciência e corrigir com colaboração faz toda a diferença.
Top comments (0)