Dando continuidade às “boas práticas em TI”, vamos conversar sobre outro assunto que, frequentemente, gera transtornos e incômodos no ambiente de trabalho.
Em TI, é comum que haja algum erro em código ou em algum detalhe, que acaba interferindo na execução do programa completo. Além disso, também pode haver erro em máquinas, servidores, entre outros. O erro é comum, o difícil é aceitá-lo.
Programadores se sentiam extremamente mal ao errar e acabavam perdendo a oportunidade de aprender com o erro, discuti-lo em equipe e trocar experiências.
Por isso, a cultura blameless vem reforçar que “a culpa não é sua” e é possível aprender continuamente com os erros.
Ps: ao fim do post, inseri um vídeo e também algumas sugestões de leituras para quem tiver mais interesse no assunto, mas não são obrigatórias, apenas complementares.
Aprendizagem contínua, cultura livre de culpa e Blameless Postmortems
A aprendizagem contínua e a cultura livre de culpa são dois aspectos culturais que as organizações devem compreender melhor na adoção do DevOps. E como fazer acontecer? Como construir respeito e confiança, eliminando a culpa e hostilidade? Para que as pessoas sintam-se confortáveis para trabalhar juntas.
Trust Blockers:
- Falta de contexto
- Objetivos conflitantes
As organizações precisam evoluir com o auto diagnóstico e aperfeiçoamento. E assim, falhas ou problemas significa resolver e compartilhar os efeitos, tornando a resolução disponível para todos na empresa. Este sistema dinâmico nos permite assumir e aprender com os erros para evitar recorrências.
“Quando as respostas a incidentes e acidentes são consideradas injustas (buscando culpados), isso pode impedir investigações de segurança, causando medo, tornando as organizações mais burocráticas ao invés de mais cuidadosas, e criando segredos e autoproteção”.
Blameless Postmortems
É uma reunião que acontece (se possível) em até 48 horas após o incidente, visando identificar as falhas no processo para corrigi-las. Deixe um terceiro para executá-la. Blameless é não culpar as pessoas pessoas pelas falhas, sabendo das responsabilidades inerentes da função.
Algumas recomendações para a comunicação Postmortem:
- Admita a falha
- Soa como humano
- Tenha um canal de comunicação
- Seja autêntico
E um roteiro recomendado para a reunião é o seguinte:
- A descrição do incidente
- A causa raiz
- Como o incidente foi estabilizado ou corrigido
- Um timeline dos eventos, incluindo todas as ações realizadas
- Como o incidente afetou os usuários
- Remediações e ações corretivas
As técnicas do 5 Porquês (5 Whys) e o Diagrama de Ishikawa ajudam na análise da causa raiz e efeito dos problemas.
Fonte:
Aprendizagem contínua, cultura livre de culpa e Blameless Postmortems
<< https://leonardo-matsumota.com/2019/02/14/aprendizagem-continua-cultura-livre-de-culpa-e-blameless-postmortems/ >>
Outras leituras sugeridas:
Blameless: A culpa não é sua
<< https://www.fernandoike.com/2017/08/21/blameless-a-culpa-n%C3%A3o-%C3%A9-sua/ >>
Blameless Postmortem
<< https://www.fernandoike.com/2017/09/07/blameless-postmortem/ >>
Análise e lições do Postmortem da Gitlab
<< https://www.linkedin.com/pulse/an%C3%A1lise-e-li%C3%A7%C3%B5es-do-postmortem-da-gitlab-fernando-ike >>
How SRE Creates a Blameless Culture
<< https://devops.com/how-sre-creates-a-blameless-culture/ >>
CEI - ATENDIMENTO 
Nossa Gio esses posts instigaram a minha curiosidade a querer aprender mais sobre os assuntos abordados! Acho que poderia ser uma série de uns 100 posts hein?!!!!😊
Este é um assunto que tenho pontuado já faz algum tempo, onde tento demostrar o quanto é importante compartilhar informações inclusive os erros para que possamos aprender juntos. Sem culpados e nem julgamentos, somente com o objetivo de crescermos em conjunto e também para o desenvolvimento
da percepção das responsabilidades individuais que temos e de que elas afetam a todos como equipe. Já demos o pontapé inicial com nossas reuniões periódicas e trocas de experiências diárias agora é só evoluir!!!!
CurtirCurtido por 1 pessoa