Os bárbaros do DevOps chegaram

Não vou esconder: sou um intruso na 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 precisarão aprender a programar. Não apenas scripts de gurus,
mas fundamentos de programação reais. 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.

 

(*) Patrick Hubbard é Head Geek da SolarWinds