Postmortem: Aprendendo com os erros
Noite de Domingo, 15 de Novembro de 2020, dia do primeiro turno das eleições municipais, os noticiários dão os resultados de várias capitais e destacaram um atraso na apuração e contabilização dos votos para prefeito na capital de São Paulo. Segundo o TSE esse atraso foi causado pelo “…desligamento de um dos oito nós de processamento do servidor principal….” do supercomputadores do TSE. E agora?
Não é objetivo deste post discutir por que uma infraestrutura que custou R$ 26 milhões falhou na hora “H”. Uma plataforma que lida com um evento que possui data e hora de início e fim, com um número de sessões eleitorais conhecido, com um número de urnas eletrônicas conhecido, com o número de candidatos conhecido, com o número de eleitores conhecido, o dado é de “bem” para “muito bem” estruturado, e eu tenho minhas dúvidas se podemos chamar de Big Data pois não contém as três propriedades que o qualificaria como Big Data: Volume, Variedade e Velocidade. Situação mais previsível que essa é impossível, só mesmo a lei da gravidade. De toda forma, é do interesse de quem trabalha com aplicações e infraestruturas entender quais foram os eventos que levaram à falha e o que podemos aprender com os eles?
O processo de levantar as informações dos eventos ocorridos, criar um registro dos fatos que antecederam a(s) falha(s), registrar os impactos causados, registrar as ações tomadas para restabelecer o(s) serviço(s), identificar a causa raiz do problema e ações que devem ser tomadas para que a(s) mesma(s) falha(s) não aconteça novamente é conhecido como Postmortem, mas o que é um Postmortem exatamente!?!?!
Origem
A palavra POSTMORTEM é composta pelo prefixo POST, que pode ser entendido como após ou depois e MORTEM do latin significa morte. A expressão Postmortem significa tempo após a morte, estudar após a morte, dissecar, fazer autópsia.
O termo Postmortem é utilizado por muitas áreas, na medicina, segurança do trabalho, na aviação, na indústria de transformação e na TI inclusive, e é justamente nessa área que vamos manter sobre o uso desse termo.
Objetivo do Postmortem
Engana-se quem acha que o objetivo de um processo de Postmortem é encontrar um ou mais culpado(s) para o problema, o principal objetivo é garantir a reconstrução dos fatos de maneira a organizá-los em uma linha do tempo até chegar ao momento do incidente e encontrar a causa raiz do problema. O incidente é último evento de uma sequência linear e corresponde a tentativa de sistematização de um processo de algo que deu errado que se contrapõe à noção de fatalidade (Almeida,2000).
O Postmortem é preciso ser visto como uma oportunidade para eliminar um ponto fraco e fazer com que sua aplicação ou infraestrutura seja um pouco mais resiliente em relação a falhas.
Fazendo um paralelo com o evento da apuração, o TSE elaborou um documento relatando os testes do supercomputador, a falha em um nó de processamento e a falta de calibragem da inteligência artificial (TSE,2020). Eu considero esse documento uma importante resposta à sociedade e algo mais próximo possível que pessoas externas possam chamar de Postmortem.
Como fazer um Postmortem
A equipe de Site Reliability Engineering (SRE) do Google descreve seus critérios para criar procedimentos de Postmortem no livro Site Reliability Engineering. O time deve utilizar alguma ferramenta de cooperação entre equipe possua as seguintes funcionalidades:
- Colaboração em tempo real por chat e por áudio para a comunicação e troca de dados e ideias entre times.
- Sistema de armazenamento de artefatos e evidências.
- Sistema de ticket e de notificações por e-mail.
Ainda segundo os autores, no processo de elaboração do documento, as equipes se reúnem para compartilhar os artefatos coletados e montarem a linha do tempo dos fatos, para isso é importante que tenha as seguintes informações:
- Os principais dados do incidente foram coletados? Logs, gráficos, etc..
- As avaliações de impacto estão completas? Usuários afetados, dados corrompidos, etc..
- A causa raiz era suficientemente profunda?
- O plano de ação é apropriado e as correções de bugs resultantes têm a prioridade apropriada?
- O resultado foi compartilhado com as partes interessadas relevantes?
Se você achou interessante esse formato, o time de SRE disponibiliza um template de um documento de postmortem, existem outros modelos mais genéricos como esses disponibilizados no Github.
Recomendo assistir um vídeo de divulgação sobre esse assunto do próprio Google, explicado de uma forma bem descontraída e informativa.
Conclusão
Em muitos lugares utilizam o modelo caça às bruxas para achar um culpado e expor o erro aos seus pares ou aos superiores pela falha. Atitudes assim inibem as pessoas de colaborarem com a mudança e com as melhorias de uma aplicação. O raciocínio é simples “se eu não não mexer em nada, não vai quebrar” e se não quebra não se escuta piadas nem sofro constrangimentos.
Falhas acontecem e sempre vão acontecer, a diferença está em como sua equipe reage diante delas. A cultura de realizar um processo de Postmortem buscando somente a causa raiz é sem dúvida uma maneira de melhorar seu produto/plataforma evitando que erros sejam repetidos. Realizar um processo de Postmortem abre frentes de melhorias em áreas de software, banco de dados, infraestrutura, automação e em de partes do seu sistema que por algum motivo ficaram esquecidas.
E sobre o atraso na apuração da eleição!!?? bemmmm … eu ouvi aee nos botecos virtuais que bastava um laptop tunadão para fazer esse somatório de votos … vamos combinar né, que na prática é fazer uma soma, uma somaaaaa 1+1=2, 2+2=4 … assim por diante e apresentar o resultado …. mas, mesmo com todos esses contratempos antes das 23h o resultado já tinha sido divulgado, diferentemente de outros lugares que recentemente estavam recontando votos dez dias após as eleições. Vamos aguardar o desempenho do supercomputador no segundo turno :) :)
Abraços!
DICA RÁPIDA DE LIVRO
Estou lendo atualmente o livro Engenharia de Confiabilidade do Google: Como o Google Administra Seus Sistemas de Produção
Referências
-
Dica de livro Engenharia de Confiabilidade do Google: Como o Google Administra Seus Sistemas de Produção
-
ALMEIDA, Ildeberto Muniz de. Construindo a culpa e evitando a prevenção: caminhos da investigação de acidentes do trabalho em empresas e município de porte médio, Botucatu, São Paulo, 1997. 2000. Tese (Doutorado em Saúde Ambiental) - Faculdade de Saúde Pública, University of São Paulo, São Paulo, 2001. doi:10.11606/T.6.2001.tde-01112001-145305. Acesso em: 2020-11-25., https://www.teses.usp.br/teses/disponiveis/6/6134/tde-01112001-145305/publico/tde.pdf
-
TSE: Nota técnica sobre o atraso da totalização dos votos em 15/11, https://www.tse.jus.br/imprensa/noticias-tse/arquivos/nota-tecnica-eleicoes-2020-1o-turno/rybena_pdf?file=https://www.tse.jus.br/imprensa/noticias-tse/arquivos/nota-tecnica-eleicoes-2020-1o-turno/at_download/file
-
Betsy B, Chris J, Jennifer P, Niall R M, Site Reliability Engineering, https://sre.google/sre-book/table-of-contents/
-
SRE Postmortem templates, https://sre.google/sre-book/example-postmortem/
-
Postmortem templates genéricos, https://github.com/dastergon/postmortem-templates
-
SRE Postmortem vídeo, https://www.youtube.com/watch?v=UBe7U2b3tsA
MENTORIA
Curtiu o blog? Quer trocar uma ideia comigo sobre algum post?
Marca Aqui! É um papo gratuito
oferecido para quem é leitor do blog, podemos falar de temas como: DevOps, SRE e carreira em TI.
Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!
|