V době psaní tohoto článku se při vyhledávání na oblíbeném pracovním webu na frázi „síťový inženýr“ vrátilo asi tři sta volných pracovních míst po celém Rusku. Pro srovnání, vyhledávání fráze „správce systému“ vrátí téměř 2.5 tisíce volných míst a „DevOps engineer“ - téměř 800.
Znamená to, že v dobách vítězných mraků, Dockeru, Kubernetes a všudypřítomné veřejné Wi-Fi už nejsou síťaři potřeba?
Pojďme na to (c)
Pojďme se seznámit. Jmenuji se Alexey a jsem networker.
V sítích se pohybuji více než 10 let a více než 15 let pracuji s různými *nix systémy (měl jsem možnost pohrát si s Linuxem i FreeBSD). Pracoval jsem u telekomunikačních operátorů, velkých společností, které jsou považovány za „podnikové“ a v poslední době pracuji v „mladých a odvážných“ fintech, kde jsou mraky, devops, kubernetes a další děsivá slova, která mě a mým kolegům určitě udělají zbytečnými . Někdy. Možná.
vyloučení odpovědnosti: „V našem životě není všechno vždy a všude, ale něco, někdy na místech“ (c) Maxim Dorofeev.
Vše níže napsané lze a je třeba považovat za osobní názor autora, který si nečiní nárok na konečnou pravdu, ba ani za plnohodnotnou studii. Všechny postavy jsou fiktivní, všechny náhody jsou náhodné.
Vítej v mém světě.
Kde vůbec můžete networkery potkat?
1. Telekomunikační operátoři, servisní společnosti a další integrátoři. Všechno je zde jednoduché: síť je pro ně podnikání. Buď přímo prodávají konektivitu (operátoři), nebo poskytují služby pro spuštění/údržbu sítí svých zákazníků.
Zkušeností je zde hodně, ale peněz málo (pokud nejste ředitel nebo úspěšný obchodní manažer). A přesto, pokud máte rádi sítě a jste teprve na začátku své cesty, kariéra v podpoře nějakého nepříliš velkého operátora bude i nyní ideálním výchozím bodem (ve federálních je vše velmi naskriptované a tam je málo prostoru pro kreativitu). No, příběhy o tom, jak můžete vyrůst z inženýra ve službě za pár let na manažera na úrovni C, jsou také docela reálné, i když vzácné, z pochopitelných důvodů. Vždy je potřeba personál, protože dochází k fluktuaci. To je dobře i špatně zároveň - volná místa se vždycky najdou, na druhou stranu často ti nejaktivnější/chytřejší rychle odcházejí buď na povýšení, nebo do jiných, „teplejších“ míst.
2. Podmíněný „podnik“. Nezáleží na tom, zda jeho hlavní činnost souvisí s IT nebo ne. Hlavní je, že má vlastní IT oddělení, které zajišťuje chod interních systémů společnosti včetně sítě v kancelářích, komunikačních kanálů s pobočkami atd. Funkce síťového inženýra v takových společnostech může vykonávat „na částečný úvazek“ správce systému (pokud je síťová infrastruktura malá nebo je spravována externím dodavatelem) a síťový specialista, pokud takový existuje, může současně se starat o telefonování a SAN (není dobré). Platí se různě – velmi záleží na ziskovosti podnikání, velikosti firmy a struktuře. Pracoval jsem se společnostmi, kde byly systémy Cisco pravidelně „nakládány do sudů“, a se společnostmi, kde byla síť postavena z fekálií, tyčinek a modré pásky a servery nebyly nikdy aktualizovány (netřeba dodávat, že nebyly poskytnuty žádné rezervy). Zkušeností je zde mnohem méně a téměř jistě to bude v oblasti striktního vendor-locku neboli „jak udělat něco z ničeho“. Osobně mi to přišlo hrozně nudné, i když se to mnoha lidem líbí - všechno je docela odměřené a předvídatelné (pokud mluvíme o velkých společnostech), „dorakha-bahato“ atd. Nejméně jednou za rok nějaký významný prodejce řekne, že přišel s dalším mega-super-duper systémem, který nyní vše zautomatizuje a všichni správci systému a síťaři mohou být rozptýleni, takže pár bude mačkat tlačítka v krásném rozhraní. Realita je taková, že i když budeme ignorovat náklady na řešení, networkeři odtamtud nikam nepůjdou. Ano, možná místo konzole bude opět webové rozhraní (ne však konkrétní hardware, ale velký systém, který spravuje desítky a stovky takových kusů hardwaru), ale znalost „jak vše uvnitř funguje“ bude být potřeba.
3. Produktové společnosti, jejíž zisk pochází z vývoje (a často i provozu) nějakého softwaru nebo platformy – stejného produktu. Obvykle jsou malí a šikovní, do rozsahu podniků a jejich byrokratizace mají ještě daleko. Právě zde se masově vyskytují ti samí devops, cuber, docker a další strašná slova, která jistě ze sítě a síťových inženýrů udělají zbytečný základ.
Jak se liší síťař od správce systému?
V chápání lidí ne z IT - nic. Oba se dívají na černou obrazovku a píší nějaká kouzla, někdy tiše nadávají.
V chápání programátorů - možná podle oborů. Správci systému spravují servery, síťaři spravují přepínače a směrovače. Někdy je administrativa špatná a všem se všechno rozpadne. No, v případě něčeho divného jsou na vině i síťaři. Jen proto, že tě šuká, proto.
Ve skutečnosti je hlavním rozdílem přístup k práci. Možná, že právě mezi networkery je nejvíce zastánců přístupu „Pokud to funguje, nedotýkejte se toho!“. Zpravidla lze něco udělat (v rámci jednoho dodavatele) pouze jedním způsobem, celou konfiguraci boxu máte jako na dlani. Cena chyby je vysoká a někdy velmi vysoká (například budete muset ujet několik set kilometrů, abyste restartovali router, a v tuto chvíli bude několik tisíc lidí bez komunikace - u telekomunikačního operátora docela běžná situace) .
Podle mého názoru jsou proto síťoví inženýři na jedné straně extrémně motivováni ke stabilitě sítě (a změna je hlavním nepřítelem stability) a za druhé jejich znalosti jdou více do hloubky než do šířky (nemáte musíte být schopni konfigurovat desítky různých démonů, musíte znát technologie a jejich implementaci od konkrétního výrobce zařízení). To je důvod, proč systémový administrátor, který vygoogloval, jak zaregistrovat vlan v systému Cisco, ještě není síťař. A je nepravděpodobné, že bude schopen efektivně podporovat (a také odstraňovat problémy) více či méně složitou síť.
Ale proč potřebujete networker, když máte hostitele?
Za další peníze (a pokud jste velmi velký a oblíbený klient, možná dokonce zdarma, „jako přítel“), inženýři datového centra nakonfigurují vaše přepínače tak, aby vyhovovaly vašim potřebám, a možná vám dokonce pomohou vytvořit rozhraní BGP s poskytovateli. (pokud máte vlastní podsíť IP adres pro oznámení).
Hlavním problémem je, že datové centrum není vaše IT oddělení, je to samostatná společnost, jejímž cílem je zisk. Včetně na náklady vás jako klienta. Datové centrum poskytuje stojany, poskytuje jim elektřinu a chlad a také poskytuje určitou „výchozí“ konektivitu k internetu. Na základě této infrastruktury může datové centrum hostovat vaše zařízení (kolokace), pronajímat vám server (dedikovaný server) nebo poskytovat spravované služby (například OpenStack nebo K8s). Ale byznysem datového centra (obvykle) není správa klientské infrastruktury, protože tento proces je dost pracný, málo automatizovaný (a v normálním datovém centru je automatizováno vše, co je možné), unifikovaný ještě hůř (každý klient je individuální) a obecně plné stížností („Říkáš mi, že server byl nastaven, ale teď se zhroutil, je to tvoje chyba!!!111“). Pokud vám tedy hostitel s něčím pomůže, bude se to snažit co nejvíce zjednodušit a zpohodlnit. Protože dělat to obtížné je nerentabilní, alespoň z pohledu mzdových nákladů inženýrů stejného hostitele (ale situace jsou různé, viz prohlášení o vyloučení odpovědnosti). To neznamená, že hostitel nutně udělá všechno špatně. Ale není vůbec pravda, že udělá přesně to, co opravdu potřebujete.
Zdálo by se, že věc je zcela samozřejmá, ale několikrát jsem se ve své praxi setkal s tím, že firmy začaly spoléhat na svého poskytovatele hostingu trochu více, než by měly, a nevedlo to k ničemu dobrému. Musel jsem zdlouhavě a podrobně vysvětlovat, že ani jedna SLA nepokryje ztráty z prostojů (existují výjimky, ale obvykle je to pro klienta velmi, VELMI drahé) a že hostitel vůbec neví, co se děje v infrastruktura zákazníků (s výjimkou velmi obecných ukazatelů). A hostitel vám také nevytváří zálohy. Situace je ještě horší, pokud máte více než jednoho hostitele. V případě jakýchkoliv problémů mezi nimi určitě za vás nezjistí, co se pokazilo.
Ve skutečnosti jsou zde motivy úplně stejné jako při výběru „interní admin tým vs outsourcing“. Pokud jsou rizika spočítána, kvalita je uspokojivá a podniku to nevadí, proč to nezkusit. Na druhou stranu je síť jednou z nejzákladnějších vrstev infrastruktury a stěží se vyplatí nechat ji na cizích chlapech, pokud už všechno ostatní podporujete sami.
V jakých případech je nutný networker?
Dále budeme hovořit konkrétně o moderních potravinářských společnostech. U operátorů a enterprise je vše plus minus jasné – za poslední roky se tam změnilo málo a networkery tam byly potřeba dříve a jsou potřeba i nyní. Ale s těmi samými „mladými a odvážnými“ věci nejsou tak jasné. Často umisťují celou svou infrastrukturu do cloudů, takže vlastně ani nepotřebují správce – samozřejmě kromě správců stejných cloudů. Infrastruktura je na jednu stranu svým designem celkem jednoduchá, na druhou stranu dobře zautomatizovaná (ansible/puppet, terraform, ci/cd... no, znáte to). Ale i zde jsou situace, kdy se bez síťového inženýra neobejdete.
Příklad 1, klasika
Předpokládejme, že společnost začíná s jedním serverem s veřejnou IP adresou, který je umístěn v datovém centru. Pak jsou dva servery. Pak více... Dříve nebo později bude potřeba soukromá síť mezi servery. Protože „externí“ provoz je omezen jak šířkou pásma (například ne více než 100 Mbit/s), tak objemem stahovaného/nahrávaného za měsíc (různí hostitelé mají různé tarify, ale šířka pásma do vnějšího světa je obvykle mnohem dražší než privátní síť).
Hoster přidá k serverům další síťové karty a zahrne je do jejich přepínačů v samostatné vlan. Mezi servery se objeví „plochá“ místní oblast. Komfortní!
Roste počet serverů a roste i provoz v privátní síti – zálohování, replikace atd. Hoster vám nabízí přesun do samostatných přepínačů, abyste nerušili ostatní klienty a oni nerušili vás. Hoster nainstaluje některé přepínače a nějak je nakonfiguruje - s největší pravděpodobností ponechá jednu plochou síť mezi všemi vašimi servery. Všechno funguje dobře, ale v určitém okamžiku začnou problémy: zpoždění mezi hostiteli se periodicky zvyšuje, protokoly si stěžují na příliš mnoho arp paketů za sekundu a během auditu pentester posral celou vaši lokální síť a rozbil pouze jeden server.
Co mám dělat?
Rozdělte síť na segmenty - vlany. Nakonfigurujte si vlastní adresování v každé vlan, vyberte bránu, která bude přenášet provoz mezi sítěmi. Nakonfigurujte acl na bráně, abyste omezili přístup mezi segmenty, nebo dokonce v blízkosti nainstalujte samostatný firewall.
Příklad 1, pokračování
Servery jsou připojeny k síti LAN jedním kabelem. Vypínače ve stojanech jsou na sebe nějak propojené, ale pokud dojde k havárii v jednom stojanu, odpadnou další tři sousední. Schémata existují, ale existují pochybnosti o jejich relevanci. Každý server má svou veřejnou adresu, kterou vydává hostitel a je vázána na rack. Tito. Při přesunu serveru je nutné změnit adresu.
Co mám dělat?
Připojte servery pomocí LAG (Link Aggregation Group) pomocí dvou kabelů k přepínačům v racku (musí být také redundantní). Vyhraďte si spoje mezi stojany, převeďte je na typ „hvězda“ (neboli nyní módní CLOS), aby ztráta jednoho stojanu neovlivnila ostatní. Vyberte „centrální“ rozvaděče, ve kterých bude umístěno jádro sítě a kam budou připojeny další rozvaděče. Zároveň si udělejte pořádek s veřejným adresováním, vezměte si z hostera (nebo z RIR pokud možno) podsíť, kterou sami (nebo prostřednictvím hostitele) oznámíte do světa.
Zvládne to všechno „obyčejný“ správce systému, který nemá hluboké znalosti sítí? Nejsem si jistý. Udělá to hostitel? Možná bude, ale budete potřebovat poměrně podrobnou technickou specifikaci, kterou bude také muset někdo vypracovat. a poté zkontrolujte, zda je vše provedeno správně.
Příklad 2: Cloud
Řekněme, že máte VPC v nějakém veřejném cloudu. Chcete-li získat přístup z kanceláře nebo místní části infrastruktury k místní síti uvnitř VPC, musíte nakonfigurovat připojení přes IPSec nebo vyhrazený kanál. Na jednu stranu je IPSec levnější, protože není třeba kupovat další hardware, můžete nastavit tunel mezi vaším serverem s veřejnou adresou a cloudem. Ale - zpoždění, omezený výkon (protože kanál musí být šifrovaný) plus nezaručená konektivita (protože přístup je přes běžný internet).
Co mám dělat?
Vytvořte připojení prostřednictvím vyhrazeného kanálu (například AWS to nazývá Direct Connect). K tomu si najděte partnerského operátora, který vás připojí, určí vám nejbližší přípojný bod (jak vy k operátorovi, tak operátor ke cloudu) a nakonec vše nastavíte. Je možné toto vše udělat bez síťového inženýra? Určitě ano. Jak se ale bez něj v případě problémů vypořádat, už tak jasné není.
Mohou se také objevit problémy s dostupností mezi cloudy (pokud máte multicloud) nebo problémy se zpožděním mezi různými regiony atd. Samozřejmě se nyní objevilo mnoho nástrojů, které zvyšují transparentnost toho, co se děje v cloudu (stejné Thousand Eyes), ale to jsou všechny nástroje síťového inženýra a ne jeho náhrada.
Mohl bych načrtnout ještě tucet takových příkladů ze své praxe, ale myslím, že je jasné, že tým od určité úrovně rozvoje infrastruktury musí mít člověka (nejlépe více než jednoho), který ví, jak síť funguje a umí konfigurovat síťová zařízení a řešit případné problémy. Věřte mi, že bude mít co dělat
Co by měl síťař vědět?
Není vůbec nutné (a někdy dokonce škodlivé), aby se síťový inženýr zabýval pouze sítí a ničím jiným. I když neuvažujeme o variantě s infrastrukturou, která žije téměř výhradně ve veřejném cloudu (a, ať se říká, je stále populárnější), a vezmeme si například on-premise nebo privátní cloudy, kde na „samotné znalosti na úrovni CCNP“ „Neodejdeš.
Kromě vlastně sítí - i když je prostě nekonečné pole ke studiu, i když se soustředíte pouze na jednu oblast (providerské sítě, podniky, datová centra, Wi-Fi...)
Mnozí z vás si samozřejmě nyní vzpomenou na Python a další „síťovou automatizaci“, ale to je pouze nutná, nikoli však postačující podmínka. Aby se síťový inženýr „úspěšně připojil k týmu“, musí být schopen mluvit stejným jazykem jak s vývojáři, tak s ostatními administrátory/vývojáři. Co to znamená?
- být schopen v Linuxu nejen pracovat jako uživatel, ale také jej spravovat, alespoň na úrovni sysadmin-jun: nainstalovat potřebný software, restartovat neúspěšnou službu, napsat jednoduchou systemd-unit.
- Pochopte (alespoň obecně), jak funguje síťový zásobník v Linuxu, jak funguje síť v hypervizorech a kontejnerech (lxc / docker / kubernetes).
- Samozřejmě umět pracovat s ansible/kuchařem/loutkou nebo jiným systémem SCM.
- O SDN a sítích pro privátní cloudy (například TungstenFabric nebo OpenvSwitch) by měl být napsán samostatný řádek. To je další obrovská vrstva znalostí.
Ve zkratce jsem popsal typického specialistu na tvar T (jak je nyní v módě říkat). Zdá se to jako nic nového, ale na základě zkušeností s rozhovory se ne všichni síťoví inženýři mohou pochlubit znalostmi alespoň dvou témat z výše uvedeného seznamu. Nedostatek znalostí „v příbuzných oborech“ v praxi velmi ztěžuje nejen komunikaci s kolegy, ale také pochopení požadavků, které business klade na síť jako na nejnižší infrastrukturu projektu. A bez tohoto porozumění je obtížnější obhájit svůj názor a „prodat“ jej podnikání.
Na druhou stranu stejný zvyk „rozumět tomu, jak systém funguje“, dává networkerům velmi dobrou výhodu oproti různým „generalistům“, kteří vědí o technologiích z článků na Habré/médium a chatů na Telegramu, ale absolutně netuší, jak na co principy, na kterých ten či onen software funguje? A znalost určitých zákonitostí, jak známo, úspěšně nahrazuje znalost mnoha skutečností.
Závěry, nebo jen TL;DR
- Síťový administrátor (jako DBA nebo VoIP inženýr) je specialista s poměrně úzkým profilem (na rozdíl od systémových administrátorů/devs/SRE), jehož potřeba nevzniká okamžitě (a ve skutečnosti nemusí nastat dlouho) . Pokud se však objeví, je nepravděpodobné, že bude nahrazen externími odborníky (outsourcing nebo běžní administrátoři pro obecné účely, „kteří se také starají o síť“). Poněkud smutnější je, že potřeba takových specialistů je malá a podmínečně ve společnosti s 800 programátory a 30 vývojáři/administrátory mohou být pouze dva networkeři, kteří se svými povinnostmi odvádějí vynikající práci. Tito. trh byl a je velmi, velmi malý a s dobrým platem - ještě méně.
- Na druhou stranu, dobrý síťař v moderním světě musí znát nejen sítě samotné (a jak automatizovat jejich konfiguraci), ale také to, jak s nimi spolupracují operační systémy a software, který nad těmito sítěmi běží. Bez toho bude nesmírně obtížné porozumět tomu, co po vás vaši kolegové požadují, a sdělit jim (přiměřeně) vaše přání/požadavky.
- Neexistuje žádný cloud, je to jen počítač někoho jiného. Musíte pochopit, že používání veřejných/soukromých cloudů nebo služeb poskytovatele hostingu „který za vás udělá vše na klíč“ nic nemění na tom, že vaše aplikace stále používá síť a problémy s ní ovlivní provoz tvá aplikace. Vaše volba je, kde bude umístěno kompetenční centrum, které bude zodpovídat za síť vašeho projektu.
Zdroj: www.habr.com