DevOps-insenerid ei eksisteeri. Kes siis eksisteerib ja mida sellega teha?

Viimastel aegadel on sellised kuulutused internetti tunginud. Kuigi palk on ahvatlev, ei saa jätta tähelepanuta, et sisu on täielik mööda. Alustuseks eeldatakse, et "DevOps" ja "insener" on mingil moel võimalik kokku sulandada, seejärel järgneb juhuslik nõudmiste nimekiri, millest osa on selgelt kopeeritud süsteemiadministraatori töökuulutusest.

Selles postituses tahaksime rääkida, kuidas me oleme jõudnud sellesse olukorda, mida tegelikult DevOps tähendab ja mida selle kõigega nüüd peale hakata.

Selliseid töökuulutusi võib igati kritiseerida, kuid tõde jääb tõeks: neid on palju ja turg on hetkel selline. Me korraldasime DevOps konverentsi ja kuulutasime avatult: "DevOops — mitte DevOps-inseneridele". Paljudele tundub see kummaline ja jabur: miks inimesed, kes korraldavad täiesti kommertslikku üritust, lähevad turu vastu. Hetkel selgitame kõike.

Kultuurist ja protsessidest

Alustame sellest, et DevOps ei ole inseneriteema. Kõik sai alguse sellest, et ajalooliselt välja kujunenud rollide jagamine ei paranda toote kvaliteeti. Kui programmeerijad teevad vaid programmeerimist, kuid ei hooli testimisest, on tarkvara täis vigu. Kui administraatoritele ei ole oluline, kuidas ja miks tarkvara on kirjutatud, muutub tugi tõeliseks väljakutseks.

Näiteks süsteemiadministraatori ja SRE lähenemise erinevuse kirjeldamine teenuse haldamiseks. algab kuulus Google SRE raamat.Huvitavaid uuringuid on läbi viidud DORA uuringu -st on näha, et parimad arendajad suudavad kuidagi uusi muudatusi tootmisse muita kiiremini kui kord tunnis. Samuti testivad nad käsitsi mitte rohkem kui 10% (see on nähtav eelmisel aastal DORA). Kuidas nad selle saavutavad? "Excel or die" - ütleb üks aruande pealkirju. Süvaanalüüsi jaoks selle statistika testimise osas soovitan pöörduda Baruch Sadogursky pealause poole "Meil on DevOps. Lähme ja vallandame kõik testijad" teisel meie konverentsil, Heisenbug.

"Kui kaaslaste vahel ei ole ühte meelt,
ei viib seda asja paika,
ja sellest ei tule midagi, vaid ainult vaev."
Kunagi oli Luik, Vähk ja Siig…

Kuidas arvate, kui suur hulk veebiarendajatest tõeliselt mõistab, millistes tingimustes nende rakendused tootmises töötavad? Kui palju neist läheb süsteemiadministraatorite juurde ja proovib mõista, mis juhtub andmebaasi kokkuvarisemise korral? Ja kes läheb testijate juurde ja palub õpetada, kuidas korralikult teste kirjutada? Ning seal on veel turvaeksperdid, tootejuhid ja palju teisi inimesi.

DevOpsi peamine idee on luua koostöö erinevate rollide ja osakondade vahel. Esiteks saavutatakse see mitte millegi keerulise tarkvaraga, vaid suhtlemise praktikaga. DevOps on kultuur, praktika, metoodika ja protsessid. Sellist inseneri eriala ei eksisteeri, mis nendele küsimustele vastaks.

Sulgurtsükkel

Kust tuli siis distsipliin nimega "devops-inseneriteadus"? Meil on selle kohta hüpotees! DevOpsi ideed osutusid tõeliselt heaks — sedavõrd heaks, et nad said oma edu ohvriks. Kõikide nende teemade ümber said kokku müüvad värbajad ja inimesed, kellel on väga eriline õhkkond.

Kujutage ette: eile olite Himmkas shawarma valmistamas ja täna olete juba suur inimene, vanem värbaja. Siin on terve kandidaatide otsingu ja valiku protsess, kõik ei ole lihtne, seda tuleb mõista. Oletame, et osakonnajuhataja ütleb: leia spetsialist X. Lisame X-le sõna "insener" ja asi on liikumas. Kas vajalik on Linux? Siis on see kindlalt Linuxi insener, kui soovid DevOps'i — DevOps insener. Töökuulutus ei koosne üksnes pealkirjast, vaid sinna tuleb kirjutada ka mingi tekst. Lihtsaim on kirjutada Googlest leitud võtmesõnade rida, kes palju suudab fantaasiasse panustada. DevOps koosneb kahest sõnast — "Dev" ja "Ops", seega tuleb kokku panna võtmesõnad, mis puudutavad arendajaid ja administraatoreid, kõik ühte hunnikusse. Nii tekivad töökuulutused, mis räägivad 42 programmeerimiskeele valdamisest ja 20 aastat Kubernetes'i ja Swarmi samaaegsest kasutamisest. Tööprotsess.

Nii on inimestes juurdunud mõttetu ja halastamatu kuvand mingist superkangelasest "devopsist", kes seadistab kõigile deploy'd Jenkinsis ja õnne tuleb. Ah, kui kõik oleks nii lihtne. "Ja veel, nii saab jahtida süsteemi administraatoreid," mõtleb HR, "moesõna, võtmesõnad on samad, peaksid sööma minema."

Nõudlus tekitab pakkumise, ja kõikide nende jaburite töökuulutuste peale tõttas hullumeelne hulk süsteemiadministraatoreid, kes taipasid: saab teha kõike nagu varem, aga teenida mitu korda rohkem, nimetades end "devopsideks". Kuidas sa seadistasid servereid läbi SSH käsitsi ükshaaval, teed sa seda edasi, aga nüüd on see justkui devopsi praktika. See on keeruline nähtus, mis on osaliselt seotud klassikaliste adminnide alahindamisega ja DevOpsi ümber toimuva hype'iga, aga kokkuvõttes — mis on, see on.

Nii et meil on nõudlus ja pakkumine. Suletud ring, mis toidab ennast ise. Just selle vastu me võitleme (sealhulgas korraldades DevOops konverentsi).

Ilmselgelt ei ole ainukesed süsteemiadministraatorid, kes on end "devopsideks" ümber nimetanud, ka teisi osalisi — näiteks professionaalsed SRE-d või Infrastructure-as-Code arendajad.

Millega inimesed DevOpsis (tõeliselt) tegelevad

Nii et soovite edeneda DevOpsi praktikate õppimisel ja rakendamisel. Aga kuidas seda teha, millisesse suunda vaadata? Ilmne on, et pimesi järgida populaarseid märksõnu ei tasu.

Kui tööd on, peab keegi sellega tegelema. Oleme juba välja selgitanud, et need ei ole "DevOps-insenerid", siis kes? Tundub, et õigem on seda formuleerida mitte ametite, vaid konkreetsete töövaldkondade kaudu.

Esiteks võib tegeleda DevOpsi südamiku — protsesside ja kultuuriga. Kultuur on aeglane ja keeruline teema, ja kuigi see on traditsiooniliselt juhtide vastutusalas, osalevad selles kõik, alates programmeerijatest kuni administraatoriteni. Paar kuud tagasi ütles Tim Lister intervjuus:

«Kultuur määratleb organisatsiooni põhiväärtused. Inimesed ei pruugi seda tavaliselt märgata, kuid meie, olles kogenud konsultandid, oleme selle märkamisega harjunud. Sa lähed ettevõttesse ja juba mõne minuti pärast hakkad sa tunnetama, mis toimub. Me nimetame seda ‘lõhnaks’. Vahel on see lõhn tõeliselt meeldiv. Vahel aga tekitab see iiveldust. (…) Sa ei saa kultuuri muuta, enne kui ei ole teadlik väärtustest ja uskumustest, mis konkreetseid tegusid juhivad. Käitumist on lihtne jälgida, aga uskumusi on keeruline leida. DevOps on just hea näide sellest, kuidas kõik muutub järjest keerulisemaks.»

On the technical side, of course, there is an issue. If your new code comes for testing after a month, but the release only happens a year later, and it's physically impossible to speed this up — you might never reach good practices. Good practices are supported by good tools. For instance, with the concept of Infrastructure-as-Code in mind, you can use anything from AWS CloudFormation and Terraform to Chef-Ansible-Puppet. You need to know and be able to use all of this, and that is already a proper engineering discipline. It’s important not to confuse cause and effect: first, you work according to SRE principles, and only then implement these principles in the form of specific technical solutions. Moreover, SRE is a very complex methodology that doesn’t just focus on configuring Jenkins but revolves around five key principles:

• Improving interaction between roles and departments
• Accepting mistakes as an integral part of work
• Gradual implementation of changes
• Utilizing tooling and other automation
• Measuring everything that can be measured

This is not just a set of statements but a concrete guide to action. Näiteks vigade tegemise teel tuleb mõista riske, mõõta teenuste kättesaadavust ja kättesaamatust millegagi nagu SLI (teenusetaseme näitajad) ja SLO (teenusetaseme eesmärgid), õppida kirjutama postmortem'i ja teha nii, et nende kirjutamine ei oleks hirmutav.

SRE distsipliinis on tööriistade kasutamine ainult üks osa edust, kuigi see on oluline. Me peame pidevalt tehniliselt arenema, jälgima, mis maailmas toimub ja kuidas seda oma töös rakendada.

Oma korda on Cloud Native lahendused muutunud väga populaarseks. Vastavalt Cloud Native Computing Foundationi tänapäevasele arusaamale võimaldavad Cloud Native tehnoloogiad organisatsioonidel arendada ja käivitada skaleeritavaid rakendusi kaasaegsetes dünaamilistes keskkondades, nagu avalikud, privaatsed ja hübriidpilved. Näiteks võivad tuua konteinerid, teenuste võrgu, mikroteenused, muutumatud infrastruktuurid ja deklaratiivsed API-d. Kõik need tehnikad võimaldavad nõrkade seostega süsteemide jääda elastseks, hallatavaks ja hästi jälgitavaks. Hea automatiseerimine võimaldab inseneridel teha suuri muudatusi tihti ja ettearvatavate tulemustega, muutes selle mitte järjest raskemaks tööks. Kõike seda toetab hulk tuntud tööriistu, nagu Docker ja Kubernetes.

See, et on üsna keeruline ja laialivalguv määratlus, kuna valdkond on samuti keeruline. Ühest küljest väidetakse, et sellele süsteemile uusi muudatusi peaks olema lihtne lisada. Teiselt poolt, et mõista, kuidas luua teatud konteineriseeritud keskkond, kus nõrgalt seotud teenused elavad tarkvaradefinieritud infrastruktuuris ja toimetatakse sinna pideva CI/CD abil, ning ehitada kogu selle ümber DevOps praktikaid — selleks tuleb tõeliselt palju kogemusi omada.

Mida kõigega sellel teha

Igaühel on oma viis nende probleemide lahendamiseks: näiteks võib avaldada korralikke tööpakkumisi, et murda kinni jäänud ring. Võib välja selgitada, mida tähendavad sellised sõnad nagu DevOps ja Cloud Native ning kasutada neid õigesti ja sihipäraselt. Võib areneda DevOpsis ja oma näitega näidata õigeid lähenemisviise.

Meie korraldame konverentsi DevOps 2020 Moskvas, mis pakub võimalust sügavamalt mõista neid teemasid, millest just rääkisime. Selleks on loodud mitu ettekannete gruppi:

• Protsessid ja kultuur;
• Site Reliability Engineering;
• Cloud Native;

Kuidas valida, kuhu minna? Siin on õrn nüanss. Ühelt poolt on DevOps suhtlemine, ja me soovime, et te läheksite ettekannetele erinevatesse plokkidesse. Teiselt poolt, kui olete arenduse juht, kes tuli konverentsile, et keskenduda ühele konkreetsele ülesandele, siis ei piirata teid — ilmselt valite protsesside ja kultuuri ploki. Ärge unustage, et pärast konverentsi jäävad teile salvestised (pärast tagasiside vormi täitmist), seega saate alati hiljem vaadata vähem olulisi ettekandeid.

Ilmselgelt ei saa te konverentsil korraga osaleda kolmes sessioonis, seetõttu oleme programmi koostanud nii, et igas ajavahemikus on teemad igale maitsele.

Jäänud on vaid mõista, mida teha, kui olete DevOps-insener! Esiteks proovige kindlaks teha, millega te tegelikult tegelete. Tavaliselt kasutatakse selle sõna all järgmist:

• Arendajad, kes tegelevad infrastruktuuriga. Teie jaoks sobivad kõige rohkem ettekannete grupid, mis käsitlevad SRE-d ja Cloud Native'i.
• Süsteemiadministraatorite jaoks on asi keerulisem. DevOops ei ole süsteemiadministreerimise konverents. Õnneks on süsteemiadministreerimise teemal palju suurepäraseid konverentse, raamatuid, artikleid, videoid ja muud sarnast. Teisest küljest, kui soovite arendada oma arusaama kultuurist ja protsessidest, õppida pilvetehnoloogiaid ning Cloud Native'i elu üksikasju, siis me tervitame teid! Mõelge sellele: te tegelete haldamisega, aga mis edasi? Et äkitselt ebamugavas olukorras mitte olla, tasub juba praegu õppida.

On veel üks võimalus: te jääte kindlaks ja jätkate väitmist, et olete just DevOps-insener ja mitte kuidagi teisiti, mis iganes see ka tähendaks. Siis sunnime teid pettuma, DevOops ei ole konverents DevOps-inseneridele!

Slide ettekande autor Konstantin Diener Munchenis

DevOops 2020 Moskvas toimub 29.-30. aprillil Moskvas, piletid on juba osta ametlikul veebisaidil.

Lisaks võite esitada oma ettekande kuni 8. veebruarini. Pange tähele, et vormi täitmisel peate valima sihtrühma, kellele teie ettekande toob kõige rohkem kasu (nimekirja sees on peidus üllatus).

Allikas: habr.com