Op it stuit is dit hast de djoerste posysje op 'e merk. De ophef om "DevOps"-yngenieurs is boppe alle tinkbere grinzen, en noch slimmer mei Senior DevOps-yngenieurs.
Ik wurkje as haad fan 'e ôfdieling yntegraasje en automatisearring, tink de Ingelske dekodearring - DevOps Manager. It is net wierskynlik dat it Ingelske transkripsje ús deistige aktiviteiten wjerspegelet, mar de Russyske ferzje yn dit gefal is krekter. Fanwegen de aard fan myn aktiviteit is it natuerlik dat ik takomstige leden fan myn team ynterviewje moat, en yn 't ôfrûne jier binne sawat 50 minsken troch my trochgien, en itselde oantal is ôfsnien op prescreen mei myn meiwurkers.
Wy binne noch op syk nei kollega's, om't efter it DevOps-label in heul grutte laach fan ferskate soarten yngenieurs skûlet.
Alles dat hjirûnder skreaun is is myn persoanlike miening, jo hoege it net mei iens te wêzen, mar ik jou ta dat it wat kleur sil jaan oan jo hâlding foar it ûnderwerp. Nettsjinsteande it risiko om út 'e foardiel te fallen, publisearje ik myn miening om't ik leau dat it in plak hat om te wêzen.
Bedriuwen hawwe ferskillende begripen fan wa't DevOps-yngenieurs binne en, om't se fluch in boarne ynhierje, hingje se dit label oan elkenien. De situaasje is hiel frjemd, om't bedriuwen ree binne om unrealistyske fergoedingen te beteljen oan dizze minsken, en ûntfange, yn 'e measte gefallen, in arkbehearder foar har.
Dus wa binne DevOps-yngenieurs?
Litte wy begjinne mei de skiednis fan har uterlik - Untwikkelingsoperaasjes ferskynden as in oare stap nei it optimalisearjen fan ynteraksje yn lytse teams om de snelheid fan produktproduksje te ferheegjen, as in ferwachte konsekwinsje. It idee wie om it ûntwikkelteam te fersterkjen mei kennis fan prosedueres en oanpak by it behearen fan de produktomjouwing. Mei oare wurden, de ûntwikkelder moat begripe en witte hoe't syn produkt wurket yn bepaalde betingsten, moat begripe hoe't syn produkt kin ynsette, hokker skaaimerken fan 'e omjouwing kinne wurde oanpast om prestaasjes te ferbetterjen. Dat, in skoft, ferskynden ûntwikkelders mei in DevOps-oanpak. DevOps-ûntwikkelders skreau bouw- en ferpakkingsskripts om har aktiviteiten en de prestaasjes fan 'e produksjeomjouwing te ferienfâldigjen. De kompleksiteit fan 'e oplossingsarsjitektuer en de ûnderlinge ynfloed fan ynfrastruktuerkomponinten yn' e rin fan 'e tiid begon lykwols de prestaasjes fan' e omjouwings te ferleegjen; mei elke iteraasje wie in hieltyd djipper begryp fan bepaalde komponinten nedich, wat de produktiviteit fan 'e ûntwikkelder fermindere fanwegen de ekstra kosten foar it begripen fan de komponinten en tuningsystemen foar in spesifike taak. . De eigen kosten fan de ûntwikkelder groeiden, de kosten fan it produkt tegearre mei it, de easken foar nije ûntwikkelders yn it team sprongen skerp, om't se ek de ferantwurdlikheden fan 'e ûntwikkeling "stjer" moasten dekke en, fansels, de "stjerren" waarden minder en minder beskikber. It is ek de muoite wurdich op te merken dat, yn myn ûnderfining, in pear ûntwikkelders ynteressearre binne yn 'e spesifikaasjes fan pakketferwurking troch de kernel fan it bestjoeringssysteem, regels foar pakketrouting, en aspekten fan hostfeiligens. De logyske stap wie om in behearder te lûken dy't dit bekend is en him ferlykbere ferantwurdlikheden tawize, dy't, troch syn ûnderfining, it mooglik makke om deselde yndikatoaren te berikken tsjin in legere kosten yn ferliking mei de kosten fan in "stjer" ûntwikkeling. Sokke behearders waarden yn in team pleatst en syn haadtaak wie om test- en produksjeomjouwings te behearjen, neffens de regels fan in spesifyk team, mei middels tawiisd oan dit bepaalde team. Dit is hoe't, yn feite, DevOps ferskynde yn 'e tinzen fan' e mearderheid.
Foar in part of folslein, yn 'e rin fan' e tiid, begûnen dizze systeembehearders de behoeften fan dit bepaalde team te begripen op it mêd fan ûntwikkeling, hoe it libben makliker te meitsjen foar ûntwikkelders en testers, hoe't jo in update útrolje en net hoege te oernachtsjen op freed yn it kantoar, korrigearje ynset flaters. De tiid gie troch, en no wiene de "stjerren" systeembehearders dy't begrepen wat ûntwikkelders woene. Om de ynfloed te minimalisearjen, begûnen behearprogramma's op te kommen; elkenien ûnthâlde de âlde en betroubere metoaden foar it isolearjen fan it OS-nivo, wat it mooglik makke om de easken foar feiligens, it behear fan it netwurkdiel, en de hostkonfiguraasje as in minimum te minimalisearjen. gehiel en, as gefolch, ferminderje de easken foar nije "stjerren".
In "prachtige" ding is ferskynd - docker. Wêrom prachtich? Ja, allinich om't it meitsjen fan isolaasje yn in chroot of finzenis, lykas OpenVZ, net-triviale kennis fan it OS fereasket, yn tsjinstelling, it nut lit jo gewoan in isolearre applikaasjeomjouwing meitsje op in bepaalde host mei alles dat nedich is binnen en hân oer de teugels fan ûntwikkeling wer, en de systeembehearder kin allinnich beheare mei mar ien host, garandearje syn feiligens en hege beskikberens - in logyske ferienfâldiging. Mar de foarútgong stiet net stil en systemen wurde wer komplekser, der binne hieltyd mear komponinten, ien host foldocht net mear oan de behoeften fan it systeem en it is nedich om klusters te bouwen, wy geane wer werom nei systeembehearders dy't binne by steat om te bouwen dizze systemen.
Syklus nei syklus ferskine ferskate systemen dy't de ûntwikkeling en/of administraasje ferienfâldigje, orkestraasjesystemen ferskine, dy't, oant jo moatte ôfwike fan it standertproses, maklik te brûken binne. Microservice-arsjitektuer ferskynde ek mei it doel om alles hjirboppe beskreaun te ferienfâldigjen - minder relaasjes, makliker te behearjen. Yn myn ûnderfining fûn ik gjin folslein mikroservicearsjitektuer, ik soe sizze 50 oant 50 - 50 prosint fan mikrotsjinsten, swarte doazen, kamen yn, kamen út ferwurke, de oare 50 binne in torn monolith, tsjinsten kinne net apart wurkje fan oare komponinten. Dit alles sette wer beheiningen op it nivo fan kennis fan sawol ûntwikkelders as behearders.
Fergelykbere "swings" yn it nivo fan saakkundige kennis fan in bepaalde boarne bliuwe oant hjoed de dei. Mar wy dwaen in bytsje ôf, d'r binne in protte punten dy't it wurdich binne om te markearjen.
Build Engineer / Release Engineer
Hiel heech spesjalisearre yngenieurs dy't ûntstienen as in middel foar standerdisearring fan softwarebouprosessen en releases. Yn it proses fan it yntrodusearjen fan wiidferspraat Agile soe it lykje dat se net mear yn fraach wiene, mar dit is fier fan it gefal. Dizze spesjalisaasje ferskynde as in middel om de gearstalling en levering fan software op yndustriële skaal te standerdisearjen, d.w.s. mei help fan standert techniken foar alle bedriuw produkten. Mei de komst fan DevOps ferlearen ûntwikkelders har funksjes foar in part, om't it de ûntwikkelders wiene dy't it produkt begûnen ta te rieden foar levering, en sjoen de feroarjende ynfrastruktuer en de oanpak om sa rap mooglik te leverjen sûnder each foar kwaliteit, waarden se yn 'e rin fan' e tiid yn in stopper fan feroaringen, om't it oanhâlden fan kwaliteitsnoarmen ûnûntkomber fertraget leveringen. Dat, stadichoan, in diel fan 'e funksjonaliteit fan Build / Release-yngenieurs migrearre nei de skouders fan systeembehearders.
Ops binne sa oars
Wy geane op en wer de oanwêzigens fan in grut oanbod fan ferantwurdlikheden en it gebrek oan kwalifisearre personiel triuwt ús nei strange spesjalisaasje, lykas paddestoelen nei rein, ferskate operaasjes ferskine:
- TechOps - enikey systeembehearders aka HelpDesk Engineer
- LiveOps - systeembehearders primêr ferantwurdlik foar produksjeomjouwings
- CloudOps - systeembehearders spesjalisearje yn iepenbiere wolken Azure, AWS, GCP, ensfh.
- PlatOps/InfraOps/SysOps - ynfrastruktuer systeembehearders.
- NetOps - netwurkbehearders
- SecOps - systeembehearders spesjalisearre yn ynformaasjefeiligens - PCI-neilibjen, CIS-neilibjen, patching, ensfh.
DevOps is (yn teory) in persoan dy't alle prosessen fan 'e ûntwikkelingssyklus út 'e earste hân begrypt - ûntwikkeling, testen, begrypt de produktarsjitektuer, is yn steat om feiligensrisiko's te beoardieljen, is bekend mei oanpak en automatisearringsynstruminten, teminsten op in hege nivo nivo, neist dit, ek begrypt pre- en post-ferwurking. produkt release stipe. In persoan dy't by steat is om te fungearjen as advokaat foar sawol operaasjes as ûntwikkeling, wat in geunstige gearwurking mooglik makket tusken dizze twa pylders. Begrypt de prosessen fan planningswurk troch teams en it behearen fan klantferwachtingen.
Om dit soarte wurk en ferantwurdlikheden út te fieren, moat dizze persoan de middels hawwe om net allinich de ûntwikkelings- en testprosessen te behearjen, mar ek it behear fan 'e produktynfrastruktuer, lykas boarneplanning. DevOps yn dit begryp kinne net lizze yn IT, noch yn R&D, of sels yn 'e PMO; it moat ynfloed hawwe op al dizze gebieten - de technyske direkteur fan it bedriuw, Chief Technical Officer.
Is dit wier yn jo bedriuw? - Ik twifelje. Yn 'e measte gefallen is dit of IT as R&D.
Gebrek oan fûnsen en mooglikheid om te beynfloedzjen op syn minst ien fan dizze trije gebieten fan aktiviteit sil ferskowe it gewicht fan problemen nei wêr't dizze feroarings binne makliker te passen, lykas it tapassen fan technyske beheinings op releases yn ferbân mei "smoarge" koade neffens statyske analyzer systemen. Dat is, as de PMO in strikte deadline stelt foar de frijlitting fan funksjonaliteit, R&D kin gjin resultaat fan hege kwaliteit produsearje binnen dizze deadlines en produsearret it sa goed it kin, wêrtroch refactoring foar letter lit, DevOps relatearre oan IT blokkearret de frijlitting mei technyske middels . Gebrek oan autoriteit om de situaasje te feroarjen, yn it gefal fan ferantwurdlike meiwurkers, liedt ta de manifestaasje fan hyperferantwurdlikens foar wat se net kinne beynfloedzje, benammen as dizze meiwurkers flaters begripe en sjogge, en hoe't se se korrigearje - "Bliss is ûnwittendheid", en as gefolch fan burn-out en ferlies fan dizze meiwurkers.
DevOps boarne merk
Litte wy nei ferskate fakatueres sjen foar DevOps-posysjes fan ferskate bedriuwen.
Wy binne ree om jo te treffen as jo:
- Jo besite Zabbix en witte wat Prometheus is;
- Iptables;
- BASH PhD Studint;
- professor Ansible;
- Linux Guru;
- Witte hoe't jo debuggen brûke en applikaasjeproblemen fine tegearre mei ûntwikkelders (php/java/python);
- Routing makket jo net hysterysk;
- Wês wichtich omtinken foar systeemfeiligens;
- Reservekopy fan "alles en alles", en ek mei súkses werstelle dizze "alles en alles";
- Jo witte hoe't jo it systeem op sa'n manier konfigurearje om it maksimum út it minimum te heljen;
- Replikaasje ynstelle foardat jo op bêd gean op Postgres en MySQL;
- It opsetten en oanpassen fan CI / CD is sa nedich foar jo as moarnsiten / lunch / diner.
- Hawwe ûnderfining mei AWS;
- Klear om te ûntwikkeljen mei it bedriuw;
Dus:
- fan 1 oan 6 - systeembehearder
- 7 - in bytsje netwurk administraasje, dy't ek past yn de systeembehearder, Midden nivo
- 8 - in bytsje feiligens, dat is ferplichte foar in middelste nivo systeembehearder
- 9-11 - Middelste systeembehearder
- 12 - Ofhinklik fan 'e tawiisde taken, middensysteembehearder of bouwingenieur
- 13 - Virtualisaasje - Middelste systeembehearder, of de saneamde CloudOps, avansearre kennis fan 'e tsjinsten fan in spesifike hostingside, foar it effisjint gebrûk fan fûnsen en it ferminderjen fan de lêst op ûnderhâld
Gearfetsjend dizze fakatuere, kinne wy sizze dat Midden / Senior Systeembehearder is genôch foar de jonges.
Trouwens, jo moatte behearders net sterk ferdielen op Linux / Windows. Fansels begryp ik dat de tsjinsten en systemen fan dizze twa wrâlden ferskillend binne, mar de basis foar alles is itselde en elke selsrespektearjende admin is bekend mei sawol de iene as de oare, en sels as hy net fertroud is, sil it net lestich wêze foar in foechhawwende admin om der bekend mei te wurden.
Litte wy in oare fakatuere beskôgje:
- Underfining yn it bouwen fan hege-load systemen;
- Prachtige kennis fan Linux OS, algemiene systeemsoftware en webstack (Nginx, PHP / Python, HAProxy, MySQL / PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Underfining mei virtualisaasjesystemen (KVM, VMWare, LXC / Docker);
- Behearsking yn skripttalen;
- Begryp fan 'e bestjoeringsprinsipes fan netwurkprotokolnetwurken;
- Begryp fan 'e prinsipes fan it bouwen fan fout-tolerante systemen;
- Unôfhinklikens en inisjatyf;
Litte wy sjen nei:
- 1 - Senior Systeembehearder
- 2 - Ofhinklik fan 'e betsjutting set yn dizze stack - Midden / Senior Systeembehearder
- 3 - Wurkûnderfining, ynklusyf, kin betsjutte - "It kluster hat net opheven, mar makke en beheard firtuele masines, d'r wie ien Docker-host, tagong ta konteners wie net beskikber" - Middelste systeembehearder
- 4 - Junior systeembehearder - ja, in admin dy't net wit hoe't jo basale automatisearringsskripts skriuwe moatte, nettsjinsteande de taal, gjin admin - enikey.
- 5 - Middelste systeembehearder
- 6 - Senior Systeembehearder
Om gearfetsje - Midden / Senior Systeembehearder
Noch ien:
- Devops ûnderfining;
- Underfining yn it brûken fan ien of mear produkten om CI / CD-prosessen te meitsjen. Gitlab CI sil in foardiel wêze;
- Wurkje mei konteners en virtualisaasje; As jo docker brûkten, goed, mar as jo k8s brûkten, geweldich!
- Underfining fan wurkjen yn in agile team;
- Kennis fan elke programmeartaal;
Litte wy sjen:
- 1 - Hmm... Wat bedoele de jonges? =) Meast wierskynlik witte se sels net wat der efter ferburgen is
- 2 - Build Engineer
- 3 - Middelste systeembehearder
- 4 - Sêfte feardigens, wy sille it no net beskôgje, hoewol Agile is in oar ding dat wurdt ynterpretearre op in manier dy't handich is.
- 5 - Te verbose - it kin in skripttaal wêze as in kompilearre taal. Ik freegje my ôf oft it skriuwen yn Pascal en Basic op skoalle by harren past? =)
Ik soe ek graach in notysje litte oer punt 3 om it begryp te fersterkjen wêrom't dit punt wurdt behannele troch de systeembehearder. Kubernetes is gewoan in orkestraasje, in ark dat direkte kommando's omkeart nei netwurkbestjoerders en hosts foar virtualisaasje / isolaasje yn in pear kommando's en lit jo kommunikaasje mei har abstrakt meitsje, dat is alles. Bygelyks, lit ús nimme 'build framework' Make, dat, troch de wei, ik beskôgje gjin kader. Ja, ik wit oer de moade om Make oeral te skowen, wêr't it nedich is en net nedich - Maven yn Make, bygelyks serieus ynpakke?
Yn essinsje is Make gewoan in wrapper oer de shell, it ferienfâldigjen fan de kompilaasje-, keppelings- en kompilaasjeomjouwingskommando's, krekt as k8s.
Ien kear haw ik in keardel ynterviewd dy't k8s brûkte yn syn wurk boppe op OpenStack, en hy spruts oer hoe't hy tsjinsten dêrop ynset, lykwols, doe't ik frege oer OpenStack, die bliken dat it waard administreare, lykas opwekke troch systeem behearders. Tinke jo wirklik dat in persoan dy't OpenStack hat ynstalleare, nettsjinsteande hokker platfoarm hy efter him brûkt, gjin k8s kin brûke? =)
Dizze oanfreger is eins gjin DevOps, mar in systeembehearder en, om krekter te wêzen, in Kubernetes-behearder.
Lit ús nochris gearfetsje - Midden / Senior Systeembehearder sil genôch wêze foar har.
Hoefolle te weagjen yn grammen
It berik fan foarstelde salarissen foar de oantsjutte fakatueres is 90k-200k
No wol ik in parallel tekenje tusken de monetêre beleanningen fan Systeembehearders en DevOps Engineers.
Yn prinsipe, om dingen te ferienfâldigjen, kinne jo de rangen ferspriede op basis fan wurkûnderfining, hoewol dit net krekt wêze sil, mar foar it doel fan it artikel sil it genôch wêze.
In ûnderfining:
- oant 3 jier - Junior
- oant 6 jier âld - Midden
- mear as 6 - Senior
De sykside foar wurknimmers biedt:
Systeembehearders:
- Junior - 2 jier - 50k rub.
- Midden - 5 jier - 70k rub.
- Senior - 11 jier - 100k rub.
DevOps Engineers:
- Junior - 2 jier - 100k rub.
- Midden - 3 jier - 160k rub.
- Senior - 6 jier - 220k rub.
Neffens de ûnderfining fan "DevOps", waard ûnderfining brûkt dy't op syn minst ien of oare manier de SDLC beynfloede.
Ut it boppesteande folget dat bedriuwen feitlik gjin DevOps nedich hawwe, en ek dat se op syn minst 50 prosint fan 'e ynearsten plande kosten kinne besparje troch in behearder yn te hieren; boppedat koene se de ferantwurdlikheden dúdliker definiearje fan 'e persoan dy't se sykje en folje de need flugger. Wy moatte ek net ferjitte dat in dúdlike ferdieling fan ferantwurdlikheden ús mooglik makket om de easken foar personiel te ferminderjen, en ek in geunstigere sfear yn it team te meitsjen, troch it ûntbrekken fan oerlappingen. De grutte mearderheid fan fakatueres is fol mei nutsbedriuwen en DevOps-labels, mar se binne net basearre op werklike easken foar in DevOps Engineer, allinich fersiken foar in arkbehearder.
It proses fan it oplieden fan DevOps-yngenieurs is ek allinich beheind ta in set fan spesifike wurken, nutsbedriuwen, en leveret gjin algemien begryp fan 'e prosessen en har ôfhinklikens. It is grif goed as in persoan AWS EKS kin ynsette mei Terraform, yn kombinaasje mei de Fluentd-sidecar yn dit kluster en de AWS ELK-stapel foar it logsysteem yn 10 minuten, mei mar ien kommando yn 'e konsole, mar as hy it net begrypt prinsipe fan it ferwurkjen fan harsels logs en wêr't se foar nedich binne, as jo net witte hoe't jo metriken op har sammelje en de degradaasje fan 'e tsjinst folgje, dan sil it noch altyd deselde enikey wêze dy't wit hoe't jo guon nutsbedriuwen kinne brûke.
De fraach skept lykwols oanbod, en wy sjogge in ekstreem oververhitte merk foar de DevOps-posysje, wêr't de easken net oerienkomme mei de eigentlike rol, mar allinich systeembehearders mear fertsjinje kinne.
Dus wa binne se? DevOps of gierige systeembehearders? =)
Hoe fierder te libjen?
Wurkjouwers moatte easken krekter formulearje en sykje nei krekt dyjingen dy't nedich binne, en net etiketten omsmite. Jo witte net wat DevOps dogge - jo hawwe se yn dat gefal net nedich.
Arbeiders - Learje. Ferbetterje jo kennis konstant, besjoch it algemiene byld fan prosessen en folgje it paad nei jo doel. Jo kinne wurde wa't jo wolle, jo moatte gewoan besykje.
Boarne: www.habr.com