A cikk írásának időpontjában egy népszerű álláskereső oldalon a «Hálózati mérnök» kifejezés körülbelül háromszáz állást hozott fel Oroszország-szerte. Összehasonlításul, a «rendszergazda» kifejezés közel 2,5 ezer állást, a «DevOps mérnök» pedig közel 800 állást ad.
Jelenti ez, hogy a hálózati mérnökök már nem szükségesek a győzedelmeskedő felhők, a Docker, a Kubernetes és a mindent átható nyilvános Wi-Fi korában?
Nézzük meg (c)
Ismerkedjünk meg. A nevem Alexej, és hálózati mérnök vagyok.
Több mint 10 éve foglalkozom hálózatokkal és több mint 15 éve dolgozom különböző *nix rendszerekkel (mert már foglalkoztam Linux-szal és FreeBSD-vel is). Dolgoztam távközlési szolgáltatóknál, nagyvállalatoknál, amelyeket „vállalati” kategóriába sorolnak, és az utóbbi időben egy „fiatal és merész” fintech cégnél dolgozom, ahol a felhők, devopsok, kubernetesek és más rémisztő szavak biztosan feleslegessé teszik engem és kollégáimat. Egyszer, talán.
Disclaimer: „Az életünkben nem minden, mindig és mindenhol, de néha és helyenként van valami” (c) Makszim Dorofejev.
A lentieket személyes véleményként kell kezelni, amely nem igényel végső igazságot, és még csak nem is teljes kutatás. Minden szereplő fiktív, minden egybeesés véletlenszerű.
Üdvözöljük a világomban.
Hol találkozhatunk egyáltalán hálózati mérnökökkel?
1. Távközlési szolgáltatók, szolgáltató cégek és egyéb integrátorok. Itt minden egyszerű: a hálózat számukra üzlet. Vagy közvetlenül adják el a kapcsolatot (szolgáltatók), vagy szolgáltatásokat nyújtanak az ügyfeleik hálózatainak elindításához / karbantartásához.
Itt sok tapasztalat van, de pénz — nem igazán (ha nem te vagy a vezető, vagy egy sikeres értékesítési menedzser). Mégis, ha szereted a hálózatokat, és csak most kezdesz, a karrier a kisebb szolgáltatóknál ideális kiindulópont lehet, még most is. (A nagyobb cégeknél minden nagyon szigorúan szabályozott, és alig van hely a kreativitásnak.) Azok a történetek is igazak, hogy a műszaki támogató mérnökből néhány év alatt C-szintű menedzser válhat, habár ezek ritkák, érthető okok miatt. Mindig van igény a munkaerőre, hiszen a fluktuáció megvalósul. Ez egyszerre jó és rossz — mindig vannak állások, másrészt a legaktívabb/legokosabb emberek gyakran gyorsan elmennek, vagy előléptetik őket, vagy más, „melegebb” helyekre igazolnak át.
2. Feltételes „vállalati”. Nem számít, hogy az alapvető tevékenysége informatikához kapcsolódik-e vagy sem. A lényeg az, hogy van saját IT osztálya, amely a vállalat belső rendszereinek működését biztosítja, beleértve az irodák hálózatát, a fiókok közötti kommunikációs csatornákat stb. Az ilyen cégeknél a hálózati mérnök feladatait „mellekállásban” a rendszergazda is elláthatja (ha a hálózati infrastruktúra kicsi, vagy külső vállalkozóra bízzák), a hálózati szakember pedig, ha van, is figyelheti a telefonhálózatot és a SAN-t (tudománya). A bérek eltérőek — nagymértékben függ a vállalkozás marginálisságától, a cég méretétől és struktúrájától. Dolgoztam olyan cégeknél, ahol a Cisco eszközöket rendszeresen „betehették” a rakományba, és olyan cégeknél is, ahol a hálózat teljes mértékben úgy épült, mint a trágyák, botok és kék szigetelő szalag, míg a szervereket soha nem frissítették (mondanom sem kell, hogy semmilyen tartalék sem volt). Itt a tapasztalat kicsit csökkent, és valószínűleg a szigorú vendor-lock területén vagy „hogyan lehet valamiből valamit csinálni” kategóriában fog kimerülni. Személy szerint nekem ott borzasztó unalmasnak tűnt, de sokan szeretik — minden elég kiszámítható és nyugodt (ha nagyobb cégekről beszélünk), „dorahá-bahato” stb. Évente legalább egyszer valamelyik nagy beszállító azt mondja, hogy kitalálta a legújabb mega-szuper-duper rendszert, ami most minden automatizál, és az összes rendszergazdát és hálózati mérnököt el lehet küldeni, csak néhányat kell hagyni, hogy nyomogassák a gombokat a szép interfészen. A valóság azonban az, hogy még ha el is tekintünk a megoldás költségétől, a hálózati mérnökök továbbra is ott maradnak. Igen, lehet, hogy a konzol helyett ismét webfelület lesz (de már nem a konkrét hardverhez, hanem egy nagy rendszerhez, amely tucatnyi és száznyi ilyen hardvert kezel), de a tudás, hogy „mi hogyan működik belül”, még mindig szükséges lesz.
3. Termékcégek, amelynek nyereségét valamilyen szoftver vagy platform fejlesztése (és gyakran üzemeltetése) hozza — ez a termék. Általában kicsik és agilisek, még messze vannak az üzleti szférák méretétől és bürokratikus működésétől. Itt találkozhatunk azokkal a devops szakemberekkel, kuber- és docker-szakértőkkel, valamint más ijesztő kifejezésekkel, amelyek biztosan feleslegessé teszik a hálózatokat és a hálózati mérnököket.
Miben különbözik a hálózati mérnök a rendszergazdától?
Az IT-n kívül állók számára nem jelent semmit. Mindkettő a fekete képernyőt bámulja és valami varázsigét ír, néha halkan káromkodva.
A programozók számára legfeljebb annyit jelent, hogy a szakterület. Az sysadminok a szervereket, a hálózati szakemberek a switch-eket és routereket adminisztrálják. Néha rosszul végzik a munkájukat, és mindenki szenved. Ha valami furcsa történik, a hálózati szakemberek is hibáztatva vannak. Csak mert f@sz, ez az oka.
Valójában a legfőbb különbség a munkához való hozzáállás. Talán pont a hálózati szakemberek között a leggyakoribb az "Ami működik, azt nem piszkálom!" megközelítés. Valami dolgot (egy gyártó termékein belül) általában csak egyféleképpen lehet megcsinálni, a doboz teljes konfigurációja — ott van, a tenyeredben. A hiba ára magas, néha nagyon magas lehet (például több száz kilométert kell utazni, hogy újraindítsd a routert, miközben több ezer ember lesz kapcsolat nélkül — ez egy teljesen szokványos helyzet a szolgáltatónál).
Szerintem ezért a hálózati mérnökök egyrészt rendkívül motiváltak a hálózat stabilitására (mivel a változások a stabilitás legnagyobb ellensége), másrészt a tudásuk mélyebben, mint szélesebb körben terjed ki (nem szükséges tucatnyi különböző démon konfigurálása, hanem a technológiák és azok megvalósítása a konkrét gyártó berendezésénél ismeretes). Ezért az adminisztrátor, aki a neten utánanézett, hogyan kell VLAN-t beállítani a Cisco-n, még nem hálózati szakember. És valószínűleg nem fog hatékonyan támogatni (és hibaelhárítani) egy összetettebb hálózatot.
De miért van szükség hálózati szakemberre, ha van the host?
További pénzért (ha nagyon nagy és kedvenc ügyfél vagy — lehet, hogy ingyen, "baráti alapon") a datacenter mérnökei beállítják a switch-eidet az igényeidnek megfelelően, és lehet, hogy még segítenek BGP-kapcsolat létesítésében a szolgáltatókkal (ha van saját alhálózatod) IP-címek bejelentéséhez).
A fő probléma az, hogy a data center nem az Ön IT részlege, hanem egy különálló cég, amelynek célja a nyereségszerzés. Ideértve Önt, mint ügyfelet is. A data center állványokat biztosít, ellátja azokat árammal és hűtéssel, valamint biztosít egy bizonyos "alapértelmezett" kapcsolódást az internethez. Ezen infrastruktúra alapján a data center elhelyezheti az Ön berendezését (colocation), bérbe adhat Önnek egy szervert (dedicated server), vagy nyújthat managed service-t (például OpenStack vagy K8s). De a data center üzlete (általában) nem az ügyfelek infrastruktúrájának adminisztrálása, mert ez a folyamat meglehetősen munkaigényes, rosszul automatizálható (még a normál data centerben is mindent automatizálni kell, ami csak lehetséges), még rosszabbul egységesíthető (mivel minden ügyfél egyedi) és egyáltalán nem kockázatmentes („beállították nekem a szervert, most meg leállt, ezért Ön a felelős!!!111”). Tehát ha a hosztolónak segítenie kell Önnek, akkor megpróbálja ezt a lehető legegyszerűbben és úgynevezett „kondó” módon tenni. Mert bonyolultan dolgozni - nem gazdaságos, legalábbis a hosztoló mérnökeinek munkaigénye szempontjából (de előfordulhatnak különböző helyzetek, lásd a diszklaimert). Ez nem jelenti azt, hogy a hosztoló mindent rosszul csinál. De egyáltalán nem biztos, hogy pontosan azt fogja csinálni, amire Önnek valójában szüksége volt.
Első pillantásra ez egy elég nyilvánvalónak tűnő dolog, de a gyakorlatomban többször is találkoztam azzal, hogy a cégek picit túlzottan bíztak a hosting szolgáltatójukban, ami nem vezetett jóra. Hosszan és részletesen kellett elmagyaráznom, hogy egyetlen SLA sem fedezi a leállásból származó veszteségeket (vannak kivételek, de ezek általában nagyon, NAGYON drágák az ügyfél számára), és hogy a hosztoló általában nem tudja, mi történik az ügyfelek infrastruktúrájában (kivéve a nagyon általános mutatószámokat). És a hosztoló a bback-upokat sem készíti el Ön helyett. Még rosszabb a helyzet, ha több hosztolója van. Bármilyen probléma esetén, ők biztosan nem fogják kideríteni Ön helyett, hogy mi is ment végül rosszul.
A valódi indokok itt ugyanazok, mint amikor az "saját admin csapat vs kiszervezés" kérdése merül fel. Ha a kockázatok értékelve vannak, a minőség megfelelő, és a vállalat nem ellenzi – miért ne próbálnánk ki? Másrészt, a hálózat az infrastruktúra egyik legalapvetőbb rétege, így aligha érdemes rá bízni a külsősökre, ha minden mást már magunk is fenntartunk.
Mikor van szükség hálózati mérnökre?
A következőkben kifejezetten a modern termékorientált cégekről lesz szó. Az operátorokkal és vállalati szektorral minden nagyjából világos – ott az utóbbi években alig változott valami, a hálózati mérnökök ott korábban is szükségesek voltak, és jelenleg is azok. Azonban a "fiatal és merész" cégekkel a helyzet nem ennyire egyértelmű. Gyakran az egész infrastruktúrájukat felhőben helyezik el, így nem is igazán van szükségük adminisztrátorokra – kivéve a felhők adminjait, természetesen. Az infrastruktúra egyrészről elég egyszerű felépítésű, másrészről jól automatizált (ansible/puppet, terraform, ci/cd… tudják, mire gondolok). De még itt is vannak olyan helyzetek, amikor elengedhetetlen a hálózati mérnök.
Példa 1, klasszikus
Tegyük fel, hogy a cég egy nyilvános ip-címmel rendelkező szerverrel kezd, ami egy adatközpontban található. Aztán a szerverek száma kettőre nő. Majd még több… Előbb-utóbb szükség van egy magánhálózatra a szerverek között. Mert a "külső" forgalom korlátozott, akár sávszélességben (például nem több mint 100 Mbit/s), akár a letöltött/átadott adatok mennyiségében havonta (különböző szolgáltatóknál különböző tarifák vannak, de a külső világba való sávszélesség általában sokkal drágább a magánhálózathoz képest).
A hoszterszolgáltató további hálózati kártyákat ad a szerverekhez, és ezeket egy külön vlan-ba köti a switch-ein. A szerverek között megjelenik egy "lapos" lokális hálózat. Kényelmes!
A szerverek száma növekszik, a forgalom a privát hálózatban is nő — biztonsági mentések, replikációk stb. A szolgáltató külön switchekre költöztet, hogy ne zavarják egymást a kliensek. A szolgáltató valamilyen switchet telepít, és beállítja őket — valószínűleg egy sík hálózatot hagyva az összes szerver között. Minden jól működik, de egy bizonyos idő után problémák merülnek fel: időnként nő a késleltetés a hostok között, a naplókban túl sok arp-csomagról van szó másodpercenként, és a pentester az audit során a helyi hálózatot teljesen átjárta, csak egy szervert megszakítva.
Mit kell tenni?
A hálózatot szeletekre kell osztani — VLAN-ok. Minden VLAN-ban saját címzést kell beállítani, egy átjárót kijelölni, ami átirányítja a forgalmat a hálózatok között. Az átjárón ACL-t kell beállítani a hozzáférés korlátozására a szeletek között, vagy akár egy külön tűzfalat is helyezni.
Példa 1, folytatás
A szerverek egy kábel segítségével csatlakoznak a helyi hálózathoz. A switchek a rackben valahogy összekapcsolódnak, de egy rack meghibásodása esetén három szomszédos is kiesik. Léteznek sémák, de a relevanciájukban vannak kétségek. Minden szerver saját publikus címmel rendelkezik, amelyet a szolgáltató ad ki és a rackhez van hozzárendelve. Azaz, ha a szervert áthelyezik, a címet is meg kell változtatni.
Mit kell tenni?
A szervereket LAG (Link Aggregation Group) segítségével két kábellel kell csatlakoztatni a rack switcheihez (ezeket is redundálni kell). A rackek közötti kapcsolatokat is redundálni kell, és "csillag" elrendezésre (vagy a népszerű CLOS-ra) kell alakítani, hogy egy rack kiesése ne befolyásolja a többit. Kijelölni a "központi" rackeket, ahol a hálózati mag elhelyezkedik, és ahová a többi rack csatlakozik. Ezzel egy időben rendbe kell tenni a publikus címzést, a szolgáltatótól (vagy a RIR-től, ha van rá lehetőség) subnet-et kell kérni, amelyet önállóan (vagy a szolgáltatón keresztül) be kell jelenteni a világ felé.
El tudja mindezt végezni egy "normális" rendszergazda, akinek nincsenek mélyreható ismeretei a hálózatokról? Nem vagyok benne biztos. Meg fogja ezt csinálni a szolgáltató? Talán igen, de részletes műszaki leírást kérnek tőled, amelyet szintén valakinek össze kell állítania, és később ellenőrizni kell, hogy minden rendben van-e.
Példa 2. Felhő
Tegyük fel, hogy van egy VPC-je valamilyen nyilvános felhőben. Ahhoz, hogy hozzáférjen az irodából vagy az on-prem részből a VPC-n belüli helyi hálózathoz, be kell állítania a kapcsolatot IPSec-en vagy dedikált csatornán keresztül. Egyfelől az IPSec olcsóbb, mivel nem kell további hardvert vásárolni, be lehet állítani egy alagutat a nyilvános IP-címmel rendelkező szervere és a felhő között. De - késlekedés, korlátozott teljesítmény (mivel a csatornát titkosítani kell), és ráadásul nem garantált kapcsolódási stabilitás (mivel a hozzáférés a szokásos interneten keresztül történik).
Mit kell tenni?
Hozza létre a kapcsolatot egy dedikált csatornán (például az AWS-nél ezt Direct Connect-nek hívják). Ehhez keressen egy partner szolgáltatót, aki összekapcsolja Önt, határozza meg a legközelebbi csatlakozási pontot (mint az Ön szolgáltatójánál, úgy a felhő szolgáltatónál is), és végül mindent állítson be. Lehet mindezt hálózati mérnök nélkül megoldani? Bizonyára, igen. De hogy fogja ezt hibaelhárítani, ha probléma merül fel - az már nem annyira egyértelmű.
Ezenkívül problémák merülhetnek fel a rendelkezésre állással a felhők között (ha több felhőt használ) vagy késleltetési problémák merülhetnek fel különböző régiók között, stb. Határozottan számos olyan eszköz jelent meg, amelyek növelik a felhőben zajló események átláthatóságát (például a Thousand Eyes), de ezek mind hálózati mérnöki eszközök, nem pedig annak helyettesítése.
Még egy tucat ilyen példát tudnék felhozni a gyakorlatomból, de úgy gondolom, egyértelmű, hogy egy csapatban, bizonyos infrastruktúrafejlettség után, kell lennie egy személynek (és a legjobb, ha több is van), aki tudja, hogyan működik a hálózat, képes beállítani a hálózati berendezéseket, és meg tudja oldani a problémákat, ha azok felmerülnek. Higgye el, lesz dolga bőven.
Mit kell tudnia egy hálózati szakembernek?
A hálózati mérnöknek nem kötelező (sőt, néha hátrányos is), hogy csak a hálózattal foglalkozzon, és semmi mással. Még ha nem is vesszük figyelembe a nyilvános felhőben szinte teljes egészében működő infrastruktúra lehetőségét (ami, akarva akaratlanul, egyre népszerűbb), és vegyünk például on-premise vagy privát felhőket, ahol a "CCNP szintű tudás" önmagában nem elegendő.
A hálózatok mellett - bár itt elképesztő mértékű tanulási lehetőség rejlik, még ha csak egy irányra összpontosítunk is (szolgáltatói hálózatok, nagyvállalatok, adatközpontok, Wi-Fi…)
Természetesen sokan közületek most a Pythonra és a többi "hálózati automatizálásra" gondolnak, de ez csak egy szükséges, de nem elégséges feltétel. Ahhoz, hogy a hálózati mérnök "sikeresen beilleszkedjen a közösségbe", képesnek kell lennie arra, hogy egy nyelvet beszéljen a fejlesztőkkel, valamint az adminisztrátor és DevOps kollégákkal. Mit jelent ez?
- Tudni kell nemcsak Linuxban felhasználóként dolgozni, hanem az adminisztrációját is végezni, legalább junior rendszergazda szinten: telepíteni a szükséges szoftvereket, újraindítani a leállt szolgáltatásokat, írni egy egyszerű systemd-unitot.
- Érteni (legalábbis általánosságban), hogyan működik a hálózati verem a Linuxban, hogyan van felépítve a hálózat a hypervizorokban és konténerekben (lxc / docker / kubernetes).
- Természetesen tudni kell dolgozni az ansible/chef/puppet vagy más SCM rendszerrel.
- Külön említést érdemel az SDN és a privát felhők hálózatai (például TungstenFabric vagy OpenvSwitch). Ez egy újabb hatalmas tudásanyag.
Röviden, a tipikus T-alakú szakembert írtam le (ahogy most divatos mondani). Úgy tűnik, semmi új, de a munkainterjúk tapasztalatai alapján messze nem minden hálózati mérnök dicsekedhet azzal, hogy legalább két témában ismeretekkel rendelkezik a fent említett listából. A gyakorlatban a "szomszédos területeken" való ismeretek hiánya nagymértékben megnehezíti nemcsak a kollégákkal való kommunikációt, hanem a vállalat által támasztott hálózati követelmények megértését is, mint a projekt legalapvetőbb infrastruktúráját. Enélkül a megértés nélkül nehéz érvelni és "eladni" az álláspontunkat a vállalatnak.
Másrészről, az a megszokott szokás, hogy "megértem, hogyan működik a rendszer" nagyon jó előnyt ad a hálózati mérnököknek a különböző "széles spektrumú szakemberekkel" szemben, akik a technológiákról cikkeket olvasnak a Habrén / Mediumon és chatelnek a Telegramon, de teljesen nem értik, hogy egy-egy szoftver hogyan működik. És ahogy tudjuk, bizonyos törvényszerűségek ismerete sikeresen helyettesíti számos tény ismeretét.
Következtetések, vagy egyszerűen TL;DR
- A hálózati adminisztrátor (mint a DBA vagy VoIP szakember) egy viszonylag szűk profilú szakember (ellentétben a rendszergazdákkal/devops-okkal/SRE-kkel), akire a kereslet nem merül fel azonnal (sőt, sokáig nem is merül fel). De ha egyszer szükség van rá, akkor valószínűleg nem pótolható külső szakértelemmel (outsourcing vagy általános adminisztrátorok, „akik még a hálózatot is figyelik”). Ami valamivel szomorúbb — az ilyen szakemberek iránti igény alacsony, és mondjuk egy 800 programozós és 30 devops-os/adminstárból álló cégben lehet, hogy csak kettő hálózati szakértő van, akik tökéletesen végzik a feladataikat. Tehát a piac eddig is kicsi volt és van, és hogy jó fizetéssel — az még kisebb.
- Másrészről, egy jó hálózati szakember a modern világban nemcsak a hálózatokat (és azok beállításának automatizálását) kell, hogy ismerje, hanem azt is, hogy az operációs rendszerek és a fölöttük futó szoftverek hogyan interakálnak a hálózatokkal. Enélkül rendkívül nehéz megérteni, mit kérnek tőled a kollégáid, és érdemben közvetíteni a kívánságaikat/követelményeiket.
- Nincs felhő, csak valaki más számítógépe. Meg kell érteni, hogy a nyilvános/privát felhők vagy a szolgáltatók „akik mindent megcsinálnak helyetted” használata nem mentesíti az alól, hogy az alkalmazásod még mindig hálózatot használ, és a hálózattal kapcsolatos problémák hatással lesznek az alkalmazásod működésére. A te választásod — ahol a kompetencia központ található, amely felelős a projekted hálózatáért.
Forrás: habr.com
