ITIL

Como escrever um Relatório de Incidente / Postmortem

4K views
3 Comentários
5
(7)

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!
 

O que você achou disso?

Média da classificação 5 / 5. Número de votos: 7

Nenhum voto até agora! Seja o primeiro a avaliar este post.

Como você achou esse post útil...

Ajude o site a crescer compartilhando o conteúdo

Lamentamos que este post não tenha sido útil para você!

Vamos melhorar este post!

Diga-nos, como podemos melhorar este post?

Tags: google, incidente, itil, postmortem

Artigos Relacionados

3 Comentários. Deixe novo

Gostou do conteúdo? Deixe seu comentário

Secured By miniOrange