Tätä artikkelia kirjoitettaessa suositulta työsivustolta hakulausekkeella "Verkkoinsinööri" löytyi noin kolmesataa avointa työpaikkaa eri puolilla Venäjää. Vertailun vuoksi haku ilmauksella "järjestelmänvalvoja" antaa lähes 2.5 tuhatta avointa työpaikkaa ja "DevOps-insinööri" - lähes 800.
Tarkoittaako tämä sitä, että verkon käyttäjiä ei enää tarvita voitokkaiden pilvien, Dockerin, Kubernetesin ja kaikkialla olevan julkisen Wi-Fi:n aikoina?
Selvitetään se (c)
Tutustutaan. Nimeni on Aleksei ja olen verkostoituja.
Olen ollut mukana verkoissa yli 10 vuotta ja työskennellyt eri *nix-järjestelmien kanssa yli 15 vuotta (minulla oli mahdollisuus puuhailla sekä Linuxin että FreeBSD:n kanssa). Olen työskennellyt teleoperaattoreissa, suurissa yrityksissä, joita pidetään "yrityksinä", ja viime aikoina olen työskennellyt "nuoressa ja rohkeassa" fintechissä, jossa pilvet, devopit, kubernetit ja muut pelottavat sanat, jotka tekevät minusta ja kollegoistani ehdottomasti tarpeettomia . Jonain päivänä. Voi olla.
Vastuuvapauslauseke: "Elämässämme kaikki ei ole aina ja kaikkialla, vaan jotain, joskus paikoin" (c) Maxim Dorofejev.
Kaikkea alla kirjoitettua voidaan ja tulee pitää kirjoittajan henkilökohtaisena mielipiteenä, joka ei väitä olevan lopullinen totuus tai edes täysimittainen tutkimus. Kaikki hahmot ovat kuvitteellisia, kaikki sattumat ovat satunnaisia.
Tervetuloa minun maailmaani.
Missä voit jopa tavata verkostoituneita?
1. Teleoperaattorit, palveluyritykset ja muut integraattorit. Täällä kaikki on yksinkertaista: verkosto heille on bisnestä. Ne joko myyvät suoraan yhteyksiä (operaattoreita) tai tarjoavat palveluita asiakkaidensa verkkojen käynnistämiseen/ylläpitoon.
Täällä on paljon kokemusta, mutta ei paljon rahaa (ellet ole johtaja tai menestyvä myyntipäällikkö). Ja kuitenkin, jos pidät verkoista ja olet vasta matkasi alussa, ura jonkun ei kovin suuren operaattorin tukena on nytkin ihanteellinen lähtökohta (liittovaltion verkoissa kaikki on hyvin käsikirjoitettua, ja siellä on vähän tilaa luovuudelle). Tarinat siitä, kuinka päivystävästä insinööristä voi kasvaa muutamassa vuodessa C-tason johtajaksi, ovat myös melko todellisia, vaikkakin harvinaisia, ilmeisistä syistä. Henkilöstöä tarvitaan aina, sillä vaihtuvuutta tapahtuu. Tämä on yhtä aikaa sekä hyvää että huonoa - vapaita paikkoja toisaalta aina on - usein aktiivisimmat/älykkäimmät lähtevät nopeasti joko promootioon tai muihin, "lämpimimpiin" paikkoihin.
2. Ehdollinen "yritys". Sillä ei ole väliä, liittyykö hänen päätoimintansa IT-alaan vai ei. Pääasia, että sillä on oma IT-osasto, joka varmistaa yrityksen sisäisten järjestelmien toiminnan, mukaan lukien toimistojen verkon, viestintäkanavat konttoreihin jne. Verkkoinsinöörin tehtäviä tällaisissa yrityksissä voi suorittaa "osa-aikaisesti" järjestelmänvalvoja (jos verkkoinfrastruktuuri on pieni tai sitä hoitaa ulkopuolinen urakoitsija), ja verkkoasiantuntija, jos sellainen on, voi samalla huolehtia puhelimesta ja SAN:sta (ei hyvä). He maksavat eri tavalla - se riippuu suuresti liiketoiminnan kannattavuudesta, yrityksen koosta ja rakenteesta. Olen työskennellyt yritysten kanssa, joissa Cisco-järjestelmiä "ladattiin säännöllisesti tynnyreihin", ja yritysten kanssa, joissa verkko rakennettiin ulosteista, tikkuista ja sinisestä teipistä, eikä palvelimia koskaan päivitetty (tarpeetonta sanoa, ettei myöskään varauksia annettu) . Kokemusta täällä on paljon vähemmän, ja se liittyy melkein varmasti tiukkaan myyjälukitukseen tai "miten tehdä jotain tyhjästä". Henkilökohtaisesti pidin sitä villin tylsänä, vaikka monet ihmiset pitävät siitä - kaikki on melko mitattua ja ennustettavaa (jos puhumme suurista yrityksistä), "dorakha-bahato" jne. Ainakin kerran vuodessa joku suuri toimittaja kertoo keksineensä toisen mega-super-duper-järjestelmän, joka automatisoi kaiken nyt ja kaikki järjestelmänvalvojat ja verkkokäyttäjät voidaan hajauttaa, jolloin pari nappia painaa kauniissa käyttöliittymässä. Tosiasia on, että vaikka jättäisimme huomiotta ratkaisun kustannukset, verkottajat eivät lähde sieltä minnekään. Kyllä, ehkä konsolin tilalle tulee jälleen web-käyttöliittymä (mutta ei tietty laitteisto, vaan suuri järjestelmä, joka hallitsee kymmeniä ja satoja tällaisia laitteita), mutta tieto "kuinka kaikki toimii sisällä" olla tarpeen.
3. Tuoteyritykset, jonka tuotto tulee jonkin ohjelmiston tai alustan - saman tuotteen - kehittämisestä (ja usein myös toiminnasta). Yleensä ne ovat pieniä ja ketterät, ne ovat vielä kaukana yritysten mittakaavasta ja niiden byrokratisoinnista. Juuri täällä niitä samoja devoppeja, cubereita, telakoita ja muita kauheita sanoja löytyy massasta, mikä varmasti tekee verkosta ja verkkoinsinööreistä tarpeettoman alkeellisen.
Miten verkonkäyttäjä eroaa järjestelmänvalvojasta?
Ihmisten ymmärryksessä, jotka eivät ole IT:stä - ei mitään. Molemmat katsovat mustaa näyttöä ja kirjoittavat loitsuja, joskus hiljaa kiroillen.
Ohjelmoijien ymmärryksessä - ehkä aihealueittain. Järjestelmänvalvojat hallinnoivat palvelimia, verkkokäyttäjät kytkimiä ja reitittimiä. Joskus hallinto on huonoa, ja kaikki hajoaa kaikkien kohdalla. No, jos jotain outoa, myös verkottajat ovat syyllisiä. Vain siksi, että vittuun, siksi.
Itse asiassa tärkein ero on lähestymistapa työhön. Ehkä juuri verkostoituneiden keskuudessa on eniten "Jos toimii, älä koske!" -lähestymistavan kannattajia. Pääsääntöisesti jotain voidaan tehdä (yhden myyjän sisällä) vain yhdellä tavalla; laatikon koko kokoonpano on kämmenelläsi. Virheen hinta on korkea ja joskus erittäin korkea (joudut esimerkiksi matkustamaan useita satoja kilometrejä käynnistääksesi reitittimen uudelleen, ja tällä hetkellä useat tuhannet ihmiset ovat ilman yhteyttä - melko yleinen tilanne teleoperaattorille) .
Mielestäni tästä syystä verkkoinsinöörit ovat toisaalta erittäin motivoituneita verkon vakauteen (ja muutos on vakauden päävihollinen), ja toiseksi heidän tietämyksensä menee syvemmälle kuin laajalle (et sinun on kyettävä konfiguroimaan kymmeniä erilaisia demoneita, sinun on tunnettava tekniikat ja niiden toteutus tietyltä laitevalmistajalta). Siksi järjestelmänvalvoja, joka googletti kuinka rekisteröidä vlan Cisco-järjestelmään, ei ole vielä verkkokäyttäjä. Ja on epätodennäköistä, että hän pystyy tehokkaasti tukemaan (sekä vianmääritykseen) enemmän tai vähemmän monimutkaista verkkoa.
Mutta miksi tarvitset verkottajaa, jos sinulla on isännöitsijä?
Lisärahaa vastaan (ja jos olet erittäin suuri ja rakas asiakas, ehkä jopa ilmaiseksi, "ystävänä") palvelinkeskusten insinöörit määrittävät kytkimesi tarpeidesi mukaan ja ehkä jopa auttavat sinua luomaan BGP-rajapinnan palveluntarjoajien kanssa. (jos sinulla on oma IP-osoitteiden aliverkko ilmoitusta varten).
Suurin ongelma on, että konesali ei ole IT-osastosi, se on erillinen yritys, jonka tavoitteena on tuottaa voittoa. Mukaan lukien sinun kustannuksellasi asiakkaana. Palvelinkeskus tarjoaa telineitä, tarjoaa niille sähköä ja kylmää ja tarjoaa myös jonkin verran "oletus"-yhteyttä Internetiin. Tämän infrastruktuurin perusteella palvelinkeskus voi isännöidä laitteitasi (colokation), vuokrata sinulle palvelimen (omistettu palvelin) tai tarjota hallittua palvelua (esimerkiksi OpenStack tai K8s). Mutta konesalin liiketoiminta (yleensä) ei ole asiakasinfrastruktuurin hallintaa, koska tämä prosessi on melko työvoimavaltainen, huonosti automatisoitu (ja normaalissa konesalissa kaikki mikä on mahdollista automatisoitua), yhtenäinen vielä huonommin (jokainen asiakas on yksilöllinen) ja yleensä täynnä valituksia ("kerrotit minulle, että palvelin on perustettu, mutta nyt se on kaatunut, se on sinun syytäsi!!!111"). Siksi, jos isännöitsijä auttaa sinua jossain, hän yrittää tehdä siitä mahdollisimman yksinkertaista ja kätevää. Koska vaikean tekeminen on kannattamatonta, ainakin tämän saman isännän insinöörien työvoimakustannusten kannalta (mutta tilanteet ovat erilaisia, katso vastuuvapauslauseke). Tämä ei tarkoita, että isännöitsijä tekisi kaiken huonosti. Mutta se ei ole ollenkaan tosiasia, että hän tekee juuri sen, mitä todella tarvitsit.
Vaikuttaa siltä, että asia on varsin ilmeinen, mutta useaan otteeseen olen käytännössä törmännyt siihen, että yritykset alkoivat luottaa isännöintipalveluntarjoajaansa hieman enemmän kuin pitäisi, eikä tämä johtanut mihinkään hyvään. Minun piti selittää pitkästi ja yksityiskohtaisesti, että yksikään SLA ei kattaisi seisokkien aiheuttamia tappioita (poikkeuksiakin on, mutta yleensä se on asiakkaalle erittäin, ERITTÄIN kallista) ja että isännöitsijä ei ole ollenkaan tietoinen siitä, mitä asiakkaiden infrastruktuuri (lukuun ottamatta hyvin yleisiä indikaattoreita). Ja isännöitsijä ei myöskään tee varmuuskopioita puolestasi. Tilanne on vielä pahempi, jos sinulla on useampi kuin yksi isäntä. Jos heidän välillään on ongelmia, he eivät varmasti saa selville, mikä meni pieleen.
Itse asiassa motiivit ovat tässä täsmälleen samat kuin valittaessa "sisäinen järjestelmänvalvojatiimi vs ulkoistaminen". Jos riskit on laskettu, laatu on tyydyttävä, eikä yritystä haittaa, miksi ei kokeilisi. Toisaalta verkko on yksi perusinfrastruktuurin kerroksista, ja sitä tuskin kannattaa jättää ulkopuolisille kavereille, jos kaikkea muuta jo tuet itse.
Missä tapauksissa tarvitaan verkostoituja?
Seuraavaksi puhumme erityisesti nykyaikaisista elintarvikeyrityksistä. Operaattoreiden ja yritysten kanssa kaikki on selvää, plussaa tai miinusta - siellä ei ole juurikaan muuttunut viime vuosina, ja verkottajia siellä tarvittiin ennenkin, ja niitä tarvitaan nytkin. Mutta samojen "nuorten ja rohkeiden" kanssa asiat eivät ole niin selkeitä. Usein he sijoittavat koko infrastruktuurinsa pilviin, joten he eivät edes tarvitse järjestelmänvalvojia - paitsi tietysti samojen pilvien ylläpitäjiä. Infrastruktuuri on toisaalta suunnittelultaan melko yksinkertainen, toisaalta se on hyvin automatisoitu (ansible/puppet, terraform, ci/cd... no, tiedäthän). Mutta täälläkin on tilanteita, joissa et voi tulla toimeen ilman verkkoinsinööriä.
Esimerkki 1, klassikko
Oletetaan, että yritys aloittaa yhdellä palvelimella, jolla on julkinen IP-osoite ja joka sijaitsee datakeskuksessa. Sitten on kaksi palvelinta. Sitten lisää... Ennemmin tai myöhemmin tarvitaan yksityistä verkkoa palvelimien välillä. Koska "ulkoista" liikennettä rajoittaa sekä kaistanleveys (esimerkiksi enintään 100 Mbit/s) että ladattujen/latausten määrä kuukaudessa (eri isännöitsijillä on erilaiset tariffit, mutta kaistanleveys ulkomaailmaan on yleensä paljon kalliimpaa kuin yksityinen verkko).
Isäntäkone lisää ylimääräisiä verkkokortteja palvelimiin ja sisällyttää ne kytkimiinsä erillisessä vlanissa. Palvelinten väliin ilmestyy "tasainen" paikallisalue. Mukava!
Palvelimien määrä kasvaa, ja myös yksityisen verkon liikenne kasvaa - varmuuskopiot, replikaatiot jne. Isännöitsijä tarjoaa siirtävänsä sinut erillisiin kytkimiin, jotta et häiritse muita asiakkaita, eivätkä he häiritse sinua. Isännöitsijä asentaa joitain kytkimiä ja jollakin tavalla konfiguroi ne - todennäköisimmin jättäen yhden tasaisen verkon kaikkien palvelimiisi. Kaikki toimii hyvin, mutta jossain vaiheessa ongelmat alkavat: viiveet isäntien välillä lisääntyvät ajoittain, lokit valittavat liian monesta arp-paketista sekunnissa ja auditoinnin aikana pentesteri nai koko paikallisverkkosi rikkoen vain yhden palvelimen.
Mitä minun pitäisi tehdä?
Jaa verkko segmentteihin - vlan. Määritä oma osoitteesi jokaisessa vlanissa, valitse yhdyskäytävä, joka siirtää liikennettä verkkojen välillä. Määritä yhdyskäytävän acl rajoittaaksesi pääsyä segmenttien välillä tai jopa asenna erillinen palomuuri lähelle.
Esimerkki 1, jatkuu
Palvelimet on kytketty LAN-verkkoon yhdellä johdolla. Telineissä olevat kytkimet on jotenkin kytketty toisiinsa, mutta jos yhdessä telineessä tapahtuu onnettomuus, putoaa vielä kolme vierekkäistä. Suunnitelmia on olemassa, mutta niiden merkityksellisyyttä epäillään. Jokaisella palvelimella on oma julkinen osoite, jonka isännöitsijä antaa ja joka on sidottu telineeseen. Nuo. Palvelinta siirrettäessä osoite on vaihdettava.
Mitä minun pitäisi tehdä?
Yhdistä palvelimet LAG:lla (Link Aggregation Group) kahdella johdolla telineessä oleviin kytkimiin (niiden on myös oltava redundantteja). Varaa telineiden väliset liitännät ja muunna ne "tähdeksi" (tai nyt muodikkaaksi CLOSiksi), jotta yhden telineen katoaminen ei vaikuta muihin. Valitse "keskitelineet", joissa verkon ydin sijoitetaan ja joihin muut telineet liitetään. Samalla laita julkinen osoitus järjestykseen, ota isännöitsijältä (tai RIR:ltä, jos mahdollista) aliverkko, jonka sinä itse (tai isännöitsijän kautta) ilmoitat maailmalle.
Voiko tämän kaiken tehdä "tavallinen" järjestelmänvalvoja, jolla ei ole syvällistä tietoa verkoista? Epävarma. Tekeekö isännöitsijä tämän? Ehkä se tulee, mutta tarvitset melko yksityiskohtaisen teknisen eritelmän, joka jonkun on myös laadittava. ja tarkista sitten, että kaikki on tehty oikein.
Esimerkki 2: Pilvi
Oletetaan, että sinulla on VPC jossain julkisessa pilvessä. Jotta pääset toimistosta tai infrastruktuurin paikallisesta osasta VPC:n sisällä olevaan paikallisverkkoon, sinun on määritettävä yhteys IPSecin tai erillisen kanavan kautta. Toisaalta IPSec on halvempi, koska ei tarvitse ostaa lisälaitteita; voit luoda tunnelin julkisella osoitteella varustetun palvelimesi ja pilven välille. Mutta - viiveet, rajoitettu suorituskyky (koska kanava on salattava), sekä takaamaton yhteys (koska pääsy tapahtuu tavallisen Internetin kautta).
Mitä minun pitäisi tehdä?
Luo yhteys erillisen kanavan kautta (esimerkiksi AWS kutsuu sitä Direct Connectiksi). Tätä varten etsi kumppanioperaattori, joka yhdistää sinut, päätä lähimpänä oleva yhteyspiste (sekä sinä operaattoriin että operaattori pilveen) ja lopuksi määritä kaikki. Onko mahdollista tehdä tämä kaikki ilman verkkoinsinööriä? Varmasti kyllä. Mutta vianmääritys ilman häntä ongelmien sattuessa ei ole enää niin selvää.
Saattaa myös olla ongelmia käytettävyydessä pilvien välillä (jos sinulla on multicloud) tai ongelmia viiveissä eri alueiden välillä jne. Tietenkin nyt on ilmestynyt monia työkaluja, jotka lisäävät pilvessä tapahtuvan läpinäkyvyyttä (sama Thousand Eyes), mutta nämä ovat kaikki verkkoinsinöörin työkaluja, eivätkä korvaa häntä.
Voisin hahmotella tusinaa lisää tällaisia esimerkkejä omasta käytännöstäni, mutta mielestäni on selvää, että tietyltä infrastruktuurin kehitystasolta lähtien tiimissä täytyy olla henkilö (mieluiten useampi kuin yksi), joka tietää, miten verkko toimii ja osaa konfiguroida verkkolaitteita ja ratkaise ongelmat, jos niitä ilmenee. Usko minua, hänellä on tekemistä
Mitä verkostoitujan tulee tietää?
Verkkoinsinöörin ei ole ollenkaan välttämätöntä (ja joskus jopa haitallista) käsitellä vain verkkoa eikä mitään muuta. Vaikka emme harkitsisikaan vaihtoehtoa infrastruktuurilla, joka asuu lähes kokonaan julkisessa pilvessä (ja sanotaanpa mitä tahansa, siitä on tulossa yhä suositumpi), vaan otamme esimerkiksi tilapäiset tai yksityiset pilvet, joissa aiheesta "CCNP-tason tieto yksin" "Et lähde.
Itse asiassa verkkojen lisäksi - vaikka opiskelukenttä on yksinkertaisesti loputon, vaikka keskittyisit vain yhteen alueeseen (palveluntarjoajan verkot, yritykset, datakeskukset, Wi-Fi ...)
Tietysti monet teistä muistavat nyt Pythonin ja muun "verkkoautomaation", mutta tämä on vain välttämätön, mutta ei riittävä ehto. Jotta verkkoinsinööri "liittyisi onnistuneesti tiimiin", hänen on pystyttävä puhumaan samaa kieltä sekä kehittäjien että muiden järjestelmänvalvojien/kehittäjien kanssa. Mitä se tarkoittaa?
- pystyä paitsi työskentelemään Linuxissa käyttäjänä, myös hallita sitä, ainakin sysadmin-jun -tasolla: asenna tarvittava ohjelmisto, käynnistä epäonnistunut palvelu uudelleen, kirjoita yksinkertainen systemd-unit.
- Ymmärrä (ainakin yleisesti), kuinka verkkopino toimii Linuxissa, kuinka verkko toimii hypervisoreissa ja konteissa (lxc / docker / kubernetes).
- Tietenkin pystyä työskentelemään ansible/chef/puppet tai muun SCM-järjestelmän kanssa.
- SDN:stä ja yksityispilvien verkoista (esim. TungstenFabric tai OpenvSwitch) tulee kirjoittaa erillinen rivi. Tämä on toinen valtava tietokerros.
Lyhyesti sanottuna kuvailin tyypillistä T-muodon asiantuntijaa (kuten nyt on muotia sanoa). Ei näytä olevan mitään uutta, mutta haastattelukokemuksen perusteella kaikki verkkoinsinöörit eivät voi ylpeillä tiedolla vähintään kahdesta yllä olevasta luettelosta. Käytännössä tiedon puute "liitännäisaloilla" vaikeuttaa paitsi kommunikointia työtovereiden kanssa myös yritysten asettamien vaatimusten ymmärtämistä verkostolle projektin alimman tason infrastruktuurina. Ja ilman tätä ymmärrystä on vaikeampaa puolustaa näkemystäsi ja "myy" se yrityksille.
Toisaalta sama tapa "ymmärtää järjestelmän toiminta" antaa verkostoituneille erittäin hyvän edun verrattuna erilaisiin "yleistöihin", jotka tietävät teknologioista Habré/medium-artikkeleista ja Telegramin keskusteluista, mutta heillä ei ole minkäänlaista käsitystä siitä, miten mitä tehdä. millä periaatteilla tämä tai tuo ohjelmisto toimii? Ja tiettyjen mallien tuntemus, kuten tiedetään, korvaa menestyksekkäästi monien tosiasioiden tiedon.
Johtopäätökset, tai vain TL;DR
- Verkon ylläpitäjä (kuten DBA- tai VoIP-insinööri) on asiantuntija, jolla on melko kapea profiili (toisin kuin järjestelmänvalvojat/devs/SRE), jonka tarvetta ei esiinny heti (eikä itse asiassa voi ilmaantua pitkään aikaan) . Mutta jos se ilmenee, sitä tuskin korvaa ulkopuolinen asiantuntemus (ulkoistaa tai tavalliset yleisvalvojat, "jotka myös huolehtivat verkosta"). Hieman surullisinta on se, että tarve tällaisille asiantuntijoille on pieni, ja ehdollisesti 800 ohjelmoijan ja 30 devopin/ylläpitäjän yrityksessä voi olla vain kaksi verkottajaa, jotka tekevät erinomaista työtä vastuullaan. Nuo. markkinat olivat ja ovat hyvin, hyvin pienet, ja hyvällä palkalla - jopa vähemmän.
- Toisaalta hyvän verkostoitujan nykymaailmassa täytyy tietää paitsi itse verkot (ja kuinka niiden konfigurointi automatisoidaan), vaan myös kuinka näiden verkkojen päällä toimivat käyttöjärjestelmät ja ohjelmistot ovat vuorovaikutuksessa niiden kanssa. Ilman tätä on äärimmäisen vaikeaa ymmärtää, mitä kollegasi sinulta kysyvät, ja välittää (kohtuullisesti) toiveitasi/vaatimuksiasi heille.
- Pilviä ei ole, se on vain jonkun muun tietokone. Sinun on ymmärrettävä, että julkisten/yksityisten pilvien tai palveluntarjoajan palveluiden käyttäminen "joka tekee kaiken puolestasi avaimet käteen -periaatteella" ei muuta sitä tosiasiaa, että sovelluksesi käyttää edelleen verkkoa ja siihen liittyvät ongelmat vaikuttavat verkkopalvelun toimintaan. hakemuksesi. Valintasi on, missä osaamiskeskus sijaitsee, joka vastaa hankkeesi verkostosta.
Lähde: will.com