O que são Blameless postmortems? | Alura Cursos Online
O que são Blameless postmortems?
6 min6 minutos de leitura
6 min6 minutos de leitura
No ambiente complexo de TI é irrealista dizer que incidentes nunca vão acontecer,e quando eles ocorrem, a forma com que o time lida é crucial. Um processo já conhecido é a criação do postmortem (em português, “depois da morte”), que geralmente é um documento, e tem como objetivo ajudar os times a estruturar um processo para a discussão e análise desses incidentes.
Este documento, geralmente, contém: 1) a descrição do ocorrido e a causa raiz; 2) em qual período a indisponibilidade ocorreu; 3) quais os impactos (perda de dados, por exemplo); 3) a linha do tempo dos fatos ocorridos (hora e descrição); 4) quais medidas foram tomadas para a solução; 5) e quais foram adotadas depois do problema, para evitar que ele ocorra novamente e evidenciar os aprendizados da equipe com a ocorrência.
Autor(a)
Mônica Matos Bock
Oi eu sou o Goku :) apaixonada por café, graphic novels e tecnologia.
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Esse postmortem também pode tomar a forma de uma reunião interna, com as pessoas no papel de SRE (Site Reliability Engineering, ou "Engenharia de Confiabilidade de Sites"). O mais importante aqui é que exista um momento em que o time consiga levantar todos os itens listados acima, para compartilhar o conhecimento e que durante a indisponibilidade, as ações tomadas sejam documentadas para a posteridade, de forma que seja possível analisar não somente o problema, mas também quais foram as ações do time durante o incidente.
Para quais tipos de incidentes criamos postmortems?
Quando um time decide adotar essa prática, é importante que sejam discutidos quais são os critérios para a criação do documento. Alguns exemplos podem ser:
Quando seu sistema fica indisponível mais do que um determinado período de tempo;
Quando ocorre perda de dados;
Quando a experiência do usuário é afetada;
Ou até quando é necessário voltar o sistema à uma versão anterior.
Qualquer empresa pode adotar?
Sim, não é necessário que a sua empresa tenha SREs - por exemplo - para usar postmortem. O mais importante é que seu time converse e saiba os motivos de adotar esse conceito, e que além disso, exista um processo já desenhado e pronto para quando incidentes acontecerem. O uso do postmortem não deve ser iniciado de forma reativa, mas seu time deve estar preparado para usá-lo em qualquer momento. Também deve-se garantir um tempo do time para discutir os postmortems juntos.
Para garantir que tudo será discutido e as ações mapeadas depois do incidente serão resolvidas, é possível adotar um status para os postmortem, como:
“em aberto” quando ainda não foram discutidos;
e dar como “fechados” somente os que já foram avaliados pelo grupo ou que já tiveram todas as ações resolvidas.
Agora que já entendemos o que é postmortem e a sua funcionalidade para o time, vamos entender o que é o Blameless postmortem?
O que é Blameless postmortem?
Para garantir que o processo do postmortem seja maduro, não cause danos ao time e não crie um ambiente com uma cultura ruim, existe o conceito Blameless postmortem (ou em tradução livre, livre de culpa). Nesse formato, tudo é feito sem apontar nomes ou culpados, afinal o que queremos de resultado aqui não é gerar atritos, é avaliar o que causou o problema e garantir que não se repita, ou seja, o foco aqui é o incidente ou falha e não as pessoas.
Para isso, é importante que todos saibam qual o resultado esperado do postmortem, isto é, que todo o time saiba que não deve comunicar o incidente citando nomes, que haja a definição de quem trabalhará nas ações do postmortem colaborativamente, se desvencilhando daquele velho formato conhecido: “quem derrubou o sistema é quem deve corrigi-lo.”
Listamos abaixo algumas ações que você pode incluir no postmortem para garantir a diminuição de riscos nos seus sistemas:
Documentar e alinhar processos;
Escrever testes;
Monitorar os seus sistemas e os sistemas que são vitais para a sua empresa;
Se possível, financeiramente falando, ter um “plano b” para sistemas, como: servidores e provedores de Cloud, que quando caem deixam todos os sistemas offline;
Garantir que o seu time saiba como escrever software de maneira segura.
Vamos ver um exemplo de como essas dicas podem ser aplicadas? Para isso, segue um modelo de postmortem para analisarmos juntos:
Autores: Mônica, Jacque, Leonardo
Data: 18/01/2022
Status: Concluído
Descrição do incidente: Problema nos pagamentos via boleto no checkout.
Detecção: Rodrigo do time de CS informou que um cliente não conseguiu emitir boleto (09:15).
Causa raíz: Indisponibilidade do banco emissor dos boletos.
Linha de eventos:
09:15 Fomos informados pelo time de CS que um cliente não conseguiu emitir boleto.
09:20 Conseguimos reproduzir o problema no ambiente de dev, e o gateway de pagamentos já confirmou a indisponibilidade do meio de pagamento.
09:32 Comunicamos a empresa da indisponibilidade.
09:40 Mariana e Leonardo iniciaram um hotfix (ajuste urgente no sistema) para processar pagamentos de boleto por outro gateway, e assim por outro banco.
10:10 Correção no ar.
10:12 Emitimos um boleto de teste em produção para garantir que estava funcionando.
Impactos: 57 minutos de indisponibilidade na emissão de boletos no site.
Aprendizados e ações:
Garantir que tenhamos uma opção b na indisponibilidade dos meios de pagamento do checkout. Para isso, vamos desenvolver uma funcionalidade que processa o pagamento pelo meio de pagamento disponível (funcionando) no checkout (Responsável: Jacque). Link do card no Trello.
Como pudemos perceber no exemplo supracitado, o time descreve em forma de linha do tempo os eventos que tiveram como origem o incidente reportado às 09:15 e que teve sua correção garantida às 10:12 da manhã. Também consta ali o plano de ação para evitar que a indisponibilidade do meio de pagamento boleto volte a ocorrer, ou seja, o documento coloca em evidência o incidente e a solução e não responsabiliza nenhuma pessoa pelo problema.
É importante lembrar que deve-se ter cuidado ao citar nomes de membros do time no postmortem, para não fazer de forma que atribua culpa. Além disso, você pode registrar quem foi o responsável pelas ações de correção após o início do incidente. Se desejar, você pode registrar também o nome das empresas que são suas clientes e que foram afetadas.
Conclusão
Como vimos, com a adoção do postmortem a equipe consegue ter ali documentado, não somente o problema identificado, mas a sua correção e a volta à normalidade do sistema; além disso, ele também atua como uma aprendizagem para o time - que deve, no mínimo, tomar ações para evitar a repetição do problema e conhecer bem a sua causa raiz.
Portanto, a forma como os times lidam com incidentes, molda como os times trabalham e como o ambiente de trabalho é visto por todos. Usar conceitos como Blameless postmortem substituindo o velho - e nenhum pouco construtivo - “apontamento de dedos” (ou de culpados), é uma das formas de ter um ambiente mais harmonioso e colaborativo. Caso você queira conhecer mais sobre esse assunto, indico esse post no blog da Google: Postmortem Culture: Learning from Failure.
