Incident response B2

Nível: B2

Objetivo

Conduzir um incidente em inglês usando a linguagem de um incident commander: declarar severidade, montar timeline, propor mitigação, separar root cause de sintomas, escalar com critério e manter uma cadência de comunicação clara para stakeholders técnicos e de negócio.

Explicação

Em um incidente real, a maior parte da confusão não é técnica — é de comunicação. O engenheiro que lidera o incident (o incident commander, ou IC) precisa falar de forma curta, factual e temporalmente precisa, em três frentes ao mesmo tempo: a frente técnica (o que está acontecendo e o que está sendo feito), a frente de stakeholders (status para produto, suporte, liderança) e a frente de mitigação (o que vamos fazer agora para reduzir impacto). Em B2, espera-se que o IC conduza essa conversa em inglês com vocabulário preciso, sem perder o tom calmo que o time precisa ouvir.

1. Papéis em um incidente

• Incident commander (IC): não é quem conserta o sistema; é quem coordena. Declara o incidente, define a severidade, faz as perguntas certas, decide quando escalar e mantém a cadência de updates. *I'm taking IC on this.*
• Operations lead / tech lead: é quem efetivamente investiga e executa a mitigação. Reporta ao IC.
• Communications lead (em incidentes maiores): escreve os status updates externos e atualiza a status page. Em times pequenos, o IC acumula esse papel.
• Subject-matter experts (SMEs): pessoas convocadas para áreas específicas (banco, rede, billing). Entram quando o IC precisa de uma opinião especializada.

2. Severidade

Severidade descreve o impacto ao cliente e à operação, não a complexidade técnica. A escala varia entre empresas, mas o padrão mais comum é:

• SEV1 / Sev-1: impacto crítico — perda de receita, dados em risco, serviço totalmente indisponível para um grande grupo de usuários. Paging 24/7, IC obrigatório, updates a cada 15 minutos.
• SEV2: impacto significativo — funcionalidade principal degradada, alguns clientes afetados. Paging no horário do on-call, updates a cada 30 minutos.
• SEV3: impacto limitado — bug visível, workaround conhecido, poucos clientes. Paging opcional, atualização via ticket.
• SEV4: impacto mínimo — cosmético ou observacional. Não vira incidente, vira ticket.

Dizer a severidade em voz alta é um dos primeiros atos do IC: *I'm declaring this a SEV2 based on customer impact.* A frase importa porque toda a cadência de comunicação em volta depende dessa escolha. Errar para baixo (chamar de SEV3 o que é SEV1) é pior do que errar para cima, porque atrasa a mobilização.

3. Mitigação vs root cause

Um erro B2 comum é confundir mitigação com resolução definitiva. Em incidente, mitigação é qualquer ação que reduz o impacto agora — pode ser um rollback, um feature flag desligado, um rate limit, um redirect. Root cause é a causa técnica que originou o problema, e ela é investigada depois que a mitigação está em curso.

• *We're rolling back release 412 as a mitigation. The root cause is still under investigation.*
• *Mitigation in place: traffic is now routed to the secondary cluster. We're still looking for the root cause.*

O IC deve sempre separar as duas frases. Se a equipe está só mitigando, diga *mitigation in place, root cause unknown*; se a causa já foi identificada, diga *root cause identified as X, working on permanent fix*.

4. Timeline

A timeline é o registro temporal do incidente em ordem cronológica, com horários e frases curtas. O IC mantém a timeline durante o incidente e ela vira a base do postmortem. Boas entradas de timeline têm:

• Horário (em UTC, idealmente).
• Fato observável, não interpretação: *14:07 UTC — payment API returned 500 for 12% of requests* em vez de *14:07 — something broke*.
• Quem fez o quê: *14:12 — Nina rolled back release 412*.
• Decisões: *14:15 — escalated to SEV1*.

Em B2, o IC fala a timeline em voz alta nos updates: *Here is the timeline so far: at 14:00 the alert fired, at 14:05 we paged the on-call, at 14:07 we identified the affected service, and at 14:12 we rolled back.* Cada entrada é um fato, não um sentimento.

5. Escalation

Escalar é trazer mais pessoas ou mais autoridade para o incidente. A decisão de escalar é do IC e acontece em três gatilhos típicos:

• Severidade aumenta durante o incidente: *I'm escalating this from SEV2 to SEV1 because the blast radius is now wider than expected.*
• Capacidade técnica se esgota: o time atual não consegue avançar na mitigação e precisa de um especialista (banco, segurança, rede). *We need to escalate to the database team — please page the DB on-call.*
• Impacto de negócio se amplia: receita, clientes chave ou dados em risco. *Given the impact on enterprise customers, I'm escalating to leadership and to legal.*

Note o uso de I'm escalating (voz ativa) em vez de *it's being escalated* (voz passiva distante). Em incidente, voz ativa reduz ambiguidade sobre quem está decidindo.

6. Cadência de comunicação

Communication cadence é a frequência com que o IC emite updates. A regra é: cadência mais curta para severidade mais alta.

• SEV1: update a cada 15 minutos, mesmo que a atualização seja *no change, still mitigating*.
• SEV2: update a cada 30 minutos.
• SEV3: update quando há mudança relevante.

Um update eficaz tem quatro blocos:

1. O que sabemos (fatos confirmados).
2. O que estamos fazendo (mitigação em curso).
3. O que mudou desde o último update (uma frase).
4. Próximo update em X minutos.

Exemplo: *Update at 14:30 UTC: payment API is still returning errors for ~8% of requests. Mitigation in place — we rolled back release 412 and traffic is recovering. No change in scope since the last update. Next update at 14:45 UTC.*

O IC nunca deixa o canal em silêncio por mais de 15 minutos em um SEV1, mesmo que o conteúdo seja *no change* — silêncio durante um incidente faz as pessoas assumirem o pior.

7. Linguagem do incident commander

Frases-modelo que o IC usa o tempo todo:

• *I'm declaring a SEV2 incident for the payments service.*
• *Who is the operations lead on this? I need one person investigating.*
• *Can someone give me a status update in two sentences?*
• *What's the current customer impact? Number, not adjectives.*
• *What's our mitigation, and when does it go in?*
• *I need the timeline so far, in UTC.*
• *I'm going to escalate this to SEV1 — please page the secondary on-call.*
• *Mitigation in place. We're now in recovery mode.*
• *Hold on deploys until we close the incident.*
• *Action items will go to the postmortem; for now, focus on mitigation.*

O tom é direto, sem drama, sem hedge desnecessário. Em incidente, *I don't know* é uma resposta aceitável e melhor do que uma resposta inventada — desde que seja seguida de *and here's how we're going to find out*.

Exemplos

Erros comuns

• Confundir mitigation com root cause: dizer 'we fixed it' depois de um rollback é tecnicamente errado — rollback é mitigação; o fix permanente vem depois do postmortem.
• Declarar a severidade sem números de impacto: 'this is bad' não é severidade; '12% of payment requests are failing' é.
• Escalar de forma passiva ('it was decided to escalate') em vez de ativa ('I'm escalating this to SEV1'). Em incidente, voz ativa deixa claro quem decidiu.
• Pular a timeline e falar em ordem lógica ('first we did X, then Y') em vez de ordem cronológica. A timeline é temporal, não narrativa.
• Silêncio entre updates em SEV1: se passou mais de 15 minutos sem comunicação, as pessoas assumem que está pior do que está. Update 'no change' é melhor que ausência de update.
• Misturar canais: discutir mitigação no canal de stakeholders ou status no canal técnico. O IC mantém papéis e canais separados, mesmo em times pequenos.
• Tratar SEV3 como se fosse SEV1 (paging 24/7, cadência de 15 min) ou SEV1 como SEV3 (updates vagos, sem paging). A severidade dita a cadência — não a intuição do IC.
• Dizer 'we are looking into it' como update final. Em B2, o IC sempre fecha com próximo passo ou próximo horário de update.

Prática guiada

Reescreva cada bloco seguindo o padrão do incident commander: severidade → impacto numérico → mitigação → root cause → cadência.

1. Declaração de severidade

`Payments is broken, looks bad.` → `I'm declaring a SEV1 for the payments service. Roughly 30% of requests are returning 500 errors.`

1. Mitigation vs root cause

`We turned off the new feature and the errors stopped. Done.` → `Mitigation in place: we disabled the checkout feature flag and errors dropped to baseline. Root cause is still under investigation; we'll open a postmortem after we close the incident.`

1. Escalation

`Someone should call the DB team.` → `I'm escalating to the database team — please page the DB on-call. We need a DBA in the bridge.`

1. Update 'no change'

`Still working on it.` → `Update at 15:00 UTC: no change since the last update. Mitigation is holding; error rate steady at 1.2%. Next update at 15:15 UTC.`

Repare que cada frase carrega uma decisão ou um fato, não uma opinião. Esse é o tom de um IC em B2.

Resumo

Conduzir um incidente em inglês é, antes de tudo, conduzir uma conversa. O incident commander (IC) declara a severidade com base em impacto numérico (SEV1 a SEV4), separa mitigation (o que reduz o impacto agora) de root cause (a causa que será investigada depois), mantém uma timeline em UTC com fatos observáveis, decide escalations em voz ativa quando o blast radius aumenta ou a capacidade técnica se esgota, e segue uma communication cadence curta para severidades altas (15 min em SEV1, 30 min em SEV2). A linguagem é direta, sem hedge desnecessário, com frases-modelo: *I'm declaring a SEV2*, *mitigation in place, root cause under investigation*, *I'm escalating this to SEV1*, *no change since the last update*.

História: Incident response B2

Nível: B2

História em inglês

Friday night, 14:00 UTC

It was a Friday night when the alerts started firing across the payments service. Within two minutes, the error rate jumped from 0.4% to 12%. Nina, the on-call engineer, opened the incident bridge and said, "I'm declaring a SEV1 for the payments service. Customer impact is roughly 12% of payment requests failing with 500 errors." She added, "I'm taking IC. Marcos, can you take operations lead? We'll need a database engineer on this within ten minutes."

Building the timeline

By 14:05 UTC, Marcos had joined the bridge and started pulling logs. At 14:07 UTC, the team confirmed the affected service: the new retry logic introduced in release 412. Nina said, "Here is the timeline so far: at 14:00 the alert fired, at 14:02 the error rate crossed 10%, and at 14:07 we identified release 412 as the suspect. Next status update at 14:15 UTC." She then asked, "What's the current blast radius? I need a number, not adjectives." Marcos answered, "Roughly 12% of payment requests across two regions. No impact on refunds yet."

Mitigation in place

At 14:12 UTC, Marcos rolled back release 412 as a mitigation. By 14:18 UTC, the error rate had dropped to 0.6%. Nina sent the next status update: "Mitigation in place: release 412 rolled back, error rate back to baseline. Root cause is still under investigation. Next update at 14:30 UTC." She also announced, "We are holding all deploys to the payments service until we close the incident." Marcos added, "The database team is investigating a misconfigured retry policy in the worker. That's the leading candidate for the root cause, but we need to confirm."

Escalation and close

At 14:25 UTC, support reported that two enterprise customers were also seeing failures in their reconciliation jobs. Nina said, "I'm escalating this to leadership and to legal — enterprise customers are affected, and we need both groups in the loop." By 14:40 UTC, the error rate was stable at 0.4% and no new customer reports had come in. Nina closed the incident at 14:55 UTC: "Mitigation held for 40 minutes. We're downgrading from SEV1 to SEV3. Root cause is the retry policy in release 412 — that will go to the postmortem. Action items will be tracked there."

Tradução linha por linha

Notas de vocabulário

• I'm declaring a SEV1 = abertura padrão de um incidente: severidade + nome do serviço.
• I'm taking IC = assumir o papel de incident commander; voz ativa e direta.
• customer impact = sempre em números, não em adjetivos ('about 12% of requests').
• timeline so far = registro cronológico do incidente em UTC; base do postmortem.
• rolled back release 412 as a mitigation = rollback é mitigação, não fix; o fix vem no postmortem.
• Mitigation in place = frase-modelo para indicar que a ação imediata está segurando o sistema.
• root cause is still under investigation = frase-modelo para indicar que a causa ainda não foi fechada.
• holding all deploys = ação padrão do IC para estabilizar o sistema durante o incidente.
• I'm escalating this to leadership = voz ativa + razão do escalation (clientes enterprise afetados).
• downgrading from SEV1 to SEV3 = rebaixar a severidade quando o impacto se reduz; cadência também muda.

Perguntas de compreensão

1. What service was affected by the incident?
2. What severity did Nina declare when the incident started?
3. What was the customer impact when the incident was declared?
4. Who took operations lead on the bridge?
5. What was the first mitigation the team applied?
6. Why did Nina escalate the incident to leadership and legal?
7. What did Nina announce about deploys during the incident?
8. What was identified as the root cause of the incident?
9. What did Nina do at 14:55 UTC?

Prática com a história

1. Transforme em voz ativa do IC: 'It was decided to escalate the incident to SEV1.'
2. Preencha: 'Mitigation ___: we rolled back release 412 and the error rate is back to baseline.'
3. Classifique: 'The retry policy in the worker was misconfigured and caused the crash.'
4. Escreva um update 'no change' para um SEV1 com mitigation segurando, incluindo horário e próximo update.
5. Reescreva a frase do IC em tom mais formal: 'We're saying it's SEV1.'