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.
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.
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
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?
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?
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
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.”
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
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.
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
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?
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
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/