O que diabos é DevOps?

Uma breve História do Tempo

Para entender o DevOps, precisamos viajar no tempo até a velhice, quando não havia nada além de programadores.

Como o Tao nos ensina:

Os programadores de antigamente eram misteriosos e profundos. Não podemos entender seus pensamentos, então tudo o que fazemos é descrever sua aparência:

• Consciente, como uma raposa cruzando a água
• Alerta, como um general no campo de batalha
• Gentil, como uma anfitriã cumprimentando seus convidados
• Simples, como blocos de madeira não esculpidos
• Opaco, como piscinas negras em cavernas escuras

O programador deu origem à linguagem de máquina. A linguagem de máquina deu origem ao montador. O montador deu origem ao compilador. Agora existem milhares de idiomas. Cada linguagem tem seu propósito, por mais humilde que seja. Cada idioma expressa o Yin e Yang do software. Cada idioma tem seu lugar dentro do software.

Na época, os escritórios de desenvolvimento de software eram principalmente chamados de laboratórios, e os programadores eram cientistas. Para criar um bom aplicativo, os programadores precisavam entender completamente o problema que o aplicativo estava resolvendo. Eles precisavam saber onde o aplicativo seria usado e que tipo de sistema o executaria. Em essência, os programadores sabiam tudo sobre seu aplicativo, desde a especificação, passando pelo desenvolvimento, até a implantação e o suporte.

E então a natureza humana entrou em ação, e começamos a pedir mais. Mais velocidade, mais recursos, mais usuários, mais tudo.

Sendo criaturas modestas, humildes e pacíficas, os programadores tinham muito pouca chance de sobreviver a essa explosão de usuários carentes sempre pedindo mais. A melhor chance de prevalecer era começar a evoluir em direções diferentes e criar castas. Logo, os programadores foram extintos como antepassados ​​de novas raças chamadas desenvolvedores, engenheiros de software, administradores de rede, desenvolvedores de banco de dados, desenvolvedores web, arquitetos de sistemas, engenheiros de controle de qualidade e muitos mais. Evoluir rapidamente e se adaptar aos desafios do mundo exterior passou a fazer parte do seu DNA. Nova casta pode evoluir em questão de semanas. Desenvolvedores da Web se tornaram desenvolvedores de back-end, desenvolvedores de front-end, desenvolvedores PHP, desenvolvedores Ruby, desenvolvedores Angular... tudo estava indo para o inferno.

Logo todos esqueceram que vinham do mesmo pai, um Programador. Um cientista simples e pacífico que só queria tornar o mundo um lugar melhor. Eles começaram a brigar entre si, alegando que cada um deles é verdadeiro descendente de “O Programador” e que seu sangue é mais puro que os outros.

Com o passar do tempo, eles reduziram sua interação ao mínimo e falaram um com o outro apenas quando realmente precisavam. Eles pararam de comemorar o sucesso de seus familiares distantes e, eventualmente, até pararam de enviar um cartão postal de vez em quando.

Se eles apenas pesquisassem seus sentimentos, descobririam que a centelha do Programador estava em seus corações, esperando para brilhar e trazer paz à galáxia.

Em sua corrida egoísta e egocêntrica para conquistar o mundo, os descendentes de programadores esqueceram o propósito de seu trabalho - resolver problemas para seus clientes. Os clientes começaram a sentir a dor de tal comportamento à medida que os projetos atrasavam, eram muito caros ou até falhavam.

De vez em quando, uma estrela brilhante brilhava e alguém se inspirava para tentar fazer as pazes entre os descendentes. Eles inventaram a Cachoeira. Essa foi uma ideia brilhante, pois utilizou o fato de que diferentes grupos de desenvolvedores se comunicavam apenas quando necessário. Quando um grupo terminava sua parte do trabalho, ele se comunicava com o próximo grupo para enviar o trabalho ao longo do processo e nunca mais olhava para trás.

Isso funcionou por um tempo, mas como sempre, os humanos (Clientes) queriam mais novamente. Eles queriam participar mais ativamente de todo o processo de criação de software, dar sua opinião com mais frequência e pedir mudanças mesmo quando já era tarde demais.

Projetos de software tornaram-se tão propensos a falhas que foram aceitos como um padrão da indústria. As estatísticas mostraram que mais de 50% dos projetos estavam falhando e parece que não havia nada a ser feito sobre isso (ZDNet, CNet)

Cada geração teve alguns indivíduos de mente aberta que sabiam que todos esses grupos de desenvolvedores precisam encontrar uma maneira de trabalhar juntos, se comunicar e ser flexíveis para garantir que seus clientes recebam a melhor solução possível. Há vestígios dessas tentativas já em 1957, por colegas do grande John Von Neumann. No entanto, tivemos que esperar até o início de 2001 para começar a revolução, quando uma dúzia suja criou um Manifesto Ágil.

O Manifesto Ágil é baseado em doze princípios:

1. Satisfação do cliente pela entrega antecipada e contínua de software valioso
2. Bem-vindo à mudança de requisitos, mesmo em desenvolvimento tardio
3. O software em funcionamento é entregue com frequência (semanas em vez de meses)
4. Cooperação estreita e diária entre empresários e desenvolvedores
5. Os projetos são construídos em torno de indivíduos motivados, em quem se deve confiar
6. A conversa cara a cara é a melhor forma de comunicação (co-location)
7. Software funcionando é a principal medida de progresso
8. Desenvolvimento sustentável, capaz de manter um ritmo constante
9. Atenção contínua à excelência técnica e bom design
10. Simplicidade - a arte de maximizar a quantidade de trabalho não feito - é essencial
11. Equipes auto-organizadas
12. Adaptação regular às circunstâncias em mudança

O manifesto ágil foi o primeiro grande passo para trazer paz à Galáxia e restaurar o equilíbrio da Força. Pela primeira vez em muito tempo, conectar todas as partes interessadas no processo de desenvolvimento de software se baseava tanto de forma cultural e “humana”, quanto de forma processual e mecanizada. As pessoas começaram a conversar umas com as outras, a se encontrar regularmente e a trocar ideias e comentários o tempo todo. Eles perceberam que têm muito mais em comum do que pensavam, e os clientes passaram a fazer parte da equipe, não apenas algum fator externo que era esperado para enviar o dinheiro e não fazer perguntas.

Ainda havia alguns obstáculos a superar, mas o futuro parecia mais brilhante do que nunca. Ser ágil significa estar aberto e disposto a se adaptar às mudanças constantes. No entanto, com tantas mudanças, é difícil manter o foco no objetivo final e na entrega. E foi assim que o Lean Software Development ganhou vida.

Viciados em LSD (trocadilho intencional) e correndo o risco de serem exilados e párias, alguns dos descendentes procuraram soluções fora de sua casta e da indústria de software. Eles encontraram a salvação nas obras de um grande fabricante de automóveis. O Sistema Toyota de Produção era incrível em sua simplicidade e era tão óbvio que sua manufatura enxuta pode ser facilmente aplicada ao desenvolvimento de software.

Existem 7 princípios do lean:

1. Eliminar desperdício
2. Construir qualidade em
3. Criar conhecimento (amplificar o aprendizado)
4. Adiar Compromisso (Decidir o mais tarde possível)
5. Entregue o mais rápido possível
6. Respeitar as pessoas (empoderar a equipe)
7. Otimize o Todo

Somados ao Agile, os princípios Lean apoiaram a mentalidade e o foco em fazer as coisas certas, sendo flexíveis durante todo o processo.

Uma vez que o Agile e o Lean foram adotados pelas equipes de desenvolvimento de software, foi preciso apenas mais um passo para aplicar todo o conjunto de princípios à TI como um todo - o que finalmente nos trouxe ao DevOps!

Entre no DevOps - Rodovia de três pistas

A visão antiga das equipes de desenvolvimento de software incluía analistas de negócios, arquitetos de sistema, desenvolvedores front-end, desenvolvedores back-end, testadores e assim por diante. A otimização do processo de desenvolvimento de software, incluindo princípios ágeis e enxutos, foi principalmente focada nisso. Uma vez que o aplicativo estava “pronto para produção”, ele foi enviado para “Operações”, incluindo engenheiros de sistemas, engenheiros de lançamento, DBAs, engenheiros de rede, profissionais de segurança, etc. A remoção da grande muralha entre Dev e Ops é a principal força motriz do DevOps .

DevOps é o resultado da implementação de princípios lean em todo o fluxo de valor de TI. O fluxo de valor de TI estende o desenvolvimento para a produção, combinando todos os 'parentes distantes' que descenderam do programador original.

A melhor explicação das soluções de DevOps é dada por Gene Kim, e se você ainda não leu o Projeto Phoenix, sugiro que reserve um tempo e o faça.

Você não deve contratar um engenheiro de DevOps e DevOps não deve ser um novo departamento em sua TI. DevOps é uma cultura, uma mentalidade e faz parte da TI como um todo. Não há ferramentas que tornem sua TI uma organização DevOps , e nenhum nível de automação capacitará suas equipes a entregar o máximo valor aos seus clientes.

DevOps é geralmente referido como método de três vias, mas eu os vejo como três pistas da mesma rodovia. Você começa na pista um, então você acelera e muda para a pista dois, e eventualmente você está acelerando na terceira pista.

• Pista um - O desempenho do sistema como um todo é o ponto focal principal e é enfatizado sobre o desempenho de qualquer elemento individual do sistema

• Faixa dois - Certifique-se de que haja um loop de feedback constante enviado a montante e não ignorado

• Pista três - Cultive experimentos, melhoria constante e falhe rápido

Pista um - Acelerando

Compreender a importância de todo o sistema e priorizar os itens de trabalho corretamente é a primeira coisa que uma organização de TI precisa aprender ao adotar os princípios de DevOps. Ninguém no fluxo de valor de TI pode criar um gargalo e reduzir o fluxo de trabalho.

Garantir um fluxo de trabalho ininterrupto é o objetivo final para todos os incluídos no processo. Independentemente do papel que uma pessoa ou equipe tenha, é imperativo que eles busquem alcançar uma compreensão profunda do sistema. Adotar essa forma de pensar tem um impacto direto na qualidade, pois os defeitos nunca são enviados para baixo porque causariam gargalos.

Certificar-se de que o trabalho não está parando não é suficiente. Uma organização produtiva deve sempre buscar aumentar o fluxo. Existem inúmeras metodologias para aumentar o fluxo. Você pode encontrar uma solução em Teoria das Restrições, Seis Sigma, Lean ou Sistema Toyota de Produção. Sinta-se à vontade para escolher qualquer um deles, criar o seu próprio ou combiná-los.

Os princípios de DevOps não se importam com a equipe a que você pertence, se você for um System Architect, DBA, QA ou administrador de rede. As mesmas regras se aplicam a todos, e espera-se que todos sigam dois princípios simples:

• Mantenha o fluxo do sistema ininterrupto
• Aumente e otimize o fluxo de trabalho em todos os momentos

Pista dois - Prepare-se

O fluxo ininterrupto do sistema é unidirecional e espera-se que vá do desenvolvimento às operações. Em um mundo ideal, isso significa que o software é criado rapidamente com alta qualidade, implantado em produção e agregando valor aos clientes.

No entanto, DevOps não é Utopia e, se a entrega unidirecional fosse possível, o método em cascata seria suficiente. Avaliar as entregas e comunicar o fluxo é muito importante para garantir a qualidade. O primeiro canal de comunicação “upstream” que deve ser implementado é Ops to Dev.

Dar um high-five para si mesmo é fácil, mas pedir feedback e dar feedback é a maneira de ver a imagem real. É imperativo que cada pequeno passo downstream seja seguido por uma confirmação upstream instantânea.

Não importa como você estabelece o ciclo de feedback. Você pode convidar desenvolvedores para participar de reuniões da equipe de suporte ou trazer o administrador da rede para o planejamento semanal do sprint. Enquanto seu feedback estiver em vigor e os comentários forem coletados e tratados, sua organização estará acelerando na estrada do DevOps.

Pista três - Warp 10

A via rápida DevOps não é para mentes fracas. Para entrar no caminho rápido do DevOps, sua organização deve ser madura o suficiente. Trata-se de correr riscos e aprender com o fracasso, experimentar continuamente e aceitar que a repetição e a prática são o pré-requisito para a maestria. Muitas vezes você ouvirá o termo Kata, e isso tem um motivo. O treinamento contínuo e a repetição levam à maestria porque fazem movimentos complexos se tornarem uma rotina.

Mas antes de começar a combinar movimentos, é imperativo que você domine cada passo individual primeiro.

“O que é apropriado para o Mestre não é apropriado para o noviço. Você deve entender o Tao antes de transcender a estrutura.”

DevOps Third Way/Fast Lane incluem alocar tempo para experimentos contínuos diariamente, recompensar constantemente a equipe por assumir riscos e introduzir falhas no sistema para aumentar a resiliência.

Para garantir que sua organização não implodirá ao implementar esses tipos de medidas, você deve criar ciclos de feedback frequentes entre todas as equipes, garantindo que todos os gargalos sejam claros e o fluxo do sistema seja ininterrupto.

A implementação destas medidas torna a sua organização sempre alerta e capaz de responder aos desafios de forma rápida e eficaz.

Resumo - Lista de verificação da organização DevOps

Aqui está uma lista de verificação que você pode usar para validar como o DevOps está habilitado para sua organização de TI. Por favor, sinta-se à vontade para comentar o artigo e adicionar seus próprios pontos.

• Não há muro entre a equipe de desenvolvimento e a equipe de operações. Ambos fazem parte do mesmo processo
• O trabalho que é enviado de uma equipe para outra é sempre verificado e de alta qualidade
• Não há “empilhamento” de trabalho e todos os gargalos são tratados
• A equipe de desenvolvimento não está usando o tempo de Operações para suas atividades, porque implantação e manutenção fazem parte da mesma caixa de tempo
• A equipe de desenvolvimento não entrega o código para implantação às 17h às sextas-feiras, deixando as operações para limpar seu trabalho no fim de semana
• Os ambientes de desenvolvimento são padronizados e as operações podem reproduzi-los e dimensioná-los facilmente para a produção
• A equipe de desenvolvimento pode fornecer novas versões conforme acharem apropriado e as operações podem implantá-las facilmente na produção
• Existem linhas de comunicação claras entre todas as equipes
• Todos os membros da equipe têm tempo para experimentar e trabalhar na melhoria do sistema
• Defeitos são introduzidos (ou simulados) e tratados no sistema regularmente. As lições aprendidas de cada experimento são documentadas e compartilhadas com todas as pessoas relevantes. O tratamento de incidentes é uma rotina e principalmente tratado de maneira conhecida

Conclusão

Usar ferramentas modernas de DevOps como Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS etc. não significa que você está aplicando os princípios de DevOps. DevOps é uma forma de pensar. Todos fazemos parte do mesmo processo, compartilhamos o mesmo tempo e entregamos valor juntos. Cada pessoa que participa do processo de entrega de software pode acelerar ou desacelerar todo o sistema. Um bug criado durante o desenvolvimento pode derrubar o sistema, assim como a configuração errada do firewall.

Todas as pessoas fazem parte do DevOps e, quando sua organização entender isso, as ferramentas e a pilha de tecnologia que o ajudarão a gerenciá-lo aparecerão magicamente.