Nätverkstekniker (är) nödvändiga

Vid skrivandet av denna artikel gav en sökning på en populär jobbsida med frasen "Nätverkstekniker" omkring trehundra lediga tjänster över hela Ryssland. För jämförelsevis visar en sökning med frasen "systemadministratör" nästan 2500 lediga tjänster, medan "DevOps ingenjör" visar nästan 800.

Betyder detta att nätverksfolk inte längre behövs i en tid med dominerande moln, Docker, Kubernetes och allestädes närvarande offentliga Wi-Fi?
Låt oss reda ut detta (c)

Låt mig presentera mig. Jag heter Aleksei och jag är nätverksingenjör.

Jag har arbetat med nätverk i mer än 10 år och har mer än 15 års erfarenhet av olika *nix-system (har fått möjlighet att arbeta med både Linux och FreeBSD). Jag har arbetat för teleoperatörer, stora företag som ofta betraktas som "enterprise", och på senare tid har jag arbetat i en "ung och djärv" fintech där moln, DevOps, Kubernetes och andra skrämmande termer som säkerligen kommer att göra mig och mina kollegor överflödiga. När som helst. Kanske.

ansvarsfriskrivning: "I vårt liv är inte allt, alltid och överallt, utan ibland och på vissa ställen" (c) Maxim Dorofejev.

Allt som skrivit nedan kan och bör anses vara författarens personliga åsikter, utan anspråk på den slutgiltiga sanningen, och inte ens på en fullständig forskning. Alla karaktärer är fiktiva, alla likheter är slumpmässiga.

Välkommen till min värld.

Var kan man överhuvudtaget träffa nätverksfolk?

1. Telekomoperatörer, tjänsteföretag och andra integratörer. Här är det enkelt: nätverk är en affär för dem. De säljer antingen direkt anslutning (operatörer) eller tillhandahåller tjänster för att starta/underhålla nätverk för sina kunder.

Det finns mycket erfarenhet här, men inte mycket pengar (om du inte är direktör eller en framgångsrik försäljningschef). Men om du gillar nätverk och är i början av din karriär, kommer en roll i support på en mindre operatör fortfarande vara en perfekt startpunkt (i federala företag är allt väldigt genomsyrat av manus och det finns lite utrymme för kreativitet). Berättelser om att man kan växa från en jouringenjör till en C-level chef på några år är också fullt möjliga, även om de är sällsynta av uppenbara skäl. Det finns alltid behov av personal, eftersom personalomsättningen verkligen förekommer. Det är både bra och dåligt på samma gång — det finns alltid lediga tjänster, å andra sidan tenderar de mest aktiva/intelligenta ofta att snabbt gå vidare till högre positioner eller till andra, mer 'bekväma' platser.

2. Tveksamt "enterprise". Oavsett om företagets huvudverksamhet är IT eller inte, är det viktigaste att det finns en egen IT-avdelning som ansvarar för drift av företagets interna system, inklusive nätverk på kontoren och kommunikationskanaler till filialerna osv. I sådana företag kan en systemadministratör (om nätverksinfrastrukturen är liten, eller hanteras av en extern entreprenör) fungera som nätverksingenjör. Om det finns en nätverksingenjör kan den personen dessutom övervaka telefoni och SAN (för att vara tydlig). Lönerna varierar mycket — det beror starkt på affärens lönsamhet, företagets storlek och organisation. Jag har arbetat med företag där man ofta belastade Routerns kapacitet, och företag där nätverket byggdes av skräp, pinnar och blå tejp, där servrarna aldrig uppdaterades (det är onödigt att nämna att det inte heller fanns några reserver). Erfarenheten här är betydligt mindre, och den kommer nästan säkert att vara inom området för hård vendor-lock eller

3. Produktföretag, vars vinst kommer från utveckling (och ofta, drift) av någon mjukvara eller plattform — den så kallade produkten. Vanligtvis är de små och snabba, de har inte kommit långt i skala jämfört med stora företag och deras byråkrati. Här finns massor av devops, kuber, dockor och andra skrämmande termer som säkert kommer att göra nätverken och nätverksingénjörerna till en överflödig rest.

Vad skiljer en nätverksingenjör från en systemadministratör?

I människors uppfattning utanför IT — är det inget. Både den ena och den andra tittar på en svart skärm och skriver något slags formel, ibland muttrande tyst.

I programmerarnas ögon — kanske som ett ämnesområde. Systemadministratörer administrerar servrar, nätverksadministratörer hanterar switchar och routrar. Ibland görs det dåligt, och då faller allt ihop. I sådana fall är det alltid nätverksadministratörernas fel. Just because fuck you, that’s why.

Men i verkligheten är den viktigaste skillnaden arbetssättet. Bland nätverksadministratörer är det nog flest som förespråkar ”Fungerar — rör det inte!”. Att göra något (inom en enskild leverantör) kan vanligtvis göras på endast ett sätt, hela konfigurationen av enheten — den ligger där, i din hand. Priset för ett misstag — är högt, ibland till och med mycket högt (till exempel måste man åka flera hundra kilometer för att starta om routern, medan flera tusen personer kommer vara utan kontakt — en helt vanlig situation för en operatör).

Enligt min åsikt är det just därför som nätverksingenjörer, å ena sidan, är extremt motiverade att upprätthålla nätverksstabilitet (och förändringar är stabilitetens främsta fiende), och å andra sidan går deras kunskaper djupare snarare än bredare (det krävs inte att man kan konfigurera tiotals olika tjänster, man måste förstå teknologierna och deras implementering hos en specifik tillverkare). Det är därför en systemadministratör som har googlat hur man konfigurerar VLAN på Cisco — inte räknas som en nätverksadministratör. Och det är osannolikt att han effektivt kan stödja (eller felsöka) ett mer eller mindre komplext nätverk.

Men varför behövs en nätverksadministratör om du har hostingleverantören?

Mot en extra kostnad (och om du är en mycket stor och omtyckt kund — kanske till och med gratis, "som en vän") kommer datacenteringenjörer att konfigurera dina switchar efter dina behov och kanske till och med hjälpa till att etablera BGP-anslutningar med leverantörerna (om du har ditt eget underrättelse IP-adresser för annonseringen).

Huvudproblemet är att datacentret inte är din IT-avdelning, utan ett separat företag vars mål är att göra vinst. Detta inkluderar också vinster från dig som kund. Datacentret tillhandahåller hyllor, ser till att de får el och kyla, samt ger viss "standard" anslutning till internet. Baserat på denna infrastruktur kan datacentret placera din utrustning (colocation), hyra ut en server till dig (dedicated server), eller erbjuda managed service (till exempel OpenStack eller K8s). Men datacentrets (vanligtvis) affärsidé är inte att administrera kundernas infrastruktur, eftersom denna process är ganska arbetsintensiv, svårt att automatisera (och i ett normalt datacenter är allt som möjligt automatiserat), ännu svårare att standardisera (varje kund är unik) och i allmänhet kan leda till klagomål ("ni installerade servern åt mig, men nu har den kraschat, det är ert fel!!!111"). Därför, om hostingleverantören hjälper dig med något, kommer de att försöka göra det så enkelt och "standardiserat" som möjligt. Det är för att göra något komplicerat inte är lönsamt, åtminstone sett till den arbetsmängd som ingenjörerna hos denna hostingleverantör har (men situationer kan vara olika, se disclaimer). Detta innebär inte att hostingleverantören nödvändigtvis gör allt dåligt. Men det är långt ifrån en garanti att de kommer att göra precis det som du verkligen behövde.

Det kan tyckas vara en ganska uppenbar sak, men jag har flera gånger stött på att företag har börjat förlita sig på sin hostingprovider lite mer än vad som var rimligt, vilket aldrig lett till något bra. Jag har varit tvungen att förklara länge och detaljerat att ingen SLA kan täcka förluster från stillestånd (det finns undantag, men dessa är vanligtvis mycket, MYCKET dyra för kunden) och att hostingleverantören överhuvudtaget inte är medveten om vad som händer i beställarnas infrastruktur (förutom väldigt allmänna indikatorer). Och backuper gör hostingleverantören inte för dig heller. Ännu värre blir det om du har mer än en hostingleverantör. Vid problem mellan dem kommer de definitivt inte att reda ut vad som egentligen har gått fel.

Motivationen här är exakt de samma som när det gäller valet mellan "egen administratörsgrupp vs outsourcing". Om riskerna är beräknade, kvaliteten är tillfredsställande och företaget inte har något emot det — varför inte prova? Å andra sidan är nätverket en av de mest grundläggande lagren av infrastrukturen, och det är tveksamt om man bör överlämna det åt externa personer, särskilt om allt annat redan hanteras internt.

När behövs en nätverksingenjör?

Härnäst handlar det specifikt om moderna produktbolag. Med operatörer och stora företag är situationen mer eller mindre klar — det har inte förändrats mycket under de senaste åren, och nätverksingenjörer har alltid varit nödvändiga där. Men med de "unga och djärva" är det inte så entydigt. Ofta lägger de hela sin infrastruktur i molnet, så de behöver inte speciellt många administratörer — förutom administratörerna för just dessa moln, förstås. Infrastrukturen är å ena sidan ganska enkel, å andra sidan är den väl automatiserad (ansible/puppet, terraform, ci/cd… ni vet). Men även här finns det situationer där man inte kan klara sig utan en nätverksingenjör.

Exempel 1, klassiskt

Anta att företaget börjar med en server med en offentlig ip-adress, som står i datacentret. Sedan ökar antalet servrar till två. Sedan fler... Tidigt eller sent kommer behovet av ett privat nätverk mellan servrarna. Eftersom "extern" trafik begränsas både i bandbredd (max 100 Mbit/s till exempel) och i volym nedladdat/överfört per månad (olika värdar har olika priser, men bandbredd i den externa världen är oftast mycket dyrare än för ett privat nätverk).

Värden lägger till extra nätverkskort i servrarna och ansluter dem till sina switchar i en separat vlan. En "platt" lokalnätverk uppstår mellan servrarna. Bekvämt!

Antalet servrar ökar, trafiken i det privata nätverket också — säkerhetskopior, replikeringar osv. Huvudleverantören erbjuder att flytta er till separata switchar så att ni inte stör andra kunder och de inte stör er. Leverantören installerar vissa switchar och konfigurerar dem på ett eller annat sätt — troligtvis lämnar man en platt nätverksstruktur mellan alla era servrar. Allt fungerar bra, men vid en viss punkt börjar problem att uppstå: latenser mellan värdarna ökar periodvis, i loggarna syns varningar om för många arp-paket per sekund, och en penetrationstestare lyckades bryta sig in i hela ert lokala nätverk genom att bara hacka en server.

Vad behöver göras?

Dela nätverket i segment — VLAN. Konfigurera en egen adressering i varje VLAN, utse en gateway som hanterar trafiken mellan nätverken. På gatewayn sätta upp ACL för att begränsa åtkomst mellan segmenten, eller helt enkelt installera en separat brandvägg bredvid.

Exempel 1, fortsättning

Servrarna är anslutna till det lokala nätverket med en kabel. Switcharna i racken är på något sätt sammanlänkade, men vid ett haveri i ett rack förlorar också tre angränsande rack anslutningen. Det finns scheman, men det finns tveksamheter kring deras relevans. Varje server har en offentlig adress som tillhandahålls av leverantören och är kopplad till racken. D.v.s. när servern flyttas måste adressen ändras.

Vad behöver göras?

Anslut servrarna med hjälp av LAG (Link Aggregation Group) med två kablar till switcharna i racken (även dessa behöver redundans). Säkra anslutningarna mellan racken, omkonfigurera till "stjärna" (eller den idag trendiga CLOS), så att bortfall av ett rack inte påverkar de andra. Utse "centrala" rack där det nätverkskärnan kommer att placeras och där andra rack kommer att kopplas in. Åtgärda även offentlig adressering, erhåll av leverantören (eller av RIR, om möjligt) ett subnet som ni, själva (eller via leverantören) kan annonsera mot omvärlden.

Kan en "vanlig" systemadministratör utan djupa kunskaper inom nätverk klara av allt detta? Jag är osäker. Kommer leverantören att göra det? Kanske, men det kommer att krävas en ganska detaljerad kravspecifikation från er, som också behöver skrivas av någon. Och därefter kontrollera att allt görs korrekt.

Exempel 2. Moln

Anta att du har en VPC i något offentligt moln. För att få åtkomst från kontoret eller on-prem-delen av infrastrukturen till det lokala nätverket inom VPC, behöver du konfigurera en anslutning via IPSec eller en dedikerad lina. Å ena sidan är IPSec billigare eftersom du inte behöver köpa extra hårdvara, du kan ställa in en tunnel mellan din server med offentlig IP-adress och molnet. Men - det finns förseningar, begränsad prestanda (eftersom kanalen måste krypteras), plus osäker anslutning (eftersom åtkomsten går genom vanligt internet).

Vad behöver göras?

Upprätta en anslutning via en dedikerad lina (till exempel, hos AWS kallas detta Direct Connect). För detta, hitta en partneroperatör som kan ansluta dig, bestämma närmaste ingångspunkt (både för dig till operatören och operatören till molnet), och slutligen konfigurera allt. Kan detta göras utan nätverksingenjör? Sannolikt, ja. Men hur man felsöker detta utan honom i händelse av problem är inte så klart.

Det kan också uppstå problem med tillgänglighet mellan moln (om du har en multiskylt) eller problem med fördröjningar mellan olika regioner, osv. Certainly har det nu kommit många verktyg som ökar transparensen kring vad som händer i molnet (som Thousand Eyes), men dessa är fortfarande nätverksingenjörens verktyg, inte dess ersättning.

Jag skulle kunna nämna ett dussin sådana exempel från min egen praktik, men jag tror att det är tydligt att i ett team, när infrastrukturen når en viss utvecklingsnivå, måste det finnas någon (och helst flera) som vet hur nätverket fungerar, kan konfigurera nätverksutrustningen och lösa problem om de uppstår. Tro mig, det kommer att finnas mycket att göra.

Vad bör en nätverksingenjör veta?

Det är inte nödvändigt (och ibland till och med skadligt) att nätverksingenjören endast fokuserar på nätverket och inget annat. Även om man inte tar hänsyn till alternativet med infrastruktur som nästan helt lever i det offentliga molnet (och det blir, oavsett hur man ser på det, allt mer populärt), och tar exempelvis on-premise eller privata moln, där man inte klarar sig endast med 'kunskaper på CCNP-nivå'.

Förutom nätverken - på detta område finns det en oändlig mängd att studera, även om man endast fokuserar på ett visst område (operatörnätverk, företag, datacenter, WiFi…)

Självklart, många av er kommer att tänka på Python och annan "nätverksautomation", men det är bara ett nödvändigt, men inte tillräckligt villkor. För att en nätverksingenjör ska kunna "integrera framgångsrikt i teamet" måste han kunna prata samma språk med både utvecklare och kollegor inom administration/devops. Vad innebär det?

• kunna inte bara arbeta i Linux som användare utan också administrera det, åtminstone på en junior sysadmin-nivå: installera nödvändig programvara, starta om en kraschad tjänst, skriva en enkel systemd-enhet.
• förstå (åtminstone i stora drag) hur nätverksstacken i Linux fungerar, hur nätverket är uppbyggt i hypervisorer och containrar (lxc / docker / kubernetes).
• Självklart, kunna arbeta med ansible/chef/puppet eller något annat SCM-system.
• Det bör också nämnas speciellt om SDN och nätverk för privata moln (till exempel TungstenFabric eller OpenvSwitch). Detta är ännu en stor mängd kunskap.

Sammanfattningsvis har jag beskrivit en typisk T-formad specialist (som det numera kallas). Det verkar som inget nytt, men av erfarenhet från intervjuer kan inte alla nätverksingenjörer skryta med att ha kunskaper i åtminstone två ämnen från listan ovan. I praktiken gör bristen på kunskaper "inom angränsande områden" kommunikationen med kollegor mycket svårare, liksom förståelsen för de krav som verksamheten ställer på nätverket som den mest grundläggande infrastrukturen i projektet. Utan denna förståelse blir det svårare att argumentera för sin åsikt och "sälja" den till verksamheten.

Å andra sidan ger den vanan att "förstå hur systemet fungerar" nätverksingenjörer ett stort försprång framför olika "specialister med bred kompetens" som endast känner till teknologier genom artiklar på Habré/Medium och chattar på Telegram, men som inte har någon verklig förståelse för vilka principer som ligger bakom olika programvaror. Och att känna till vissa åkommor ersätter framgångsrikt kunskapen om många fakta.

Slutsatser, eller helt enkelt TL;DR

1. Nätverksadministratör (precis som DBA eller VoIP-ingenjör) är en specialist med ganska snäva kunskapsområden (i motsats till systemadministratörer/devops/SRE), vars behov inte uppstår omedelbart (och kanske inte ens under lång tid). Men när behovet väl uppstår, är det osannolikt att man kan ersätta den expertisen från utsidan (outsourcing eller vanliga administratörer med bred profil, "som också håller ett öga på nätet"). Det är något sorgligt — behovet av sådana specialister är litet, och i en företag med 800 programmerare och 30 devops/administratörer kan det finnas endast två nätverksadministratörer som gör ett utmärkt jobb. Det vill säga, marknaden har varit och är fortfarande mycket liten, och för att få en bra lön — ännu mindre.
2. Å andra sidan bör en bra nätverksadministratör i den moderna världen inte bara veta om nätverk (och hur man automatiserar deras konfiguration), utan också hur operativsystem och programvaror som körs ovanpå dessa nätverk interagerar. Utan detta blir det extremt svårt att förstå vad kollegorna begär av dig och att motivera dina önskemål/krav till dem.
3. Det finns ingen moln, det är bara någon annans dator. Man måste förstå att användningen av offentliga/privata moln eller tjänster från hostingleverantörer "som gör allt åt dig nyckelfärdigt" inte avskaffar det faktum att din applikation fortfarande använder nätverket, och problem med det kommer att påverka din applikations funktion. Ditt val — var kompetenscentret kommer att ligga, som kommer att ansvarar för nätverket för ditt projekt.

Källa: habr.com