As operações de TI devem ir além da criação de scripts para a automação

Teste rápido – qual é mais pesado? Meio quilo de penas ou meio quilo de pedras?

Pergunta capciosa, é claro. Uma libra é uma libra. Há muito mais penas em um quilo do que pedras.

Certo, mudando de assunto, qual é mais rápido? Um script executado por meio de um comando manual ou um script invocado por meio de uma chamada de API?

Neste ponto, você provavelmente deduziu que a resposta é como a primeira e respondeu que não há diferença. Pelo menos não uma diferença perceptível.

Um script é um script, e seu tempo de execução não depende de seu método de invocação. Seja iniciado por um comando manual ou invocado por meio de uma API, o script será executado tão rápido quanto for possível. Período.

Isso é importante porque melhorar a velocidade das operações com automação não é realmente uma questão de script, mas sim de processo. É sobre a transferência. Você nunca otimizará as implantações se se concentrar apenas na criação de scripts para etapas individuais do processo. Você precisa ir mais alto, até o processo em si, antes de ver uma melhora real.

O objetivo da automação em todos os setores é quase sempre a otimização. Vimos isso em nossa pesquisa State of Application Delivery de 2018, onde 72% dos entrevistados com uma iniciativa de transformação digital identificaram a “otimização de TI” como o principal benefício esperado. O objetivo era a otimização.

Otimizar significa encontrar e eliminar gargalos. No mundo da TI, isso quase sempre acontece nas transferências entre etapas de um processo operacional. O trabalho real – os roteiros – é o valor. O tempo entre a execução desses scripts é quase sempre uma fonte de atraso e frustração para aqueles que esperam o resultado. A maioria (52%) dos NetOps ainda gerencia a infraestrutura dessa maneira. 

Não basta que cada domínio operacional defina sua parte no processo. Elaborar um script para alterar o firewall, provisionar e configurar serviços de aplicativos e criar a infraestrutura do aplicativo são coisas boas a serem feitas individualmente. Mas isso é só o começo. Juntas, essas etapas individuais automatizadas compõem um único processo operacional. Automatizar isso é o que chamamos de orquestração. E é na orquestração que encontramos os atrasos e as transferências defeituosas que introduzem as ineficiências que prejudicam os ITOps. 

É aqui que a cultura e a estrutura organizacional importam. Se você é o primeiro passo no processo de implantação – digamos, montando a infraestrutura do aplicativo – então você é quem deve passar o processo para a próxima etapa da fila. Provavelmente essa é a etapa de provisionamento dos serviços do aplicativo (balanceamento de carga, etc.).

A quem você entrega isso? Vai para uma fila? Vocês geram um ticket? Como isso funciona?

Deve ser uma transição perfeita, governada por um manual abrangente (receita, livro de receitas, manifesto, etc.) ou por algum sistema externo que supervisione a execução do processo. A introdução da interação manual na execução do processo significa que você não está realmente aproveitando a automação, está apenas criando um script.

E embora os scripts possam ser um componente integral da sua estratégia de automação, eles não são automação em si porque não conseguem se integrar ao processo de governança que os orienta.

Se você vai otimizar a TI usando automação, então você precisa automatizar processos. Porque é assim que você elimina os tempos de espera e descobre os processos operacionais fossilizados (incluindo três camadas de aprovações) que realmente melhorarão o desempenho e aumentarão a velocidade de forma significativa.   

Automação – não apenas scripts – é um sinal de uma prática de NetOps madura que o deixa um passo mais perto do objetivo de uma rede ágil.