Certificações oficiais DevOps

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:

  1. 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.
  2. Trate como prioridade máxima qualquer impedimento que prejudique a consistência entre os ambientes.
  3. 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.

  1. Programe e envie o código ao trunk.
  2. Gere pacotes prontos para implantação.
  3. Valide os pacotes, as dependências e a prontidão da configuração.
  4. Valide se o ambiente está pronto.
  5. Execute os testes automatizados.
  6. Registre todos os resultados de validação e dos testes automatizados para fins de auditoria e conformidade.
  7. Implante os pacotes no ambiente de destino.
  8. Execute testes automatizados no ambiente de destino para validar a implantação.
  9. Monitore as métricas de sistema, desempenho e atividade do ambiente de destino.
  10. 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.


Padrão de implantação azul-verde (fonte: Octopus Deploy)
  1. Ambiente azul

    Atende às solicitações com a versão atual.

  2. Ambiente verde

    Prepare e verifique a nova versão separadamente.

  3. Redirecione o tráfego

    Direcione o tráfego para a nova versão. Se necessário, volte à anterior.

Veja o diagrama original ↗

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.


Padrão de implantação canário (fonte: Octopus Deploy)
  1. Canário

    Implante a nova versão primeiro em um grupo pequeno.

  2. Teste

    Observe e verifique a nova versão.

  3. Amplie a liberação

    Amplie a liberação quando as verificações forem bem-sucedidas.

Veja o diagrama original ↗

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.


The Dark Launch (fonte: TechCo Media)
  1. Implante a funcionalidade

    Coloque o novo código no sistema em execução.

  2. Controle a visibilidade

    Ative a funcionalidade para usuários selecionados por meio de uma feature flag.

  3. Amplie o acesso

    Mantenha a funcionalidade desativada para os demais usuários até que tudo esteja pronto.

Veja o diagrama original ↗

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.


Padrão de aplicação estranguladora (fonte: Microsoft Azure Design Patterns)
  1. Início da migração

    Coloque uma fachada na frente do aplicativo legado e dos novos módulos.

  2. Fase avançada da migração

    Direcione mais funcionalidades para os módulos modernos enquanto o sistema legado continua disponível.

  3. Migração concluída

    Direcione todo o tráfego do aplicativo para o sistema substituto.

Veja o diagrama original ↗

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.



Garantimos que nosso treinamento on-line gratuito vai preparar você para passar no exame de certificação DevOps!

  1. 01

    Faça sua inscrição on-line

    Escolha sua certificação Accredited e conclua a inscrição.

  2. 02

    Receba seu código de acesso

    Seu código pessoal de acesso ao exame chega imediatamente por e-mail.

  3. 03

    Prepare-se e faça o exame

    Estude com o treinamento gratuito e responda a 50 questões de múltipla escolha on-line.

  4. 04

    Conquiste sua credencial vitalícia

    Receba um certificado com validade mundial e um selo digital verificável.

Amostra de Certified DevOps Generalist™
Inscreva-se para a certificação

A SUA FORMAÇÃO PREMIUM GRATUITA ON-LINE

Receba a terceira edição de DevOps Revealed

Criamos seu treinamento com um grupo de líderes de negócios e de pessoas, coaches, mentores, especialistas e autoridades reconhecidas em DevOps dos principais setores. Qualquer visitante do site da International DevOps Certification Academy™ pode acessá-lo. Encontre os materiais pelos links Seu livro gratuito sobre DevOps e Seu treinamento premium gratuito de DevOps do menu principal.

Estes materiais são propriedade intelectual da International DevOps Certification Academy™ e estão protegidos por direitos autorais. Nós os disponibilizamos gratuitamente a todos porque compartilhar nossa experiência ajuda os profissionais de DevOps e promove o desenvolvimento da área.

Seu exame de certificação é composto de questões de múltipla escolha. Estude o conteúdo do treinamento on-line para adquirir os conhecimentos necessários para passar no exame e conquistar a certificação DevOps.

Garantimos que nosso treinamento on-line premium e gratuito vai preparar você para passar no exame de certificação DevOps!