Negócios: Tecnologia · Aula N.tec.5

Coreografia: incident response com copiloto

A IA correlaciona log entre serviços e monta a timeline do incidente em minutos, mas a causa raiz, o rollback e a assinatura do postmortem continuam sendo do incident commander humano.

Exemplos para

Três da manhã, PagerDuty dispara. O checkout está devolvendo erro 500 pra 12% dos pedidos, e o time inteiro acorda tentando entender o que mudou nas últimas duas horas. Antes disso era vasculhar Datadog, Grafana e o log do serviço de pagamento um por um, quase quarenta minutos só pra montar a linha do tempo antes de sequer cogitar uma causa. Hoje você cola os logs dos três serviços na IA e, em menos de dois minutos, ela devolve uma timeline com o horário de cada erro, o deploy que saiu às 2h48 e a versão anterior estável. Ela também sugere, com a mesma confiança de sempre, que a causa é uma migração de banco que rodou junto. Só que essa migração já tinha rodado semana passada sem problema nenhum, e é você, o incident commander, que precisa notar isso antes de decidir o rollback.

Putz, três da manhã, alarme disparando, e a primeira pergunta na sua cabeça nunca é "o que está bonito", é "o que mudou". Antes disso significava abrir três, quatro painéis diferentes e cruzar log na mão, meia hora perdida só pra entender a cena do crime antes de sequer cogitar uma causa. A IA muda essa parte de um jeito real: ela lê tudo isso rápido e te entrega uma linha do tempo. O problema é que ela também aponta uma causa, com a mesma cara de certeza de sempre, e nem sempre ela acertou.

A ideia central desta aula. Um incidente tem uma coreografia com passos fixos, e a IA entra com força nos passos mecânicos: correlacionar log entre serviços, montar a timeline, rascunhar o postmortem. O que continua seu, sempre, é a causa raiz, a decisão de fazer rollback, corrigir ou esperar, a decisão de escalar, e a assinatura final do postmortem. A IA acende a cena; você lê a cena e decide o que fazer com ela. E como em todo lugar deste módulo, a causa que ela propõe é suspeita até você conferir no log real.

01A coreografia do incidente, passo a passo

Um incidente bem conduzido tem uma ordem, e pular passo é o que faz time bom errar decisão simples sob pressão. Detectar, montar a timeline, levantar a causa provável, decidir a ação, comunicar, e por fim escrever o postmortem. Seis passos, papéis bem definidos entre máquina e pessoa.

A IA entra com força nos passos dois e seis: montar a timeline a partir do log bruto, e rascunhar o postmortem a partir do que já aconteceu. Você entra com força nos passos três, quatro e cinco: levantar a causa de verdade, decidir a ação, e comunicar com a sua própria voz pra quem precisa saber. O passo um, detectar, geralmente já vem de um alerta automático, PagerDuty, Datadog, o que for; a coreografia começa de fato quando alguém, você, assume o comando.

1 Detectar alerta dispara 2 Timeline a IA monta 3 Causa você audita 4 Decidir rollback ou não 5 Comunicar sua voz 6 Postmortem a IA rascunha passos 3, 4 e 5 são seus passos 2 e 6: a IA monta o rascunho

02Onde a IA entra com força: correlacionar log e montar a timeline

Aqui a IA ganha o seu tempo de verdade. Um incidente moderno cruza serviços: o frontend, a API, o banco, um fornecedor externo, cada um com o próprio log, em ferramentas diferentes. Juntar isso na mão, olhando timestamp por timestamp em Datadog, Grafana e no log bruto do serviço, é o tipo de trabalho mecânico que consome os primeiros vinte, trinta minutos preciosos de qualquer incidente.

Cole os logs relevantes na IA e peça exatamente isso: uma timeline com horário de cada evento, o que mudou perto do início do problema (deploy, migração, mudança de configuração), e os serviços afetados em ordem. Ela faz isso em segundos, e o ganho de tempo é real. Mas repare no limite: isso é leitura de eventos, não conclusão sobre a causa. A IA aponta o que aconteceu e quando. O que aquilo significa ainda não está decidido.

03Onde não entra: causa raiz, rollback e escalada

Aqui mora o risco que dá nome a esta aula. Depois de montar a timeline, a maioria das ferramentas de IA vai um passo além e sugere uma causa provável. E ela faz isso com o mesmo tom seguro de sempre, seja a causa certa ou inventada. Ela pode citar a linha errada do diff, culpar um serviço que só coincidiu no tempo, ou repetir um padrão comum de falha que não é o seu caso.

Por isso a causa raiz de verdade é sempre uma decisão sua, conferida no log original, não aceita porque "parece razoável". O mesmo vale pras três decisões que vêm em seguida: fazer rollback, aplicar um hotfix ou esperar; escalar pra outro time ou não; e declarar a severidade do incidente. Nenhuma dessas decisões é técnica pura, todas carregam um julgamento de risco e de contexto que só quem está no comando do incidente consegue pesar. A IA nunca assume o comando. Ela entrega munição pro comandante decidir.

IA propõe causa tom seguro, certa ou não você confere no log original bate: rollback ou hotfix decidido não bate: investiga mais, ou escala a decisão só sai depois da conferência, nunca antes

04O runbook vivo

Todo incidente que se resolve carrega uma lição, e a maioria dessas lições morre no chat do time em vez de virar conhecimento reusável. O runbook vivo é o oposto disso: cada incidente real que passa pela sua mesa vira uma atualização concreta no runbook, não uma revisão trimestral que ninguém lembra de fazer.

Depois de fechar o incidente, peça pra IA comparar o que aconteceu com o runbook atual: esse cenário já estava coberto? O passo que funcionou precisa entrar como novo procedimento? Isso é o mesmo princípio do sistema que melhora sozinho que você já viu no módulo de Financeiro, aplicado aqui: o runbook não é um documento que se escreve uma vez, é uma peça que cresce com cada entrega real. Você já viu, na aula 6.1, a IA operando um processo inteiro com portões de qualidade; o runbook vivo é o portão de conhecimento desse mesmo processo, ficando mais forte a cada rodada.

Saiba mais: por que o postmortem sem culpa protege a qualidade da causa raiz

A prática de postmortem sem culpa (blameless postmortem) existe porque, quando alguém teme ser apontado como o erro, a tendência é simplificar a causa raiz pra encerrar o assunto rápido, "foi um erro de configuração" em vez de investigar por que o processo permitiu esse erro chegar em produção. Isso importa duas vezes mais quando a IA está no meio: se o time aceita a primeira causa que ela sugere só pra fechar o caso mais rápido, a causa real, geralmente uma falha de processo, continua escondida e o mesmo incidente volta a acontecer. Um postmortem sem culpa, auditado com cuidado, é o que impede tanto a pessoa quanto a máquina de virar bode expiatório barato de uma causa que ninguém investigou direito.

05Auditoria do postmortem antes de publicar

O rascunho de postmortem que a IA escreve costuma ser bom: organiza a timeline, descreve o impacto, sugere ações de prevenção. O risco mora exatamente na seção de causa raiz, porque é ali que ela pode inventar uma explicação plausível que não bate com o log de verdade.

Antes de publicar, quem assina o postmortem confere a causa raiz linha por linha contra o log original, o mesmo princípio de auditoria que atravessa este módulo inteiro desde a primeira aula. Se a causa não bate, o postmortem não sai, não importa quão bem escrito esteja. Um postmortem publicado com causa errada não é só um erro de registro, é uma lição errada que o time inteiro vai carregar pro próximo incidente parecido.

Faça agora

Faça você

Pegue um incidente real recente do seu time, a sua tarefa real ou outro, ou simule um cenário parecido se não tiver um à mão.

  1. Reúna os logs relevantes (do serviço afetado e de pelo menos um serviço vizinho) e peça pra IA montar a timeline: o que aconteceu, em que ordem, o que mudou perto do início do problema.
  1. Peça pra ela sugerir uma causa provável e rascunhar o postmortem a partir dessa timeline.
  1. Agora faça a parte que é sua: abra o log original e confira, linha por linha, se a causa que ela sugeriu realmente bate com o que aconteceu. Anote se bateu ou não.
  1. Se não bateu, escreva a causa real e ajuste o postmortem antes de considerá-lo pronto pra qualquer pessoa ler.

Você acabou de rodar a coreografia inteira, e a parte que separou um postmortem confiável de um bonito e errado foi exatamente a conferência que você fez no passo três.

Pratique

1. Na coreografia de incident response com IA copiloto, o que ela faz bem e com força?

2. A IA sugeriu, durante um incidente, que a causa raiz foi uma migração de banco que já tinha rodado sem problema na semana anterior. Qual é a atitude correta?

3. O que torna um runbook 'vivo', no sentido desta aula?

Para o quadro

Sobre a primeira perguntaàs três da manhã ninguém pergunta o que está bonito. Pergunta o que mudou.
Sobre a divisãomontar a timeline é dela. Causa raiz, rollback e escalada continuam sendo do time.
Sobre o runbookele cresce a cada incidente de verdade, incorporando o que funcionou e o que faltava.
O que você achou desta página?
Recomendaria esta página para alguém do seu time?