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

Blameless: A culpa não é sua

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

Fernando ike

November 08, 2017
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 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
  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 as 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. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. ❏ 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
  14. 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
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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?
  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. 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
  23. Gameday Um exercício para aumentar a resiliência através injeção de

    falhas em larga escala nos sistemas críticos
  24. 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
  25. 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