Treinamento escrito de DevOps
Como implantar código DevOps com baixo risco em produção?
Em muitas organizações de TI, implantar em produção é trabalhoso e estressante. Para evitar problemas, as equipes tendem a implantar com a menor frequência possível. Assim, inevitavelmente passam a implantar lotes maiores, que causam problemas ainda maiores. Esse ciclo vicioso se agrava e infelizmente retrata a situação da maioria das maiores organizações, inclusive aquelas cujo negócio principal é software e tecnologia.
Sua equipe DevOps tem mecanismos integrados de controle e mitigação de riscos
Em uma organização de TI típica, o desenvolvimento constrói o software e as operações cuidam da implantação. A metodologia DevOps transfere os mecanismos de controle e mitigação de riscos de equipes independentes para sua própria equipe autossuficiente e capacitada. Essa equipe usa processos de implantação automatizada e revisão por pares.
Como os ambientes de produção e de não produção são tão importantes quanto o software produzido pela equipe DevOps, a equipe adota três princípios:
- Garanta a consistência de todos os ambientes quanto aos sistemas operacionais, componentes, interfaces, níveis de correção, demais dependências e, claro, ao próprio software e suas configurações.
- Trate como prioridade máxima qualquer impedimento que prejudique a consistência entre os ambientes.
- Implante com as mesmas técnicas em todos os ambientes para que o ensaio das implantações em produção se torne uma prática diária.
Seu mecanismo integrado de implantação por autosserviço
O mecanismo automatizado de implantação por autosserviço segue estas etapas.
- Programe e envie o código ao trunk.
- Gere pacotes prontos para implantação.
- Valide os pacotes, as dependências e a prontidão da configuração.
- Valide se o ambiente está pronto.
- Execute os testes automatizados.
- Registre todos os resultados de validação e dos testes automatizados para fins de auditoria e conformidade.
- Implante os pacotes no ambiente de destino.
- Execute testes automatizados no ambiente de destino para validar a implantação.
- Monitore as métricas de sistema, desempenho e atividade do ambiente de destino.
- Forneça feedback rápido e corrija ou reverta a implantação se algo der errado.
Implantação e liberação são etapas diferentes
Com o mecanismo automatizado de autosserviço para implantar código em ambientes de produção e de não produção, sua equipe DevOps pode implantar diariamente. Como nem toda implantação libera uma funcionalidade ou um benefício para os clientes, a equipe precisa projetar as aplicações e/ou os ambientes de modo que as liberações dispensem mudanças de código e novas implantações associadas.
Padrão de implantação azul-verde
Um dos desafios da implantação automatizada é a transição da etapa final de testes para a produção. Em geral, é preciso fazer isso rapidamente para minimizar a indisponibilidade. Na implantação azul-verde, você mantém dois ambientes de produção tão idênticos quanto possível. Em um dado momento, um deles, por exemplo o azul, está ativo. Ao preparar uma nova versão do software, você realiza a etapa final de testes no ambiente verde. Quando o software estiver funcionando no ambiente verde, altere o roteamento para que todas as solicitações sejam encaminhadas a ele. O ambiente azul fica ocioso.
-
Ambiente azul
Atende às solicitações com a versão atual.
-
Ambiente verde
Prepare e verifique a nova versão separadamente.
-
Redirecione o tráfego
Direcione o tráfego para a nova versão. Se necessário, volte à anterior.
Padrão de implantação canário
(também chamado de The Dark Launch)
Os canários já foram usados regularmente nas minas de carvão como um sistema de alerta antecipado. Gases tóxicos na mina, como metano ou dióxido de carbono, matavam o pássaro antes de afetar os mineiros. Sinais de sofrimento da ave indicavam que as condições eram perigosas.
Inspirada no uso de canários nas minas, a implantação canário libera versões para um grupo de usuários ou servidores. Primeiro, implante a mudança em um pequeno conjunto de servidores e teste-a. Depois, aplique-a aos demais. A implantação canário serve como alerta antecipado e reduz o impacto na disponibilidade. Se ela falhar, os demais servidores não serão afetados.
-
Canário
Implante a nova versão primeiro em um grupo pequeno.
-
Teste
Observe e verifique a nova versão.
-
Amplie a liberação
Amplie a liberação quando as verificações forem bem-sucedidas.
Facebook, Google e várias outras grandes empresas de tecnologia usam um padrão canário chamado “The Dark Launch”. Elas liberam e testam novas funcionalidades aos poucos com um grupo pequeno de usuários antes de liberá-las para todos. Assim, descobrem se você gosta da mudança e avaliam seu impacto no desempenho. O Facebook chama sua ferramenta de “Gatekeeper” porque ela controla o acesso dos consumidores a cada nova funcionalidade.
-
Implante a funcionalidade
Coloque o novo código no sistema em execução.
-
Controle a visibilidade
Ative a funcionalidade para usuários selecionados por meio de uma feature flag.
-
Amplie o acesso
Mantenha a funcionalidade desativada para os demais usuários até que tudo esteja pronto.
O nome dark launch se deve ao fato de que essas funcionalidades geralmente não são anunciadas. Elas são liberadas discretamente para 1% dos usuários, depois 5%, depois 30% e assim por diante. Às vezes, a funcionalidade fica disponível por alguns dias e você nunca mais a vê. Isso provavelmente ocorre porque ela teve desempenho ruim ou porque a empresa só queria coletar feedback inicial para orientar o desenvolvimento.
Padrão de liberação com sistema imunológico de cluster
Esse padrão é uma extensão da implantação canário. Ele exige que os sistemas de monitoramento do desempenho e das atividades do software estejam integrados ao processo de liberação.
Na implantação canário da ilustração acima, depois da implantação inicial no servidor laranja, os sistemas de monitoramento registram métricas de sistema, desempenho e atividade do software e emitem alertas antecipados se os problemas ultrapassarem certos limites. Isso aciona a reversão automatizada do código instalado no servidor laranja.
Se os testes automatizados no servidor laranja e o monitoramento indicarem bons resultados, a equipe DevOps poderá implantar o código nos demais clusters de servidores azuis com muito mais confiança. Em resumo, o padrão de liberação com sistema imunológico de cluster oferece à equipe:
- Proteção adicional contra problemas que podem passar despercebidos pela automação de testes.
- Feedback rápido e reversão automatizada quando surgem problemas em produção.
Chaves de ativação de funcionalidades
Com chaves de ativação, você pode ativar e desativar funcionalidades da aplicação. Depois que todo o código necessário para uma funcionalidade é implantado em produção, basta acionar a chave para liberá-la. Essas chaves geralmente são parâmetros em arquivos de configuração do sistema em tempo de execução ou em bancos de dados de configuração.
Com essas chaves, a equipe DevOps pode desativar uma funcionalidade se a implantação canário causar erros ou piorar a experiência do usuário. Se o sistema tiver dificuldade para ganhar escala, você também poderá desativar funcionalidades que consomem muitos recursos e são relativamente menos importantes. Assim, mesmo que o sistema tenha dificuldade para operar em escala com todas as funcionalidades, os clientes podem continuar usando as mais críticas com o melhor desempenho possível. Em um portal de comércio eletrônico, por exemplo, você pode desativar temporariamente a visualização de faturas para liberar mais CPU e memória para a finalização das compras.
Em uma arquitetura orientada a serviços, as equipes DevOps também podem implantar versões diferentes dos serviços sem ativá-las. Quando todas as versões exigidas por uma funcionalidade ou por um fluxo novo estiverem implantadas, você poderá acionar as chaves dos serviços para habilitar o fluxo.
Projete a arquitetura para liberações mais seguras
Nenhuma arquitetura atende perfeitamente a todos os produtos e serviços de software em qualquer escala.
Quando uma startup cria sua plataforma de TI, normalmente escolhe uma arquitetura monolítica para chegar ao mercado com a maior rapidez e o menor custo e validar a justificativa de negócio. O problema é que funções principais e complementares, interfaces de usuário e de sistemas e integrações ficam todas interligadas, sem componentes arquiteturalmente separados. Ao longo da trajetória de organizações como Amazon, Google, Facebook e Ebay, elas precisaram abandonar as arquiteturas monolíticas para ganhar escala rapidamente e liberar e ampliar funcionalidades com baixo risco. O passo seguinte foi migrar para arquiteturas orientadas a serviços ou microsserviços, usando o padrão de aplicação estranguladora.
Padrão de aplicação estranguladora para migrar para microsserviços com baixo risco
Substituir por completo um sistema complexo pode exigir muito trabalho. Muitas vezes, você precisa migrar gradualmente para um novo sistema e manter o antigo para atender as funcionalidades que ainda não foram migradas. Operar duas versões da aplicação, porém, significa que os clientes precisam saber onde cada funcionalidade está disponível. Sempre que uma funcionalidade ou serviço é migrado, é preciso atualizar os clientes para apontar para o novo local.
O padrão de aplicação estranguladora substitui funcionalidades específicas aos poucos por novas aplicações e serviços. Crie uma fachada que intercepte as solicitações destinadas ao back-end do sistema legado. A fachada encaminha as solicitações à aplicação legada ou aos novos serviços. As funcionalidades existentes podem ser migradas gradualmente para o novo sistema, e os consumidores podem continuar usando a mesma interface sem perceber que houve uma migração.
O Ebay foi uma das primeiras organizações a usar o padrão de aplicação estranguladora para migrar uma arquitetura monolítica legada para microsserviços. A migração começou colocando as aplicações atrás de APIs universais bem definidas no ecossistema Ebay, de modo que não foi preciso reescrever todo o código de uma vez. A organização também reestruturou a engenharia em equipes pequenas, de 6 a 10 engenheiros. Uma equipe de até 10 pessoas consegue cuidar da API universal da plataforma de leilões, a API de leilões mais usada do mundo.
-
Início da migração
Coloque uma fachada na frente do aplicativo legado e dos novos módulos.
-
Fase avançada da migração
Direcione mais funcionalidades para os módulos modernos enquanto o sistema legado continua disponível.
-
Migração concluída
Direcione todo o tráfego do aplicativo para o sistema substituto.
CONCLUSÃO
Na maioria dos departamentos de TI, as equipes não são responsabilizadas por criar padrões de implantação preparados para o futuro, escaláveis e mais seguros, nem pelas arquiteturas associadas. Ainda assim, construir uma arquitetura e funcionalidades que permitam implantar com mais rapidez e segurança é um requisito importante para o sucesso com DevOps.
Você e suas equipes só colhem os benefícios da implantação contínua e das liberações tranquilas quando conseguem implantar diariamente com rapidez e baixo risco.
