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

Blameless Postmortem: Como organizações exponenciais aprendem com as falhas

Fernando ike
December 17, 2020

Blameless Postmortem: Como organizações exponenciais aprendem com as falhas

Apresentação sobre Blameless Postmortem para o DevOpsDays Aracaju em 2020.

Fernando ike

December 17, 2020
Tweet

More Decks by Fernando ike

Other Decks in Technology

Transcript

  1. Blameless Postmortem
    Fernando Ike
    Como organizações exponenciais
    aprendem com as falhas

    View Slide

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

    View Slide

  3. Quem já errou no trabalho?

    View Slide

  4. Não avisou que aquela ação iria
    gerar um incidente?

    View Slide

  5. Foi demitido por errar no
    trabalho?

    View Slide

  6. O Ciclo da vergonha/culpa/ em
    7 passos
    John Allspaw

    View Slide

  7. 1. Engenheiro tomam atitude e contribuem para uma falha ou acidente
    2. Engenheiro é punido, envergonhado, culpado ou reprimido
    3. Reduz a confiança entre engenheiros e a gerência fica procurando alguém
    como bode expiatório
    4. Engenheiros ficam em silêncio sobre detalhes de
    ações/situações/observações, resultando na engenharia de "Cover-Your-Ass
    (pelo medo de punição)
    5. Gerentes tornam-se menos conscientes e informados sobre o desempenho do
    trabalho do dia a dia, engenheiros se tornam menos preparados ou condição
    latente para falha devido ao silêncio mencionado no passo #4
    6. Erros tornam-se mais prováveis, condição latente para eles não serem
    identificadas devido ao passo #5
    7. Repete a partir do passo #1

    View Slide

  8. Reprimir as maçãs podres pode parecer uma solução
    rápida e gratificante, mas é como fazer xixi nas calças.
    Você sente aliviado, talvez mesmo até agradável e
    aquecido por algum tempo, mas depois fica frio e
    desconfortável. E você parece um idiota.
    The Field Guide to Understanding Human Error - Sidney Dekker

    View Slide

  9. ● Erro humano é visto como a causa da falha
    ● Dizer o que as pessoas deveriam ter feito é um forma satisfatória para
    descrever um fracasso
    ● Dizer às pessoas para serem mais cuidadosas fará com que o problema
    desapareça
    Primeira história - A visão antiga do erro humano

    View Slide

  10. ● Erro humano é visto como o efeito da vulnerabilidade sistêmica profunda dentro de uma
    organização
    ● Dizer o que as pessoas deveriam ter feito não explica porque fazia sentido fazer o que
    faziam
    ● Somente procurando constantemente suas vulnerabilidades as organizações podem
    melhorar a segurança
    Segunda história - A nova visão do erro humano

    View Slide

  11. "Debaixo de cada história simples e óbvia
    sobre "erro humano", há uma história mais
    profunda e complexa sobre a organização"
    The Field Guide to Understanding Human Error - Sidney Dekker

    View Slide

  12. ● É importante ter uma cultura de confiança, aprendizado e responsabilidade quando
    alguma coisa dá errado na sua organização
    ● Just Culture significa que irá fazer o esforço para balancear a segurança e a
    responsabilidade
    Dekker em Just Culture

    View Slide

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

  14. What Psychological Safety Means in a Cloud Native Organisation
    The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth - Amy Edmondson’s

    View Slide

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

    View Slide

  16. Thinking: Fast and Slow
    1 - Intuitivo, emocional
    2 - Analítico, racional

    View Slide

  17. Uma Cultura Blameless acredita que os
    sistemas não são inerentemente seguros e
    humanos fazem o melhor para eles
    continuem rodando
    John Willis
    Blameless Culture

    View Slide

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

  19. Quem aplica
    Postmortem?

    View Slide

  20. View Slide

  21. Campos “mais” comuns
    Título
    Data do relatório
    Impacto (incluso o de valor)
    Descrição
    Causas-Raizes
    Resolução
    Pessoas envolvidas
    Lições Aprendidas
    Ações a serem tomadas
    Timeline

    View Slide

  22. Incidentes, causas e cadeia de eventos
    Um incidente (quase) nunca há uma única
    causa-raíz. Os eventos isolados,
    geralmente, não causariam um incidente
    mas a relação de causa e efeito de cada
    evento numa sequência que explica muitas
    vezes como o incidente ocorreu.

    View Slide

  23. Até onde ir na investigação de um incidente?
    A investigação dos eventos deve analisar
    não só gráficos, logs e ações tomadas
    como também processos e design dos
    sistemas/produtos.
    Deve ir a fundo para identificar débito
    técnico, não conhecimento de práticas e
    técnicas pela(s) equipe(s) envolvidas.

    View Slide

  24. Quem deve saber?
    Todos!
    Postmortems são histórias de
    cada incidente com as lições
    aprendidas que vem ser
    compartilhadas ou estar
    disponíveis para que outros
    aprendam também sem que o
    mesmo incidente aconteça
    novamente

    View Slide

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

    View Slide

  26. 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
    ● QAs
    ● PO/PM

    View Slide

  27. View Slide

  28. 5 Whys (Por quês)

    View Slide

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

  30. Elementos chaves para usar 5 Whys
    1. Descrições exatas e completa dos problemas
    2. Honestidade completa em responder as perguntas
    3. A determinação de ir a fundo nos problemas e resolvê-los

    View Slide

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

  32. Trocar o Quem e Por que...
    ...por O que e Como

    View Slide

  33. View Slide

  34. Acidentalmente destruí o
    banco de dados de
    produção no meu
    primeiro dia de trabalho
    e me mandaram embora.
    Além disso, o CTO me
    disse que eles irão me
    processar.
    Como estou ferrado?

    View Slide

  35. Oi, o cara aqui foi quem
    acidentalmente destruiu
    o banco de dados da
    GitLab.com's no início
    deste ano.
    Não é culpa sua.

    View Slide

  36. View Slide

  37. View Slide

  38. Wheel of Misfortune GameDay
    Chaos Engineering

    View Slide

  39. Chaos Engineering
    Engenharia do Caos é a disciplina da experimentação de sistemas
    distribuídos para aumentar a confiança na capacidade dos sistemas para
    suportar condições turbulentas na produção

    View Slide

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

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

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

  43. View Slide

  44. Patológica Burocrática Geradora
    Pelo Poder Por regras Por desempenho
    Baixa cooperação Cooperação modesta Altamente cooperativa
    Mata o mensageiro Mensageiros são negligenciados Mensageiros são treinados
    Evita responsabilidades Diminui as responsabilidades Riscos são compartilhados
    Desencoraja construir pontes Construção de pontes são toleradas Construção de pontes são encorajadas
    Procura-se um bode expiatório para culpar
    em caso de falhas
    Procura-se fazer "justiça" em caso de falha
    Procura-se investigar procurando o problema no
    "sistema"
    Impede novidades Novidades são problemas Novidades são implementadas
    Uma Tipologia da Cultura Organizacional - Ron Westrum

    View Slide

  45. Referências
    First Day and destroy database
    Google Postmortem example report
    Gitlab postmortem live document
    Gitlab postmortem report
    HootSuite Timeline in the Whiteboard
    Postmortem collection
    5 Whys
    Resilience Engineering: Learning to Embrace Failure
    Gameday
    The Field Guide to Understanding Human Error
    Blameless PostMortems and a Just Culture
    VictorOps Guide to Blameless Post-mortems
    It's Not Your Fault - Blameless Post-mortems

    View Slide