{"id":97373,"date":"2020-10-17T14:42:32","date_gmt":"2020-10-17T12:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/seteviki-ne-nuzhny"},"modified":"2020-10-17T14:42:32","modified_gmt":"2020-10-17T12:42:32","slug":"seteviki-ne-nuzhny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Profissionais de rede (n\u00e3o) s\u00e3o necess\u00e1rios","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

No momento da reda\u00e7\u00e3o deste artigo, a busca em um site de empregos popular pela express\u00e3o \"Engenheiro de Redes\" retornava cerca de trezentas vagas em toda a R\u00fassia. Em compara\u00e7\u00e3o, a busca pela frase \"administrador de sistemas\" exibia quase 2.5 mil vagas, enquanto \"engenheiro DevOps\" apresentava quase 800.<\/p>\n

Isso significa que os profissionais de redes n\u00e3o s\u00e3o mais necess\u00e1rios em tempos de nuvens predominantes, Docker, Kubernetes e do onipresente Wi-Fi p\u00fablico?
\nVamos esclarecer (c)<\/p>\n

\"Profissionais
\n<\/a><\/noindex>
\nVamos nos apresentar. Meu nome \u00e9 Alexey e sou engenheiro de redes. <\/p>\n

Tenho mais de 10 anos de experi\u00eancia em redes e mais de 15 anos trabalhando com diversos sistemas *nix (j\u00e1 trabalhei tanto com Linux quanto com FreeBSD). Trabalhei em operadores de telecomunica\u00e7\u00f5es, em grandes empresas consideradas \"enterprise\", e nos \u00faltimos tempos estou atuando em uma fintech \"jovem e ousada\", onde nuvens, DevOps, Kubernetes e outras palavras assustadoras que certamente far\u00e3o de mim e meus colegas profissionais obsoletos. Algum dia. Talvez.<\/p>\n

aviso legal: \"Na nossa vida, nem tudo \u00e9 sempre e em todo lugar, mas algumas coisas, \u00e0s vezes e em alguns locais\" (c) Maxim Dorofeev.<\/p>\n

Tudo o que se segue pode e deve ser visto como a opini\u00e3o pessoal do autor, que n\u00e3o pretende ser a verdade absoluta, nem mesmo uma pesquisa completa. Todos os personagens s\u00e3o fict\u00edcios, e todas as coincid\u00eancias s\u00e3o acidentais.<\/p><\/blockquote>\n

Bem-vindo ao meu mundo.<\/p>\n

Onde voc\u00ea pode encontrar profissionais de redes?<\/h3>\n

\n1. Operadoras de telecomunica\u00e7\u00f5es, empresas de servi\u00e7os e outros integradores<\/b>. Aqui tudo \u00e9 simples: para eles, a rede \u00e9 um neg\u00f3cio. Eles ou vendem conectividade diretamente (operadoras) ou oferecem servi\u00e7os de lan\u00e7amento\/manuten\u00e7\u00e3o das redes de seus clientes. <\/p>\n

Aqui h\u00e1 muita experi\u00eancia, mas pouco dinheiro \u2014 a menos que voc\u00ea seja um diretor ou um gerente de vendas de sucesso. No entanto, se voc\u00ea gosta de redes e est\u00e1 apenas come\u00e7ando, uma carreira no suporte de algum operador que n\u00e3o seja muito grande ainda ser\u00e1, mesmo agora, um ponto ideal para come\u00e7ar (nas grandes empresas tudo \u00e9 muito roteirizado, e h\u00e1 pouco espa\u00e7o para criatividade). Al\u00e9m disso, hist\u00f3rias sobre como algu\u00e9m pode come\u00e7ar como engenheiro de plant\u00e3o e, em poucos anos, evoluir para um gerente de n\u00edvel C tamb\u00e9m s\u00e3o bastante reais, embora raras, por raz\u00f5es compreens\u00edveis. A demanda por profissionais existe sempre, porque a rotatividade de pessoal realmente acontece. Isso \u00e9 bom e ruim ao mesmo tempo \u2014 sempre h\u00e1 vagas, mas, por outro lado, frequentemente, os mais ativos\/inteligentes acabam saindo rapidamente, seja para promo\u00e7\u00f5es ou para outros lugares mais \"confort\u00e1veis\".<\/p>\n

2. O \"enterprise\" condicional<\/b>N\u00e3o importa se sua atividade principal est\u00e1 relacionada \u00e0 TI ou n\u00e3o. O principal \u00e9 que haja um departamento de TI que cuida do funcionamento dos sistemas internos da empresa, incluindo a rede nos escrit\u00f3rios, canais de comunica\u00e7\u00e3o com as filiais, etc. As fun\u00e7\u00f5es 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\u00e9m gerenciar a telefonia e o SAN (nada demais). Os sal\u00e1rios variam muito \u2014 dependem fortemente da margem de lucro do neg\u00f3cio, 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\u00e3o eram atualizados nunca (n\u00e3o \u00e9 necess\u00e1rio dizer que n\u00e3o havia reservas em nenhum lugar). A experi\u00eancia aqui \u00e9 muito menor, e ela, quase com certeza, estar\u00e1 na \u00e1rea de um forte vendor-lock, ou 'como fazer algo do nada'. Para mim, pessoalmente, parecia extremamente entediante, embora muitos gostem \u2014 tudo \u00e9 bastante tranquilo e previs\u00edvel (se estivermos falando de grandes empresas), 'dorah\u00e1-bahato', etc. N\u00e3o 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\u00f5es em uma interface bonita. A realidade, por\u00e9m, \u00e9 que, mesmo se abstrairmos o custo da solu\u00e7\u00e3o, os engenheiros de rede n\u00e3o desaparecer\u00e3o. Sim, talvez, em vez de um console, haver\u00e1 novamente uma interface web (mas n\u00e3o de um equipamento espec\u00edfico, e sim de um grande sistema que gerencia dezenas e centenas desses equipamentos), mas o conhecimento de 'como tudo dentro funciona' ainda ser\u00e1 necess\u00e1rio.<\/p>\n

3. Empresas de Produto<\/b>, cujo lucro vem do desenvolvimento (e, muitas vezes, da opera\u00e7\u00e3o) de algum software ou plataforma \u2014 o tal produto. Normalmente, s\u00e3o pequenas e \u00e1geis, ainda est\u00e3o longe da escala das empresas grandes e de sua burocracia. \u00c9 aqui que se encontram em massa os devops, kubernetes, dockers e outras palavras assustadoras, que sem d\u00favida tornar\u00e3o desnecess\u00e1ria a rede e os engenheiros de rede como um resqu\u00edcio obsoleto. <\/p>\n

Como um engenheiro de rede se diferencia de um administrador de sistemas?<\/h3>\n

\nNa compreens\u00e3o das pessoas que n\u00e3o s\u00e3o da \u00e1rea de TI \u2014 nada. Tanto um quanto o outro olham para a tela preta e escrevem alguns feiti\u00e7os, \u00e0s vezes xingando baixinho. <\/p>\n

Na perspectiva dos programadores, \u00e9 apenas um dom\u00ednio espec\u00edfico. Os administradores de sistema gerenciam servidores, os especialistas em rede gerenciam switches e roteadores. \u00c0s vezes, eles cometem erros, e tudo falha. E, em caso de problemas estranhos, a culpa tamb\u00e9m \u00e9 dos especialistas em rede. Apenas porque sim, \u00e9 por isso.<\/p>\n

Na verdade, a principal diferen\u00e7a \u00e9 a abordagem ao trabalho. Provavelmente, \u00e9 entre os profissionais de rede que mais se encontra defensores da abordagem \"Funciona \u2014 n\u00e3o toque!\". Fazer alguma coisa (dentro de um \u00fanico fornecedor) geralmente s\u00f3 pode ser feito de uma maneira, toda a configura\u00e7\u00e3o do dispositivo \u2014 aqui est\u00e1, na palma da m\u00e3o. O custo do erro \u00e9 alto, \u00e0s vezes muito alto (por exemplo, voc\u00ea ter\u00e1 que viajar por v\u00e1rias centenas de quil\u00f4metros para reiniciar o roteador, enquanto isso v\u00e1rias milhares de pessoas ficar\u00e3o sem conex\u00e3o \u2014 uma situa\u00e7\u00e3o bastante comum para um operador de telecomunica\u00e7\u00f5es).<\/p>\n

Na minha opini\u00e3o, \u00e9 exatamente por isso que os engenheiros de rede, por um lado, est\u00e3o extremamente motivados pela estabilidade da rede (e mudan\u00e7as s\u00e3o o principal inimigo da estabilidade), e por outro, seus conhecimentos v\u00e3o mais a fundo do que a largura (n\u00e3o \u00e9 necess\u00e1rio saber como configurar dezenas de diferentes dem\u00f4nios, \u00e9 preciso entender as tecnologias e sua implementa\u00e7\u00e3o por um fabricante espec\u00edfico de equipamentos). Portanto, um administrador de sistemas que pesquisou como configurar VLAN em um Cisco ainda n\u00e3o \u00e9 um profissional de rede. E provavelmente n\u00e3o conseguir\u00e1 manter (e tamb\u00e9m solucionar problemas) de forma eficaz uma rede mais ou menos complexa. <\/p>\n

Mas por que voc\u00ea precisaria de um profissional de rede, se voc\u00ea tem hospedagem<\/a>?<\/b><\/p>\n

Por uma taxa extra (e se voc\u00ea for um cliente muito grande e querido \u2014 talvez at\u00e9 gratuitamente, \"por amizade\"), os engenheiros do data center configurar\u00e3o seus switches de acordo com suas necessidades e, possivelmente, at\u00e9 ajudar\u00e3o a implementar a conex\u00e3o BGP com os provedores (se voc\u00ea tiver sua pr\u00f3pria subnet endere\u00e7os IP<\/a> para o an\u00fancio).<\/p>\n

O principal problema \u00e9 que o data center n\u00e3o \u00e9 o seu departamento de TI, mas sim uma empresa separada cujo objetivo \u00e9 obter lucro. Incluindo por meio de voc\u00ea, como cliente. O data center fornece mais espa\u00e7o, garante a eletricidade e o resfriamento, al\u00e9m de oferecer alguma \"conectividade padr\u00e3o\" com a internet. Com base nessa infraestrutura, o data center pode abrigar seu equipamento (coloca\u00e7\u00e3o), alugar um servidor (servidor dedicado) ou oferecer um servi\u00e7o gerenciado (como OpenStack ou K8s). No entanto, a administra\u00e7\u00e3o da infraestrutura dos clientes (geralmente) n\u00e3o \u00e9 o neg\u00f3cio do data center, pois esse processo \u00e9 bastante trabalhoso, dif\u00edcil de automatizar (e em um data center normal, tudo que puder ser automatizado, o \u00e9), ainda mais dif\u00edcil de padronizar (cada cliente \u00e9 \u00fanico) e, de fato, pode levar a reclama\u00e7\u00f5es (\"voc\u00ea configurou meu servidor, mas agora ele caiu; voc\u00ea \u00e9 o culpado!!!111\"). Portanto, se o provedor de hospedagem ajudar de alguma forma, far\u00e1 isso da maneira mais simples e \"b\u00e1sica\" poss\u00edvel. Pois fazer de forma complexa n\u00e3o \u00e9 rent\u00e1vel, pelo menos do ponto de vista do esfor\u00e7o dos engenheiros do pr\u00f3prio provedor (mas as situa\u00e7\u00f5es podem variar, consulte o aviso). Isso n\u00e3o significa que o provedor n\u00e3o far\u00e1 as coisas corretamente. Mas n\u00e3o h\u00e1 garantia de que ele far\u00e1 exatamente o que voc\u00ea realmente precisava.<\/p>\n

\u00c0 primeira vista, parece algo bastante \u00f3bvio, mas encontrei v\u00e1rias vezes em minha pr\u00e1tica que as empresas come\u00e7aram a confiar em seus provedores de hospedagem um pouco mais do que deveriam, e isso n\u00e3o trouxe bons resultados. Tive que explicar detalhadamente que nenhum SLA cobre as perdas por paradas (h\u00e1 exce\u00e7\u00f5es, mas geralmente s\u00e3o muito, MUITO caras para o cliente) e que o provedor n\u00e3o est\u00e1 ciente do que acontece na infraestrutura dos clientes (exceto por indicadores muito gerais). E o provedor tamb\u00e9m n\u00e3o faz backups por voc\u00ea. A situa\u00e7\u00e3o \u00e9 ainda pior se voc\u00ea tiver mais de um provedor. Em caso de problemas entre eles, definitivamente n\u00e3o estar\u00e3o decidindo por voc\u00ea o que realmente deu errado.<\/p>\n

Na verdade, os motivos aqui s\u00e3o exatamente os mesmos que na escolha entre 'equipe pr\u00f3pria de administradores vs outsourcing'. Se os riscos foram avaliados, a qualidade est\u00e1 adequada e o neg\u00f3cio est\u00e1 a favor \u2014 por que n\u00e3o tentar? Por outro lado, a rede \u00e9 uma das camadas mais b\u00e1sicas da infraestrutura, e dificilmente vale a pena entreg\u00e1-la a terceiros, se voc\u00ea j\u00e1 est\u00e1 gerenciando o resto por conta pr\u00f3pria.<\/p>\n

Em quais casos \u00e9 necess\u00e1rio um engenheiro de rede?<\/b><\/p>\n

A seguir, falaremos especificamente sobre empresas de produtos modernas. Com os operadores e o setor empresarial, as coisas s\u00e3o mais ou menos claras \u2014 pouco mudou nos \u00faltimos anos, e engenheiros de rede sempre foram necess\u00e1rios. Mas com os 'jovens e ousados', a situa\u00e7\u00e3o n\u00e3o \u00e9 t\u00e3o clara. Frequentemente, eles hospedam toda a sua infraestrutura na nuvem, ent\u00e3o nem mesmo administradores s\u00e3o particularmente necess\u00e1rios \u2014 exceto os administradores das pr\u00f3prias nuvens, claro. A infraestrutura, por um lado, \u00e9 bastante simples em sua estrutura, mas, por outro, \u00e9 bem automatizada (ansible\/puppet, terraform, ci\/cd... bem, voc\u00ea sabe). Mas mesmo aqui existem situa\u00e7\u00f5es em que n\u00e3o se pode prescindir de um engenheiro de rede.<\/p>\n

Exemplo 1, cl\u00e1ssico<\/b><\/p>\n

Suponha que a empresa comece com um servidor com um endere\u00e7o IP p\u00fablico, que est\u00e1 localizado em um data center. Depois, o n\u00famero de servidores aumenta para dois. Depois mais... Tarde ou cedo, surge a necessidade de uma rede privada entre os servidores. Porque o tr\u00e1fego 'externo' \u00e9 limitado tanto em largura (n\u00e3o mais que 100Mbit\/s, por exemplo), quanto no volume de dados baixados\/enviados por m\u00eas (cada provedor tem diferentes tarifas, mas a largura para o mundo externo, geralmente, \u00e9 muito mais cara do que a rede privada).<\/p>\n

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!<\/p>\n

O n\u00famero de servidores est\u00e1 crescendo, o tr\u00e1fego na rede privada tamb\u00e9m - backups, replica\u00e7\u00f5es, etc. O provedor de hospedagem oferece segreg\u00e1-lo em switches separados, para que voc\u00ea n\u00e3o interfira em outros clientes e eles n\u00e3o interfiram em voc\u00ea. 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\u00e7am os problemas: periodicamente surgem lat\u00eancias entre os hosts, nos logs reclama\u00e7\u00f5es sobre um n\u00famero excessivo de pacotes ARP por segundo, e o pentester, durante a auditoria, teve acesso toda a sua rede interna, quebrando apenas um servidor.<\/p>\n

O que precisa ser feito?<\/i><\/p>\n

Dividir a rede em segmentos \u2014 VLANs. Configurar endere\u00e7amento pr\u00f3prio em cada VLAN, designar um gateway que redirecione o tr\u00e1fego entre as redes. No gateway, configurar ACL para restringir o acesso entre os segmentos, ou at\u00e9 mesmo colocar um firewall separado ao lado.<\/p>\n

Exemplo 1, continua\u00e7\u00e3o<\/b><\/p>\n

Os servidores est\u00e3o conectados \u00e0 rede interna por um cabo. Os switches nos racks est\u00e3o interconectados de alguma forma, mas se houver uma falha em um rack, outros tr\u00eas vizinhos tamb\u00e9m caem. Existem esquemas, mas h\u00e1 d\u00favidas sobre sua atualidade. Cada servidor tem seu pr\u00f3prio endere\u00e7o p\u00fablico, que \u00e9 atribu\u00eddo pelo provedor e vinculado ao rack. Ou seja, ao mover o servidor, \u00e9 necess\u00e1rio alterar o endere\u00e7o.<\/p>\n

O que precisa ser feito?<\/i><\/p>\n

Conectar os servidores usando LAG (Link Aggregation Group) com dois cabos para os switches no rack (eles tamb\u00e9m precisam ser redundantes). Reservar as conex\u00f5es entre os racks, remodel\u00e1-las para uma estrutura de 'estrela' (ou o moderno CLOS), para que a queda de um rack n\u00e3o afete os outros. Designar racks 'centrais', onde o n\u00facleo da rede ficar\u00e1 localizado, e que conectar\u00e3o outros racks. Aproveitar para organizar a endere\u00e7amento p\u00fablico, obter uma sub-rede do provedor (ou do RIR, se poss\u00edvel) que ser\u00e1 anunciada para o mundo de forma independente (ou atrav\u00e9s do provedor).<\/p>\n

Um 'administrador de sistemas' comum, sem conhecimentos profundos em redes, consegue fazer tudo isso? N\u00e3o tenho certeza. O provedor far\u00e1 isso? Pode ser que sim, mas voc\u00ea precisar\u00e1 fornecer um documento de requisitos t\u00e9cnicos bastante detalhado, que tamb\u00e9m precisar\u00e1 ser elaborado. E depois, ser\u00e1 necess\u00e1rio supervisionar se tudo foi feito corretamente.<\/p>\n

Exemplo 2. Nuvem<\/b><\/p>\n

Suponha que voc\u00ea tenha um VPC em alguma nuvem p\u00fablica. Para conseguir acesso do escrit\u00f3rio ou de uma parte on-premises da infraestrutura \u00e0 rede local dentro do VPC, voc\u00ea precisa configurar uma conex\u00e3o via IPSec ou um link dedicado. Por um lado, o IPSec \u00e9 mais barato, pois voc\u00ea n\u00e3o precisa comprar hardware adicional, podendo configurar um t\u00fanel entre o seu servidor com endere\u00e7o p\u00fablico e a nuvem. Mas isso traz lat\u00eancias, desempenho limitado (pois o canal precisa ser criptografado) e conectividade n\u00e3o garantida (j\u00e1 que o acesso \u00e9 feito pela internet comum). <\/p>\n

O que precisa ser feito?<\/i><\/p>\n

Estabelecer uma conex\u00e3o atrav\u00e9s de um link dedicado (por exemplo, na AWS isso \u00e9 chamado de Direct Connect). Para isso, encontre um parceiro operador que fa\u00e7a a conex\u00e3o, determine o ponto de interconex\u00e3o mais pr\u00f3ximo de voc\u00ea (tanto do seu lado quanto do operador para a nuvem) e, finalmente, configure tudo. \u00c9 poss\u00edvel fazer tudo isso sem um engenheiro de redes? Certamente, sim. Mas como solucionar problemas sem ele em caso de dificuldades j\u00e1 n\u00e3o \u00e9 t\u00e3o claro. <\/p>\n

Al\u00e9m disso, podem surgir problemas de disponibilidade entre nuvens (se voc\u00ea tiver uma multicloud) ou problemas de lat\u00eancia entre diferentes regi\u00f5es, etc. Sem d\u00favida, hoje existem muitas ferramentas que aumentam a transpar\u00eancia do que acontece na nuvem (como o Thousand Eyes), mas s\u00e3o ferramentas para engenheiros de redes, e n\u00e3o um substituto.<\/p>\n

Eu poderia listar mais uma d\u00fazia de exemplos pr\u00e1ticos, mas acredito que esteja claro que, em uma equipe, a partir de um certo n\u00edvel 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\u00e1 muito trabalho para essa pessoa. <\/p>\n

O que um engenheiro de redes deve saber?<\/b><\/p>\n

N\u00e3o \u00e9 de forma alguma obrigat\u00f3rio (e, \u00e0s vezes, at\u00e9 prejudicial) que um engenheiro de redes se dedique apenas \u00e0 rede e nada mais. Mesmo sem considerar a infraestrutura que vive quase totalmente na nuvem p\u00fablica (que, de qualquer forma, est\u00e1 se tornando cada vez mais popular), e levando em conta, por exemplo, nuvens on-premises ou privadas, onde apenas \"conhecimentos no n\u00edvel CCNP\" n\u00e3o s\u00e3o suficientes. <\/p>\n

Al\u00e9m, propriamente dito, das redes \u2014 embora aqui haja um campo vasto para estudo, mesmo se focando apenas em uma \u00e1rea espec\u00edfica (redes de provedores, corporativas, data centers, Wi-Fi...)<\/p>\n

Certamente, muitos de voc\u00eas agora lembram do Python e de outras \"automa\u00e7\u00f5es de rede\", mas isso \u00e9 apenas uma condi\u00e7\u00e3o necess\u00e1ria, n\u00e3o suficiente. Para que um engenheiro de rede \"se integre com sucesso \u00e0 equipe\", ele deve ser capaz de se comunicar na mesma l\u00edngua tanto com desenvolvedores quanto com colegas administradores\/devops. O que isso significa?<\/p>\n