sábado, Janeiro 20, 2018
Breaking News
Home » ITIL » Como escrever um Relatório de Incidente / Postmortem

Como escrever um Relatório de Incidente / Postmortem

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!

 

Sobre Diego Duarte

Diego Duarte Atua como coordenador de NOC, toca um violãozinho nas horas vagas e tenta eternamente entender o que o fez escolher TI

Veja também!

Dica: Ferramenta do Google para verificar performance de Websites

Saudações, pessoal Manter um site rápido e adequado às principais formas de acesso (navegadores PC …

Este artigo lhe foi útil? comente e ajude outros acrescentando seu ponto de vista!