Apresentação para o DevOpsDays Goiânia sobre os quais os tipos comuns de erros ao escrever um Postmortem de um incidente em TI, quais os viéses mais comuns e como abordar.
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.
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
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 - 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
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?
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
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”
fernandoike
k1low
oracle4engineer
akki_megane
tokyo_metropolitan_gov_smart_tokyo_strat
wadayusuke
blue_goheimochi
yamamotohiroya
hirosatogamo
ad5jp
sumiren
oogfranz
gothedistance
panda_program
tmm1
lynnandtonic
jponch
swwweet
productmarketing
reverentgeek
morganepeng
sachag
bluesmoon
philhawksworth
davidbonilla