DevOps para iniciantes
Tudo o que você precisa saber para começar a usar o DevOps
12 de março. 07 minutos de leitura
O que é DevOps e por que as organizações estão migrando para um “Modelo Operacional de DevOps”?
Vamos começar com duas definições, ambas de fornecedores de nuvem em hiperescala — Microsoft e Amazon:
“DevOps é a união de pessoas, processos e tecnologias para permitir a entrega contínua de valor aos clientes”. - Microsoft.com
"DevOps é a combinação de filosofias culturais, práticas e ferramentas que aumentam a capacidade de uma organização de fornecer aplicações e serviços em alta velocidade: evoluindo e melhorando produtos em um ritmo mais rápido do que as organizações que utilizam processos tradicionais de desenvolvimento de software e gerenciamento de infraestrutura. Essa velocidade permite que as organizações atendam melhor seus clientes e concorram no mercado de maneira mais eficaz”. - Amazon.com
As definições concordam em vários fatores -chave que são relevantes para o iniciante em DevOps entender -
- DevOps é “mais do que apenas ferramentas” — ele combina pessoas, cultura, processos, práticas, ferramentas e tecnologias.
- O DevOps é centrado no cliente — ele se esforça para agregar valor e atender seus clientes melhor.
- O DevOps visa melhorar o tempo de lançamento no mercado - entregando valor em “alta velocidade” (ou continuamente), mas, o que é mais importante, sem comprometer a estabilidade, disponibilidade ou segurança das suas aplicações/serviços.
Afinal, por que o DevOps é necessário?
Antes de nos aprofundarmos nessas três áreas, é importante perguntar: “Por que DevOps”?
O que havia de errado com as formas existentes de gerenciamento de Desenvolvimento e Operações (o “Dev” + “Ops” de “DevOps”) que estimulou a necessidade de mudança?
Esta também é uma pergunta importante a ser feita antes de iniciar sua própria transformação de DevOps: quais necessidades do cliente você NÃO está atendendo atualmente com seu modelo de entrega atual e você pode mensurar (quantificar) o hiato entre o que você está fornecendo atualmente e o que seus clientes precisam? Isso o ajudará a construir o "caso de negócios para DevOps" visando obter o investimento e recursos necessários para atingir suas metas de transformação de DevOps.
A resposta curta a esta pergunta é que, em muitas organizações, Dev e Ops eram silos com objetivos diferentes, linhas de reporte de gestão distintas e culturas diferentes. Isso significava que o trabalho - principalmente os lançamentos de novas aplicações - não fluía de maneira rápida e fácil das estações de trabalho do desenvolvedor para os ambientes de produção utilizando o pipeline de lançamento. As mudanças nos sistemas foram vistas como de alto risco, introduzindo bugs e levando à instabilidade e baixa disponibilidade dos sistemas de produção.
Esse cenário, por sua vez, leva à insatisfação e reclamações dos clientes. Isso resultou no fato de a área de Operações, que era incentivada em torno da estabilidade e disponibilidade, estar constantemente em conflito com a área de Desenvolvimento, que era incentivada a colocar novos recursos nas mãos dos clientes o mais rápido possível.
Esse conflito e desalinhamento se intensificaram conforme muitas equipes de desenvolvimento adotaram metodologias de desenvolvimento de software Agile e de Entrega Contínua enfatizando lançamentos menores e mais frequentes. As operações não tinham “filosofias, práticas e ferramentas culturais” para atender a essa necessidade, pelo menos não sem arriscar a estabilidade dos sistemas de produção. Consequentemente, o DevOps evoluiu para atender a essa necessidade de velocidade e estabilidade.
O que o seu modelo DevOps deve conter?
Dessa forma, considerando que o DevOps é “mais do que apenas ferramentas”, quais são os principais elementos de um “Modelo de DevOps”?
Uma estrutura popular na comunidade de DevOps é o modelo “The DevOps Handbook.ou "Manual de DevOps". Tabela 1 — O Modelo CALMS detalha os cinco elementos do modelo.
O desafio de mudar para um Modelo Operacional de DevOps, especialmente para tecnólogos do departamento de TI, é que somos ótimos na implementação da automação e ferramentas, mas temos muito menos experiência em aspectos como curadoria de uma cultura forte, análise de processos Lean ou mensuração eficaz dos resultados do cliente em vez de apenas monitorar as métricas do sistema. Isto destaca a necessidade de o pessoal de Transformação de DevOps ir além do departamento de TI para ajudar a promover a mudança. Por exemplo, o departamento de RH deveria ter pessoas com mais experiência em promover mudanças culturais. Caso a sua organização estiver envolvida na área de manufatura, você poderá encontrar uma profunda experiência na metodologia Lean em outras partes do negócio. A mudança para um modelo de DevOps não é algo que possa ser realizado pelo departamento de TI isoladamente do resto da organização.
| Modelo CALMS | |
Cultura | Uma “Cultura de DevOps” enfatiza a aceitação (não a resistência) da mudança, necessidade de colaboração dentro e entre as equipes para atingir objetivos compartilhados, fluxo livre de informações e “segurança psicológica" (“Uma crença de que o contexto [do grupo/equipe] é seguro para a tomada de riscos interpessoais - expressar ideias, perguntas, preocupações ou erros será algo bem-vindo e valorizado”). |
Automação | A automação permite que as tarefas sejam realizadas de maneira rápida e reproduzível, sem erro humano. A automação nos dá feedback sobre o sucesso ou fracasso das tarefas rapidamente, o que ajuda a apoiar a tomada de decisões. A automação pode melhorar a velocidade e eficiência de custos, enquanto reduz o retrabalho e erros. A abordagem de DevOps para automação é frequentemente descrita como uma abordagem “como código” - infraestrutura como código, configuração como código, e assim por diante, usando ferramentas como Terraforma e Fantoche. |
Lean | "Lean" é uma abordagem de manufatura que se concentra na redução de desperdícios e defeitos. O Lean analisa todo o fluxo de valor, melhorando a eficiência e eficácia. Estar ocupado não é o mesmo que agregar valor; a metodologia Lean pode ajudar a identificar trabalhos desnecessários que desperdiçam recursos. |
Mensuração | A mensuração apoia uma melhor tomada de decisões com base em provas empíricas, não em opiniões ou “intuições”. Mensurar as coisas certas dá um feedback rápido às equipes e as mantém alinhadas à meta de valor para o cliente. Esteja ciente de que a aplicação de metas pode ter consequências culturais não intencionais, ou seja, “enganar o sistema”. Quatro "Métricas de DevOps," populares defendidas pela Dra. Nicole Forsgren et al. no livro "Accelerate: The Science of Lean Software and DevOps," são Frequência de Implantação (DF), Lead time para mudanças (LTTC), Tempo médio de recuperação (MTTR) e Taxa de falhas de mudança (CFR). |
Compartilhamento | Metas compartilhadas criam um propósito comum, e experiências e lições compartilhadas apoiam o aprendizado organizacional. Não basta ter uma “cultura de compartilhamento” — devem existir mecanismos para capacitá-lo. Isso pode incluir ferramentas de colaboração como Slack ou Zoom, wikis, atividades de equipe como “post-mortems sem culpados" após grandes incidentes, sessões de treinamento do tipo “lunch & learn” ou até mesmo atividades cotidianas, como reuniões diárias de Scrum ou “programação em pares”, que facilitam o compartilhamento de informações e conhecimentos entre os membros da equipe. |
Foco no cliente e alinhamento das partes interessadas
A seguir, devemos analisar o que significa ser “focado no cliente” como parte de uma transformação de DevOps.
Para qualquer pessoa que desempenhe uma função de liderança, especialmente em grandes organizações empresariais distribuídas, a reclamação de que a “TI” não está “alinhada” com “O Negócio” é provavelmente familiar.
Muitos clientes [internos] ou usuários finais de outros departamentos consideram que a TI “não está lhes dando o que desejam ou precisam” para atender às necessidades dos seus clientes externos reais. A TI é vista como um silo separado dentro da organização mais ampla, sendo muito lenta, introspectiva e focada em “fazer coisas nerds de TI” do que em entregar valor para o cliente.
Por mais injusto que isso possa parecer para muitos no departamento de TI, basta olhar para a estrutura de muitos departamentos de TI para ver a veracidade desta afirmação. A maioria dos departamentos de TI tradicionais são organizados em torno de silos tecnológicos; por exemplo, DBAs em uma equipe, redes e comunicações em outra, infraestrutura de servidores em outra, e assim por diante. Atingir um resultado ponta a ponta para o cliente, por exemplo, o lançamento de um novo produto ou serviço, requer coordenação entre todos esses diferentes silos, o que pode ser algo caro e demorado.
O “alinhamento do produto” é parte da resposta?
Como parte da transformação do DevOps, muitas organizações estão migrando para um modelo “alinhado ao produto”, ou seja, equipes multidisciplinares que dividem os silos de TI tradicionais para se concentrarem na entrega de um produto/serviço que atenda a uma necessidade específica do cliente. Elas também são chamadas de "equipes alinhadas ao fluxo de valor" pois estão alinhadas ao fluxo de valor do cliente e podem entregar novos produtos ou recursos de produto “ponta a ponta”, desde a ideia inicial, passando pela fase de desenvolvimento, até a implantação e operações na produção. Essas equipes são “proprietárias” do seu produto, e suas métricas de sucesso devem estar alinhadas com as métricas reais do cliente, como satisfação do cliente, adoção, crescimento etc.
Acelerando a mudança
Finalmente, quando olhamos para o “tempo de lançamento no mercado” e como o DevOps pode alcançar “velocidade E estabilidade”,
Muitas organizações de TI tradicionais, afetadas por lançamentos desastrosos de produtos prejudicados pela baixa qualidade do código, testes inadequados e processos de lançamento manual propensos a erros, têm medo de mudanças. Consequentemente, elas são realizadas com pouca frequência, algumas vezes até em ciclos anuais ou trimestrais. Estes “lançamentos do tipo big bang” são, paradoxalmente, ainda mais difíceis de gerenciar e coordenar, o que aumenta o risco. Conforme discutido anteriormente, isso também leva a uma intensa frustração do “Negócio”, porque a TI é muito lenta e complicada. Por sua vez, isso leva os usuários corporativos a tentar contornar o departamento de TI... a temida “shadow IT” - produtos e serviços de TI que não estão sob o controle do departamento de TI - e isso pode representar riscos de segurança, entre outros, para o negócio e seus clientes.
Ao mesmo tempo, o apetite dos usuários por novos recursos e a impaciência em relação aos recursos prometidos há muito tempo e que ainda não foram lançados são cada vez maiores. As organizações que conseguem atender ou antecipar as necessidades dos clientes rapidamente, com pouca ou nenhuma interrupção nos serviços existentes, a um custo menor e com maior qualidade, podem ganhar participação de mercado daquelas que não conseguem fazer isso. A pesquisa de DevOps mostrou que as organizações que o adotam, especialmente aquelas que se destacam nas quatro métricas de DevOps discutidas anteriormente, podem superar suas metas em crescimento de clientes, participação de mercado e lucratividade.
Ao promover uma cultura que adota a mudança e utiliza práticas técnicas como a automação para melhorar a qualidade, reduzir erros humanos e dar feedback rápido caso algo der errado, o DevOps capacita as organizações a lançar mudanças menores com muito mais frequência e menos riscos. Muitas organizações estão lançando centenas, se não milhares, de mudanças no ambiente de produção todos os dias, com uma taxa de falha de mudanças muito baixa e um lead time para a mudança rápido. Isto encanta tanto os clientes internos quanto externos, aumenta a satisfação do cliente e inicia um “ciclo virtuoso” de melhor desempenho em cada etapa do fluxo de valor.
Boa sorte na sua jornada de DevOps!
Sobre o autor
