{"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\/no\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Nettverksingeni\u00f8rer (er) n\u00f8dvendige","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u00e5 tidspunktet for denne artikkelen ga s\u00f8k p\u00e5 et popul\u00e6rt jobbnettsted etter frasen \u00abNettverksingeni\u00f8r\u00bb omtrent tre hundre stillinger i hele Russland. Til sammenligning gir s\u00f8k etter uttrykket \u00absystemadministrator\u00bb nesten 2,5 tusen stillinger, mens \u00abDevOps-ingeni\u00f8r\u00bb n\u00e6rmer seg 800.<\/p>\n

Betyr dette at nettverksfolk ikke lenger er n\u00f8dvendige i en tid med dominerende skyer, Docker, Kubernetes og allestedsn\u00e6rv\u00e6rende offentlig Wi-Fi?
\nLa oss unders\u00f8ke (c)<\/p>\n

\"Nettverksingeni\u00f8rer
\n<\/a><\/noindex>
\nLa oss bli kjent. Jeg heter Alexey, og jeg er nettverksingeni\u00f8r. <\/p>\n

Jeg har jobbet med nettverk i over 10 \u00e5r og har mer enn 15 \u00e5rs erfaring med ulike *nix-systemer (har hatt erfaring med b\u00e5de Linux og FreeBSD). Jeg har jobbet for telekommunikasjonsoperat\u00f8rer og store selskaper, som gjerne kalles \u00abenterprise\u00bb, og den siste tiden har jeg jobbet i en \u00abung og dristig\u00bb fintech, hvor skyer, DevOps, Kubernetes og andre skremmende ord kan gj\u00f8re meg og kollegene mine un\u00f8dvendige. En dag. Kanskje.<\/p>\n

ansvarsfraskrivelse: \u00abI livet v\u00e5rt er ikke alt alltid og overalt perfekt, men noen ganger og steder\u00bb (c) Maxim Dorofejev.<\/p>\n

Alt som er skrevet nedenfor, kan og skal betraktes som forfatterens personlige mening, som ikke gj\u00f8r krav p\u00e5 \u00e5 v\u00e6re den endelige sannheten, eller engang en fullverdig studie. Alle karakterer er fiktive, alle likheter er tilfeldige.<\/p><\/blockquote>\n

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

Hvor kan man egentlig m\u00f8te nettverksfolk?<\/h3>\n

\n1. Telekommunikasjonsoperat\u00f8rer, tjenesteselskaper og andre integratorer<\/b>. Her er alt enkelt: Nettverket er for dem en forretning. De selger enten direkte tilkobling (operat\u00f8rer), eller tilbyr tjenester for oppstart\/vedlikehold av nettverk for sine kunder. <\/p>\n

Her er det mye erfaring, men ikke s\u00e5 mye penger (med mindre du er direkt\u00f8r 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\u00f8r v\u00e6re, selv n\u00e5, 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\u00f8ringeni\u00f8r til C-level manager p\u00e5 f\u00e5 \u00e5r, er ogs\u00e5 helt reelle, selv om de er sjeldne, av \u00e5penbare grunner. Behovet for arbeidskraft finnes alltid, fordi det er en viss omsetning. Dette er b\u00e5de bra og d\u00e5rlig \u2014 det er alltid ledige stillinger, p\u00e5 den annen side \u2014 ofte forlater de mest aktive \/ kloke jobber raskt, enten for en forfremmelse eller for andre, mer \u00abbehagelige\u00bb steder.<\/p>\n

2. Betinget \u00abenterprise\u00bb<\/b>Uansett om hovedvirksomheten hans har noe med IT \u00e5 gj\u00f8re eller ikke. Det viktigste er at de har sin egen IT-avdeling som jobber med drift av interne systemer i selskapet, inkludert nettverket p\u00e5 kontorene, kommunikasjonslinjene til filialene og s\u00e5 videre. Rolle som nettverksingeni\u00f8r i slike selskaper kan administreres av en systemadministrator (hvis nettverksinfrastrukturen er liten, eller hvis en ekstern leverand\u00f8r h\u00e5ndterer det), mens nettverksingeni\u00f8ren, hvis han faktisk er til stede, ogs\u00e5 kan ta seg av telefonisystemet og SAN (fordi hvorfor ikke). L\u00f8nningene varierer \u2013 det avhenger sterkt av l\u00f8nnsomheten i forretningen, st\u00f8rrelsen p\u00e5 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\u00f8ppel, pinner og bl\u00e5-isolasjonsteip, og serverne aldri ble oppdatert (trenger jeg \u00e5 si at det heller ikke var gjort noen reserver?). Erfaringene her er betydelig mindre, og vil nesten sikkert v\u00e6re innen for hard vendor-lock, eller 'hvordan lage noe ut av ingenting'. Personlig syntes jeg det virket d\u00f8dskjedelig der, selv om mange liker det \u2013 alt skjer i et behagelig tempo og er forutsigbart (hvis vi snakker om store selskaper), 'dora-ka-bahato' og s\u00e5 videre. Ikke mindre enn en gang i \u00e5ret sier en stor leverand\u00f8r at de har utviklet en ny mega-super-duper-system som n\u00e5 automatiserer absolutt alt, og at alle systemadministratorer og nettverksingeni\u00f8rer kan avskjediges, bare etterlate noen f\u00e5 til \u00e5 trykke p\u00e5 knapper i et pent grensesnitt. Virkeligheten er at selv om man abstraherer fra kostnaden av l\u00f8sningen, vil ikke nettverksingeni\u00f8rer forsvinne derfra. Ja, kanskje det i stedet for konsollen igjen vil v\u00e6re 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\u00e6re n\u00f8dvendig.<\/p>\n

3. Produktbedrifter<\/b>, hvor inntektene kommer fra utviklingen (og ofte driften) av programvare eller plattformer \u2013 det produktet. Vanligvis er de sm\u00e5 og dynamiske, de er fortsatt langt fra st\u00f8rrelsen p\u00e5 store selskaper og deres byr\u00e5krati. Det er nettopp her at devops, kuber, docker og andre skumle ord finnes i stor skala, og de vil definitivt gj\u00f8re nettverket og nettverksingeni\u00f8rene til un\u00f8dvendige relikter. <\/p>\n

Hvordan skiller en nettverksingeni\u00f8r seg fra en systemadministrator?<\/h3>\n

\nI folks sin forstand som ikkje kjem fr\u00e5 IT \u2013 ingenting. Begge ser p\u00e5 den svarte skjermen og skriv nokre formularar, av og til mumlar dei stille. <\/p>\n

I programmeres forst\u00e5else \u2014 annet enn et emneomr\u00e5de. Systemadministratorer administrerer servere, nettverksfolk administrerer svitsjer og rutere. Noen ganger gj\u00f8r de det d\u00e5rlig, og alt kollapser. I tilfelle noe merkelig skjer, er nettverksfolk ogs\u00e5 skyldige. Bare fordi, fuck you, derfor.<\/p>\n

I verkelegheita er det viktigaste skillet tiln\u00e6rminga til arbeidet. Kanskje er det among nettverksfolk at tiln\u00e6rminga \u00abDet fungerer \u2013 ikkje r\u00f8r!\u00bb er mest utbreidd. Du kan som regel berre gjere ei oppg\u00e5ve (innan ein leverand\u00f8r) p\u00e5 \u00e9in m\u00e5te, og heile konfigureringa av boksen \u2013 den ligg rett der i handflata. Feilpris \u2013 h\u00f8g, og av og til er det veldig h\u00f8g (til d\u00f8mes, du m\u00e5 reise fleire hundre kilometer for \u00e5 omstarte rutaren, og i mellomtida vil fleire tusen menneske sitte utan forbindelse \u2013 heilt vanleg for ein teleoperat\u00f8r).<\/p>\n

Etter mi meining er det derfor nettverksingeni\u00f8rar, p\u00e5 den eine sida, sv\u00e6rt motivert for stabiliteten til nettverket (og endringar er hovudfienden til stabilitet), og p\u00e5 den andre sida, g\u00e5r kunnskapen deira meir i djupda enn i breidda (du m\u00e5 ikkje kunne konfigurere ti ulike demonar, du m\u00e5 vite teknologiane og deira implementering hos den spesifikke utstyrsprodusenten). Derfor er ikkje sysadminen som har googla korleis han kan konfigurere VLAN p\u00e5 Cisco, ein nettverksmann. Og han vil neppe kunne st\u00f8tte (og ogs\u00e5 feils\u00f8ke) eit meir eller mindre komplisert nettverk effektivt. <\/p>\n

Men kvifor treng du ein nettverksmann, n\u00e5r du har hoster<\/a>?<\/b><\/p>\n

For ein ekstra kostnad (og dersom du er ein veldig stor og elsket kunde \u2013 kanskje til og med gratis, \u00abfor vennskap\u00bb), vil datacenteringeni\u00f8rar konfigurere svitsjane dine etter dine behov, og kanskje til og med hjelpe deg med \u00e5 sette opp BGP-peering med leverand\u00f8rar (hvis du har ditt eige subnett IP-adresser<\/a> for annonsering).<\/p>\n

Det grunnleggende problemet er at datasenteret ikke er IT-avdelingen din, det er et eget selskap med m\u00e5l om \u00e5 tjene penger. Inkludert ved \u00e5 belaste deg som kunde. Datasenteret tilbyr racks, gir dem str\u00f8m og kj\u00f8ling, og gir ogs\u00e5 en viss \u00abstandard\u00bb tilkobling til internett. Basert p\u00e5 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 \u00e5 administrere kundenes infrastruktur, fordi denne prosessen er sv\u00e6rt tidkrevende, vanskelig \u00e5 automatisere (og i et normalt datasenter er alt som er mulig automatisert), enda vanskeligere \u00e5 standardisere (hver kunde er individuell), og generelt kan det f\u00f8re til klager (\u00abDu satte opp serveren min, og n\u00e5 har den krasjet, det er dere som har skylden!!!111\u00bb). Derfor, hvis vertskapet hjelper deg med noe, vil det pr\u00f8ve \u00e5 gj\u00f8re det s\u00e5 enkelt og \u00abstandard\u00bb som mulig. Det \u00e5 gj\u00f8re noe komplisert er ikke l\u00f8nnsomt, i hvert fall ikke n\u00e5r det gjelder ingeni\u00f8renes arbeidskraft i det samme vertskapet (men situasjoner kan variere, se forbehold). Det betyr ikke at vertskapet n\u00f8dvendigvis gj\u00f8r alt d\u00e5rlig. Men det er heller ikke sikkert at de gj\u00f8r nettopp det du egentlig hadde behov for.<\/p>\n

Det kan virke ganske \u00e5penbart, men jeg har flere ganger opplevd at selskaper begynte \u00e5 stole p\u00e5 hosting-leverand\u00f8ren sin litt mer enn de burde, noe som aldri endte godt. Jeg m\u00e5tte bruke mye tid p\u00e5 \u00e5 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\u00e5r 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 \u00e9n vertskap. I tilfelle problemer mellom dem, vil de absolutt ikke finne ut av hva som egentlig gikk galt for deg.<\/p>\n

Motivene er de samme som n\u00e5r man velger 'egen administrasjonsgruppe vs outsourcing'. Hvis risikoene er vurdert, kvaliteten er god, og bedriften er \u00e5pen for det \u2014 hvorfor ikke pr\u00f8ve? P\u00e5 den annen side er nettverket en av de mest grunnleggende lagene i infrastrukturen, og det er knapt verdt \u00e5 overlate det til eksterne folk, hvis alt annet allerede administreres internt.<\/p>\n

N\u00e5r trenger man en nettverksingeni\u00f8r?<\/b><\/p>\n

Her skal vi spesifikt snakke om moderne produktbaserte selskaper. N\u00e5r det gjelder operat\u00f8rer og enterprise, er situasjonen mer eller mindre klar \u2014 det har ikke v\u00e6rt mye forandring de siste \u00e5rene, og nettverksingeni\u00f8rer har alltid v\u00e6rt n\u00f8dvendige der. Men med de 'unge og dristige' er det ikke s\u00e5 entydig. De plasserer ofte hele infrastrukturen sin i skyen, s\u00e5 de trenger vanligvis ikke engang administratorer \u2014 bortsett fra administratorene for de aktuelle skyene, selvf\u00f8lgelig. Infrastrukturen er, p\u00e5 den ene siden, forholdsvis enkel infrastrukturmessig, men p\u00e5 den annen side er den godt automatisert (ansible\/puppet, terraform, ci\/cd\u2026 ja, du vet). Men selv her er det situasjoner hvor man ikke kan klare seg uten en nettverksingeni\u00f8r.<\/p>\n

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

La oss anta at et selskap starter med \u00e9n server med offentlig IP-adresse, plassert i et datasenter. S\u00e5 blir det to servere. S\u00e5 flere... R\u00e5tt eller sent, blir det n\u00f8dvendig med et privat nettverk mellom serverne. Fordi 'utenlandstrafikk' er begrenset b\u00e5de n\u00e5r det gjelder b\u00e5ndbredde (ikke mer enn 100Mbit\/s for eksempel) og mengden nedlastet\/opplastet per m\u00e5ned (forskjellige leverand\u00f8rer har forskjellige priser, men b\u00e5ndbredden til omverdenen er som regel mye dyrere enn det private nettverket).<\/p>\n

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!<\/p>\n

Antallet av servere \u00f8ker, trafikken i det private nettverket gj\u00f8r det ogs\u00e5 \u2014 backup, replikasjoner osv. Leverand\u00f8ren tilbyr \u00e5 flytte deg til separate svitsjer slik at du ikke forstyrrer andre kunder, og de ikke forstyrrer deg. Leverand\u00f8ren setter opp noen svitsjer og konfigurerer dem p\u00e5 en eller annen m\u00e5te \u2014 mest sannsynlig ved \u00e5 la alle serverne dine v\u00e6re p\u00e5 et flatt nettverk. Alt fungerer bra, men etter hvert oppst\u00e5r det problemer: periodisk \u00f8ker forsinkelsene mellom vertsene, i loggene er det klager p\u00e5 for mange arp-pakker per sekund, og en pentester fikk tilgang til hele ditt lokale nettverk under revisjonen, bare ved \u00e5 bryte en server.<\/p>\n

Hva m\u00e5 gj\u00f8res?<\/i><\/p>\n

\u00c5 dele nettverket i segmenter \u2014 VLAN. Konfigurere sin egen adressering i hvert VLAN, tildele en gateway som vil f\u00f8re trafikken mellom nettverkene. P\u00e5 gatewayen konfigurere ACL for \u00e5 begrense tilgang mellom segmentene, eller sette opp en egen brannmur ved siden av.<\/p>\n

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

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

Hva m\u00e5 gj\u00f8res?<\/i><\/p>\n

Koble serverne sammen med LAG (Link Aggregation Group) med to ledninger til svitsjene i skapet (de m\u00e5 ogs\u00e5 v\u00e6re reservert). S\u00f8rg for at tilkoblingene mellom skapene er reservert, endre dem til et 'stjernem\u00f8nster' (eller den moderne CLOS), slik at en enkelt skapfeil ikke p\u00e5virker de andre. Tildel 'sentrale' skap der det nettverkskjernen vil ligge, og der andre skap skal kobles til. Samtidig, s\u00f8rg for \u00e5 ordne den offentlige adresseringen, f\u00e5 en adresseblokk fra leverand\u00f8ren (eller fra RIR, hvis mulig) som selv kan annonseres til verden.<\/p>\n

Kan alt dette gj\u00f8res av en 'vanlig' systemadministrator uten dyp kunnskap om nettverk? Jeg er ikke sikker. Vil leverand\u00f8ren gj\u00f8re det? Kanskje de vil, men du m\u00e5 gi en ganske detaljert spesifikasjon, som ogs\u00e5 m\u00e5 skrives av noen. Og deretter m\u00e5 du kontrollere at alt er gjort riktig.<\/p>\n

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

La oss si at du har en VPC i en offentlig sky. For \u00e5 f\u00e5 tilgang fra kontoret eller den lokale delen av infrastrukturen til det lokale nettverket inne i VPC, m\u00e5 du sette opp en tilkobling via IPSec eller en dedikert linje. P\u00e5 den ene siden er IPSec billigere, siden du ikke trenger \u00e5 kj\u00f8pe 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\u00e5r via vanlig internett). <\/p>\n

Hva m\u00e5 gj\u00f8res?<\/i><\/p>\n

Sett opp tilkobling via dedikert linje (for eksempel kalles dette Direct Connect hos AWS). For dette m\u00e5 du finne en partneroperat\u00f8r som kan koble deg til, bestemme den n\u00e6rmeste tilkoblingspunktet (b\u00e5de fra deg til operat\u00f8ren og fra operat\u00f8ren til skyen), og til slutt sette opp alt. Kan dette gj\u00f8res uten nettverksingeni\u00f8r? Sannsynligvis ja. Men hvordan l\u00f8ser man problemer uten en? Det er ikke s\u00e5 klart. <\/p>\n

Det kan ogs\u00e5 oppst\u00e5 problemer med tilgjengeligheten mellom skyer (hvis du har multicloud) eller problemer med forsinkelser mellom forskjellige regioner osv. Uten tvil har det n\u00e5 kommet mange verkt\u00f8y som \u00f8ker gjennomsiktigheten i hva som skjer i skyen (som Thousand Eyes), men det er alle verkt\u00f8y for nettverksingeni\u00f8rer og ikke en erstatning for dem.<\/p>\n

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\u00e5 av infrastrukturutvikling, m\u00e5 det v\u00e6re en person (og helst flere) som vet hvordan nettverket fungerer, kan sette opp nettverksutstyr og h\u00e5ndtere problemer hvis de oppst\u00e5r. Tro meg, han vil ha mer enn nok \u00e5 gj\u00f8re. <\/p>\n

Hva b\u00f8r en nettverksingeni\u00f8r vite?<\/b><\/p>\n

Det er ikke n\u00f8dvendig (og til og med noen ganger skadelig) for en nettverksingeni\u00f8r \u00e5 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\u00e6rt), og tar for eksempel on premise eller private skyer, der kun \"kunnskap p\u00e5 CCNP-niv\u00e5\" ikke vil v\u00e6re tilstrekkelig. <\/p>\n

Utover selve nettverkene \u2014 selv om dette er et uendelig felt for studier, selv om man bare konsentrerer seg om ett enkelt omr\u00e5de (leverand\u00f8rnettverk, bedrifter, datasentre, Wi-Fi...)<\/p>\n

Selvf\u00f8lgelig vil mange av dere n\u00e5 tenke p\u00e5 Python og annen \"nettverksautomatisering\", men dette er bare et n\u00f8dvendig, men ikke tilstrekkelig vilk\u00e5r. For at en nettverksingeni\u00f8r skal \"integreres i teamet\" m\u00e5 han kunne snakke samme spr\u00e5k med b\u00e5de utviklere og kolleger innen administrasjon\/devops. Hva betyr dette?<\/p>\n