Tällä hetkellä tämä on lähes markkinoiden kallein asema. Melu "DevOps"-insinöörien ympärillä on yli kaikkien kuviteltavissa olevien rajojen, ja vielä pahempaa vanhempien DevOps-insinöörien kanssa.
Työskentelen integraatio- ja automaatioosaston päällikkönä, arvaa englanninkielinen dekoodaus - DevOps Manager. On epätodennäköistä, että englanninkielinen transkriptio kuvastaa päivittäistä toimintaamme, mutta venäläinen versio on tässä tapauksessa tarkempi. Toimintani luonteesta johtuen on luontevaa, että joudun haastattelemaan tulevia tiimini jäseniä, ja viimeisen vuoden aikana minun kauttani on käynyt noin 50 henkilöä ja saman verran on katkaistu esinäytöksissä työntekijöideni kanssa.
Etsimme edelleen työkavereita, sillä DevOps-leiman takana piilee erittäin suuri kerros erilaisia insinöörejä.
Kaikki alla kirjoitettu on henkilökohtaista mielipidettäni, sinun ei tarvitse yhtyä siihen, mutta myönnän, että se lisää hieman väriä asenteeseesi aiheeseen. Huolimatta suosiosta putoamisen vaarasta, julkaisen mielipiteeni, koska uskon, että sillä on paikka olla.
Yrityksillä on erilainen käsitys siitä, keitä DevOps-insinöörit ovat, ja resurssien nopean palkkaamisen vuoksi ne kiinnittävät tämän etiketin kaikkiin. Tilanne on varsin outo, sillä yritykset ovat valmiita maksamaan näille ihmisille epärealistisia palkkioita, saamalla heille useimmiten työkaluvastaavan.
Keitä ovat DevOps-insinöörit?
Aloitetaanpa sen ilmestymishistoriasta – Kehitystoiminta ilmestyi odotettuna seurauksena jälleen askeleena kohti vuorovaikutuksen optimointia pienissä tiimeissä tuotetuotannon nopeuttamiseksi. Ajatuksena oli vahvistaa kehitystiimiä tuoteympäristön hallinnan menetelmien ja lähestymistapojen tuntemuksella. Toisin sanoen kehittäjän on ymmärrettävä ja tiedettävä, kuinka hänen tuotteensa toimii tietyissä olosuhteissa, hänen on ymmärrettävä, kuinka tuotteensa otetaan käyttöön, mitä ympäristön ominaisuuksia voidaan säätää suorituskyvyn parantamiseksi. Joten jonkin aikaa DevOps-lähestymistapaa käyttäviä kehittäjiä ilmestyi. DevOps-kehittäjät kirjoittivat rakennus- ja pakkauskomentosarjoja yksinkertaistaakseen toimintaansa ja tuotantoympäristön suorituskykyä. Ratkaisuarkkitehtuurin monimutkaisuus ja infrastruktuurikomponenttien keskinäinen vaikutus ajan myötä alkoivat kuitenkin heikentää ympäristöjen suorituskykyä; jokaisen iteroinnin myötä vaadittiin yhä syvempää tiettyjen komponenttien ymmärrystä, mikä heikensi kehittäjän tuottavuutta ylimääräisten komponenttien takia. kustannukset, jotka aiheutuvat komponenttien ja viritysjärjestelmien ymmärtämisestä tiettyä tehtävää varten. Kehittäjän omat kustannukset kasvoivat, tuotteen hinta sen mukana, vaatimukset uusille kehittäjille tiimissä hyppäsivät jyrkästi, koska heidän piti kattaa myös kehitystähden vastuut ja luonnollisesti "tähdet" vähenivät. ja vähemmän saatavilla. On myös syytä huomata, että kokemukseni mukaan harvat kehittäjät ovat kiinnostuneita käyttöjärjestelmän ytimen pakettien käsittelyn erityispiirteistä, pakettien reitityssäännöistä ja isäntätietoturvanäkökohdista. Looginen askel oli houkutella järjestelmänvalvoja, joka tuntee tämän ja antaa hänelle samanlaisia vastuita, mikä mahdollisti hänen kokemuksensa ansiosta saavuttaa samat indikaattorit halvemmalla kuin "tähti" -kehityksen kustannuksissa. Tällaiset järjestelmänvalvojat sijoitettiin tiimiin, ja hänen päätehtävänsä oli hallita testi- ja tuotantoympäristöjä tietyn tiimin sääntöjen mukaisesti tälle tietylle tiimille osoitetuilla resursseilla. Näin itse asiassa DevOps ilmestyi enemmistön mieliin.
Osittain tai kokonaan, ajan myötä, nämä järjestelmänvalvojat alkoivat ymmärtää tämän tietyn tiimin tarpeita kehitystyön alalla, kuinka helpottaa kehittäjien ja testaajien elämää, kuinka päivittää päivitys voidaan ottaa käyttöön eikä tarvitse jäädä yöksi perjantaihin toimistoon, korjaamalla käyttöönottovirheet. Aika kului, ja nyt "tähdet" olivat järjestelmänvalvojat, jotka ymmärsivät, mitä kehittäjät halusivat. Vaikutusten minimoimiseksi hallintaapuohjelmia alkoi tulla esiin; kaikki muistivat vanhat ja luotettavat käyttöjärjestelmän tason eristysmenetelmät, jotka mahdollistivat turvallisuuden, verkko-osan hallinnan ja isäntäkonfiguraation minimoimisen. kokonaisuutena ja sen seurauksena vähentää uusien "tähtien" vaatimuksia.
"Ihana" asia on ilmestynyt - telakka. Miksi upea? Kyllä, vain siksi, että eristämisen luominen chrootissa tai vankilassa sekä OpenVZ:ssä vaati ei-triviaalia käyttöjärjestelmän tuntemusta, päinvastoin apuohjelman avulla voit yksinkertaisesti luoda eristetyn sovellusympäristön tietylle isännälle, jossa on kaikki tarvittava sisällä ja käsissä. Kehitysohjat jälleen, ja järjestelmänvalvoja voi hallita vain yhden isännän, mikä varmistaa sen turvallisuuden ja korkean käytettävyyden - looginen yksinkertaistus. Mutta edistyminen ei pysähdy ja järjestelmät ovat jälleen yhä monimutkaisempia, komponentteja on enemmän ja enemmän, yksi isäntä ei enää täytä järjestelmän tarpeita ja on tarpeen rakentaa klustereita, palaamme jälleen järjestelmänvalvojien pariin, jotka ovat pystyy rakentamaan näitä järjestelmiä.
Jakso toisensa jälkeen ilmaantuu erilaisia kehitystä ja/tai hallintoa yksinkertaistavia järjestelmiä, orkesterijärjestelmiä, joita on helppo käyttää, kunnes joudut poikkeamaan vakioprosessista. Mikropalveluarkkitehtuuri ilmestyi myös tavoitteena yksinkertaistaa kaikkea edellä kuvattua - vähemmän suhteita, helpompi hallita. Kokemukseni mukaan en löytänyt täysin mikropalveluarkkitehtuuria, sanoisin, että 50-50-50 prosenttia mikropalveluista, mustista laatikoista, tuli sisään, tuli ulos käsiteltynä, loput 50 on repeytynyt monoliitti, palvelut eivät pysty toimimaan erillään muista komponentit. Kaikki tämä asetti jälleen rajoituksia sekä kehittäjien että järjestelmänvalvojien tietotasolle.
Samanlaiset "heilahtelut" tietyn resurssin asiantuntijatiedon tasolla jatkuvat tähän päivään asti. Mutta poikkeamme hieman, on monia korostamisen arvoisia kohtia.
Rakennusinsinööri/julkaisuinsinööri
Erittäin pitkälle erikoistuneet insinöörit, jotka nousivat esiin keinona standardoida ohjelmistojen rakennusprosesseja ja -julkaisuja. Laajalle levinneen Agilen käyttöönoton aikana näyttää siltä, että ne eivät enää olleet kysyttyjä, mutta tämä ei ole kaukana siitä. Tämä erikoistuminen ilmestyi keinona standardisoida ohjelmistojen kokoamista ja toimittamista teollisessa mittakaavassa, ts. käyttäen standarditekniikoita kaikille yrityksen tuotteille. DevOpsin myötä kehittäjät menettivät osittain toimintonsa, koska juuri kehittäjät alkoivat valmistella tuotetta toimitusta varten, ja koska infrastruktuuri muuttui ja lähestymistapa toimittaa mahdollisimman nopeasti laadusta välittämättä, ne muuttuivat ajan myötä muutosten pysäyttäjä, koska laatustandardien noudattaminen hidastaa väistämättä toimituksia. Joten vähitellen osa Build/Release-insinöörien toiminnoista siirtyi järjestelmänvalvojien harteille.
Opit ovat niin erilaisia
Eteenpäin mennään ja taas monien vastuiden läsnäolo ja pätevän henkilöstön puute ajaa meidät kohti tiukkaa erikoistumista, kuten sieniä sateen jälkeen, erilaisia toimintoja ilmaantuu:
- TechOps - enikey-järjestelmänvalvojat eli HelpDesk Engineer
- LiveOps - järjestelmänvalvojat, jotka vastaavat ensisijaisesti tuotantoympäristöistä
- CloudOps – järjestelmänvalvojat, jotka ovat erikoistuneet julkisiin Azure-, AWS-, GCP-pilviin jne.
- PlatOps/InfraOps/SysOps - infrastruktuurin järjestelmänvalvojat.
- NetOps - verkonvalvojat
- SecOps - tietoturvaan erikoistuneet järjestelmänvalvojat - PCI-yhteensopivuus, CIS-yhteensopivuus, korjaukset jne.
DevOps on (teoriassa) henkilö, joka ymmärtää omalta kädeltä kaikki kehityssyklin prosessit - kehitys, testaus, ymmärtää tuotearkkitehtuurin, osaa arvioida tietoturvariskejä, tuntee lähestymistavat ja automaatiotyökalut ainakin korkealla taso ymmärtää tämän lisäksi myös esi- ja jälkikäsittelyn tuotteen julkaisutuen. Henkilö, joka pystyy toimimaan sekä toiminnan että kehityksen puolestapuhujana, mikä mahdollistaa suotuisan yhteistyön näiden kahden pilarin välillä. Ymmärtää tiimityön suunnittelun ja asiakkaiden odotusten hallinnan prosessit.
Tällaisten töiden ja vastuiden suorittamiseksi tällä henkilöllä on oltava keinot hallita kehitys- ja testausprosessien lisäksi myös tuoteinfrastruktuurin hallintaa sekä resurssien suunnittelua. Tämän ymmärryksen kehittäjät eivät voi sijaita IT-alalla, tutkimuksessa ja kehityksessä tai edes PMO:ssa; sillä on oltava vaikutusvalta kaikilla näillä alueilla - yrityksen tekninen johtaja, tekninen johtaja.
Onko tämä totta sinun yrityksessäsi? - Epäilen. Useimmissa tapauksissa tämä on joko IT- tai T&K-toimintaa.
Rahoituksen puute ja kyky vaikuttaa ainakin yhteen näistä kolmesta toiminta-alueesta siirtää ongelmien painon sinne, missä näitä muutoksia on helpompi soveltaa, kuten teknisten rajoitusten soveltaminen julkaisuihin liittyen "likaiseen" koodiin staattisen sähkön mukaan. analysaattorijärjestelmät. Eli kun PMO asettaa tiukan määräajan toiminnallisuuksien julkaisulle, T&K ei pysty tuottamaan laadukasta tulosta näissä määräajoissa ja tuottaa sen parhaansa mukaan jättäen refaktoroinnin myöhempään, IT:hen liittyvä DevOps estää julkaisun teknisin keinoin. . Valtuutuksen puute tilanteen muuttamiseksi vastuullisten työntekijöiden tapauksessa johtaa ylimääräiseen vastuuseen siitä, mihin he eivät voi vaikuttaa, varsinkin jos nämä työntekijät ymmärtävät ja näkevät virheet ja kuinka ne korjataan - "Autuus on tietämättömyyttä", ja seurauksena näiden työntekijöiden työuupumisesta ja menetyksestä.
DevOps-resurssimarkkinat
Katsotaanpa useita avoimia DevOps-tehtäviä eri yrityksiltä.
Olemme valmiita tapaamaan sinut, jos:
- Omistat Zabbixin ja tiedät mikä Prometheus on;
- Iptables;
- BASH tohtoriopiskelija;
- Professori Ansible;
- Linux Guru;
- Osaat käyttää virheenkorjausta ja etsiä sovellusongelmia yhdessä kehittäjien kanssa (php/java/python);
- Reititys ei tee sinusta hysteeristä;
- Kiinnitä erityistä huomiota järjestelmän turvallisuuteen;
- Varmuuskopioi "kaikki ja kaikki" ja palauta myös onnistuneesti tämä "kaikki ja kaikki";
- Osaat konfiguroida järjestelmän siten, että minimistä saadaan maksimi;
- Määritä replikointi ennen nukkumaanmenoa Postgresissa ja MySQL:ssä;
- CI:n/CD:n asettaminen ja säätäminen on sinulle yhtä välttämätöntä kuin aamiainen/lounas/illallinen.
- Sinulla on kokemusta AWS:stä;
- Valmis kehittymään yrityksen kanssa;
Joten:
- 1 - 6 - järjestelmänvalvoja
- 7 - pientä verkonhallintaa, joka sopii myös järjestelmänvalvojan keskitasolle
- 8 - vähän turvallisuutta, joka on pakollinen keskitason järjestelmänvalvojalle
- 9-11 – Keskijärjestelmänvalvoja
- 12 — Määritetyistä tehtävistä riippuen joko keskijärjestelmänvalvoja tai rakennusinsinööri
- 13 - Virtualisointi - Middle System Administrator tai ns. CloudOps, edistynyt tuntemus tietyn isännöintisivuston palveluista varojen tehokkaaseen käyttöön ja ylläpitokuormituksen vähentämiseen
Yhteenvetona tästä avoimesta työpaikasta voidaan sanoa, että Keski/Senior System Administrator riittää miehille.
Muuten, sinun ei pitäisi jakaa järjestelmänvalvojia voimakkaasti Linuxissa/Windowsissa. Ymmärrän tietysti, että näiden kahden maailman palvelut ja järjestelmät ovat erilaisia, mutta perusta kaikelle on sama ja jokainen itseään kunnioittava järjestelmänvalvoja tuntee sekä toisen että toisen, ja vaikka hän ei olisi tuttu, se pätevän järjestelmänvalvojan ei ole vaikea tutustua siihen.
Tarkastellaanpa toista avointa työpaikkaa:
- Kokemus korkean kuormituksen järjestelmien rakentamisesta;
- Erinomainen Linux-käyttöjärjestelmän, yleisten järjestelmäohjelmistojen ja verkkopinon tuntemus (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Kokemusta virtualisointijärjestelmistä (KVM, VMWare, LXC/Docker);
- skriptikielien taito;
- Verkkoprotokollaverkkojen toimintaperiaatteiden ymmärtäminen;
- Vikasietoisten järjestelmien rakentamisen periaatteiden ymmärtäminen;
- Itsenäisyys ja oma-aloitteisuus;
Katsotaanpa:
- 1 – vanhempi järjestelmävastaava
- 2 - Riippuen tähän pinoon lisätystä merkityksestä - Keski/Senior System Administrator
- 3 - Työkokemus, mukaan lukien, voi tarkoittaa - "Klusteri ei nostanut, vaan loi ja hallinnoi virtuaalikoneita, oli yksi Docker-isäntä, pääsy säilöihin ei ollut käytettävissä" - Keskijärjestelmänvalvoja
- 4 - Junior System Administrator - kyllä, järjestelmänvalvoja, joka ei osaa kirjoittaa perusautomaatiokomentosarjoja kielestä riippumatta, ei järjestelmänvalvoja - enikey.
- 5 - Keskitason järjestelmänvalvoja
- 6 – vanhempi järjestelmävastaava
Yhteenvetona - Keski / Senior System Administrator
Toinen:
- Devops-kokemus;
- Kokemus yhden tai useamman tuotteen käytöstä CI/CD-prosessien luomiseen. Gitlab CI on eduksi;
- Työskentely säilöjen ja virtualisoinnin kanssa; Jos käytit dockeria, hyvä, mutta jos käytit k8:a, hienoa!
- Kokemusta työskentelystä ketterässä tiimissä;
- Minkä tahansa ohjelmointikielen tuntemus;
Katsotaan:
- 1 - Hmm... Mitä kaverit tarkoittavat? =) Todennäköisesti he eivät itse tiedä, mitä sen takana on piilotettu
- 2 - Rakennusinsinööri
- 3 - Keskitason järjestelmänvalvoja
- 4 - Pehmeä taito, emme ota sitä nyt huomioon, vaikka ketterä on toinen asia, jota tulkitaan sopivalla tavalla.
- 5 - Liian monisanainen - se voi olla skriptikieli tai käännetty kieli. Mietin, sopiiko Pascalilla ja Basicilla kirjoittaminen koulussa heille? =)
Haluaisin myös jättää huomautuksen kohtaan 3 vahvistaakseni ymmärrystä siitä, miksi järjestelmänvalvoja kattaa tämän kohdan. Kubernetes on vain orkestraatio, työkalu, joka kääriä suorat komennot verkkoajureille ja virtualisointi-/eristysisännille muutamaan komentoon ja antaa sinun tehdä kommunikaatiosta niiden kanssa abstraktia, siinä kaikki. Otetaan esimerkiksi 'build framework' Make, jota en muuten pidä kehyksenä. Kyllä, tiedän muotia työntää Makea minne tahansa, missä se on välttämätöntä ja ei tarpeen - esimerkiksi Mavenin kääriminen Makeeseen vakavasti?
Pohjimmiltaan Make on vain kääre kuoren päällä, mikä yksinkertaistaa käännös-, linkitys- ja käännösympäristökomentoja, aivan kuten k8s.
Kerran haastattelin kaveria, joka käytti k8s:a työssään OpenStackin päällä, ja hän kertoi kuinka hän otti palveluita käyttöön siinä, mutta kun kysyin OpenStackista, kävi ilmi, että se oli sekä järjestelmän hallinnoima että nostama. ylläpitäjät. Luuletko todella, että OpenStackin asentanut henkilö ei voi käyttää k8s:a riippumatta siitä, mitä alustaa hän käyttää takanaan? =)
Tämä hakija ei itse asiassa ole DevOps, vaan järjestelmänvalvoja ja tarkemmin sanottuna Kubernetes-järjestelmänvalvoja.
Tehdään vielä yhteenveto - Keski/Senior System Administrator riittää heille.
Kuinka paljon painoa grammoina
Ilmoitettujen työpaikkojen palkkaehdotus on 90 200-XNUMX XNUMX
Nyt haluaisin verrata järjestelmänvalvojien ja DevOps-insinöörien rahapalkintoja.
Periaatteessa asioiden yksinkertaistamiseksi voit hajauttaa arvosanat työkokemuksen perusteella, vaikka tämä ei ole tarkkaa, mutta artikkelin tarkoituksiin se riittää.
Kokemus:
- 3 vuotta asti - Junior
- 6-vuotiaaksi asti - Keski
- yli 6 – Senior
Työntekijähakusivusto tarjoaa:
Järjestelmänvalvojat:
- Juniori - 2 vuotta - 50k hieroa.
- Keski - 5 vuotta - 70k hieroa.
- Seniori - 11 vuotta - 100k hieroa.
DevOps-insinöörit:
- Juniori - 2 vuotta - 100k hieroa.
- Keski - 3 vuotta - 160k hieroa.
- Seniori - 6 vuotta - 220k hieroa.
”DevOpsin” kokemuksen mukaan käytettiin kokemusta, joka ainakin jotenkin vaikutti SDLC:hen.
Yllä olevasta seuraa, että yritykset eivät itse asiassa tarvitse DevOpsia, ja että he voisivat säästää vähintään 50 prosenttia alun perin suunnitelluista kustannuksista palkkaamalla järjestelmänvalvojan, ja lisäksi he voisivat määritellä selkeämmin etsimänsä vastuut. ja täyttää tarpeen nopeammin. Emme saa myöskään unohtaa, että selkeä vastuunjako mahdollistaa päällekkäisyyksien puuttumisen vuoksi henkilöstövaatimusten vähentämisen sekä suotuisamman ilmapiirin luomisen tiimiin. Suurin osa avoimista työpaikoista on täynnä apuohjelmia ja DevOps-tunnisteita, mutta ne eivät perustu todellisiin DevOps-insinöörin vaatimuksiin, vaan vain työkalun järjestelmänvalvojan pyyntöihin.
DevOps-insinöörien koulutusprosessi rajoittuu myös tiettyihin töihin, apuohjelmiin, eikä se tarjoa yleistä käsitystä prosesseista ja niiden riippuvuuksista. On varmasti hyvä, kun henkilö voi ottaa AWS EKS:n käyttöön Terraformilla, yhdessä tämän klusterin Fluentd-sivuvaunun ja lokijärjestelmän AWS ELK-pinon kanssa 10 minuutissa käyttämällä vain yhtä konsolin komentoa, mutta jos hän ei ymmärrä Itse lokien käsittelyn periaate ja mihin niitä tarvitaan, jos et osaa kerätä niistä mittareita ja seurata palvelun huononemista, niin se on silti sama enikey, joka osaa käyttää joitain apuohjelmia.
Kysyntä luo kuitenkin tarjontaa, ja näemme DevOps-asemalle erittäin ylikuumentuneet markkinat, joissa vaatimukset eivät vastaa todellista roolia, vaan antavat vain järjestelmänvalvojille mahdollisuuden ansaita enemmän.
Keitä he ovat? DevOps vai ahneet järjestelmänvalvojat? =)
Kuinka jatkaa elämää?
Työnantajien tulisi muotoilla vaatimuksia tarkemmin ja etsiä juuri niitä, joita tarvitaan, eikä heitellä tarroja. Et tiedä, mitä DevOps tekevät – et tarvitse niitä siinä tapauksessa.
Työntekijät - Opi. Paranna tietämystäsi jatkuvasti, katso kokonaiskuvaa prosesseista ja seuraa polkua tavoitteeseesi. Voit tulla keneksi haluat, sinun täytyy vain yrittää.
Lähde: will.com