Minst én gang i løpet av en tung nettverkskonfigurasjon eller feilsøkingsøkt, får noen tilskuere et quizzical look og sier noe om effekten av "Gee, det virker veldig komplisert. Er det ikke en enklere måte?"
Oftere enn ikke, dette skjer mens jeg er kne dypt i en haug med ssh- eller telnet-økter til forskjellige rutere, brytere eller brannmurer, og holder noen titalls variabler i hodet. "Nei," svarer jeg, "det er det ikke."
[Også på .com: Les Paul Venezias øyeblikkelige klassiker, "Ni trekk fra veteran Unix-admin." | Så hvis du tør, bli med i debatten om omstart av Unix-baserte systemer. ]
Du kan tro at vi på dette tidspunktet ville ha magiske GUI-grensesnitt og veiviserdrevne konfigurasjonselementer som ville la enhver tilfeldig person riktig konfigurere OSPF-tunneling gjennom GRE, EIGRP-omfordeling og BGP-peering. Jeg mener, de har eksistert i evigheter - burde de ikke være mye enklere å administrere nå? Svaret er åpenbart for nettverksadministratorer: Hvis hvert nettverk var identisk, så ville det vært greit. Virkeligheten tilsier noe annet.
Kraften til disse protokollene og verktøyene ligger i deres omfang og bruksområde. Du kan gjøre ting med Cisco IOS som til og med folk fra Cisco aldri virkelig vurderte; på konfigurasjonsnivå er IOS et programmeringsspråk, ikke bare en bytte- eller ruteplattform. Årsaken til at Linux-kjernen er skrevet i C, ikke et VPL (visuelt programmeringsspråk), er den samme grunnen til at det ikke er en brukbar GUI for stamme til streng for tung ruting og byttekonfigurasjoner. Visst, det er SNMP-baserte verktøy som gjør det enkelt å bytte VLAN-tildelingen til en switchport eller legge til oversettelser og regler til en brannmur, men de kan bare gå så langt. Uunngåelig løper de opp mot veggen til det de har blitt bygget for å håndtere versus det som faktisk er mulig via det underliggende operativsystemet.
Det er ikke bare nye konfigurasjoner som går utover hva disse verktøyene kan takle; feilsøking og feilsøking av etablerte nettverk har en tendens til å kreve enda mer forståelse og dyktighet. Det er ikke noe som heter Clippy for tunge ruteproblemer eller til og med for enkle problemer som en feilkonfigurert lenke i en LACP-pakke. Kort sagt, det er ikke noe sikkerhetsnett for nettverkskonfigurasjoner. Det er ingen praktisk IDE som på en eller annen måte vil vite at du har transponert to tall i en OSPF-nettverkserklæring, noe som forårsaker rutingsprotokollfeil på et eksternt sted.
Ingenting av dette er nyheter for nettverksadministratorer, men det er sjokkerende for uinnvidde. Av en eller annen grunn tror mange at konfigurering av en 9-sporers kjernebryter eller konstruering av et MPLS-nettverk fungerer på samme måte som å konfigurere deres Netgear-hjemmeroters Wi-Fi-parametere. I noen tilfeller har jeg til og med hørt bråk om at nettverksadministratorer "får det til å virke vanskeligere enn det er" for å sikre jobbsikkerhet. Selv om jeg er sikker på at det har skjedd fra tid til annen, kan jeg forsikre deg om at de aller fleste nettverksadministratorer som arbeider gjennom enorme pakkespor for å finne ut hvorfor trafikk på en WAN-kobling av og til forsvinner, eller hvorfor bestemte delnett ikke blir dirigert riktig gjennom en mesh VPN-konfigurasjon for eksternt nettsted overvurderer ikke problemet bare for å øke statusen.
Selv utover konfigurasjonsgrensesnittet og kompleksiteten (men likevel nødvendigheten) av konfigurasjonselementer som samme sikkerhet-trafikk tillater intra-interface er det faktum at det å bruke disse verktøyene krever en grundig forståelse av hvordan de fungerer, noe som resulterer fra en livslang læringsprosess. Og i motsetning til mange andre IT-oppgaver, er det ingen angre-knapp når du utilsiktet avskjærer tilgangen til et eksternt nettsted og ikke kan komme tilbake til den eksterne enheten for å løse problemet.
Ja, nettverksadministrasjon er vanskelig. Det er muligens det mest utfordrende aspektet i moderne IT. Det er bare slik det må være - i det minste til noen utvikler nettverksenheter som kan lese tankene.
Denne historien, "Hvorfor nettverksadministrasjonen blåser så hardt," ble opprinnelig publisert på .com. Les mer av Paul Venezias The Deep End-blogg på .com. For de siste nyhetene om forretningsteknologi, følg .com på Twitter.
