Por Patrick Hubbard *
Publicada em 22 de junho de 2017 no site CIO.
Alguns consideram o DevOps uma panaceia todo-poderosa, um paraíso cantado em versos em que o mundo das operações funciona sem atrito no éter insondável. Entretanto, a maioria dos administradores de rede e de aplicativos costuma adotar uma destas duas posições: "Sim. O DevOps é muito útil. O que há de tão surpreendente nisso?" ou "Não tenho tempo, paciência nem uma equipe para ficar fazendo vudu. Aqui nós trabalhamos de verdade." Existem muitos fornecedores demonstrando como seus produtos aceleram o DevOps, o passando direto para Agile, entrega contínua de redes e muito mais, sem pegar fôlego para atrair o interesse de equipes de TI empresariais para as quais o DevOps ainda é uma novidade.
Quando olho para a nossa equipe de TI interna aqui na SolarWinds, uma das mais conservadoras que conheci, percebo que também é possível para qualquer departamento de TI usar o DevOps para tornar-se um ativo vital para a empresa, e não apenas uma área de suporte. Na verdade, não temos escolha, já que ele está chegando a empresas de todos os portes, queiramos ou não.
A lentidão da TI é fatal
No caso da TI tradicional, procedimental e compartimentalizada, não é a pressão para resolver problemas com urgência nem o medo que os recursos se esgotem que destrói o entusiasmo da equipe. O que o destrói é o andamento moroso dos projetos. O que o gerenciamento de TI quase nunca entende é que não passamos um mês colocando novos racks de rede online porque queremos – fazemos isso porque projetos monolíticos, insatisfatoriamente projetados ou baseados em dados históricos incorrem em riscos, e a ferramenta de mitigação de riscos de TI aceitável na maioria das empresas é o trabalho de um comitê. Todos nós já passamos por isso. Projetos que deveriam levar aproximadamente dois dias para serem concluídos são discutidos por semanas em reuniões com pelo menos uma dezena de participantes presenciais e outros tantos no viva-voz.
A esta altura, aqueles que já sabem como se reunir ou trabalhar com um painel de tarefas podem estar torcendo o nariz, lembrando-se dos tempos difíceis, antes da adoção do Agile. Vocês diriam aos engenheiros de rede do exemplo acima: "Criem pequenas equipes para seus principais esforços e segmentem esses esforços em blocos de curto prazo. Não é difícil!" Mas a maioria de vocês pode estar pensando: "OK, devo admitir que estou começando a ouvir meus colegar falar sobre o DevOps, mas nem sei por onde começar." É compreensível.
Um exemplo pessoal
Nossa TI é incrivelmente avessa a riscos e, como resultado, muito tradicional. É fato que eles precisam gerenciar uma operação global, conformidade regulatória e muito mais, mas, em geral, tendem a não mexer em time que está ganhando (e isso não traz nenhum benefício ao resultado final). Portanto, quando eles adotaram práticas de DevOps de livre e espontânea vontade, isso chamou minha atenção. Seu primeiro sucesso foi migrar a arquitetura de servidor IIS™ no CoLos para entrega contínua.
A equipe de operações estava gerenciando cerca de uma centena de instâncias de IIS em uma variedade de funções, a maioria manualmente, desde a porta de entrada do site .com até serviços de informações, proxies, balanceadores de carga e muito mais. Pode-se comprovar a adequação do IIS como um todo, mas o WindowsServer® em que ele reside deixa alguns administradores nervosos. Existem permissões e patches, incerteza na detecção de intrusos e intranquilidade quanto ao que fazer caso um estado atípico seja detectado.
A equipe existente, e não jovens profissionais terceirizados cheios de si, aprendeu algumas fórmulas do Chef e do Ruby. Eles criaram redes de desenvolvimento/teste/preparação em que imagens de máquinas foram criadas, testadas e empacotadas por scripts. Delegaram a configuração de scripts da equipe de rede para especialistas em aplicativos, virtualização e armazenamento. Criaram pequenas equipes multifuncionais para supervisionar o projeto e acabaram se surpreendendo com algo incrível. Toda noite, em um horário programado e sem interação humana, batalhões inteiros de novas máquinas com IIS eram executados, testados na produção e adicionados aos pools dos balanceadores de cargas. Servidores existentes eram extraídos dos pools e limpos, e seus IPs liberados de forma programática pelo IPAM. A equipe de operações podia contar automaticamente com servidores IIS/Windows Servers totalmente novos todos os dias.
Mais do que um feito épico e um projeto de sucesso para a equipe, o primeiro projeto conseguiu o impossível: encantou o gerenciamento. Ele demonstrou o benefício real do DevOps na produção, ou seja, rapidez sem afobação. O DevOps reduziu significativamente os ciclos de implantação sem exigir o aumento do número de funcionários e, ao mesmo tempo, reduziu os riscos por meio da automação. Esse é o ponto alto em rapidez segura e eficiente, que torna a adoção do DevOps aceitável até para os mais céticos.
A parte do "senão..."
A principal meta do DevOps é a rapidez mas, infelizmente, as mudanças nas organizações de TI continuam sendo o aspecto mais lento em muitas empresas, ainda que a diretoria esteja em busca de agilidade. Atualmente, a habilidade de uma empresa de adaptar-se rapidamente em busca de novas oportunidades e novos fluxos de receita é o que a diferencia dos concorrentes. Cada vez mais, a liderança sênior está passando a ver a transição para o DevOps não mais como uma teoria, mas como uma ferramenta indispensável.
Se sua equipe de operações já começou a adotar os locatários centrais Agile do DevOps e seu gerente está relatando os benefícios reais para o CIO, você está no bom caminho. Mas, para as equipes confinadas ao mundo tradicional da abordagem lenta e baseada em tíquetes o tempo está se esgotando. Mais cedo ou mais tarde, sua empresa perceberá as vantagens do DevOps e remodelará suas operações.
A mudança pode acontecer organicamente. Talvez sua liderança executiva aprenda algo com colegas de outras empresas, incentivando e capacitando sua equipe a aprender e explorar novas habilidades e técnicas. Ou talvez possa ser você a aproveitar uma oportunidade de ser independentemente estratégico, implementando novos processos e demonstrando um novo valor ou oportunidade. Ambos representam excelentes resultados. Mas a transição também pode vir abruptamente, com a chegada de um jovem CIO que já use o DevOps e que, em seis meses, substitua toda a equipe "herdada".
Assim, a meta é explorar como aproveitar as técnicas do DevOps, independentemente de você fazer parte do departamento de TI de uma empresa multinacional com 300 funcionários, liderar o departamento de rede de um grupo de administradores versáteis de uma empresa de médio porte ou trabalhar sozinho. Participe de um workshop de liberação do ceticismo e dê uma folheada em um livro sobre Agile. Pergunte-se se existe algum processo demorado e entediante de configuração manual de redes que seja um bom candidato à automação. Contate seus colegas em comunidades técnicas e pergunte o que funciona para eles. Aprenda um pouco de Perl, configure o Chef, experimente construir sistemas em seu laboratório a partir de scripts em vez de usar a linha de comando; é provável que você descubra por que as técnicas do DevOps são uma resposta inevitável para uma TI cada vez mais complexa, que é pressionada a fornecer redes e sistemas de forma rápida e confiável.
(*) Patrick Hubbard é gerente técnico da SolarWinds
Nenhum comentário:
Postar um comentário