Saudações, pessoal
Vamos falar sobre como escrever um Relatório de Incidente, também conhecido como Postmortem. Em vez de dar-lhe algo da minha própria criação, vamos ver um Relatório de Incidente do Google no início de 2013, o que nos serve comoum bom exemplo.
Trabalhando em TI, todos sabemos que, de tempos em tempos, as coisas nem sempre funcionam como deveriam, apesar do planejamento e das melhores intenções. Quando “o calo aperta”, você pode ser solicitado a escrever um Relatório de Incidente que possa ser compartilhado com executivos, colegas de trabalho ou mesmo clientes.
Quando lemos o relatório do Incidente do Google sobre uma interrupção do serviço da API, temos um reporte simples e objetivo, que tem como função, responder as perguntas costumeiras em caso de interrupção de serviço. Não vamos ler o relatório completo, mas vamos ver a estrutura dos relatórios e várias coisas mencionadas.
O relatório é composto por cinco partes, um resumo de problemas, uma linha de tempo, análise de causa raiz, resolução e recuperação e, finalmente, medidas corretivas e preventivas. Revise cada uma dessas peças em detalhes.
Estrutura do Report
Resumo do problema
- Breve resumo (5 frases)
- Listar a duração juntamente com as horas de início e término (incluir fuso horário)
- Indicar o impacto (a maioria dos pedidos de usuários resultou em 500 erros, no pico de 100%)
- Fechar com causa raiz
Cronograma
- Lista o fuso horário
- Cobre a duração da interrupção
- Quando a interrupção começou
- Quando a equipe foi notificada
- Ações, eventos, …
- Quando o serviço foi restaurado
Causa raiz
- Explicação detalhada do evento
- Não disfarçar nem enfeitar
Resolução e recuperação
- Explicação detalhada das ações tomadas (inclui horários)
Medidas Corretivas e Preventivas
- Lista detalhada de maneiras de evitar que ele aconteça de novo
- O que podemos fazer melhor na próxima vez?
Este Relatório de Incidentes também aponta para o fato de que o Google tem muitos sistemas internos e maquinário processual que está acontecendo nos bastidores. Penso nisso como boas práticas para qualquer empresa. Por exemplo, eles têm capacidades de monitoramento e alertas automatizadas de serviço, sabemos disso porque eles listaram quando a interrupção começou, e quando a equipe foi alertada via pager. Eles também têm gerenciamento de mudanças, na medida em que foram capazes de ver quem fez o que e, em última instância, tentar reverter as mudanças. Em minha mente, essa é a chave, se você não tem essa visibilidade em mudanças, então levará tempo para descobrir o que desencadeou a questão.
Links de apoio:
Artigo base:
https://sysadmincasts.com/episodes/20-how-to-write-an-incident-report-postmortem
Post Mortem do Google:
https://developers.googleblog.com/2013/05/google-api-infrastructure-outage_3.html
Bom pessoal, espero que seja útil
Fico por aqui e até a próxima!
3 Comentários. Deixe novo
Estava procurando com o detalhamento exato de como você abordou como: resumo do problema, cronograma, resoluções e medidas corretivas e preventivas. Muito obrigado!
Boa tarde, Douglas
Que bom que gostou e obrigado por comentar!
abs
[…] postmortem ou MIR (Major Incident Report), pense em como evitar que isso ocorra […]