{"id":97373,"date":"2020-10-17T14:42:32","date_gmt":"2020-10-17T12:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/seteviki-ne-nuzhny"},"modified":"2020-10-17T14:42:32","modified_gmt":"2020-10-17T12:42:32","slug":"seteviki-ne-nuzhny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Netv\u00e6rkere (er) ikke n\u00f8dvendige","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u00e5 tidspunktet for denne artikels skrivning gav en s\u00f8gning p\u00e5 en popul\u00e6r jobs\u00f8gningsside med de s\u00f8geord \"Netv\u00e6rksingeni\u00f8r\" omkring tre hundrede jobopslag i hele Rusland. Til sammenligning giver en s\u00f8gning p\u00e5 frasen \"systemadministrator\" n\u00e6sten 2,5 tusinde jobopslag, mens \"DevOps-ingeni\u00f8r\" n\u00e6sten giver 800.<\/p>\n

Betyr det, at netv\u00e6rkere ikke l\u00e6ngere er n\u00f8dvendige i en tid med dominerende cloud-teknologier, Docker, Kubernetes og alomfattende offentlig Wi-Fi?
\nLad os dykke ind (c)<\/p>\n

\"Netv\u00e6rkere
\n<\/a><\/noindex>
\nLad os l\u00e6re hinanden at kende. Mit navn er Alexey, og jeg er netv\u00e6rker. <\/p>\n

Jeg har arbejdet med netv\u00e6rk i over 10 \u00e5r og har over 15 \u00e5rs erfaring med forskellige *nix-systemer (jeg har haft mulighed for at arbejde med b\u00e5de Linux og FreeBSD). Jeg har arbejdet hos telekommunikationsoperat\u00f8rer, i store virksomheder, der betragtes som \"enterprise\", og for tiden arbejder jeg i en \"ung og dristig\" fintech, hvor cloud-l\u00f8sninger, DevOps, Kubernetes og andre skr\u00e6mmende ord, der helt sikkert vil g\u00f8re mig og mine kolleger overfl\u00f8dige. Engang. M\u00e5ske.<\/p>\n

disclaimer: \"I vores liv er ikke alt, altid og overalt, og nogle ting, nogle gange og nogle steder\" (c) Maxim Dorofeev.<\/p>\n

Alt det f\u00f8lgende kan og b\u00f8r betragtes som forfatterens personlige mening, der ikke g\u00f8r krav p\u00e5 at v\u00e6re den endegyldige sandhed, og ikke engang som en fuldgyldig unders\u00f8gelse. Alle karakterer er fiktive, alle ligheder er tilf\u00e6ldige.<\/p><\/blockquote>\n

Velkommen til min verden.<\/p>\n

Hvor kan man egentlig m\u00f8de netv\u00e6rkere?<\/h3>\n

\n1. Telekommunikationsoperat\u00f8rer, servicevirksomheder og andre integratorer<\/b>. Her er det enkelt: netv\u00e6rk er for dem en forretning. De s\u00e6lger enten direkte forbindelsen (operat\u00f8rer) eller tilbyder tjenester til opstart\/vedligeholdelse af deres kunders netv\u00e6rk. <\/p>\n

Der er meget erfaring her, men ikke s\u00e6rlig mange penge (medmindre du er direkt\u00f8r eller en succesfuld salgsleder). Alligevel, hvis du kan lide netv\u00e6rk, og du er kun i starten af din karriere, vil en karriere i supporten hos en mindre operat\u00f8r faktisk v\u00e6re en ideel startpunkt (i de store virksomheder er alt meget skemalagt, og der er lidt plads til kreativitet). Og historierne om, at man kan rykke fra at v\u00e6re en weekendingeni\u00f8r til C-level manager p\u00e5 f\u00e5 \u00e5r, er ogs\u00e5 reelle, selvom de er sj\u00e6ldne af \u00e5benlyse grunde. Behovet for medarbejdere er altid til stede, fordi personaleoms\u00e6tningen faktisk sker. Det er b\u00e5de godt og skidt p\u00e5 samme tid \u2014 der er altid ledige stillinger, men ofte forsvinder de mest aktive\/kloge forholdsvis hurtigt til h\u00f8jere stillinger eller til andre, mere 'behagelige' steder.<\/p>\n

2. Betinget 'enterprise'<\/b>. Uanset om virksomhedens prim\u00e6re aktivitet er relateret til IT eller ej, er den vigtigste ting, at den har en IT-afdeling, der h\u00e5ndterer driften af virksomhedens interne systemer, herunder netv\u00e6rket p\u00e5 kontorerne, kommunikationskanaler til filialer osv. Funktionen som netv\u00e6rkstekniker i s\u00e5danne virksomheder kan 'fungerende' udf\u00f8res af en systemadministrator (hvis netv\u00e6rksinfrastrukturen er lille, eller det h\u00e5ndteres af en ekstern leverand\u00f8r), mens netv\u00e6rksteknikeren, hvis han findes, ogs\u00e5 kan tage sig af telefoni og SAN (bare lige for at n\u00e6vne det). L\u00f8nningerne varierer - det afh\u00e6nger i h\u00f8j grad af virksomhedens margin, st\u00f8rrelse og struktur. Jeg har arbejdet med virksomheder, hvor Cisco var overrendt, og virksomheder hvor netv\u00e6rket var bygget af affald, pinde og bl\u00e5 isoleringstejp, og hvor serverne sj\u00e6ldent blev opdateret (skal jeg n\u00e6vne, at der heller ikke var nogen reserver?). Erfaringen her er betydeligt mindre, og den vil n\u00e6sten helt sikkert v\u00e6re pr\u00e6get af stram vendor-lock, eller 'hvordan man f\u00e5r noget ud af ingenting'. Personligt fandt jeg det ekstremt kedeligt, selvom mange kan lide det - alt er ret roligt og forudsigeligt (hvis vi taler om store virksomheder), 'do-re mis-myndigt', osv. Mindst en gang om \u00e5ret siger en stor leverand\u00f8r, at de har opfundet et nyt mega-super-duper-system, der automatisk h\u00e5ndterer alt, s\u00e5 alle systemadministratorer og netv\u00e6rksteknikere kan fyres, og kun et par kan blive tilbage til at klikke p\u00e5 knapperne i et flot interface. Virkeligheden er dog, at selvom man abstraherer fra omkostningerne ved l\u00f8sningen, s\u00e5 vil netv\u00e6rksteknikerne ikke forsvinde. Ja, m\u00e5ske vil der i stedet v\u00e6re et webinterface (men ikke l\u00e6ngere for et bestemt stykke hardware, men for et stort system, der styrer dusinvis og hundreder af s\u00e5danne enheder), men man vil stadig have brug for viden om 'hvordan alt indeni er opbygget'.<\/p>\n

3. Produktvirksomheder<\/b>, hvis indt\u00e6gt kommer fra udvikling (og ofte drift) af et eller andet software eller platform - netop det produkt. Normalt er de sm\u00e5 og agile, de er langt fra at have st\u00f8rrelsen og bureaukratiet i store virksomheder. Det er her, de s\u00e5kaldte DevOps, Kubernetes, Docker og andre skr\u00e6mmende ord er massivt til stede, og som i h\u00f8j grad vil g\u00f8re netv\u00e6rket og netv\u00e6rksteknikere til en un\u00f8dvendig relikt. <\/p>\n

Hvordan adskiller en netv\u00e6rkstekniker sig fra en systemadministrator?<\/h3>\n

\nI folks uden IT-forst\u00e5else ser det som intet. B\u00e5de den ene og den anden kigger ind i en sort sk\u00e6rm og skriver nogle formularer, nogle gange mumlende bandeord. <\/p>\n

I programmeres forst\u00e5else er det kun et sp\u00f8rgsm\u00e5l om dom\u00e6net. Systemadministratoren administrerer servere, netv\u00e6rksfolkene administrerer switche og routere. Nogle gange g\u00e5r det galt, og hele systemet falder. I tilf\u00e6lde af m\u00e6rkelige problemer er netv\u00e6rksfolkene ogs\u00e5 skyldige. Bare fordi, fuck dig, det er derfor.<\/p>\n

I virkeligheden er den vigtigste forskel tilgang til arbejdet. M\u00e5ske er det blandt netv\u00e6rksteknikerne, at tilgangen \"Den virker \u2014 lad v\u00e6re med at r\u00f8re ved den!\" er mest udbredt. At g\u00f8re en given opgave (inden for \u00e9n leverand\u00f8r) kan som regel kun g\u00f8res p\u00e5 \u00e9n m\u00e5de, hele konfigurationen af apparatet \u2014 den ligger lige foran dig. Fejlen koster meget, og nogle gange rigtig meget (for eksempel at man skal k\u00f8re flere hundrede kilometer for at genstarte routeren, mens flere tusinde mennesker sidder uden forbindelse \u2014 en helt almindelig situation for en teleserviceudbyder).<\/p>\n

Jeg mener, det er grunden til, at netv\u00e6rksteknikere p\u00e5 den ene side er ekstremt motiverede for netv\u00e6rksstabilitet (og \u00e6ndringer er den st\u00f8rste fjende af stabilitet), og p\u00e5 den anden side deres viden g\u00e5r dybere snarere end bredere (man beh\u00f8ver ikke vide, hvordan man konfigurerer dusinvis af forskellige d\u00e6moner, man skal kende teknologierne og deres implementering hos den specifikke hardwareleverand\u00f8r). Derfor er en systemadministrator, der har googlet, hvordan man konfigurerer VLAN p\u00e5 en Cisco \u2014 stadig ikke en netv\u00e6rkstekniker. Og det er tvivlsomt, at han effektivt kan vedligeholde (og fejls\u00f8ge) et mere eller mindre komplekst netv\u00e6rk. <\/p>\n

Men hvorfor er en netv\u00e6rkstekniker n\u00f8dvendig, hvis du har en hoster<\/a>?<\/b><\/p>\n

For ekstra penge (og hvis du er en meget stor og v\u00e6rdsat kunde \u2014 m\u00e5ske endda gratis, 'for venskabets skyld') vil datacenteringeni\u00f8rer konfigurere dine switches efter dine behov, og m\u00e5ske endda hj\u00e6lpe med at etablere BGP-forbindelsen med udbydere (hvis du har dit eget subnet ip-adresser<\/a> til annoncering).<\/p>\n

Det prim\u00e6re problem er, at datacentret ikke er din IT-afdeling; det er en separat virksomhed, hvis m\u00e5l er at opn\u00e5 profit. Inklusive fra dig som klient. Datacentret leverer racks, sikrer elektricitet og k\u00f8ling, samt giver en vis \"default\" forbindelse til internettet. Baseret p\u00e5 denne infrastruktur kan datacentret placere dit udstyr (colocation), leje en server til dig (dedicated server) eller tilbyde managed services (f.eks. OpenStack eller K8s). Men datacentrets forretning (normalt) omfatter ikke administration af kunders infrastruktur, fordi denne proces er ret arbejdskr\u00e6vende, d\u00e5rligt automatiseret (og i et ordentligt datacenter er alt, hvad der kan automatiseres, automatiseret), endnu sv\u00e6rere at standardisere (hver kunde er unik) og i det hele taget kan f\u00f8re til krav (\"I satte mig en server op, men nu er den g\u00e5et ned, det er jeres skyld!!!111\"). Derfor, hvis hoster vil hj\u00e6lpe dig med noget, vil de fors\u00f8ge at g\u00f8re det s\u00e5 simpelt og \"standardiseret\" som muligt. At g\u00f8re det kompliceret er nemlig ikke \u00f8konomisk fordelagtigt, i det mindste set fra ingeni\u00f8rernes arbejdsbyrde i den p\u00e5g\u00e6ldende hoster (men situationer kan variere, se disclaimer). Det betyder ikke, at hosteren n\u00f8dvendigvis vil g\u00f8re alt d\u00e5rligt. Men det er slet ikke sikkert, at de vil g\u00f8re pr\u00e6cis det, du har brug for.<\/p>\n

Det virker m\u00e5ske indlysende, men jeg har flere gange oplevet i min praksis, at virksomheder begyndte at stole p\u00e5 deres hostingudbyder lidt mere, end de burde, og det f\u00f8rte ikke til noget godt. Jeg m\u00e5tte i lang tid forklare, at ingen SLA d\u00e6kker tab fra nedetid (der er undtagelser, men normalt er det meget, MEGET dyrt for klienten), og at hosteren slet ikke er informeret om, hvad der sker i kundernes infrastruktur (bortset fra meget generelle oplysninger). Og hosteren laver heller ikke backups for dig. Det bliver endnu v\u00e6rre, hvis du har mere end \u00e9n hoster. I tilf\u00e6lde af problemer mellem dem vil de bestemt ikke finde ud af, hvad der gik galt for dig.<\/p>\n

Motiverne her er pr\u00e6cis de samme som ved valget mellem \"eget adminteam vs outsourcing\". Hvis risiciene er vurderet, kvaliteten er tilfredsstillende, og virksomheden er \u00e5ben for det \u2014 hvorfor ikke give det et fors\u00f8g? P\u00e5 den anden side er netv\u00e6rket et af de mest grundl\u00e6ggende lag i infrastrukturen, og det vil n\u00e6ppe v\u00e6re klogt at overlade det til eksterne folk, n\u00e5r alt andet allerede st\u00f8ttes af jer selv.<\/p>\n

Hvorn\u00e5r har man brug for en netv\u00e6rkstekniker?<\/b><\/p>\n

I det f\u00f8lgende vil vi fokusere p\u00e5 moderne produktbaserede virksomheder. Med operat\u00f8rer og enterprise-sektoren er det mere eller mindre klart \u2014 der har ikke v\u00e6ret mange \u00e6ndringer de seneste \u00e5r, og netv\u00e6rksteknikere har altid v\u00e6ret n\u00f8dvendige. Men med de \"unge og dristige\" er tingene ikke s\u00e5 entydige. Oftest placerer de hele deres infrastruktur i skyen, s\u00e5 de har ikke rigtig brug for administratorer \u2014 bortset fra administratorerne af selve skyen, selvf\u00f8lgelig. Infrastrukturen er, p\u00e5 den ene side, relativt simpel i sin opbygning, men p\u00e5 den anden side godt automatiseret (ansible\/puppet, terraform, ci\/cd... ja, I kender det). Men selv her er der situationer, hvor man ikke kan undv\u00e6re en netv\u00e6rkstekniker.<\/p>\n

Eksempel 1, klassisk<\/b><\/p>\n

Antag, at virksomheden starter med \u00e9n server med en offentlig IP-adresse, som st\u00e5r i datacenteret. S\u00e5 kommer der en server mere. S\u00e5 flere... Rigtigt eller forkert, der opst\u00e5r et behov for et privat netv\u00e6rk mellem serverne. Fordi \"ekstern\" trafik er begr\u00e6nset b\u00e5de i b\u00e5ndbredde (h\u00f8jst 100 Mbit\/s for eksempel) og i den m\u00e6ngde data, der downloades\/overf\u00f8res per m\u00e5ned (forskellige udbydere har forskellige takster, men b\u00e5ndbredden til den eksterne verden er generelt dyrere end et privat netv\u00e6rk).<\/p>\n

Udbyderen tilf\u00f8jer ekstra netv\u00e6rkskort til serverne og tilslutter dem til deres switches i et separat VLAN. Der opst\u00e5r en \"flad\" lokalnetv\u00e6rk mellem serverne. Det er praktisk!<\/p>\n

Antallet af servere vokser, og trafikken i det private netv\u00e6rk stiger ogs\u00e5 \u2014 backups, replikationer osv. Hostingudbyderen tilbyder at adskille jer i separate switche, s\u00e5 I ikke forstyrrer hinanden. Hostingudbyderen installererer nogle switche og konfigurerer dem p\u00e5 en eller anden m\u00e5de \u2014 sandsynligvis med \u00e9n flad netv\u00e6rk imellem alle jeres servere. Alt fungerer godt, men p\u00e5 et tidspunkt opst\u00e5r der problemer: der opst\u00e5r periodiske forsinkelser mellem v\u00e6rterne, der er klager i logfilerne over for mange arp-pakker pr. sekund, og en pentester fik adgang til hele jeres lokale netv\u00e6rk under en audit ved kun at kompromittere \u00e9n server.<\/p>\n

Hvad skal der g\u00f8res?<\/i><\/p>\n

Opdel netv\u00e6rket i segmenter - VLAN'er. Konfigurer hver VLAN med sin egen adressering, tildel en gateway, der videresender trafik mellem netv\u00e6rkene. P\u00e5 gatewayen skal du konfigurere ACL for at begr\u00e6nse adgangen mellem segmenterne, eller du kan v\u00e6lge at placere en separat firewall ved siden af.<\/p>\n

Eksempel 1, fortsat<\/b><\/p>\n

Serverne er forbundet til det lokale netv\u00e6rk med et enkelt kabel. Switche i rackene er p\u00e5 en eller anden m\u00e5de forbundet til hinanden, men ved en fejl i et rack falder yderligere tre n\u00e6rliggende fra. Der findes diagrammer, men deres aktualitet er tvivlsom. Hver server har sin egen offentlige adresse, som udleveres af hostingudbyderen og er knyttet til racken. Det vil sige, at adressen skal \u00e6ndres, n\u00e5r serveren flyttes.<\/p>\n

Hvad skal der g\u00f8res?<\/i><\/p>\n

Forbind serverne med LAG (Link Aggregation Group) med to kabler til switche i rackene (disse skal ogs\u00e5 v\u00e6re redundant). Forbindelserne mellem rackene skal v\u00e6re redundant og g\u00f8res til en \"stjerne\" (eller den aktuelle CLOS), s\u00e5 uheld i \u00e9t rack ikke p\u00e5virker de andre. Dediker \"centrale\" racks, som vil rumme det netv\u00e6rksm\u00e6ssige kerne og tilkobles andre racks. Samtidig bringe den offentlige adressering i orden, tage et subnet fra hostingudbyderen (eller fra RIR, hvis muligt), som selvst\u00e6ndigt (eller gennem hostingudbyderen) kan annonceres til verden.<\/p>\n

Kan alt dette g\u00f8res af en \"almindelig\" systemadministrator uden dybe netv\u00e6rkskendskaber? Ikke sikker. Vil hostingudbyderen g\u00f8re det? M\u00e5ske, men der kr\u00e6ves en ret detaljeret specifikation fra jer, som ogs\u00e5 skal skrives af nogen. Og derefter skal det kontrolleres, at alt er gjort korrekt.<\/p>\n

Eksempel 2. Cloud<\/b><\/p>\n

Lad os sige, at du har et VPC i en offentlig cloud. For at f\u00e5 adgang fra kontoret eller on-prem-delen af infrastrukturen til det lokale netv\u00e6rk inden for VPC, skal du konfigurere en forbindelse via IPSec eller en dedikeret linje. P\u00e5 den ene side er IPSec billigere, da du ikke beh\u00f8ver at k\u00f8be ekstra hardware; du kan konfigurere en tunnel mellem din server med offentlig adresse og cloud\u2019en. Men \u2013 der er forsinkelser, begr\u00e6nsede ydelser (da linjen skal krypteres), plus en ikke-garanteret forbindelsesmulighed (da adgangen sker via almindeligt internet). <\/p>\n

Hvad skal der g\u00f8res?<\/i><\/p>\n

Opret forbindelse via en dedikeret linje (for eksempel kaldes det hos AWS Direct Connect). For at g\u00f8re dette skal du finde en partneroperat\u00f8r, der kan forbinde dig, bestemme den n\u00e6rmeste tilslutningspunkt (b\u00e5de for dig til operat\u00f8ren og operat\u00f8ren til cloud\u2019en), og endelig konfigurere alt. Kan dette g\u00f8res uden en netv\u00e6rksingeni\u00f8r? Sikkert ja. Men hvordan man fejls\u00f8ger det uden ham i tilf\u00e6lde af problemer - det er ikke s\u00e5 klart. <\/p>\n

Der kan ogs\u00e5 opst\u00e5 problemer med tilg\u00e6ngeligheden mellem clouds (hvis du har multi-cloud) eller problemer med forsinkelser mellem forskellige regioner osv. Uden tvivl er der kommet mange v\u00e6rkt\u00f8jer, der \u00f8ger gennemsigtigheden af, hvad der sker i cloud\u2019en (det samme Thousand Eyes), men det er alle v\u00e6rkt\u00f8jer til netv\u00e6rksingeni\u00f8ren, ikke hans erstatning.<\/p>\n

Jeg kunne finde p\u00e5 ti s\u00e5danne eksempler fra min praksis, men jeg tror, det er klart, at i et team, n\u00e5r infrastrukturen n\u00e5r et bestemt udviklingsniveau, skal der v\u00e6re en person (eller helst flere), der ved, hvordan netv\u00e6rket fungerer, kan konfigurere netv\u00e6rksudstyr og h\u00e5ndtere problemer, hvis de opst\u00e5r. Tro mig, han vil have nok at lave. <\/p>\n

Hvad skal en netv\u00e6rksingeni\u00f8r vide?<\/b><\/p>\n

Det er slet ikke n\u00f8dvendigt (og endda, nogle gange, skadelig), for en netv\u00e6rksingeni\u00f8r kun at besk\u00e6ftige sig med netv\u00e6rket og intet andet. Selv hvis man ikke betragter scenariet med en infrastruktur, der n\u00e6sten udelukkende lever i en offentlig cloud (som uundg\u00e5eligt bliver mere og mere popul\u00e6r), og tager for eksempel on premise eller private clouds, hvor alene 'viden p\u00e5 CCNP-niveau' ikke er tilstr\u00e6kkelig. <\/p>\n

Udover selve netv\u00e6rkene - selvom der her er et uendeligt felt til udforskning, selvom man kun fokuserer p\u00e5 et enkelt omr\u00e5de (provider-netv\u00e6rk, enterprise, datacentre, WiFi ...)<\/p>\n

Selvf\u00f8lgelig vil mange af jer nu t\u00e6nke p\u00e5 Python og anden \"netv\u00e6rksautomatisering\", men det er kun en n\u00f8dvendig, men ikke tilstr\u00e6kkelig betingelse. For at en netv\u00e6rksingeni\u00f8r kan \"integrere sig vellykket i teams\", skal han kunne kommunikere med b\u00e5de udviklere og kollegaer som administratorer\/devops. Hvad betyder det?<\/p>\n