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.

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 às 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 qualidadeRetrospectivas 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
Referências

41. Fernando ike
● https://www.fernandoike.com.br
● @fernandoike
● https://www.linkedin.com/in/fernandoike
● https://www.naestradadevops.com