Os vícios ao escrever um Postmortem

Os vícios ao escrever um Postmortem

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.

https://devopsdays.org/events/2020-goiania

168c322e7157a4cfffdeb88ab2309e02?s=128

Fernando ike

September 15, 2020
Tweet

Transcript

  1. Os vícios ao escrever um Postmortem @fernandoike

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

  3. TEMOS VAGAS!! #VempraZup Tire foto do QR Code para ver

    as oportunidades. zup.com.br/vagas
  4. 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.
  5. None
  6. 5 Whys (Por quês)

  7. 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
  8. Um incidente num ecommerce

  9. 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?
  10. 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?
  11. 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
  12. 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”
  13. 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.”
  14. O viés da causa-raiz

  15. 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
  16. 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.
  17. 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
  18. Abrace a complexidade... Pessoa + Software + Processos

  19. 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?
  20. Postmortem escrito só por Devs e/ou Ops

  21. 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
  22. Papéis envolvidos num incidente Responsável pelo Incidente Responsável pela Comunicação

    Responsável pelo Planejamento Responsável pelo Postmortem
  23. O viés do Postmortem automatizados???

  24. Um incidente nunca é igual a outro incidente

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

    tem
  26. Escrever um Postmortem é uma atividade Cognitiva que precisa (ainda)

    de humanos para analisar e interpretar as múltiplas perspectivas de um incidente
  27. 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/
  28. 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”
  29. Fernando Ike // linkedin.com/in/fernandoike // twitter.com/fernandoike // pontocafe.fernandoike.com