Os vícios ao escrever um Postmortem @fernandoike

Fernando Ike // linkedin.com/in/fernandoike // twitter.com/fernandoike // pontocafe.fernandoike.com

TEMOS VAGAS!! #VempraZup Tire foto do QR Code para ver as oportunidades. zup.com.br/vagas

Por que Postmortem? É uma oportunidade de aprendizagem (processo) estruturada através de análise e retrospectiva para identificar as causa(s)-raiz de uma falha ou incidente. Como um processo de feedback loop, deve-se encaminhar mudanças de código, designer ou processos organizacionais para que não ocorra novamente uma falha ou incidente.

No content

5 Whys (Por quês)

O que é 5 Whys (Por quês)? 5 Whys é uma técnica interrogativa iterativa criada por Sakichi Toyoda para explorar a relação de causa-efeito de um determinado problema no processo fabril na Toyota

Um incidente num ecommerce

Os 5 Whys (Por quês) 1- Por que o site caiu? 2- Por que o banco de dados está aceitando mais conexões? 3- Por que o banco de dados atingiu o limite de conexões? 4- Por que as transações no banco de dados não estão sendo finalizadas? 5- Por que o banco de dados está sem um índice para essas consultas?

Os 5 Whys (Por quês) 1- Por que o site está indisponível? 2- Por que o banco de dados não aceita mais conexões? 3- Por que havia conexões da aplicação presa no banco de dados? 4- Por que as transações estavam muito lentas? 5- Por que foi esquecido de adicionar o índice do campo novo? 6- Por que não foi criado o teste para identificar a falta do índice?

Críticas ao 5 Whys “A tendência da investigação parar nos sintomas e não continuar investigando mais profundamente até encontrar as causas-raiz” “A falta de habilidade de quem está investigando além dos atuais conhecimentos” “ Dificuldade em apoiar e facilitar quem está investigando a fazer as pergunta certas” “Dificuldade de reproduzir os resultados: equipes diferentes usando a técnica do 5 Whys chegam em causa diferentes ao mesmo problema” https://www.adb.org/sites/default/files/publication/27641/five-whys-technique.pdf

Conway Law é “…organizações que projetam sistemas (no sentido amplo usados aqui) restringem o desenvolvimento dos projetos como cópias da estrutura de comunicação dessas organizações”

Conway Law “Uma organização de pesquisa contrata oitos pessoas nas quais irão produzir um compilador COBOL e outro em ALGOL. Depois de algumas estimativas iniciais da dificuldade e de tempo, cinco pessoas são designadas para trabalhar no compilador COBOL e três para o compilador ALGOL. O resultado será que o compilador COBOL terá 5 etapas e o compilador ALGOL terá 3.”

O viés da causa-raiz

O viés da causa-raiz - primeira visão 1/2 ● Considerar a possibilidade de ter sido esquecido a criação de índice e o respectivo teste. ● Considerar que as pessoas da equipe podem não saber este tipo de teste ou mesmo não sabem fazer nenhum tipo de teste. ● Definido uma nova função de compra ● Criado a instrução para adicionar a coluna sem índice

O viés da causa-raiz - primeira visão 2/2 ● Os testes unitários não tinham cobertura para este problema ● Revisores do Pull Request/Merge Request não viram a falta de índice ● A coluna sem índice não degradou o desempenho nos testes de carga ● A função foi implementada em produção sem degradar desempenho ● Após campanha de marketing da nova função, as compras usando a nova função aumentaram para 30% do total e o site caiu.

O viés da causa-raiz - segunda visão ● Definido uma nova função de compra ● Criado a instrução para adicionar a coluna sem índice ● Os testes unitários não tinham cobertura para este problema ● Revisores do Pull Request/Merge Request não viram a falta de índice ● A coluna sem índice não degradou o desempenho nos testes de carga ● A função foi implementada em produção sem degradar desempenho ● Após campanha de marketing da nova função, as compras usando a nova função aumentaram para 30% do total e o site caiu

Abrace a complexidade... Pessoa + Software + Processos

O viés da causa-raiz - além do operacional ● A equipe responsável pela função tinha as habilidades para evitar que o incidente acontecesse? ● Se eles tivessem a documentação ou referências do que era a funcionalidade evitaria? Se eles soubessem técnicas como Test-Driven Development evitaria o incidente? ● A equipe estava trabalhando no limite da capacidade?

Postmortem escrito só por Devs e/ou Ops

Quem deve estar envolvido A escrita de um Postmortem envolve não só os papéis que estiveram nas atividades de resolução de um incidente, também todos os papéis em torno das aplicações envolvidas num incidente. Exemplo: Desenvolvedores Sysadmin/SREs Segurança PO/PM

Papéis envolvidos num incidente Responsável pelo Incidente Responsável pela Comunicação Responsável pelo Planejamento Responsável pelo Postmortem

O viés do Postmortem automatizados???

Um incidente nunca é igual a outro incidente

Automação presume-se que há um controle do “ambiente” mas não tem

Escrever um Postmortem é uma atividade Cognitiva que precisa (ainda) de humanos para analisar e interpretar as múltiplas perspectivas de um incidente

Responsabilidade vs Segurança (Psicológica) “Ter uma Cultura Justa (Just Culture) significa que você está se esforçando para ter um equilíbrio entre responsabilidade e segurança. Isso significa que investigar os erros focado nos aspectos situacionais dos mecanismos de uma falha e o processo de tomada de decisão dos indivíduos próximos à falha, uma organização pode ficar mais segura do que normalmente seria se tivesse simplesmente punindo os atores envolvidos, como também uma remediação” https://codeascraft.com/2012/05/22/blameless-postmortems/

Abrace as falhas “Não consumir seu erro budget é porque você não está fazendo coisas novas” Adaptação da frase de Daniel Colchete na apresentação “introdução à SRE no Google”

Fernando Ike // linkedin.com/in/fernandoike // twitter.com/fernandoike // pontocafe.fernandoike.com