Ganhos:
- Capacidade de compreender o ciclo de vida de um incidente (detecção, triagem, mitigação, resolução, postmortem), métricas MTTD/MTTR e o princípio de 'mitigar primeiro, investigar depois'
- Capacidade de usar IA para restringir hipóteses no momento do incidente e produzir um esboço post-mortem sem culpa, validando cada causa raiz com dados
- Capacidade de aplicar a disciplina de escrever em uma linguagem que não culpe o post-mortem e compartilhar dados de eventos mascarando-os.
Todo sistema eventualmente quebra. A diferença é como as boas equipes se preparam para esse evento inevitável e como aprendem. Incidente é um evento inesperado que interrompe ou ameaça interromper o serviço: uma falha no serviço, tempos de resposta disparados, perda de dados. O gerenciamento de incidentes significa detectar, mitigar, resolver o incidente o mais rápido possível e, então, aprender com ele. Esta é a disciplina que impulsiona os profissionais de DevOps e SRE (Site Reliability Engineering) dia e noite.
Duas métricas críticas medem a qualidade do evento: MTTD (Mean Time To Detect) e MTTR (Mean Time To Recover). O objetivo é encolher ambos. A IA adiciona dois grandes valores aqui: resumir rapidamente os logs e métricas no momento do evento para restringir a possível causa raiz e elaborar rapidamente um post-mortem (relatório de investigação pós-evento) após o evento. Mas as decisões sobre o curso dos acontecimentos - qual serviço desligar, reverter, o que dizer ao cliente - são suas.
Ciclo de vida de um evento
- Detecção: Um alarme soa ou chega uma reclamação do cliente. Quanto mais cedo melhor.
- Triagem: qual a gravidade? Qual é o domínio? Os níveis de gravidade são atribuídos – geralmente SEV1 (mais crítico, sistema inteiro) a SEV4 (menor).
- Monte sua equipe de resposta. Em incidentes críticos, um comandante do incidente assume a coordenação.
- Mitigar: Estancar o sangramento primeiro – geralmente uma reversão ou cobertura de uma bandeira. Você encontrará a causa raiz mais tarde.
- Solução: aplique correção permanente.
- Aprender (postmortem): O que aconteceu, por que aconteceu, como podemos evitar que aconteça novamente?
Dica: Um dos erros mais caros no momento do incidente é atrasar a interrupção do sangramento porque "vamos primeiro descobrir a causa raiz exata". Regra: primeiro diminua (serviço de restauração/restauração) e depois pergunte. Reverter para uma versão em boas condições costuma ser a mitigação mais rápida.
Cultura post mortem sem culpa
A espinha dorsal de equipes saudáveis é uma cultura de post-mortem sem culpa: o objetivo não é “quem fez isso”, mas “que sistema e processo permitiu esse erro?” é a questão. As pessoas escondem o erro se sabem que serão punidas; O erro oculto é repetido. Postmortem não é um relatório de acusação, mas um documento de aprendizagem.
Uma boa análise retrospectiva inclui: resumo, impacto (quantos usuários, por quanto tempo, quanto dinheiro), cronograma, causa(s) raiz(ões), o que deu certo/ruim e itens de ação – medidas concretas, cada uma com um proprietário e uma data.
Cuidado: Ao escrever postmortems com IA, certifique-se de eliminar a linguagem acusatória (ou seja, “a pessoa X cometeu um erro”). Também mascare IDs de clientes, IPs internos e segredos ao alimentar dados de eventos para a IA – os postmortems costumam ser amplamente compartilhados.
Análise de causa raiz: 5 porquês e IA
Uma técnica clássica é a dos “5 porquês”: pergunte “por quê?” para um problema. Ao perguntar repetidamente, você passa do sintoma superficial à raiz real. "O serviço travou. Por quê? Sem memória. Por quê? Houve um vazamento. Por quê? Uma atualização de biblioteca..." A IA é rápida para construir essa cadeia e sugerir possíveis ramificações — mas você deve verificar cada "porquê" com seus dados; A IA também pode construir uma cadeia razoável, mas errada.
Tabela de gravidade
Nível
Impacto
exemplo
intervenção
SEV1
Todo o sistema/perda crítica de negócios
O pagamento caiu completamente
Instantaneamente, toda a equipe, o comandante
SEV2
Disfunção grave
Falha nos logins
Rápido, de plantão + suporte
SEV3
Efeito parcial/limitado
Um relatório está atrasado
durante o horário de trabalho
SEV4
pequeno/cosmético
erro de digitação
fila de trabalho comum
três mini cases
Caso 1 — MTTR de 45 minutos a 8 minutos. O serviço de pagamento travou. O engenheiro de plantão entregou os logs mascarados e as últimas informações de implantação à IA e perguntou “Qual é o gatilho mais provável nos últimos 20 minutos?” ele perguntou. A IA mostrou que o colapso começou no mesmo minuto da última implantação. O engenheiro reverteu imediatamente essa versão; O serviço retornou em 8 minutos. A causa raiz (um bug no pool de conexões na nova versão) foi então convenientemente investigada.
Caso 2 – esboço post mortem em 20 minutos. Depois de um SEV2, a equipe estava cansada e sem forças para escrever um relatório; muitas vezes o relatório era adiado por semanas. Desta vez, eles forneceram a linha do tempo e as notas do incidente à IA e produziram um esboço post-mortem livre de crimes. A IA criou uma estrutura elegante para impacto, cronograma e itens de ação; A equipe preencheu com fatos e publicou em 20 minutos. A lição não foi perdida.
Caso 3 – causa raiz errada detectada. Em um caso, a IA disse “causa raiz da sobrecarga do banco de dados” e parecia razoável. Mas o engenheiro confirmou as métricas: a carga do banco de dados estava normal no momento do incidente. A verdadeira causa foi um problema de DNS externo. A hipótese inicial da IA era fluida, mas errada; A validação com dados evitou que o relatório fosse publicado com conclusão incorreta.
Quatro modelos copiáveis
1) Triagem rápida no momento do incidente:
Estamos vivenciando um evento de produção. Sintomas mascarados: [SINTOMA].Últimas alterações: [LAST DEPLOY/CHANGE]. Dê-me: (1) as três hipóteses de causa raiz mais prováveis em ordem de probabilidade, (2) o comando/métrica que verificará cada uma em 1 minuto, (3) a etapa de mitigação SAFE mais rápida (por exemplo, reversão). Declare que devo verificar cada hipótese.
2) Esboço post-mortem inocente:
Escreva um esboço post-mortem inocente a partir das notas do incidente abaixo. Seções: Resumo, Impacto (usuário/duração/custo), Cronograma, Causa(s) raiz, O que deu certo, O que deu errado, Itens de ação (cada um com proprietário + campo de data). Concentre-se em nomenclatura, processo e sistema. Notas: [MASCARADO]
3) Análise dos 5 porquês:
Construa uma cadeia de "5 Porquês", começando com o seguinte sintoma: [SINTOMA].Mostre se há mais de uma ramificação possível em cada etapa. Ao lado de cada "porquê" escreva a evidência (log/métrica) que analisarei para verificá-la. Ao final, marque quais etapas ainda não foram verificadas.
4) Criação de itens acionáveis:
De acordo com essa causa raiz, sugira itens acionáveis que impedirão a recorrência do mesmo evento. Classifique cada item por: (a) prevenção, detecção ou redução, (b) esforço estimado, (c) impacto. Classifique pela maior relação impacto/esforço. Causa raiz: [X]
Alerta fraco / Alerta forte
Fraco: “O serviço travou, o que devo fazer?”
Resultado: sem contexto; A IA pode fazer recomendações gerais que não se adequam ao seu caso e pode até chegar a uma causa raiz definitiva.
Forte: "O serviço de pagamento de produção está dando 5xx há 5 minutos. A última implantação foi há 6 minutos. Forneça as três hipóteses de causa raiz mais prováveis em ordem de probabilidade, informe o comando que verificará cada uma delas e sugira a mitigação segura mais rápida. Não seja específico, declare que preciso verificar."
Diferença: o segundo prompt fornece o sintoma, o momento e a última alteração; exige hipótese + verificação + redução e mantém a IA imprecisa.
Erros comuns
- Procurando a causa raiz exata antes de mitigar. Atrasa a interrupção do sangramento e aumenta o MTTR.
- Publicar a primeira hipótese de IA sem verificá-la. Raiz fluida, mas falsa, causa vazamento no relatório.
- Linguagem acusatória. Postmortem escrito anonimamente promove ocultação e repetição de erros.
- Relatório orientado para a ação sem marcadores. Uma proposta sem dono e data nunca será implementada.
- Compartilhando dados de eventos sem mascará-los. Postmortem chega a um público amplo; dados secretos/pessoais são vazados.
- Não preparar antecipadamente o caminho de reversão. Se a reversão não for prática, a redução será retardada.
Resumindo
O gerenciamento de incidentes consiste em detectar, mitigar, resolver e aprender rapidamente com eventos inevitáveis; MTTD e MTTR são métricas importantes. A regra de ouro é “mitigar primeiro, investigar depois” e reverter para a versão conhecida é muitas vezes a mitigação mais rápida. A IA é inestimável para resumir registros no momento do evento, restringir hipóteses e produzir esboços post-mortem isentos de culpa após o evento – mas é sua responsabilidade validar cada hipótese de causa raiz com dados, eliminar a linguagem de culpa e mascarar dados do evento.
Tarefa de aplicativo
Considere um evento passado (ou fictício). (1) Fazer com que a IA gere hipóteses e etapas de verificação com o modelo de “triagem rápida no local”; Observe qual hipótese pode ser confirmada pelos dados. (2) Esboce um relatório usando o modelo “esboço post mortem inocente” e preencha-o com fatos. (3) Identifique pelo menos dois itens acionáveis e atribua um proprietário e uma data a cada um.
lista de verificação
- [ ] No momento do incidente, pensei primeiro em mitigar (reversão/desligamento) e deixei a causa raiz para mais tarde.
- [] Verifiquei todas as hipóteses de causa raiz da IA com log/métrica.
- [ ] Escrevi em uma linguagem que não culpa post-mortem, focando no processo e no sistema.
- [] Atribuí a cada item acionável um proprietário e uma data.
- [] Mascarei as informações secretas e pessoais dos dados do evento que forneci à IA.
- [ ] Atribuí o nível de severidade corretamente de acordo com o impacto.