A cikk írásakor egy népszerű állásoldalon a „Hálózati mérnök” kifejezésre végzett keresés mintegy háromszáz üres állást eredményezett Oroszország-szerte. Összehasonlításképpen: a „rendszergazda” kifejezésre való keresés csaknem 2.5 ezer betöltetlen állást, a „DevOps mérnök” pedig csaknem 800-at ad vissza.
Ez azt jelenti, hogy a győztes felhők, a Docker, a Kubernetes és a mindenütt nyilvános Wi-Fi idején nincs többé szükség hálózatépítőkre?
Találjuk ki (c)
Ismerkedjen. A nevem Alexey, hálózatépítő vagyok.
Több mint 10 éve foglalkozom hálózatokkal, és több mint 15 éve dolgozom különféle *nix rendszerekkel (volt alkalmam Linuxon és FreeBSD-n is bütykölni). Dolgoztam távközlési szolgáltatóknál, nagyvállalatoknál, amelyeket „vállalkozásnak” tartanak, és mostanában a „fiatal és merész” fintechben dolgozom, ahol felhők, devopok, kubernetesek és más ijesztő szavak, amelyek biztosan feleslegessé tesznek engem és a kollégáimat. . Majd egyszer. Lehet.
felelősségkizárás: „Életünkben nem minden van mindig és mindenhol, hanem valami, néha helyenként” (c) Maxim Dorofeev.
Mindent, ami alább írunk, a szerző személyes véleményének lehet és kell tekinteni, amely nem tart igényt a végső igazságra, de még csak egy teljes értékű tanulmánynak sem. Minden karakter fiktív, minden véletlen egybeesés.
Üdv a világomban.
Hol lehet netezőkkel találkozni?
1. Távközlési szolgáltatók, szolgáltató cégek és egyéb integrátorok. Itt minden egyszerű: számukra a hálózat egy üzlet. Vagy közvetlenül értékesítik az összeköttetést (üzemeltetőket), vagy szolgáltatásokat nyújtanak ügyfeleik hálózatának elindításához/karbantartásához.
Itt sok a tapasztalat, de nem sok pénz (hacsak nem igazgató vagy sikeres értékesítési vezető). És mégis, ha szereted a hálózatokat, és még csak az út elején jársz, akkor még most is ideális kiindulópont lehet egy nem túl nagy szolgáltatót támogató karrier (a szövetségi hálózatokban minden nagyon jól meg van írva, és kevés hely a kreativitásnak). Nos, azok a történetek, amelyek arról szólnak, hogyan lehet szolgálatban lévő mérnökből néhány év alatt C-szintű menedzserré válni, szintén valósak, bár nyilvánvaló okokból ritkák. Személyzetre mindig szükség van, mert fluktuáció előfordul. Ez egyszerre jó és rossz - mindig vannak szabad helyek, másrészt - gyakran a legaktívabbak/okosabbak gyorsan elmennek akár promócióra, akár más, "melegebb" helyre.
2. Feltételes „vállalkozás”. Nem mindegy, hogy fő tevékenysége informatikához kapcsolódik-e vagy sem. A lényeg, hogy saját informatikai részlege van, amely biztosítja a cég belső rendszereinek működését, beleértve az irodák hálózatát, a fiókok kommunikációs csatornáit stb. A hálózatmérnöki feladatokat az ilyen cégeknél „részmunkaidőben” rendszergazda látja el (ha kicsi a hálózati infrastruktúra vagy külső vállalkozó kezeli), hálózati szakember pedig, ha van, a ugyanakkor vigyázzon a telefonálásra és a SAN-ra (nem jó). Különböző módon fizetnek - ez nagyban függ a vállalkozás jövedelmezőségétől, a vállalat méretétől és a struktúrától. Dolgoztam olyan cégekkel, ahol rendszeresen „hordóba rakták” a Cisco rendszereket, illetve olyan cégekkel, ahol ürülékből, pálcikákból és kék szalagból építették a hálózatot, és a szervereket soha nem frissítették (mondanom sem kell, tartalékot sem adtak). Itt sokkal kevesebb a tapasztalat, és szinte biztos, hogy a szigorú szállítói letiltás, vagy „hogyan készítsünk valamit a semmiből” területén. Személy szerint én vadul unalmasnak találtam, bár sokan szeretik - minden eléggé mért és kiszámítható (ha nagyvállalatokról beszélünk), „dorakha-bahato” stb. Évente legalább egyszer valamelyik nagyobb gyártó azt mondja, hogy kitaláltak egy újabb mega-szuper-duper rendszert, ami most mindent automatizál, és az összes rendszergazdát és hálózatépítőt szét lehet oszlatni, így pár gombnyomásra marad egy gyönyörű felületen. A valóság az, hogy még ha figyelmen kívül hagyjuk is a megoldás költségeit, a hálózatépítők onnan nem mennek sehova. Igen, lehet, hogy a konzol helyett ismét lesz webes felület (de nem egy konkrét hardver, hanem egy nagy rendszer, amely több tíz és száz ilyen hardvert kezel), de a „hogyan működik belül minden” ismerete továbbra is megmarad. szükség van.
3. Termékcégek, amelynek haszna valamilyen szoftver vagy platform – ugyanazon termék – fejlesztéséből (és gyakran üzemeltetéséből) származik. Általában kicsik és fürgeek, még mindig messze vannak a vállalkozások méretétől és bürokratizáltságától. Itt találhatók tömegesen ugyanazok a devopok, cuber-ok, dockerek és egyéb szörnyű szavak, amelyek minden bizonnyal felesleges kezdetekké teszik a hálózatot és a hálózati mérnököket.
Miben különbözik a hálózatépítő a rendszergazdától?
A nem informatikus emberek megértésében - semmi. Mindketten a fekete képernyőre néznek, és írnak néhány varázslatot, néha csendesen káromkodva.
A programozók felfogásában – talán tantárgyanként. A rendszergazdák adminisztrálják a szervereket, a hálózatépítők a switcheket és az útválasztókat. Néha rossz az adminisztráció, és mindenkinél minden szétesik. Nos, ha bármi furcsa, akkor a hálózatépítők is hibásak. Csak azért, mert bassza meg, ezért.
Valójában a fő különbség a munka megközelítése. Talán a hálózatépítők körében van a legtöbb támogató a „Ha működik, ne nyúlj hozzá!”. Általános szabály, hogy valamit (egy szállítón belül) csak egy módon lehet megtenni; a doboz teljes konfigurációja ott van a tenyerében. A hiba költsége magas, és néha nagyon magas (például több száz kilométert kell utaznia az útválasztó újraindításához, és ebben az időben több ezer ember lesz kommunikáció nélkül - ez meglehetősen gyakori helyzet egy távközlési szolgáltatónál) .
Véleményem szerint ez az oka annak, hogy a hálózati mérnökök egyrészt rendkívül erősen motiváltak a hálózat stabilitása iránt (és a változás a stabilitás legfőbb ellensége), másrészt a tudásuk inkább mélyreható, mint tágabb (nem több tucat különböző démon konfigurálására van szüksége, ismernie kell a technológiákat és azok megvalósítását egy adott berendezésgyártótól). Ez az oka annak, hogy az a rendszergazda, aki rákeresett a google-ban, hogyan kell VLAN-t regisztrálni Cisco rendszeren, még nem hálózatépítő. És nem valószínű, hogy képes lesz hatékonyan támogatni (valamint hibaelhárítást) egy többé-kevésbé bonyolult hálózatot.
De miért van szüksége hálózatépítőre, ha van tárhelye?
További pénzért (és ha Ön egy nagyon nagy és szeretett ügyfél, akár ingyen, „barátként”), az adatközponti mérnökök az Ön igényeinek megfelelően konfigurálják a kapcsolóit, és talán még egy BGP-interfész kialakításában is segítenek a szolgáltatókkal. (ha rendelkezik saját IP-címek alhálózatával a bejelentéshez).
A fő probléma az, hogy az adatközpont nem az Ön informatikai részlege, hanem egy külön cég, amelynek célja a profitszerzés. Beleértve az Ön, mint ügyfél költségére. Az adatközpont állványokat biztosít, árammal és hideggel látja el őket, valamint némi „alapértelmezett” csatlakozást is biztosít az internethez. Ezen infrastruktúra alapján az adatközpont otthont adhat az Ön berendezéseinek (kolokáció), szervert bérelhet Önnek (dedikált szerver), vagy felügyelt szolgáltatást nyújthat (például OpenStack vagy K8s). De egy adatközpont dolga (általában) nem a kliens infrastruktúra adminisztrációja, mert ez a folyamat meglehetősen munkaigényes, rosszul automatizált (és egy normál adatközpontban minden, ami lehetséges, automatizált), egységes még rosszabb (minden ügyfél egyéni), és általában tele van panaszokkal ("azt mondod, hogy a szervert beállították, de most összeomlott, az egész a te hibád!!! 111"). Ezért, ha a házigazda segít valamiben, megpróbálja a lehető legegyszerűbbé és kényelmesebbé tenni. Mert ezt a nehézséget nem kifizetődő, legalábbis ugyanannak a hosternek a mérnökeinek munkaerő-költségei szempontjából (de a helyzetek eltérőek, lásd a felelősség kizárását). Ez nem jelenti azt, hogy a házigazda feltétlenül mindent rosszul csinál. De egyáltalán nem tény, hogy pontosan azt fogja tenni, amire valóban szüksége van.
Úgy tűnik, a dolog teljesen nyilvánvaló, de a gyakorlatom során többször találkoztam azzal, hogy a cégek a kelleténél kicsit jobban kezdtek támaszkodni a tárhelyszolgáltatójukra, és ez nem vezetett semmi jóra. Hosszan és részletesen el kellett magyaráznom, hogy egyetlen SLA sem fedezné az állásidőből származó veszteségeket (vannak kivételek, de általában ez nagyon-nagyon drága az ügyfélnek), és a hoster egyáltalán nincs tisztában azzal, hogy mi történik az ügyfelek infrastruktúrája (kivéve a nagyon általános mutatókat). És a házigazda sem készít biztonsági másolatot neked. Még rosszabb a helyzet, ha egynél több házigazdája van. Ha bármilyen probléma van köztük, biztosan nem fogják kideríteni, mi történt.
Valójában az indítékok itt pontosan ugyanazok, mint a „házon belüli adminisztrációs csapat kontra kiszervezett” választásnál. Ha a kockázatokat kiszámítják, a minőség megfelelő, és a vállalkozás nem bánja, miért ne próbálná ki. Másrészt a hálózat az infrastruktúra egyik legalapvetőbb rétege, és aligha érdemes külsősekre hagyni, ha már minden mást magad támogatsz.
Milyen esetekben van szükség hálózatépítőre?
A következőkben kifejezetten a modern élelmiszeripari vállalatokról lesz szó. Az üzemeltetőknél és a vállalkozásoknál minden világos, plusz vagy mínusz – ott kevés változás történt az elmúlt években, és korábban is kellettek hálózatépítők, és most is szükség van rájuk. De ugyanezekkel a „fiatal és merész” dolgokkal nem ennyire egyértelműek a dolgok. Gyakran a teljes infrastruktúrájukat a felhőkbe helyezik, így nincs is igazán szükségük adminisztrátorra – kivéve persze ugyanezen felhők rendszergazdáit. Az infrastruktúra egyrészt meglehetősen egyszerű kialakítású, másrészt jól automatizált (ansible/puppet, terraform, ci/cd... hát ugye). De még itt is vannak olyan helyzetek, amikor nem lehet hálózati mérnök nélkül megbirkózni.
1. példa, klasszikus
Tegyük fel, hogy egy vállalat egy nyilvános IP-címmel rendelkező szerverrel indul, amely egy adatközpontban található. Aztán van két szerver. Aztán még... Előbb-utóbb szükség lesz egy privát hálózatra a szerverek között. Mert a „külső” forgalmat mind a sávszélesség (például legfeljebb 100 Mbit/s), mind a havi letöltött/feltöltött mennyiség korlátozza (a különböző hostereknek eltérő tarifái vannak, de a sávszélesség a külvilág felé általában sokkal drágább, mint egy privát hálózat).
A hoster további hálózati kártyákat ad a szerverekhez, és külön vlan-ben helyezi el azokat a kapcsolóikban. Egy „lapos” helyi terület jelenik meg a szerverek között. Kényelmes!
A szerverek száma nő, és a privát hálózaton is nő a forgalom - biztonsági mentések, replikációk stb. A hoster felajánlja, hogy külön kapcsolókba helyezi át Önt, hogy ne zavarjon más ügyfeleket, és ők se zavarják Önt. A kiszolgáló telepít néhány kapcsolót, és valahogy konfigurálja azokat – valószínűleg egyetlen lapos hálózatot hagyva az összes szerver között. Minden jól működik, de egy bizonyos pillanatban problémák kezdődnek: a hosztok közötti késések időről időre megnőnek, a naplók másodpercenként túl sok arp csomagra panaszkodnak, és egy audit során a pentester az egész helyi hálózatot átszúrta, és csak egy szervert tört meg.
Mit tegyek?
Ossza fel a hálózatot szegmensekre - vlanokra. Konfigurálja saját címét minden egyes vlan-ben, válasszon egy átjárót, amely a hálózatok közötti forgalmat továbbítja. Konfigurálja az acl-t az átjárón a szegmensek közötti hozzáférés korlátozása érdekében, vagy akár külön tűzfalat is telepíthet a közelben.
1. példa, folytatás
A szerverek egy vezetékkel csatlakoznak a LAN-hoz. A rack-ekben lévő kapcsolók valahogy össze vannak kötve, de ha az egyik rackben baleset történik, akkor még három szomszédos leesik. Sémák léteznek, de relevanciájukat illetően kétségek merülnek fel. Minden szervernek saját nyilvános címe van, amelyet a tárhely ad ki, és amely a rackhez van kötve. Azok. Szerver áthelyezésekor a címet meg kell változtatni.
Mit tegyek?
Csatlakoztassa a szervereket a LAG (Link Aggregation Group) segítségével két vezetékkel a rackben lévő kapcsolókhoz (ezeknek is redundánsnak kell lenniük). Foglalja le az állványok közötti csatlakozásokat, és alakítsa át őket „csillaggá” (vagy a mostanában divatos CLOS-sá), hogy az egyik rack elvesztése ne érintse a többit. Válassza ki a „központi” rackeket, amelyekben a hálózati mag elhelyezkedik, és ahol más rack-ek csatlakoznak. Ezzel egyidejűleg tedd rendbe a nyilvános megszólítást, vegyél el a hostertől (vagy lehetőség szerint a RIR-től) egy alhálózatot, amit te magad (vagy a hosteren keresztül) jelentesz be a világnak.
Megteheti mindezt egy „hétköznapi” rendszergazda, aki nem rendelkezik mély hálózatismeretekkel? Nem biztos. A házigazda megteszi ezt? Lehet, hogy lesz, de kell egy elég részletes műszaki specifikáció, amit valakinek el is kell készítenie. majd ellenőrizze, hogy minden rendben van-e.
2. példa: Felhő
Tegyük fel, hogy van VPC-je valamilyen nyilvános felhőben. Ahhoz, hogy az irodából vagy az infrastruktúra helyszíni részéből hozzáférjen a VPC-n belüli helyi hálózathoz, konfigurálnia kell a kapcsolatot IPSec-en vagy egy dedikált csatornán keresztül. Egyrészt az IPSec olcsóbb, mert nincs szükség további hardver vásárlására; létrehozhat egy alagutat a nyilvános címmel rendelkező szervere és a felhő között. De - késések, korlátozott teljesítmény (mivel a csatornát titkosítani kell), plusz a nem garantált kapcsolat (mivel a hozzáférés a normál interneten keresztül történik).
Mit tegyek?
Hozza létre a kapcsolatot egy dedikált csatornán keresztül (például az AWS közvetlen kapcsolatnak nevezi). Ehhez keressen egy partner operátort, aki összeköti Önt, döntse el a hozzád legközelebb eső csatlakozási pontot (mind az üzemeltetőhöz, mind az operátor a felhőhöz), és végül állítson be mindent. Lehetséges mindezt hálózati mérnök nélkül? Biztosan igen. De már nem olyan egyértelmű, hogyan lehet nélküle elhárítani a problémákat.
Problémák lehetnek a felhők közötti elérhetőséggel (ha többfelhővel rendelkezik), vagy problémák lehetnek a különböző régiók közötti késleltetéssel stb. Természetesen mostanra sok olyan eszköz jelent meg, amelyek növelik a felhőben zajló események átláthatóságát (ugyanaz a Thousand Eyes), de ezek mind egy hálózati mérnök eszközei, és nem helyettesítik őt.
Még egy tucatnyi példát tudnék felvázolni a gyakorlatomból, de szerintem egyértelmű, hogy a csapatnak az infrastruktúra fejlesztésének egy bizonyos szintjétől kezdve kell lennie egy embernek (lehetőleg többnek), aki ismeri a hálózat működését és konfigurálni tudja. hálózati berendezéseket, és megoldja a felmerülő problémákat. Hidd el, lesz dolga
Mit kell tudnia egy hálózatépítőnek?
Egyáltalán nem szükséges (sőt, néha káros is), hogy egy hálózatmérnök csak a hálózattal foglalkozzon, semmi mással. Még ha nem is fontolgatjuk a lehetőséget egy olyan infrastruktúrával, amely szinte teljes egészében a nyilvános felhőben él (és bármit is mondunk, egyre népszerűbb), és vegyük például a helyszíni vagy privát felhőket, ahol a „CCNP szintű tudás egyedül” „Nem fogsz elmenni.
Valójában a hálózatok mellett - bár egyszerűen végtelen a tanulmányi terület, még akkor is, ha csak egy területre koncentrál (szolgáltatói hálózatok, vállalkozások, adatközpontok, Wi-Fi ...)
Természetesen most már sokan emlékeznek a Pythonra és más „hálózati automatizálásra”, de ez csak szükséges, de nem elégséges feltétel. Ahhoz, hogy egy hálózati mérnök „sikeresen csatlakozhasson a csapathoz”, képesnek kell lennie ugyanazon a nyelven beszélni a fejlesztőkkel és a többi rendszergazdával/fejlesztővel. Mit jelent?
- tudjon nem csak felhasználóként dolgozni Linux alatt, hanem adminisztrálni is, legalább sysadmin-jun szinten: telepítse a szükséges szoftvert, indítsa újra a meghibásodott szolgáltatást, írjon egy egyszerű systemd-unit-ot.
- Ismerje meg (legalábbis általánosságban), hogyan működik a hálózati verem Linux alatt, hogyan működik a hálózat hipervizorokban és konténerekben (lxc / docker / kubernetes).
- Természetesen tudjon dolgozni ansible/chef/puppet vagy más SCM rendszerrel.
- Külön sort kell írni az SDN-ről és a privát felhők hálózatairól (például TungstenFabric vagy OpenvSwitch). Ez egy másik hatalmas tudásréteg.
Röviden egy tipikus T-alakú specialistát írtam le (mint most divatos mondani). Úgy tűnik, nem újdonság, de az interjú tapasztalatai alapján nem minden hálózatmérnök büszkélkedhet legalább két téma ismeretével a fenti listából. A gyakorlatban a „kapcsolódó területeken” való ismeretek hiánya nagyon megnehezíti nemcsak a kollégákkal való kommunikációt, hanem azoknak a követelményeknek a megértését is, amelyeket az üzlet a hálózattal, mint a projekt legalacsonyabb szintű infrastruktúrájával szemben támaszt. E megértés nélkül pedig nehezebb megvédeni nézőpontját és „eladni” az üzletnek.
Másrészt a „rendszer működésének megértésének” szokása nagyon jó előnyt biztosít a hálózatépítőknek a különféle „generalistákhoz” képest, akik a Habré/médiumról szóló cikkekből és a Telegram chatjéből ismerik a technológiákat, de fogalmuk sincs, hogyan mit tegyenek. ez vagy az a szoftver milyen elvek alapján működik? És bizonyos minták ismerete, mint ismeretes, sikeresen helyettesíti sok tény ismeretét.
Következtetések, vagy csak TL;DR
- A hálózati adminisztrátor (mint a DBA vagy VoIP mérnök) egy meglehetősen szűk profilú szakember (ellentétben a rendszergazdákkal/devs/SRE-vel), amelynek igénye nem azonnal merül fel (sőt, sokáig nem is) . De ha mégis felmerül, nem valószínű, hogy külső szakértők helyettesítik (kiszervezik vagy közönséges általános célú rendszergazdák, „akik a hálózatot is gondozzák”). Ami valamivel szomorúbb, hogy kicsi az igény ilyen szakemberekre, és feltételesen egy 800 programozót és 30 fejlesztőt/adminisztrátort számláló cégben lehet, hogy csak két hálózatépítő van, aki kiválóan látja el feladatait. Azok. a piac nagyon-nagyon kicsi volt és van, és jó fizetés mellett - még kevesebb.
- Másrészt a modern világban egy jó hálózatépítőnek nemcsak magukat a hálózatokat kell ismernie (és azok beállításának automatizálását), hanem azt is, hogy az e hálózatokon futó operációs rendszerek és szoftverek hogyan lépnek kapcsolatba velük. E nélkül rendkívül nehéz lesz megérteni, hogy kollégái mit kérnek Öntől, és (ésszerűen) közvetíteni számukra kívánságait/követelményeit.
- Nincs felhő, csak valaki más számítógépe. Meg kell értenie, hogy a nyilvános/privát felhők vagy egy olyan tárhelyszolgáltató szolgáltatásainak használata, amely „mindent kulcsrakész alapon megtesz helyetted”, nem változtat azon a tényen, hogy az alkalmazás továbbra is használja a hálózatot, és az ezzel kapcsolatos problémák befolyásolják a a te alkalmazásod. Az Ön választása az, hogy hol található a kompetenciaközpont, amely a projekt hálózatáért lesz felelős.
Forrás: will.com