Blameless: A culpa não é sua

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
   

   View Slide

2. View Slide

3. View Slide

4. View Slide

5. Quem já errou no trabalho?
   

   View Slide

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

   View Slide

7. Foi demitido por errar no
   trabalho?
   

   View Slide

8. View Slide

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

   View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

23. View Slide

24. View Slide

25. 5 Whys (Por ques)?
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

32. View Slide

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?
    

    View Slide

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.
    

    View Slide

35. View Slide

36. Wheel of Misfortune GameDay
    Chaos Engineering
    

    View Slide

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
    

    View Slide

38. Gameday
    Um exercício para aumentar a resiliência através injeção de falhas
    em larga escala nos sistemas críticos
    

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

    View Slide

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

    View Slide