Patrick Hubbard é Head Geek™ da SolarWinds
Não vou esconder: sou um intruso na Tecnologia da Informação (TI). Não vim para o Ops porque adoro as fascinantes nuances dos inúmeros aplicativos e tecnologias estranhos e inusitados. O domínio da remediação de problemas de serviço novos e obscuros via linha de comando é uma desventura, não uma plataforma para realização pessoal. Não, comecei minha carreira como um desenvolvedor convicto e vim para o Ops com o intuito de automatizá-lo: para identificar e eliminar a configuração manual onde quer que ela retarde os negócios ou diminua a qualidade do serviço.
Antes do bug do milênio, eu devia parecer alguém vindo de um futuro absurdo do DevOps, determinado a criar um mundo em que o propósito e a competência humanos fossem codificados de forma repetível, e as mudanças fossem gerenciadas e aplicadas de modo habitual. O software, e não a labuta humana, deve ser o principal responsável pela atuação da TI. Mas falar isso é fácil, difícil é fazer.
Exército de braços cruzados
Com a supervalorização de DevOps, BizDevOps, DevSecOps, BizDevSecOps e DevTudooMaisOps beirando o inacreditável, é perfeitamente razoável que as organizações de TI sejam céticas ou até mesmo abertamente avessas a desenvolvedores. Os profissionais de TI e os desenvolvedores tradicionais vêm de mundos diferentes. Um parece mais uma vocação para ajudar as pessoas (semelhante à dos professores), com uma tendência para tolerar a frustração e as dificuldades que muitas vezes estão envolvidas nisso. O outro surge de um desejo sincero de transformar de alguma forma os truques da tecnologia em algo de utilidade visível. Talvez isso aconteça porque os projetos paralelos dos desenvolvedores geralmente envolvem robótica ou outras modificações com motores ou LEDs que convertem os estados lógicos efêmeros em efeitos físicos.
As operações de TI, por outro lado, há décadas fazem bordas piscarem e ventiladores girarem. Uma coisa com um cabo de energia que gera calor residual está claramente fazendo alguma coisa: é algo que o Ops tem orgulho de ter. Eles pensam em seus encargos tangíveis antes de dormir e no café da manhã e são protetores como um pai ou uma mãe. A cautela deles em relação aos desenvolvedores é muitas vezes parecida com a forma como penso nos gatos. Geralmente não gosto de gatos, mas me reservo o direito de gostar de alguns específicos.
Os gatos não melhoram a própria reputação destruindo móveis quando suas garras coçam, e os desenvolvedores angariam suspeita legítima quando reduzem a produção devido à falta de compreensão das operações do mundo real ou a uma disciplina de testes ineficiente. O desejo da gestão de adotar princípios ágeis em TI, implementar técnicas do DevOps ou talvez até mesmo processos reais de entrega contínua precisa ser compreendido. A reação inicial das equipes de TI em relação ao DevOps é na maior parte das vezes braços nervosamente cruzados por toda a mesa de conferência.
Um futuro para a programação
O DevOps — e, mais especificamente, os princípios ágeis — exigem confiança de todas as partes. A confiança entre as equipes de que todos estejam trabalhando rumo a um objetivo comum, a confiança de que a realocação de tarefas por líderes é baseada na otimização de longo prazo, a confiança de que os gerentes realmente entendem que falhar no início significa aceitar mais falhas, mas também a confiança da gestão de que, ao final, essas falhas serão reduzidas por meio de uma melhor resiliência. Talvez a base mais importante da confiança seja o crédito, e é nisso que aqueles com mentalidade de desenvolvedor podem ajudar mais a TI.
Querendo ou não, em algum momento, as equipes de operações, iniciantes ou não, precisarão aprender a programar. Não apenas scripts de gurus, mas fundamentos de programação reais que não são aprendidos em qualquer curso de programação. Não é útil para os desenvolvedores se perguntarem, com irritação: "Como o monitor de Ops vai instalar e manter este aplicativo quando ele sequer ouvir falar em marcação multidimensional ou rastreamento distribuído? Cruzes!" Em vez disso, o que ajuda é lembrar, embora seja difícil de acreditar, que houve uma época em que eles não tinham esse furor e confiança de programador.
No meu caso, eu tinha 11 anos e queria rolar um jogo horizontalmente sem tremulação e aprender a linguagem Assembly foi o único modo de fazer isso. Passei a acreditar que poderia aprender o que fosse necessário, mesmo que o fracasso fizesse parte do processo; além disso, seria um indicador chave de desempenho da aprendizagem. Acima de tudo, aprendi que a programação era poderosa, podia ser aplicada a quase qualquer área e tinha uma capacidade única de minimizar o tédio e a labuta. É esse conhecimento que torna os programadores eficazes, e não o domínio da pilha do dia.
Na Cisco Live de julho, milhares de administradores tradicionais visitaram o pavilhão DevNet, que dobrou de tamanho em relação ao ano anterior. Centenas de engenheiros de rede grisalhos e bem-sucedidos (do tipo que usa linhas de comandos) participaram de aulas práticas dos fundamentos da programação em Python, sessões de automação da API e muito mais. Foi maravilhoso ver o sorriso em seus rostos e o entusiasmo renovado em um momento compartilhado de descoberta em que perceberam que quase todo o processo pode realmente ser capturado em código. Esses administradores serão bem-vindos na TI por muitos anos no futuro.
Os profissionais de TI capacitados com conhecimento operacional profundo e um desejo de aprender novas habilidades fora de sua zona de conforto serão os futuros líderes de equipes de TI. Com a confiança da gestão e um pouco de tempo reservado para o laboratório, eles romperão os antigos gargalos tecnológicos e da organização. São eles os bárbaros que chegaram. Eles estão aqui não para acelerar a destruição da TI pelo lado de fora, mas salvá-la por dentro.
