Decisões sobre desenvolvimento, teste, implantação, operação e manutenção de aplicativos corporativos não estão sendo tomadas de forma isolada. Antigamente, pode ter acontecido que o pessoal de operações de rede fosse quem estivesse no controle, que fosse a última parada antes que algo importante pudesse acontecer. E para ser honesto, a maioria deles provavelmente gostava assim.
Mas as coisas mudaram. Agora, em vez de exercer um controle rígido, o NetOps está sendo bombardeado com pessoas (pessoas de DevOps, para sermos honestos) que preferem fazer as coisas por conta própria. Coisas que a NetOps gostaria que você não fizesse (como burlar os protocolos de segurança do seu novo aplicativo ou mexer nas configurações de balanceamento de carga para a atualização desse aplicativo).
Agora, pode-se dizer que o pessoal do DevOps está apenas tentando melhorar as coisas. Mais adaptável. Mais autogerenciado e menos microgerenciado. Mais ágil (com A maiúsculo).
O problema é que, no ambiente empresarial de hoje, o DevOps precisa do NetOps se quiser manter seu estilo de trabalho Agile. O DevOps simplesmente não pode fazer isso sozinho (afinal, todos esses aplicativos são executados em uma infraestrutura subjacente). E eles não podem esperar que a NetOps fique em segundo plano e abra mão de todas as suas responsabilidades tradicionais. Nem você gostaria que fizessem isso. O NetOps desempenha um papel importante na manutenção da segurança e do desempenho de todos os aplicativos que o DevOps cria, além de trazer habilidades e capacidades importantes para o fluxo de trabalho de CI/CD.
Se você está no DevOps e está tentando trazer seus colegas NetOps mais profundamente para o fluxo de trabalho de CI/CD, primeiro você precisa que eles queiram participar, para ver o valor em mudar o status quo. Na verdade, isso é bem fácil de fazer, já que as tarefas mais fáceis que a automação resolve facilmente são todas as tarefas rotineiras, tediosas e demoradas, que precisam ser feitas repetidamente. O tipo de tarefa que qualquer trabalhador sensato ficaria feliz em delegar a um bot.
Ordens de alteração são um ótimo exemplo. Selecionando seu caminho através de uma pilha de pedidos, inserindo manualmente cada alteração e, em seguida, verificando duas vezes se você fez tudo certo, porque, afinal, este é o seu nono pedido esta manhã e todos eles estão começando a se misturar. Por que você entrou neste campo em primeiro lugar? Atendendo ordens de mudança o dia todo, todos os dias? Eu não acho.
Existe uma maneira melhor. E isso é para automatizar completamente todas aquelas tarefas redundantes e repetidas que atrapalham um dia que de outra forma seria interessante e produtivo.
O pessoal da empresa queria que liderássemos com isso, porque tudo gira em torno do produto, certo? Quem se importa se os homens e mulheres que fazem isso amam seus empregos, certo? (Errado!)
No entanto, o desempenho robusto e a segurança das suas aplicações são, na verdade, um efeito colateral muito bom para que seu trabalho seja menos entorpecente e redundante.
Ao automatizar os serviços que tornam seus aplicativos confiáveis e seguros, você não apenas libera tempo para projetos mais interessantes e menos repetitivos, mas também melhora a qualidade desses serviços. Isso ocorre porque fluxos de trabalho automatizados e bem elaborados não surgem sozinhos. É função do engenheiro NetOps criar o modelo ideal no qual cada fluxo de trabalho automatizado opera, gerando, por sua vez, resultados ideais repetidamente.
A beleza da automação é que, se você fizer certo da primeira vez, saberá que será feito certo todas as vezes depois disso.
Em um fluxo de trabalho automatizado, o NetOps não apenas consegue manter o controle sobre suas áreas de especialização (o que torna suas aplicações mais rápidos, confiáveis e seguros), como também pode gerar processos automatizados tão simples de usar que o DevOps nunca mais considerará ser enganado (o que, novamente, torna suas aplicações mais rápidos, mais confiáveis e mais seguros).
Quase sempre acontece que nem as equipes de DevOps nem as de NetOps são capazes de descobrir todas as soluções envolvidas na manutenção de aplicativos e dados críticos de uma organização por conta própria. Sempre foi o caso de essas duas equipes precisarem trabalhar juntas. E os recursos de automação de hoje contribuem muito para reduzir o atrito em torno dessas interações.
DevOps, NetOps, SecOps… nenhuma Ops é uma ilha. No fluxo de trabalho moderno de CI/CD, o sucesso vem por meio do desenvolvimento de metodologias claramente definidas e comprovadas que podem ser replicadas de forma rápida e fácil (ou seja, automaticamente) em sistemas complexos. Criar uma base sólida para esses fluxos de trabalho automatizados exige uma parceria sólida entre DevOps, NetOps e SecOps, com cada um emprestando sua experiência em apoio aos outros.
Não importa o ambiente (nuvem, contêiner, etc.), seus aplicativos dependem de serviços de aplicativos subjacentes, serviços de rede e serviços de segurança. O NetOps tem a função de manter os dados fluindo pela rede, garantindo que os aplicativos sejam escaláveis e responsivos, e garantindo que os dados estejam disponíveis quando necessário e protegidos sempre. E cada equipe de operações tem um papel a desempenhar na redução de riscos, seja o risco de seu aplicativo não funcionar como esperado, o risco de sua rede ficar sobrecarregada ou o risco de ameaças externas tentarem atacar seus ativos. E é interessante notar que os princípios do DevOps que geram bons resultados para o desenvolvimento de software — cultura, automação, medição e compartilhamento — são os mesmos princípios que geram bons resultados de segurança, de acordo com o Relatório do Estado do DevOps de 2019 da Puppet .
Essa interação entre as diversas equipes de operações é constante. É a maneira como a TI tem operado durante toda a era da Internet. Mas sempre há espaço para melhorias, como quando o processo de desenvolvimento de software Agile surgiu, expandindo os limites da rapidez com que os aplicativos poderiam ser desenvolvidos e implantados. Naquela época, o DevOps começou a fazer a grande mudança para uma abordagem mais ágil ao desenvolvimento, adotando uma maneira mais rápida de ir “do código ao cliente”.
Esse aumento na velocidade está impulsionando a mudança radical que o DevOps está testemunhando agora. Isso tem um lado bom, pois o DevOps consegue se mover mais rápido e ser mais proativo; e tem um lado ruim, pois pode criar atrito quando os processos de outros departamentos não estão configurados para funcionar da mesma maneira.
Simplesmente ignorar outros departamentos ou desconsiderar colegas de trabalho que ainda não se adaptaram à sua nova maneira de fazer as coisas é uma má ideia. Quando o DevOps tenta fazer tudo sozinho, é ineficiente e inadequado. É assim que os processos são interrompidos (inadvertidamente ou não), e processos interrompidos podem levar a todos os tipos de coisas dando errado. E não apenas para DevOps, mas para todos, incluindo seus clientes, que são as últimas pessoas que você quer impactar negativamente.
Para que o DevOps realmente faça seu trabalho corretamente, você precisa do NetOps como um parceiro, não um inimigo. E a base de qualquer parceria sólida é a comunicação. O DevOps precisa se comunicar com a equipe de rede sobre como obter os serviços necessários para dar suporte aos seus aplicativos.
Muitas vezes, a equipe de DevOps será especialista em automação, na estrutura geral e em coisas como infraestrutura como código; mas a equipe de rede é especialista em entender os recursos arquitetônicos reais que precisam ser provisionados e quais ferramentas estão disponíveis para esse provisionamento. Por meio de conversas e respeito mútuo, DevOps e NetOps podem identificar onde a automação é necessária e a melhor forma de realizá-la.
Você não tem nada a perder, DevOps, e muito a ganhar ao ajudar seus colegas NetOps a estender a função da automação em todo o fluxo de trabalho de CI/CD. O segredo é reconhecer que, assim como você é especialista em desenvolvimento de código, um ou mais de seus colegas de trabalho são especialistas em provisionar serviços de rede e segurança para dar suporte a esse código. Não perca a chance de ajudá-los a serem os melhores especialistas que podem ser.