Nettverksingeniører (er) nødvendige

På tidspunktet for denne artikkelen ga søk på et populært jobbnettsted etter frasen «Nettverksingeniør» omtrent tre hundre stillinger i hele Russland. Til sammenligning gir søk etter uttrykket «systemadministrator» nesten 2,5 tusen stillinger, mens «DevOps-ingeniør» nærmer seg 800.

Betyr dette at nettverksfolk ikke lenger er nødvendige i en tid med dominerende skyer, Docker, Kubernetes og allestedsnærværende offentlig Wi-Fi?
La oss undersøke (c)

La oss bli kjent. Jeg heter Alexey, og jeg er nettverksingeniør.

Jeg har jobbet med nettverk i over 10 år og har mer enn 15 års erfaring med ulike *nix-systemer (har hatt erfaring med både Linux og FreeBSD). Jeg har jobbet for telekommunikasjonsoperatører og store selskaper, som gjerne kalles «enterprise», og den siste tiden har jeg jobbet i en «ung og dristig» fintech, hvor skyer, DevOps, Kubernetes og andre skremmende ord kan gjøre meg og kollegene mine unødvendige. En dag. Kanskje.

ansvarsfraskrivelse: «I livet vårt er ikke alt alltid og overalt perfekt, men noen ganger og steder» (c) Maxim Dorofejev.

Alt som er skrevet nedenfor, kan og skal betraktes som forfatterens personlige mening, som ikke gjør krav på å være den endelige sannheten, eller engang en fullverdig studie. Alle karakterer er fiktive, alle likheter er tilfeldige.

Velkommen til min verden.

Hvor kan man egentlig møte nettverksfolk?

1. Telekommunikasjonsoperatører, tjenesteselskaper og andre integratorer. Her er alt enkelt: Nettverket er for dem en forretning. De selger enten direkte tilkobling (operatører), eller tilbyr tjenester for oppstart/vedlikehold av nettverk for sine kunder.

Her er det mye erfaring, men ikke så mye penger (med mindre du er direktør eller en vellykket salgsleder). Likevel, hvis du liker nettverk og er i starten av karrieren din, vil en jobb innen support hos en mindre operatør være, selv nå, et perfekt utgangspunkt (hos de store er alt veldig skjematisk, og det er lite rom for kreativitet). Og historiene om at man kan vokse fra en operatøringeniør til C-level manager på få år, er også helt reelle, selv om de er sjeldne, av åpenbare grunner. Behovet for arbeidskraft finnes alltid, fordi det er en viss omsetning. Dette er både bra og dårlig — det er alltid ledige stillinger, på den annen side — ofte forlater de mest aktive / kloke jobber raskt, enten for en forfremmelse eller for andre, mer «behagelige» steder.

2. Betinget «enterprise»Uansett om hovedvirksomheten hans har noe med IT å gjøre eller ikke. Det viktigste er at de har sin egen IT-avdeling som jobber med drift av interne systemer i selskapet, inkludert nettverket på kontorene, kommunikasjonslinjene til filialene og så videre. Rolle som nettverksingeniør i slike selskaper kan administreres av en systemadministrator (hvis nettverksinfrastrukturen er liten, eller hvis en ekstern leverandør håndterer det), mens nettverksingeniøren, hvis han faktisk er til stede, også kan ta seg av telefonisystemet og SAN (fordi hvorfor ikke). Lønningene varierer – det avhenger sterkt av lønnsomheten i forretningen, størrelsen på selskapet og strukturen. Jeg har jobbet med selskaper hvor Cisco-enheter ble presset til det ytterste, og med selskaper der nettverket ble bygget av søppel, pinner og blå-isolasjonsteip, og serverne aldri ble oppdatert (trenger jeg å si at det heller ikke var gjort noen reserver?). Erfaringene her er betydelig mindre, og vil nesten sikkert være innen for hard vendor-lock, eller 'hvordan lage noe ut av ingenting'. Personlig syntes jeg det virket dødskjedelig der, selv om mange liker det – alt skjer i et behagelig tempo og er forutsigbart (hvis vi snakker om store selskaper), 'dora-ka-bahato' og så videre. Ikke mindre enn en gang i året sier en stor leverandør at de har utviklet en ny mega-super-duper-system som nå automatiserer absolutt alt, og at alle systemadministratorer og nettverksingeniører kan avskjediges, bare etterlate noen få til å trykke på knapper i et pent grensesnitt. Virkeligheten er at selv om man abstraherer fra kostnaden av løsningen, vil ikke nettverksingeniører forsvinne derfra. Ja, kanskje det i stedet for konsollen igjen vil være et webgrensesnitt (men ikke for en bestemt enhet, men for et stort system som styrer dusinvis og hundrevis av slike enheter), men kunnskapen 'hvordan alt er bygget opp' vil fortsatt være nødvendig.

3. Produktbedrifter, hvor inntektene kommer fra utviklingen (og ofte driften) av programvare eller plattformer – det produktet. Vanligvis er de små og dynamiske, de er fortsatt langt fra størrelsen på store selskaper og deres byråkrati. Det er nettopp her at devops, kuber, docker og andre skumle ord finnes i stor skala, og de vil definitivt gjøre nettverket og nettverksingeniørene til unødvendige relikter.

Hvordan skiller en nettverksingeniør seg fra en systemadministrator?

I folks sin forstand som ikkje kjem frå IT – ingenting. Begge ser på den svarte skjermen og skriv nokre formularar, av og til mumlar dei stille.

I programmerarane si forståing – kanskje berre som ei fagområde. Sysadminar administrerer serverar, nettverksfolk administrerer svitsjar og rutarar. Nokon gonger gjer dei det dårleg, og alt faller saman. Vel, i tilfelle noko rart skjer, skuldast det også nettverksfolka. Just because fuck you, that’s why.

I verkelegheita er det viktigaste skillet tilnærminga til arbeidet. Kanskje er det among nettverksfolk at tilnærminga «Det fungerer – ikkje rør!» er mest utbreidd. Du kan som regel berre gjere ei oppgåve (innan ein leverandør) på éin måte, og heile konfigureringa av boksen – den ligg rett der i handflata. Feilpris – høg, og av og til er det veldig høg (til dømes, du må reise fleire hundre kilometer for å omstarte rutaren, og i mellomtida vil fleire tusen menneske sitte utan forbindelse – heilt vanleg for ein teleoperatør).

Etter mi meining er det derfor nettverksingeniørar, på den eine sida, svært motivert for stabiliteten til nettverket (og endringar er hovudfienden til stabilitet), og på den andre sida, går kunnskapen deira meir i djupda enn i breidda (du må ikkje kunne konfigurere ti ulike demonar, du må vite teknologiane og deira implementering hos den spesifikke utstyrsprodusenten). Derfor er ikkje sysadminen som har googla korleis han kan konfigurere VLAN på Cisco, ein nettverksmann. Og han vil neppe kunne støtte (og også feilsøke) eit meir eller mindre komplisert nettverk effektivt.

Men kvifor treng du ein nettverksmann, når du har hoster?

For ein ekstra kostnad (og dersom du er ein veldig stor og elsket kunde – kanskje til og med gratis, «for vennskap»), vil datacenteringeniørar konfigurere svitsjane dine etter dine behov, og kanskje til og med hjelpe deg med å sette opp BGP-peering med leverandørar (hvis du har ditt eige subnett IP-adresser for annonsering).

Det grunnleggende problemet er at datasenteret ikke er IT-avdelingen din, det er et eget selskap med mål om å tjene penger. Inkludert ved å belaste deg som kunde. Datasenteret tilbyr racks, gir dem strøm og kjøling, og gir også en viss «standard» tilkobling til internett. Basert på denne infrastrukturen kan datasenteret plassere utstyret ditt (colocation), leie deg en server (dedicated server) eller tilby managed services (for eksempel OpenStack eller K8s). Men forretningsmodellen til datasenteret er vanligvis ikke å administrere kundenes infrastruktur, fordi denne prosessen er svært tidkrevende, vanskelig å automatisere (og i et normalt datasenter er alt som er mulig automatisert), enda vanskeligere å standardisere (hver kunde er individuell), og generelt kan det føre til klager («Du satte opp serveren min, og nå har den krasjet, det er dere som har skylden!!!111»). Derfor, hvis vertskapet hjelper deg med noe, vil det prøve å gjøre det så enkelt og «standard» som mulig. Det å gjøre noe komplisert er ikke lønnsomt, i hvert fall ikke når det gjelder ingeniørenes arbeidskraft i det samme vertskapet (men situasjoner kan variere, se forbehold). Det betyr ikke at vertskapet nødvendigvis gjør alt dårlig. Men det er heller ikke sikkert at de gjør nettopp det du egentlig hadde behov for.

Det kan virke ganske åpenbart, men jeg har flere ganger opplevd at selskaper begynte å stole på hosting-leverandøren sin litt mer enn de burde, noe som aldri endte godt. Jeg måtte bruke mye tid på å forklare at ingen SLA vil dekke tapene fra nedetid (det finnes unntak, men de er vanligvis veldig, VELDIG dyre for kunden) og at vertskapet overhodet ikke vet hva som foregår i kundens infrastruktur (bortsett fra veldig generelle indikatorer). Og vertskapet tar heller ikke backup for deg. Det blir enda verre hvis du har mer enn én vertskap. I tilfelle problemer mellom dem, vil de absolutt ikke finne ut av hva som egentlig gikk galt for deg.

Motivene er de samme som når man velger 'egen administrasjonsgruppe vs outsourcing'. Hvis risikoene er vurdert, kvaliteten er god, og bedriften er åpen for det — hvorfor ikke prøve? På den annen side er nettverket en av de mest grunnleggende lagene i infrastrukturen, og det er knapt verdt å overlate det til eksterne folk, hvis alt annet allerede administreres internt.

Når trenger man en nettverksingeniør?

Her skal vi spesifikt snakke om moderne produktbaserte selskaper. Når det gjelder operatører og enterprise, er situasjonen mer eller mindre klar — det har ikke vært mye forandring de siste årene, og nettverksingeniører har alltid vært nødvendige der. Men med de 'unge og dristige' er det ikke så entydig. De plasserer ofte hele infrastrukturen sin i skyen, så de trenger vanligvis ikke engang administratorer — bortsett fra administratorene for de aktuelle skyene, selvfølgelig. Infrastrukturen er, på den ene siden, forholdsvis enkel infrastrukturmessig, men på den annen side er den godt automatisert (ansible/puppet, terraform, ci/cd… ja, du vet). Men selv her er det situasjoner hvor man ikke kan klare seg uten en nettverksingeniør.

Eksempel 1, klassisk

La oss anta at et selskap starter med én server med offentlig IP-adresse, plassert i et datasenter. Så blir det to servere. Så flere... Rått eller sent, blir det nødvendig med et privat nettverk mellom serverne. Fordi 'utenlandstrafikk' er begrenset både når det gjelder båndbredde (ikke mer enn 100Mbit/s for eksempel) og mengden nedlastet/opplastet per måned (forskjellige leverandører har forskjellige priser, men båndbredden til omverdenen er som regel mye dyrere enn det private nettverket).

Verten legger til ekstra nettverkskort i serverne og kobler dem til sine svitsjer i en egen VLAN. Mellom serverne opprettes et 'flat' lokalt nettverk. Praktisk!

Antallet av servere øker, trafikken i det private nettverket gjør det også — backup, replikasjoner osv. Leverandøren tilbyr å flytte deg til separate svitsjer slik at du ikke forstyrrer andre kunder, og de ikke forstyrrer deg. Leverandøren setter opp noen svitsjer og konfigurerer dem på en eller annen måte — mest sannsynlig ved å la alle serverne dine være på et flatt nettverk. Alt fungerer bra, men etter hvert oppstår det problemer: periodisk øker forsinkelsene mellom vertsene, i loggene er det klager på for mange arp-pakker per sekund, og en pentester fikk tilgang til hele ditt lokale nettverk under revisjonen, bare ved å bryte en server.

Hva må gjøres?

Del nettverket opp i segmenter — VLAN-er. Konfigurer hver VLAN med sin egen adressering, tildel en gateway som vil dirigere trafikk mellom nettverkene. På gatewayen konfigurer ACL for å begrense tilgangen mellom segmentene, eller sett opp en egen brannmur ved siden av.

Eksempel 1, fortsettelse

Serverne er koblet til det lokale nettverket med én ledning. Svitsjene i skapene er koblet sammen på en eller annen måte, men hvis det skjer en feil i ett skap, mister tre naboer også tilkoblingen. Skjemaene eksisterer, men det er tvil om deres relevans. Hver server har sin egen offentlige adresse, som tilbys av leverandøren og er knyttet til skapet. Det vil si at når serveren flyttes, må adressen endres.

Hva må gjøres?

Koble serverne sammen med LAG (Link Aggregation Group) med to ledninger til svitsjene i skapet (de må også være reservert). Sørg for at tilkoblingene mellom skapene er reservert, endre dem til et 'stjernemønster' (eller den moderne CLOS), slik at en enkelt skapfeil ikke påvirker de andre. Tildel 'sentrale' skap der det nettverkskjernen vil ligge, og der andre skap skal kobles til. Samtidig, sørg for å ordne den offentlige adresseringen, få en adresseblokk fra leverandøren (eller fra RIR, hvis mulig) som selv kan annonseres til verden.

Kan alt dette gjøres av en 'vanlig' systemadministrator uten dyp kunnskap om nettverk? Jeg er ikke sikker. Vil leverandøren gjøre det? Kanskje de vil, men du må gi en ganske detaljert spesifikasjon, som også må skrives av noen. Og deretter må du kontrollere at alt er gjort riktig.

Eksempel 2. Skyen

La oss si at du har en VPC i en offentlig sky. For å få tilgang fra kontoret eller den lokale delen av infrastrukturen til det lokale nettverket inne i VPC, må du sette opp en tilkobling via IPSec eller en dedikert linje. På den ene siden er IPSec billigere, siden du ikke trenger å kjøpe ekstra maskinvare, og du kan sette opp en tunnel mellom serveren din med offentlig adresse og skyen. Men det er forsinkelser, begrenset ytelse (siden kanalen krever kryptering), pluss usikker tilkobling (siden tilgangen går via vanlig internett).

Hva må gjøres?

Sett opp tilkobling via dedikert linje (for eksempel kalles dette Direct Connect hos AWS). For dette må du finne en partneroperatør som kan koble deg til, bestemme den nærmeste tilkoblingspunktet (både fra deg til operatøren og fra operatøren til skyen), og til slutt sette opp alt. Kan dette gjøres uten nettverksingeniør? Sannsynligvis ja. Men hvordan løser man problemer uten en? Det er ikke så klart.

Det kan også oppstå problemer med tilgjengeligheten mellom skyer (hvis du har multicloud) eller problemer med forsinkelser mellom forskjellige regioner osv. Uten tvil har det nå kommet mange verktøy som øker gjennomsiktigheten i hva som skjer i skyen (som Thousand Eyes), men det er alle verktøy for nettverksingeniører og ikke en erstatning for dem.

Jeg kunne fortsatt ramse opp dusinet av slike eksempler fra min praksis, men jeg tror det er klart at i et team, fra et visst nivå av infrastrukturutvikling, må det være en person (og helst flere) som vet hvordan nettverket fungerer, kan sette opp nettverksutstyr og håndtere problemer hvis de oppstår. Tro meg, han vil ha mer enn nok å gjøre.

Hva bør en nettverksingeniør vite?

Det er ikke nødvendig (og til og med noen ganger skadelig) for en nettverksingeniør å kun jobbe med nettverket og ingenting annet. Selv om man ikke vurderer infrastrukturen som nesten helt lever i offentlig sky (og det, som sagt, blir mer og mer populært), og tar for eksempel on premise eller private skyer, der kun "kunnskap på CCNP-nivå" ikke vil være tilstrekkelig.

I tillegg til selve nettverkene - selv om dette er et uendelig felt for studier, selv om man bare fokuserer på ett enkelt område (operatørnettverk, enterprise, datasentre, wifi...)

Selvfølgelig vil mange av dere nå tenke på Python og annen "nettverksautomatisering", men dette er bare et nødvendig, men ikke tilstrekkelig vilkår. For at en nettverksingeniør skal "integreres i teamet" må han kunne snakke samme språk med både utviklere og kolleger innen administrasjon/devops. Hva betyr dette?

• Å kunne ikke bare bruke Linux som bruker, men også administrere det, minst på et nivå som junior systemadministrator: installere nødvendig programvare, starte opp igjen en tjeneste som har krasjet, skrive en enkel systemd-enhet.
• Å forstå (i det minste på et overordnet nivå) hvordan nettverksstakken i Linux fungerer, hvordan nettverket er bygd opp i hypervisorer og containere (lxc / docker / kubernetes).
• Selvfølgelig bør du kunne arbeide med ansible/chef/puppet eller et annet SCM-system.
• I tillegg må vi nevne SDN og nettverk for private skyer (for eksempel TungstenFabric eller OpenvSwitch). Dette er enda en stor del av kunnskap.

Kort sagt har jeg beskrevet en typisk T-formet spesialist (som det nå er moderne å si). Det virker ikke som noe nytt, men av erfaring fra intervjuer kan ikke alle nettverksingeniører skryte av kunnskaper om minst to emner fra listen ovenfor. I praksis gjør mangel på kunnskap "i tilknyttede områder" kommunikasjonen med kolleger mye vanskeligere, samt forståelse av kravene som virksomheten stiller til nettverket som den mest grunnleggende infrastrukturen i prosjektet. Uten denne forståelsen blir det vanskeligere å argumentere for sitt synspunkt og "selge" det til virksomheten.

På den annen side gir nettverksingeniørens vane med å "forstå hvordan systemet fungerer" dem en betydelig fordel over ulike "bredt spesialiserte eksperter" som vet om teknologier fra artikler på Habr/Medium og grupper på Telegram, men som ikke har noen klar ide om prinsippene som fungerer for ulike programvarer. Kunnskap om visse mønstre erstatter, som kjent, effektivt kunnskap om mange fakta.

Konklusjoner, eller bare TL;DR

1. Nettverksadministratoren (som DBA eller VoIP-ingeniør) er en spesialist med en relativt smal profil (i motsetning til systemadministratorer/devops/SRE), behovet for dem oppstår ikke alltid umiddelbart (og kan faktisk ta tid før det oppstår). Men når det først skjer, er det lite sannsynlig at man kan erstatte deres ekspertise med hjelp utenfra (outsourcing eller vanlige administratorer med bredere profil, "som også ser etter nettverket"). Det som er litt mer trist, er at behovet for slike spesialister er lite, og i en bedrift med 800 programmerere og 30 devops/adminer kan det være bare to nettverksingeniører som gjør jobben sin utmerket. Altså, markedet har vært og er fortsatt ganske lite, og for å få en god lønn — enda mindre.
2. På den annen side må en god nettverksingeniør i den moderne verden ikke bare vite om nettverk (og hvordan automatisere konfigurasjonen av dem), men også hvordan operativsystemer og programvare som kjører over disse nettverkene interagerer med dem. Uten dette vil det være ekstremt vanskelig å forstå hva kollegene dine ber om og på en begrunnet måte formidle dine ønsker/krav til dem.
3. Det finnes ingen sky, det er bare noen andres datamaskin. Man må forstå at bruken av offentlige/private skyer eller tjenester fra hosting-leverandører "som gjør alt for deg" fratar deg ikke ansvaret for at applikasjonen din fortsatt bruker nettverket, og problemer med det vil påvirke applikasjonens drift. Ditt valg er hvor kompetansesenteret som skal ha ansvar for nettverket til prosjektet ditt skal ligge.

Kilde: habr.com