No momento da redação deste artigo, a busca em um site de empregos popular pela expressão "Engenheiro de Redes" retornava cerca de trezentas vagas em toda a Rússia. Em comparação, a busca pela frase "administrador de sistemas" exibia quase 2.5 mil vagas, enquanto "engenheiro DevOps" apresentava quase 800.
Isso significa que os profissionais de redes não são mais necessários em tempos de nuvens predominantes, Docker, Kubernetes e do onipresente Wi-Fi público?
Vamos esclarecer (c)
Vamos nos apresentar. Meu nome é Alexey e sou engenheiro de redes.
Tenho mais de 10 anos de experiência em redes e mais de 15 anos trabalhando com diversos sistemas *nix (já trabalhei tanto com Linux quanto com FreeBSD). Trabalhei em operadores de telecomunicações, em grandes empresas consideradas "enterprise", e nos últimos tempos estou atuando em uma fintech "jovem e ousada", onde nuvens, DevOps, Kubernetes e outras palavras assustadoras que certamente farão de mim e meus colegas profissionais obsoletos. Algum dia. Talvez.
aviso legal: "Na nossa vida, nem tudo é sempre e em todo lugar, mas algumas coisas, às vezes e em alguns locais" (c) Maxim Dorofeev.
Tudo o que se segue pode e deve ser visto como a opinião pessoal do autor, que não pretende ser a verdade absoluta, nem mesmo uma pesquisa completa. Todos os personagens são fictícios, e todas as coincidências são acidentais.
Bem-vindo ao meu mundo.
Onde você pode encontrar profissionais de redes?
1. Operadoras de telecomunicações, empresas de serviços e outros integradores. Aqui tudo é simples: para eles, a rede é um negócio. Eles ou vendem conectividade diretamente (operadoras) ou oferecem serviços de lançamento/manutenção das redes de seus clientes.
Aqui há muita experiência, mas pouco dinheiro — a menos que você seja um diretor ou um gerente de vendas de sucesso. No entanto, se você gosta de redes e está apenas começando, uma carreira no suporte de algum operador que não seja muito grande ainda será, mesmo agora, um ponto ideal para começar (nas grandes empresas tudo é muito roteirizado, e há pouco espaço para criatividade). Além disso, histórias sobre como alguém pode começar como engenheiro de plantão e, em poucos anos, evoluir para um gerente de nível C também são bastante reais, embora raras, por razões compreensíveis. A demanda por profissionais existe sempre, porque a rotatividade de pessoal realmente acontece. Isso é bom e ruim ao mesmo tempo — sempre há vagas, mas, por outro lado, frequentemente, os mais ativos/inteligentes acabam saindo rapidamente, seja para promoções ou para outros lugares mais "confortáveis".
2. O "enterprise" condicionalNão importa se sua atividade principal está relacionada à TI ou não. O principal é que haja um departamento de TI que cuida do funcionamento dos sistemas internos da empresa, incluindo a rede nos escritórios, canais de comunicação com as filiais, etc. As funções do engenheiro de rede em tais empresas podem ser 'conjuntamente' realizadas por um administrador de sistemas (caso a infraestrutura de rede seja pequena, ou um contratante externo cuide dela), e o especialista em rede, se existir, pode também gerenciar a telefonia e o SAN (nada demais). Os salários variam muito — dependem fortemente da margem de lucro do negócio, do tamanho da empresa e de sua estrutura. Trabalhei com empresas onde os switches eram sobrecarregados regularmente e com empresas onde a rede era feita de restos, paus e fita adesiva, e os servidores não eram atualizados nunca (não é necessário dizer que não havia reservas em nenhum lugar). A experiência aqui é muito menor, e ela, quase com certeza, estará na área de um forte vendor-lock, ou 'como fazer algo do nada'. Para mim, pessoalmente, parecia extremamente entediante, embora muitos gostem — tudo é bastante tranquilo e previsível (se estivermos falando de grandes empresas), 'dorahá-bahato', etc. Não menos que uma vez por ano, algum grande fornecedor afirma que inventou mais um mega-super-hyper-sistema, que agora automatiza tudo e pode demitir todos os sysadmins e engenheiros de rede, deixando alguns para clicar em botões em uma interface bonita. A realidade, porém, é que, mesmo se abstrairmos o custo da solução, os engenheiros de rede não desaparecerão. Sim, talvez, em vez de um console, haverá novamente uma interface web (mas não de um equipamento específico, e sim de um grande sistema que gerencia dezenas e centenas desses equipamentos), mas o conhecimento de 'como tudo dentro funciona' ainda será necessário.
3. Empresas de Produto, cujo lucro vem do desenvolvimento (e, muitas vezes, da operação) de algum software ou plataforma — o tal produto. Normalmente, são pequenas e ágeis, ainda estão longe da escala das empresas grandes e de sua burocracia. É aqui que se encontram em massa os devops, kubernetes, dockers e outras palavras assustadoras, que sem dúvida tornarão desnecessária a rede e os engenheiros de rede como um resquício obsoleto.
Como um engenheiro de rede se diferencia de um administrador de sistemas?
Na compreensão das pessoas que não são da área de TI — nada. Tanto um quanto o outro olham para a tela preta e escrevem alguns feitiços, às vezes xingando baixinho.
Na compreensão dos programadores — talvez apenas um campo de aplicação. Os administradores de sistemas gerenciam servidores, enquanto os profissionais de rede gerenciam switches e roteadores. Às vezes, eles administram mal, e tudo cai. No caso de algo estranho, também são culpados os profissionais de rede. Just because fuck you, that’s why.
Na verdade, a principal diferença é a abordagem ao trabalho. Provavelmente, é entre os profissionais de rede que mais se encontra defensores da abordagem "Funciona — não toque!". Fazer alguma coisa (dentro de um único fornecedor) geralmente só pode ser feito de uma maneira, toda a configuração do dispositivo — aqui está, na palma da mão. O custo do erro é alto, às vezes muito alto (por exemplo, você terá que viajar por várias centenas de quilômetros para reiniciar o roteador, enquanto isso várias milhares de pessoas ficarão sem conexão — uma situação bastante comum para um operador de telecomunicações).
Na minha opinião, é exatamente por isso que os engenheiros de rede, por um lado, estão extremamente motivados pela estabilidade da rede (e mudanças são o principal inimigo da estabilidade), e por outro, seus conhecimentos vão mais a fundo do que a largura (não é necessário saber como configurar dezenas de diferentes demônios, é preciso entender as tecnologias e sua implementação por um fabricante específico de equipamentos). Portanto, um administrador de sistemas que pesquisou como configurar VLAN em um Cisco ainda não é um profissional de rede. E provavelmente não conseguirá manter (e também solucionar problemas) de forma eficaz uma rede mais ou menos complexa.
Mas por que você precisaria de um profissional de rede, se você tem hospedagem?
Por uma taxa extra (e se você for um cliente muito grande e querido — talvez até gratuitamente, "por amizade"), os engenheiros do data center configurarão seus switches de acordo com suas necessidades e, possivelmente, até ajudarão a implementar a conexão BGP com os provedores (se você tiver sua própria subnet endereços IP para o anúncio).
O principal problema é que o data center não é o seu departamento de TI, mas sim uma empresa separada cujo objetivo é obter lucro. Incluindo por meio de você, como cliente. O data center fornece mais espaço, garante a eletricidade e o resfriamento, além de oferecer alguma "conectividade padrão" com a internet. Com base nessa infraestrutura, o data center pode abrigar seu equipamento (colocação), alugar um servidor (servidor dedicado) ou oferecer um serviço gerenciado (como OpenStack ou K8s). No entanto, a administração da infraestrutura dos clientes (geralmente) não é o negócio do data center, pois esse processo é bastante trabalhoso, difícil de automatizar (e em um data center normal, tudo que puder ser automatizado, o é), ainda mais difícil de padronizar (cada cliente é único) e, de fato, pode levar a reclamações ("você configurou meu servidor, mas agora ele caiu; você é o culpado!!!111"). Portanto, se o provedor de hospedagem ajudar de alguma forma, fará isso da maneira mais simples e "básica" possível. Pois fazer de forma complexa não é rentável, pelo menos do ponto de vista do esforço dos engenheiros do próprio provedor (mas as situações podem variar, consulte o aviso). Isso não significa que o provedor não fará as coisas corretamente. Mas não há garantia de que ele fará exatamente o que você realmente precisava.
À primeira vista, parece algo bastante óbvio, mas encontrei várias vezes em minha prática que as empresas começaram a confiar em seus provedores de hospedagem um pouco mais do que deveriam, e isso não trouxe bons resultados. Tive que explicar detalhadamente que nenhum SLA cobre as perdas por paradas (há exceções, mas geralmente são muito, MUITO caras para o cliente) e que o provedor não está ciente do que acontece na infraestrutura dos clientes (exceto por indicadores muito gerais). E o provedor também não faz backups por você. A situação é ainda pior se você tiver mais de um provedor. Em caso de problemas entre eles, definitivamente não estarão decidindo por você o que realmente deu errado.
Na verdade, os motivos aqui são exatamente os mesmos que na escolha entre 'equipe própria de administradores vs outsourcing'. Se os riscos foram avaliados, a qualidade está adequada e o negócio está a favor — por que não tentar? Por outro lado, a rede é uma das camadas mais básicas da infraestrutura, e dificilmente vale a pena entregá-la a terceiros, se você já está gerenciando o resto por conta própria.
Em quais casos é necessário um engenheiro de rede?
A seguir, falaremos especificamente sobre empresas de produtos modernas. Com os operadores e o setor empresarial, as coisas são mais ou menos claras — pouco mudou nos últimos anos, e engenheiros de rede sempre foram necessários. Mas com os 'jovens e ousados', a situação não é tão clara. Frequentemente, eles hospedam toda a sua infraestrutura na nuvem, então nem mesmo administradores são particularmente necessários — exceto os administradores das próprias nuvens, claro. A infraestrutura, por um lado, é bastante simples em sua estrutura, mas, por outro, é bem automatizada (ansible/puppet, terraform, ci/cd... bem, você sabe). Mas mesmo aqui existem situações em que não se pode prescindir de um engenheiro de rede.
Exemplo 1, clássico
Suponha que a empresa comece com um servidor com um endereço IP público, que está localizado em um data center. Depois, o número de servidores aumenta para dois. Depois mais... Tarde ou cedo, surge a necessidade de uma rede privada entre os servidores. Porque o tráfego 'externo' é limitado tanto em largura (não mais que 100Mbit/s, por exemplo), quanto no volume de dados baixados/enviados por mês (cada provedor tem diferentes tarifas, mas a largura para o mundo externo, geralmente, é muito mais cara do que a rede privada).
O provedor adiciona placas de rede extras aos servidores e as conecta a seus switches em um VLAN separado. Surge uma rede local 'plana' entre os servidores. Conveniente!
O número de servidores está crescendo, o tráfego na rede privada também - backups, replicações, etc. O provedor de hospedagem oferece segregá-lo em switches separados, para que você não interfira em outros clientes e eles não interfiram em você. O provedor instala alguns switches e os configura de alguma forma - provavelmente, deixando uma rede flat entre todos os seus servidores. Tudo funciona bem, mas em determinado momento começam os problemas: periodicamente surgem latências entre os hosts, nos logs reclamações sobre um número excessivo de pacotes ARP por segundo, e o pentester, durante a auditoria, teve acesso toda a sua rede interna, quebrando apenas um servidor.
O que precisa ser feito?
Dividir a rede em segmentos - VLANs. Configurar uma endereçamento próprio para cada VLAN, designar um gateway que encaminhe o tráfego entre as redes. No gateway, configurar ACL para restringir o acesso entre os segmentos, ou até mesmo instalar um firewall separado ao lado.
Exemplo 1, continuação
Os servidores estão conectados à rede interna por um cabo. Os switches nos racks estão interconectados de alguma forma, mas se houver uma falha em um rack, outros três vizinhos também caem. Existem esquemas, mas há dúvidas sobre sua atualidade. Cada servidor tem seu próprio endereço público, que é atribuído pelo provedor e vinculado ao rack. Ou seja, ao mover o servidor, é necessário alterar o endereço.
O que precisa ser feito?
Conectar os servidores usando LAG (Link Aggregation Group) com dois cabos para os switches no rack (eles também precisam ser redundantes). Reservar as conexões entre os racks, remodelá-las para uma estrutura de 'estrela' (ou o moderno CLOS), para que a queda de um rack não afete os outros. Designar racks 'centrais', onde o núcleo da rede ficará localizado, e que conectarão outros racks. Aproveitar para organizar a endereçamento público, obter uma sub-rede do provedor (ou do RIR, se possível) que será anunciada para o mundo de forma independente (ou através do provedor).
Um 'administrador de sistemas' comum, sem conhecimentos profundos em redes, consegue fazer tudo isso? Não tenho certeza. O provedor fará isso? Pode ser que sim, mas você precisará fornecer um documento de requisitos técnicos bastante detalhado, que também precisará ser elaborado. E depois, será necessário supervisionar se tudo foi feito corretamente.
Exemplo 2. Nuvem
Suponha que você tenha um VPC em alguma nuvem pública. Para conseguir acesso do escritório ou de uma parte on-premises da infraestrutura à rede local dentro do VPC, você precisa configurar uma conexão via IPSec ou um link dedicado. Por um lado, o IPSec é mais barato, pois você não precisa comprar hardware adicional, podendo configurar um túnel entre o seu servidor com endereço público e a nuvem. Mas isso traz latências, desempenho limitado (pois o canal precisa ser criptografado) e conectividade não garantida (já que o acesso é feito pela internet comum).
O que precisa ser feito?
Estabelecer uma conexão através de um link dedicado (por exemplo, na AWS isso é chamado de Direct Connect). Para isso, encontre um parceiro operador que faça a conexão, determine o ponto de interconexão mais próximo de você (tanto do seu lado quanto do operador para a nuvem) e, finalmente, configure tudo. É possível fazer tudo isso sem um engenheiro de redes? Certamente, sim. Mas como solucionar problemas sem ele em caso de dificuldades já não é tão claro.
Além disso, podem surgir problemas de disponibilidade entre nuvens (se você tiver uma multicloud) ou problemas de latência entre diferentes regiões, etc. Sem dúvida, hoje existem muitas ferramentas que aumentam a transparência do que acontece na nuvem (como o Thousand Eyes), mas são ferramentas para engenheiros de redes, e não um substituto.
Eu poderia listar mais uma dúzia de exemplos práticos, mas acredito que esteja claro que, em uma equipe, a partir de um certo nível de desenvolvimento da infraestrutura, deve haver uma pessoa (ou melhor, mais de uma) que saiba como a rede funciona, consiga configurar o equipamento de rede e resolver problemas se eles surgirem. Acredite, haverá muito trabalho para essa pessoa.
O que um engenheiro de redes deve saber?
Não é de forma alguma obrigatório (e, às vezes, até prejudicial) que um engenheiro de redes se dedique apenas à rede e nada mais. Mesmo sem considerar a infraestrutura que vive quase totalmente na nuvem pública (que, de qualquer forma, está se tornando cada vez mais popular), e levando em conta, por exemplo, nuvens on-premises ou privadas, onde apenas "conhecimentos no nível CCNP" não são suficientes.
Além das redes em si — aqui há um campo vasto para estudo, mesmo se concentrando apenas em uma única direção (redes de provedores, corporativas, data centers, Wi-Fi...)
Certamente, muitos de vocês agora lembram do Python e de outras "automações de rede", mas isso é apenas uma condição necessária, não suficiente. Para que um engenheiro de rede "se integre com sucesso à equipe", ele deve ser capaz de se comunicar na mesma língua tanto com desenvolvedores quanto com colegas administradores/devops. O que isso significa?
- Deve ser capaz não apenas de trabalhar no Linux como usuário, mas também de administrá-lo, pelo menos no nível de um administrador júnior: instalar o software necessário, reiniciar um serviço que caiu, escrever uma unidade systemd simples.
- Entender (pelo menos em termos gerais) como funciona a pilha de rede no Linux, como as redes são organizadas em hipervisores e contêineres (lxc / docker / kubernetes).
- Naturalmente, deve saber trabalhar com ansible/chef/puppet ou outro sistema de SCM.
- Merece destaque em separado o SDN e as redes para nuvens privadas (por exemplo, TungstenFabric ou OpenvSwitch). Este é mais um enorme conjunto de conhecimentos.
Resumindo, descrevi o típico especialista T-shape (como se diz atualmente). Embora não pareça nada novo, por experiência em entrevistas, nem todos os engenheiros de rede podem se gabar de conhecimentos em pelo menos dois tópicos da lista acima. Na prática, a falta de conhecimentos "em áreas relacionadas" dificulta muito não apenas a comunicação com os colegas, mas também a compreensão das exigências que os negócios impõem à rede, como a infraestrutura de nível mais baixo do projeto. E sem essa compreensão, torna-se mais difícil defender sua opinião de forma argumentada e "vendê-la" ao negócio.
Por outro lado, esse hábito de "entender como o sistema funciona" dá aos profissionais de rede uma grande vantagem sobre diversos "especialistas de amplo espectro", que conhecem as tecnologias apenas por artigos no Habr/Médio e em chats no Telegram, mas não têm ideia sobre os princípios de funcionamento de determinado software. E o conhecimento de certas regularidades, como se sabe, substitui com sucesso o conhecimento de muitos fatos.
Conclusões ou apenas TL;DR
- O administrador de rede (assim como o DBA ou engenheiro de VoIP) é um especialista de perfil bastante específico (diferente de administradores de sistemas/devops/SRE), cuja necessidade não surge imediatamente (e pode não surgir por um bom tempo, na verdade). Mas, quando essa necessidade aparece, é difícil substituí-lo por expertise externa (outsourcing ou administradores gerais que "também monitoram a rede"). O que é ainda mais triste é que a demanda por esses especialistas é baixa, e, em uma empresa com 800 programadores e 30 devops/admins, pode haver apenas dois profissionais de rede que desempenham bem suas funções. Ou seja, o mercado foi e ainda é bastante pequeno, e para bons salários — ainda menor.
- Por outro lado, um bom profissional de rede no mundo moderno deve saber não apenas sobre redes (e como automatizar sua configuração), mas também como os sistemas operacionais e softwares que rodam sobre essas redes interagem com elas. Sem esse conhecimento, será muito difícil entender as solicitações dos colegas e comunicar (de forma fundamentada) suas necessidades/exigências a eles.
- Não existe nuvem, é apenas o computador de outra pessoa. É importante entender que o uso de nuvens públicas/privadas ou serviços de provedores de hospedagem "que fazem tudo para você" não elimina o fato de que seu aplicativo ainda usa uma rede, e problemas nessa rede afetarão o funcionamento do seu aplicativo. Sua escolha é onde estará o centro de competência responsável pela rede do seu projeto.
Fonte: habr.com
