Viimaseid aegu on sellised kuulutused täitnud internetti. Kuigi palk võib olla meeldiv, ei saa eirata, et jagatud kirjutises on täielik vale. Alguses eeldatakse, et „DevOps“ ja „insener“ saab mingil moel kokku liita üheks sõnaks, siis järgnevad suvaline nimekiri nõudmistest, millest osa on selgelt kopeeritud süsteemiadministraatori töökohast.
Selles postituses tahaksime rääkida, kuidas me sellesse olukorda jõudsime, mis DevOps tegelikult on ja mida nüüd sellega teha.
Selliseid tööpakkumisi võib kindlasti kriitika alla võtta, kuid põhjused on selged: neid on palju ja selline on hetke turg. Me korraldasime devops-konverentsi ja ütleme avameelselt: " — ei ole DevOps-inseneridele". Paljudele tundub see kummaline ja veider: miks inimesed, kes korraldavad täiesti ärilist üritust, on turu vastu. Praegu seletame kõik välja.
Kultuurist ja protsessidest
Alustame sellest, et DevOps ei ole inseneriteadus. Kõik algas sellest, et ajalooliselt kujunenud rollide jaotamine ei tööta tootete kvaliteedi nimel. Kui programmeerijad programmeerivad, kuid ei soovi kuulda testimisest – tarkvara on täis vigu. Kui administraatorid ei hooli, kuidas ja miks tarkvara on kirjutatud – tugi muutub õuduseks.
Näiteks kirjeldatakse erinevust süsteemiadministraatori ja SRE lähenemise vahel teenuse haldamisel Huvitavad uuringud viidi läbi – on selge, et parimad arendajad suudavad kuidagi uusi muudatusi tootmisse panna kiiremini kui kord tunnis. Nad testivad aga käsitsi mitte rohkem kui 10% (see on näha) Kuidas nad selle saavutavad? "Excel or die" – ütleb üks aruande pealkirjadest. Üksikasjalikumate arutelude saamiseks selle statistika kohta testimise kontekstis võid pöörduda Baruch Sadogursky kõne poole meie teisel konverentsil, Heisenbug.
"Kui sõprade seas pole kokkulepet,
Siis ei õnnestu koostööl,
Ja ei tule sellest muud kui vaev.
Kord Luulet, Kraan ja Siig..."
Mida arvate, kui suur osa veebiprogrammeerijatest mõistab tegelikult, millistes tingimustes nende rakendused tootmises töötavad? Kui palju neist läheb administraatorite juurde ja püüab välja selgitada, mis juhtub andmebaasi kokkuvarisemisel? Ja kes neist läheks teste tegema ja paluks õpetada, kuidas õigesti teste kirjutada? Seal on veel turvamehi, tootejuhte ja palju teisi inimesi.
DevOpsi peamine idee on tagada sujuv koostöö rollide ja osakondade vahel. Esiteks saavutatakse see mitte mingite keerukate tarkvaralahendustega, vaid suhtlemise praktikaga. DevOps on kultuur, praktika, metodoloogia ja protsessid. Ei ole sellist insenerierialat, mis vastaks nendele küsimustele.
Sulgur ring
Kust aga tekkis distsipliin nimega „devops-inseneria”? Meil on teooria! DevOpsi ideed osutusid nii heaks, et nad muutusid oma edu ohvriks. Ümber selle teema hakkasid kogunema kahtlased värbajad ja inimkaubitsejad, kellel on oma ainulaadne õhkkond.
Kujutage ette: eile tegite Himmis shawarma’t, aga täna olete juba suur inimene, vanem värbaja. Siin on terve kandidaatide otsimise ja valimise protsess, kõik ei ole lihtne, tuleb aru saada. Oletame, et osakonna juht ütleb: leia spetsialist X jaoks. Lisame X-ile sõna „insener” ja asi on klaar. Kas on vajalik Linux? No see on kindel Linux-insener, soovite DevOps’i — DevOps-insener. Töökuulutus ei koosne mitte ainult pealkirjast, vaid sees peab olema ka mingit teksti. Lihtsaim on kirjutada Google’ist leitud märksõnade kogum,et kellelgi piisab fantaasiast. DevOps koosneb kahest sõnast — „Dev” ja „Ops”, seega tuleb kokku kleebida arendajate ja administratoride suhtes seotud märksõnad, kõik ühte kuhja. Nii tekivad töökuulutused, mis nõuavad 42 programmeerimiskeele valdamist ja 20 aastat Kubernetes’i ja Swarm’i samaaegset kasutamist. Töökorraldus.
Nii on inimeste teadvuses juurdunud mõttetu ja halastamatu superkangelaste „devops’i” kuvand, kes seadistab kõigile Jenkinsis deploy’i ja õnn tuleb. Oh, kui kõik oleks nii lihtne. "Ja veel võib sellega süsteemiadministreerijate peal jahipidada," mõtleb HR, "moodne sõna, märksõnad on samad, peaksid kindlasti klikkima."
Küsimus loob pakkumise ja kõikidele nende nõmedatele tööpakkumistele on tunginud meeletu arv süsteemiadministraatoreid, kes on aru saanud: neid samu asju saab teha sama hästi nagu varem, aga nüüd saab teenida mitu korda rohkem, nimetades ennast 'devops' nende considerat ning see "devopsi praktika". Nii nagu sa seadistad servere SSH kaudu käsitsi ükshaaval, nii jätkad sa seda tegemist, ainult et nüüd on see näiliselt devopsi harjutamine. See on keeruline nähtus, mis on osaliselt seotud klassikaliste adminnide alahindamise ja DevOpsi hüpete ringiga, kuid kokkuvõttes on see, mis see on.
Nii et meil on nõudlus ja pakkumine. Isolatsioon, mis toidab iseennast. Sellega meie tegeleme (sh luues DevOops konverentsi).
Muidugi, lisaks süsteemiadminnidele, kes on nimetatud 'devopsiks', on ka teisi osalisi — näiteks professionaalsed SRE-d või Infrastructure-as-Code arendajad.
Mida inimesed DevOpsis tõeliselt teevad
Nii et soovid süveneda DevOpsi praktikatena. Kuidas seda teha, kuhu suunda vaadata? Ilmselt ei tasu pime pidada kinni populaarsetest märksõnadest.
Kui töö on olemas, peab keegi sellega tegelema. Oleme juba välja selgitanud, et need ei ole 'devopsinsenerid', siis kes? Tundub, et õigem on seda formuleerida mitte ametikohtade terminoloogia, vaid konkreetsete tööalaste suundade kaudu.
Esiteks, võib tegeleda DevOpsi südamega — protsesside ja kultuuriga. Kultuur on aeglane ja keeruline asi, ja kuigi see on traditsiooniliselt juhtide vastutus, osaleb selles kõik, alates programmeerijatest kuni adminnideni. Mõni kuu tagasi ütles Tim Lister :
"Kultuur on määratud organisatsiooni põhiväärtustega. Tavaline on, et inimesed ei pane sellele tähele, kuid me, olles töötanud konsultatsioonis juba aastaid, oleme harjunud sellele tähelepanu pöörama. Sa astud ettevõttesse ja juba mõne minuti pärast hakkad tundma, mis toimub. Me nimetame seda 'lõhnaks'. Mõnikord on see lõhn tõeliselt hea. Mõnikord tekitab see iiveldust. (...) Sa ei saa kultuuri muuta enne, kui on selgitatud välja väärtused ja uskumused, mis seisavad konkreetsed tegevused. Käitumist on lihtne jälgida, aga uskumiste otsimine on keeruline. DevOps on just suurepärane näide sellest, kuidas kõik muutub üha keerulisemaks."
On the technical side of things, of course, there's a question. If your new code arrives for testing in a month, but it only gets released a year later, and physically speeding this up is impossible, then you might not even reach good practices. Good practices are supported by good tools. For example, by holding the concept of Infrastructure-as-Code in mind, one can use anything from AWS CloudFormation and Terraform to Chef-Ansible-Puppet. It is essential to know and be able to use all of this, and that is already a genuine engineering discipline. It's vital not to confuse cause and effect: first, you work according to SRE principles, and only then do you implement these principles in the form of specific technical solutions. Moreover, SRE is a very comprehensive methodology, which doesn't just tell you how to configure Jenkins, but rather about five main 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 . For example, on the path to accepting mistakes, one will need to address risks, measure service availability and unavailability using something like SLI () and SLO (), learn to write postmortems, and ensure that writing them isn't intimidating.
In the SRE discipline, the use of tools is just one part of success, though undoubtedly an important one. We need to continually develop technically, keeping an eye on global happenings and how we can apply them in our work.
Omakorda on nüüdseks saanud väga populaarseks Cloud Native lahendused. Vastavalt tänapäevasele arusaamale Cloud Native Computing Foundationist võimaldavad Cloud Native tehnoloogiad organisatsioonidel arendada ja käivitada skaleeritavaid rakendusi tänapäeva dünaamilistes keskkondades, nagu avalikud, era- ja hübriidpilved. Näiteks võib tuua konteinerid, teenuste võrgud, mikroteenused, muutumatud infrastruktuurid ja deklaratiivsed API-d. Kõik need tehnikad võimaldavad nõrgalt seotud süsteemide jääda elastseteks, hallatavateks ja hästi jälgitavateks. Hea automatiseerimine võimaldab inseneridel teha suuri muudatusi sageli ja ettearvatavate tulemustega, mitte muutes seda põrguliseks tööks. Kõike seda toetab tuntud tööriistade komplekt, nagu Docker ja Kubernetes.
See on üsna keeruline ja keeruline määratlus, mis on seotud sellega, et valdkond on samuti keeruline. Ühelt poolt väidetakse, et uued muudatused peaksid selle süsteemi lisanduma suhteliselt lihtsalt. Teiselt poolt, et mõista, kuidas luua konteineriseeritud keskkond, kus nõrgalt seotud teenused elavad tarkvaraga määratletud infrastruktuuris ja viiakse sinna sisse pideva CI/CD abil, ning ehitada kogu selle ümber DevOps-praktikad — selleks peab olema oma kogemus.
Mida kõigega nende probleemidega teha
Igaühel on oma lähenemine nende probleemide lahendamiseks: näiteks võiks avaldada korralikke tööpakkumisi, et katkestada suletud ring. Saame aru, mida tähendavad sellised sõnad nagu DevOps ja Cloud Native, ning kasutada neid õigesti ja asjakohaselt. Saame arendada end DevOpsis ja oma näitega demonstreerida õigeid lähenemisi.
Me korraldame konverentsi , mis annab võimaluse süvitsi minna teemadesse, millest me just rääkisime. Selleks on mitu esitluste rühma:
- Protsessid ja kultuur;
- Site Reliability Engineering;
- Cloud Native;
Kuidas valida, kuhu minna? Siin on peen nüanss. Ühest küljest on DevOps seotud suhtlemisega ja me väga loodame, et osalete ettekannetes erinevatest plokkidest. Teisest küljest, kui olete arenduse juht, kes tuli konverentsile, et keskenduda ühele konkreetselt ülesandele, ei piira teid keegi – selgelt on see plokk, mis käsitleb protsesse ja kultuuri. Ärge unustage, et konverentsi järel jäävad teile salvestused (pärast tagasisidevormi täitmist), seega saate alati hiljem vaadata vähem olulisi ettekandeid.
On selge, et konverentsil ei saa te korraga osaleda kolmes rajatises, seega koostame programmi nii, et igas ajavahemikus oleks teemasid igale maitsele.
Jäänud on vaid mõista, mida teha, kui olete DevOps-insener! Esiteks proovige välja selgitada, millega te tegelikult tegelete. Tavaliselt kasutatakse selle sõna all:
- Arendajaid, kes tegelevad infrastruktuuriga. Teie jaoks sobivad kõige rohkem ettekannete grupid, mis käsitlevad SRE-d ja Cloud Native'i.
- Süsteemiadministraatoreid. Siin on keerulisem. DevOps ei ole üldse süsteemiadministreerimisest. Õnneks on süsteemiadministreerimise teemal palju suurepäraseid konverentse, raamatuid, artikleid, videosid internetis jne. Teiselt poolt, kui teil on huvi kultuuri ja protsesside mõistmise, pilvetehnoloogiate uurimise ja Cloud Native’iga elamise üksikasjade poole, siis oleks meil hea meel teid näha! Mõelge sellele: te teete haldust, aga mis siis edasi? Et mitte ootamatult ebamugavasse olukorda sattuda, tuleks juba nüüd õppida.
Oleme veel üks võimalus: püsige ja jätkake väitmises, et olete just DevOps-insener ja mitte kuidagi teisiti, ükskõik, mida see ka ei tähendaks. Siis pean teid kurvastama, DevOps ei ole konverents DevOps-inseneride jaoks!
Slaidist Münchenis
DevOops 2020 Moskvas toimub 29.-30. aprillil Moskvas, lipud on juba saadaval .
Lisaks saate kuni 8. veebruarini. Pidage meeles, et vormi täitmisel peate valima sihtrühma, kellele teie ettekandest kõige rohkem kasu on (see üllatus on loendi sees peidus).
Allikas: habr.com
