No momento em que este artigo foi escrito, uma pesquisa em um site de empregos popular pela frase “Engenheiro de Rede” retornou cerca de trezentas vagas em toda a Rússia. Para efeito de comparação, uma busca pela frase “administrador de sistemas” retorna quase 2.5 mil vagas, e “engenheiro DevOps” - quase 800.
Isso significa que os networkers não são mais necessários em tempos de nuvens vitoriosas, Docker, Kubernetes e Wi-Fi público onipresente?
Vamos descobrir (c)
Vamos nos conhecer. Meu nome é Alexey e sou um networker.
Estou envolvido com redes há mais de 10 anos e trabalho com vários sistemas *nix há mais de 15 anos (tive a oportunidade de mexer tanto no Linux quanto no FreeBSD). Trabalhei em operadoras de telecomunicações, grandes empresas consideradas “empresariais”, e recentemente tenho trabalhado em fintech “jovens e ousadas”, onde nuvens, devops, kubernetes e outras palavras assustadoras que com certeza tornarão eu e meus colegas desnecessários . Algum dia. Talvez.
isenção de responsabilidade: “Na nossa vida, nem tudo está sempre e em todo lugar, mas alguma coisa, às vezes em alguns lugares” (c) Maxim Dorofeev.
Tudo o que está escrito a seguir pode e deve ser considerado opinião pessoal do autor, que não pretende ser a verdade última, nem mesmo um estudo completo. Todos os personagens são fictícios, todas as coincidências são aleatórias.
Bem vindo ao meu mundo.
Onde você pode conhecer networkers?
1. Operadoras de telecomunicações, empresas de serviços e outros integradores. Tudo é simples aqui: a rede para eles é um negócio. Eles vendem diretamente conectividade (operadoras) ou fornecem serviços de lançamento/manutenção das redes de seus clientes.
Há muita experiência aqui, mas pouco dinheiro (a menos que você seja um diretor ou um gerente de vendas de sucesso). E ainda assim, se você gosta de redes e está apenas no início de sua jornada, uma carreira de suporte a alguma operadora não muito grande será, mesmo agora, um ponto de partida ideal (nas federais tudo é muito roteirizado, e aí há pouco espaço para criatividade). Bem, histórias sobre como você pode passar de um engenheiro de plantão em alguns anos para um gerente de nível C também são bastante reais, embora raras, por razões óbvias. Sempre há necessidade de pessoal, porque ocorre rotatividade. Isto é bom e ruim ao mesmo tempo - sempre há vagas, por outro lado - muitas vezes os mais ativos/inteligentes saem rapidamente ou para promoção ou para outros lugares “mais quentes”.
2. “Empresa” condicional. Não importa se sua atividade principal está relacionada à TI ou não. O principal é que possui um departamento de informática próprio, que garante o funcionamento dos sistemas internos da empresa, incluindo rede nos escritórios, canais de comunicação com filiais, etc. As funções de um engenheiro de rede nessas empresas podem ser desempenhadas “em tempo parcial” por um administrador de sistema (se a infraestrutura de rede for pequena ou for gerenciada por um contratante externo), e um especialista em rede, se houver, pode, no ao mesmo tempo cuidar da telefonia e SAN (não é bom). Eles pagam de forma diferente - depende muito da rentabilidade do negócio, do tamanho da empresa e da estrutura. Trabalhei com empresas onde os sistemas Cisco eram regularmente “carregados em barris” e com empresas onde a rede era construída a partir de fezes, paus e fita azul, e os servidores nunca eram atualizados (é desnecessário dizer que também não foram fornecidas reservas). Há muito menos experiência aqui, e quase certamente será na área de estrito bloqueio de fornecedor, ou “como fazer algo do nada”. Pessoalmente, achei extremamente chato, embora muitas pessoas gostem - tudo é bastante comedido e previsível (se estamos falando de grandes empresas), “dorakha-bahato”, etc. Pelo menos uma vez por ano, algum grande fornecedor diz que criou outro sistema mega-super-duper que irá automatizar tudo agora e todos os administradores de sistema e redes podem ser dispersos, deixando alguns para pressionar botões em uma interface bonita. A realidade é que, mesmo que ignoremos o custo da solução, os networkers não irão a lado nenhum a partir daí. Sim, talvez em vez do console haja novamente uma interface web (mas não uma peça específica de hardware, mas um grande sistema que gerencia dezenas e centenas dessas peças de hardware), mas o conhecimento de “como tudo funciona dentro” ainda será ser necessário.
3. Empresas de produtos, cujo lucro vem do desenvolvimento (e, muitas vezes, da operação) de algum software ou plataforma – esse mesmo produto. Geralmente são pequenos e ágeis, ainda estão longe da escala das empresas e da sua burocratização. É aqui que esses mesmos devops, cubers, dockers e outras palavras terríveis são encontrados em massa, o que certamente tornará a rede e os engenheiros de rede um rudimento desnecessário.
Qual a diferença entre um networker e um administrador de sistema?
No entendimento de quem não é de TI - nada. Ambos olham para a tela preta e escrevem alguns feitiços, às vezes xingando baixinho.
Na compreensão dos programadores - talvez por área temática. Os administradores de sistema administram servidores, os operadores de rede administram switches e roteadores. Às vezes a administração é ruim e tudo desmorona para todos. Bem, em caso de algo estranho, a culpa também é dos networkers. Só porque vá se foder, é por isso.
Na verdade, a principal diferença é a abordagem do trabalho. Talvez seja entre os networkers que há mais defensores da abordagem “Se funcionar, não toque!”. Via de regra, algo pode ser feito (dentro de um fornecedor) de uma só forma: toda a configuração da caixa está ali na palma da sua mão. O custo de um erro é alto e às vezes muito alto (por exemplo, você terá que viajar várias centenas de quilômetros para reiniciar o roteador e, neste momento, vários milhares de pessoas ficarão sem comunicação - uma situação bastante comum para uma operadora de telecomunicações) .
Na minha opinião, é por isso que os engenheiros de rede, por um lado, são extremamente motivados pela estabilidade da rede (e a mudança é o principal inimigo da estabilidade) e, por outro, o seu conhecimento é mais profundo do que amplo (você não precisa ser capaz de configurar dezenas de daemons diferentes, você precisa conhecer as tecnologias e sua implementação de um fabricante de equipamento específico). É por isso que um administrador de sistema que pesquisou no Google como registrar uma vlan em um sistema Cisco ainda não é um networker. E é improvável que ele seja capaz de apoiar efetivamente (bem como solucionar problemas) uma rede mais ou menos complexa.
Mas por que você precisa de um networker se você tem um hoster?
Por dinheiro adicional (e se você for um cliente muito grande e querido, talvez até de graça, “como amigo”), os engenheiros do data center configurarão seus switches para atender às suas necessidades e talvez até o ajudem a estabelecer uma interface BGP com provedores (se você tiver sua própria sub-rede de endereços IP para o anúncio).
O principal problema é que o data center não é o seu departamento de TI, é uma empresa separada cujo objetivo é obter lucro. Inclusive às custas de você como cliente. O data center fornece racks, fornece eletricidade e frio e também fornece alguma conectividade “padrão” à Internet. Com base nesta infraestrutura, o data center pode hospedar seu equipamento (colocation), alugar um servidor para você (servidor dedicado) ou fornecer um serviço gerenciado (por exemplo, OpenStack ou K8s). Mas o negócio de um data center (normalmente) não é a administração da infraestrutura do cliente, porque esse processo é bastante trabalhoso, pouco automatizado (e em um data center normal tudo o que é possível é automatizado), unificado ainda pior (cada cliente é individual) e geralmente repleto de reclamações (“você me disse que o servidor foi configurado, mas agora ele travou, é tudo culpa sua!!!111”). Portanto, se o hoster ajudar você em alguma coisa, ele tentará torná-la o mais simples e conveniente possível. Porque fazer difícil não é lucrativo, pelo menos do ponto de vista dos custos trabalhistas dos engenheiros deste mesmo hoster (mas as situações são diferentes, veja o aviso). Isso não significa que o hoster necessariamente fará tudo mal. Mas não é fato que ele fará exatamente o que você realmente precisa.
Parece que a coisa é bastante óbvia, mas várias vezes na minha prática me deparei com o fato de que as empresas começaram a confiar no seu provedor de hospedagem um pouco mais do que deveriam, e isso não levou a nada de bom. Tivemos que explicar detalhadamente que nenhum SLA cobrirá perdas por tempo de inatividade (há exceções, mas geralmente é muito, MUITO caro para o cliente) e que o hoster não está ciente do que está acontecendo em infra-estrutura dos clientes (excepto indicadores muito gerais). E o hoster também não faz backups para você. A situação é ainda pior se você tiver mais de um hoster. Caso haja algum problema entre eles, certamente não descobrirão para você o que deu errado.
Na verdade, os motivos aqui são exatamente os mesmos de quando se escolhe “equipe administrativa interna versus terceirizada”. Se os riscos são calculados, a qualidade é satisfatória e o negócio não se importa, porque não tentar. Por outro lado, a rede é uma das camadas mais básicas de infraestrutura, e não vale a pena deixá-la para pessoas de fora se você já dá suporte a todo o resto.
Em que casos é necessário um networker?
A seguir falaremos especificamente sobre as empresas alimentícias modernas. Com as operadoras e as empresas, tudo está claro, mais ou menos - pouco mudou nos últimos anos, e os networkers eram necessários lá antes, e são necessários agora. Mas com esses mesmos “jovens e ousados” as coisas não são tão claras. Muitas vezes eles colocam toda a sua infraestrutura nas nuvens, então nem mesmo precisam de administradores – exceto os administradores dessas mesmas nuvens, é claro. A infraestrutura, por um lado, é bastante simples no seu design, por outro lado, é bem automatizada (ansible/puppet, terraform, ci/cd... bem, você sabe). Mas mesmo aqui há situações em que você não pode viver sem um engenheiro de rede.
Exemplo 1, clássico
Suponha que uma empresa comece com um servidor com endereço IP público, localizado em um data center. Depois, há dois servidores. Depois mais... Mais cedo ou mais tarde, haverá necessidade de uma rede privada entre servidores. Porque o tráfego “externo” é limitado tanto pela largura de banda (não mais que 100Mbit/s por exemplo) quanto pelo volume de downloads/uploads por mês (diferentes hosters têm tarifas diferentes, mas a largura de banda para o mundo exterior é geralmente muito mais cara do que um rede privada).
O hoster adiciona placas de rede adicionais aos servidores e as inclui em seus switches em uma vlan separada. Uma área local “plana” aparece entre os servidores. Confortável!
O número de servidores está crescendo e o tráfego na rede privada também está crescendo – backups, replicações, etc. O hoster se oferece para movê-lo para switches separados para que você não interfira com outros clientes e eles não interfiram com você. O hoster instala alguns switches e os configura de alguma forma - provavelmente, deixando uma rede plana entre todos os seus servidores. Tudo funciona bem, mas em determinado momento começam os problemas: os atrasos entre os hosts aumentam periodicamente, os logs reclamam de muitos pacotes arp por segundo e durante uma auditoria o pentester fodeu toda a sua rede local, quebrando apenas um servidor.
O que devo fazer?
Divida a rede em segmentos - vlans. Configure seu próprio endereçamento em cada vlan, selecione um gateway que irá transferir o tráfego entre redes. Configure o acl no gateway para limitar o acesso entre segmentos ou até mesmo instale um firewall separado nas proximidades.
Exemplo 1, continuação
Os servidores estão conectados à LAN com um cabo. Os interruptores nos racks estão de alguma forma conectados entre si, mas se ocorrer um acidente em um rack, mais três adjacentes cairão. Existem esquemas, mas há dúvidas sobre a sua relevância. Cada servidor possui seu próprio endereço público, que é emitido pelo hoster e vinculado ao rack. Aqueles. Ao mover um servidor, o endereço deve ser alterado.
O que devo fazer?
Conecte os servidores utilizando LAG (Link Aggregation Group) com dois cabos aos switches do rack (eles também precisam ser redundantes). Reserve as conexões entre os racks e converta-as em “estrela” (ou o já na moda CLOS) para que a perda de um rack não afete os demais. Selecione racks “centrais” onde ficará localizado o núcleo da rede e onde os demais racks serão conectados. Ao mesmo tempo, coloque o endereçamento público em ordem, tire do hoster (ou do RIR, se possível) uma sub-rede, que você mesmo (ou através do hoster) anuncia ao mundo.
Tudo isso pode ser feito por um administrador de sistema “comum” que não tenha profundo conhecimento de redes? Não tenho certeza. O hoster fará isso? Talvez sim, mas você precisará de uma especificação técnica bastante detalhada, que alguém também precisará elaborar. e depois verifique se tudo foi feito corretamente.
Exemplo 2: Nuvem
Digamos que você tenha uma VPC em alguma nuvem pública. Para obter acesso do escritório ou de parte local da infraestrutura à rede local dentro da VPC, você precisa configurar uma conexão via IPSec ou um canal dedicado. Por um lado, o IPSec é mais barato, porque não há necessidade de comprar hardware adicional; você pode configurar um túnel entre seu servidor com endereço público e a nuvem. Mas - atrasos, desempenho limitado (já que o canal precisa ser criptografado), além de conectividade não garantida (já que o acesso é feito pela Internet normal).
O que devo fazer?
Crie uma conexão por meio de um canal dedicado (por exemplo, a AWS chama isso de Direct Connect). Para isso, encontre uma operadora parceira que irá conectar você, decida o ponto de conexão mais próximo de você (tanto você com a operadora quanto a operadora com a nuvem) e, por fim, configure tudo. É possível fazer tudo isso sem um engenheiro de rede? Certamente sim. Mas como solucionar problemas sem ele em caso de problemas não é mais tão claro.
Também pode haver problemas de disponibilidade entre nuvens (se você tiver uma multicloud) ou problemas com atrasos entre diferentes regiões, etc. Claro, agora surgiram muitas ferramentas que aumentam a transparência do que está acontecendo na nuvem (os mesmos Mil Olhos), mas todas essas são ferramentas de um engenheiro de rede, e não um substituto para ele.
Eu poderia esboçar mais uma dúzia de exemplos da minha prática, mas acho que está claro que a equipe, a partir de um certo nível de desenvolvimento de infraestrutura, deve ter uma pessoa (de preferência mais de uma) que saiba como a rede funciona e possa configurar equipamento de rede e resolver problemas caso surjam. Acredite em mim, ele terá algo para fazer
O que um networker deve saber?
Não é de todo necessário (e às vezes até prejudicial) que um engenheiro de rede lide apenas com a rede e nada mais. Mesmo que não consideremos a opção com uma infra-estrutura que reside quase inteiramente na nuvem pública (e, digam o que se diga, está a tornar-se cada vez mais popular), e tomemos, por exemplo, nuvens locais ou privadas, onde sobre “conhecimento apenas no nível CCNP” “Você não vai embora.
Além, de fato, de redes - embora haja simplesmente um campo infinito de estudo, mesmo que você se concentre apenas em uma área (redes de provedores, empresas, data centers, Wi-Fi...)
É claro que muitos de vocês agora se lembrarão do Python e de outras “automações de rede”, mas esta é apenas uma condição necessária, mas não suficiente. Para que um engenheiro de rede “junte-se à equipe com sucesso”, ele deve ser capaz de falar a mesma linguagem com desenvolvedores e colegas administradores/desenvolvedores. O que isso significa?
- ser capaz não apenas de trabalhar no Linux como usuário, mas também de administrá-lo, pelo menos no nível sysadmin-jun: instalar o software necessário, reiniciar um serviço com falha, escrever uma unidade systemd simples.
- Entenda (pelo menos em termos gerais) como funciona a pilha de rede no Linux, como funciona a rede em hipervisores e contêineres (lxc/docker/kubernetes).
- Claro, ser capaz de trabalhar com ansible/chef/puppet ou outro sistema SCM.
- Uma linha separada deve ser escrita sobre SDN e redes para nuvens privadas (por exemplo, TungstenFabric ou OpenvSwitch). Esta é outra enorme camada de conhecimento.
Resumindo, descrevi um típico especialista em formato de T (como está na moda dizer agora). Não parece nada novo, mas com base na experiência em entrevistas, nem todos os engenheiros de rede podem se orgulhar de ter conhecimento de pelo menos dois tópicos da lista acima. Na prática, a falta de conhecimento “em áreas afins” torna muito difícil não só a comunicação com os colegas, mas também a compreensão dos requisitos que as empresas colocam na rede, como a infraestrutura de nível mais baixo do projeto. E sem esse entendimento fica mais difícil defender seu ponto de vista e “vendê-lo” para as empresas.
Por outro lado, o mesmo hábito de “entender como o sistema funciona” dá aos networkers uma vantagem muito boa sobre vários “generalistas” que conhecem tecnologias a partir de artigos no Habré/medium e chats no Telegram, mas não têm absolutamente nenhuma ideia de como fazer isso. princípios em que este ou aquele software funciona? E o conhecimento de certos padrões, como se sabe, substitui com sucesso o conhecimento de muitos fatos.
Conclusões, ou apenas TL;DR
- Um administrador de rede (como um DBA ou engenheiro de VoIP) é um especialista com um perfil bastante restrito (ao contrário de administradores de sistema/desenvolvedores/SRE), cuja necessidade não surge imediatamente (e pode não surgir por muito tempo, na verdade) . Mas se surgir, é improvável que seja substituído por especialistas externos (terceirizados ou administradores comuns de uso geral, “que também cuidam da rede”). O que é um pouco mais triste é que a necessidade de tais especialistas é pequena e, condicionalmente, numa empresa com 800 programadores e 30 devops/administradores, pode haver apenas dois networkers que fazem um excelente trabalho com as suas responsabilidades. Aqueles. o mercado era e é muito, muito pequeno, e com um bom salário - menos ainda.
- Por outro lado, um bom networker no mundo moderno deve conhecer não apenas as próprias redes (e como automatizar sua configuração), mas também como os sistemas operacionais e softwares executados nessas redes interagem com elas. Sem isso, será extremamente difícil compreender o que os seus colegas lhe pedem e transmitir-lhes (razoavelmente) os seus desejos/exigências.
- Não há nuvem, é apenas o computador de outra pessoa. Você precisa entender que usar nuvens públicas/privadas ou os serviços de um provedor de hospedagem “que faz tudo para você em regime turnkey” não muda o fato de que seu aplicativo ainda usa a rede, e problemas com ela afetarão a operação de sua aplicação. A sua escolha é onde ficará localizado o centro de competência, que será responsável pela rede do seu projeto.
Fonte: habr.com