Práticas DevOps Avançadas

Alguns times ágeis já tem práticas básicas implementadas dentro de algumas disciplinas DevOps. Ou outros times podem ter necessidades muito específicas dentro do mundo DevOps, que poderiam ser classificadas como avançadas. Neste contexto, compilo aqui 12 práticas DevOps avançadas de grande auxílio para diversos tipos de times que estejam buscando melhoria contínua de sua maturidade.

1. Testes de Carga

Em aplicações Web, podem haver variações abruptas no perfil de carga da aplicação em produção. Isso se deve a natureza estocástica no comportamento de requisições Web e a natureza do protocolo HTTP. Não é incomum que picos aconteçam e gerem 10x mais carga de trabalho que o uso médio da aplicação. Os sintomas comuns nas aplicações de mercado são longos tempos de resposta e até mesmo indisponibilidade do servidor Web (erros 5xx).

Estes sintomas podem ser minimizados com o uso de testes de carga em aplicações Web. O teste de carga é uma prática que permite gerar uma carga controlada para uma aplicação em um ambiente de testes específico ou homologação e assim estabelecer se um determinado build é robusto e pode ser promovido para ambientes de produção.

2. Testes de Estresse

O teste de estresse é um tipo de teste de carga onde queremos criar fraturas em uma aplicação dentro de um ambiente com parâmetros de hardware previamente estabelecidos. Ele consiste em aumentarmos gradativamente a carga em uma aplicação para saber qual será o primeiro componente a falhar por sobrecarga (ex. Banco de dados, servidor Web ou fila de mensagem). Esta técnica permite que o time de operações possa priorizar a sua atenção em infraestruturas complexas. Ela também permite aos times de desenvolvimento estabelecer os limites de uso da sua aplicação para os seus clientes.

3. Integração Contínua (Continuous Integration)

Depois que a automação dos builds acontece, ela pode ser programada para ser executada em base diária ou até mesmos várias vezes por dia. Quando esta maturidade for alcançada, podemos avançar para que ela seja executada continuamente, i.e., toda vez que um um commit acontecer em um código fonte.

É esperado que esta prática faça pelo menos o seguinte conjunto de passos:

  • promova a recompilação do código fonte do projeto;
  • execute as suites de teste de unidade automatizados do projeto;
  • gere o build do produto;
  • crie um novo rótulo para o build;
  • gere defeitos automatizados para o time se o build falhou por algum motivo.

A prática da integração continua promove as seguintes vantagens:

  • detectar erros no momento que os mesmos acontecem;
  • buscar um ambiente de gestão de configuração minimamente estável de forma continuada;
  • estabelecer uma mudança cultural no paradigma de desenvolvimento, através de feedbacks contínuos para o time de desenvolvimento da estabilidade do build.

4. Implantação Contínua (Continuous Deployment)

Depois que um processo mínimo de integração e implanatção estiver em curso, podemos avançar também para um processo contínuo de implantação nos ambientes intermediários (testes ou homologação). Este processo pode ser controlado por uma ferramenta e normalmente é ativado quando um novo build foi gerado pela ferramenta de automação de builds.

Em linhas gerais, a prática da implantação contínua garante que mesmo conjunto de bits do build é replicado no ambiente do desenvolvedor para ambientes controlados de desenvolvimento e homologação, garantindo a consistência do build em outros ambientes.

Em ambientes rigidamente governados onde existam processos ITIL, DBAs e times independentes de QA, naturalmente irão haver ciclo de pré-aprovações ou pós-aprovações para que as promoções de ambiente ocorram. O fato importante a notar na cultura DevOps é que o ser humano envolvido não copia arquivos ou parametriza aplicações. Ele examina a requisição, o build, parâmetros e as suas evidências de teste. Ao aprovar a solicitação de promoção, um robô irá fazer a movimentação dos builds e a parametrização apropriada da aplicação. Se ele não autorizar a promoção, um defeito é aberto para o solicitante no canal apropriado.

5. Entrega Contínua (Continuous Delivery)

Em termos simples, a entrega continua é o processo de implantação contínua em ambiente de produção. Ela é normalmente ativada por uma ferramenta automatizada quando um novo build for publicado com sucesso no ambiente de homologação. A entrega contínua normalmente envolve:

  • a requisição de aprovação de implantação para o responsável pelo ambiente de produção;
  • a cópia dos arquivos do ambiente de homologação para o ambiente de produção;
  • a verificação do estado da aplicação disponibilizada em produção.

Observe que a entrega contínua não significa que o ambiente de produção é modificado a todo instante. Apenas empresas de serviços de Internet podem e devem fazer isso. A entrega contínua implica que o ambiente de produção pode ser alterado se um novo build estiver disponível e as aprovações necessárias foram dadas para a promoção do build.

A entrega contínua envolve tipicamente a execução de smoke tests, que são testes de sanidade da aplicação. Estes testes verificam minimamente a estabilidade do build colocado em produção e testam cenários funcionais mínimos.

6. Integração Contínua, Implantação Contínua e Entrega Contínua – Entenda as diferenças

A integração continua (Continuous Integration) é o processo de compilar o código em ambiente limpo, rodar testes e outros processos de qualidade e gerar um build, disparado por qualquer modificação no código fonte.

Já a implantação continua (Continuos Deployment) é o processo de promover o build gerado no processo de integração para ambientes intermediários como QA ou homologação.

Finalmente, a entrega continua (Continuous Delivery) é o processo de implantação continua que busca promover os builds para o ambiente de produção.

7. Testes Canários (ou Testes A/B)

Os testes canários são práticas úteis para empresas que praticam a entrega contínua e querem minimizar efeitos colaterais de novas funcionalidades na comunidade de usuários.

Quando um novo produto é colocado em produção pela automação dos releases, pode haver um risco de negócio em liberar as novas funcionalidades para toda a sua comunidade de usuários. Talvez seja necessário fazer um certo experimento de negócio para saber se aquela funcionalidade será realmente útil e se será mantida ou removida do produto.

Estes experimentos controlados, especialmente úteis em startups, podem ser ativados com os testes canários. O termo é devido a uma prática que ocorria nas minerações na Europa há alguns séculos. Mineiros levavam canários em gaiolas para novos veios em suas minas. Eles começam a trabalhar e deixavam os canários perto deles ao longo do dia de trabalho. Se um canário morresse depois de um tempo pequeno naquele ambiente, era porque o ambiente não estava saudável para a atividade humana devido a gases tóxicos. Na cultura DevOps da TI, o teste canário consiste em habilitar novas funcionalidades apenas para um grupo controlado de usuários (os canários). Ou seja, em ambiente de produção a aplicação opera de duas formas distintas para duas comunidades (A/B). Isso pode ser implementado através do padrão de desenho chamado Feature Toogles[1] e permite estabelecer uma prática chamada HDD (Hypothesis Driven Development). Se os canários não gostam do ambiente, a funcionalidade pode ser removida facilmente do produto em ambiente de produção sem intervenção no código fonte.

8. Infraestrutura como Código (IAC)

Times de baixa performance DevOps ainda possuem processos manuais e morosos de acionamento entre desenvolvimento e operações. Um exemplo prático é a criação de uma nova máquina feita do time de desenvolvimento para o time de ops. Em muitas empresas, este tipo de requisição demora horas, dias ou até mesmo semanas para ser realizada.

Quando times alcançam boa maturidade na configuração de elementos como scripts, elas podem avançar e tratar até o mesmo o hardware como código. Através de tecnologias disseminadas nos últimos anos em ambientes Linux, Windows e OS/X, é possível configurar os processos de automaçao de build e automação de releases para criar uma máquina virtual através de um código de script. A infraestrutura como código é prática essencial para aproximar devs e ops, pois ela permite estabelecer para o time de operações confiabilidade apropriada para as novas implantações realizadas em ambientes de produção.

A infraestrutura como código traz ainda como grande benefício estabelecer um protocolo comum entre os times de desenvolvimento e o time de operações. Esta prática elimina a necessidade da criação manual de ambientes físicos, que é moroso, propenso a erros e que causa muito atrito entre times. Ao automatizar esse processo, podemos reduzir brutalmente o tempo de ciclo para entrega de aplicações em produção. A tecnologia do Docker[2] é um excelente exemplo neste sentido.

Através de ferramentas utilitárias como o Power Shell DSC no Windows, Puppet, Chef, entre outras, arquivos de scripts que especificam configurações de máquinas podem ser compilados e então implantados em plataformas de nuvens como a Microsoft Azure ou Amazon EC2. A implantação deste arquivo cria, dinamicamente, uma máquina virtual com a exata especificação informada. Ou seja,  o trabalho de criação manual de uma máquina virtual e sua tediosa configuração é eliminado. Ao invés, criamos e testamos um script em alguma linguagem e o ambiente subjacente se encarrega de fazer o provisionamento das máquinas virtuais no ambiente de produção.

Até alguns anos atrás, somente era possível pensar no IAC se usássemos ambientes de nuvens públicas. Mais recentemente, isso é também possível com tecnologias similares em nuvens privadas com Linux e Windows. Tecnologias como o Pivotal Cloud Foundry e o IBM Bluemix, entre outras, tornaram possíveis fazer IAC em nuvens privadas.

9. Ambientes Self-Service

Em muitas empresas, é comum que um novato demore horas ou até dias para que consiga estabelecer um novo ambiente de trabalho. Isso é devido ao conjunto de passos manuais necessários, falta de procedimentos operacionais e dificuldades implíticas a montagem de ambientes Java EE ou .NET.

A prática de ambientes self-service permite que através de um código de script todo um ambiente de trabalho seja baixado, criado e disponibilizado para habilitar um desenvolvedor no seu trabalho em poucos minutos. Dado que um desenvolvedor tenha uma estação de trabalho com excelente memória RAM e uma rede veloz, é possível operacionalizar esta prática e salvar tempo precioso como o estabelecimento de ambientes de trabalho com confiabilidade e robustez. O Docker, em particular, é uma tecnologia que ganhou popularidade nos últimos anos para apoiar também esta prática.

10. Injeção de Falhas

Uma prática avançada DevOps é injetar defeitos no ambiente de produção de forma explícita. Por exemplo, podemos deliberadamente desligar o acesso ao banco de dados ou outros recursos críticos e forçar a aplicação a falhar. Isso pode parecer bizarro para alguns ou um contrassenso para outros. Mas pode fazer todo o sentido quando estamos buscando ambientes de alta disponibilidade e confiabilidade. Através do uso de procedimentos controlados de desestabilização da aplicação, podemos verificar como a aplicação se recupera de uma falha em ambiente de produção. Algumas perguntas que o time de operações poderia investigar incluem:

  • Ela se recupera automaticamente e retorna para o estado original antes da falha?
  • Ela emite alarmes apropriados para as partes interessadas?
  • Ela fornece mensagens simples e explicativas para os usuários finais?

Esta prática começou a ganhar momento na TI depois que a Netflix publicou[3] o uso desta prática nos seus ambientes de produção e a disponibilização da sua ferramenta de injeção de falhas chamada Simian Army[4]. Conceitualmente, esta prática permite estabelecer um mecanismo de antifragilidade[5] na sua aplicação, tornando-a melhor ao longo do tempo à medida que ela seja estressada.

11. Telemetria

A telemetria é uma forma avançada de monitoração de aplicações em ambiente de produção. Ela permite conhecer mais profundamente os padrões de uso de uma aplicação, variações de carga, acesso, entre outras questões. A Telemetria conta também com um mecanismo intrínseco de capacidade de análise de uso (analytics) que permite aos times conhecer os padrões de acesso e assim evoluir o produto tecnicamente e também do ponto de vista de negócio com mais sabedoria.

12. Planejamento de Capacidade

O planejamento de capacidade envolve o uso de técnicas estatísticas e teoria de filas para conhecer, modelar e simular a carga de trabalho em aplicações e assim estabelecer o hardware mais apropriado para rodar uma aplicação, bem como ter ciência dos limites e potenciais problemas de operação.

Esta técnica pode ser implementada por ferramentas de testes de carga e performance e são especialmente úteis para empresas que trabalhem com cenários desafiantes de cargas de trabalho e busquem o uso de computação elástica em ambientes de nuvens.

[1] http://martinfowler.com/articles/feature-toggles.html

[2] http://docker.com

[3] https://www.infoq.com/br/news/2012/08/netflix-chaos-monkey

[4] https://github.com/Netflix/SimianArmy

[5] A fragilidade significa que algo quebra sob algum estresse, como por exemplo um copo fino solto de certa altura. Já a robustez indica que algo resiste a um estresse sem alterar o seu estado. Mas a antifragilidade vai muito além da robustez e resiliência. Um organismo antifrágil melhora o seu estado depois de submetido a um estresse. Por exemplo, exercícios físicos, até um certo nível, geram estresses em pessoas e a resposta do corpo delas é se tornar melhor com uma melhor densidade óssea e maior massa muscular. A antifragilidade é o oposto matemático da fragilidade. Enquanto a fragilidade é denotada como um número negativo -X, a robustez seria denotada como o número 0 e a antifragilidade seria denotada como um número positivo X. Este conceito é apresentado e discutido no livro AntiFrágil – Coisas que se beneficiam com o caos, de Nicholas Taleb, publicado em 2012.

No próximo post, iremos começar a apresentar ferramentas do ecossistema de DevOps.

 

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s