Treinamento escrito de DevOps

Por que estabelecer ciclos de feedback para implantações mais seguras em produção?

Em mercados competitivos, departamentos de garantia da qualidade e operações separados do desenvolvimento dificultam atender os clientes rapidamente e responder de forma contínua às suas demandas. Ainda assim, embora a maioria dos desenvolvedores reclame da burocracia, quando tem a oportunidade de trabalhar com especialistas em qualidade e operações na própria equipe, ainda teme fazer implantações em produção sem supervisão. Daí a necessidade de técnicas e medidas para tornar essas implantações mais seguras.

Como manter um fluxo DevOps contínuo

Para manter um fluxo contínuo e sem interrupções, as organizações DevOps mais bem-sucedidas implantam mudanças em produção com frequência e em lotes pequenos. Assim, todos na equipe podem avaliar e entender as mudanças e corrigi-las quando necessário.

Criar um pipeline automatizado de implantação é só parte do trabalho. Integre a telemetria operacional ao pipeline para receber feedback rápido sobre os resultados das mudanças em produção e pré-produção. Estabeleça também um entendimento comum de que todos na equipe DevOps são responsáveis pela saúde e continuidade de todo o fluxo de valor e do pipeline.

Use telemetria para tornar as implantações mais seguras

Só considere uma mudança e sua implantação “prontas” depois de comprovar que funcionam conforme foram projetadas e programadas. Após implantar, acompanhe de perto as métricas dos módulos alterados, as novas métricas, se houver, e as métricas dos outros componentes que possam ser afetados.

Mesmo com testes automatizados em pré-produção e monitoramento pela infraestrutura de telemetria, ainda haverá problemas em produção. É impossível evitá-los todos, mas você pode se preparar para corrigi-los quando acontecerem. Se uma mudança interromper o pipeline de implantação, reúna os especialistas necessários para resolver o problema e restabelecer seu funcionamento. Três métodos usados com frequência são:

1. Desativar a funcionalidade Essa é a maneira mais fácil de corrigir um problema. Ela dispensa uma implantação urgente de código. Basta desativar a funcionalidade pela chave de ativação. As partes com erro na implantação não precisam ser corrigidas de imediato, então a equipe DevOps tem tempo de identificar corretamente a causa-raiz e aprimorar suas técnicas para reduzir a probabilidade de o problema voltar a ocorrer.
2. Corrigir o problema com uma nova mudança Implante código novo para corrigir o problema. Embora essa abordagem seja arriscada em organizações de TI tradicionais, ela pode funcionar com eficiência e segurança em organizações DevOps que têm testes e implantação automatizados e telemetria abrangente em produção.
3. Reverter a mudança Remova o código com erro e, com sorte, o problema desaparecerá.

Faça os desenvolvedores receberem feedback das operações reais

Faça um rodízio na equipe DevOps para que as pessoas assumam responsabilidades operacionais e lidem com incidentes. Assim, todos no fluxo de valor entendem os desafios e as responsabilidades dos centros de trabalho das etapas seguintes. Coloque desenvolvedores, testadores, arquitetos, designers, gerentes e diretores em plantões operacionais para receberem alertas de incidentes às 3h da manhã. Assim, todos compreendem melhor as consequências das decisões que tomam no dia a dia.

Esse rodízio evita que os especialistas em operações se sintam isolados. Toda a equipe DevOps ajuda a equilibrar a correção de incidentes em produção, a redução da dívida técnica e o desenvolvimento de novas funcionalidades. Quando arquitetos e desenvolvedores também são acordados às 3h da manhã, os incidentes são corrigidos mais rápido do que nunca.

Quando desenvolvedores observam clientes usando o software, descobrem várias melhorias que podem fazer de imediato. O mesmo acontece quando arquitetos, designers, desenvolvedores e testadores acompanham as etapas seguintes do ciclo de engenharia de software. Ao entender o impacto de seu trabalho nessas etapas, eles passam a enxergar novas formas de melhorar a qualidade e ajustar os resultados para ajudar os colegas que os recebem. Todos na equipe DevOps passam a tratar os requisitos operacionais não funcionais no backlog, como parte do trabalho diário. Isso só é possível com ciclos rápidos e contínuos de feedback na organização.

Faça os desenvolvedores operarem o próprio sistema

É difícil transmitir aos desenvolvedores as lições aprendidas com sistemas reais em produção. Por isso, organizações DevOps de destaque, como o Google, atribuem às equipes de desenvolvimento a responsabilidade pela operação do software durante e depois do lançamento inicial. Enquanto o produto está sob gestão do desenvolvimento, os engenheiros de operações atuam como consultores. Depois que o produto se mostra estável em produção por cerca de 6 meses, é transferido para a equipe de operações. A transferência só acontece após verificar critérios como defeitos passados e em aberto, cobertura da telemetria, incidentes fora do horário de trabalho, projeto arquitetural com baixo acoplamento e segurança das mudanças e implantações.

Se, sob gestão de operações, forem descobertos problemas importantes de projeto e de código, o produto pode voltar para os desenvolvedores. Nessa etapa, o desenvolvimento fica responsável por estabilizar o software, e os engenheiros de operações atuam como consultores.

CONCLUSÃO

Neste capítulo, abordamos técnicas para manter um fluxo mais seguro e bem-sucedido nos pipelines de implantação da sua organização DevOps.

Essas técnicas demonstram respeito mútuo e colaboração entre desenvolvedores e engenheiros de operações nas equipes DevOps.