No momento de escribir este artigo, unha busca nun sitio de traballo popular para a frase "Enxeñeiro de rede" devolveu preto de trescentas vacantes en toda Rusia. A modo de comparación, a busca da frase "administrador do sistema" devolve case 2.5 mil vacantes e "Enxeñeiro DevOps" - case 800.
¿Significa isto que xa non se necesitan usuarios de rede en tempos de nubes victoriosas, Docker, Kubernetes e wifi pública ubicua?
Imos descubrir (c)
Imos coñecer. Chámome Alexey e son unha rede.
Levo máis de 10 anos implicado nas redes e levo máis de 15 anos traballando con varios sistemas *nix (tiven a oportunidade de xogar tanto con Linux como con FreeBSD). Traballei en operadores de telecomunicacións, grandes empresas que se consideran "empresas", e recentemente traballei en fintech "xoven e atrevida", onde nubes, devops, kubernetes e outras palabras de medo que definitivamente farán que eu e os meus compañeiros sexan innecesarios. . Algún día. Pode ser.
exención de responsabilidade: "Na nosa vida, non todo está sempre e en todas partes, senón algo, ás veces en lugares" (c) Maxim Dorofeev.
Todo o que se escribe a continuación pode e debe ser considerado a opinión persoal do autor, que non pretende ser a verdade definitiva, nin sequera un estudo completo. Todos os personaxes son ficticios, todas as coincidencias son aleatorias.
Benvido ao meu mundo.
Onde podes coñecer aos networkers?
1. Operadores de telecomunicacións, empresas de servizos e outros integradores. Aquí todo é sinxelo: a rede para eles é un negocio. Venden directamente conectividade (operadores) ou proporcionan servizos para lanzar/mantener as redes dos seus clientes.
Hai moita experiencia aquí, pero non moito diñeiro (a non ser que sexas un director ou un xestor de vendas exitoso). E aínda así, se che gustan as redes, e só estás ao comezo da túa andaina, unha carreira de apoio a algún operador non moi grande será, aínda agora, un punto de partida ideal (nas federais todo está moi guionado, e hai hai pouco espazo para a creatividade). Ben, as historias sobre como pode pasar dun enxeñeiro de servizo nuns anos a un xestor de nivel C tamén son bastante reais, aínda que raras, por razóns obvias. Sempre hai necesidade de persoal, porque se produce a rotación. Isto é bo e malo ao mesmo tempo -sempre hai prazas, por outra banda-, moitas veces os máis activos/intelixentes marchan rapidamente para promocionar ou para outros lugares "máis cálidos".
2. "empresa" condicional. Dá igual que a súa actividade principal estea relacionada coa informática ou non. O principal é que dispón dun departamento informático propio, que garante o funcionamento dos sistemas internos da empresa, incluíndo a rede nas oficinas, as canles de comunicación ás sucursais, etc. As funcións dun enxeñeiro de rede en tales empresas poden ser realizadas "a tempo parcial" por un administrador do sistema (se a infraestrutura de rede é pequena ou é xestionada por un contratista externo), e un especialista en rede, se o hai, pode ao mesmo tempo coida a telefonía e a SAN (non é bo). Pagan de forma diferente: depende moito da rendibilidade do negocio, do tamaño da empresa e da estrutura. Traballei con empresas nas que os sistemas Cisco estaban regularmente "cargados en barrís" e con empresas onde a rede se construíu con feces, paus e cinta azul, e os servidores nunca se actualizaron (non fai falta dicir que tampouco se proporcionaron reservas). Hai moita menos experiencia aquí, e case seguramente será no ámbito do estrito bloqueo de provedores ou "como facer algo da nada". Persoalmente, pareceume moi aburrido, aínda que a moita xente gústalle: todo é bastante medido e previsible (se falamos de grandes empresas), "dorakha-bahato", etc. Polo menos unha vez ao ano, algúns dos principais provedores di que crearon outro sistema mega-super-duper que automatizará todo agora e todos os administradores do sistema e usuarios de rede poden ser dispersos, deixando un par de botóns para premer nunha fermosa interface. A realidade é que, aínda que ignoremos o custo da solución, os networkers non irán a ningún lado. Si, quizais en lugar da consola haxa outra vez unha interface web (pero non un hardware específico, senón un gran sistema que xestiona decenas e centos de tales pezas de hardware), pero o coñecemento de "como funciona todo dentro" aínda así. ser necesario.
3. Empresas de produtos, cuxo beneficio provén do desenvolvemento (e, moitas veces, do funcionamento) dalgún software ou plataforma: ese mesmo produto. Normalmente son pequenos e áxiles, aínda están lonxe da escala das empresas e da súa burocratización. É aquí onde se atopan en masa eses mesmos devops, cubers, dockers e outras palabras terribles, o que sen dúbida fará que os enxeñeiros de rede e redes sexan un rudimento innecesario.
En que se diferencia un administrador de rede dun administrador de sistemas?
Na comprensión das persoas non de TI - nada. Ambos miran a pantalla negra e escriben algúns feitizos, ás veces xurándose en silencio.
Na comprensión dos programadores - quizais por área temática. Os administradores do sistema administran os servidores, os operadores de rede administran os conmutadores e os enrutadores. Ás veces a administración é mala, e todo se desmorona para todos. Ben, en caso de algo estraño, os responsables da rede tamén teñen a culpa. Só porque te jodas, por iso.
De feito, a principal diferenza é o enfoque do traballo. Quizais sexa entre os networkers que hai máis partidarios do enfoque "Se funciona, non o toques!". Como regra xeral, pódese facer algo (dentro dun só provedor) dunha soa forma; toda a configuración da caixa está alí mesmo na palma da túa man. O custo dun erro é alto, e ás veces moi alto (por exemplo, terás que percorrer varios centos de quilómetros para reiniciar o enrutador e neste momento varios miles de persoas estarán sen comunicación - unha situación bastante común para un operador de telecomunicacións) .
Na miña opinión, é por iso que os enxeñeiros de rede, por unha banda, están moi motivados pola estabilidade da rede (e o cambio é o principal inimigo da estabilidade) e, en segundo lugar, o seu coñecemento vai máis en profundidade que en amplitude (non necesita ser capaz de configurar ducias de daemons diferentes, é necesario coñecer as tecnoloxías e a súa implementación dun fabricante de equipos específico). É por iso que un administrador do sistema que buscou en Google como rexistrar un vlan nun sistema Cisco aínda non é un usuario de rede. E é improbable que poida soportar eficazmente (así como solucionar problemas) unha rede máis ou menos complexa.
Pero por que necesitas un networker se tes un hoster?
Por diñeiro adicional (e se es un cliente moi grande e querido, quizais incluso de balde, "como amigo"), os enxeñeiros do centro de datos configurarán os teus conmutadores para que se adapten ás túas necesidades e quizais mesmo che axuden a establecer unha interface BGP cos provedores. (se tes a túa propia subrede de enderezos IP para o anuncio).
O principal problema é que o centro de datos non é o teu departamento de TI, é unha empresa separada cuxo obxectivo é obter beneficios. Incluso a expensas de ti como cliente. O centro de datos proporciona bastidores, dálles electricidade e frío e tamén ofrece algunha conectividade "predeterminada" a Internet. En función desta infraestrutura, o centro de datos pode aloxar o teu equipo (colocación), alugarche un servidor (servidor dedicado) ou proporcionarche un servizo xestionado (por exemplo, OpenStack ou K8s). Pero o negocio dun centro de datos (normalmente) non é a administración da infraestrutura do cliente, porque este proceso é bastante laborioso, mal automatizado (e nun centro de datos normal todo o posible está automatizado), unificado aínda peor (cada cliente). é individual) e xeralmente está cheo de queixas ("dime que o servidor estaba configurado, pero agora fallou, é culpa túa!!!111"). Polo tanto, se o anfitrión che axuda con algo, intentará facelo o máis sinxelo e cómodo posible. Porque facelo difícil non é rendible, polo menos dende o punto de vista dos custos laborais dos enxeñeiros deste mesmo hoster (pero as situacións son distintas, ver a renuncia de responsabilidade). Isto non significa que o anfitrión fará necesariamente todo mal. Pero non é para nada un feito que fará exactamente o que realmente necesitabas.
Parece que a cousa é bastante obvia, pero varias veces na miña práctica atopeime co feito de que as empresas comezaron a confiar no seu provedor de hospedaxe un pouco máis do que deberían, e isto non levou a nada bo. Tiven que explicar detalladamente e detalladamente que nin un só SLA cubriría as perdas derivadas do tempo de inactividade (hai excepcións, pero normalmente é moi, MOI caro para o cliente) e que o hospedador non é nada consciente do que está a suceder en a infraestrutura dos clientes (salvo indicadores moi xerais). E o host tampouco fai copias de seguridade para ti. A situación é aínda peor se tes máis dun hoster. En caso de problemas entre eles, certamente non descubrirán por ti o que pasou mal.
En realidade, os motivos aquí son exactamente os mesmos que cando se elixe "equipo de administración interno vs subcontratar". Se se calculan os riscos, a calidade é satisfactoria e o negocio non lle importa, por que non probalo. Por outra banda, a rede é unha das capas máis básicas de infraestrutura, e case non paga a pena deixala a rapaces de fóra se xa soportas todo o demais.
En que casos é necesario un networker?
A continuación falaremos en concreto das empresas de alimentación modernas. Cos operadores e as empresas, todo está claro, máis ou menos: pouco cambiou alí nos últimos anos e antes necesitábanse usuarios de rede, e son necesarios agora. Pero con eses mesmos "xovens e atrevidos" as cousas non están tan claras. A miúdo colocan toda a súa infraestrutura nas nubes, polo que nin sequera necesitan administradores, excepto os administradores desas mesmas nubes, por suposto. A infraestrutura, por unha banda, é bastante sinxela no seu deseño, por outra, está ben automatizada (ansible/titere, terraform, ci/cd... bueno, xa sabes). Pero incluso aquí hai situacións nas que non podes prescindir dun enxeñeiro de rede.
Exemplo 1, clásico
Supoñamos que unha empresa comeza cun servidor cun enderezo IP público, que se atopa nun centro de datos. Despois hai dous servidores. Despois máis... Tarde ou cedo, haberá que ter unha rede privada entre servidores. Porque o tráfico "externo" está limitado tanto polo ancho de banda (non máis de 100 Mbit/s, por exemplo) como polo volume de descargas/cargas ao mes (os diferentes servidores teñen tarifas diferentes, pero o ancho de banda para o mundo exterior adoita ser moito máis caro que un rede privada).
O servidor engade tarxetas de rede adicionais aos servidores e inclúeas nos seus conmutadores nun vlan separado. Aparece unha área local "plana" entre os servidores. Cómodo!
O número de servidores crece e tamén medra o tráfico na rede privada: copias de seguridade, réplicas, etc. O host ofréceche moverte a interruptores separados para que non interfira con outros clientes e non interfiran contigo. O servidor instala algúns interruptores e configúraos dalgún xeito, moi probablemente, deixando unha rede plana entre todos os teus servidores. Todo funciona ben, pero nun momento determinado comezan os problemas: os atrasos entre hosts aumentan periódicamente, os rexistros quéixanse de demasiados paquetes arp por segundo e durante unha auditoría o pentester fodiu toda a túa rede local, rompendo só un servidor.
Que se debe facer?
Divide a rede en segmentos - vlans. Configure o seu propio enderezo en cada vlan, seleccione unha pasarela que transferirá o tráfico entre as redes. Configure acl na pasarela para limitar o acceso entre segmentos ou incluso instale un firewall separado nas proximidades.
Exemplo 1, continuación
Os servidores están conectados á LAN cun cable. Os interruptores dos bastidores están dalgún xeito conectados entre si, pero se hai un accidente nun bastidor, caen outros tres adxacentes. Os esquemas existen, pero hai dúbidas sobre a súa relevancia. Cada servidor ten o seu propio enderezo público, que é emitido polo host e está ligado ao rack. Eses. Cando se move un servidor, hai que cambiar o enderezo.
Que se debe facer?
Conecte os servidores mediante LAG (Link Aggregation Group) con dous cables aos interruptores do rack (tamén deben ser redundantes). Reserva as conexións entre os bastidores e convérteos nunha "estrela" (ou o agora de moda CLOS) para que a perda dun bastidor non afecte ós outros. Seleccione bastidores "centrais" nos que se situará o núcleo de rede e onde se conectarán outros racks. Ao mesmo tempo, ordena o enderezo público, toma do servidor (ou do RIR, se é posible) unha subrede, que ti mesmo (ou a través do servidor) anuncias ao mundo.
Todo isto pode ser feito por un administrador do sistema "común" que non teña un coñecemento profundo das redes? Non estou seguro. Fará isto o anfitrión? Quizais o fará, pero necesitarás unha especificación técnica bastante detallada, que alguén tamén terá que elaborar. e despois comprobar que todo está feito correctamente.
Exemplo 2: Nube
Digamos que tes un VPC nalgunha nube pública. Para acceder desde a oficina ou a parte local da infraestrutura á rede local dentro da VPC, cómpre configurar unha conexión a través de IPSec ou unha canle dedicada. Por unha banda, IPSec é máis barato, porque non é necesario comprar hardware adicional; podes configurar un túnel entre o teu servidor cun enderezo público e a nube. Pero - atrasos, rendemento limitado (xa que a canle debe ser cifrada), ademais de conectividade non garantida (xa que o acceso é a través da Internet normal).
Que se debe facer?
Cree unha conexión a través dunha canle dedicada (por exemplo, AWS chámalle Conexión directa). Para iso, busca un operador socio que te conecte, decida o punto de conexión máis próximo a ti (tanto ti co operador como o operador coa nube) e, finalmente, configura todo. É posible facer todo isto sen un enxeñeiro de rede? Seguro que si. Pero como solucionar problemas sen el en caso de problemas xa non está tan claro.
Tamén pode haber problemas coa dispoñibilidade entre nubes (se tes unha multinube) ou problemas con atrasos entre distintas rexións, etc. Por suposto, agora apareceron moitas ferramentas que aumentan a transparencia do que está a suceder na nube (os mesmos Mil Ollos), pero todas estas son ferramentas dun enxeñeiro de rede, e non un substituto para el.
Podería esbozar unha ducia de exemplos deste tipo da miña práctica, pero creo que está claro que o equipo, partindo dun certo nivel de desenvolvemento da infraestrutura, debe ter unha persoa (preferentemente máis dunha) que coñeza o funcionamento da rede e poida configurar. equipos de rede e resolver problemas se xorden. Créeme, terá algo que facer
Que debería saber un networker?
Non é para nada necesario (e incluso, ás veces, prexudicial) que un enxeñeiro de rede se ocupe só da rede e nada máis. Aínda que non nos plantexamos a opción cunha infraestrutura que vive case na súa totalidade na nube pública (e, diga o que se diga, cada vez é máis popular), e tomemos, por exemplo, a nube local ou privada, onde sobre "Coñecemento de nivel CCNP só" "Non marcharás.
Ademais das redes, de feito, aínda que hai un campo infinito de estudo, aínda que te concentres só nunha área (redes de provedores, empresas, centros de datos, Wi-Fi...)
Por suposto, moitos de vós recordaredes agora Python e outras "automatizacións de rede", pero esta é só unha condición necesaria, pero non suficiente. Para que un enxeñeiro de rede se "úna con éxito ao equipo", debe ser capaz de falar o mesmo idioma tanto cos desenvolvedores como con outros administradores/desenvolvedores. Qué significa?
- ser capaz non só de traballar en Linux como usuario, senón tamén de administralo, polo menos a nivel sysadmin-jun: instalar o software necesario, reiniciar un servizo fallido, escribir unha simple unidade de sistema.
- Comprender (polo menos en termos xerais) como funciona a pila de rede en Linux, como funciona a rede en hipervisores e contedores (lxc/docker/kubernetes).
- Por suposto, poder traballar con ansible/chef/puppet ou outro sistema SCM.
- Debe escribirse unha liña separada sobre SDN e redes para nubes privadas (por exemplo, TungstenFabric ou OpenvSwitch). Esta é outra gran capa de coñecemento.
En resumo, describín un típico especialista en forma de T (como está de moda dicir agora). Parece nada novo, pero segundo a experiencia de entrevistas, non todos os enxeñeiros de rede poden presumir de coñecer polo menos dous temas da lista anterior. Na práctica, a falta de coñecemento "en campos relacionados" dificulta moito non só a comunicación cos compañeiros, senón tamén a comprensión dos requisitos que as empresas colocan na rede, como a infraestrutura de menor nivel do proxecto. E sen este entendemento, faise máis difícil defender o seu punto de vista e "venderllo" ás empresas.
Por outra banda, o mesmo hábito de "comprender como funciona o sistema" dá aos usuarios de redes unha moi boa vantaxe sobre varios "xeralistas" que coñecen tecnoloxías a partir de artigos sobre Habré/medium e chats en Telegram, pero non teñen absolutamente nin idea de como facer. principios sobre este ou aquel software? E o coñecemento de certos patróns, como é sabido, substitúe con éxito o coñecemento de moitos feitos.
Conclusións, ou só TL;DR
- Un administrador de rede (como un enxeñeiro DBA ou VoIP) é un especialista cun perfil bastante estreito (a diferenza dos administradores de sistemas/desenvolvedores/SRE), cuxa necesidade non xorde inmediatamente (e pode que non xurda durante moito tempo, de feito) . Pero se se produce, é improbable que sexa substituído por expertos externos (subcontratar ou administradores comúns de propósito xeral, "que tamén coidan da rede"). O que é algo máis triste é que a necesidade de tales especialistas é pequena e, condicionalmente, nunha empresa con 800 programadores e 30 devops/administradores, pode haber só dous networkers que fagan un excelente traballo coas súas responsabilidades. Eses. o mercado era e é moi, moi pequeno, e cun bo soldo, aínda menos.
- Por outra banda, un bo creador de redes no mundo moderno debe coñecer non só as propias redes (e como automatizar a súa configuración), senón tamén como interactúan con elas os sistemas operativos e o software que se executan enriba destas redes. Sen isto, será moi difícil comprender o que che piden os teus compañeiros e transmitirlles (razoablemente) os teus desexos/esixencias.
- Non hai nube, é só o ordenador doutra persoa. Debes entender que o uso de nubes públicas/privadas ou os servizos dun provedor de hospedaxe "que fai todo por ti de forma chave en man" non cambia o feito de que a túa aplicación aínda usa a rede, e os problemas con ela afectarán o funcionamento da rede. a súa aplicación. A túa elección é onde estará situado o centro de competencias, que será o responsable da rede do teu proxecto.
Fonte: www.habr.com