Treinamento escrito de DevOps
Como promover o aprendizado contínuo em DevOps?
Sua experiência com projetos de software já mostrou que problemas são inevitáveis, mesmo com listas de verificação, revisões por pares e mecanismos de controle, auditoria e conformidade. É hora de a equipe e a organização DevOps criarem uma cultura de autodiagnóstico, aprendizado e melhoria contínua. Aceite que os problemas ocorrem e prepare as equipes para lidar com eles. Resolver problemas deve fazer parte do dia a dia e contribuir para o aprendizado e a melhoria da organização. Para ampliar o efeito das soluções, torne-as visíveis e facilmente acessíveis a toda a organização DevOps.
A Netflix, uma organização DevOps de destaque, criou um software interno chamado Chaos Monkey para simular eventos catastróficos em seus data centers na nuvem. O Chaos Monkey destrói servidores aleatoriamente nos sistemas de produção, permitindo que a equipe verifique sua capacidade de manter a resiliência, a estabilidade e a qualidade do serviço sem interrupção para os clientes. A equipe aprende com cada falha e aplica as lições para tornar os sistemas mais estáveis e resilientes.
A importância de criar uma cultura de aprendizado
Quando a organização procura culpados depois de incidentes, cria uma cultura de medo entre os engenheiros. O trabalho se torna lento, burocrático e sujeito a disputas internas. Em vez de aprender conscientemente com os erros, aumentar a resistência e a resiliência e agir com mais atenção para evitá-los, as pessoas se preocupam em se proteger. O trabalho, os problemas e até as soluções nunca ficam plenamente visíveis.
Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so
- produzem menos para errar menos.
- deixam de dar visibilidade ao trabalho, aos problemas e às soluções.
- perdem o incentivo para transformar soluções em aprendizado organizacional.
- O mesmo problema, ou um muito parecido, certamente voltará a ocorrer, pois ninguém dedica tempo e energia a aprender, compartilhar e ensinar sobre os problemas e as soluções nem a torná-los visíveis.
Realize análises pós-incidente assim que possível, enquanto as causas ainda estão frescas na memória
Os objetivos de uma análise pós-incidente são simples:
- Identificar o que deu certo para lembrar de repetir essas ações em situações semelhantes.
- Registrar o que deveria ter sido feito de outra forma para aprimorar as técnicas no futuro.
- Registrar o que você fez de errado e sugerir abordagens alternativas ou medidas de segurança para usar na próxima vez em que enfrentar um problema semelhante.
- Descobrir por que fazia sentido tomar ou deixar de tomar a medida que levou ao incidente.
Examinar os próprios erros assusta e, em algumas organizações, pode ser perigoso. Se admitir um erro expõe você a críticas ou punições, provavelmente evitará falar sobre ele. Essa estratégia é contraproducente, pois deixar de entender um erro passado normalmente leva a repeti-lo no futuro. Organizações comprometidas com a melhoria entendem isso e se empenham em criar um processo e uma cultura que permitam examinar os erros com segurança.
Antes de participar de uma análise pós-incidente, aceite algumas premissas básicas:
- Todas as pessoas tentam fazer o melhor de que são capazes, conforme seu entendimento da situação.
- As decisões são tomadas sob pressão, com informações imperfeitas.
- Muitas vezes, você precisa realizar tarefas para as quais não foi treinado, com as ferramentas e os recursos que estiverem à mão.
- Nessas situações, os erros são inevitáveis.
- O objetivo desse processo é examinar o que aconteceu e identificar as lições que podem ser aprendidas, sem atribuir culpa a pessoas nem a suas ações.
- O resultado é uma avaliação dos processos e de como melhorá-los, sem avaliar indivíduos ou grupos de pessoas.
É essencial que todos os envolvidos aceitem plenamente o modelo “Sem culpados, estamos aqui para aprender”. Muitas organizações se esforçam para criar ambientes assim. A FAA, por exemplo, conta com o Aviation Safety Reporting System, pelo qual pilotos que cometem “erros” podem obter imunidade a sanções regulatórias se relatarem os incidentes.
As análises pós-incidente devem sempre definir medidas práticas para evitar que o incidente volte a ocorrer. Alguns exemplos são novas métricas de telemetria, novos casos de teste automatizados, identificação de tipos de mudança que exigem revisão adicional de código, refatoração ou desacoplamento de componentes complexos que causam problemas frequentes.
Divulgue amplamente os registros das análises pós-incidente e as lições aprendidas. Assim, o conhecimento de uma etapa do fluxo de valor se transforma em aprendizado para toda a organização. Isso também mostra que a organização DevOps valoriza a transparência, a abertura e o aprendizado.
Organize simulações de incidentes para melhorar seus sistemas
Uma simulação de incidentes, ou game day, é diferente daqueles eventos monótonos em que os extrovertidos se divertem e os introvertidos ficam no celular esperando o tempo passar.
Em um game day, falhas catastróficas são simuladas nos sistemas de teste. As equipes DevOps trabalham para resolvê-las e aprender com elas.
Por exemplo, desative um servidor crítico para verificar se o mecanismo de failover funciona sem interromper o serviço. A equipe DevOps verifica se e como funciona a recuperação a partir dos backups ou da infraestrutura como código (IaC). Identificar problemas nesses cenários ajuda a equipe a criar sistemas resilientes e tolerantes a falhas e a aprender com o exercício.
Ao resolver os problemas, a equipe DevOps fortalece os vínculos com outros departamentos enquanto ensaia situações de falha sem a pressão de um incidente real. Você pode testar e melhorar os processos de comunicação e de diagnóstico de problemas em toda a organização.
Você também poderá observar sinais fracos de problemas maiores que talvez apareçam no futuro. Incidentes frequentes de baixa prioridade durante essas simulações ou um pequeno efeito colateral que quase derrube outro componente crítico da arquitetura são sinais importantes. Leve-os em conta e investigue-os para melhorar os sistemas.
CONCLUSÃO
Incentive sua equipe DevOps a assumir riscos calculados. Organizações DevOps de alto desempenho como a sua cometem erros com mais frequência. Isso faz parte do aprendizado e da melhoria do desempenho.
Em comparação com organizações típicas, as de alto desempenho têm 80% menos falhas críticas nos sistemas de produção. Em outras palavras, elas têm cinco vezes menos incidentes que afetam os clientes. É por isso que os engenheiros precisam se sentir livres para cometer erros e aprender com eles.
