Atualizações de status durante incidentes: modelo e cadência

Objetivo

Manter usuários e partes interessadas internas informados enquanto os responsáveis pela resposta trabalham, sem desviá-los para responder perguntas, e deixar uma linha do tempo que o postmortem possa aproveitar.

Pré-requisitos

Papéis definidos por nome: o livro Google SRE (citado) descreve um papel de comunicação cujo ocupante é o rosto público da força-tarefa de resposta ao incidente e emite atualizações periódicas; o SRE workbook (citado) chama esse papel de Communications Lead, que responde ao Incident Commander. Também são necessários uma página de status ou um canal de avisos, uma escala de severidade e modelos combinados antes do incidente.

Passos

1. Quando um incidente é declarado, atribua a comunicação a alguém que não esteja depurando. Se a equipe tiver só duas pessoas, o Incident Commander cuida da comunicação e a outra pessoa investiga.
2. Publique a primeira atualização dentro de um prazo fixo após a declaração, mesmo que ela diga apenas que um problema está sendo investigado. Descreva o impacto do ponto de vista do usuário ("os uploads falham com erro desde 09:40 UTC"), não a causa suspeita.
3. Use um único modelo para todas as atualizações: Status (investigando, identificado, em monitoramento, resolvido), Impacto (quem, o quê, desde quando), O que sabemos, O que estamos fazendo, Solução alternativa (workaround), se houver, e Próxima atualização às, com o horário do relógio e o fuso horário.
4. Cumpra a cadência prometida. Uma atualização que diz "sem alterações; próxima atualização às 11:00 UTC" é informação; uma atualização perdida é um segundo incidente para quem lê. O processo público da PagerDuty (citado) atribui ao seu liaison interno, e não ao Incident Commander, a tarefa de dar atualizações regulares de status à equipe executiva, aproximadamente a cada trinta minutos; escolha uma cadência por severidade e registre-a por escrito.
5. Separe a redação interna da externa. As atualizações internas podem citar sistemas, hipóteses e pessoas; as externas citam os efeitos visíveis para o usuário e as soluções alternativas, e evitam especular sobre a causa.
6. Na resolução, informe o horário, se houve perda ou atraso de dados, o que os usuários precisam fazer (nada, tentar de novo, reenviar o arquivo) e que um postmortem será publicado, com a data.
7. Guarde cada atualização na íntegra; a sequência é a linha do tempo de comunicação para o postmortem, junto com o documento de incidente descrito no livro SRE.

Resultado esperado

As partes interessadas deixam de pedir novidades aos responsáveis pela resposta, porque sabem quando virá a próxima atualização; o postmortem dispõe de horários exatos do que foi comunicado e quando.

Limites e base de verificação

Obrigações contratuais ou regulatórias de notificação ficam fora deste artigo. Os modelos não decidem o que é seguro divulgar; isso continua sendo um julgamento a cada incidente. Os papéis e o valor da cadência vêm dos documentos citados; não se afirma nenhuma redução na duração dos incidentes.