Tivemos o privilégio de acompanhar nessa semana o primeiro DevOps Days Belo Horizonte. Lotação esgotada, excelentes palestras e muitas trocas de experiência. Definitivamente, o tema DevOps está nos corações e mentes de muitos profissionais de TI pelo Brasil afora.

E como boa coincidência, tivemos nesse mês a publicação do relatório State of DevOps Report 2018 do instituto de pesquisa e avaliação DevOps – o DORA. Ele trouxe nessa edição um modelo evolucionário para o aumento da sua maturidade DevOps. E esse modelo foi compilado através da análise do que milhares de empresas tem feito por todo o planeta. Faço um resumo do relatório abaixo para ajudá-lo a desenhar a sua jornada DevOps.

Estágio 0 – Construir a Base

A análise dos dados da pesquisa do estado de DevOps de 2018 revelou as práticas fundamentais empregadas pelas equipes bem-sucedidas. Essas práticas se correlacionam tão fortemente com o sucesso do DevOps que o instituo DORA recomenda que elas são essenciais em todos os estágios do desenvolvimento do DevOps. Em outras palavras, as práticas que devem ser adotadas em qualquer estágio para progredir para o próximo estágio permanecem importantes até mesmo para aquelas organizações que evoluíram mais longe em sua jornada DevOps e que já mostraram o maior sucesso.

As práticas fundamentais estão listadas abaixo:

• O monitoramento e alertas são configuráveis ​​pelas equipes que operam o serviços em produção. 
• Os padrões de implantação para a criação de aplicativos ou serviços são reutilizados.
• Os padrões de teste para a criação de aplicativos ou serviços são reutilizados.
• As equipes contribuem com melhorias nas ferramentas fornecidas por outras equipes.
• As configurações são gerenciadas por uma ferramenta de gerenciamento de configuração.

Estágio 1: Normalize a pilha de tecnologia

A maioria das organizações que usam grandes quantidades de tecnologia está lidando com muita complexidade, diminuindo seus esforços para avançar nos negócios. Portanto, não é surpreendente que os primeiros esforços em uma transformação DevOps
(ou qualquer tipo de transformação de negócios) se concentraria na redução da complexidade.

As duas práticas que definem o estágio 1 funcionam para reduzir a complexidade:
• As equipes de desenvolvimento de aplicativos usam controle de versão.
• Equipes fazem a implantação de aplicações em um conjunto padrão de sistemas operacionais.

Estágio 2: Padronize e reduza a variabilidade

No estágio 1, vemos organizações normalizando suas tecnologias
e processos. Quando chegam ao estágio 2, as organizações já começaram o processo de padronização de um conjunto de tecnologias; configurações de aplicativos separados dos dados, uso consistente de controle de versão e também um processo consistente para testes de infraestrutura e um padrão de compartilhamento de código-fonte.

No estágio 2, as organizações estão trabalhando para padronizar e reduzir a variabilidade, um tema que prevalece em todos os estágios da evolução do DevOps.

Toda organização tem variação, que pode derivar de várias causas diferentes, incluindo:
• Adoção de novas tecnologias para substituir muitas funções de tecnologias antigas. E ao mesmo tempo, as tecnologias mais antigas nunca são removidas.
• Produtos caseiros que não seguem padrões comuns do setor e não possuem interfaces comuns.
• Uma proliferação de ferramentas que se sobrepõem e não foram racionalizadas.
• Fusões e aquisições, que trazem ainda mais tecnologias legadas para casa.

No estágio 2, a reutilização de tecnologias e padrões se torna importante. Isso leva os times de Dev e  Ops a colaborar e tomar decisões de arquitetura que afetam a capacidade de implementação e testabilidade dos aplicativos. Por causa do direcionamento para esses padrões comuns, as equipes começam a inventar maneiras de aumentar a velocidade na adoção de padrões e reduzir ainda mais a variação. Isso impulsiona a inovação no nível de equipe para otimizar processos e fluxos de trabalho em torno das pilhas de tecnologia abençoadas.

Um antipadrão primário a ser observado neste estágio é que cada equipe se normalize em seus próprios padrões. Isso levará a um maior grau de variação global e é exatamente a direção errada.

Em essência, as práticas de definição para o estágio 2 são:
• Construa em um conjunto padrão de tecnologias.
• Implante em um sistema operacional padrão único. (ou em um conjunto mínimo, se um apenas não for possível)

Os principais benefícios da organização dos padrões e tecnologias de uma equipe de TI são:
• Velocidade de entrega mais rápida.
• Mais flexibilidade para a equipe de desenvolvimento trabalhar em novos aplicativos, serviços ou componentes.
• Área de superfície reduzida para vulnerabilidades de segurança.
• Menos partes móveis para manter, atualizar e aprender. E isso reduz a complexidade essencial e acidental.

Etapa 3: Expandir as práticas do DevOps por toda a TI e além

Os estágios 1 e 2 reduzem a complexidade geral da pilha de tecnologia para que as equipes possam obter resultados mais repetitivos com variação limitada. O estágio 3 é sobre a expansão das práticas de DevOps para o grupo mais amplo de equipes de TI e prestação de serviços.

No estágio 3, as práticas de DevOps se espalham para além das equipes de desenvolvimento e operações, onde primeiro criaram suas raízes. À medida que a colaboração aumenta e a organização se concentra em melhorias em torno do gerenciamento de serviços, implantação, redução de tempos de espera e minimização de aprovações, esses esforços afetam as áreas além dos departamentos de tecnologia. O compartilhamento de ferramentas, aplicativos e serviços aprimorados – assim como o conhecimento – com outras áreas funcionais da empresa agora se torna fundamental para expandir o sucesso anterior do DevOps e dimensionar o DevOps em toda a organização.

As pesquisa do instituto DORA mostraram que o estágio 3 é onde as iniciativas de DevOps mudam de pequenos grupos de sucesso em algumas equipes para uma onda que se espalha e eventualmente transforma toda a organização.

Foi também observado em achados do grupo que o Estágio 2 (reduzindo a variação
na pilha de tecnologia) e a Etapa 3 pode ocorrer em ordem direta, em ordem inversa ou ao mesmo tempo. Mas ambos precisam acontecer antes de progredir para o estágio 4 (automatizar a entrega da infraestrutura).

Ou seja, faz mais sentido concentrar-se na redução da variabilidade nos estágios iniciais, de modo que haja menos ocorrências para gerenciar, economizando tempo e distração de sua equipe. Mas se isso não for possível porque algumas dessas coisas estão fora do seu controle, trabalhe primeiro nas coisas que você pode controlar. O mais importante é que a equipe de gerenciamento de serviços de TI e quaisquer outras equipes que dependem de serviços trabalhem juntas durante esse estágio.

As práticas definidoras no estágio 3 são:
• Os indivíduos tem autonomia para poder trabalhar sem aprovação manual de fora da equipe (ex. gerentes e áreas de negócio). E isso foi alcançado através da confiabilidade obtida na busca das práticas do estágio 2.
• Padrões de implantação para criar aplicativos e serviços são reutilizados.

Outras práticas importantes para estágio são:

• Os indivíduos conseguem fazer alterações com tempos de espera reduzidos (lead times).
• Mudanças de serviço podem ser feitas durante o horário comercial.
• Revisões pós-incidente ocorrem e os resultados são compartilhados.
• Equipes constroem código em um conjunto padrão de tecnologias.
• Equipes usam integração contínua.
• As equipes de infraestrutura usam também controle de versão.

Etapa 4: Automatizar a entrega da infraestrutura

O estágio 4 é onde as equipes de infraestrutura estão no centro da atenção. As práticas definidoras neste estágio são sobre automatizar a entrega de infraestrutura – o que muitos pensam como o início de uma iniciativa de DevOps.

Essas práticas de automação de infra-estrutura aparecem mais tarde na jornada evolucionária do que podemos esperar. Isso porque são ativadas por coisas que caracterizam estágios anteriores: normalização, redução de variáveis ​​e expansão da evolução do DevOps para além das equipes de tecnologia nos negócios. Sucesso em estabelecer esses fatores em estágios iniciais torna muito mais fácil alcançar o sucesso no Estágio 4.

E  isso não quer dizer que a automação de infraestrutura não está acontecendo em estágios anteriores. Já no Estágio 0: Construir a base, a prática de gerenciar configurações de infraestrutura com uma ferramenta de gerenciamento de configuração rapidamente se instala desde o início, quando as equipes de operações estão buscando padronizar para resolver suas próprias necessidades.

A principal diferença no estágio 4 é que o objetivo de conduzir a automação de infraestrutura nesse estágio é proporcionar maior agilidade a todo o negócio, não apenas para uma única equipe.

Embora esse estágio seja gratificante – parece que você está realmente fazendo o DevOps agora – é importante reconhecer que os estágios anteriores possibilitam a automação da infraestrutura. O instituto DORA viu organizações tentando saltar imediatamente para este
estágio sem passar pelos estágios anteriores. E o resultado é a frustração. É preciso que essas organizações demorem mais do que o esperado para fazer qualquer progresso real com a automação da infraestrutura.

As equipes de infra-estrutura nesse estágio da jornada de DevOps começam a adotar práticas de desenvolvimento ágil, como o uso de controle de versão para configuração do sistema e configurações de aplicativos, e adotam ferramentas usadas pelas equipes de desenvolvimento de aplicativos. As equipes, nesse estágio, também automatizam as configurações de políticas de segurança dentro de sua esfera de influência.

As práticas centrais para o estágio 4 são:
• As configurações do sistema são automatizadas.
• O provisionamento é automatizado. 

E algumas práticas associadas são:
• Configurações de aplicativo estão no controle de versão.
• As equipes de infraestrutura usam o controle de versão.

Estágio 5: Fornecer recursos de autoatendimento

Para passar para o Estágio 5, uma organização deve ter os seus vários departamentos comprometidos em fornecer recursos de TI como um serviço para a empresa, em vez de tratar a TI como um centro de custo que executa ordens de serviço. Esses departamentos incluem desenvolvimento, qualidade, operações, segurança, ITSM e outras áreas funcionais.

Neste último estágio da evolução do DevOps, os benefícios para a organização multiplicarem-se enormemente à medida que a colaboração bem-sucedida entre os limites funcionais se acelera.

Esses ganhos são vistos em várias áreas distintas:
• A arquitetura de aplicativos vai além da padronização de tecnologias e começa a evoluir no sentido de trabalhar e suportar a migração na nuvem, a adoção de contêineres e a proliferação de microsserviços.
• A automação da política de segurança passa de atender as necessidades de uma equipe para se tornar a linha de base de como a segurança e a conformidade são medidas em todo o departamento, ou mesmo em toda a organização. Além disso, o provisionamento automatizado avança para o provisionamento de ambientes completos para desenvolvedores, testadores e outras equipes técnicas.

Uma vez que você comece a ter sucesso em múltiplos limites funcionais, os pilares do DevOps – (CAMS) Cultura, Automação, Mensuração e Compartilhamento – tornam-se mais difundidos em toda a organização.

As duas práticas de definição para o estágio 5 são:
• Respostas a incidentes são automatizadas.
• Recursos de TI (ex. máquinas ou conteineres) estão disponíveis via autoatendimento.

As duas práticas associadas neste estágio são:
• Aplicativos de arquitetura com base nas necessidades de negócios.
• As equipes de segurança estão envolvidas no design e na implantação de tecnologia.

Resumo do relatório

Em resumo, os dados coletados pelo instituto DORA mostraram que embora existam muitos caminhos individuais por meio de uma transformação DevOps, há maneiras de atingir e dimensionar o sucesso mais rapidamente. As organizações têm uma escolha: elas podem escolher ser sistemáticas sobre como elas evoluem ou podem adotar uma abordagem mais dispersa. É claro que é possível que até mesmo uma abordagem ad-hoc funcione, mas o que foi observado nas organizações que atingiram os níveis mais altos da evolução do DevOps é que elas não chegaram lá por acaso.