Blog/Artigos · Operações
Severidade, comando de incidente, MTTR e o postmortem sem culpa, com o modelo do Google SRE, o ICS do PagerDuty e ITIL.
Quando o inimigo chega à terra, a Torá manda tocar as trombetas: um sinal claro que reúne o povo e mobiliza a resposta. Incidente em produção é isso, e a maioria dos times falha justamente no sinal. Ou ninguém toca a trombeta e o problema cresce em silêncio, ou todos tocam ao mesmo tempo e vira pânico sem comando. Gestão de incidentes é a disciplina de tocar o alarme certo, reunir os papéis certos e ter uma só prioridade no fogo: restaurar o serviço, e só depois perguntar por quê.
O primeiro erro é não ter uma escala objetiva de gravidade. Sem ela, tudo é urgente ou nada é, e o time queima em falso alarme ou ignora o incidente real. A escala de severidade, SEV1 a SEV4 ou P1 a P4, define por impacto de negócio, não por componente técnico: SEV1 é o serviço crítico fora para muitos clientes, SEV4 é o incômodo menor sem impacto sentido. A severidade decide quem é acordado, quão rápido e com qual cerimônia.
A severidade precisa ser declarável por qualquer um e ajustável durante o incidente. Quem detecta declara a severidade inicial pela melhor estimativa, e o comando reajusta conforme o quadro clareia. O erro oposto ao alarme de menos é o alarme de mais: declarar SEV1 para tudo esgota o time e dessensibiliza o pager. A escala só funciona se for honesta, e uma matriz de impacto por alcance e por criticidade tira a decisão do achismo.
O incidente grave falha quando vira uma multidão de engenheiros mexendo em tudo ao mesmo tempo, sem ninguém coordenando. A resposta madura é o Incident Command System, adaptado dos bombeiros para a tecnologia pela PagerDuty e pelo Google SRE: papéis claros e temporários. O Comandante do Incidente (IC) coordena e decide, não põe a mão no código. O de operações investiga e conserta. O de comunicação atualiza clientes e liderança. O escriba registra a linha do tempo.
A chave é separar quem coordena de quem conserta. O IC não é o mais sênior nem o que sabe mais do sistema; é quem mantém a cabeça fria, faz as perguntas e toma decisões, liberando os especialistas para focar no conserto sem serem interrompidos a cada cinco minutos por perguntas de status. Numa central de registros, foi exatamente isso que estruturei junto às normas de incidente: severidade P1 a P4, Major Incident Management e RTO de duas horas em P1, para que o fogo tivesse comando, e não corrida.
A métrica que importa no incidente é o tempo de restauração, e ela se decompõe: tempo para detectar (MTTD), para reconhecer, para diagnosticar e para reparar. O MTTR total é o que o cliente sofre, e otimizá-lo raramente significa consertar mais rápido; significa detectar mais cedo e mitigar antes de entender. Reverter o último deploy, redirecionar tráfego, ativar o modo degradado: restaurar o serviço é a prioridade, mesmo sem saber ainda a causa raiz.
É contraintuitivo para o engenheiro, que quer entender antes de agir, mas no incidente a ordem se inverte: mitigue primeiro, investigue depois. A causa raiz é trabalho da gestão de problemas, que vem calmamente depois; o incidente termina quando o cliente parou de sofrer, não quando o mistério foi resolvido. O change failure rate e a facilidade de rollback, métricas do DORA, são o que mais reduzem o MTTR na prática, porque a mitigação mais rápida quase sempre é desfazer a última mudança.
Mitigar vem antes de diagnosticar. O incidente acaba quando o cliente para de sofrer, não quando o mistério é resolvido.
O incidente termina, mas o valor está no que vem depois: o postmortem. E aqui a cultura decide tudo. O postmortem sem culpa, princípio que John Allspaw consolidou na Etsy e que o Google SRE adotou, parte de que as pessoas agiram de forma razoável com a informação que tinham no momento. O foco sai de quem errou e vai para que condições do sistema permitiram o erro, porque punir o indivíduo só ensina o time a esconder incidente, e sistema que esconde falha é sistema que repete falha.
Um bom postmortem tem linha do tempo factual, análise de causa que vai além do erro humano imediato, e ações concretas com dono e prazo, tratadas como trabalho prioritário e não como intenção. O antipadrão é o postmortem que termina em ação corretiva foi mais cuidado, que não muda nada. A pergunta certa não é por que a pessoa clicou no botão errado, é por que o sistema permitia que um clique errado causasse esse estrago, e o que mudamos para que o próximo erro humano seja inofensivo.
| Aspecto | Sem culpa (aprende) | Com culpa (esconde) |
|---|---|---|
| Pergunta central | que condição permitiu o erro? | quem cometeu o erro? |
| Sobre o humano | agiu razoável com o que sabia | foi negligente, precisa treinar |
| Ação típica | mudança no sistema, com dono e prazo | 'ter mais cuidado', sem dono |
| Efeito no time | reporta cedo, aprende, melhora | esconde incidente, repete falha |
Gestão de incidentes é tocar o alarme certo e reunir o comando: severidade objetiva por impacto, papéis claros que separam quem coordena de quem conserta, e uma só prioridade no fogo, restaurar antes de entender. O MTTR encolhe pela detecção precoce e pela mitigação rápida, e o postmortem sem culpa faz a falha não voltar. Google SRE, o ICS do PagerDuty, John Allspaw e ITIL dão o método. A IA vira escriba, aponta a causa e encurta o MTTD, mas comandar o incidente com a cabeça fria continua sendo trabalho humano.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Operaçõesשֹׁרֶשׁ
Incidente apaga o fogo; problema tira a lenha. Sem gestão de problemas, o mesmo incidente volta todo mês. RCA, cinco porquês, Ishikawa e KEDB, com o método do ITIL 4.
Operaçõesנֵר תָּמִיד
Por que AIOps sem SLO vira mais ruído, como o burn rate decide quando acordar alguém e onde o modelo entra na correlação e no diagnóstico.
