A adoção da automação pela NetOps levará à necessidade de NetOps Ops

A automação é o futuro. O DevOps há muito tempo adotou a ideia de automatizar tudo o que está à vista, mas o NetOps está rapidamente diminuindo a lacuna entre eles usando amplamente a automação e a orquestração em processos de produção.

Quase metade (46%%) dos entrevistados em nossa pesquisa State of Application Delivery 2018 indicou pelo menos uso "parcial" de automação na produção. Isso inclui sempre usar automação para grandes mudanças de produção (25%), pequenas mudanças de produção (26%) e até mesmo resposta a incidentes (22%). Mais da metade ‘às vezes’ usa automação em todos os três casos.

Essa automação é implementada de várias maneiras. Automação de rede como a da Cisco, VMware e OpenStack são populares, assim como estruturas e ferramentas como Puppet, Chef e os bons e velhos scripts Python.

Dizer que a automação é algo que realmente está acontecendo não é um eufemismo. O NetOps chegou. Isto não é um exercício.

Isso é emocionante, à primeira vista, mas quando você se aprofunda no que isso significa, descobrimos que há desafios que talvez ainda não tenham surgido.

Por exemplo, automatizar uma alteração no firewall ou no roteador é uma coisa. Incluir isso em um processo de implantação abrangente, bem, essa é outra (e o termo apropriado para isso é orquestração, caso você esteja se perguntando).

Depois de começar a encadear (integrar) sistemas e scripts, você construiu o que é equivalente a um "aplicativo". Há muitas partes móveis que precisam ser implantadas, gerenciadas, mantidas, atualizadas, corrigidas e licenciadas.

Esta não é uma tarefa de Sísifo, mas é uma que a NetOps provavelmente não está levando em consideração.

É ótimo que os desenvolvedores agora possam inserir um tíquete no ServiceNow e isso dará início a um fluxo de trabalho de TI que provisiona, configura e cobra automaticamente pelo recurso desejado. Mas o que acontece quando o ServiceNow falha? Ou quando um dos componentes dessa frágil cadeia de repente desmorona. Ou quando uma atualização de um dos componentes interrompe a integração?

Se você fechar os olhos, ouvirá o som dos desenvolvedores rindo de uma overdose de prazer pelo infortúnio com o pensamento.

Uma das consequências não intencionais da automação da TI é que a TI terá mais software e sistemas para manter. Alguns deles serão críticos e exigirão mais cuidados e alimentação do que outros.

Assim como há legiões de desenvolvedores de "manutenção" ou "suporte" dentro de organizações empresariais cuja tarefa é simplesmente manter os sistemas de software em execução, haverá a necessidade de uma função semelhante dentro da TI para lidar com as operações diárias das Operações NetOps.

NetOpsOps. Sim, é uma palavra-valise terrível, mas é uma maneira precisa de descrever o que será necessário à medida que a automação consome cada vez mais tarefas de implantação do NetOps.

Algumas dessas tarefas serão de uma natureza (integração, sistemas de software, etc.) que podem ser assumidas pela equipe de operações existente. Mas alguns são específicos da rede, e isso significa alguém que entenda os scripts, os sistemas e os componentes de rede envolvidos.

Você não pode solucionar problemas, atualizar ou modificar códigos/scripts/modelos se não souber o que eles estão fazendo.

Se você me perguntar o que há de errado com meu snowmobile, eu vou dizer que não tenho ideia. Eu sei como abrir o capô e carregar a bateria, mas não me peça para mexer nas peças que o fazem funcionar. Isso é o mesmo que pedir a um estagiário de desenvolvimento proficiente em JavaScript para atualizar um caderno COBOL. Essa é uma receita para o desastre.

No final das contas, o NetOps vai precisar de algumas pessoas (os NetOps Ops) que tenham conhecimento sobre a rede e os sistemas usados para automatizá-la. Quanto mais a automação for usada, mais essencial será ter essas pessoas no local para assumir a responsabilidade de manter essa automação enquanto os engenheiros trabalham na próxima grande novidade.