Pastaruoju metu internetą užplūdo tokie skelbimai. Nepaisant malonaus atlyginimo, negalima nesijausti, kad viduje įrašyta laukinė erezija. Iš pradžių daroma prielaida, kad „DevOps“ ir „inžinierius“ kažkaip gali būti sujungti į vieną žodį, o tada atsiranda atsitiktinis reikalavimų sąrašas, kai kurie iš jų aiškiai nukopijuoti iš laisvos sysadmin darbo vietos.
Šiame įraše norėčiau šiek tiek pakalbėti apie tai, kaip mes pasiekėme šį gyvenimo tašką, kas iš tikrųjų yra „DevOps“ ir ką su juo daryti dabar.
Tokias laisvas darbo vietas galima smerkti visais įmanomais būdais, tačiau faktas lieka faktu: jų yra daug, o rinka šiuo metu veikia taip. Surengėme devopso konferenciją ir atvirai pareiškiame: „ – ne DevOps inžinieriams. Daugeliui tai atrodys keista ir laukinė: kodėl žmonės, rengiantys visiškai komercinį renginį, eina prieš rinką. Dabar mes viską paaiškinsime.
Apie kultūrą ir procesus
Pradėkime nuo to, kad „DevOps“ nėra inžinerijos disciplina. Viskas prasidėjo nuo to, kad istoriškai nusistovėjęs vaidmenų pasiskirstymas neveikia gaminių kokybei. Kai programuotojai tik programuoja, bet nenori nieko girdėti apie testavimą, programinė įranga yra nusėta klaidų. Kai administratoriams nerūpi, kaip ir kodėl parašyta programinė įranga, palaikymas virsta pragaru.
Pavyzdžiui, aprašant skirtumą tarp sistemos administratoriaus ir SRE požiūrio į paslaugų valdymą . Buvo atlikti įdomūs tyrimai - Akivaizdu, kad geriausi kūrėjai kažkaip sugeba įdiegti naujus gamybos pakeitimus greičiau nei kartą per valandą. Jie išbando rankomis ne daugiau kaip 10% (tai matyti iš ). Kaip jie tai daro? „Excel arba die“, sakoma vienoje iš ataskaitos antraščių. Norėdami išsamiai aptarti šią statistiką testavimo kontekste, galite žiūrėti Barucho Sadogurskio pagrindinį pranešimą kitoje mūsų konferencijoje Heisenbug.
„Kai bendražygiai nesusitaria,
Jiems ne viskas gerai,
Ir nieko iš to neišeis, tik kančia.
Kadaise gulbė, vėžys ir lydeka...“
Kaip manote, kuri žiniatinklio programuotojų dalis tikrai supranta, kokiomis sąlygomis jų programos naudojamos gamyboje? Kiek iš jų eis pas administratorius ir bandys išsiaiškinti, kas bus, jei duomenų bazė sugenda? O kuris iš jų eis pas bandytojus ir prašys, kad išmokytų taisyklingai rašyti testus? Taip pat yra apsaugos darbuotojai, produktų vadybininkai ir daugybė kitų žmonių.
Bendra „DevOps“ idėja yra sukurti bendradarbiavimą tarp vaidmenų ir skyrių. Visų pirma, tai pasiekiama ne kokia nors sumaniai sukonfigūruota programine įranga, o bendravimo praktika. „DevOps“ yra apie kultūrą, praktiką, metodiką ir procesus. Nėra jokios inžinerijos specialybės, kuri galėtų atsakyti į šiuos klausimus.
Užburtas ratas
Iš kur tada atsirado „devops engineering“ disciplina? Turime versiją! „DevOps“ idėjos buvo geros – tokios geros, kad tapo savo sėkmės aukomis. Kai kurie šešėliniai verbuotojai ir prekeiviai žmonėmis, turintys savo atmosferą, pradėjo suktis aplink visą šią temą.
Įsivaizduokite: vakar kūrėte šavarmą Chimkuose, o šiandien jau esate didelis žmogus, vyresnysis verbuotojas. Vyksta visas kandidatų paieškos ir atrankos procesas, viskas nėra lengva, reikia suprasti. Tarkime, skyriaus vedėjas sako: susiraskite specialistą X. Priskiriame X žodį „inžinierius“, ir viskas. Reikia Linux? Na, tai tikrai „Linux“ inžinierius, jei norite „DevOps“, tada „DevOps“ inžinierius. Laisvą darbo vietą sudaro ne tik pavadinimas, bet ir tam tikras tekstas turi būti įvestas viduje. Paprasčiausias būdas yra įvesti raktinių žodžių rinkinį iš Google, atsižvelgiant į jūsų vaizduotę. „DevOps“ susideda iš dviejų žodžių – „Dev“ ir „Ops“, o tai reiškia, kad turime suklijuoti su kūrėjais ir administratoriais susijusius raktinius žodžius, visus į vieną krūvą. Taip atsiranda laisvų darbo vietų, susijusių su 42 programavimo kalbų mokėjimu ir 20 metų Kubernetes ir Swarm naudojimo vienu metu. Darbo schema.
Taip žmonių mintyse įsitvirtino beprasmis ir negailestingas tam tikro „devopso“ superherojaus įvaizdis, kuris visus sukonfigūraus dislokuoti pas Jenkinsą, ir laimė ateis. O jei viskas būtų taip paprasta. „Ir taip galite sumedžioti sistemos administratorius“, – mano HR, – „tai madingas žodis, raktiniai žodžiai yra tie patys, jie turėtų imti masalą“.
Paklausa kuria pasiūlą, o visas šias šiukšlių vietas užpildė beprotiškai daug sistemų administratorių, kurie suprato: viską galima daryti taip pat, kaip ir anksčiau, bet pasivadinus „devops“ gauti kelis kartus daugiau. Lygiai taip pat, kaip sukonfigūravote serverius per SSH rankiniu būdu po vieną, jūs ir toliau juos konfigūruosite, bet dabar tai tariamai yra „devops“ praktika. Tai tam tikras sudėtingas reiškinys, iš dalies susijęs su klasikinių administratorių neįvertinimu ir „DevOps“ ažiotažu, tačiau apskritai tai, kas atsitiko, atsitiko.
Taigi turime pasiūlą ir paklausą. Užburtas ratas, kuris maitina save. Su tuo mes kovojame (taip pat ir kurdami DevOops konferenciją).
Žinoma, be sistemos administratorių, kurie save pervadino „devops“, yra ir kitų dalyvių – pavyzdžiui, profesionalių SRE arba Infrastructure-as-Code kūrėjų.
Ką žmonės veikia DevOps (tikrai)
Taigi norite mokytis ir pritaikyti „DevOps“ praktiką. Bet kaip tai padaryti, kuria kryptimi žiūrėti? Akivaizdu, kad neturėtumėte aklai pasikliauti populiariais raktiniais žodžiais.
Jei yra darbas, kažkas turi jį atlikti. Mes jau išsiaiškinome, kad tai nėra „devops inžinieriai“, o kas yra? Atrodo teisingiau tai suformuluoti ne pagal pareigybes, o apie konkrečias darbo sritis.
Pirma, galite atkreipti dėmesį į „DevOps“ esmę – procesus ir kultūrą. Kultūra yra lėtas ir sunkus verslas, ir nors tradiciškai tai yra vadovų pareiga, vienaip ar kitaip dalyvauja visi – nuo programuotojų iki administratorių. Prieš porą mėnesių Timas Listeris :
„Kultūrą lemia pagrindinės organizacijos vertybės. Dažniausiai žmonės to nepastebi, tačiau ilgus metus dirbę konsultavimo srityje esame įpratę tai pastebėti. Įeini į kompaniją ir tiesiogine prasme per kelias minutes pradedi jausti, kas vyksta. Mes tai vadiname „skoniu“. Kartais šis kvapas yra tikrai geras. Kartais tai sukelia pykinimą. (...) Negalite pakeisti kultūros, kol nesuprantamos vertybės ir įsitikinimai, slypintys už konkrečių veiksmų. Elgesį lengva stebėti, bet sunku ieškoti įsitikinimų. „DevOps“ yra tik puikus pavyzdys, kaip viskas darosi vis sudėtingiau.
Žinoma, yra ir techninė problemos dalis. Jei jūsų naujasis kodas bus išbandytas per mėnesį, bet išleistas tik po metų, o viso to paspartinti fiziškai neįmanoma, galite nesilaikyti gerosios praktikos. Geroji praktika yra paremta geromis priemonėmis. Pavyzdžiui, turėdami omenyje „Infrastructure-as-Code“ idėją, galite naudoti bet ką – nuo „AWS CloudFormation“ ir „Terraform“ iki „Chef-Ansible-Puppet“. Visa tai reikia žinoti ir mokėti, o tai jau gana inžinerinė disciplina. Svarbu nepainioti priežasties su pasekme: iš pradžių dirbi pagal SRE principus ir tik tada įgyvendini šiuos principus tam tikrų specifinių techninių sprendimų pavidalu. Tuo pačiu metu SRE yra labai išsami metodika, kuri nenurodo, kaip nustatyti Jenkins, bet apie penkis pagrindinius principus:
- Pagerinta komunikacija tarp vaidmenų ir skyrių
- Klaidų priėmimas kaip neatsiejama darbo dalis
- Pakeitimų vykdymas palaipsniui
- Naudojant įrankius ir kitą automatiką
- Matuoja viską, ką galima išmatuoti
Tai ne tik kai kurie teiginiai, bet ir konkretus . Pavyzdžiui, norėdami priimti klaidas, turėsite suprasti riziką, įvertinti paslaugų prieinamumą ir nepasiekiamumą naudodami kažką panašaus į SLI () ir SLO (), išmokite rašyti postmortems ir kad jų rašymas nebūtų baisus.
SRE disciplinoje įrankių naudojimas yra tik viena sėkmės dalis, nors ir svarbi. Turime nuolat tobulėti techniškai, žiūrėti, kas vyksta pasaulyje ir kaip tai galima pritaikyti savo darbe.
Savo ruožtu „Cloud Native“ sprendimai dabar tapo labai populiarūs. Kaip šiandien apibrėžia „Cloud Native Computing Foundation“, „Cloud Native“ technologijos leidžia organizacijoms kurti ir paleisti keičiamo dydžio programas šiandieninėje dinamiškoje aplinkoje, pvz., viešuosiuose, privačiuose ir hibridiniuose debesyse. Pavyzdžiai: konteineriai, paslaugų tinkleliai, mikropaslaugos, nekintanti infrastruktūra ir deklaratyvios API. Visi šie metodai leidžia laisvai sujungtoms sistemoms išlikti elastingoms, valdomoms ir gerai stebimoms. Geras automatizavimas leidžia inžinieriams dažnai atlikti didelius pakeitimus ir pasiekti nuspėjamų rezultatų, netapdami to rūpesčiu. Visa tai palaiko daugybė gerai žinomų įrankių, tokių kaip „Docker“ ir „Kubernetes“.
Šis gana sudėtingas ir platus apibrėžimas atsirado dėl to, kad ši sritis taip pat yra gana sudėtinga. Viena vertus, teigiama, kad nauji šios sistemos pakeitimai turėtų būti įtraukti gana paprastai. Kita vertus, išsiaiškinti, kaip sukurti tam tikrą konteinerinę aplinką, kurioje laisvai susietos paslaugos veiktų programinės įrangos apibrėžtoje infrastruktūroje ir būtų ten teikiamos naudojant nuolatinį CI / CD, ir sukurti DevOps praktiką aplink visa tai – visa tai reikalauja daugiau. nei vienas valgo šunį.
Ką su visu tuo daryti
Kiekvienas šias problemas sprendžia savaip: pavyzdžiui, galite paskelbti įprastas laisvas darbo vietas, kad ištrauktumėte užburtą ratą. Galite išsiaiškinti, ką reiškia tokie žodžiai kaip „DevOps“ ir „Cloud Native“, ir naudoti juos teisingai bei tiksliai. Galite kurti naudodami „DevOps“ ir savo pavyzdžiu parodyti tinkamus metodus.
Mes rengiame konferenciją , kuri suteikia galimybę labiau įsigilinti į dalykus, apie kuriuos ką tik kalbėjome. Tam yra kelios ataskaitų grupės:
- Procesai ir kultūra;
- Svetainės patikimumo inžinerija;
- Cloud Native;
Kaip pasirinkti, kur eiti? Čia yra subtilus dalykas. Viena vertus, „DevOps“ yra sąveika, ir mes tikrai norime, kad dalyvautumėte pristatymuose iš skirtingų blokų. Kita vertus, jei esate plėtros vadovas, atėjęs į konferenciją susikoncentruoti ties viena konkrečia užduotimi, tuomet jūsų niekas neriboja – aišku, tai bus blokas apie procesus ir kultūrą. Nepamirškite, kad po konferencijos (užpildę atsiliepimų formą) turėsite įrašų, todėl vėliau visada galėsite žiūrėti ne tokius svarbius pranešimus.
Akivaizdu, kad pačioje konferencijoje negali eiti vienu metu trimis takeliais, todėl programą organizuojame taip, kad kiekviename laiko tarpsnyje būtų temų kiekvienam skoniui.
Belieka tik suprasti, ką daryti, jei esate „DevOps“ inžinierius! Pirmiausia pabandykite nustatyti, ką iš tikrųjų darote. Paprastai jie mėgsta vadinti šį žodį:
- Kūrėjai, dirbantys su infrastruktūra. Jums labiausiai tinka ataskaitų grupės apie SRE ir Cloud Native.
- Sistemos administratoriai. Čia sudėtingiau. „DevOops“ nėra skirtas sistemos administravimui. Laimei, sistemos administravimo tematika yra daug puikių konferencijų, knygų, straipsnių, vaizdo įrašų internete ir kt. Kita vertus, jei norėtumėte tobulėti, kad suprastumėte kultūrą ir procesus, sužinotumėte apie debesų technologijas ir gyvenimo detales naudojant „Cloud Native“, mes mielai jus pamatysime! Pagalvokite apie tai: jūs darote administravimą, o ką tada darysite? Kad staiga nepatektumėte į nemalonią situaciją, turėtumėte išmokti dabar.
Yra ir kitas variantas: tu atkakliai ir toliau tvirtini, kad esi konkrečiai „DevOps“ inžinierius ir nieko daugiau, kad ir ką tai reikštų. Tada turime jus nuvilti, „DevOops“ nėra „DevOps“ inžinierių konferencija!
Slysti iš Miunchene
„DevOops 2020 Moscow“ vyks balandžio 29-30 dienomis Maskvoje, bilietai jau yra .
Be to, galite iki vasario 8 d. Atkreipkite dėmesį, kad pildydami formą turite pasirinkti tikslinę auditoriją, kuriai iš jūsų ataskaitos bus daugiausia naudos (sąraše yra staigmena).
Šaltinis: www.habr.com