NetOps precisa de defensores, não de adversários

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Você está prestes a saborear uma refeição pela qual esperou o dia todo quando percebe que ela está malpassada. Frustrado, você fala de forma ríspida com quem está atendendo e talvez até reduza a gorjeta. A pessoa recebe a reclamação com um sorriso, embora não tenha culpa. Afinal, não foi ela quem preparou sua refeição. Mas ela é o seu ponto de contato com a cozinha e, no fim das contas, é quem paga o preço pelas falhas que acontecem longe dos seus olhos.

Seja o garçom de um restaurante ou um representante de atendimento ao cliente de <insira o serviço aqui>, geralmente é a pessoa que interage com você que acaba sofrendo a maior parte da sua angústia, frustração ou raiva quando algo dá errado.

Isso também se aplica ao data center.

À medida que a TI passa por sua transformação digital com o objetivo de alcançar maior otimização e agilidade, são as equipes de NetOps que têm maior probabilidade de interagir com os "clientes" internos e, portanto, acabam arcando com a maior parte da insatisfação dos usuários quando os processos não avançam com a rapidez desejada.

É importante reconhecer que nem sempre é a equipe de "NetOps" que está dificultando a implantação da mais recente tecnologia/aplicação/serviço. Os obstáculos à agilidade geralmente decorrem da falta de adoção de todas as premissas do DevOps à medida que as organizações buscam transformar as operações de TI.

Você está praticando DevOps ou apenas automatizando?

CAMS é o modelo mais utilizado para disseminar os princípios fundamentais do DevOps. CAMS significa: cultura, automação, mensuração e compartilhamento.

Desses quatro, a automação é o que tem maior probabilidade de ser adotado com entusiasmo. Os outros três tendem a ser deixados de lado ou simplesmente ignorados na busca por aumentar a velocidade da prestação de serviços de TI.

É especialmente importante observar que os três conceitos comumente ignorados estão interligados. É difícil mudar a cultura quando as equipes ainda estão isoladas por função e concentradas em métricas que não importam para as outras equipes. Trabalhamos em função daquilo pelo qual somos avaliados. Se formos avaliados pela disponibilidade da rede, é nisso que vamos nos concentrar — mesmo que nossos colegas de operações estejam tentando melhorar a disponibilidade da aplicação.

A propósito, talvez você se lembre da pesquisa sobre o Estado da Automação de Redes na qual unimos forças com a Red Hat para mergulhar no complexo universo de DevOps, NetOps e automação. Nela, constatamos uma grande disparidade entre as métricas (medições) buscadas pelas equipes de NetOps e aquelas buscadas pelos profissionais envolvidos em desenvolvimento e operações.

Quase três quartos (73%) das equipes de NetOps citaram a "disponibilidade da rede" como sua principal métrica. Do outro lado, 59% dos profissionais de desenvolvimento e operações afirmaram que a "disponibilidade das aplicações" era sua principal métrica. Por outro lado, quase o dobro dos profissionais de desenvolvimento e operações (30%) são avaliados pela frequência de implantações em comparação com os de NetOps (16%) e Segurança (17%).

Por que essa disparidade é importante? Se meu principal objetivo é manter a rede disponível, vou dedicar meu tempo à rede. A instrumentação e o monitoramento — sendo este último essencial para o componente de compartilhamento do DevOps — se concentrarão primeiro na rede e, talvez, depois na aplicação. Se houver tempo. Ninguém tem tempo para a segurança e, de qualquer forma, ninguém é avaliado por ela. Na verdade, o principal indicador citado para a segurança foi <rufem os tambores> a "disponibilidade da rede", métrica usada para avaliar 59% dos profissionais de segurança.

As pessoas, que ainda estão no centro da TI e compõem as equipes responsáveis por implementar a automação e a orquestração, não estão necessariamente alinhadas em torno dos mesmos objetivos. Um dos fatores que contribuem para esse desalinhamento é o isolamento persistente dos domínios operacionais. As equipes de NetOps e Segurança tendem a trabalhar mais segundo o modelo de equipe de "função única". A equipe de NetOps se preocupa com a rede. E a de Segurança? Com a segurança. E a de Operações? Com as operações de sistemas.

Mas a questão é ainda mais profunda do que isso. Porque dentro dos GRANDES silos existem silos ainda menores. Assim como uma matriosca — uma boneca russa —, há muitas equipes diferentes dentro de NetOps pelas quais aquela solicitação aparentemente simples de um "novo site" precisa passar antes de ser concluída. Muitos serviços de infraestrutura e de aplicações precisam ser provisionados e integrados para que essa solicitação possa ser atendida. Um novo site exige não apenas os recursos de computação e rede para hospedá-lo, mas também uma série de outros requisitos. Um servidor web e seu armazenamento. Controle de acesso. Certificados e gerenciamento de chaves. Balanceamento de carga. Regras de firewall. A lista de silos internos de TI pelos quais essa solicitação "simples" precisa passar é interminável.

E se um desses silos dentro do silo de NetOps não for automatizado, o processo para bruscamente. Isso pode acrescentar dias, ou até semanas, ao tempo necessário para atender a uma solicitação desse tipo.

Para quem vê de fora — para o solicitante —, parece que a equipe de NetOps simplesmente não está fazendo seu trabalho. É a "contraparte", o "intermediário", o "parceiro de TI" que precisa lidar com a angústia daqueles que exigem saber por que está demorando tanto para atender ao que parece ser uma solicitação simples. Culpamos a equipe de NetOps da mesma forma que os leigos em tecnologia culpam o provedor local por instabilidades na Internet, quando o problema, na verdade, está em um roteador no núcleo da rede, gerenciado por algum outro provedor.

Seja um defensor, não um adversário

A transição para uma TI mais colaborativa e transparente ainda é apenas um ponto distante no horizonte para muitas organizações. Embora algumas equipes de TI reconheçam essa necessidade e adotem as mudanças necessárias, nem todas fazem o mesmo. Nos cinco anos em que realizamos pesquisas sobre serviços de aplicações, não vimos o "DevOps" alcançar o nível de importância estratégica necessário para realmente iniciar as mudanças culturais e organizacionais indispensáveis para atingir a velocidade que os negócios desejam — e da qual precisam. Em vez disso, as organizações adotaram a automação e se esqueceram dos outros três componentes essenciais do DevOps.

É preocupante não reconhecer que a adoção do movimento DevOps pela TI envolve muito mais do que apenas automação. Isso significa não perceber que, para ganhar velocidade, é preciso automatizar o pipeline — e esse pipeline atravessa praticamente todos os domínios operacionais e silos da TI. Portanto, todos os envolvidos precisam avançar rumo à automação; caso contrário, não será possível alcançar a velocidade e a frequência de implantações desejadas. Não basta simplesmente adotar a automação e esperar ter sucesso. Quando a automação precisa transpor as fronteiras entre grupos isolados em silos, não haverá sucesso sem uma mudança cultural significativa.

A mudança necessária precisa vir de cima. Principalmente a mudança organizacional. Não podemos simplesmente nos reorganizar por conta própria, podemos? Não podemos redefinir a prioridade de nossos objetivos e usar um conjunto de métricas totalmente diferente, podemos?

Não podemos, e, a menos que conscientizemos e convençamos aqueles que podem fazer as mudanças necessárias, ficaremos presos a processos manuais em meio a um pipeline que, de resto, é automatizado.

Então, vamos parar de usar a equipe de NetOps como bode expiatório e reconhecer que ela também pode estar frustrada. Em vez disso, lembre aos tomadores de decisão da necessidade de reavaliar as estruturas organizacionais e redefinir as prioridades das métricas para obter um melhor alinhamento com os negócios e com o restante do pipeline contínuo.

Gritar com o pessoal de NetOps que está na linha de frente pode até parecer satisfatório, mas isso não muda de fato a situação que deu origem à raiva. E, sem mudanças, o pipeline não vai ficar mais rápido.

Seja um defensor da equipe de NetOps, em vez de seu adversário. Ela precisa de toda a ajuda possível.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie