Close

Framework CALMS

Avalie sua capacidade e avalie o progresso em sua jornada de DevOps.

Ian Buchanan

Engenheiro Principal de Soluções


CALMS é uma estrutura que avalia a capacidade de uma empresa adotar processos de DevOps, bem como uma maneira de medir o sucesso durante uma transformação de DevOps. A sigla foi cunhada por Jez Humble, coautor de “The DevOps Handbook”, e significa Cultura, Automation, Lean, Medição e Compartilhamento.

Cultura


O DevOps não é só um processo ou uma abordagem diferente para o desenvolvimento — é uma mudança de cultura. E uma parte importante da cultura DevOps é a colaboração.

Todas as ferramentas e automação do mundo são inúteis, a menos que os profissionais de desenvolvimento e TI/Ops trabalhem juntos. Porque DevOps não resolve problemas de ferramentas. Resolve problemas humanos.

Pense em DevOps como uma evolução de equipes ágeis — a diferença é que agora as operações estão incluídas por padrão. Formar equipes orientadas por projeto para substituir equipes com base em funções é um passo na direção certa. Inclua desenvolvimento, controle de qualidade, gerenciamento de produto, design, operações, gerenciamento de projeto e qualquer outro conjunto de habilidades que o projeto exija. Em vez de ter uma equipe fazendo tudo ou contratar "profissionais de DevOps", é mais importante ter equipes com base em produtos que possam trabalhar juntas sem problemas.

Poucas coisas promovem mais a colaboração do que compartilhar um objetivo comum e um plano para chegar lá juntos. Em algumas empresas, mudar de repente para equipes com base em produtos é excessivo e precoce. Por isso, comece aos poucos. As equipes de desenvolvimento podem — e devem — convidar os membros adequados da equipe de operações para participar de sessões de planejamento, reuniões rápidas diárias e demonstrações de sprint. As equipes de operações podem convidar os principais desenvolvedores para suas reuniões. É uma maneira ágil e orgânica de acompanhar o andamento do trabalho, das ideias e das dificuldades uns dos outros.

Material relacionado

Saiba mais sobre os benefícios do DevOps

Material relacionado

Construa uma cultura de DevOps

Desafios e até emergências são testes eficazes da cultura de DevOps. Os setores de desenvolvimento, operações e atendimento ao cliente atacam o problema para resolver em equipe? Os incidentes post-mortem se concentram em melhorar os resultados para o próximo incidente em vez de apontar o dedo? Se a resposta for “sim”, temos uma boa indicação de que a empresa está abraçando uma cultura de DevOps.

As empresas mais bem-sucedidas adotaram a cultura DevOps em todos os departamentos e em todos os níveis do fluxograma. Em uma escala tão ampla, o termo “DevOps” costuma ser muito estreito e o termo não é mais necessário. Tais empresas têm canais abertos de comunicação e conversam com regularidade. Elas presumem que manter o cliente satisfeito é tanto responsabilidade do gerenciamento de produto quanto da equipe de desenvolvimento. Elas entendem que DevOps não é trabalho de apenas uma equipe. É o trabalho de todos.

Automação


Investir em automação elimina o trabalho manual repetitivo, produz processos repetíveis e cria sistemas confiáveis.

Compilação, teste, implementação e provisionamento automatizados são o ponto de partida típico para equipes que ainda não têm isso implantado. E, veja só: quer motivo melhor para desenvolvedores, testadores e operadores trabalharem juntos que criar sistemas para o benefício de todos?

Equipes novas em automação em geral começam com entrega contínua: a prática de executar cada mudança de código ao longo de uma odisseia de testes automatizados — muitas vezes facilitados por infraestrutura baseada em nuvem — depois o empacotamento de builds e sua promoção por meio de ambientes usando implementações automatizadas.

Por quê? Computadores executam testes com mais rigor e fidelidade que humanos. Esses testes detectam bugs e falhas de segurança mais cedo. E as implementações automatizadas alertam a TI/Ops sobre desvios de servidor entre ambientes, o que reduz surpresas na hora do lançamento.

Outra grande contribuição do DevOps é "configuração como código". Os desenvolvedores trabalham para criar aplicativos modulares e que possam ser combinados, porque eles são mais confiáveis e sua manutenção é mais fácil. O mesmo pensamento pode ser expandido para a infraestrutura que os hospeda, estejam eles na nuvem ou na rede da própria empresa.

"Configuração como código" e "entrega contínua" não são os únicos tipos de automação no mundo do DevOps, mas merecem menção especial porque ajudam a derrubar a barreira entre desenvolvimento e operações. E, quando o DevOps usa implementações automatizadas para enviar códigos testados com todo o cuidado para ambientes com provisionamento idêntico, "Funciona no meu computador!" vira irrelevante.

Enxuto


Quando se escuta "enxuto" no contexto de software, é normal pensar em eliminar atividades de baixo valor e avançar rápido — sendo fragmentário e ágil. Ainda mais relevantes para o DevOps são os conceitos de melhoria contínua e aceitação de falhas — que lançam as bases de uma mentalidade experimental.

Uma mentalidade de DevOps reconhece oportunidades de melhoria contínua em toda parte. Algumas são óbvias, como realizar retrospectivas regulares para que os processos da sua equipe possam melhorar. Outras são sutis, como teste A/B de diferentes abordagens de integração para novos usuários do seu produto.

Podemos agradecer o desenvolvimento agile por tornar a melhoria contínua em uma ideia dominante. Os primeiros a adotar a metodologia agile comprovaram que um produto simples nas mãos dos clientes hoje vale mais que um produto perfeito nas mãos dos clientes daqui a seis meses. Se o produto for melhorado continuamente, os clientes se manterão fiéis.

Adivinhe só: falhar é inevitável. Então você pode muito bem preparar sua equipe para absorver isso, recuperar-se e aprender com as falhas (alguns chamam isso de "ser antifrágil"). Na Atlassian, acreditamos que, se você não falha de vez em quando, não está se esforçando o bastante.

No contexto do DevOps, falhar não é um crime condenável. As equipes presumem que tudo está fadado a desandar em algum momento, assim, elas criam pensando em detecção e recuperação rápidas. Análises post-mortem focam no ponto em que o processo desandou e como torná-lo mais consistente, não em qual membro da equipe errou o código. Por quê? Porque melhoria contínua e falha andam lado a lado.

Medição


É difícil provar que nossos esforços de melhoria contínua estão de fato rendendo qualquer melhoria sem dados. Ainda bem que há muitas ferramentas e tecnologias para medir o desempenho, como o tempo que os usuários dedicam ao seu produto, se uma postagem de blog gerou alguma venda ou com que frequência alertas críticos aparecem nos seus logs.

Embora você possa medir praticamente qualquer coisa, isso não significa que precise (ou deva) medir tudo. Pegue uma página do desenvolvimento agile e comece com o básico:

Quanto tempo levou para ir do desenvolvimento à implementação?

Com que frequência erros ou falhas recorrentes acontecem?

Quanto tempo a recuperação leva depois de uma falha do sistema?

Quantas pessoas estão usando seu produto no momento?

Quantos usuários você ganhou/perdeu nesta semana?

Com uma base forte estabelecida, é mais fácil capturar métricas mais sofisticadas quanto ao uso de recursos, jornadas do cliente e acordos de nível de serviço (SLAs). As informações que você obtém vêm a calhar quando é hora de mapear o roteiro e especificar sua próxima ação importante.

Todos esses dados interessantes vão ajudar a sua equipe a tomar decisões, mas são ainda mais eficientes quando compartilhados com outras equipes — ainda mais se forem de outros departamentos. Por exemplo, as equipes de marketing querem recursos novos e atraentes que possam vender. Porém, enquanto isso, você está percebendo uma alta rotatividade de clientes porque o produto está cheio de débitos técnicos. Usar dados dos usuários como base para o roteiro — mesmo que tenha poucos recursos e muitas correções — torna mais fácil obter um consenso e adesão das partes interessadas.

Compartilhamento


Seria ótimo se tivesse uma varinha mágica para transformar todas as equipes em equipes de alto desempenho de DevOps, mas as transformações de DevOps exigem uma mistura de práticas, filosofias culturais e ferramentas. Mesmo assim, como você leu, os benefícios de quebrar os silos de Desenvolvimento e Operações valem a pena — maior confiança, lançamentos de software mais rápidos, implementações mais confiáveis e um melhor ciclo de feedback entre equipes e clientes.

Abraçar o DevOps não é uma tarefa pequena. No entanto, com a mentalidade, o esforço e as ferramentas corretas, uma empresa pode passar por uma transformação de DevOps que produz benefícios significativos.

O antigo conflito entre equipes de desenvolvimento e operações tem muito a ver com a falta de uma base comum. A gente acredita que compartilhar responsabilidades e sucessos ajuda muito a criar uma ponte entre elas. Os desenvolvedores podem ganhar boa vontade instantânea ajudando a carregar um dos maiores fardos das operações: o pager (uma construção figurativa nos dias de hoje). O DevOps é ambicioso na ideia de que as mesmas pessoas que criam um aplicativo devem estar envolvidas no lançamento e na execução.

Conclusão…


Dessa ideia surge a frase, "você construiu, você executa," o que promove uma abordagem prática entre as equipes. Porém, você não deve apenas contratar desenvolvedores e esperar que eles sejam excelentes operadores também. Significa que desenvolvedores e operadores trabalham juntos durante o ciclo de vida do aplicativo. Além disso, os relatórios mostraram que o código e os produtos revisados por pares são a única revisão que acaba em melhor entrega e desempenho; na verdade, revisores externos não foram mais eficazes do que não realizar qualquer revisão.

As equipes que adotam o DevOps costumam ter uma função rotativa na qual os desenvolvedores resolvem problemas detectados pelos usuários finais e, ao mesmo tempo, resolvem problemas de produção. Essa pessoa responde a problemas urgentes relatados pelo cliente, criando correções quando necessário, e trabalha com o backlog de defeitos relatados pelo cliente. O "desenvolvedor no suporte" aprende muito sobre como o aplicativo é usado no mundo real. Com a alta disponibilidade à equipe de operações, as equipes de desenvolvimento estabelecem confiança e respeito mútuo.

Ian Buchanan
Ian Buchanan

Ian Buchanan é engenheiro principal de soluções do DevOps na Atlassian , onde trabalha com foco na comunidade crescente do DevOps e no aplicativo do Jira, Bitbucket e Bamboo para melhorar a integração e a entrega contínuas. Embora Ian Buchanan tenha uma experiência vasta com Java e .NET, ele é mais conhecido como campeão de práticas simples e ágeis em grandes empresas.

Durante sua carreira, ele foi bem-sucedido em gerenciar ferramentas de desenvolvimento de software empresarial em todas as fases dos seus ciclos de vida, do início ao fim. Ele trouxe melhorias de processo na organização toda com resultados de maior produtividade, melhor qualidade e maior satisfação do cliente. Ele construiu equipes multinacionais ágeis que valorizam a autodireção e a auto-organização. Quando não está falando ou criando códigos, Ian se rende à sua paixão por analisadores, meta programação e linguagens específicas de domínio.


Compartilhe este artigo
Próximo tópico

Leitura recomendada

Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.

Ilustração DevOps

Comunidade do DevOps

Ilustração DevOps

Caminho de aprendizagem de DevOps

Ilustração do mapa

Comece gratuitamente

Inscreva-se para receber a newsletter de DevOps

Thank you for signing up