Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Fernando Ike // linkedin.com/in/fernandoike // twitter.com/fernandoike // pontocafe.fernandoike.com

Slide 3

Slide 3 text

Quem já errou no trabalho?

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Foi demitido por errar no trabalho?

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

● 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

Slide 10

Slide 10 text

● 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

Slide 11

Slide 11 text

"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

Slide 12

Slide 12 text

● É 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

Slide 13

Slide 13 text

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/

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Abrace a complexidade... Pessoa + Software + Processos

Slide 16

Slide 16 text

Thinking: Fast and Slow 1 - Intuitivo, emocional 2 - Analítico, racional

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

Quem aplica Postmortem?

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Papéis envolvidos num incidente Responsável pelo Incidente Responsável pela Comunicação Responsável pelo Planejamento Responsável pelo Postmortem

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

5 Whys (Por quês)

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Trocar o Quem e Por que... ...por O que e Como

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

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?

Slide 35

Slide 35 text

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.

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

Wheel of Misfortune GameDay Chaos Engineering

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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”

Slide 41

Slide 41 text

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”

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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