Kes on DevOps?

Praegu on see tõenäoliselt turu kõige kallim positsioon. Müra DevOps inseneride ümber ületab kõik kujuteldavad piirid, ning olukord on veelgi halvem Senior DevOps inseneride osas.
Ma töötan integratsiooni ja automatiseerimise osakonna juhina, arvake ära ingliskeelne lühend — DevOps Manager. Kas ingliskeelne lühend peegeldab meie igapäevaseid ülesandeid — ei, aga vene variant on antud juhul täpsem. Minu töö iseloomust tulenevalt pean ma loomulikult intervjueerima tulevasi tiimiliikmeid, ja möödunud aasta jooksul on minu kaudu käinud umbes 50 inimest, lisaks on sama palju kõrvaldatud minu töötajate esialgsetest intervjuudest.

Meie oleme endiselt kolleegide otsingul, kuna DevOps sildiga peitub väga suur hulk erinevat tüüpi insenere.

Kõik, mis allpool on kirjutatud, on minu isiklik arvamus, te ei pea sellega nõustuma, kuid usun, et see võib teie suhtumist teemasse mõjutada. Võttes arvesse riski jääda halba valgusesse, avaldan oma arvamuse, kuna usun, et sellel on oma koht.

Ettevõtted mõistavad erinevalt, kes on DevOps insenerid ja kiire värbamise nimel riputavad nad selle sildi igasugustele inimestele. Olemuselt on olukord üsna kummaline, kuna ettevõtted on valmis maksma neile uskumatuid hüvesid, saades enamasti selle eest administraator-tööriista.

Kellele siis tegelikult kuuluvad DevOps insenerid?

Alustame ajaloost — Development Operations tekkis veel ühe sammuna, et optimeerida koostööd väikestes meeskondades tootmisprotsessi kiirusel, mis oli oodatud tagajärg. Idee oli selles, et arendustiim saaks tugevdada oma teadmisi tootehalduse protseduuridest ja lähenemistest. Teisisõnu, arendaja peab mõistma, kuidas tema toode erinevates tingimustes töötab, olema teadlik selle toote kasutuselevõtust ja teadma, milliseid keskkonna omadusi kohandada, et parandada jõudlust. Nii tekkis mingi aja pärast DevOps lähenemisega arendajaid. DevOps arendajad kirjutasid kogumise ja pakendamise skripte, et lihtsustada oma tegevust ja tootlikku keskkonda. Siiski, lahenduste arhitektuuri keerukus ja infrastruktuurikomponentide vastastikune mõju hakkasid aja jooksul halvendama keskkondade tööjõudlust; iga iteratsioon nõudis üha sügavamaid teadmisi erinevatest komponentidest, vähendades arendaja tootlikkust, kuna tekkisid lisakulud komponentide mõistmiseks ja süsteemide sätimiseks konkreetse ülesande jaoks. Arendaja enda hind tõusis, toote hind koos sellega; uutele arendajatele meeskonnas esitati äärmiselt kõrgeid nõudmisi, sest neil tuli ka katta

Osaliselt või täielikult, aja jooksul hakkasid need süsteemiadministraatorid aru saama selle konkreetse arendusteami vajadustest, et lihtsustada arendajate ja testijate elu, kuidas rakendada värskendusi ning mitte jääda reedeti ööbima kontorisse, parandades juurutusvigu. Aeg möödus, nüüd said süsteemiadministraatoritest 'staarsed tegijad', kes mõistsid, mida arendajad tahavad. Häirete minimeerimise eesmärgil hakati kasutama haldustooted, meenutati kõiki vanu ja usaldusväärseid OS-taseme isolatsioonimeetodeid, mis võimaldasid minimeerida turvalisuse, võrguhalduse nõudeid ning ka hosti konfiguratsiooni, mis omakorda vähendas uute „staaride” nõudeid.

Ilmus 'suurepärane' asi — docker. Miks on see suurepärane? Ainult sellepärast, et isolatsiooni loomine chroot'is või jail'is, samuti OpenVZ nõudis tõsiseid OS- teadmisi, samas kui tööriist võimaldas lihtsalt luua rakenduste isoleeritud keskuse mingis hostis koos kõikide vajalike elementidega ning anda juhtimise arendusele tagasi, andes süsteemiadministraatorile võimaluse hallata vaid ühte hosti, tagades selle turvalisuse ja kõrge kättesaadavuse — loogiline lihtsustamine. Kuid teadus ei seisa ja süsteemid muutuvad järjest keerulisemaks, komponente on üha rohkem ja rohkem, üks host enam ei rahulda süsteemi vajadusi ja klastreid tuleb ehitada, naaseme jälle süsteemiadministraatorite juurde, kes suudavad neid süsteeme üles ehitada.

Tsüklist tsüklisse ilmnevad erinevad süsteemid, mis lihtsustavad arendust ja/või haldust, ilmuvad orkestreerimissüsteemid, mis on sama kaua, kui ei pea standardprotsessist kõrvale kalduma, lihtsad kasutada. Mikroteenuste arhitektuur ilmnes samuti eesmärgiga lihtsustada kõike ülaltoodut — vähem vastastikuseid seoseid, lihtsam haldamine. Oma kogemuses ei ole ma täielikult näinud mikroteenuste arhitektuuri, ütleksin 50-50 — 50% mikroteenuseid, mustad kastid, mis saadeti sisse, väljund töötlemine, teised 50% — rebestatud monoliit, teenused, mis ei suuda töötada eraldi teistest komponentidest. Kõik see pani taas piiranguid nii arendajate kui ka administraatorite teadmiste tasemele.

Sarnased "kiiged" teatud ressursi ekspertteadmise tasemel kestavad tänaseni. Kuid oleme veidi kõrvale kaldunud, on veel palju asju, mida tasub käsitleda.

Ehitusinsener / Väljalaskeinsener

Äärmiselt kitsas spetsialiseerumine, mis tekkis tarkvaraarenduse ja selle väljalaskmise protsesside standardiseerimise vahendina. Agile'i laialdase sisseviimise tõttu näis, et neist on saanud vähem nõutud, kuid see on kaugel tõest. See spetsialiseerumine tekkis just tarkvaraarenduse ja tarne standardiseerimise vahendina tööstuslikus mastaabis, s.t. kasutades kõigi ettevõtte toodete jaoks standardpäraseid tehnikaid. DevOps'i tekkimisega kaotasid arendajad osaliselt oma ülesandeid, kuna just nemad hakkasid tootetarnet ette valmistama. Muutuvate infrastruktuuri ja lähenemisviisi tõttu maksimaalselt kiirele tarnimisele, ilma kvaliteedi peale mõtlemata, muundusid nad ajaga justkui muudatuste piduriteks, kuna kvaliteedistandardite järgimine aeglustab paratamatult tarnet. Nii on järk-järgult osa Build / Release inseneride funktsioonidest langenud süsteemsete administraatorite õlgadele.

Ops’id on nii erinevad

Liigume edasi ja taas, suur hulk kohustusi ja kvalifitseeritud töötajate puudus sunnib meid ranged spetsialiseerumised välja töötama nagu seened pärast vihma, ilmuvad erinevad Operations:

• TechOps — süsteemsed administraatorid ehk HelpDesk insenerid
• LiveOps — süsteemsed administraatorid, kes vastutavad peamiselt tootmisälade eest
• CloudOps — süsteemsed administraatorid, kes on spetsialiseerunud avalikele pilvedele, nagu Azure, AWS, GCP jne.
• PlatOps / InfraOps / SysOps — infrastruktuuri süsteemsed administraatorid.
• NetOps — võrguadministraatorid
• SecOps — süsteemsed administraatorid, kes on spetsialiseerunud infotehnoloogia turvalisusele — PCI vastavus, CIS vastavus, plaastrid jne.

DevOps — is a person who understands the entire development cycle processes in theory — development, testing, understands product architecture, able to assess security risks, familiar with automation approaches and tools, at least at a high level, and also understands pre- and post-release product support. This person can act as an advocate for both Operations and Development, enabling favorable collaboration between these two pillars. They comprehend the processes of work planning by teams and management of client expectations.

To perform such work and duties, this person must have the means to manage not only the processes of development and testing but also the management of product infrastructure and resource planning. In this understanding, a DevOps cannot be in IT, R&D, or even PMO; they must have influence in all these areas — a company's technical director, Chief Technical Officer.

Is this the case in your company? — I doubt it. In most cases, it is either IT or R&D.

The lack of means and the ability to influence at least one of these three areas of activity will shift the weight of issues towards where these changes can be applied more easily, such as imposing technical constraints on releases due to 'dirty' code according to static analysis systems. That is, when PMO sets a strict deadline for delivering functionality, R&D cannot provide a quality outcome within that timeframe and delivers what it can, leaving refactoring for later, while DevOps related to IT technically blocks the release. The lack of authority to change the situation, in the case of responsible employees, leads to hyper-responsibility for what they cannot influence, especially if these employees understand and see mistakes and how to fix them — 'Happiness is ignorance,' and consequently leads to burnout and loss of these employees.

DevOps resources market

Let's take a look at several DevOps job openings from different companies.

We are ready to meet with you if you:

1. Are proficient in Zabbix and know what Prometheus is;
2. Iptables;
3. BASH enthusiast;
4. Ansible professor;
5. Linux guru;
6. Kas oskate kasutada debugimise tööriistu ja koos arendajatega tuvastada rakenduseprobleeme (php/java/python);
7. Routimine ei tekita teile paanikat;
8. Pöörate märkimisväärset tähelepanu süsteemi turvalisusele;
9. Teete varukoopiaid "kõigest ja kõigist" ning taastate edukalt "kõike ja kõiki";
10. Osate süsteemi seadistada nii, et maksimeerida minimaalset;
11. Seate enne magamaminekut replikatsioonid Postgresi ja MySQL-i jaoks;
12. CI/CD seadistamine ja kohandamine on teie jaoks hädavajalik nagu hommikusöök/lõunasöök/õhtusöök.
13. Omate kogemusi AWS-iga;
14. Olete valmis koos ettevõttega arenema;

Nii:

• alates 1 kuni 6 — süsteemiadministraator
• 7 — veidi võrguhaldust, mis sobib samuti kesktaseme sysadmini profiili
• 8 — veidi turvalisust, mis on olemasoleva kesktaseme sysadmini jaoks hädavajalik
• 9-11 — Kesktaseme süsteemiadministraator
• 12 — Sõltuvalt seatud ülesannetest kas kesktaseme süsteemiadministraator või Build Engineer
• 13 — virtualiseerimine — kesktaseme süsteemiadministraator või nn CloudOps, süvendatud teadmised just konkreetsete teenuste kohta hostimine platvormi jaoks, et efektiivselt kasutada rahalisi vahendeid ja vähendada hoolduskulu

Kokkuvõttes võib selle tööpakkumise kohta öelda, et noortele piisab kesktaseme/seniori süsteemiadministraatori kogemustest.

Muide, ei ole mõtet liiga rangelt jagada administreerijaid Linuxi/Windowsi põhjal. Ma mõistan, et nende kahe maailma teenused ja süsteemid on erinevad, kuid alused on siiski ühed ja iga endaga arvestav administraator on tuttav mõlemaga, ja isegi kui ta pole tuttav, siis ei tohiks arvestava administraatori jaoks olla raske selle teadmise omandamine.

Vaatame teist tööpakkumist:

1. Kogemus kõrge koormusega süsteemide ehitamisel;
2. Suurepärased teadmised Linuxi operatsioonisüsteemist, süsteemitarkvarast ja veebitehnoloogiast (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Kogemus virtualiseerimissüsteemidega (KVM, VMWare, LXC/Docker);
4. Keskendumine skriptimiskeelte valdamisele;
5. Arusaam võrguprotokollide tööpõhimõtetest;
6. Arusaam talitlushäiretega süsteemide rajamise põhimõtetest;
7. Iseseisvus ja algatusvõime;

Arvutame läbi:

• 1 — vanem süsteemiadministraator
• 2 — Sõltuvalt sellest, mida selle stack-i mõttes silmas peetakse — kesktaseme/seniori süsteemiadministraator
• 3 — Kogemus, sealhulgas, võib tähendada — "Klastri ülesseadmata, kuid virtuaalmasinate loomine ja haldamine, üks Docker host, juurdepääs konteineritele natakas" — kesktaseme süsteemiadministraator
• 4 — Noorem süsteemiadministraator — jah, administraator, kes ei oska kirjutada elementaarseid automatiseerimise skripte, olenemata keelest, ei ole administraator — tehniline spetsialist.
• 5 — Keskmine süsteemiadministraator
• 6 — Vanem süsteemiadministraator

Kokkuvõttes — Keskmine/Vanem süsteemiadministraator

Veel üks:

1. DevOps-i kogemus;
2. Kogemus ühe või mitme toote kasutamisel CI/CD protsesside loomisel. Gitlab CI on eelis;
3. Töö konteinerite ja virtualiseerimisega; Kui olete kasutanud dockerit – hea, aga kui k8s – suurepärane!
4. Kogemus agile-meeskonnas;
5. Tundmine mistahes programmeerimiskeelt;

Vaadakem:

• 1 — Hmm… Mida poisid silmas peavad? =) Tõenäoliselt ei tea nad isegi, mis selle taga peitub
• 2 — Ehitusinsener
• 3 — Keskmine süsteemiadministraator
• 4 — Pehmed oskused, neid ei arutada praegu, kuigi Agile on veel üks asi, mida tõlgendatakse nii, nagu on mugav.
• 5 — Liialt ebamugav — see võib olla skriptikeel või kompileeritud keel. Huvitav, kas Pascal ja Basic, millega koolis kirjutati, sobivad neile? =)

Sooviksin teha märkuse seoses 3. punktiga, et tugevdada arusaamist, miks seda punkti katab süsteemiadministraator. Kubernetes on lihtsalt orkestreerimine, tööriist, mis pakub abstraktset suhtlust võrgudraiverite ja virtualiseerimise/isolatsiooni hostidega, ühendades otsekäsklusi paariks käsuks, ja see on kõik. Näiteks võetagu 'ehituse raamistik' Make, mida ma, muide, raamistikuks ei pea. Jah, ma tean moest pookida Make igale poole, kus seda vajalik ja mittetäielik — näiteks, kuidas muuta Maven Make'iks, tõsiselt?
Sisuliselt on Make lihtsalt shelli käsuvorm, mis lihtsustab kompilatsioonikäske, linkimist, kompilatsiooni keskkonda, täpselt nagu k8s.

Kunagi vestlesin poisiga, kes kasutas k8s oma töös OpenStacki peal, ja ta rääkis, kuidas ta teenuseid seal juurutab, kuid kui küsimus selle kohta, kuidas OpenStacki haldada, tuli, selgus, et seda haldavad süsteemiadministraatorid. Kas te tõesti arvate, et inimene, kes käivitas OpenStacki, olenemata sellest, millist platvormi ta taga kasutab, ei suuda kasutada k8s-i? =)
Tegelikult ei ole see kandidaat DevOps, vaid sama süsteemiadministraator ja, et olla täpsem, Kubernetes Administraator.

Kokkuvõttes — Keskmine/Vanem süsteemiadministraator on piisav.

Kui palju kaaluda grammides

Pakutud palgavahemik antud ametikohtade jaoks — 90k-200k
Nüüd sooviksin tuua paralleeli süsteemi administraatorite ja DevOps inseneride rahaliste preemiate vahel.

Põhimõtteliselt võib kogemustepõhised astmed jaotada, kuigi see ei ole täpne, artikkel on piisav selleks.

Kogemus:

1. kuni 3 aastat — Junior
2. kuni 6 aastat — Middle
3. üle 6 aasta — Senior

Töötajate otsimise veebisait pakub:
Süsteemi administraatorid:

1. Junior — 2 aastat — 50k rub.
2. Middle — 5 aastat — 70k rub.
3. Senior — 11 aastat — 100k rub.

DevOps insenerid:

1. Junior — 2 aastat — 100k rub.
2. Middle — 3 aastat — 160k rub.
3. Senior — 6 aastat — 220k rub.

DevOps'i kogemust arvestati igasuguse SDLC-ga seotud ajaga.

Ülaltoodust järeldub, et tegelikult ei vaja ettevõtted DevOps'e, ning nad oleksid võinud säästa vähemalt 50 protsenti algselt planeeritud kuludest, palgates hoopis administraatori; ning nad oleksid võinud selgelt määratleda otsitava isiku ülesanded ja kiiremini oma vajaduse täita. Samuti ei tohi unustada, et selge vastutuse jagamine vähendab töötajate nõudmisi ja loob kollektiivis sobivama atmosfääri, sest kattuvusi pole. Enamik tööpakkumisi on aga täis utiliite ja DevOps'i silte, kuid neil pole tõeliselt nõudeid DevOps inseneri kohta, vaid tegemist on tööriistade administraatori nõudmistega.

DevOps inseneride koolitusprotsess on samuti piiratud ainult spetsiifiliste tööde, utiliitide kogumiga, mis ei anna ülevaadet protsessidest ja nende sõltuvustest. Kindlasti on hea, kui inimene oskab kasutada Terraform'i AWS EKS-i juurutamiseks, koos Fluentd sidecar'iga selles klastris ja AWS ELK stack'iga logimise süsteemi jaoks 10 minutiga, kasutades vaid ühte käsku konsoolis, aga kui ta ei mõista logide töötlemise põhimõtet ja milleks need vajalikud on, ei tea, kuidas neid jälgida ja teenuse halvenemist tuvastada, siis on ta lihtsalt tehnik, kes oskab mõningaid utiliite kasutada.

Küll aga toob nõudlus kaasa pakkumise ja me näeme ülemäära ülekuumenenud DevOps positsioonide turgu, kus nõudmised ei vasta tegelikule rollile ja võimaldavad ainult süsteemiadministraatoritel rohkem teenida.

Nii et kes nad on? DevOps'id või ahned süsteemiadministraatorid? =)

Kuidas edasi elada?

Tööandjatele – sõnastada nõudmised täpsemalt ja otsida just neid, kes on vajalikud, mitte laiali pillata silte. Te ei tea, millega DevOps tegeleb – nemad ei ole teie jaoks vajalikud.

Töötajatele – õppida. Jätkata oma teadmiste täiendamist, vaadata laiemat ülevaadet protsessidest ja jälgida teed seatud eesmärgini. Võite saada kelleks iganes, peate vaid pingutama.

Allikas: habr.com