V době psaní tohoto článku hledání na populárním pracovním portálu podle fráze „Síťový inženýr“ zobrazovalo přibližně tři sta volných pracovních míst po celé České republice. Pro srovnání, hledání podle fráze „systémový administrátor“ ukazuje téměř 2,5 tisíce nabídek, a „DevOps inženýr“ - skoro 800.
Znamená to, že síťoví odborníci už nejsou potřeba v době, kdy dominuje cloud, Docker, Kubernetes a všudypřítomný veřejný Wi-Fi?
Pojďme tomu přijít na kloub (c)
Pojďme se seznámit. Jmenuji se Alexej a jsem síťový inženýr.
Více než 10 let se věnuji sítím a více než 15 let pracuji s různými *nix systémy (měl jsem možnost zabývat se jak Linuxem, tak FreeBSD). Pracoval jsem u telekomunikačních operátorů, ve velkých firmách považovaných za „enterprise“, a v poslední době pracuji ve „mladém a drsném“ fintechu, kde se objevují cloudu, DevOps, Kubernetes a další strašlivá slova, která mě a mé kolegy jistě učiní zbytečnými. Někdy. Možná.
disclaimer: „V našem životě není vše, vždy a všude, a některé věci, někdy a na různých místech“ (c) Maxim Dorofejeff.
Vše, co je napsáno níže, lze a je třeba považovat za osobní názor autora, který si neansikuje pravdu v poslední instanci, ani za plnohodnotný výzkum. Všechny postavy jsou smyšlené, všechna shodnutí jsou náhodná.
Vítejte v mém světě.
Kde lze vůbec potkat síťové odborníky?
1. Telekomunikační operátoři, servisní společnosti a další integrátoři. Tady je to jednoduché: síť je pro ně byznys. 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 mnoho, peněz — ne moc (pokud nejste ředitel nebo úspěšný obchodní manažer). Přesto, pokud vás zajímají sítě a teprve začínáte, kariéra v podpoře nějakého méně známého operátora bude, i dnes, ideálním výchozím bodem (ve federálních společnostech je vše velmi rigidní a prostoru pro kreativitu je málo). A příběhy o tom, že můžete z pozice pohotovostního inženýra za několik let povýšit na manažera na úrovni C-level, jsou také velmi reálné, i když vzácné, z pochopitelných důvodů. Potřeba pracovních sil je vždy, protože fluktuace je skutečná. To je zároveň dobré i špatné — vždy jsou volná místa, na druhou stranu — často ti nejaktivnější / nejchytřejší odcházejí dost rychle buď na povýšení, nebo na jiná, „teplejší“ místa.
2. Podmíněný „enterprise“. Je jedno, zda je jeho hlavní činnost spojená s IT či nikoli. Hlavní je, že má vlastní IT oddělení, které se stará o fungování vnitřních systémů společnosti, včetně sítě v kancelářích, komunikačních kanálů do poboček atd. Funkce síťového inženýra v takových firmách může „kromě toho“ vykonávat systémový administrátor (pokud je síťová infrastruktura malá nebo se o ni stará externí dodavatel), a síťař, pokud přece jen existuje, může také dohlížet na telefonii a SAN (není to nic zvláštního). Platí se různě — hodně záleží na maržovosti podnikání, velikosti firmy a struktuře. Pracoval jsem s firmami, kde se cisco pravidelně „zatěžovalo sudy“, a s firmami, kde se síť stavěla z exkrementů, klacků a modré izolační pásky, a servery se vůbec neaktualizovaly (ani netřeba říkat, že žádné zálohy také nebyly). Zkušeností zde je mnohem méně, a téměř určitě bude v oblasti tvrdého vendor-locku, nebo „jak z ničeho udělat něco“. Mně se tam zdálo neskutečně nudné, i když mnohým to vyhovuje — všechno je dost klidné a předvídatelné (pokud hovoříme o velkých společnostech), „do pádu a hodně“ atd. Nejméně jednou za rok nějaký velký dodavatel oznámí, že vymyslel další mega-super-duper systém, který teď všechno automatizuje a všechny administrátory a síťaře bude moct poslat na ulici, přičemž pár jich nechá jen na mačkání tlačítek v hezkém rozhraní. Realita je však taková, že i když se odhlédne od nákladů na řešení, síťaři se odtud nikam nedostanou. Ano, možná, že místo konzole bude opět webové rozhraní (ale už ne konkrétního zařízení, ale velkého systému, který řídí desítky a stovky takových zařízení), ale znalosti „jak to všechno uvnitř funguje“ budou stále potřeba.
3. Produktové společnosti, jejichž zisk pochází z vývoje (a často, provozu) nějakého softwaru nebo platformy — toho pravého produktu. Obvykle jsou malé a hbité, mají daleko k rozměrům enterprise a jejich byrokratizaci. Právě zde se masově vyskytují ti praví devopsáci, kubernetesáci, dockeráci a další děsivá slova, která bezpodmínečně učiní síť a síťové inženýry zbytečnými relikty.
Jaký je rozdíl mezi síťařem a administrátorem?
Pro lidi, kteří nejsou v IT, to nic neznamená. Oba se dívají na černou obrazovku a píší nějaké zaklínání, někdy tiše proklínají.
Pro programátory to může znamenat pouze oborovou znalost. Správci systémů spravují servery, síťoví administrátoři spravují přepínače a směrovače. Někdy se to nedělá správně a všechno se zhroutí. No a v případě nějakých podivností to jsou také síťoví administrátoři, protože prostě proto, že fuj, to je důvod.
Ve skutečnosti je hlavním rozdílem přístup k práci. Právě mezi síťovými administrátory se nejčastěji setkáte s příznivci přístupu "Funguje — nesahám na to!". Udělat určitou věc (v rámci jednoho dodavatele) je obvykle možné jen jedním způsobem, celá konfigurace zařízení je přehledná a viditelná. Cena chyby je vysoká, a někdy velmi vysoká (například budete muset jet stovky kilometrů, abyste restartovali směrovač, zatímco bez spojení zůstanou tisíce lidí — což je pro operátory běžná situace).
Podle mého názoru právě proto jsou síťoví inženýři na jedné straně silně motivovaní k stabilitě sítě (a změny jsou hlavním nepřítelem stability), a na druhé straně jejich znalosti jdou spíše do hloubky než do šířky (není nutné umět konfigurovat desítky různých démonů, je třeba znát technologie a jejich realizaci u konkrétního výrobce zařízení). Proto správce systému, který na Googlu našel, jak nastavit VLAN na Cisco, ještě není síťový administrátor. A pravděpodobně nebude schopen efektivně udržovat (a také řešit problémy) relativně složitou síť.
Ale proč potřebujete síťového administrátora, když máte hoster?
Za dodatečné peníze (a pokud jste opravdu velký a oblíbený klient — možná dokonce i zdarma, "z přátelství") inženýři datového centra nastaví vaše přepínače podle vašich potřeb a možná vám dokonce pomohou nastavit BGP-hranic se poskytovateli (pokud máte svou podsíť IP adres pro vyhlášení).
Hlavním problémem je, že datacentrum není vaše IT oddělení, je to samostatná společnost, jejímž cílem je dosáhnout zisku. A to i tím, že se stará o vás jako klienta. Datacentrum poskytuje stojany, zajišťuje je elektrickou energií a chlazením a také poskytuje určité "standardní" připojení k internetu. Na základě této infrastruktury může datacentrum umístit vaše zařízení (colocation), pronajmout vám server (dedicated server) nebo poskytnout spravovanou službu (například OpenStack nebo K8s). Ale podnikáním datacentra (obvykle) není správa infrastruktury klientů, protože tento proces je poměrně pracný, těžko automatizovatelný (a v normálním datacentru je automatizováno vše, co je možné), ještě mnohem hůře unifikovatelný (každý klient je individuální) a obecně může vyvolat stížnosti ("nastavili jste mi server a teď spadl, za všechno můžete vy!!!111"). Proto pokud vám hostitel v něčem pomůže, pokusí se to udělat co nejjednodušeji a „odepřeným“ způsobem. Je totiž nevýhodné dělat věci složitě, alespoň z pohledu pracovních nákladů inženýrů onoho hostitele (ale situace bývají různé, viz disklamer). To neznamená, že hostitel všechno udělá špatně. Ale vůbec není zaručeno, že udělá přesně to, co jste ve skutečnosti potřebovali.
Na první pohled se to zdá být docela zřejmé, ale já jsem se ve své praxi několikrát setkal s tím, že společnosti začaly spoléhat na svého poskytovatele hostingu o něco více, než by měly, a to nepřineslo nic dobrého. Bylo třeba dlouho a podrobně vysvětlovat, že žádný SLA nepokryje ztráty způsobené výpadkem (existují výjimky, ale obvykle to vyjde klienta velmi, OPRAVDU draho) a že hostitel vůbec není informován o tom, co se děje v infrastruktuře zákazníků (kromě velmi obecných ukazatelů). A zálohy za vás hostitel také nedělá. Ještě horší je situace, pokud máte více než jednoho hostitele. V případě jakýchkoli problémů mezi nimi, určitě nebudou zjišťovat za vás, co se vlastně pokazilo.
Motivy jsou v tomto případě úplně stejné jako při výběru "vlastní tým administrátorů vs outsourcing". Pokud jsou rizika vyhodnocena, kvalita vyhovuje a podnik s tím souhlasí — proč to nezkusit. Na druhou stranu, síť je jednou z nejzákladnějších vrstev infrastruktury a těžko by se mělo svěřovat externím lidem, pokud všechno ostatní už sami udržujete.
Kdy je potřeba síťař?
Dále se budeme bavit především o moderních produktových společnostech. U operátorů a podnikových řešení je to víceméně jasné — tam se za poslední roky příliš nezměnilo a síťaři byli potřební dříve, jsou potřební i nyní. Ale u těch "mladých a nebojácných" je situace nejednoznačná. Často umísťují celou svou infrastrukturu do cloudů, takže ani administrátoři moc nejsou potřeba — kromě administrátorů těchto cloudů, samozřejmě. Infrastruktura je na jedné straně poměrně jednoduchá, na druhé straně dobře automatizovaná (ansible/puppet, terraform, ci/cd… no, víte, jak to je). Ale i přesto existují situace, kdy se bez síťového inženýra neobejdete.
Příklad 1, klasický
Představme si, že společnost začíná s jedním serverem s veřejnou ip adresou umístěným v datovém centru. Poté se servery stávají dvěmi. A pak více... Dříve či později vzniká potřeba soukromé sítě mezi servery. Protože "vnější" provoz je omezen jak šířkou pásma (ne více než 100 Mbit/s, například), tak objemem stáhnutého/odeslaného dat za měsíc (různí hostitelé mají různé tarify, ale šířka pásma do externího světa je obvykle výrazně dražší než soukromá síť).
Hostingová společnost přidává do serverů další síťové karty a zapojuje je do svých přepínačů v samostatném vLanu. Mezi servery vzniká "plochá" lokální síť. Pohodlné!
Počet serverů roste, také provoz v privátní síti — zálohy, replikace atd. Hostingová společnost nabízí možnost umístit vás do samostatných přepínačů, abyste nerušili ostatní klienty a oni nerušili vás. Hostingová společnost instaluje určité přepínače a nějak je nastavuje — pravděpodobně tak, že mezi vašimi servery zanechá jednu plochou síť. Vše funguje dobře, ale v určitém okamžiku začínají problémy: občas se zvyšují zpoždění mezi hostiteli, v logách se objevují chyby na příliš vysoký počet arp paketů za sekundu a pentester při auditu měl celou vaši lokální síť, když rozbil jen jeden server.
Co je potřeba udělat?
Rozdělit síť na segmenty — vlan’y. V každém vlanu nastavit svou adresaci, vyčlenit bránu, která bude přesměrovávat provoz mezi sítěmi. Na bráně nastavit acl pro omezení přístupu mezi segmenty, nebo obecně umístit vedle specializovaný firewall.
Příklad 1, pokračování
Servery jsou připojeny k lokální síti jedním kabelem. Přepínače ve skříních jsou nějak propojeny, ale při havárii v jedné skříni odpadnou i tři sousední. Schémata existují, ale o jejich aktuálnosti jsou pochybnosti. Každý server má svoji veřejnou adresu, kterou poskytuje hostingová společnost a je přidělena ke skříni. Tedy při přesunu serveru je potřeba adresu měnit.
Co je potřeba udělat?
Připojit servery pomocí LAG (Link Aggregation Group) dvěma kabely k přepínačům ve skříni (ty také musí být zálohovány). Spojení mezi skříněmi rezervovat, přepracovat na "hvězdu" (nebo oblíbený CLOS), aby výpadek jedné skříně neovlivnil ostatní. Vyčlenit "centrální" skříně, ve kterých bude síťové jádro, a kam budou připojeny ostatní skříně. Zároveň uspořádat veřejnou adresaci, vzít od hostitele (nebo od RIR, pokud je to možné) podsíť, kterou samostatně (nebo prostřednictvím hostitele) oznámit světu.
Může to všechno udělat "běžný" administrátor, který nemá hluboké znalosti v sítích? Nejsem si jistý. Bude to dělat hostingová společnost? Možná ano, ale budete potřebovat poměrně podrobnou specifikaci, kterou také bude nutné někomu připravit. A pak zkontrolovat, že vše bylo uděláno správně.
Příklad 2. Cloudový
Představme si, že máte VPC v nějakém veřejném cloudu. Abyste získali přístup z kanceláře nebo z on-prem části infrastruktury do lokální sítě uvnitř VPC, musíte nastavit připojení přes IPSec nebo dedikovanou linku. Na jedné straně je IPSec levnější, protože nemusíte kupovat další hardware, můžete nastavit tunel mezi vaším serverem s veřejnou adresou a cloudem. Nicméně, latence, omezený výkon (protože kanál je třeba šifrovat) a navíc negarantovaná konektivita (protože přístup probíhá přes běžný internet) mohou být nevýhodou.
Co je potřeba udělat?
Zřídit připojení přes dedikovanou linku (například u AWS se tomu říká Direct Connect). K tomu je potřeba najít partnera-operatora, který vás připojí, určit se s nejbližším bodem zapojení (jak vás k operatorovi, tak operatora do cloudu) a nakonec všechno nastavit. Je možné toto vše udělat bez síťového inženýra? Určitě, ano. Jak to však problém řešit bez něj, když nastanou potíže — to už tak jasné není.
Také mohou nastat problémy s dostupností mezi cloudu (pokud máte multi-cloud) nebo problémy s latencí mezi různými regiony atd. Samozřejmě, nyní existuje mnoho nástrojů, které zvyšují transparentnost toho, co se v cloudu děje (například Thousand Eyes), ale to jsou všechno nástroje síťového inženýra, a ne jeho náhrada.
Mohl bych napsat ještě desítky takových příkladů ze své praxe, ale myslím, že je jasné, že v týmu, počínaje určitým stupněm rozvoje infrastruktury, by měl být člověk (a lépe více než jeden), který ví, jak funguje síť, bude schopen nastavit síťové zařízení a vyřešit problémy, pokud nastanou. Věřte mi, bude mít co na práci.
Co by měl síťový inženýr vědět?
Není vůbec nezbytné (a někdy dokonce škodlivé), aby se síťový inženýr zabýval pouze sítí a ničím jiným. I když nezohledníme variantu s infrastrukturou, která téměř celá žije v veřejném cloudu (a ta se, ať se vám to líbí nebo ne, stává čím dál populárnější), vezmeme např. on-premise nebo soukromé cloudy, kde se s jedinými "znalostmi na úrovni CCNP" daleko nedostanete.
Kromě samotných sítí — i když zde je přímo bezedné pole pro studium, i když se zaměříte pouze na jedno konkrétní směrování (providerové sítě, enterprise, datacentra, wifi...)
Samozřejmě, mnozí z vás si nyní vzpomenou na Python a další „automaci sítě“, ale to je pouze nezbytný, nikoli však postačující předpoklad. Aby se síťový inženýr „úspěšně zapojil do týmu“, musí umět mluvit jedním jazykem jak s vývojáři, tak s kolegy administrátory/devopsy. Co to znamená?
- Umět nejen pracovat v Linuxu jako uživatel, ale také ho spravovat, alespoň na úrovni junior administrátora: nasadit potřebný software, restartovat padlou službu, napsat jednoduchou unit pro systemd.
- Rozumět (alespoň v obecných rysech), jak funguje síťový stack v Linuxu, jak je sítí ve hypervizorech a kontejnerech (lxc / docker / kubernetes).
- Samozřejmě, umět pracovat s ansible/chef/puppet nebo jiným systémem SCM.
- Zvláštní zmínku si zaslouží SDN a sítě pro soukromé cloudu (například TungstenFabric nebo OpenvSwitch). To je další obrovský objem znalostí.
Pokud to shrneme, popsal jsem typického specialistu ve tvaru T (jak se teď říká). Zdá se, že nic nového, avšak podle zkušeností z pohovorů daleko ne všichni síťoví inženýři mohou se chlubit znalostmi alespoň v dvou tématech z výše uvedeného seznamu. V praxi, nedostatek znalostí „v příbuzných oblastech“ velmi ztěžuje nejen komunikaci s kolegy, ale také porozumění požadavkům, které podnik klade na síť jako na nejzákladnější infrastrukturu projektu. A bez tohoto porozumění je těžší obhájit svůj názor a „prodat“ ho byznysu.
Na druhé straně, zvyk „rozumět, jak systém funguje“ poskytuje síťařům velmi dobrou výhodu před různými „specialisty širokého profilu“, kteří vědí o technologiích ze článků na Habr/Medium a chatů na Telegramu, ale nemají vůbec představu o tom, na jakých principech funguje ten či onen software. A znalost některých zákonitostí, jak je známo, úspěšně nahrazuje znalost mnoha faktů.
Závěry, nebo jednoduše TL;DR
- Síťový administrátor (stejně jako DBA nebo VoIP inženýr) je specialista poměrně úzkého profilu (na rozdíl od sysadminů/devops/SRE), jehož potřeba nevzniká hned (a může dlouho nevznikat). Ale když už vznikne, těžko ji nahradí expertíza zvenčí (outsourcing nebo obvyklí administrátoři širokého profilu, „kteří se ještě starají o síť“). Což je trochu smutné — potřeba takových specialistů je malá, a za předpokladu, že ve firmě je 800 programátorů a 30 devops/administrátorů, mohou být jen dva síťoví administrátoři, kteří skvěle plní své povinnosti. T.j. trh byl a stále je velmi malý, a s dobrou mzdou — a to ještě méně.
- Na druhou stranu, dobrý síťový administrátor v moderním světě by měl rozumět nejen samotným sítím (a jak automatizovat jejich nastavení), ale také tomu, jak s nimi interagují operační systémy a software, který nad těmito sítěmi běží. Bez toho bude extrémně těžké pochopit, co po tobě kolegové žádají, a přiměřeně předat své požadavky.
- Neexistuje žádný cloud, je to jen počítač někoho jiného. Je třeba pochopit, že použití veřejných/soukromých cloudů nebo služeb poskytovatelů hostingu „který vše dělá na klíč“ nezrušuje to, že vaše aplikace stále využívá síť, a problémy s ní budou mít vliv na provoz vaší aplikace. Vaše volba — kde bude umístěno centrum kompetence, které bude odpovědné za síť vašeho projektu.
Zdroj: habr.com
