A fábula dos porcos assados (e os sistemas de informação)

Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir dai, toda vez que queriam comer porco assado, incendiavam um bosque.  O tempo passou, e o sistema de assar porcos continuou basicamente o mesmo.

Mas as coisas nem sempre funcionavam bem: às vezes os animais ficavam queimados demais ou parcialmente crus. As causas do fracasso do sistema, segundo os especialistas, a dos porcos, que não permaneciam onde deveriam, ou à inconstante natureza do fogo, tão difícil de controlar, ou, ainda, às árvores, excessivamente verdes, ou à umidade da terra ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas.

As causas eram, como se vê, difíceis de determinar – na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: havia maquinário diversificado, indivíduos dedicados a acender o fogo e especialistas em ventos – os anemotécnicos. Havia um diretor-geral de Assamento e Alimentação Assada, um diretor de Técnicas Ígneas, um administrador-geral de Reflorestamento, uma Comissão de Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas Alimentícias e o Bureau Orientador de Reforma Igneooperativas.

Eram milhares de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores árvores e sementes, fogo mais potente etc. Havia grandes instalações para manter os porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento oportuno.

Um dia, um incendiador chamado João Bom-Senso resolveu dizer que o problema era fácil de ser resolvido – bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então sobre uma armação metálica sobre brasas, até que o efeito do calor – e não as chamas – assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o diretor-geral de Assamento mandou chamá-lo ao seu gabinete e disse-lhe: “Tudo o que o senhor propõe está correto, mas não funciona. Isso pode funcionar na teoria, mas na prática não faz sentido. O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a sua teoria? E com os acendedores de diversas especialidades? E os especialistas em sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com suas máquinas purificadoras de ar? E os conferencistas e estudiosos, que ano após ano têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Hein?.”

“Não sei”, disse João, encabulado.

“O senhor percebe agora que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê que, se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução há muito tempo?.”

“O senhor, com certeza, compreende que eu não posso simplesmente convocar os anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas? O que o senhor espera que eu faça com os quilômetros de bosques já preparados, cujas árvores não dão frutos e nem têm folhas para dar sombra? E o que fazer com nossos engenheiros em porcopirotecnia? Vamos, diga-me!”.

“Não sei, senhor.”

“Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí que pode resolver tudo. O problema é bem mais sério do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia – isso poderia trazer problemas para o senhor no seu cargo.”

João Bom-Senso, coitado, não falou mais um “a”. Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões de Reforma e Melhoramentos, que falta o Bom-Senso.”

Desconheço o autor desta fábula, mas ainda vejo florestas sendo queimadas com muito mais frequência do que imaginaria na área de Tecnologia de Informação.

Ouvi um relato de um projeto que foi fragmentado para quatro empresas fornecedoras operando remotamente, cada um com a sua especialidade tecnológica (Mobilidade, barramento, back-end e Web). Uma desculpa para este arranjo foi que cada empresa fornecedora era “dona” de uma tecnologia e os acordos contratuais exigiam esta distribuição. Dois anos depois e com com milhões de reais gastos nenhum produto foi entregue. O diretor de assamento então resolveu assar no espeto os gerentes e algumas fábricas que participaram deste processo.

Também tive a oportunidade de ver um time de produto que herdou uma arquitetura Web absurdamente complexa de um  “arquiteto super inteligente” de uma fábrica de software. O efeito desta arquitetura é o que time demora 3 semanas para implementar um cadastro de complexidade média.

Estas histórias reais me lembram do conceito de complexidade acidental e complexidade essencial, popularizado na TI por Neal Ford.

A complexidade essencial representa a dificuldade inerente a qualquer problema. Na nossa fábula acima, acender fogo era necessário para assar os porcos.  A complexidade decorrente dos compromissos que assumimos que incorrem em dívidas técnicas é diferente. Consiste em todas as formas imposta externamente de que o software se torne complexo e não deve existir em um mundo perfeito. A isso chamamos de complexidade acidental. Tecnologias como o Java EJB, Microsoft BizTalk e ERPs cujos nomes não podem ser pronunciados são exemplos de complexidade acidental na TI.

Tomo a liberdade aqui de expandir a definição original do autor, pensada para arquiteturas de software, para arranjos essenciais e arranjos acidentais.

Por exemplo, a existência de analistas desenvolvedores, analistas de testes e líderes de projetos são arranjos essenciais para entregar software de qualidade. Já times de testes e times de desenvolvedores que trabalham em salas separadas e com processos cascatas são exemplos de arranjos acidentais. E os  “gerentes de projetos” que ficam atrás das suas mesas 8 horas por dia atualizando cronogramas Gantt de 1000 linhas e perguntando aos seus coordenados “Eh aí, tá pronto?” são exemplos também ruins de arranjos acidentais.

Se você está cansado de queimar florestas inteiras para assar porcos, recomendo a aplicação de práticas do Lean Software Development, um corpo de práticas muito legais para você descomplicar a sua TI e a forma como entrega e mantém software.

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
Edsger W. Dijkstra

Maturidade DevOps – Gestão de Releases, Implantação e Entrega Contínua

Este é o nosso quarto post da série sobre maturidade em práticas DevOps. E aqui vamos discutir como podemos melhorar a maturidade no processo de gestão de releases, implantação contínua e entrega contínua.

Quando estamos discutindo Releases, estamos falando em como mover com velocidade e segurança um build nos diversos ambientes da sua empresa (exemplo – testes, homologação e produção).

Os princípios orientadores da gestão de releases

  1. Construa qualidade contínua
  2. Trabalhe em pequenos lotes
  3. Os computadores executam tarefas repetitivas, as pessoas resolvem problemas
  4. Procure melhoria contínua, obsessivamente
  5. Todos devem ser responsáveis

Construa qualidade contínua

Edwards Deming, figura-chave na história do movimento Lean e influenciador do movimento DevOps, ofereceu 14 princípios fundamentais para a gestão.  O terceiro princípio diz – “Eliminar a dependência da inspeção para alcançar a qualidade. Elimine a necessidade de inspeção em massa, construindo qualidade no produto em primeiro lugar “.

É muito mais barato solucionar problemas e defeitos se os encontrarmos imediatamente – idealmente antes de serem verificados no controle de versão, executando testes automatizados localmente. Encontrar defeitos através da inspeção (como o teste manual) é demorado e caro.

Criar e evoluir loops de feedback para detectar problemas o mais cedo possível é essencial na entrega contínua. Se encontrarmos um problema em nossos testes exploratórios, não devemos apenas corrigi-lo, mas depois perguntar: como poderíamos ter captado o problema com um teste automatizado de aceitação? Quando um teste de aceitação falha, devemos perguntar: Poderíamos ter escrito um teste de unidade para capturar esse problema?

Trabalhe em pequenos lotes

Em abordagens tradicionais para o desenvolvimento de software as transferências de desenvolvimento para teste ou teste para produção de TI consistem em lançamentos completos: semanas ou meses de trabalho por equipes e fábricas com muitas pessoas. E a razão pela qual muitos times trabalham em grandes lotes é devido ao grande custo fixo de entregar as mudanças.

Na entrega contínua tomamos a abordagem oposta e buscamos obter todas as mudanças no controle de versão até o final da liberação, obtendo feedback o mais rápido possível. Um dos principais objetivos da entrega contínua é mudar a economia do processo de entrega de software para tornar economicamente viável trabalhar em pequenos lotes para que possamos obter os muitos benefícios dessa abordagem.

Trabalhar em pequenos lotes tem muitos benefícios. Isso reduz o tempo necessário para obter feedback sobre o nosso trabalho, facilita a triagem e a reação a problemas e aumenta a eficiência e a motivação.

Computadores executam tarefas repetitivas, as pessoas resolvem problemas

Uma das primeiras idéias filosóficas da tradição de Toyota é o jidoka, às vezes traduzido como “automação com um toque humano”. O objetivo é que os computadores executem tarefas simples e repetitivas, como testes de regressão para que os humanos possam se concentrar na resolução de problemas . Assim, computadores e pessoas se complementam.

Muitas pessoas se preocupam que a automação os afastará de um emprego. Este não é o objetivo. Nunca haverá escassez de trabalho em uma empresa de sucesso. Em vez disso, as pessoas são liberadas do trabalho de trabalho despreocupado para se concentrar em atividades de maior valor. Isso também tem o benefício de melhorar a qualidade, uma vez que os seres humanos estão mais propensos a erros ao executar tarefas insensatas.

Procure melhoria contínua, obsessivamente

A melhoria contínua, ou kaizen em japonês, é outra idéia-chave do movimento Lean. Taiichi Ohno, uma figura-chave da história da empresa Toyota, disse uma vez,

“As oportunidades de Kaizen são infinitas. Não pense que você tenha feito as coisas melhores do que antes e esteja à vontade … Isso seria como o aluno que se torna orgulhoso porque superou seu mestre duas vezes em três na esgrima. Uma vez que você escolhe as idéias kaizen, é importante ter a atitude correta em nosso trabalho diário porque depois de uma ideia Kaizen existe uma outra ideia Kaizen a ser descoberta.”

Não trate a transformação como um projeto que será iniciado e depois concluído para que possamos retornar ao negócio como de costume. As melhores organizações são aquelas em que todos tratam o trabalho de melhoria como parte essencial do seu trabalho diário e onde ninguém está satisfeito com o status quo.

Todos devem ser responsáveis

Em organizações de alto desempenho, nada é “problema de outra pessoa”. Os desenvolvedores são responsáveis ​​pela qualidade e estabilidade do software que eles criam. As equipes de operações são responsáveis ​​por ajudar os desenvolvedores a desenvolver qualidade. Todos trabalham juntos para atingir os objetivos de nível organizacional, em vez de otimizar o que é melhor para sua equipe ou departamento.

Quando as pessoas fazem otimizações locais que reduzem o desempenho geral da organização, muitas vezes são devido a problemas sistêmicos como sistemas de gerenciamento pobres, ciclos orçamentários anuais ou incentivos que recompensam os comportamentos errados. Um exemplo clássico é recompensar os desenvolvedores por aumentar sua velocidade ou escrever mais código ou recompensar testadores com base no número de erros que eles encontram.

A maioria das pessoas quer fazer o que é certo, mas eles vão adaptar seu comportamento com base em como eles são recompensados. Portanto, é muito importante criar loops de feedback rápido das coisas que realmente importam: como os clientes reagem ao que construímos e o impacto em nossa organização.

Estabelecido esta base conceitual, vamos apresentar aqui uma escala de maturidade para a gestão de releases.

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de gestão de releases. A entrega de um release nos ambientes de testes, homologação e produção é sempre feita de forma manual e sem o auxílio de ferramentas. Neste nível observamos que os desenvolvedores precisam trocar manualmente os apontamentos de banco de dados e editar arquivos de configuração (exemplos – WebConfig em .NET ou web.xml e Java).  Muitas vezes observamos rebotes e atritos com o time de infraestrutura e erros em produção devido a falhas humanas.
  2. Maturidade 2 – Consciente –  Aqui a cultura de releases começa a ser instalada. Ferramentas como Ansible ou Microsoft PowerShell  começam a ser utilizadas para automatizar os passos de publicação. Embora o processo ainda exija intervenção humana, os passos estão documentados em scripts que podem ser disparados sob demanda.
  3. Maturidade 3 – Gerenciado – Aqui os releases começam a ser publicados em intervalos regulares em ambientes controlados. Ferramentas como o Jenkins, GitLab, IBM Racional Team Concert, Microsoft TFS ou Microsoft VSTS entram em cena para pegar um build que já tenha sido produzido e mover este build para os ambientes de testes, homologação e produção. Neste nível informações sobre senhas de produção não são mais conhecidas pelo time de desenvolvidos. Os arquivos com estas informações são usados pelos ambientes de gestão de release de forma transparente. E aqui também existem smoke tests automatizados que verificam se o ambiente de testes, homologação ou produção não foram quebrados.
  4. Maturidade 4 – Avançado – Aqui temos um incremento na frequência de implantação de builds e também na capacidade de desfazer publicações automaticamente. Os builds começam a ser implantados com frequência diária em ambientes de testes e homologação e as publicações em produção ocorrem conforme os calendários acordados com áreas de negócio. E um aspecto crítico observado neste nível também é a capacidade de desfazermos publicações caso alguma instalabilidade tenha sido observada em ambiente de produção. Esta capacidade de desfazer publicações, obviamente, é controlada por ferramentas para evitar erros humanos.
  5. Maturidade 5 – Melhoria Contínua – Aqui o time está tão avançado que começa a experimentar a prática da implantação contínua (continuous deployment) e entrega contínua (continuous delivery). A primeira prática lida com a capacidade de publicar automaticamente builds nos ambientes de testes e homologação toda vez que um novo build tiver sido gerado pelo time.  E a segunda prática lida com a capacidade de entregar builds em produção de forma automatizada e com governança toda vez que um build tiver sido aprovado no ambiente de homologação. Aqui vemos também os times experimentando com testes e ambientes canários (também chamados de testes A/B).

 

Observe que esta escala de qualidade trabalha com dois fatores: o esforço humano necessário para a publicação de builds e a frequência de publicação. Times pouco maduros tem muita dificuldade para fazer publicações e normalmente dependem de intervenções humanas para publicar uma aplicação. Já times com maturidade alta tem o seu processo totalmente controlado por robôs, que não ficam cansados, e conseguem gerar publicações com grande frequência.

 

Recursos de Aprendizado

Se você deseja avançar a maturidade do seu time nesta importante prática, deixo aqui um conjunto importante de livros que são hoje referência para desenvolvedores profissionais. Os primeiros é específico sobre o processo de implantaçao e entrega contínua e conta também um excelente sítio Web com várias práticas documentadas.

Temos ainda dois outros livros sobre DevOps que mostram em contexto os processos de implantação e entrega contínua

41db4qikfil-_sx348_bo1204203200_     41x0usghmnl-_sy346_

51mcvngdt6l

 

Maturidade DevOps – Pessoas e Robôs colaborando juntos com o ChatOps

Já discutimos nesta série três dimensões da maturidade DevOps.

Iremos agora discutir um aspecto primordial na cultura DevOps, que é o aumento da comunicação e colaboração. Curiosamente, são agora os robôs (ou bots) que vem ao nosso alcance aqui para ajudar times a manter o compasso da comunicação.

Conheça o ChatOps

O ChatOps é a prática do desenvolvimento e operação orientado por conversações. Ao trazer suas ferramentas para suas conversas e usar um bot de bate-papo modificado para trabalhar com plug-ins e scripts, as equipes de desenvolvimento podem automatizar tarefas e colaborar, trabalhando melhor, mais barato e mais rápido.

Ou seja, enquanto estiver em uma sala de bate-papo, os membros da equipe podem digitar comandos que o bot do chat está configurado para executar scripts personalizados e plugins, tais como o disparo de build ou a promoção de código para um ambiente de homologação. Isto é, toda a equipe colabora em tempo real à medida que os comandos são executados.

A figura abaixo exemplifica a arquitetura básica de uma infraestrutura ChatOps.

chatops-fundamental-architecture

Da mesma forma, as ferramentas como o GitHub, Jira, Trello, VSTS, Jenkins, Puppet, entre outras, também podem ser configuradas para gerarem eventos de conversação dos bots. E com isso as ferramentas “avisam” os seres humanos sobre eventos importantes que devam ser monitorados.

Existem muitas ferramentas para realizarmos ChatOps, como por exemplo o HipChat, Flowdock e o  Campfire. Cito aqui o Slack como exemplo, ferramenta para chat entre seres humanos e robôs. Você pode imaginar ao usá-la que ela é similar ao Skype ou GoogleTalk, mas ela vai muito além. Por contar das integrações diversas com muitas ferramentas, ela permite  que times interajam com ela através de comandos para enviar ou receber notificações de ferramentas como o VSTS, Docker, Ansible ou Puppet.  Um exemplo simplista é mostrado na figura abaixo.

15-slash-command-example

E existe também a possibilidade de você integrar qualquer ferramenta nativa que possua na sua empresa através de ferramentas para o desenvolvimento de ChatOps. Um artigo com 12 frameworks da Nordic API fornece algumas boas opções para isso.

Um Modelo de Maturidade para Automação da Comunicação

Com esta definição de ChatOps, vamos caminhar em direção a um modelo de maturidade de infraestrutura como código

  1. Maturidade 1 – Inicial – Aqui não existe automação da comunicação. As ferramentas operam de forma silenciosa e também não aceitam comandos através de ferramentas de linha de comando e ferramentas de chats. O conceito de bots é desconhecido ou ignorado pelos times.
  2. Maturidade 2 – Consciente –  Aqui os primeiros experimentos de automação começam a acontecer. Neste nível, o time começa a usar integradores de uso trivial como IFTTT e o Zapier para fazer ferramentas como o Trello e JIRA conversarem com ferramentas de chats como o Slack ou HipChat.
  3. Maturidade 3 – Gerenciado – Aqui a automação da conversação ganha escala e existe forte comunicação das ferramentas de ciclo de vida com as ferramentas de chat nos pontos críticos dos processos. Além disso, os times começam a experimentar também o envio de comandos automatizados nas ferramentas de Chats para disparar processos automatizados de build, release e operação, entre outros. É esperado neste nível que todo o time de desenvolvimento passe a usar esta infraestrutura de comunicação.
  4. Maturidade 4 – Avançado – Neste nível, todo o ciclo de vida do desenvolvimento e operação de um produto está automatizado por conversações, seja dos humanos para as ferramentas quanto vice-versa. Neste nível, até produtos nativos foram personalizados e integrados na automação da comunicação com frameworks ChatOps. Aqui as equipes de infraestrutura também se sentem confortáveis para usar esta abordagem de comunicação.
  5. Maturidade 5 – Melhoria Contínua – Aqui existe excelência na comunicação entre humanos e máquinas e a sintaxe dos comandos é estendida para suportar conversações mais sofisticadas, até mesmo com uso de recursos de processamento de linguagem natural (NLP). O processo é continuamente aperfeiçoado e todo o time participa do processo do enriquecimento da aplicação. Os times de desenvolvimento e operações controlam o seu ambiente de forma muito mais ágil que times convencionais.

 

Recursos de Aprendizado

Alguns livros a respeito são indicados abaixo. O primeiro é uma introdução leve ao tema para os mais apressados. O segundo dá um tratamento um pouco mais extenso ao tema e o terceiro trata de aspectos mais avançados para aqueles que precisam criar e manter bots.

captura-de-tela-2016-12-19-as-19-42-46         captura-de-tela-2016-12-19-as-19-41-49

captura-de-tela-2016-12-19-as-19-35-38

O segundo livro está temporariamente disponível para download a partir do seguinte sítio.

Finalmente, recomendo também este vídeo de 36 minutos que conta a história do ChatOps no GitHub, organização que originalmente cunhou este termo.


E você, já conversou com um robô? Compartilhe aqui as suas experiência com ChatOps no mundo DevOps.

captura-de-tela-2016-12-19-as-19-45-47

 

Maturidade DevOps – Infraestrutura como Código

Conversando com uma pessoa que trabalha em uma grande empresa pública há alguns meses, ouvi o seguinte relato.

“Meu time precisava de um ambiente para a homologação do nosso produto, que já estava com um atraso considerável. Entretanto, ouvi da nossa infraestrutura que a requisição do ambiente de homologação demoraria algumas semanas. A partir deste momento, toda uma cadeia de estresses se estabeleceu de lado a lado, com pressões diversas de pessoas do desenvolvimento e respostas áridas do time de operações. E no final das contas, o nosso time precisou esperar 3 semanas para ter um ambiente liberado. E isso somente tornou o nosso projeto, que já estava ruim, em um pesadelo vivo”, – Gestor Irritado com a sua infraestrutura do século XX

Por mais estranha que esta história pareça, ela é ainda comum nas empresas que visito e nas empresas de meus colegas de TI. E, sim, algo está errado com isso. Com os avanços das últimas duas décadas nas tecnologias de virtualização e conteinerização, a engenharia de automação de infraestrutura pode emergir como uma disciplina.

Infraestrutura Programável

A Infraestrutura como código, ou infraestrutura programável, significa escrever código (que pode ser feito usando um linguagem de alto nível ou qualquer linguagem descritiva) para gerenciar configurações e automatizar o provisionamento da infraestrutura e implantações. Isso não é simplesmente escrever um scripts que sobe e roda uma máquina virtual, mas envolve também o uso de práticas de desenvolvimento de software testadas e comprovadas que já estão sendo usadas no desenvolvimento de aplicativos. Em suma, isso significa que você escreve código para provisionar e gerenciar seu servidor, além de automatizar processos que rodam neste servidor.

Observe o seguinte código abaixo, que pode ser executado no Windows, Linux ou Mac OS/X com uma ferramenta de provisionamento chamada Ansible.

- hosts: server
  sudo: yes
  sudo_user: root

  tasks:

  - name: Instala mysql-server
    apt: name=mysql-server state=present update_cache=yes

  - name: Instala dependencias
    apt: name=python-mysqldb state=present

  - name: Verifica se o mysql está rodando 
    service: name=mysql state=started

  - name: Criar usuario com os privilegios apropriados
    mysql_user: login_user=root login_password="" name={{ mysql_user }} password={{ mysql_password }} priv=*.*:ALL host=% state=present

  - name: Create base de dados AloMundo
    mysql_db: name=alo_mundo state=present

  - name: Copia o dump do SQL para a máquina remota
    copy: src=dumpAloMundo.sql.bz2 dest=/tmp

  - name: Restaura o dump no banco de dados AloMundo
    mysql_db: name=alo_mundo state=import target=/tmp/dump.sql.bz2

Este script (chamado de PlayBook no Ansible) instala o mysql-server na máquina remota (servidor), garante que o mysql está em execução, cria um usuário com a senha, cria o banco de dados alo_mundo, copia um dump sql para a máquina remota e o restaura no banco de dados destino.

Considere agora este exemplo, com o uso da ferramenta Docker.

  
docker pull microsoft/mssql-server-2016-express-window
docker run -d -p 1433:1433 
        -- env sa_password=senha 
        -- isolation=hyperv microsoft/mssql-server-2016-express-windows

Este script baixa um contêiner Docker de um ambiente remoto com um Windows e Microsoft SQL Server e o roda na porta 1433. E este contêiner pode ser rodado em um sistema operacional nativo diferente.

Observe que nos scripts acima você pode eliminar muito trabalho manual e permitir que o provisionamento de ambientes, instalação de softwares, configurações destes software e disparo de servidores seja todo automatizado em scripts.

Nos ambientes mais sistematizados e que requerem práticas ITIL podemos manter toda a governança necessária para o controle da infraestrutura. Ao mesmo tempo, eliminaremos o tedioso e lento trabalho manual que gera filas, atrasos e estresses para os times de TI.

Com esta definição em mãos, vamos caminhar em direção a um modelo de maturidade de infraestrutura como código

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de configuração e uso de scripts de provisionamento de ambientes. Todo o trabalho de preparação de ambientes é realizado diretamente sobre hardwares reais e isso é sempre repetido para cada nova requisição realizada para o time de infraestrutura. Nesta maturidade, os tempos de atendimento são longos e existe estresse frequente entre o time de desenvolvimento e o time de operações.
  2. Maturidade 2 – Consciente –  Aqui a cultura de virtualização começa a ser experimentada. Os times de operações adotam tecnologias como o Oracle VirtualBox, VMWare, Windows Hypervisor e similares para facilitar o trabalho de criação e configuração das máquinas. Alguns trabalhos são operacionalizados com scripts, mas o trabalho manual é ainda dominante e ainda gera tempos altos de atendimento das requisições.
  3. Maturidade 3 – Gerenciado – Aqui entram em cena ferramentas como Docker, Ansible e Puppet para tornar o trabalho de provisionamento, instalação e configuração de ambientes totalmente automatizados. Os scripts de provisionamento começam a ser escritos e organizados em repositórios de código. Com isso o atendimento de requisições de criação de ambientes é facilitado com tempos de atendimento reduzidos.
  4. Maturidade 4 – Avançado – Neste nível, os scripts são governados e podem ser distribuídos para os times de desenvolvimento para estabelecer ambientes self-service. Temos também o provisionamento dos ambientes de produção (Release Management) completamente controlados por máquinas e com mínima interferência humana. Para isso, são estabelecidos ambientes de nuvens privadas ou públicas para facilitar a implementação de políticas de escalabilidade e alocação de recursos em modelos de pagamento pelo uso. O efeito na redução do trabalho manual nos times de operações é notável.
  5. Maturidade 5 – Melhoria Contínua – Neste nível praticamente todo o trabalho de infraestrutura é gerido por código fonte e ferramentas de provisionamento. Máquinas virtuais, bancos de dados, servidores de aplicação, servidores Web e até mesmo redes (SDN) são configuradas por código fonte. O “hardware” se torna software.

 

Recursos de Aprendizado

Para quem nunca teve contato com a prática da InfraEstrutura como Código, isto pode parecer ficção. Felizmente, esta prática já é realidade em muitas empresas do Brasil. E ela pode ser operacionalizada por ferramentas gratuitas também, na sua empresa inclusive.

Deixo aqui alguns livros a respeito para o interessado em melhorar a gestão da sua infraestrutura e trazê-la para o século XXI. O primeiro explica a prática do IaC em detalhes os três outros livros apresenta ferramentas muito legais para operacionalizar esta prática.

51kktpbssjl    51otkrbt71l-_sx356_bo1204203200_

51piynh5ppl    51mweljjc4l


E como está a prática da infraestrutura na sua empresa? Já no século XXI ou ainda preso em algum túnel do tempo no século XX?

Se você não leu os dois primeiros artigos desta séria de Maturidade DevOps, deixo aqui os links:

Parte 1 – Maturidade DevOps – Qualidade de Código
Parte 2 – Maturidade DevOps – Gestão de Builds e Integração Contínua

 

Maturidade em Práticas DevOps

O termo DevOps se refere a uma coleção de práticas de engenharia de software e  infraestrutura para habilitar times de desenvolvimento, qualidade e operações a entregar e manter software com maior velocidade, qualidade e robustez. Ao mesmo tempo, pode parecer difícil começar uma iniciativa DevOps.  Por onde começar?  Quem devemos envolver? E o que fazer primeiro?

Embora possam existir muitas respostas (corretas e incorretas) para as perguntas acima, uma verdade universal é que isso depende do contexto e maturidade de cada time que esteja implementando as práticas DevOps.

Uma abordagem útil é a realização de um diagnóstico de maturidade em práticas DevOps, que  permite revelar:

  • Quais os pontos fracos e fortes ao longo de cada prática DevOps;
  • Quais as lacunas existentes frente a objetivos estratégicos das áreas de desenvolvimento e operações;
  • Benchmarks de referências entre times, áreas ou organizações;
  • Expectativas com o corpo gestor e diretor da organização;
  • Balizar a empresa para uma futura iniciativa de aumento de maturidade DevOps

Práticas DevOps

Não devemos pensar no DevOps como um movimento binário, mas como uma coleção de práticas básicas e avançadas, cada qual com uma escala de maturidade. Por exemplo, a prática da Qualidade de Código pode ser avaliada isoladamente dentro de um modelo de maturidade.

Como existem diversas práticas DevOps, uma visão simples para avaliar maturidade global ao longo dessas práticas é o uso de um gráfico radial, conforme mostrado na figura abaixo para duas empresas fictícias ABC e XYZ.

captura-de-tela-2016-12-13-as-00-00-32

Cada prática possui um valor entre 1 e 5, que pode ser descrita universalmente da seguinte forma:

  • Maturidade 1 – Inicial – Ausência da prática ou iniciativas ad hoc realizadas isoladamente por algumas pessoas.
  • Maturidade 2 – Consciente –  Prática embrionária no time ou organização. Resultados iniciais e ainda inconsistentes.
  • Maturidade 3 – Gerenciado –  Prática sistematizada pelo time ou organização. Resultados de negócio começam a se tornar visíveis pelo corpo gestor.
  • Maturidade 4 – Avançado –  Prática otimizada pelo time e que se torna parte da cultura da organização. Resultados de negócio sempre visíveis pelo corpo gestor.
  • Maturidade 5 – Melhoria Contínua – Prática em melhoria contínua. Time possui excelência na realização da prática, que foi complementarmente assimilada na cultura da organização.

Um exemplo de avaliação de maturidade –  Prática de Qualidade de Código

Vamos considerar a prática de qualidade de código e colocá-la nesta escala.

  • Maturidade 1 – Inicial – Aqui o time não possui padrões de codificação. O código não é limpo e os codificadores não são limpos. As consequências são funções e métodos com centenas ou milhares de linhas de código, acoplamento excessivo de código, variáveis globais em excesso, códigos duplicados, alta complexidade ciclomática e muitos outros code smells documentados na literatura.
  • Maturidade 2 – Consciente –  Aqui o time possui um padrão estabelecido de codificação. Provavelmente todos já personalizaram este padrão nos seus ambientes (Eclipse, Visual Studio, Web Storm) e usam suas IDEs para garantir conformidade ao padrão. Provavelmente existe também o conceito de revisão por pares para garantir que a cultura do padrão seja seguida na organização. O conceito de débito técnico começa a ser estabelecido.
  • Maturidade 3 – Gerenciado –  Neste nível a revisão por pares começa a ser automatizada, como por exemplo pelo uso de Pull Requests em ferramentas como o Git. Além disso, a liderança técnica do time programa robôs de integração noturna para verificar a qualidade do código e publicar painéis de qualidade contínua. Ferramentas como o SonarQube ou similares começam a ser usadas para comunicar os problemas de forma executiva e gerenciável e monitorar o débito técnico.
  • Maturidade 4 – Avançado –  Aqui o time incorpora atributos não-funcionais como segurança, performance, internacionalização ou acessibilidade na sua avaliação de código. Os relatórios de qualidade são contínuos e com excelente amplitude dos aspectos funcionais e não-funcionais. O uso de ferramentas de qualidade se torna prática comum e desenvolvedores estabelecem “competições do bem” para premiar os desenvolvedores mais limpos.
  • Maturidade 5 – Melhoria Contínua – A prática aqui ganha excelência e o nível é tão avançado que ela pode ser incorporada aos commits de código pelo padrão de SCM Gated Commit. Atém disso, os times aceitam e resolvem os problemas em base diária o débito técnico é pequeno ou é reduzido progressivamente ao longo do tempo.

Recursos de Aprendizado de Qualidade de Código

Se faz sentido para você e o seu time melhorar a qualidade de código no seu time, recomendamos alguns livros clássicos a respeito.

51evx6wfynl     41cqy3lxbwl

captura-de-tela-2016-12-13-as-09-48-2251alcwaoayl-_sx352_bo1204203200_

E se você ainda não tem acesso a estes livros, deixamos aqui alguns sítios com conteúdo de muito valor sobre o tema:


Iremos, ao longo de sete outros posts, descrever como avaliar a sua maturidade para as seguintes práticas:

  • Configuração como código (Infraestrutura como Código)
  • Gestão de Builds (Continuous Integration)
  • Gestão de Releases (Continuous Delivery)
  • Gestão de Testes
  • Testes de Carga, Estresse e Injeção de Falhas
  • Gestão de Configuração
  • Monitoração de Aplicações.

E o seu time, como está na maturidade de qualidade de código? Que práticas você está experimentando para melhorá-la com o seu time. Deixe aqui o seu comentário.

100 Ferramentas para Acelerar a sua Iniciativa DevOps

Fizemos aqui neste blog uma introdução ao pensamento DevOps, o seu valor de negócio e 20 práticas básicas e avançadas. Caso ainda não tenha tido oportunidade de lê-las, sugiro a leitura para ter o contexto do uso das ferramentas aqui propostas.

E é de vital importância lembrar que iniciativas DevOps são ancoradas em três Ps (Pessoas, Práticas e Produtos), nesta particular ordem. Ou seja, não faz nenhum sentido implantar alguma ferramenta muito legal na sua TI se a cultura e a prática não foi trabalhada anteriormente. 

Aviso fornecido e então vamos direto para as ferramentas, separadas por categoria.

1. Ferramentas para aumento da comunicação e orquestração de atividade

A cultura DevOps requer aumento da comunicação entre os times de desenvolvimento, qualidade e operação. Ela também requer um ambiente centralizado para a operação de ferramentas do ciclo de automação de práticas DevOps. E para suportar estas práticas existem ferramentas DevOps específicas para aumento da colaboração entre times.

O IBM Jazz, ServiceNow e o Visual Studio Team Services são exemplos particularamente interessantes neste sentido, buscando fornecer um fluxo automatizado para o ciclo de vida de práticas DevOps. O Slack e HipChat permitem integrar o conceito de conversas entre pessoas e grupos com as tarefas de automação feita via bots. Isso cria uma experiência simples e direta para reforçar os processos e práticas DevOps dentro de um time.

Estas e outras ferramentas são listadas a seguir:

  • Slack
  • HipChat
  • ServiceNow
  • IBM Jazz
  • Microsoft Visual Studio Team Services (VSTS)
  • Microsoft TFS (VSTS que você roda na sua própria infraestrutura)
  • Trello
  • Atlassian Jira
  • Pivotal Tracker

2. Ferramentas de Análise de código fonte

A cultura DevOps requer que desenvolvedores escrevam código de qualidade. Nos últimos anos, foi possível quantificar o que é qualidade de código de forma prática. Termos outrora vagos como complexidade ciclomática, modularidade, coesão alta e acoplamento fraco se tornaram métricas acionáveis em ferramentas simples como o Visual Studio Code Review e o SonarQube. Esta última tem suporte para mais de 20 linguagens e se popularizou nos últimos anos na comunidade de TI. Além disso, práticas de refatoração em tempo de desenvolvimento se tornaram simples também com a IDE JetBrains IntelliJ, JetBrains Resharper para o Visual Studio, Eclipse IDE ou Microsoft Visual Studio Code. E ferramentas como o Git suportam nativamente o conceito de Pull Requests, que simplificam a revisão por pares entre desenvolvedores.

A recomendação é que você inclua alguma das  ferramentas abaixo apontadas no ciclo de desenvolvimento e usem a automação para emitir avisos, defeitos ou até mesmo impedirem o checkin de códigos em casos extremos.

  • Microsoft Visual Studio 2015
  • Microsoft VSCode
  • JetBrains InteliiJ
  • JetBrains Resharper
  • Eclipse IDE
  • SonarQube
  • Git Pull Requests

3. Ferramentas de Gerência de Código Fonte

É impossível trabalhar com a cultura DevOps sem gerir apropriadamente o código fonte. E aqui estamos falando de ferramentas como o Subversion (SVN), Microsoft TFVC (Team Foundation Version Control), Mercurial ou Git. As duas primeiras operam de forma centralizada com um servidor de código, enquanto as duas últimas operam de forma distribuída. Em um SCM distribuído, existe um clone de cada repositório em cada máquina que tenha uma cópia do repositório de código. Em linhas gerais, as ferramentas de SCM distribuídos são conceitualmente melhores pois facilitam a gestão de troncos, automação de política e tem performance melhor que ferramentas de SCM centralizados. O Git, que foi popularizado a partir da experiência da comunidade Linux em manter de forma distribuída o desenvolvimento do seu kernel, se tornou muito popular no Brasil nos últimos anos. Se possível na sua realidade opere um SCM distribuído, seja ele Git ou Mercurial.

Ao escolher um SCM, seja ele distribuído ou centralizado, é importante decidir se ele irá operar em ambiente local ou ambiente de nuvem. O GitHub, BitBucket e o Gitlab são provedores de nuvem populares sobre os ambientes Git e Mercurial. Eles operam com planos sem custo de aquisição com funcionalidades e espaços limitados, mas permitem escalar para espaços maiores e mais funcionalidades com custos pequenos de entrada. Embora alguns gestores ainda temam as nuvens, observamos que a experiência de uso de ambientes de nuvens traz maior simplicidade, maior disponibilidade e menor custo de operação dessas ferramentas.

Seguem aqui algumas recomendações de ferramentas de SCM:
  • SVN
  • Microsoft TFVC
  • Git
  • Mercurial
  • GitHub
  • GitLab
  • Atlassian BitBucket

4. Ferramentas de Automação de Builds

Estas ferramentas são o coração da prática de gestão de builds e normalmente são específicas por tecnologia. A comunidade Java EE utiliza ferramentas como Ant e Maven e mais recentemente começou a adotar o Gradle para os seus processos de build. A comunidade Microsoft usa o MSBuild, que já vem incorporado na IDE do Visual Studio, Microsoft TFS (Team Foundation Server) e também no VSTS (TFS nas nuvens). A comunidade Javascript usa com regularidade ferramentas como o Grunt e o Gulp. Outras ferramentas populares para este fim incluem o Rake (Make do Ruby), Broccoli, SBT e Packer.

Segue um resumo das ferramentas para esta prática DevOps.

  • Maven
  • Gradle
  • MSBuild • Grunt
  • Gulp
  • Rake
  • Broccoli
  • SBT
  • Packer

5. Ferramentas de Integração Contínua

As ferramentas de integração contínua dão suporte ao escalonamento e gestão do processo de builds. Elas normalmente operam sobre as ferramentas de automação de builds e permitem que o desenvolver escalone ações automatizadas de build, sejam elas noturnas (nightly builds), em certos  momentos do dia ou disparadas por commits nos códigos (prática de continuous integration). Elas também permitem rodar outras tarefas tais como execução de suítes de testes, geração de documentação de código e abertura automatizada de defeitos.

O Jenkins é uma ferramenta sem custo de aquisição e bem popular para este tipo de processo. Ela é muito usada por desenvolvedores Java, JavaScript e LAMP. Já a comunidade Microsoft faz uso intenso do Microsoft TFS (Team Foundation Server) e vem adotando recentemente o Microsoft VSTS (Team Services). Esse último opera em nuvem e tem normalmente custo de propriedade reduzido, além de permitir a operação com times de até cinco pessoas sem nenhum custo. O VSTS permite também incorporar builds de aplicações Java, Android, iOS, Xamarin, entre outros e se tornou verdadeiramente uma ferramenta independente de ambiente Windows.

Outras ferramentas comuns para CI incluem o Atlassian Bamboo, Travis CI, IBM Rational Team Concert, Code Ship, Thought Works CruiseControl, CodeShip, TeamCity, GitLab, SolanoCI, Continuum, ContinuaCI e Shippable. Elas já fornecem ambientes de nuvens e algumas permitem você baixar o servidor para operar no seu ambiente se necessário.

Adote na sua iniciativa DevOps uma ferramenta de CI que esteja bem integrada com as suas tecnologias de código fonte e a opere em nuvens se isso não ofender as políticas de segurança da sua organização. Observamos geralmente nos preços destes produtos um custo menor de entrada e propriedade ao adotarmos infraestruturas de nuvens para a execução das práticas de automação de builds e integração contínua.

Segue aqui uma lista de ferramentas para este propósito:
  • Jenkins
  • Microsoft TFS
  • Microsoft VSTS
  • Atlassian Bamboo
  • Travis CI
  • IBM Rational Team Concert
  • Code Ship
  • Thought Works CruiseControl
  • CodeShip
  • TeamCity
  • GitLab
  • SolanoCI
  • Continuum
  • ContinuaCI
  • Shippable

6. Ferramentas de Gestão de Configuração e Provisionamento

Estas ferramentas permitem automatizar todas as suas configurações como código e também provisionar hardwares automaticamente, sendo também muito importantes para suportar releases de produtos (Release Management). Estas ferramentas são chamadas em alguns meios de CCA Tools (Continuous Configuration Automation).Em linhas gerais, elas suportam as seguintes capacidades:

  • permitem o escalonamento temporal do processo de release, que pode ser feito em base noturna (nightly release) ou ativado toda vez que um novo build estiver disponível (continuous deployment ou continuous delivery);
  • permitem escrever a configuração de hardware através de códigos de script;
  • permitem provisionar dinamicamente os ambientes de hardwares;
  • permitem copiar os builds entre os ambientes de hardware provisionados;permitem a conexão a plataformas de nuvens como Amazon EC2, Microsoft Azure, entre outras;
  • permitem configurar dinamicamente os parâmetros da aplicação copiada para os ambientes;
  • permitem estabelecer processos de aprovação antes e/ou depois das cópias dos builds;
  • permitem rodar smoke tests, gerar rótulos (labels) nos releases ou enviar notificações para os interessados no processo.
Na comunidade Microsoft, o VSTS incorporou recentemente um excelente módulo de ReleaseManagement. Ele suporta scripts de infraestrutura como código em um dialeto chamado PowerShell DSC (Desired State Configuration). Em termos simples, ele permite que o desenvolvedor especifique um hardware em um script de código DSC (que é um arquivo JSON). O ambiente VSTS cria automaticamente este ambiente de hardware no Microsoft Azure. Alé disso, o VSTS Release Management controla o fluxo de aprovações, executa as distribuições necessárias dos builds nos ambientes, realiza a configuração dos parâmetros externalizados da aplicação nos ambientes provisionados e também permite rodar testes nos ambientes de produção. Neste segmento de ferramentas estão também os maiores fornecedores de soluções e consultoria DevOps, como por exemplo as empresas Chef e Puppet Enterprises. Outras soluções comuns neste segmento incluem a Ansible, Salt, Vagrant, Terraform, Consul, CF Engine, BMC BladeLogic, BMC Release Process e Serena Release, entre outras.
Um resumo destas ferramentas é fornecido abaixo:
  • Microsoft VSTS Release Managament e Microsoft Azure
  • Chef
  • Puppet
  • Ansible
  • SaltStack
  • BMC BladeLogic
  • BMC Release Process
  • Vagrant
  • Terraform
  • Consul
  • CF Engine
  • XL Release
  • UrbanCode Release
  • Automic
  • Plutora Release
  • Serena Release
7. Ferramentas de Conteinirização
Como operar com dezenas ou centenas de máquinas virtuais para o suporte a provisionamento pode ser caro, algumas ferramentas surgiram no topo das ferramentas de virtualização para facilitar a gestão de ambientes virtualizados. Estas ferramentas são chamadas de ferramentas de conteinirização e operam permitindo que blocos de máquinas virtuais possam ser arranjados conforme necessário para criar novas configurações. Por exemplo, um time pode ter já um ambiente virtual com Oracle Database 11g, Apache Tomcat e Driver JDBC tipo 2 montado. Se um outro time precisa modificar apenas a versão do Driver JDBC para tipo 4 em um outro contexto, ele não precise recriar toda a máquina virtual do zero. Ele especifica as partes necessárias e ferramenta de conteinerizacao monta a nova máquina virtual a partir de fragmentos existentes no repositório. A ferramenta também inclui os novos fragmentos, conforme necessário. Isso gera uma tremenda economia de espaço em disco e tempo para a organização de máquinas virtuais.

O Docker é talvez a ferramenta de maior popularidade neste segmento e tem sido usado para tornar o provisionamento de hardware algo simples, barato e acionável. Outras ferramentas populares neste contexto são o Mesos, Swarm, Kubernetes e Nomad.

A lista destas ferramentas é citada a seguir:

  • Docker
  • Mesos
  • Swarm
  • Kubernetes
  • Nomad

8. Ferramenta de Gestão de Repositórios

Estas ferramentas permitem gerir os repositórios de código e bibliotecas para estabelecer ambientes controlados de desenvolvimento. Isso evita que componentes sejam introduzidos na aplicação de forma indisciplinada e através de cópia de arquivos no sistema de arquivos.

O Docker Hub é uma ferramenta neste sentido e disciplina o uso de máquinas virtuais Docker, nas nuvens ou na própria infraestrutura da empresa. No mundo Microsoft, o Nuget e o Package Management do VSTS são ferramentas usadas para este controle. Já a comunidade JavaScript e Node.JS usa o NPM (Node Package Manager). E vemos a comunidade Java usar ferramentas como o Artifactory e o Nexus para estabelecer bases controladas de bibliotecas e componentes Java.

Uma lista das ferramentas para esse propósito são listadas abaixo:

  • NPM
  • DockerHub
  • Artifactory
  • Nuget
  • Nexus

9. Ferramentas de Automação de Testes

Embora builds possam ser montados apenas com ferramentas de build management, a experiência mostra que builds requerem o uso de automação de testes para aumentar a robustez e confiabilidade do produto sendo gerado. Ou seja, as ferramentas de automação de testes são peças fundamentais no quebra-cabeças DevOps e vão de encontro ao element de testabilidade no dialeto arquitetural.

Algumas destas ferramentas incluem:

  • Automação para testes de unidade do código – JUnit, TestNG, NUnit, Visual Studio Unit Test, Jasmine, Mocha e QUnit.
  • BDD (Behaviour Driven Development) – Cucumber, CucumberJS, e SpecFlow.
  • Automação de testes funcionais – Selenium e Visual Studio Coded UI.
  • Cobertura de Código –JaCoCo e Visual Studio

A lista destas e outras ferramentas é mostrada a seguir:

  • JUnit
  • NUnit
  • TestNG
  • Visual Studio UnitTest
  • Jasmine
  • Mocha
  • QUnit
  • Cucumber
  • CucumberJS
  • SpecFlow
  • Selenium
  • Visual Studio CodedUI
  • JaCoCo

10. Ferramentas de Testes de Performance, Carga e Estresse

Em aplicações Web e móveis, onde a carga de trabalho pode variar com muita intensidade, é recomendado que usemos ferramentas de automação de teste de performance, carga de trabalho e estresse. O JMeter é uma ferramenta popular na comunidade Java, embora também possa ser usada para testar recursos Web como conexões HTTP em qualquer tecnologia. O TestNG, VSTS Web Performance e o VSTS Load Test também são outros exemplos de ferramentas para este fim.

Depois de ter estabelecimento um processo de automação de build e releases, pode ser apropriado inserir um ciclo de testes de performance e estresse no seu processo DevOps.

Uma lista de alguma destas ferramentas é mostrada abaixo:

    • Apache JMeter
    • Apache ab
    • VSTS Web Performance
    • VSTS Load Test

11. Ferramentas de Monitoração de Aplicações e Telemetria

Uma transição suave para a operação pode ser facilitada pelo uso de ferramentas de monitoração de aplicações e telemetria. Em termos simples, estas ferramentas fazem a análise dos elementos físicos dos ambientes de hardware (caixa preta), componentes da aplicação (caixa cinza) e até mesmo o comportamento do código fonte em produção (caixa branca).

A ferramenta NewRelic é um excelente exemplo neste sentido e se popularizou para a monitoração de aplicações Web. Outras ferramentas neste  sentido incluem o Kibana, DataDog, Zabbix, VSTS Application Insights, ElasticSearch e StackState.

Uma listagem destas e outras ferramentas é mostrada a seguir:

  • Kibana
  • DataDog
  • Zabbix
  • VSTS Application Insights
  • ElasticSearch
  • StackState
  • Nagios
 12. Ferramentas de Injeção de Falhas
Nesta categoria estamos falando de ferramentas que permitem injetar falhas em aplicações nos ambientes de produção, como por exemplo o Netflix Simian Army. Esta suíte227, que foi disponibilizada no GitHub, contém ferramentas utilitárias diversas, tais como:
  • Chaos Monkey – Introduz falhas aleatórias em máquinas dos ambientes de produção.
  • Latency Monkey – Introduz demoras artificiais nas comunicações RESTful para simular degradação do serviço e medir se as aplicações clientes respondem apropriadamente.
  • Conformity Monkey – Encontra instâncias que não estão aderentes a melhores práticas e as desligam. Por exemplo, uma melhor prática poderia ser que toda instância deveria pertencer a grupo de escala (auto-scale) no ambiente AWS EC2 da Amazon. Se uma instância é encontrada e não obedece a esta política, ela é terminada.
  • Doctor Monkey – Encontra instâncias que não estejam saudáveis e as desligam. Por exemplo, um sinal de falha na saúde é a CPU operar acima de 70% por mais de 1 hora. Se uma instância é encontrada em um estado não saudável, ela é terminada.
  • Janitor Monkey – Busca e limpa recursos não usados nos ambientes de produção.
  • Security Monkey – Busca vulnerabilidades em máquinas e desliga as instâncias que estejam ofedendo as políticas de segurança.
  • 10-18 Monkey – Detecta problemas de configuração (i10n e 18n) em instâncias que servem a múltiplas regiões geográficas.
  • Chaos Kong – Remove uma região inteira de disponibilidade da Amazon do ambiente de produção.

 13. Plataformas de Nuvens

As plataformas de nuvens possuem um papel importante no ciclo DevOps. Sejam públicas ou privadas, elas permitem tratar a infraestrutura e redes como código e facilitam sobremaneira os processos de gestão de releases. A Amazon WebServices talvez seja o maior expoente deste segmento, com uma rica coleção de serviços de IAAS, PAAS e SAAS para suportar o desenvolvimento e operação de aplicações. Outras soluções populares incluem o Microsoft Azure, RackSpace, Digital Ocean e Google Cloud Platform.

Essas e outras ferramentas são listadas a seguir:

    • Amazon AWS
    • Microsoft Azure
    • RackSpace
    • DigitalOcean
    • Google Cloud Platform

Fechamos o artigo com as famosas leis da automação do Bil Gates, antes que você corra para implantar todas as ferramentas citadas neste post na sua empresa.  🙂

“A primeira lei de qualquer tecnologia é que a automação de um processo eficiente irá aumentar a sua eficiência”, Bill Gates

“A segunda lei de qualquer tecnologia é que a automação de um processo ineficiente irá aumentar a sua ineficiência”,  Bill Gates”

E você, que ferramentas está usando para acelerar o DevOps na sua organização? Compartilhe as suas experiências aqui conosco.