Gerenciamento de incidentes para equipes de alta velocidade
Análises retrospectivas de incidentes públicas vs. privadas
Como saber o momento certo para compartilhar uma explicação pública pós-incidente
Houve um tempo em que quase todos os incidentes de TI ficavam confinados às quatro paredes da empresa onde ocorriam. Mas hoje, com serviços da web e infraestrutura em nuvem, essa situação é rara. Incidentes de tecnologia são um verdadeiro problema "de um para muitos", o que levou a uma grande mudança na forma como as equipes respondem, aprendem e comunicam incidentes.
Considere a análise retrospectiva de incidentes (também chamada de “revisão pós-incidente” ou “PIR”).
Uma análise retrospectiva de incidente reúne as pessoas para discutir os dados de um incidente: por que aconteceu, seu impacto, quais ações foram tomadas para mitigá-lo e resolvê-lo e o que deve ser feito para evitar que aconteça de novo.
Uma análise retrospectiva de incidente pode ser dividida em dois artefatos distintos: a reunião onde o incidente é discutido e o relatório de análise retrospectiva correspondente criado como um resultado dessa reunião.
Essas duas atividades, a reunião e o relatório, são usadas como intercambiáveis com frequência quando as pessoas se referem a uma “análise retrospectiva”. As pessoas podem estar falando sobre um ou ambos quando usam o termo.
Parceiros, clientes e usuários finais também podem querer saber o que aconteceu e quais etapas você executou para melhorar a experiência deles. Disponibilizar a análise retrospectiva de incidente em seu site público pode não ser apropriado em todos os casos, mas sua equipe de marketing ou relações públicas pode ajudá-lo a elaborar a linguagem para que as pessoas obtenham as informações de uma forma que seja informativa e gere confiança em seus serviços.
Quando fazer uma análise retrospectiva de incidente
Na Atlassian, sempre conduzimos análises retrospectivas internas para incidentes de gravidade 1 e 2 ("graves"). Para incidentes pequenos, elas são opcionais. A gente encoraja as pessoas a usar o processo de análise retrospectiva para qualquer situação em que ela seja útil.
Quem conclui a autópsia?
No geral, a equipe que entrega o serviço que causou o incidente é responsável por concluir a análise retrospectiva associada. Ela indica uma pessoa para ser responsável pela conclusão da análise retrospectiva e o item é atribuído a essa pessoa. A pessoa é denominada "proprietária da análise retrospectiva" e conduz a análise por meio de esboço e aprovação, até que ela seja publicada. No geral, os incidentes de nível de infraestrutura e de plataforma afetam uma seção transversal da empresa, tornando as análises retrospectivas mais complicadas e trabalhosas. Por esse motivo, às vezes a gente atribui um gerente de programa dedicado para ser proprietário de análises retrospectivas de nível de infraestrutura ou plataforma, já que este tipo de membro é mais apto a trabalhar entre diferentes grupos e é capaz de se comprometer com o nível de esforço necessário.
Compartilhamento de relatórios internos de análise retrospectiva
Depois que a análise retrospectiva é aprovada, descobrimos que podemos multiplicar seu valor compartilhando o que aprendemos com toda a empresa. Para esse fim, a Atlassian tem uma ação de automação que cria um rascunho de publicação no blog no Confluence quando o tíquete da análise retrospectiva é aprovado.
Como criar um relatório público de análise retrospectiva de incidente
Embora seja menos comum, às vezes, é uma boa ideia fazer uma versão pública de uma análise retrospectiva após um incidente.
Essas versões são comuns para serviços ao consumidor em grande escala que apresentam interrupções que afetam muitos usuários. Na maioria das vezes, essas equipes publicam uma versão reduzida do relatório interno, em vez do relatório interno completo. É importante limpar todas as informações privadas ou confidenciais.
Como compartilhar um relatório público de análise retrospectiva de incidente
Pode ser complicado saber o canal certo para publicar uma análise retrospectiva pública. Para algumas equipes, a publicação pode ser feita no blog ou site da empresa. Outras equipes têm um blog de engenharia específico onde caberia uma análise retrospectiva.
Em nosso produto, Statuspage, usuários podem publicar uma análise retrospectiva pública diretamente em sua página de status após a resolução de um incidente.
Aprenda a comunicação de incidentes com o Statuspage
Neste tutorial, você vai ver como usar templates de incidentes para se comunicar com eficácia durante interrupções. Adaptável a muitos tipos de interrupção de serviço.
Leia este tutorialA importância de um processo de análise retrospectiva de incidentes
Uma análise retrospectiva de incidente, também conhecida como revisão pós-incidente, é a melhor maneira de trabalhar o que aconteceu durante um incidente e capturar as lições aprendidas.
Leia este artigo