Viimasel ajal on sellised reklaamid internetti üle ujutanud. Hoolimata meeldivast palgast ei saa olla piinlik, et sees on kirjutatud metsik ketserlus. Esialgu eeldatakse, et “DevOps” ja “insener” saab kuidagi üheks sõnaks kokku liimida, ja siis tekib suvaline nõuete loetelu, millest osa on selgelt kopeeritud sysadmini vabast töökohast.
Selles postituses tahaksin veidi rääkida sellest, kuidas me selle elupunktini jõudsime, mis DevOps tegelikult on ja mida sellega nüüd peale hakata.
Selliseid vabu töökohti võib igal võimalikul moel hukka mõista, kuid fakt jääb faktiks: neid on palju ja nii turg praegu toimib. Pidasime devopsi konverentsi ja kuulutasime avalikult: " - mitte DevOpsi inseneridele." See tundub paljudele kummaline ja metsik: miks inimesed, kes teevad täiesti kommertsüritust, lähevad turule vastu. Nüüd selgitame kõike.
Kultuurist ja protsessidest
Alustame sellest, et DevOps ei ole inseneriteadus. Kõik sai alguse sellest, et ajalooliselt väljakujunenud rollijaotus ei tööta toodete kvaliteedi nimel. Kui programmeerijad ainult programmeerivad, kuid ei taha testimisest midagi kuulda, on tarkvara täis vigu. Kui administraatorid ei hooli sellest, kuidas või miks tarkvara on kirjutatud, muutub tugi põrguks.
Näiteks kirjeldades erinevust süsteemiadministraatori ja SRE lähenemisviisi vahel teenusehalduses . Sees on tehtud huvitavaid uuringuid — on selge, et parimatel arendajatel õnnestub uusi muudatusi tootmisse juurutada kuidagi kiiremini kui kord tunnis. Nad testivad oma kätega mitte rohkem kui 10% (seda on näha ). Kuidas nad seda teevad? „Excel or die” ütleb üks aruande pealkirjadest. Selle statistika üksikasjalikuks aruteluks testimise kontekstis võite vaadata Baruch Sadogursky peakõnet meie teisel konverentsil Heisenbugis.
"Kui seltsimeeste vahel pole kokkulepet,
Asjad ei lähe neil hästi,
Ja sellest ei tule midagi välja, ainult piin.
Kunagi oli luik, jõevähk ja haug..."
Mis te arvate, milline osa veebiprogrammeerijatest mõistab tõesti, millistel tingimustel nende rakendusi tootmises kasutatakse? Kui paljud neist lähevad administraatorite juurde ja proovivad aru saada, mis juhtub, kui andmebaas kokku jookseb? Ja kes neist läheb testijate juurde ja palub neil õpetada, kuidas teste õigesti kirjutada? Ja seal on ka turvamehed, tootejuhid ja hunnik teisi inimesi.
DevOpsi üldine idee on luua rollide ja osakondade vahelist koostööd. Esiteks saavutatakse see mitte mingi nutikalt konfigureeritud tarkvara, vaid suhtlemispraktikaga. DevOps käsitleb kultuuri, tavasid, metoodikat ja protsesse. Pole ühtegi insenerieriala, mis neile küsimustele vastaks.
Nõiaring
Kust tuli siis distsipliin “devops engineering”? Meil on versioon! DevOpsi ideed olid head – nii head, et said oma edu ohvriteks. Mingid hämarad värbajad ja inimkaubitsejad, kellel on oma õhkkond, hakkasid kogu selle teema ümber keerlema.
Kujutage ette: eile tegite Himkis shawarmat ja täna olete juba suur mees, vanemvärbaja. Kandidaatide otsimise ja valimisega käib terve protsess, kõik pole lihtne, tuleb aru saada. Oletame, et osakonnajuhataja ütleb: leidke X-st spetsialist. Määrame X-le sõna "insener" ja olemegi valmis. Kas vajate Linuxit? Noh, see on kindlasti Linuxi insener, kui soovite DevOpsi, siis DevOpsi insener. Vaba koht ei koosne ainult pealkirjast, vaid sinna tuleb sisestada ka mingi tekst. Lihtsaim viis on sisestada Google'ist märksõnade komplekt, mis sõltub teie kujutlusvõimest. DevOps koosneb kahest sõnast – “Dev” ja “Ops”, mis tähendab, et peame liimima arendajate ja administraatoritega seotud märksõnad ühte hunnikusse. Nii ilmuvad vabad töökohad 42 programmeerimiskeele oskuse ja 20-aastase Kubernetese ja Swarmi samaaegse kasutamise kohta. Tööskeem.
Nii on inimeste teadvuses juurdunud mõttetu ja halastamatu kuvand teatud “devopsi” superkangelasest, kes konfigureerib kõik Jenkinsi juurde minema ja õnn saabub. Oh, kui kõik oleks nii lihtne. "Ja nii saate ka süsteemiadministraatoreid jahtida," arvab HR, "see on moekas sõna, märksõnad on samad, nad peaksid õnge võtma."
Nõudlus loob pakkumise ja kõik need prügikasti vabad kohad on täidetud meeletu hulga süsteemiadministraatoritega, kes mõistsid: kõike saab teha samamoodi nagu varem, aga end “devops” nimetades saad mitu korda rohkem. Nii nagu konfigureerisite servereid SSH kaudu käsitsi ükshaaval, jätkate nende konfigureerimist, kuid nüüd on see väidetavalt devopsi tava. See on mingi kompleksne nähtus, mis on osaliselt seotud klassikaliste administraatorite alahindamise ja DevOpsi ümber käiva hüppega, kuid üldiselt juhtus see, mis juhtus.
Nii et meil on pakkumine ja nõudlus. Nõiaring, mis toidab ennast ise. Selle vastu me võitleme (sh luues DevOopsi konverentsi).
Muidugi on peale süsteemiadministraatorite, kes on end ümber nimetanud "devops", ka teisi osalejaid - näiteks professionaalsed SRE-d või Infrastructure-as-Code arendajad.
Mida inimesed DevOpsis teevad (tõesti)
Nii et soovite DevOpsi tavade õppimises ja rakendamises edasi jõuda. Aga kuidas seda teha, millises suunas vaadata? Ilmselgelt ei tohiks te pimesi populaarsetele märksõnadele loota.
Kui on tööd, peaks keegi seda tegema. Oleme juba avastanud, et need pole "devopsi insenerid", kes siis on? Õigem tundub seda sõnastada mitte ametikohtade, vaid konkreetsete töövaldkondade lõikes.
Esiteks saate käsitleda DevOpsi põhiolemust – protsesse ja kultuuri. Kultuur on aeglane ja raske äri ning kuigi traditsiooniliselt vastutavad selle eest juhid, on sellega ühel või teisel viisil seotud kõik, programmeerijatest administraatoriteni. Paar kuud tagasi Tim Lister :
„Kultuuri määravad organisatsiooni põhiväärtused. Tavaliselt inimesed seda ei märka, kuid olles töötanud aastaid konsultatsiooni alal, oleme harjunud seda märkama. Sisened seltskonda ja hakkad sõna otseses mõttes mõne minuti pärast toimuvat tundma. Me nimetame seda "maitseks". Mõnikord on see lõhn tõesti hea. Mõnikord põhjustab see iiveldust. (...) Kultuuri ei saa muuta enne, kui ei mõisteta konkreetsete tegude taga olevaid väärtusi ja uskumusi. Käitumist on lihtne jälgida, kuid uskumuste otsimine on keeruline. DevOps on lihtsalt suurepärane näide sellest, kuidas asjad muutuvad järjest keerulisemaks.
Küsimusel on loomulikult ka tehniline osa. Kui teie uut koodi testitakse kuu aja pärast, kuid see avaldatakse alles aasta hiljem ja seda kõike on füüsiliselt võimatu kiirendada, ei pruugi te häid tavasid järgida. Häid tavasid toetavad head vahendid. Näiteks Infrastructure-as-Code’i ideed silmas pidades saate kasutada kõike alates AWS CloudFormationist ja Terraformist kuni Chef-Ansible-Puppetini. Seda kõike peab teadma ja oskama ning see on juba üsna inseneriteadus. Oluline on mitte segi ajada põhjust tagajärgedega: kõigepealt töötatakse SRE põhimõtete järgi ja alles seejärel rakendatakse need põhimõtted mõne konkreetse tehnilise lahenduse näol. Samal ajal on SRE väga põhjalik metoodika, mis ei ütle teile, kuidas Jenkinsi seadistada, vaid umbes viis põhiprintsiipi:
- Parem suhtlus rollide ja osakondade vahel
- Vigade aktsepteerimine töö lahutamatu osana
- Muudatuste tegemine järk-järgult
- Tööriistade ja muu automatiseerimise kasutamine
- Mõõda kõike, mida saab mõõta
See ei ole lihtsalt mingi väidete kogum, vaid konkreetne . Näiteks vigade aktsepteerimise teel peate mõistma riske, mõõtma teenuste saadavust ja kättesaamatust, kasutades midagi sellist nagu SLI () ja SLO (), õppige kirjutama surmajärgseid pilte ja muutke nende kirjutamine mitte hirmutavaks.
SRE distsipliinis on tööriistade kasutamine vaid üks osa edust, kuigi oluline. Peame pidevalt tehniliselt arenema, vaatama, mis maailmas toimub ja kuidas seda oma töös rakendada.
Cloud Native lahendused on nüüdseks muutunud omakorda väga populaarseks. Nagu Cloud Native Computing Foundation täna on määratlenud, võimaldavad Cloud Native tehnoloogiad organisatsioonidel arendada ja käitada skaleeritavaid rakendusi tänapäeva dünaamilistes keskkondades, nagu avalikud, privaatsed ja hübriidpilved. Näited hõlmavad konteinereid, teenindusvõrke, mikroteenuseid, muutumatut infrastruktuuri ja deklaratiivseid API-sid. Kõik need tehnikad võimaldavad lõdvalt ühendatud süsteemidel jääda elastseks, juhitavaks ja hästi jälgitavaks. Hea automatiseerimine võimaldab inseneridel teha suuri muudatusi sageli ja etteaimatavate tulemustega, ilma et see oleks tüütu. Seda kõike toetab virn tuntud tööriistu nagu Docker ja Kubernetes.
See üsna keeruline ja lai määratlus tuleneb sellest, et ala on ka üsna keeruline. Ühelt poolt väidetakse, et sellesse süsteemi tuleks lisada uusi muudatusi üsna lihtsalt. Teisest küljest, et välja mõelda, kuidas luua omamoodi konteinerkeskkond, kus lõdvalt seotud teenused toimivad tarkvaraga määratletud infrastruktuuril ja tarnitakse seal pideva CI/CD abil, ning ehitada kõige selle ümber DevOps-praktika – see kõik nõuab rohkem kui üks sööb koera.
Mida selle kõigega peale hakata
Igaüks lahendab need probleemid omal moel: nõiaringi katkestamiseks võib näiteks avaldada tavalisi vabu töökohti. Saate aru saada, mida tähendavad sellised sõnad nagu DevOps ja Cloud Native, ning kasutada neid õigesti ja täpselt. Saate arendada DevOpsis ja näidata oma näitel õigeid lähenemisviise.
Teeme konverentsi , mis annab võimaluse süveneda asjadesse, millest just rääkisime. Selle jaoks on mitu aruannete rühma:
- Protsessid ja kultuur;
- Saidi töökindluse projekteerimine;
- Cloud Native;
Kuidas valida, kuhu minna? Siin on peen point. Ühest küljest on DevOps seotud suhtlemisega ja me tõesti tahame, et osaleksite erinevate plokkide esitlustel. Teisest küljest, kui olete arendusjuht, kes tuli konverentsile keskenduma ühele konkreetsele ülesandele, siis keegi ei piira teid - ilmselgelt on see protsesside ja kultuuri blokk. Ärge unustage, et pärast konverentsi (pärast tagasisideankeedi täitmist) ootavad teid salvestused, et saaksite vähem olulisi ettekandeid hiljem alati vaadata.
Ilmselgelt konverentsil endal kolmele rajale korraga minna ei saa, seega korraldame programmi nii, et igas ajapilus on teemasid igale maitsele.
Jääb üle vaid mõista, mida teha, kui olete DevOpsi insener! Esiteks proovige kindlaks teha, mida te tegelikult teete. Tavaliselt meeldib neile seda sõna kutsuda:
- Arendajad, kes töötavad infrastruktuuri kallal. SRE ja Cloud Native'i aruannete rühmad on teile kõige sobivamad.
- Süsteemiadministraatorid. Siin on keerulisem. DevOops ei ole seotud süsteemi haldamisega. Õnneks on Internetis palju suurepäraseid konverentse, raamatuid, artikleid, videoid jms süsteemihalduse teemal. Teisest küljest, kui olete huvitatud kultuuri ja protsesside mõistmise, pilvetehnoloogiate ja elu üksikasjade tundmaõppimisest Cloud Native'i abil, siis ootame teid hea meelega! Mõelge sellele: te teete haldust ja mida te siis teete? Et vältida end ootamatult ebameeldivasse olukorda sattumist, peaksite kohe õppima.
On veel üks võimalus: jääte kindlaks ja väidate jätkuvalt, et olete konkreetselt DevOpsi insener ja ei midagi muud, mida see ka ei tähendaks. Siis peame teile pettumuse valmistama, DevOops ei ole DevOpsi inseneride konverents!
Libistage Münchenis
DevOops 2020 Moskva toimub 29.-30.aprill Moskvas, piletid on juba saadaval .
Teise võimalusena saate kuni 8. veebruarini. Pange tähele, et vormi täitmisel peate valima sihtrühma, kes teie aruandest kõige rohkem kasu saab (nimekirja sisse on maetud üllatus).
Allikas: www.habr.com