SlideShare uma empresa Scribd logo
1 de 41
Baixar para ler offline
Blameless: A culpa não é sua?
(Blameless Post-Mortems)
Fernando Ike
Quem já errou no trabalho?
Não avisou que aquela ação iria
gerar um incidente?
Foi demitido por errar no
trabalho?
O Ciclo da vergonha/culpa/ em
7 passos
John Allspaw
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
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
- 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
- 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
"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
- É 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
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
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
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
Revisão de melhoria de qualidadeRetrospectivas de projeto
Laudo pós-incidente Análise de revisão de projeto
Relatório pós-incidente
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
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
❏ 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
5 Whys (Por ques)?
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
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.
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.
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.
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.
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.
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?
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.
Wheel of Misfortune GameDay
Chaos Engineering
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
Gameday
Um exercício para aumentar a resiliência através injeção de falhas
em larga escala nos sistemas críticos
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
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
Fernando ike
● https://www.fernandoike.com.br
● @fernandoike
● https://www.linkedin.com/in/fernandoike
● https://www.naestradadevops.com

Mais conteúdo relacionado

Semelhante a Blameless: A culpa não é sua

O ciclo da vida
O ciclo da vidaO ciclo da vida
O ciclo da vidaLuiz Borba
 
5 Porquê’s, 7 Perdas e 2 SS
5 Porquê’s, 7 Perdas e 2 SS5 Porquê’s, 7 Perdas e 2 SS
5 Porquê’s, 7 Perdas e 2 SSHubner Braz
 
Analista de negócios no mundo agile
Analista de negócios no mundo agileAnalista de negócios no mundo agile
Analista de negócios no mundo agileJefferson Moreira
 
Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012Leandro Silva
 
Principais motivos pelo qual você precisa ter uma ferramenta de backup
Principais motivos pelo qual você precisa ter uma ferramenta de backupPrincipais motivos pelo qual você precisa ter uma ferramenta de backup
Principais motivos pelo qual você precisa ter uma ferramenta de backupBruna Grellt
 
As OPORTUNIDADES da transformação digital no MUNDO do SUPORTE TÉCNICO
As OPORTUNIDADES da transformação digital no MUNDO do SUPORTE TÉCNICOAs OPORTUNIDADES da transformação digital no MUNDO do SUPORTE TÉCNICO
As OPORTUNIDADES da transformação digital no MUNDO do SUPORTE TÉCNICORoberto Cohen
 
Cap 25 - Erros, Alertas e Confirmação
Cap 25 - Erros, Alertas e ConfirmaçãoCap 25 - Erros, Alertas e Confirmação
Cap 25 - Erros, Alertas e ConfirmaçãoRobert Ranger
 
Tecnicas de Detenção de Avaria
Tecnicas de Detenção de AvariaTecnicas de Detenção de Avaria
Tecnicas de Detenção de AvariaDiolene Sampaio
 
Apresentação.ppt
Apresentação.pptApresentação.ppt
Apresentação.pptssuser499e03
 
Curso de CRM para empresa da indústria de óleo e gás.
Curso de CRM para empresa da indústria de óleo e gás.Curso de CRM para empresa da indústria de óleo e gás.
Curso de CRM para empresa da indústria de óleo e gás.Monica Lavoyer Escudeiro
 
Formação - Bloco 2 - Atendimento Nota 10
Formação - Bloco 2 - Atendimento Nota 10Formação - Bloco 2 - Atendimento Nota 10
Formação - Bloco 2 - Atendimento Nota 10Roberto Cohen
 
O Mítico Homem-Mês
O Mítico Homem-MêsO Mítico Homem-Mês
O Mítico Homem-MêsJuliane Silva
 
Propostas para DDS
Propostas para DDSPropostas para DDS
Propostas para DDScarlos ars
 

Semelhante a Blameless: A culpa não é sua (20)

O ciclo da vida
O ciclo da vidaO ciclo da vida
O ciclo da vida
 
MASP.pdf
MASP.pdfMASP.pdf
MASP.pdf
 
5 Porquê’s, 7 Perdas e 2 SS
5 Porquê’s, 7 Perdas e 2 SS5 Porquê’s, 7 Perdas e 2 SS
5 Porquê’s, 7 Perdas e 2 SS
 
Analista de negócios no mundo agile
Analista de negócios no mundo agileAnalista de negócios no mundo agile
Analista de negócios no mundo agile
 
Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012Sistemas para o Mundo Real - TDC 2012
Sistemas para o Mundo Real - TDC 2012
 
Principais motivos pelo qual você precisa ter uma ferramenta de backup
Principais motivos pelo qual você precisa ter uma ferramenta de backupPrincipais motivos pelo qual você precisa ter uma ferramenta de backup
Principais motivos pelo qual você precisa ter uma ferramenta de backup
 
7 passos para um bom kaizen
7 passos para um bom kaizen7 passos para um bom kaizen
7 passos para um bom kaizen
 
Estrategias Ágeis para testes sob pressão
Estrategias Ágeis para testes sob pressãoEstrategias Ágeis para testes sob pressão
Estrategias Ágeis para testes sob pressão
 
As OPORTUNIDADES da transformação digital no MUNDO do SUPORTE TÉCNICO
As OPORTUNIDADES da transformação digital no MUNDO do SUPORTE TÉCNICOAs OPORTUNIDADES da transformação digital no MUNDO do SUPORTE TÉCNICO
As OPORTUNIDADES da transformação digital no MUNDO do SUPORTE TÉCNICO
 
Cap 25 - Erros, Alertas e Confirmação
Cap 25 - Erros, Alertas e ConfirmaçãoCap 25 - Erros, Alertas e Confirmação
Cap 25 - Erros, Alertas e Confirmação
 
Tecnicas de Detenção de Avaria
Tecnicas de Detenção de AvariaTecnicas de Detenção de Avaria
Tecnicas de Detenção de Avaria
 
Cotações
CotaçõesCotações
Cotações
 
383 solucao de_problemas
383 solucao de_problemas383 solucao de_problemas
383 solucao de_problemas
 
Apresentação.ppt
Apresentação.pptApresentação.ppt
Apresentação.ppt
 
Curso de CRM para empresa da indústria de óleo e gás.
Curso de CRM para empresa da indústria de óleo e gás.Curso de CRM para empresa da indústria de óleo e gás.
Curso de CRM para empresa da indústria de óleo e gás.
 
Formação - Bloco 2 - Atendimento Nota 10
Formação - Bloco 2 - Atendimento Nota 10Formação - Bloco 2 - Atendimento Nota 10
Formação - Bloco 2 - Atendimento Nota 10
 
Não São Apenas Sapatos
Não São Apenas SapatosNão São Apenas Sapatos
Não São Apenas Sapatos
 
Introdução ao Teste de Software
Introdução ao Teste de SoftwareIntrodução ao Teste de Software
Introdução ao Teste de Software
 
O Mítico Homem-Mês
O Mítico Homem-MêsO Mítico Homem-Mês
O Mítico Homem-Mês
 
Propostas para DDS
Propostas para DDSPropostas para DDS
Propostas para DDS
 

Mais de Fernando Ike

Arquitetura de Micro Serviços
Arquitetura de Micro ServiçosArquitetura de Micro Serviços
Arquitetura de Micro ServiçosFernando Ike
 
(Quase) 10 anos de DevOps, e agora?
(Quase) 10 anos de DevOps, e agora? (Quase) 10 anos de DevOps, e agora?
(Quase) 10 anos de DevOps, e agora? Fernando Ike
 
Containers and Databases
Containers and DatabasesContainers and Databases
Containers and DatabasesFernando Ike
 
Infraestrutura Imutável - Agile Trends
Infraestrutura Imutável - Agile TrendsInfraestrutura Imutável - Agile Trends
Infraestrutura Imutável - Agile TrendsFernando Ike
 
Infraestrutura imutável - A base das aplicações na nuvem
Infraestrutura imutável - A base das aplicações na nuvemInfraestrutura imutável - A base das aplicações na nuvem
Infraestrutura imutável - A base das aplicações na nuvemFernando Ike
 
DevOps Anti-Patterns - Campus Party
DevOps Anti-Patterns - Campus PartyDevOps Anti-Patterns - Campus Party
DevOps Anti-Patterns - Campus PartyFernando Ike
 
DevOps: A revolução ruidosa da TI
DevOps: A revolução ruidosa da TIDevOps: A revolução ruidosa da TI
DevOps: A revolução ruidosa da TIFernando Ike
 
Docker Swarm Cluster
Docker Swarm ClusterDocker Swarm Cluster
Docker Swarm ClusterFernando Ike
 
DevOps - Por onde começar
DevOps - Por onde começarDevOps - Por onde começar
DevOps - Por onde começarFernando Ike
 
DevOps Anti-Patterns
DevOps Anti-PatternsDevOps Anti-Patterns
DevOps Anti-PatternsFernando Ike
 
A lista do PostgerSQL Brasil caiu?
A lista do PostgerSQL Brasil caiu? A lista do PostgerSQL Brasil caiu?
A lista do PostgerSQL Brasil caiu? Fernando Ike
 
Container revolucao
Container revolucaoContainer revolucao
Container revolucaoFernando Ike
 
Akamai Cloud Security
Akamai Cloud SecurityAkamai Cloud Security
Akamai Cloud SecurityFernando Ike
 
Management 3.0 - a vida pós-agilidade
Management 3.0 - a vida pós-agilidadeManagement 3.0 - a vida pós-agilidade
Management 3.0 - a vida pós-agilidadeFernando Ike
 
Docker na vida real
Docker na vida realDocker na vida real
Docker na vida realFernando Ike
 
Docker e postgresql
Docker e postgresqlDocker e postgresql
Docker e postgresqlFernando Ike
 
Um milhao de usuários simultâneos
Um milhao de usuários simultâneosUm milhao de usuários simultâneos
Um milhao de usuários simultâneosFernando Ike
 
Banco caiu! E a gora?
Banco caiu! E a gora?Banco caiu! E a gora?
Banco caiu! E a gora?Fernando Ike
 
Researching postgresql
Researching postgresqlResearching postgresql
Researching postgresqlFernando Ike
 

Mais de Fernando Ike (20)

Arquitetura de Micro Serviços
Arquitetura de Micro ServiçosArquitetura de Micro Serviços
Arquitetura de Micro Serviços
 
(Quase) 10 anos de DevOps, e agora?
(Quase) 10 anos de DevOps, e agora? (Quase) 10 anos de DevOps, e agora?
(Quase) 10 anos de DevOps, e agora?
 
Containers and Databases
Containers and DatabasesContainers and Databases
Containers and Databases
 
Infraestrutura Imutável - Agile Trends
Infraestrutura Imutável - Agile TrendsInfraestrutura Imutável - Agile Trends
Infraestrutura Imutável - Agile Trends
 
Infraestrutura imutável - A base das aplicações na nuvem
Infraestrutura imutável - A base das aplicações na nuvemInfraestrutura imutável - A base das aplicações na nuvem
Infraestrutura imutável - A base das aplicações na nuvem
 
DevOps Anti-Patterns - Campus Party
DevOps Anti-Patterns - Campus PartyDevOps Anti-Patterns - Campus Party
DevOps Anti-Patterns - Campus Party
 
DevOps: A revolução ruidosa da TI
DevOps: A revolução ruidosa da TIDevOps: A revolução ruidosa da TI
DevOps: A revolução ruidosa da TI
 
Docker Swarm Cluster
Docker Swarm ClusterDocker Swarm Cluster
Docker Swarm Cluster
 
DevOps - Por onde começar
DevOps - Por onde começarDevOps - Por onde começar
DevOps - Por onde começar
 
DevOps Anti-Patterns
DevOps Anti-PatternsDevOps Anti-Patterns
DevOps Anti-Patterns
 
A lista do PostgerSQL Brasil caiu?
A lista do PostgerSQL Brasil caiu? A lista do PostgerSQL Brasil caiu?
A lista do PostgerSQL Brasil caiu?
 
Container revolucao
Container revolucaoContainer revolucao
Container revolucao
 
Akamai Cloud Security
Akamai Cloud SecurityAkamai Cloud Security
Akamai Cloud Security
 
Management 3.0 - a vida pós-agilidade
Management 3.0 - a vida pós-agilidadeManagement 3.0 - a vida pós-agilidade
Management 3.0 - a vida pós-agilidade
 
Docker na vida real
Docker na vida realDocker na vida real
Docker na vida real
 
Devops
DevopsDevops
Devops
 
Docker e postgresql
Docker e postgresqlDocker e postgresql
Docker e postgresql
 
Um milhao de usuários simultâneos
Um milhao de usuários simultâneosUm milhao de usuários simultâneos
Um milhao de usuários simultâneos
 
Banco caiu! E a gora?
Banco caiu! E a gora?Banco caiu! E a gora?
Banco caiu! E a gora?
 
Researching postgresql
Researching postgresqlResearching postgresql
Researching postgresql
 

Blameless: A culpa não é sua

  • 1. Blameless: A culpa não é sua? (Blameless Post-Mortems) Fernando Ike
  • 2.
  • 3.
  • 4.
  • 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?
  • 8.
  • 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
  • 23.
  • 24.
  • 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.
  • 32.
  • 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.
  • 35.
  • 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