DevOps para NetOps é sobre escala
E escala leva à velocidade. E a velocidade leva ao sucesso.
Suponha que um engenheiro consiga processar uma solicitação de mudança em duas horas. Suponha que outro engenheiro consiga processar essa solicitação de mudança em 1,5 hora. Se eles trabalharem juntos, quanto tempo levarão para processar duzentas solicitações de mudança?
Sim, a resposta é obviamente cerveja.
Todos provavelmente se lembram (com uma boa dose de medo e aversão) dos infames problemas de “trem” ou “pintura” nas aulas de matemática, que foram projetados para nos ensinar sobre relações fracionárias. Na verdade, essa era a intenção deles, embora o que muitos de nós tenhamos aprendido com eles tenha sido uma aversão à pintura e às viagens de trem. E muitos memes. Não vamos esquecer os memes.
A questão é que esse tipo de medição formulada está se tornando um requisito no data center, especialmente na rede. Isso porque os orçamentos são limitados (eu sei, certo? Que loucura é essa?) e você só pode contratar X engenheiros para fazer Y trabalho. Em um mundo de aplicativos onde ciclos de lançamento rápidos e frequentes são a regra, o número de “X” que você pode contratar para obter lançamentos pontuais é limitado.
É por isso que a escala é o principal impulsionador do “devops” na rede, também conhecido como “netops”. Ao aplicar os princípios operacionais do DevOps à rede, acredita-se que as netops podem atingir a escala operacional necessária para tornar “X” engenheiros capazes de fazer “Y” trabalho no prazo e dentro das restrições orçamentárias, mesmo quando a relação entre X e Y é exponencial (tradução leiga: realmente desequilibrada).
O problema da solicitação de mudança é real; apresentado por um engenheiro de rede que enfrentou um número cada vez maior de solicitações de mudança (definidas como criar um ponto de extremidade do balanceador de carga para um aplicativo, adicioná-lo ao DNS e criar uma regra de firewall para permitir o acesso) que, em última análise, ameaçavam sobrecarregar a equipe disponível e, ao mesmo tempo, aumentavam o tempo de conclusão.
A resposta foi encontrada na automação, é claro, e na aplicação dos princípios do DevOps e na oferta de uma interface de autoatendimento que permitia que outros engenheiros fizessem solicitações que eram então documentadas no sistema de tickets e executadas por meio de várias APIs de serviços de rede e aplicativos.
Essa adoção da automação (e orquestração, porque todo o processo também está sendo automatizado) não só permite que os engenheiros existentes escalem operacionalmente, mas também torna o processo mais rápido . Não demora mais até duas horas para processar uma solicitação de alteração; agora, leva apenas cinco minutos.
Sim, você leu certo. Cinco minutos em vez de até duas horas.
Essa é uma melhoria significativa na velocidade decorrente da capacidade de escalar por meio da automação e orquestração. E embora não seja um projeto ambicioso para todo o data center, ele aborda um ponto problemático específico que engenheiros e proprietários de aplicativos vivenciavam com frequência. Neste caso, aparentemente até 200 vezes por semana.
É exatamente assim que os netops devem abordar a automação e a orquestração dentro da rede de produção. Descobrir as tarefas que são repetíveis e consideradas triviais pelo conselho de revisão de mudanças (ou seja, que são comprovadamente não disruptivas e que a maioria dos engenheiros consegue fazer dormindo) pode resultar em oportunidades significativas de escala, o que resulta na velocidade que os proprietários de empresas e aplicativos nos dizem que precisamos atingir na rede.
Desenterrar aquelas pepitas que podem ser automatizadas com o mínimo risco de interrupção possível deixa os engenheiros livres para se concentrar nas tarefas que não são consideradas maduras para automação. Esse foco também se traduz em menor tempo para implementações de outros serviços, pois eles ficam livres de gastar uma quantidade excessiva de tempo em tarefas mais simples e repetíveis.
Não posso enfatizar o suficiente o quão crítico é adotar uma abordagem de RCP para automação de rede: uma automação consistente, previsível e repetível permitirá uma escala mais eficiente e um tempo de entrega mais rápido, com menos risco de interrupção devido a erros. Este é o casamento dos chamados modelos operacionais “modo 1” e “modo 2”, onde a confiabilidade e a estabilidade prevalecem, mas a agilidade ainda é desejável. Ao habilitar uma abordagem de CPR para automatização e orquestração na rede, as organizações podem melhorar a agilidade com muito menos risco de prejudicar a confiabilidade de uma rede encarregada de entregar muitos, muitos (em média, cerca de 200) outros aplicativos.
As redes de data center são compostas por tecnologias legadas e emergentes, muitas vezes mantidas unidas com técnicas do tipo MacGyver, que exigem chiclete e linha de pesca. Essas redes devem oferecer suporte simultaneamente a aplicativos que estão em produção há quase cinquenta anos (os mainframes ainda existem) e a aplicativos emergentes desenvolvidos com tecnologia recém-saída das fraldas (como contêineres). Ele deve entregar todos os aplicativos e fazê-lo de forma confiável e segura. Esses padrões não podem ser ignorados em favor da velocidade e frequência exigidas por aplicações mais novas e brilhantes.
Mas as redes podem atingir um equilíbrio que permita que ambos coexistam, se puderem identificar e posteriormente automatizar completamente aquelas tarefas e opções de entrega de serviços que não sejam disruptivas e sejam consideradas tarefas de caixa de seleção pelo controle de mudanças e outros aprovadores.
Afinal, nossa equação favorita para determinar o momento de pintar uma casa muda drasticamente quando os pintores envolvidos recebem rolos de pintura automáticos em vez de pincéis manuais.
Não se preocupe tanto em mudar a rede, apenas mude a equação.