$30 off During Our Annual Pro Sale. View Details »

Os vícios ao escrever um Postmortem

Fernando ike
September 15, 2020

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

Fernando ike

September 15, 2020
Tweet

More Decks by Fernando ike

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

  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.

    View Slide

  5. View Slide

  6. 5 Whys (Por quês)

    View Slide

  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

    View Slide

  8. Um incidente num ecommerce

    View Slide

  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?

    View Slide

  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?

    View Slide

  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

    View Slide

  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”

    View Slide

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

    View Slide

  14. O viés da causa-raiz

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  18. Abrace a complexidade...
    Pessoa + Software + Processos

    View Slide

  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?

    View Slide

  20. Postmortem escrito só por
    Devs e/ou Ops

    View Slide

  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

    View Slide

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

    View Slide

  23. O viés do Postmortem automatizados???

    View Slide

  24. Um incidente nunca é igual a outro incidente

    View Slide

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

    View Slide

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

    View Slide

  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/

    View Slide

  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”

    View Slide

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

    View Slide