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.
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.
Um cliente ameaça rescindir um contrato de fornecimento alegando descumprimento de SLA contratual, e você tem 48 horas pra montar a defesa. Você pede pra IA cruzar o histórico de entregas com o texto do contrato, e ela aponta, com tom seguro, que o SLA contratual era de 95% e vocês entregaram 93%, favorecendo o cliente. O contrato real definia 90% como meta, não 95%, um número que a IA tirou de um contrato-modelo genérico, não do documento assinado de verdade. Conferir a cláusula original antes de aceitar essa leitura evita ceder num ponto que juridicamente não existe.
A pesquisa de clima da área comercial caiu 15 pontos no eixo de reconhecimento, e o RH quer uma explicação até sexta. Você pede pra IA cruzar a pesquisa com dados de turnover e de promoção dos últimos dois trimestres, e ela monta rápido uma timeline de eventos e aponta, convicta, que a causa foi o congelamento de promoções em março. As promoções não estavam congeladas, o processo só ficou mais lento por causa de um novo comitê de calibração. É você, olhando o processo de perto, que percebe a diferença antes de anunciar uma causa errada pro time inteiro.
A retenção em D7 de uma feature nova despenca 25% numa terça qualquer, sem nenhum anúncio de mudança. Você pede pra IA cruzar os eventos do produto com o changelog de deploys da semana, e ela monta a timeline rápido, apontando um experimento de A/B testing como causa provável, com a mesma confiança de sempre. O experimento realmente rodou naquele dia, mas ele afetava só 5% dos usuários, não os 25% que caíram. A causa real era um bug de cache que ninguém tinha ligado ao experimento. Cabe a você cruzar o percentual antes de fechar a causa e escrever o relatório pro time de produto.
O pipeline do mês despenca 18% numa semana, e o diretor comercial quer saber o motivo antes da reunião de forecast. Você pede pra IA cruzar o CRM com o calendário de feriados e o histórico de sazonalidade, e ela aponta, segura, que a queda é sazonalidade normal de fim de trimestre. Só que, olhando de perto, três vendedores saíram do time nas últimas duas semanas, e é esse detalhe que explica a queda de verdade, não a sazonalidade. É você quem cruza os dois sinais antes de levar uma causa errada pra reunião que decide a meta do próximo mês.
O SLA de entrega despenca de 96% pra 81% numa única semana, e o painel do Zendesk mostra reclamação subindo rápido. Você pede pra IA cruzar o tempo de cada etapa da operação com o volume processado, e ela aponta, com confiança total, que o gargalo está no centro de distribuição principal. O centro de distribuição estava normal; o atraso vinha de uma transportadora nova, contratada há dez dias, que ainda não tinha o roteiro calibrado. Confirmar isso no sistema de rastreio, antes de cobrar o centro errado, é trabalho seu.
Um relatório automático de conformidade acende um controle de LGPD como reprovado, dias antes de uma auditoria externa. Você pede pra IA investigar a origem, cruzando o log de acesso com a política vigente, e ela conclui, segura, que o problema é falta de consentimento registrado. O consentimento estava registrado, só que num campo com nome diferente do que o script de checagem esperava. É você, abrindo o registro original, que evita reportar um incidente de LGPD que não existe pro comitê de risco.
A taxa de conclusão do fluxo de cadastro cai 12 pontos depois de um redesenho, e o time de produto quer entender por quê antes do próximo sprint. Você pede pra IA cruzar as sessões gravadas com o changelog do fluxo, e ela aponta, confiante, que o campo de senha é o ponto de abandono. As sessões mostram o abandono acontecendo, na verdade, na etapa anterior, de verificação de e-mail, que ninguém tinha marcado como suspeita. Revisar as sessões de perto, em vez de aceitar o primeiro palpite, é o que evita redesenhar o campo errado.
Terça de manhã, o board pergunta por que a expansão pro mercado do Sul saiu do orçamento em 30%, e você tem até a tarde pra explicar. Você joga os relatórios financeiros da unidade de negócio na IA, que monta uma timeline de gasto mês a mês em minutos e aponta, com segurança total, que o estouro veio do custo de mídia paga. O custo de mídia paga, na verdade, ficou dentro do previsto; o estouro veio de uma consultoria contratada que a IA não separou direito na planilha. Antes de levar essa causa pro board, é você quem confere linha por linha e corrige a leitura, porque uma causa errada nesse nível vira decisão errada sobre a unidade inteira.
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.
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.
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
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.
- 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.
- Peça pra ela sugerir uma causa provável e rascunhar o postmortem a partir dessa timeline.
- 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.
- 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.
Valeu pelo feedback. Isso ajuda a afiar a próxima aula.