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

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

1. Blameless Postmortem Fernando Ike Como organizações exponenciais aprendem com as falhas
2. Fernando Ike // linkedin.com/in/fernandoike // twitter.com/fernandoike // pontocafe.fernandoike.com
3. Quem já errou no trabalho?
4. Não avisou que aquela ação iria gerar um incidente?
5. Foi demitido por errar no trabalho?
6. O Ciclo da vergonha/culpa/ em 7 passos John Allspaw
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
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
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
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
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
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
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/
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
15. Abrace a complexidade... Pessoa + Software + Processos
16. Thinking: Fast and Slow 1 - Intuitivo, emocional 2 - Analítico, racional
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
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.
19. Quem aplica Postmortem?
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
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.
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.
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
25. Papéis envolvidos num incidente Responsável pelo Incidente Responsável pela Comunicação Responsável pelo Planejamento Responsável pelo Postmortem
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
28. 5 Whys (Por quês)
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
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
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
32. Trocar o Quem e Por que... ...por O que e Como
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?
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.
38. Wheel of Misfortune GameDay Chaos Engineering
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
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”
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”
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.”
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
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