Ar sunku suvokti pagrindinį dalyką kalbant apie „DevOps“? Mes surinkome jums ryškias analogijas, įspūdingas formuluotes ir ekspertų patarimus, kurie padės net nespecialistams suprasti esmę. Pabaigoje premija yra pačių „Red Hat“ darbuotojų „DevOps“.
Terminas „DevOps“ atsirado prieš 10 metų ir iš „Twitter“ žymos virto galingu kultūriniu judėjimu IT pasaulyje – tikra filosofija, skatinančia kūrėjus greičiau atlikti darbus, eksperimentuoti ir kartoti pirmyn. „DevOps“ tapo neatsiejamai susijęs su skaitmeninės transformacijos koncepcija. Tačiau, kaip dažnai nutinka su IT terminija, per pastaruosius dešimt metų „DevOps“ įgijo daug apibrėžimų, interpretacijų ir klaidingų nuomonių apie save.
Todėl dažnai galite išgirsti tokius klausimus apie „DevOps“, ar tai tas pats, kas judrus? O gal tai kažkokia ypatinga metodika? O gal tai tik dar vienas žodžio „bendradarbiavimas“ sinonimas?
„DevOps“ apima daug skirtingų sąvokų (nuolatinis pristatymas, nuolatinis integravimas, automatizavimas ir kt.), todėl išsiaiškinti, kas svarbu, gali būti sudėtinga, ypač kai domitės šia tema. Tačiau šis įgūdis labai praverčia, nesvarbu, ar savo idėjas bandote perteikti viršininkams, ar tiesiog kam nors iš šeimos ar draugų papasakojate apie savo darbą. Todėl kol kas atidėkime į šalį terminologinius DevOps niuansus ir susitelkime į bendrą vaizdą.
Kas yra „DevOps“: 6 apibrėžimai ir analogijos
Mes paprašėme ekspertų kuo paprasčiau ir trumpiau paaiškinti „DevOps“ esmę, kad jos vertė taptų aiški bet kokio lygio techninių žinių turintiems skaitytojams. Remdamiesi šių pokalbių rezultatais, atrinkome ryškiausias analogijas ir ryškiausias formuluotes, kurios padės jums sukurti savo istoriją apie „DevOps“.
1. DevOps yra kultūrinis judėjimas
„DevOps yra kultūrinis judėjimas, kuriame abi pusės (programinės įrangos kūrėjai ir IT sistemų eksploatavimo specialistai) pripažįsta, kad programinė įranga neduoda realios naudos, kol kas nors nepradeda ja naudotis: klientai, klientai, darbuotojai, o ne esmė“, – sako vyresnioji mokslo darbuotoja Eveline Oehrlich. DevOps instituto analitikas. „Todėl abi šios šalys kartu užtikrina greitą ir kokybišką programinės įrangos pristatymą.
2. „DevOps“ yra kūrėjų įgalinimas.
„DevOps suteikia kūrėjams galimybę turėti programas, jas paleisti ir valdyti pristatymą nuo pradžios iki pabaigos.
„Paprastai apie DevOps kalbama kaip apie būdą pagreitinti programų pristatymą į gamybą kuriant ir įdiegiant automatizuotus procesus“, – sako Jai Schniepp, draudimo bendrovės „Liberty Mutual“ DevOps platformų direktorius. „Bet man tai daug esminis dalykas“. „DevOps“ suteikia kūrėjams galimybę turėti programas ar konkrečias programinės įrangos dalis, jas paleisti ir valdyti jų pristatymą nuo pradžios iki pabaigos. „DevOps“ pašalina atsakomybės painiavą ir padeda visiems, kurie dalyvauja kuriant automatizuotą kūrėjų valdomą infrastruktūrą.
3. „DevOps“ – tai bendradarbiavimas kuriant ir teikiant programas.
„Paprasčiau tariant, „DevOps“ yra požiūris į programinės įrangos gamybą ir pristatymą, kai visi dirba kartu“, – sako Gur Staf, BMC prezidentas ir skaitmeninio verslo automatizavimo vadovas.
4. DevOps yra dujotiekis
„Konvejerio surinkimas įmanomas tik tada, kai visos dalys sutampa.
„DevOps palyginčiau su automobilių surinkimo linija“, – tęsia Gur Staff. – Idėja yra suprojektuoti ir pagaminti visas dalis iš anksto, kad vėliau jas būtų galima surinkti be individualaus reguliavimo. Konvejerio surinkimas įmanomas tik tada, kai visos dalys sutampa. Tie, kurie projektuoja ir gamina variklį, turi pagalvoti, kaip jį pritvirtinti prie kėbulo ar rėmo. Tie, kurie gamina stabdžius, turi galvoti apie ratus ir pan. Tas pats turėtų būti ir su programine įranga.
Verslo logiką ar vartotojo sąsają kuriantis kūrėjas turi pagalvoti apie duomenų bazę, kurioje saugoma klientų informacija, saugumo priemones, skirtas apsaugoti vartotojų duomenis ir kaip visa tai veiks, kai paslauga pradės aptarnauti didelę, galbūt net kelių milijonų dolerių vartotojų auditoriją. “.
„Didžiausia kliūtis, kurią reikia įveikti, yra priversti žmones bendradarbiauti ir galvoti apie kitų atliekamus darbus, o ne sutelkti dėmesį tik į savo užduotis. Jei galite tai padaryti, turėsite puikią skaitmeninės transformacijos galimybę“, – priduria Gur Staff.
5. DevOps yra tinkamas žmonių, procesų ir automatizavimo derinys
Jayne Groll, „DevOps Institute“ vykdomoji direktorė, pasiūlė puikią analogiją, paaiškindama „DevOps“. Jos žodžiais, „DevOps“ yra tarsi receptas su trimis pagrindinėmis ingredientų kategorijomis: žmonės, procesas ir automatika. Daugumą šių ingredientų galima paimti iš kitų sričių ir šaltinių: Lean, Agile, SRE, CI/CD, ITIL, lyderystės, kultūros, įrankių. „DevOps“, kaip ir bet kurio gero recepto, paslaptis yra tai, kaip gauti tinkamas proporcijas ir sumaišyti šiuos ingredientus, kad būtų padidintas programų kūrimo ir išleidimo greitis ir efektyvumas.
6. DevOps yra tada, kai programuotojai dirba kaip Formulės 1 komanda
„Lenktynės neplanuojamos nuo pradžios iki finišo, o priešingai – nuo finišo iki starto.
„Kai kalbu apie tai, ko tikėtis iš „DevOps“ iniciatyvos, kaip pavyzdį galvoju apie NASCAR arba Formulės 1 lenktynių komandą“, – sako Chrisas Shortas, „Red Hat“ debesų platformos rinkodaros vyresnysis vadovas ir „DevOps'ish“ naujienlaiškio leidėjas. – Tokios komandos lyderis turi vieną tikslą: lenktynių pabaigoje užimti kuo aukštesnę vietą, atsižvelgiant į komandos turimus resursus ir ją ištikusius iššūkius. Tokiu atveju lenktynės planuojamos ne nuo starto iki finišo, o priešingai – nuo finišo iki starto. Pirmiausia iškeliamas ambicingas tikslas, o tada nustatomi būdai, kaip jį pasiekti. Tada jie suskirstomi į papildomas užduotis ir deleguojami komandos nariams.
„Komanda visą savaitę prieš lenktynes tobulina bokso sustojimą. Jis atlieka jėgos treniruotes ir kardio treniruotes, kad išlaikytų formą varginančią lenktynių dieną. Praktika bendradarbiaujant sprendžiant visas problemas, kurios gali kilti lenktynių metu. Taip pat kūrimo komanda turėtų lavinti įgūdžius dažnai leisti naujas versijas. Jei turite tokių įgūdžių ir gerai veikiančią apsaugos sistemą, naujų versijų paleidimas į gamybą taip pat vyksta dažniau. Šioje pasaulėžiūroje didesnis greitis reiškia didesnį saugumą“, – sako Short.
„Kalbama ne apie „teisingą dalyką“, – priduria Short, – tai apie kuo daugiau dalykų, trukdančių pasiekti norimą rezultatą, pašalinimas. Bendradarbiaukite ir prisitaikykite remdamiesi atsiliepimais, kuriuos gaunate realiuoju laiku. Būkite pasirengę anomalijoms ir dirbkite, kad pagerintumėte kokybę, kad sumažintumėte jų poveikį pažangai siekiant tikslo. Štai kas mūsų laukia DevOps pasaulyje.
Kaip padidinti „DevOps“ mastelį: 10 ekspertų patarimų
Tiesiog „DevOps“ ir masiniai „DevOps“ yra visiškai skirtingi dalykai. Mes jums pasakysime, kaip įveikti kliūtis kelyje nuo pirmos iki antrojo.
Daugeliui organizacijų kelionė į „DevOps“ prasideda lengvai ir maloniai. Kuriamos mažos aistringos komandos, seni procesai pakeičiami naujais, o pirmosios sėkmės laukia neilgai.
Deja, tai tik klaidingas blizgesys, pažangos iliuzija, sako Benas Grinnellas, konsultacinės bendrovės „North Highland“ generalinis direktorius ir skaitmeninio skyriaus vadovas. Ankstyvieji laimėjimai tikrai teikia vilčių, tačiau jie nepadeda pasiekti galutinio tikslo – plačiai pritaikyti „DevOps“ visoje organizacijoje.
Nesunku suprasti, kad rezultatas yra pasidalijimo tarp „mes“ ir „jie“ kultūra.
„Dažnai organizacijos pradeda šiuos novatoriškus projektus, manydamos, kad jie atvers kelią įprastoms „DevOps“ programoms, nesvarsto, ar kiti galės ar norės eiti tuo keliu“, – aiškina Benas Grinnellas. – Komandos tokiems projektams įgyvendinti dažniausiai komplektuojamos iš savimi pasitikinčių „varangiškių“, kurie jau kažką panašaus yra padarę kitose vietose, tačiau jūsų organizacijoje yra nauji. Kartu jie skatinami pažeisti ir sunaikinti taisykles, kurios lieka privalomos visiems kitiems. Nesunku pastebėti, kad rezultatas – „mes“ ir „jų“ kultūra, kuri stabdo žinių ir įgūdžių perdavimą“.
„Ir ši kultūrinė problema yra tik viena iš priežasčių, kodėl „DevOps“ sunku išplėsti. „DevOps“ komandos susiduria su vis didesniais techniniais iššūkiais, būdingais sparčiai augančioms IT įmonėms“, – sakė „Scalyr“ įkūrėjas ir pirmininkas Steve'as Newmanas.
„Šiuolaikiniame pasaulyje paslaugos keičiasi vos tik atsiranda poreikis. Puiku nuolat diegti ir diegti naujas funkcijas, tačiau šio proceso koordinavimas ir kylančių problemų pašalinimas yra tikras galvos skausmas, priduria Steve'as Newmanas. – Labai sparčiai besivystančiose organizacijose įvairių funkcijų komandų inžinieriai stengiasi išlaikyti pokyčius ir jų sukuriamus priklausomybės lygio pakopinius efektus. Be to, inžinieriai nesidžiaugia, kai iš jų atima šią galimybę ir dėl to jiems tampa sunkiau suprasti iškylančių problemų esmę.
Kaip įveikti šiuos aukščiau aprašytus iššūkius ir pereiti prie masinio DevOps pritaikymo didelėje organizacijoje? Ekspertai ragina būti kantrūs, net jei jūsų pagrindinis tikslas yra pagreitinti programinės įrangos kūrimo ciklą ir verslo procesus.
1. Atminkite, kad kultūros pokyčiams reikia laiko.
Jayne Groll, „DevOps Institute“ vykdomoji direktorė: „Mano nuomone, „DevOps“ plėtra turėtų būti tokia pat laipsniška ir pasikartojanti, kaip ir judrus vystymas (ir taip pat liečiantis kultūrą). Agile ir DevOps pabrėžia mažas komandas. Tačiau didėjant šių komandų skaičiui ir didėjant jų integracijai, vis daugiau žmonių pasirenka naujus darbo būdus ir dėl to vyksta didžiulė kultūrinė transformacija.
2. Skirkite pakankamai laiko planuodami ir pasirinkdami platformą
Eranas Kinsbruneris, „Perfecto“ pagrindinis techninis evangelistas: „Kad mastelio keitimas veiktų, „DevOps“ komandos pirmiausia turi išmokti derinti tradicinius procesus, įrankius ir įgūdžius, o tada lėtai puoselėti ir stabilizuoti kiekvieną atskirą „DevOps“ etapą. Viskas prasideda nuo kruopštaus vartotojų istorijų ir vertės srautų planavimo, o po to programinės įrangos rašymo ir versijų valdymo naudojant magistralinį vystymą ar kitus metodus, geriausiai tinkančius kodo šakojimui ir sujungimui.
„Tada ateina integravimo ir testavimo etapas, kai jau reikalinga keičiamo dydžio platforma automatizavimui. Būtent čia „DevOps“ komandoms svarbu pasirinkti tinkamą platformą, atitinkančią jų įgūdžių lygį ir galutinius projekto tikslus.
Kitas etapas yra diegimas į gamybą ir tai turėtų būti visiškai automatizuota naudojant orkestravimo įrankius ir konteinerius. Svarbu, kad visuose „DevOps“ etapuose būtų virtualizuota aplinka (gamybos simuliatorius, kokybės užtikrinimo aplinka ir faktinė gamybos aplinka), o norint gauti atitinkamas išvadas, bandymams visada naudoti tik naujausius duomenis. „Analytics“ turi būti protinga ir gebanti apdoroti didelius duomenis, o grįžtamasis ryšys yra greitas ir veiksmingas.
3. Paimkite kaltę nuo atsakomybės.
Gordonas Haffas, „RedHat“ evangelistas: „Sistemos ir atmosferos, leidžiančios ir skatinančios eksperimentuoti, sukūrimas leidžia įvykti sėkmingai vadinamoms sėkmingoms judrios programinės įrangos kūrimo nesėkmėms. Tai nereiškia, kad niekas kitas nėra atsakingas už nesėkmes. Tiesą sakant, nustatyti, kas atsakingas, tampa dar lengviau, nes „būti atsakingam“ nebėra „sukelti avariją“. Tai yra, kokybiškai keičiasi atsakomybės esmė. Keturi veiksniai tampa kritiniais: trikdžių mastas, metodai, gamybos procesai ir paskatos. (Daugiau apie šiuos veiksnius galite perskaityti Gordono Huffo straipsnyje „DevOps pamokos: 4 sveikų eksperimentų aspektai“.)
4. Išvalykite kelią į priekį
Benas Grinnellas, konsultacijų bendrovės „North Highland“ generalinis direktorius ir skaitmeninio skyriaus vadovas: „Norint pasiekti masto, rekomenduoju kartu su novatoriškais projektais pradėti „kelio valymo“ programą. Šios programos tikslas – išvalyti šiukšles, kurias palieka „DevOps“ pradininkai, pavyzdžiui, pasenusias taisykles ir panašius dalykus, kad kelias į priekį išliktų aiškus.
„Suteikite žmonėms organizacinę paramą ir paskatinkite bendravimą, kuris gerokai viršija novatorišką grupę, plačiai švęsdami naujų darbo būdų sėkmę. Mokykite žmones, kurie dalyvauja kitoje DevOps projektų bangoje ir nerimauja dėl to, kad pirmą kartą naudoja DevOps. Ir atminkite, kad šie žmonės labai skiriasi nuo pionierių.
5. Demokratizuokite įrankius
Steve'as Newmanas, „Scalyr“ įkūrėjas ir pirmininkas: „Įrankiai neturėtų būti slepiami nuo žmonių, be to, juos turėtų būti gana lengva išmokti kiekvienam, norinčiam skirti laiko. Jei galimybė teikti užklausas žurnaluose yra apribota iki trijų žmonių, „sertifikuotų“ naudoti įrankį, problemai spręsti visada turėsite ne daugiau kaip tris žmones, net jei turite labai didelę skaičiavimo aplinką. Kitaip tariant, čia yra kliūtis, kuri gali sukelti rimtų (verslo) pasekmių“.
6. Sukurkite idealias sąlygas komandiniam darbui
Tomas Clarkas, ITV bendros platformos vadovas: „Galite padaryti bet ką, bet ne viską iš karto. Taigi užsibrėžkite didelius tikslus, pradėkite nuo mažų ir judėkite į priekį greitais iteracijose. Laikui bėgant įgausite sėkmingo darbo reputaciją, todėl kiti taip pat norės naudoti jūsų metodus. Ir nesijaudinkite dėl labai efektyvios komandos sukūrimo. Vietoj to, suteikite žmonėms idealias darbo sąlygas ir bus efektyvus.
7. Nepamirškite apie Conway dėsnį ir Kanban lentas
Loganas Daigle'as, „CollabNetVersionOne“ programinės įrangos pristatymo ir „DevOps“ strategijos direktorius: „Svarbu suprasti Conway įstatymo pasekmes. Mano laisvai perfrazuojant, šis įstatymas teigia, kad mūsų kuriami produktai ir procesai, kuriuos naudojame, įskaitant „DevOps“, yra struktūrizuoti taip pat, kaip ir mūsų organizacija.
„Jei organizacijoje yra daug silosų, o planuojant, kuriant ir išleidžiant programinę įrangą kontrolė dažnai keičia savininkus, mastelio keitimo poveikis bus nulinis arba trumpalaikis. Jei organizacija sudaro daugiafunkcines komandas, susijusias su produktais, kurie finansuojami atsižvelgiant į rinką, sėkmės tikimybė labai padidėja.
„Kitas svarbus mastelio keitimo aspektas yra visų vykdomų darbų (WIP, workinprogress) rodymas Kanban plokštėse. Kai organizacijoje yra vieta, kur žmonės gali pamatyti šiuos dalykus, tai labai skatina bendradarbiavimą, o tai daro teigiamą poveikį masto didinimui.
8. Ieškokite senų randų
Manuelis Paisas, „DevOps“ konsultantas ir „Team Topologies“ bendraautoris: „Perimti „DevOps“ praktiką ne tik „Dev and Ops“ ir bandyti jas pritaikyti kitoms funkcijoms vargu ar yra optimalus būdas. Tai tikrai turės tam tikrą poveikį (pavyzdžiui, automatizuojant rankinį valdymą), tačiau daug daugiau galima pasiekti, jei pradėsime nuo pristatymo ir grįžtamojo ryšio procesų supratimo.
„Jei organizacijos IT sistemoje yra senų randų – procedūrų ir valdymo mechanizmų, kurie buvo įdiegti dėl praeities incidentų, tačiau prarado savo aktualumą (dėl produktų, technologijų ar procesų pokyčių) – tuomet juos tikrai reikia pašalinti. arba išlyginti, o ne automatizuoti neefektyvius ar nereikalingus procesus.
9. Nedauginkite DevOps parinkčių
Anthony Edwards, „Eggplant“ operacijų direktorius: „DevOps yra labai neapibrėžtas terminas, todėl kiekviena komanda baigia savo „DevOps“ versiją. Ir nėra nieko blogiau, kai organizacijoje staiga atsiranda 20 „DevOps“ atmainų, kurios tarpusavyje nelabai sutaria. Neįmanoma, kad kiekviena iš trijų kūrimo komandų turėtų savo specialią sąsają tarp kūrimo ir produkto valdymo. Produktai taip pat neturėtų turėti savo unikalių lūkesčių, susijusių su grįžtamojo ryšio apdorojimu, kai jie perkeliami į gamybos treniruoklį. Priešingu atveju niekada negalėsite padidinti „DevOps“ masto.
10. Paskelbkite „DevOps“ verslo vertę
Steve'as Newmanas, „Scalyr“ įkūrėjas ir pirmininkas: „Dirbkite, kad pripažintumėte „DevOps“ vertę. Mokykitės ir nedvejodami kalbėkite apie savo veiklos naudą. „DevOps“ yra neįtikėtinas laiko ir pinigų taupymo būdas (tik pagalvokite: mažiau prastovų, trumpesnis vidutinis atsigavimo laikas), o „DevOps“ komandos turi nenuilstamai pabrėžti (ir skelbti) šių iniciatyvų svarbą verslo sėkmei. Taip galite išplėsti šalininkų ratą ir padidinti DevOps įtaką organizacijoje.
BONUSAS
Apie Mūsų pačių „DevOps“ pasirodys rugsėjo 13 d. – taip, „Red Hat“, kaip programinės įrangos gamintojas, turi savo „DevOps“ komandas ir praktiką.
Mūsų inžinierius Markas Birgeris, kuriantis vidines automatizavimo paslaugas kitoms grupėms visoje organizacijoje, papasakos savo istoriją gryna rusų kalba – kaip Red Hat DevOps komanda perkėlė programas iš Hat Virtualization virtualios aplinkos, valdomos Ansible, į visavertį konteinerio formatą. „OpenShift“ platforma.
Bet tai dar ne viskas:
Organizacijoms perkėlus darbo krūvius į konteinerius, tradiciniai taikomųjų programų stebėjimo metodai gali neveikti. Antrajame pokalbyje paaiškinsime savo motyvaciją keisti registravimo būdą ir parodysime, kaip tęsiasi kelias, atvedęs mus prie šiuolaikinių medienos ruošos ir stebėjimo metodų.
Šaltinis: www.habr.com