Op it momint fan it skriuwen fan dit artikel, in syktocht op in populêre baan site foar de útdrukking "Netwurk Engineer" joech sa'n trijehûndert fakatueres yn hiel Ruslân. Foar fergeliking, syktocht nei de útdrukking "systeembehearder" jout hast 2.5 tûzen fakatueres, en "DevOps yngenieur" - hast 800.
Betsjut dit dat netwurkers net mear nedich binne yn tiden fan oerwinnende wolken, Docker, Kubernetes en ubiquitous iepenbiere Wi-Fi?
Litte wy it útfine (c)
Lit ús yn 'e kunde komme. Myn namme is Alexey, en ik bin in netwurker.
Ik bin mear dan 10 jier belutsen by netwurken en haw mear dan 15 jier mei ferskate *nix-systemen wurke (ik hie in kâns om te tinken mei sawol Linux as FreeBSD). Ik wurke yn telekomoperators, grutte bedriuwen dy't beskôge wurde as "bedriuw", en koartlyn haw ik wurke yn "jong en dappere" fintech, wêr't wolken, devops, kubernetes en oare enge wurden dy't my en myn kollega's perfoarst net nedich meitsje . Guon dei. Miskien.
disclaimer: "Yn ús libben is net alles altyd en oeral, mar wat, soms op plakken" (c) Maxim Dorofeev.
Alles dat hjirûnder skreaun is kin en moat wurde beskôge as de persoanlike miening fan 'e auteur, dy't net beweart dat it de ultime wierheid is, of sels in folsleine stúdzje. Alle personaazjes binne fiktyf, alle tafallichheden binne willekeurich.
Wolkom yn myn wrâld.
Wêr kinne jo sels netwurkers moetsje?
1. Telecom operators, tsjinst bedriuwen en oare integrators. Alles is hjir ienfâldich: it netwurk foar har is in bedriuw. Se ferkeapje of direkt ferbining (operators) of leverje tsjinsten foar it lansearjen / ûnderhâlden fan 'e netwurken fan har klanten.
D'r is hjir in protte ûnderfining, mar net folle jild (útsein as jo in direkteur of in suksesfolle ferkeapmanager binne). En dochs, as jo fan netwurken hâlde, en jo binne krekt oan it begjin fan jo reis, in karriêre foar stipe fan guon net heul grutte operators sil, sels no, in ideaal begjinpunt wêze (yn federale is alles heul skreaun, en d'r is in bytsje romte foar kreativiteit). No, ferhalen oer hoe't jo kinne groeie fan in yngenieur yn tsjinst yn in pear jier nei in C-nivo manager binne ek frij echt, hoewol seldsum, om foar de hân lizzende redenen. Der is altyd ferlet fan personiel, want der komt wol omset. Dit is sawol goed as min tagelyk - d'r binne altyd fakatueres, oan 'e oare kant - faak ferlitte de meast aktive/tûken gau foar promoasje of nei oare, "waarmere" plakken.
2. Betingst "bedriuw". It makket net út oft syn haadaktiviteit relatearre is oan IT of net. It wichtichste is dat it in eigen IT-ôfdieling hat, dy't de wurking fan 'e ynterne systemen fan it bedriuw soarget, ynklusyf it netwurk yn kantoaren, kommunikaasjekanalen nei filialen, ensfh. De funksjes fan in netwurkingenieur yn sokke bedriuwen kinne "dieltiid" wurde útfierd troch in systeembehearder (as de netwurkynfrastruktuer lyts is of wurdt behannele troch in eksterne oannimmer), en in netwurkspesjalist, as d'r ien is, kin by de deselde tiid sjoch nei telefony en SAN (gjin goed). Se betelje oars - it hinget sterk ôf fan 'e profitabiliteit fan it bedriuw, de grutte fan it bedriuw en de struktuer. Ik wurke mei bedriuwen dêr't de Cisco systemen waarden geregeldwei "laden yn barrels", en mei bedriuwen dêr't it netwurk waard boud út feces, stokken en blauwe tape, en de tsjinners waarden nea bywurke (nedich te sizzen, gjin reserves waarden ek levere). D'r is hjir folle minder ûnderfining, en it sil hast wis wêze op it mêd fan strikte ferkeaperslot, of "hoe kinne jo wat fan neat meitsje." Persoanlik fûn ik it wyld saai, hoewol in protte minsken it leuk fine - alles is frij mjitten en foarsisber (as wy it oer grutte bedriuwen hawwe), "dorakha-bahato", ensfh. Op syn minst ien kear yn 't jier seit guon grutte ferkeaper dat se mei in oar mega-super-duper-systeem binne kommen dat alles no sil automatisearje en alle systeembehearders en netwurkers kinne wurde ferspraat, wêrtroch't in pear knoppen litte yn in prachtige ynterface. De realiteit is dat, sels as wy de kosten fan 'e oplossing negearje, netwurkers dêr net oeral hinne sille. Ja, miskien sil d'r ynstee fan 'e konsole wer in webynterface wêze (mar net in spesifyk stik hardware, mar in grut systeem dat tsientallen en hûnderten sokke stikken hardware beheart), mar kennis fan "hoe't alles binnen wurket" sil noch altyd nedich wêze.
3. Produkt bedriuwen, wêrfan de winst komt fan 'e ûntwikkeling (en, faaks, operaasje) fan guon software of platfoarm - datselde produkt. Meastentiids binne se lyts en flink, se binne noch fier fan 'e skaal fan bedriuwen en har burokratisaasje. It is hjir dat deselde devops, cubers, dockers en oare skriklike wurden massaal fûn wurde, wat de netwurk- en netwurkyngenieurs grif in ûnnedich rudiment sil meitsje.
Hoe is in netwurker oars as in systeembehearder?
Yn it begryp fan minsken net fan IT - neat. Beide sjogge se nei it swarte skerm en skriuwe wat spreuken, soms rêstich vloekend.
Yn it begryp fan programmeurs - miskien troch fakgebiet. Systeembehearders beheare servers, netwurkers beheare switches en routers. Soms is de administraasje min, en falt alles foar elkenien útinoar. No ja, yn gefal fan wat nuver binne de netwurkers ek de skuld. Krekt om't fuck dy, dêrom.
Yn feite is it wichtichste ferskil de oanpak fan wurk. Miskien is it ûnder netwurkers dat d'r de measte oanhingers binne fan 'e oanpak "As it wurket, net oanreitsje it!". As regel kin wat dien wurde (binnen ien ferkeaper) op mar ien manier; de folsleine konfiguraasje fan 'e doaze is dêr yn' e palm fan jo hân. De kosten fan in flater binne heech, en soms heul heech (bygelyks moatte jo ferskate hûnderten kilometers reizgje om de router opnij te starten, en op dit stuit sille ferskate tûzen minsken sûnder kommunikaasje wêze - in heul gewoane situaasje foar in telekomoperator) .
Yn myn miening is dit de reden wêrom netwurkyngenieurs oan 'e iene kant ekstreem tige motivearre binne foar netwurkstabiliteit (en feroaring is de wichtichste fijân fan stabiliteit), en twad giet har kennis mear yn' e djipte as yn 'e breedte (jo dogge net) moatte tsientallen ferskillende daemons konfigurearje kinne, jo moatte de technologyen en har ymplemintaasje kenne fan in spesifike apparatuerfabrikant). Dêrom is in systeembehearder dy't googlede hoe't jo in vlan registrearje op in Cisco-systeem, noch gjin netwurker is. En it is net wierskynlik dat hy in min of mear komplekse netwurk effektyf kin stypje (lykas troubleshoot).
Mar wêrom hawwe jo in netwurker nedich as jo in hoster hawwe?
Foar ekstra jild (en as jo in heul grutte en leafste klant binne, miskien sels fergees, "as freon"), sille datacenter-yngenieurs jo skeakels konfigurearje om oan jo behoeften te passen, en miskien sels helpe jo in BGP-ynterface mei providers op te stellen (as jo jo eigen subnet fan IP-adressen hawwe foar de oankundiging).
It wichtichste probleem is dat it datasintrum net jo IT-ôfdieling is, it is in apart bedriuw waans doel is om winst te meitsjen. Ynklusyf op kosten fan jo as klant. It datasintrum leveret racks, leveret se mei elektrisiteit en kâld, en leveret ek wat "standert" ferbining mei it ynternet. Op grûn fan dizze ynfrastruktuer kin it datasintrum jo apparatuer hostje (colocation), in server oan jo ferhiere (dedicated server), of in beheare tsjinst leverje (bygelyks OpenStack of K8s). Mar it bedriuw fan in datasintrum (meastentiids) is net de administraasje fan kliïntynfrastruktuer, om't dit proses frij arbeidsintensyf is, min automatisearre (en yn in normaal datasintrum is alles wat mooglik is automatisearre), noch slimmer ferienige (elke kliïnt is yndividueel) en oer it algemien beladen mei klachten ("Jo fertelle my dat de tsjinner is ynsteld, mar no is it ferûngelokke, it is allegear jo skuld!!!111"). Dêrom, as de hoster jo mei wat helpt, sil hy besykje it sa ienfâldich en maklik mooglik te meitsjen. Omdat it dreech dwaan is net rendabel, teminsten út it eachpunt fan 'e arbeidskosten fan' e yngenieurs fan dizze selde hoster (mar situaasjes binne oars, sjoch disclaimer). Dit betsjut net dat de hoster needsaaklik alles min docht. Mar it is hielendal net in feit dat hy sil dwaan krekt wat jo echt nedich.
It soe lykje dat it ding frij fanselssprekkend is, mar ferskate kearen yn myn praktyk haw ik it feit tsjinkaam dat bedriuwen in bytsje mear op har hostingprovider begon te fertrouwen dan se moatte, en dit hat net liede ta neat goed. Ik moast lang en yn detail útlizze dat net ien SLA ferlies soe dekke fan downtime (der binne útsûnderingen, mar meastentiids is it heul, Hiel djoer foar de kliïnt) en dat de hoster hielendal net bewust is fan wat der bart yn de ynfrastruktuer fan klanten (útsein heul algemiene yndikatoaren). En de hoster makket ek gjin backups foar jo. De situaasje is noch slimmer as jo mear dan ien hoster hawwe. Yn gefal fan problemen tusken har, sille se grif net foar jo fine wat der mis gie.
Eigentlik binne de motiven hjir krekt itselde as by it kiezen fan "in-house admin team vs outsource". As de risiko's wurde berekkene, is de kwaliteit befredigjend, en it bedriuw makket it net út, wêrom besykje it net. Oan 'e oare kant is it netwurk ien fan' e meast basale lagen fan ynfrastruktuer, en it is amper wurdich om it nei bûten te litten as jo al it oare sels stypje.
Yn hokker gefallen is in netwurker nedich?
Folgjende sille wy spesifyk prate oer moderne fiedingsbedriuwen. Mei operators en ûndernimming is alles dúdlik, plus of min - d'r is net folle feroare yn 'e lêste jierren, en netwurkers wiene dêr earder nedich, en se binne no nedich. Mar mei dy selde "jong en dapper" binne dingen net sa dúdlik. Faak pleatse se har hiele ynfrastruktuer yn 'e wolken, dus se hawwe net iens echt admins nedich - útsein de admins fan deselde wolken, fansels. De ynfrastruktuer, oan 'e iene kant, is frij simpel yn syn ûntwerp, oan' e oare kant, it is goed automatisearre (ansible / puppet, terraform, ci / cd ... goed, do witst). Mar sels hjir binne d'r situaasjes as jo net kinne sûnder in netwurkingenieur.
Foarbyld 1, classic
Stel dat in bedriuw begjint mei ien server mei in iepenbier IP-adres, dat leit yn in datasintrum. Dan binne der twa tsjinners. Dan mear... Ier of let sil der ferlet wêze fan in privee netwurk tusken servers. Omdat "ekstern" ferkear wurdt beheind sawol troch bânbreedte (net mear as 100Mbit / s bygelyks) en troch it folume fan ynladen / uploaded per moanne (ferskillende hosters hawwe ferskillende tariven, mar bânbreedte nei de bûtenwrâld is meastal folle djoerder as in privee netwurk).
De hoster foeget ekstra netwurkkaarten ta oan de tsjinners en befettet se yn har skeakels yn in aparte vlan. In "plat" lokaal gebiet ferskynt tusken servers. Komfortabel!
It oantal servers groeit, en ferkear op it privee netwurk groeit ek - backups, replikaasjes, ensfh. De hoster biedt oan om jo yn aparte skeakels te ferpleatsen, sadat jo gjin oare kliïnten bemuoie, en se bemuoie jo net. De hoster ynstalleart guon skeakels en konfigurearret se op ien of oare manier - nei alle gedachten, lit ien plat netwurk tusken al jo servers. Alles wurket goed, mar op in bepaald momint begjinne problemen: fertragingen tusken hosts ferheegje periodyk, de logs kleie oer tefolle arp-pakketten per sekonde, en tidens in kontrôle hat de pentester jo hiele lokale netwurk neukte, mar ien server brekt.
Wat te dwaan?
Diel it netwurk yn segminten - vlans. Konfigurearje jo eigen adressering yn elke vlan, selektearje in poarte dy't ferkear tusken netwurken sil oerdrage. Konfigurearje acl op 'e poarte om tagong te beheinen tusken segminten, of sels in aparte firewall yn' e buert ynstallearje.
Foarbyld 1, ferfolch
De tsjinners binne ferbûn mei it LAN mei ien snoer. De skeakels yn de rekken binne op ien of oare manier mei elkoar ferbûn, mar as der in ûngelok yn ien rek komt, falle der noch trije neistlizzende. Regelings bestean, mar der binne twifels oer harren relevânsje. Elke tsjinner hat in eigen iepenbier adres, dat wurdt útjûn troch de hoster en is bûn oan it rek. Dy. By it ferpleatsen fan in server moat it adres feroare wurde.
Wat te dwaan?
Ferbine de tsjinners mei LAG (Link Aggregation Group) mei twa koarden oan de skakelaars yn it rek (se moatte ek wêze oerstallich). Reservearje de ferbiningen tusken de racks en konvertearje se nei in "stjer" (of de no modieuze CLOS), sadat it ferlies fan ien rack gjin ynfloed hat op 'e oaren. Selektearje "sintrale" racks wêryn't de netwurkkearn leit en wêr't oare racks wurde ferbûn. Tagelyk, set publike adressering yn oarder, nim fan de hoster (of fan RIR, as it mooglik is) in subnet, dat jo sels (of fia de hoster) oankundigje oan 'e wrâld.
Kin dit alles dien wurde troch in "gewoane" systeembehearder dy't gjin djippe kennis fan netwurken hat? Net wis. Sil de gasthear dit dwaan? Miskien sil it wol, mar jo sille in frij detaillearre technyske spesifikaasje nedich wêze, dy't ien ek moat opstelle. en kontrolearje dan dat alles goed dien is.
Foarbyld 2: Wolk
Litte wy sizze dat jo in VPC hawwe yn guon iepenbiere wolk. Om tagong te krijen fan it kantoar of on-prem diel fan 'e ynfrastruktuer nei it lokale netwurk binnen de VPC, moatte jo in ferbining konfigurearje fia IPSec of in tawijd kanaal. Oan de iene kant, IPSec is goedkeaper, omdat gjin needsaak om ekstra hardware te keapjen; jo kinne in tunnel ynstelle tusken jo server mei in iepenbier adres en de wolk. Mar - fertragingen, beheinde prestaasjes (om't it kanaal fersifere moat wurde), plus net garandearre ferbining (om't tagong fia it gewoane ynternet is).
Wat te dwaan?
Ferheegje in ferbining fia in tawijd kanaal (AWS neamt it bygelyks Direct Connect). Om dit te dwaan, fine jo in partneroperator dy't jo sil ferbine, beslute oer it ferbiningspunt dat it tichtst by jo is (sawol jo foar de operator as de operator nei de wolk), en, as lêste, alles ynstelle. Is it mooglik om dit alles te dwaan sûnder in netwurkingenieur? Fansels ja. Mar hoe't jo sûnder him problemen oplosse kinne yn gefal fan problemen is net mear sa dúdlik.
D'r kinne ek problemen wêze mei beskikberens tusken wolken (as jo in multicloud hawwe) of problemen mei fertragingen tusken ferskate regio's, ensfh. Fansels binne no in protte ark ferskynd dy't de transparânsje ferheegje fan wat der yn 'e wolk bart (deselde Thousand Eyes), mar dit binne allegear ark fan in netwurkingenieur, en gjin ferfanging foar him.
Ik soe noch in tsiental fan sokke foarbylden út myn praktyk sketse kinne, mar ik tink dat it dúdlik is dat it team, útgeande fan in bepaald nivo fan ynfrastruktuerûntwikkeling, in persoan (leafst mear as ien) moat hawwe dy't wit hoe't it netwurk wurket en kin konfigurearje netwurk apparatuer en sortearje út problemen as se ûntsteane. Leau my, hy sil wat te dwaan hawwe
Wat moat in netwurker witte?
It is hielendal net nedich (en sels, soms, skealik) foar in netwurk yngenieur om allinnich mei it netwurk en neat oars. Sels as wy de opsje net beskôgje mei in ynfrastruktuer dy't hast folslein yn 'e iepenbiere wolk libbet (en, wat men ek sizze kin, it wurdt hieltyd populêrder), en nimme bygelyks op premisse of partikuliere wolken, wêr't oer "kennis op CCNP-nivo allinich" "Jo sille net fuortgean.
Neist, yn feite, netwurken - hoewol d'r gewoan in einleaze fjild is foar stúdzje, sels as jo jo allinich konsintrearje op ien gebiet (oanbiedernetwurken, bedriuwen, datasintra, Wi-Fi ...)
Fansels sille in protte fan jo no Python en oare "netwurkautomatisaasje" ûnthâlde, mar dit is allinich in needsaaklike, mar net genôch betingst. Om in netwurkyngenieur "mei súkses by it team te kommen", moat hy deselde taal kinne prate mei sawol ûntwikkelders as oare behearders / devs. Wat betsjut dat?
- kinne net allinich wurkje yn Linux as brûker, mar ek om it te behearjen, teminsten op it sysadmin-jun-nivo: ynstallearje de nedige software, start in mislearre tsjinst opnij, skriuw in ienfâldige systemd-ienheid.
- Begryp (op syn minst yn algemiene termen) hoe't de netwurkstapel wurket yn Linux, hoe't it netwurk wurket yn hypervisors en konteners (lxc / docker / kubernetes).
- Fansels kinne wurkje mei ansible / chef / puppet of in oar SCM systeem.
- In aparte rigel moat skreaun wurde oer SDN en netwurken foar privee wolken (bygelyks TungstenFabric of OpenvSwitch). Dit is in oare grutte laach fan kennis.
Koartsein, ik beskreau in typyske T-foarm spesjalist (sa't it no moade is om te sizzen). It liket neat nij, mar basearre op ynterviewûnderfining kinne net alle netwurkyngenieurs opskeppe fan kennis fan op syn minst twa ûnderwerpen út 'e boppesteande list. Yn 'e praktyk makket it gebrek oan kennis "yn besibbe fjilden" it heul lestich net allinich om te kommunisearjen mei kollega's, mar ek om de easken te begripen dy't bedriuw op it netwurk pleatst, as de ynfrastruktuer fan it leechste nivo fan it projekt. En sûnder dit begryp wurdt it dreger om jo eachpunt te ferdigenjen en it te "ferkeapje" oan bedriuw.
Oan 'e oare kant, deselde gewoante fan "begripe hoe't it systeem wurket" jout netwurkers in hiel goed foardiel boppe ferskate "generalisten" dy't witte oer technologyen út artikels op Habré / medium en petearen op Telegram, mar hawwe hielendal gjin idee hoe te wat prinsipes wurket dit of dat software op? En kennis fan bepaalde patroanen, lykas bekend, ferfangt mei súkses kennis fan in protte feiten.
Konklúzjes, of gewoan TL;DR
- In netwurkbehearder (lykas in DBA- of VoIP-yngenieur) is in spesjalist mei in nochal smel profyl (yn tsjinstelling ta systeembehearders/devs/SRE), wêrfan de need net direkt ûntstiet (en miskien net foar in lange tiid, trouwens) . Mar as it ûntstiet, is it net wierskynlik dat it wurdt ferfongen troch eksterne saakkundigens (útbesteegje of gewoane algemiene doel behearders, "dy't ek soargje foar it netwurk"). Wat is wat tryster is dat de needsaak foar sokke spesjalisten is lyts, en, ûnder betingst, yn in bedriuw mei 800 programmeurs en 30 devops / behearders, kin wêze mar twa netwurkers dy't dogge in poerbêste baan mei harren ferantwurdlikheden. Dy. de merk wie en is hiel, hiel lyts, en mei in goed salaris - noch minder.
- Oan 'e oare kant moat in goede netwurker yn' e moderne wrâld net allinich de netwurken sels witte (en hoe't se har konfiguraasje automatisearje), mar ek hoe't de bestjoeringssystemen en software dy't boppe op dizze netwurken rinne mei har ynteraksje. Sûnder dit sil it heul lestich wêze om te begripen wat jo kollega's fan jo freegje en jo winsken/easken (ferstannich) oan har oer te bringen.
- D'r is gjin wolk, it is gewoan de kompjûter fan in oar. Jo moatte begripe dat it brûken fan iepenbiere / partikuliere wolken as de tsjinsten fan in hostingprovider "dat alles foar jo docht op in turnkey basis" net feroaret oan it feit dat jo applikaasje noch altyd it netwurk brûkt, en problemen dêrmei sille ynfloed hawwe op de wurking fan dyn oanmelding. Jo kar is wêr't it kompetinsjesintrum sil sitte, dat ferantwurdlik is foar it netwurk fan jo projekt.
Boarne: www.habr.com