O NetOps precisa de defensores, não de adversários
Você está pronto para saborear uma refeição que esperou o dia todo quando percebe que ela está malpassada. Frustrado, você fala rudemente com o garçom e talvez até reduza a gorjeta. Eles aceitam isso com um sorriso, mesmo que não seja culpa deles. Afinal, eles não prepararam sua refeição. Mas eles são sua interface com a cozinha e, no final das contas, são eles que pagam o preço pelos fracassos que acontecem fora da vista.
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 suportando o peso da sua angústia/frustração/raiva quando algo dá errado.
Isso também é verdade no data center.
À medida que a TI se transforma digitalmente com o objetivo de atingir maior otimização e velocidade, são as equipes de NetOps que têm mais probabilidade de interagir com "clientes" internos e, portanto, arcar com o peso dos usuários insatisfeitos quando os processos não ocorrem tão rapidamente quanto o desejado.
É importante reconhecer que nem sempre é o "NetOps" que atrapalha a implantação da última novidade/aplicativo/serviço. Os impedimentos à velocidade geralmente ocorrem devido à falha em adotar todas as premissas do DevOps à medida que as organizações buscam transformar as operações de TI.
Você está fazendo DevOps ou apenas automatizando?
O CAMS é o meio mais comumente usado para disseminar os princípios básicos do DevOps. CAMS significa: cultura , automação , medição e compartilhamento .
Destes quatro, a automação é a que provavelmente será adotada com entusiasmo. São os outros três que tendem a ser deixados para trás ou completamente ignorados na busca por melhorar a velocidade do serviço dentro da TI.
É importante notar 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 focadas em métricas que não importam para outras equipes. Trabalhamos em direção àquilo pelo qual somos medidos. Se formos medidos pelo tempo de atividade da rede, é nisso que vamos nos concentrar, mesmo que nossos colegas nas operações estejam tentando melhorar o tempo de atividade do aplicativo .
A saber, você deve se lembrar da pesquisa State of Network Automation , na qual unimos forças com a Red Hat para mergulhar no mundo obscuro do DevOps, NetOps e automação. Nele, encontramos grande disparidade entre as métricas (mensurações) buscadas pela NetOps e aquelas envolvidas no desenvolvimento e nas operações.
Quase três quartos (73%) dos NetOps citaram o "tempo de atividade da rede" como sua principal métrica. Do outro lado da cerca, 59% dos desenvolvedores e operações nos disseram que "tempo de atividade do aplicativo" era sua principal métrica. Por outro lado, quase o dobro de desenvolvedores e operações (30%) são medidos pela frequência de implantações do que NetOps (16%) e Segurança (17%).
Por que essa disparidade é importante? Se meu objetivo principal é manter a rede disponível, vou dedicar meu tempo à rede. A instrumentação e o monitoramento — este último essencial para o componente de compartilhamento do DevOps — se concentrarão primeiro na rede e, depois, talvez no aplicativo. Se houver tempo. Ninguém tem tempo para segurança e ninguém é avaliado por isso. Na verdade, a principal medida citada para segurança foi "tempo de atividade da rede", com 59% dos profissionais de segurança avaliados com essa métrica.
As pessoas, que ainda estão no centro da TI e compõem as equipes que devem implementar automação e orquestração, não estão necessariamente alinhadas aos mesmos objetivos. Um fator nesse desalinhamento é o isolamento contínuo dos domínios operacionais. Os grupos de NetOps e Segurança têm mais probabilidade de trabalhar na estrutura de uma equipe de "função única". A NetOps se preocupa com a rede. Segurança? Segurança. Operações? Operações do sistema.
Mas vai ainda mais fundo do que isso . Porque dentro dos silos GRANDES existem silos ainda menores. Assim como a matryoshka — uma boneca russa —, há muitas equipes diferentes dentro da NetOps pelas quais essa solicitação aparentemente simples de "novo site" deve fluir antes de ser concluída. Muitos serviços de infraestrutura e aplicativos devem ser provisionados e integrados antes que tal solicitação possa ser atendida. Um novo site requer não apenas os recursos de computação e rede para hospedá-lo, mas 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 intra-TI pelos quais essa solicitação "simples" deve passar é interminável.
E se um desses silos dentro do silo NetOps não for automatizado, o processo será interrompido bruscamente. Dias, se não semanas, podem ser adicionados ao tempo necessário para entregar tal solicitação.
Para quem está de fora — para o solicitante — parece que o NetOps está fracassando na tarefa. É a "contraparte", o "elo", o "parceiro de TI" que carrega a angústia daqueles que querem saber por que está demorando tanto para atender o que parece ser uma solicitação simples. Culpamos a NetOps da mesma forma que os neófitos técnicos culpam o provedor local pelos problemas de Internet, quando o problema na verdade é um roteador no backbone gerenciado por outro provedor.
Seja um defensor, não um adversário
A mudança para uma TI mais colaborativa e transparente ainda é apenas um pontinho no horizonte para muitas organizações. Embora alguns grupos de TI percebam a necessidade e adotem as mudanças necessárias, nem todos o fazem. Nos cinco anos em que conduzimos pesquisas sobre serviços de aplicativos, não vimos o "DevOps" atingir o nível de importância estratégica necessário para realmente iniciar as mudanças culturais e organizacionais necessárias para atingir o tipo de velocidade que a empresa deseja - e precisa. Em vez disso, as organizações adotaram a automação e se esqueceram dos outros três componentes essenciais para o DevOps.
Essa falha em reconhecer que o movimento DevOps em TI é mais do que apenas automação é preocupante. É uma falha reconhecer que, se você quiser ganhar velocidade, precisa automatizar o pipeline, e esse pipeline atravessa praticamente todos os domínios e silos operacionais dentro da TI. Isso significa que todos os afetados precisam migrar para a automação, ou você não conseguirá atingir a velocidade e a frequência de implantações que deseja. Você não pode simplesmente adotar a automação e esperar ter sucesso. Quando a automação precisa cruzar linhas entre grupos isolados, você falhará sem uma mudança cultural significativa.
A mudança necessária tem que vir de cima. Principalmente mudanças organizacionais. Não podemos nos reorganizar muito bem, podemos? Não podemos repriorizar nossas metas e usar um conjunto totalmente diferente de métricas, podemos?
Não podemos, e a menos que eduquemos e convençamos aqueles que podem fazer as mudanças necessárias, ficaremos presos a processos manuais no meio de um pipeline automatizado.
Então, vamos parar de usar o NetOps como bode expiatório e reconhecer que eles também podem estar frustrados. Em vez disso, lembre aos tomadores de decisão a necessidade de reavaliar as estruturas organizacionais e repriorizar as medições para obter um melhor alinhamento com o negócio e o restante do pipeline contínuo.
Gritar com o pessoal da NetOps na linha de frente pode ser satisfatório, mas não muda a situação que deu origem à raiva em primeiro lugar. E sem mudanças, o pipeline não ficará mais rápido.
Seja seu defensor do NetOps e não seu adversário. Eles precisam de toda a ajuda que puderem obter.