Blameless: A culpa não é sua? (Blameless Post-Mortems) - Fernando Ike

Ainda é muito praticado a cultura de responsabilizar as (outras) pessoas nas organizações por falhas, erros em incidentes e problemas. Uma das maneiras de mudar é implementar a cultura Blameless (Postmortem), ela tem o objetivo de não apontar para pessoas mas sim identificar e corrigir nos processos a causa da ocorrência. Blameless é muito importante para o aprendizado e crescimento das equipe nas organizações, ela é parte fundamental para que o Second e Third Way (The Three Way) seja bem implementado. Blameless também é aplicado em outras indústrias como aviação e engenharia.

Transcript

1. Blameless: A culpa não é sua? (Blameless Post-Mortems) Fernando Ike
5. Quem já errou no trabalho?
6. Não avisou que aquela ação iria gerar um incidente?
7. Foi demitido por errar no trabalho?
9. O Ciclo da vergonha/culpa/ em 7 passos John Allspaw
10. 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 educados na espreita 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
11. 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
12. - 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 as pessoas para serem mais cuidadosas fará com que o problema desapareça Primeira história - A visão antiga do erro humano
13. - 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
14. "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
15. - É 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
16. 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
17. Blameless Blameless é não culpar as pessoas pelas falhas, mas sim identificar no processo as falhas e corrigi-las. Sem deixar de lados as responsabilidades inerentes da função. Fernando Ike
18. Sua organização deve continuamente afirmar que os indivíduos nunca irão ser a 'causa raiz' das interrupções The human side of Postmortems - Dave Zwieback
19. Revisão de melhoria de qualidade Retrospectivas de projeto Laudo pós-incidente Análise de revisão de projeto Relatório pós-incidente
20. Blameless Postmortem Process- John Allspaw 1. Quais ações eles tomaram e em que momento 2. Quais os efeitos que eles observaram 3. As expectativas que eles tinham 4. As suposições que eles fizeram 5. A compreensão deles da linha do tempo dos eventos que ocorrerão 6. ... E que eles possam dar o relato detalhado sem medo de punição ou retaliação
21. 3 R's Regret - Arrependimento Um reconhecimento do impacto da interrupção e um pedido de desculpa. The human side of Postmortems - Dave Zwieback Reason - Razão Uma linha do tempo da interrupção, do incidente inicialmente detectado até a resolução, incluindo o assim chamado "causa raiz" Remedy - Solução (contorno) Uma lista dos itens solucionados para garantir que esta interrupção não irá se repetir
22. ❏ Documentar sua linha do tempo ou os dados de log ❏ Documente as conversas ❏ Deixe espaços para notas ❏ Média de tempo para resolução / Outros cálculos de tempo ❏ Nível de severidade ❏ Arquive-os para recuperação histórica ❏ Remediação - torne-o acionável Postmortem Checklist - Victor Ops
25. 5 Whys (Por ques)?
26. 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
27. 5 Porques - Gitlab fora do ar (2017) 1. Por que o Gitlab.com ficou fora do ar? O diretório do banco de dados primário foi removido acidentalmente, ao invés de remover o diretório do banco de dados secundário.
28. 5 Porques - Gitlab fora do ar (2017) 2. Por que o diretório do banco de dados foi removido? A replicação do banco de dados parou, foi necessário refazer o banco secundário. Para isso, é necessários que o dados do diretório do PostgreSQL esteja vazio. A restauração dele é um trabalho manual, porque isso não foi automatizado, nem foi documento apropriadamente.
29. 5 Porques - Gitlab fora do ar (2017) 3. Por que a replicação parou? Uma sobrecarga fez o processo de replicação parar. Isso aconteceu porque o banco de dados primário removeu os segmentos WAL antes do banco de dados secundário pudesse replicá-los.
30. 5 Porques - Gitlab fora do ar (2017) 4. Por que a carga do banco de dados cresceu? Ela foi causada por dois eventos que aconteceram ao mesmo tempo: aumento no spam em conjunto ao processo de remoção executado por funcionário da Gitlab e os dados associados.
31. 5 Porques - Gitlab fora do ar (2017) 5. Por que um funcionário da Gitlab estava designado para remover? O funcionário recebeu uma notificação de abuso por um troll. O sistema atual para responder notificação de abuso torna muito fácil ignorar os detalhes da notificação. Como resultado, o funcionário designado removeu acidentalmente.
33. Acidentalmente destrui 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?
34. 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.
36. Wheel of Misfortune GameDay Chaos Engineering
37. Enquanto ninguém quer fazer exercícios de preparação operacional, todo mundo está preparado para o Wheel of Misfortune. Neste contexto, é nada mais um mecanismo de seleção estatisticamente ajustado para escolher um desastre, seguido de role playing, onde uma pessoa faz o papel do dungeon master. Google SRE book Brent Traynor
38. Gameday Um exercício para aumentar a resiliência através injeção de falhas em larga escala nos sistemas críticos
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. First Day and destroy database: https://redd.it/6ez8ag Google Postmorteam example report: https://landing.google.com/sre/book/chapters/postmortem.html Morgue: https://github.com/etsy/morgue Gitlab postmortem live document: https://goo.gl/Ikis68 Gitlab postmortem report: https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/ HootSuite Timeline in the Whiteboard: http://code.hootsuite.com/blameless-post-mortems/ Postmortem collection: https://github.com/danluu/post-mortems 5 Whys: https://www.adb.org/sites/default/files/publication/27641/five-whys-technique.pdf Resilience Engineering: Learning to Embrace Failure: http://queue.acm.org/detail.cfm?id=2371297 Gameday: https://goo.gl/JCvhwY The Field Guide to Understanding Human Error: https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648265 Blameless PostMortems and a Just Culture: https://codeascraft.com/2012/05/22/blameless-postmortems/ VictorOps Guide to Blameless Post-mortems: https://pt.slideshare.net/VictorOps/victor-ops-guide-to-blameless-post-mortems It's Not Your Fault - Blameless Post-mortems: https://pt.slideshare.net/jhand2/its-not-your-fault-blameless-post-mortems Awesome Chaos Engineering: https://github.com/dastergon/awesome-chaos-engineering Awesome Post-Mortem: https://github.com/danluu/post-mortems Principles of Chaos: http://principlesofchaos.org/ System Failure, Human Error: Who’s to Blame? https://vimeo.com/102167635 Nasa - FAA - Boeing 720 Crash Test https://en.wikipedia.org/wiki/Controlled_Impact_Demonstration Referências
41. Fernando ike • https://www.fernandoike.com.br • @fernandoike • https://www.linkedin.com/in/fernandoike • https://www.naestradadevops.com