DevOps empresariais: por que você deve executar o que cria

Por Stephen Orban, Head of Enterprise Strategy

“Você constrói, você executa” – Werner Vogels

É uma cena que todos conhecem: você está passando tempo com a sua família e de repente o telefone rouba sua atenção. A temida campainha avisa de uma falha de SEV1. Seu aplicativo — aquele que sofre sempre de falta de memória e que é “consertado” pela área de Operações reiniciando-0 — está acabando com os recursos do servidor nos minutos que fica online. O aplicativo está realmente inutilizável O pessoal de Operações não está equipado para fazer muito mais além de reiniciar ou fazer uma reversão, mas a última cópia boa já é de alguns meses atrás. Quem sabe tudo o que mudou desde então. Corrigir essa falha depende de você, que está quilômetros de distância do escritório e do seu computador.

Incidentes como este são mais do que comuns em um modelo de TI empresarial tradicional, onde o Desenvolvimento e Operações estão cada um em um lado do muro. Mas isto não precisa ser assim. DevOps não serve só para startups. Também pode ser usado por grandes corporações. Do mesmo modo que a automatização e o atendimento ao cliente, “executar o que você constrói” pode ser um princípio efetivo para melhorar aquilo que a TI de empresas faz usando um modelo de DevOps.

Em uma situação tradicional, os desenvolvedores arquitetam e criam uma solução que depois é passada para Operações. Às vezes, eles são gentis o suficiente para fornecer certa orientação sobre como tratar com questões de produção e às vezes têm pouco ou nenhum conhecimento do ambiente de produção com o qual começar. Quando essas equipes continuam sendo entidades separadas, cada um deles tem pouca informação de como a outra trabalha e o que ela precisa. Muitas vezes, as equipes de Operações têm manuais de execução, SOPs (Procedimentos operacionais padrão) ou algum outro mecanismo para abordar questões conforme elas surgem na produção. Elas podem ser bastante efetivas quando você precisa de uma correção rápida, mas quando as causas raiz não são identificadas e abordadas, é como usar um chiclete para tampar um buraco num barco. Provavelmente, você termina afundando.

DevOps pode oferecer uma forma melhor…

A nuvem ajudou a derrubar esse muro porque, dessa forma, sua infraestrutura começa a ficar muito parecida com software. A natureza orientada por API permite tratar sua infraestrutura como um código, o que é uma coisa que os desenvolvedores compreendem. Agora que todo mundo está muito mais perto da infraestrutura, naturalmente as operações se tornam cada vez mais um requisito-chave.

Enquanto isso, o software é vendido cada vez mais como serviço e seus clientes exigem melhorias constantes, com razão. Eles podem aguentar um erro aqui e outro lá, mas só se esses erros forem corrigidos na hora e não continuarem acontecendo. Para poder acompanhar essas mudanças, você precisa ouvir dicas e pontos de vistas que seus clientes podem não estar comunicando diretamente a você. Eles, como você, estão ocupados com outras coisas, e quando eles ligam para dar feedback, parece que estão insatisfeitos. Embora a interação com os clientes seja uma questão de aprender, é melhor que eles estejam a seu favor. Esses pontos de vista são muito mais difíceis de encontrar com um muro entre Desenvolvimento e Operações — o pessoal de Operações pode estar aplicando soluções rápidas e varrendo problemas debaixo do tapete, e os desenvolvedores terão um parâmetro mais baixo de excelência operacional se tiverem excesso de rede de segurança no seu trampolim.

Todas estas coisas são bons motivos para se afastar do modelo de TI tradicional e ir em direção de uma cultura de DevOps, onde o pessoal de Desenvolvimento e de Operações se encontra dentro de um só foco. Eu tento animar os executivos a fazerem com que “executar o que você constrói” seja um princípio básico e imprescindível nas suas organizações orientadas a DevOps. Veja aqui alguns dos benefícios e comportamentos que eu tenho visto as organizações colherem:

·         Design de produção. Executar o que você constrói força as equipes de Desenvolvimento a pensarem, conforme vão projetando seu software, sobre como ele vai ser executado na produção. Isto pode ajudar suas equipes a evitar corridas no último minuto, o que acontece com frequência quando as equipes tentam forçar que o que fizeram encaixe em um ambiente de produção para poder cumprir o prazo. Eu já nem sei quantas vezes eu vi como isto afetou a qualidade materialmente. Você pode modificar coisas no momento da implementação para corrigir aquilo que está diferente entre a produção e o Desenvolvimento, fazer testes que achar que são importantes e descobrir, mais tarde, que essa modificação provocou um erro em algum lugar no sistema.

·         Maior autonomia para os funcionários. A execução que você cria mentalmente encoraja a assumir a responsabilidade e o que se faz, e isto, pela minha experiência, leva a funcionários mais independentes, responsáveis e inclusive a crescimento de carreiras na organização. Meu post anterior fala mais sobre este assunto.

·         Maior transparência. Ninguém quer interrupções na sua vida particular. Seja quem for que atender a ligação vai fazer tudo o que puder para evitar que isto tenha prioridade. Naturalmente, seu pessoal irá querer maior transparência no ambiente e implementar monitoramento proativo, de forma que possam identificar questões ou padrões de relevância antes que se tornem problemas disseminados. Além de detectar problemas antes que aconteçam, esse tipo de transparência deveria fazer com que fosse muito mais fácil encontrar as causas que geram questões que ainda têm que superar.

·         Mais automação. Os desenvolvedores detestam repetir tarefas manuais, por isso, se encontrarem coisas que têm que fazer repetidamente na produção para corrigir uma questão, provavelmente eles vão encontrar a causa raiz e automatizar coisas conforme aparecem.

·         Melhor qualidade operacional. Coisas, como transparência e automação, farão com que suas equipes sejam mais eficientes e continuarão subindo o parâmetro de excelência operacional.

·         Clientes mais satisfeitos. Executar o que você constrói força toda a equipe de TI a entender mais sobre o cliente. Esse conhecimento deixará de ser limitado a um produto ou à equipe de vendas, e esses insights podem ser incrivelmente úteis quando são usados como um ciclo de feedback para a melhoria constante da produção.

Eu tenho certeza de que vocês podem me fazer lembrar de outros benefícios, e eu adoraria saber sua opinião. Envie-as para mim!

Continue criando,
-Stephen
orbans@amazon.com
@stephenorban
http://aws.amazon.com/enterprise/