En el moment d'escriure aquest article, una cerca en un lloc de treball popular per a la frase "Enginyer de xarxa" va retornar unes tres-centes vacants a tota Rússia. Per comparar, una cerca de la frase "administrador del sistema" retorna gairebé 2.5 mil vacants i "enginyer DevOps": gairebé 800.
Vol dir això que els usuaris de xarxa ja no són necessaris en temps de núvols victoriosos, Docker, Kubernetes i Wi-Fi públic omnipresent?
Anem a esbrinar-ho (c)
Coneixem-nos. Em dic Alexey i sóc un treballador de xarxes.
He estat involucrat en xarxes durant més de 10 anys i he estat treballant amb diversos sistemes *nix durant més de 15 anys (vaig tenir l'oportunitat de jugar tant amb Linux com amb FreeBSD). Vaig treballar en operadors de telecomunicacions, grans empreses que es consideren “empresa”, i recentment he estat treballant en fintech “jove i atrevida”, on núvols, devops, kubernetes i altres paraules espantoses que definitivament em faran innecessaris a mi i als meus companys. . Algun dia. Pot ser.
exempció de responsabilitat: "A la nostra vida, no tot és sempre i a tot arreu, sinó alguna cosa, de vegades en llocs" (c) Maxim Dorofeev.
Tot el que s'escriu a continuació pot i s'ha de considerar l'opinió personal de l'autor, que no pretén ser la veritat definitiva, ni tan sols un estudi de ple dret. Tots els personatges són ficticis, totes les coincidències són aleatòries.
Benvingut al meu món.
Fins i tot on pots conèixer networkers?
1. Operadors de telecomunicacions, empreses de serveis i altres integradors. Aquí tot és senzill: la xarxa per a ells és un negoci. Venen directament connectivitat (operadors) o ofereixen serveis per llançar/mantenir les xarxes dels seus clients.
Hi ha molta experiència aquí, però no molts diners (tret que siguis un director o un gerent de vendes d'èxit). I, tanmateix, si t'agraden les xarxes, i estàs tot just al començament del teu viatge, una carrera de suport a algun operador no molt gran serà, fins i tot ara, un punt de partida ideal (en les federals tot està molt guionat, i té poc espai per a la creativitat). Bé, les històries sobre com pots passar d'un enginyer de servei en uns quants anys a un gerent de nivell C també són força reals, encara que rares, per raons òbvies. Sempre hi ha necessitat de personal, perquè es produeix la rotació. Això és bo i dolent alhora -sempre hi ha vacants, en canvi-, sovint els més actius/intel·ligents marxen ràpidament ja sigui per promocionar-se o cap a altres llocs més “càlids”.
2. "empresa" condicional. Tant se val si la seva activitat principal està relacionada amb la informàtica o no. El més important és que disposa d'un departament informàtic propi, que assegura el funcionament dels sistemes interns de l'empresa, inclosa la xarxa a les oficines, els canals de comunicació a les oficines, etc. Les funcions d'un enginyer de xarxa en aquestes empreses poden ser realitzades "a temps parcial" per un administrador del sistema (si la infraestructura de xarxa és petita o la gestiona un contractista extern), i un especialista en xarxes, si n'hi ha, pot al mateix temps cuidar la telefonia i la SAN (no bo). Paguen de manera diferent: depèn molt de la rendibilitat del negoci, la mida de l'empresa i l'estructura. Vaig treballar amb empreses on els sistemes Cisco eren regularment "carregats en barrils", i amb empreses on la xarxa es construïa amb femta, pals i cinta blava, i els servidors no s'actualitzaven mai (no cal dir que tampoc es van proporcionar reserves). Hi ha molta menys experiència aquí, i gairebé segur que serà a l'àrea del bloqueig estricte del venedor, o "com fer alguna cosa del no-res". Personalment, em va semblar molt avorrit, tot i que a molta gent li agrada: tot és bastant mesurat i previsible (si parlem de grans empreses), "dorakha-bahato", etc. Almenys una vegada a l'any, algun venedor important diu que han creat un altre sistema mega-super-duper que ho automatitzarà tot ara i tots els administradors del sistema i els usuaris de xarxa es poden dispersar, deixant-ne un parell per prémer botons en una interfície bonica. La realitat és que, fins i tot si ignorem el cost de la solució, els usuaris de xarxa no aniran enlloc d'allà. Sí, potser en lloc de la consola tornarà a haver-hi una interfície web (però no un maquinari específic, sinó un gran sistema que gestiona desenes i centenars de peces d'aquest tipus), però el coneixement de "com funciona tot dins" encara ser necessari.
3. Empreses de producte, el benefici del qual prové del desenvolupament (i, sovint, del funcionament) d'algun programari o plataforma: aquest mateix producte. En general són petites i àgils, encara estan lluny de l'escala de les empreses i de la seva burocratització. És aquí on es troben en massa aquests mateixos devops, cubers, dockers i altres paraules terribles, cosa que sens dubte farà que els enginyers de xarxa i de xarxa siguin un rudiment innecessari.
En què és diferent un administrador de xarxa d'un administrador del sistema?
En la comprensió de la gent no de les TI - res. Tots dos miren la pantalla negra i escriuen alguns encanteris, de vegades jurant en silenci.
En la comprensió dels programadors, potser per àrea temàtica. Els administradors de sistemes administren servidors, els usuaris de xarxa administren commutadors i encaminadors. A vegades l'administració és dolenta, i tot s'esfondra per a tothom. Bé, en cas de res estrany, els networkers també en tenen la culpa. Només perquè fot-te, per això.
De fet, la diferència principal és l'enfocament del treball. Potser, és entre els networkers on hi ha la majoria de partidaris de l'enfocament "Si funciona, no el toqueu!". Per regla general, es pot fer alguna cosa (dins d'un proveïdor) d'una sola manera; tota la configuració de la caixa es troba allà mateix al palmell de la mà. El cost d'un error és alt i, de vegades, molt elevat (per exemple, haureu de recórrer diversos centenars de quilòmetres per reiniciar l'encaminador i, en aquest moment, diversos milers de persones estaran sense comunicació, una situació força habitual per a un operador de telecomunicacions) .
Al meu entendre, per això els enginyers de xarxa, d'una banda, estan molt motivats per l'estabilitat de la xarxa (i el canvi és el principal enemic de l'estabilitat) i, en segon lloc, els seus coneixements van més en profunditat que en amplitud (no cal poder configurar desenes de dimonis diferents, cal conèixer les tecnologies i la seva implementació d'un fabricant d'equip específic). És per això que un administrador del sistema que va buscar a Google com registrar una vlan en un sistema Cisco encara no és un gestor de xarxa. I és poc probable que pugui donar suport eficaçment (a més de solucionar problemes) una xarxa més o menys complexa.
Però, per què necessiteu un networker si teniu un hoster?
Per diners addicionals (i si sou un client molt gran i estimat, potser fins i tot de manera gratuïta, "com a amic"), els enginyers del centre de dades configuraran els vostres commutadors segons les vostres necessitats i potser fins i tot us ajudaran a establir una interfície BGP amb els proveïdors. (si teniu la vostra pròpia subxarxa d'adreces IP per a l'anunci).
El principal problema és que el centre de dades no és el vostre departament informàtic, és una empresa independent que té com a objectiu obtenir beneficis. Incloent a costa de vostè com a client. El centre de dades proporciona bastidors, els proporciona electricitat i fred i també proporciona una certa connectivitat "per defecte" a Internet. A partir d'aquesta infraestructura, el centre de dades pot allotjar el vostre equip (ubicació), llogar-vos un servidor (servidor dedicat) o proporcionar un servei gestionat (per exemple, OpenStack o K8s). Però el negoci d'un centre de dades (normalment) no és l'administració de la infraestructura del client, perquè aquest procés és força laboriós, poc automatitzat (i en un centre de dades normal està automatitzat tot el que és possible), unificat encara pitjor (cada client). és individual) i generalment ple de queixes ("em dius que el servidor estava configurat, però ara s'ha bloquejat, és culpa teva!!!111"). Per tant, si l'hoste t'ajuda amb alguna cosa, intentarà que sigui el més senzill i còmode possible. Perquè fer-ho difícil no és rendible, almenys des del punt de vista dels costos laborals dels enginyers d'aquest mateix hoster (però les situacions són diferents, vegeu avís legal). Això no vol dir que l'amfitrió ho faci necessàriament tot malament. Però no és gens cert que farà exactament el que realment necessitaves.
Sembla que la cosa és bastant evident, però diverses vegades a la meva pràctica m'he trobat amb el fet que les empreses van començar a confiar en el seu proveïdor d'allotjament una mica més del que haurien de fer, i això no va portar a res de bo. Vaig haver d'explicar extensament i amb detall que ni un sol SLA cobriria les pèrdues per temps d'inactivitat (hi ha excepcions, però normalment és molt, MOLT car per al client) i que l'hoster no és gens conscient del que està passant en la infraestructura dels clients (excepte indicadors molt generals). I l'hoster tampoc us fa còpies de seguretat. La situació és encara pitjor si tens més d'un hoster. En cas de problemes entre ells, sens dubte no esbrinaran per vostè què ha fallat.
De fet, els motius aquí són exactament els mateixos que quan escolliu "equip d'administració intern vs subcontractació". Si es calculen els riscos, la qualitat és satisfactòria i al negoci no li importa, per què no provar-ho. D'altra banda, la xarxa és una de les capes més bàsiques d'infraestructures, i no val la pena deixar-la a gent de fora si ja en doneu suport a tota la resta.
En quins casos es necessita un networker?
A continuació parlarem específicament de les empreses modernes d'alimentació. Amb els operadors i l'empresa, tot és clar, més o menys: poc ha canviat allà en els darrers anys i abans es necessitaven els professionals de la xarxa, i ara es necessiten. Però amb aquests mateixos “joves i agosarats” les coses no estan tan clares. Sovint col·loquen tota la seva infraestructura als núvols, de manera que ni tan sols necessiten administradors, excepte els administradors d'aquests mateixos núvols, és clar. La infraestructura, d'una banda, és força senzilla en el seu disseny, de l'altra, està ben automatitzada (ansible/titella, terraform, ci/cd... bé, ja ho saps). Però fins i tot aquí hi ha situacions en què no pots prescindir d'un enginyer de xarxa.
Exemple 1, clàssic
Suposem que una empresa comença amb un servidor amb una adreça IP pública, que es troba en un centre de dades. Després hi ha dos servidors. Després més... Tard o d'hora, caldrà una xarxa privada entre servidors. Com que el trànsit "extern" està limitat tant per l'ample de banda (no més de 100 Mbit/s, per exemple) com pel volum de descàrrega/penjada per mes (els diferents hostes tenen tarifes diferents, però l'ample de banda al món exterior sol ser molt més car que un xarxa privada).
L'amfitrió afegeix targetes de xarxa addicionals als servidors i les inclou als seus commutadors en un vlan independent. Apareix una àrea local "plana" entre servidors. Còmode!
El nombre de servidors està creixent i el trànsit a la xarxa privada també augmenta: còpies de seguretat, rèpliques, etc. L'amfitrió us ofereix traslladar-vos a commutadors separats perquè no interfereixis amb altres clients i no interfereixin amb vosaltres. L'amfitrió instal·la alguns commutadors i d'alguna manera els configura, molt probablement, deixant una xarxa plana entre tots els vostres servidors. Tot funciona bé, però en un moment determinat comencen els problemes: els retards entre hosts augmenten periòdicament, els registres es queixen de massa paquets arp per segon i durant una auditoria el pentester va fotut tota la vostra xarxa local, trencant només un servidor.
Què he de fer?
Dividiu la xarxa en segments: vlans. Configureu el vostre propi adreçament a cada vlan, seleccioneu una passarel·la que transferirà trànsit entre xarxes. Configureu acl a la passarel·la per limitar l'accés entre segments, o fins i tot instal·leu un tallafoc independent a prop.
Exemple 1, continuació
Els servidors estan connectats a la LAN amb un cable. Els interruptors dels bastidors estan connectats d'alguna manera entre si, però si hi ha un accident en un bastidor, se'n cauen tres més adjacents. Els esquemes existeixen, però hi ha dubtes sobre la seva rellevància. Cada servidor té la seva pròpia adreça pública, que és emesa per l'hoster i està lligada al bastidor. Aquells. Quan es mou un servidor, s'ha de canviar l'adreça.
Què he de fer?
Connecteu els servidors mitjançant LAG (Link Aggregation Group) amb dos cables als interruptors del bastidor (també han de ser redundants). Reserveu les connexions entre els bastidors i convertiu-los en una "estrella" (o l'ara de moda CLOS) perquè la pèrdua d'un bastidor no afecti als altres. Seleccioneu els bastidors "centrals" en què s'ubicarà el nucli de xarxa i on es connectaran altres bastidors. Al mateix temps, ordena l'adreçament públic, agafeu de l'hoster (o del RIR, si és possible) una subxarxa, que vosaltres mateixos (o a través de l'hoster) anuncieu al món.
Tot això ho pot fer un administrador del sistema "normal" que no tingui un coneixement profund de les xarxes? No n'estic segur. Ho farà l'amfitrió? Potser sí, però necessitareu una especificació tècnica força detallada, que algú també haurà d'elaborar. i després comproveu que tot estigui fet correctament.
Exemple 2: núvol
Suposem que teniu un VPC en algun núvol públic. Per accedir des de l'oficina o la part local de la infraestructura a la xarxa local dins de la VPC, heu de configurar una connexió mitjançant IPSec o un canal dedicat. D'una banda, IPSec és més barat, perquè no cal comprar maquinari addicional; podeu configurar un túnel entre el vostre servidor amb una adreça pública i el núvol. Però - retards, rendiment limitat (ja que el canal s'ha d'encriptar), a més de connectivitat no garantida (ja que l'accés es fa a través d'Internet normal).
Què he de fer?
Augmenteu una connexió a través d'un canal dedicat (per exemple, AWS l'anomena Direct Connect). Per fer-ho, busqueu un operador soci que us connecti, decidiu el punt de connexió més proper a vosaltres (tant amb l'operador com l'operador amb el núvol) i, finalment, configureu-ho tot. És possible fer tot això sense un enginyer de xarxa? Segur que sí. Però com resoldre problemes sense ell en cas de problemes ja no està tan clar.
També pot haver-hi problemes amb la disponibilitat entre núvols (si teniu un multinúvol) o problemes amb retards entre diferents regions, etc. Per descomptat, ara han aparegut moltes eines que augmenten la transparència del que està passant al núvol (els mateixos Mil ulls), però aquestes són totes les eines d'un enginyer de xarxes, i no un substitut per a ell.
Podria esbossar una dotzena d'exemples més de la meva pràctica, però crec que està clar que l'equip, a partir d'un cert nivell de desenvolupament de la infraestructura, ha de tenir una persona (preferiblement més d'una) que sàpiga com funciona la xarxa i es pugui configurar. equips de xarxa i resoldre els problemes si es produeixen. Creu-me, tindrà alguna cosa a fer
Què ha de saber un networker?
No és gens necessari (i fins i tot, de vegades, perjudicial) que un enginyer de xarxa només s'ocupi de la xarxa i res més. Encara que no ens plantegem l'opció d'una infraestructura que viu gairebé íntegrament al núvol públic (i, digui el que es digui, cada cop és més popular), i prenem, per exemple, els núvols on premise o privats, on sobre "Coneixements de nivell CCNP sols" "No marxaràs.
A més de, de fet, les xarxes, tot i que simplement hi ha un camp d'estudi infinit, fins i tot si et concentres només en una àrea (xarxes de proveïdors, empreses, centres de dades, Wi-Fi...)
Per descomptat, molts de vosaltres recordareu ara Python i altres "automatització de la xarxa", però això només és una condició necessària, però no suficient. Perquè un enginyer de xarxa "s'uneixi amb èxit a l'equip", ha de ser capaç de parlar el mateix idioma tant amb els desenvolupadors com amb els altres administradors/desenvolupadors. Què vol dir?
- poder no només treballar a Linux com a usuari, sinó també administrar-lo, almenys a nivell sysadmin-jun: instal·lar el programari necessari, reiniciar un servei fallit, escriure una unitat de sistema senzilla.
- Entendre (almenys en termes generals) com funciona la pila de xarxa a Linux, com funciona la xarxa en hipervisors i contenidors (lxc/docker/kubernetes).
- Per descomptat, poder treballar amb ansible/chef/puppet o un altre sistema SCM.
- S'ha d'escriure una línia separada sobre SDN i xarxes per a núvols privats (per exemple, TungstenFabric o OpenvSwitch). Aquesta és una altra gran capa de coneixement.
En resum, vaig descriure un típic especialista en forma de T (com està de moda dir ara). No sembla res nou, però segons l'experiència d'entrevistes, no tots els enginyers de xarxa poden presumir de conèixer almenys dos temes de la llista anterior. A la pràctica, la manca de coneixements "en àmbits relacionats" dificulta molt no només la comunicació amb els companys, sinó també la comprensió dels requisits que el negoci imposa a la xarxa, com a infraestructura de baix nivell del projecte. I sense aquesta comprensió, es fa més difícil defensar el vostre punt de vista i "vendre-lo" a les empreses.
D'altra banda, el mateix hàbit de "entendre com funciona el sistema" dóna als networkers un molt bon avantatge sobre diversos "generalistes" que coneixen les tecnologies a partir d'articles a Habré/medium i xats a Telegram, però no tenen ni idea de com fer-ho. principis amb què funciona aquest o aquell programari? I el coneixement de certs patrons, com és sabut, substitueix amb èxit el coneixement de molts fets.
Conclusions, o simplement TL;DR
- Un administrador de xarxa (com un enginyer DBA o VoIP) és un especialista amb un perfil força reduït (a diferència dels administradors de sistemes/desenvolupadors/SRE), la necessitat del qual no sorgeix immediatament (i pot ser que no surti durant molt de temps, de fet) . Però si sorgeix, és poc probable que sigui substituït per experts externs (externalitzar o administradors ordinaris de propòsit general, "que també vetllen per la xarxa"). El que és una mica més trist és que la necessitat d'aquests especialistes és petita i, condicionalment, en una empresa amb 800 programadors i 30 devops/administradors, només hi pot haver dos networkers que facin una feina excel·lent amb les seves responsabilitats. Aquells. el mercat era i és molt, molt petit, i amb un bon sou, encara menys.
- D'altra banda, un bon treballador de xarxes al món modern ha de conèixer no només les xarxes en si mateixes (i com automatitzar-ne la configuració), sinó també com interactuen amb elles els sistemes operatius i el programari que s'executen a sobre d'aquestes xarxes. Sense això, serà molt difícil entendre què et demanen els teus companys i transmetre-los (raonablement) els teus desitjos/exigències.
- No hi ha núvol, només és l'ordinador d'una altra persona. Heu d'entendre que l'ús de núvols públics/privats o els serveis d'un proveïdor d'allotjament "que ho fa tot per vosaltres clau en mà" no canvia el fet que la vostra aplicació encara utilitza la xarxa i els problemes amb aquesta afectaran el funcionament de la teva aplicació. La teva elecció és on s'ubicarà el centre de competència, que serà el responsable de la xarxa del teu projecte.
Font: www.habr.com