Framework CALMS

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.

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.

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.

É 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 funções, 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 funções novas 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 poucas funções e muitas correções — torna mais fácil obter um consenso e adesão das partes interessadas.

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.

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.

A Atlassian criou o Open DevOps para equipes que buscam criar a cadeia de ferramentas que quiserem, com as ferramentas que adoram, graças às integrações com os principais fornecedores e apps do marketplace. Experimente agora mesmo.