Como lidar com uma falha em produção: um manual para equipas pequenas

Numa falha, o problema técnico raramente é a parte difícil. A coordenação é. Esta é a sequência que impede uma equipa pequena de piorar a situação.

A maioria das equipas pequenas lida mal com a sua primeira falha séria — não por incompetência, mas porque toda a gente depura ao mesmo tempo, ninguém fala com os clientes e duas pessoas fazem deploy de correções contraditórias. O manual abaixo existe para evitar isso.

Os primeiros dez minutos

1. Declare-a. Diga a palavra «incidente» em voz alta no canal da equipa. A ambiguidade sobre se isto é sério custa mais tempo do que qualquer passo técnico.
2. Nomeie um responsável do incidente. Uma pessoa, explicitamente. Ela não depura — coordena, decide e mantém a cronologia.
3. Avalie o raio de impacto: quem é afetado, há dinheiro a mover-se de forma errada, há dados em risco. Isso determina tudo o que se segue.
4. Estanque a hemorragia antes de encontrar a causa. Rollback, desativar a funcionalidade, colocar manutenção. Compreender pode esperar; o impacto no cliente não.
5. Publique uma mensagem de estado. Mesmo «estamos a investigar» é melhor que silêncio — é o silêncio que transforma uma falha num problema de confiança.

Papéis, mesmo numa equipa de quatro

Numa equipa pequena uma pessoa pode acumular dois papéis — mas responsável do incidente e investigador nunca devem ser a mesma pessoa num incidente sério.

O que dizer aos clientes

• Reconhecer depressa, mesmo sem respostas — «temos conhecimento e estamos a investigar» em minutos
• Enunciar o impacto nos termos deles: o que não conseguem fazer agora, não que serviço está degradado
• Dar uma hora para a próxima atualização e cumpri-la mesmo que nada tenha mudado
• Nunca especular sobre uma causa por confirmar — retratações custam mais confiança do que o silêncio teria custado
• Dizer claramente quando está resolvido, e seguir com uma explicação escrita se o impacto foi material

Depois: a parte que toda a gente salta

Um postmortem em 48 horas, enquanto a memória é fiel. Sem culpados — não por delicadeza, mas porque a culpa leva as pessoas a esconder informação e o incidente seguinte torna-se mais difícil de prevenir.

• Cronologia: o que aconteceu, quando, quem fez o quê — apenas factos
• Impacto: duração, utilizadores afetados, consequências de dinheiro ou dados
• Fatores contribuintes, no plural — uma causa raiz única é quase sempre uma simplificação
• Ações com responsáveis e datas; itens sem ambos são decoração
• O que correu bem — a deteção ou resposta que funcionou merece ser reforçada

Não subimos ao nível do nosso plano de resposta a incidentes. Caímos ao nível daquele que realmente praticámos.

Preparação antes de acontecer

• Alertas sobre sintomas que os clientes sentem (o pagamento falha), não apenas métricas de infraestrutura (CPU alto)
• Um rollback que é um comando e foi ensaiado em condições calmas
• Uma página de estado que existe antes de ser precisa
• Escalonamento escrito: quem se liga às 3 da manhã, e quem se essa pessoa não atender
• Um ensaio — parta algo de propósito em staging e siga o manual

Confirmar a recuperação pelos percursos reais

Menos erros podem ocultar dados inconsistentes. Defina o que deve ser demonstrado antes de encerrar o incidente.

1. Registar impacto, último estado correto e alterações recentes.
2. Escolher uma ação reversível com responsável e condição de paragem.
3. Verificar percursos críticos, tarefas atrasadas e reconciliação.

• resposta a incidentes de produção →
• boas práticas postmortem →