Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Blameless Postmortem: Como organizações exponen...

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. 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
  2. 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
  3. • 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
  4. • 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
  5. "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
  6. • É 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
  7. 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/
  8. 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
  9. 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
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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
  15. Papéis envolvidos num incidente Responsável pelo Incidente Responsável pela Comunicação

    Responsável pelo Planejamento Responsável pelo Postmortem
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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?
  21. 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.
  22. 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
  23. 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”
  24. 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”
  25. 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.”
  26. 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
  27. 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