Räägime DevOps'ist arusaadavas keeles

Kas on DevOps'i olemust keeruline tabada? Oleme kokku kogunud selged analoogiad, tabavad väljendid ja ekspertide nõuanded, mis aitavad isegi mittespetsialistidel tuuma lähemale jõuda. Lõpus on boonus – Red Hati töötajate enda DevOps.

DevOps'i mõiste tekkis 10 aastat tagasi ja on teinud teekonna Twitteri hashtag'ist võimsaks kultuuriliseks liikumiseks IT maailmas, tõeliseks filosoofiaks, mis julgustab arendajaid kiiremini tulemusi saavutama, katsetama ja edasi liikuma iteratiivsel meetodil. DevOps on saanud lahutamatuks osaks digitaaltransformatsiooni käsitusest. Kuid nagu sageli IT terminoloogia puhul, on DevOps kümne aasta jooksul saanud mitmeid määratlusi, tõlgendusi ja ekslikke arusaamu enda kohta.

Seetõttu kuuleb DevOps'i kohta tihti küsimusi nagu, kas see on sama, mis agile? Või on see mingi eriline metoodika? Või on see lihtsalt veel üks sünonüüm sõnale „koostöö“?

DevOps hõlmab palju erinevaid kontseptsioone (pidev kohaletoimetamine, pidev integreerimine, automatiseerimine jne), seega võib peamise eristamine olla keeruline, eriti kui teema on teile lähedane. Siiski on see oskus ülimalt kasulik, olenemata sellest, kas üritate oma ideid ülemustele edastada või räägite oma tööst lähedastele või tuttavatele. Seetõttu lükkame DevOpsi terminoloogilised nüansid kõrvale ja keskendume üldisele pildile.

Mis on DevOps: 6 määratlust ja analoogiat

Palusime spetsialistidel selgitada DevOpsi olemust võimalikult lihtsalt ja lühidalt, et selle väärtus muutuks selgeks lugejale, kellel on igasugune tehniline ettevalmistus. Nende vestluste tulemuseks valisime välja kõige silmapaistvamad analoogiad ja löövamad väljendid, mis aitavad teil oma DevOpsi lugu kujundada.

1. DevOps – see on kultuuriline liikumine

«DevOps on kultuuriline liikumine, mille käigus mõlemad pooled (tarkvaraarendajad ja IT-süsteemide haldurid) tunnustavad, et tarkvara ei too tõelist kasu, kuni keegi ei hakka seda kasutama: olgu need siis kliendid, tellijad või töötajad – märgib Eveline Oehrlich, DevOpsi instituudi vanemanalüütik. – Seetõttu tagavad need pooled koos tarkvara kiire ja kvaliteetse tarnimise.»

2. DevOps on see, mis annab volitusi arendajatele

«DevOps annab arendajatele õiguse hallata rakendusi, käivitada neid ja juhtida tarnimist algusest lõpuni»

«Tavaliselt räägitakse DevOpsist kui meetodist, mis kiirendab rakenduste korraldamist tootmises, rakendades automatiseeritud protsesse,» ütleb Jai Schniepp, DevOps platvormide direktor kindlustusettevõttes Liberty Mutual. «Kuid minu jaoks on see midagi palju fundamentaalsemat. DevOps annab arendajatele õiguse omada rakendusi või teatud tarkvara osi, nende haldamiseks ja kohaletoimetamiseks algusest lõpuni. DevOps elimineerib vastutuse segaduse ja suunab kõiki protsessi osalisi üles ehitama arendajate juhitud automatiseeritud infrastruktuuri.»

3. DevOps – koostöö rakenduste loomisel ja tarnimisel

«Lihtsalt öeldes, DevOps on lähenemine tarkvara tootmisele ja tarnimisele, kus kõik töötavad koos,» märkis Gur Staff, ettevõtte BMC president ja digitaalse äri automatiseerimise juht.

4. DevOps – see on konveier

«Konveieritehnika on võimalik ainult siis, kui kõik osad sobivad omavahel.»

«Ma peaks DevOps'i autotootmisliiniga. Idee seisneb selles, et kõik osad on ette kavandatud ja valmistatud selliselt, et need oleks võimalik kokku panna ilma individuaalse kohandamiseta. Tootmisliin toimib ainult siis, kui kõik osad sobivad omavahel. Need, kes projekteerivad ja valmistavad mootorit, peavad mõtlema, kuidas see kinnitada kere või raami külge. Need, kes teevad pidurid, peavad mõtlema ratastele jne. Sama peab olema ka tarkvaraga.»

„Arendaja, kes koostab äriloogikat või kasutajaliidest, peab mõtlema andmebaasile, mis salvestab teavet klientide kohta, turvameetmetele kasutajate andmete kaitsmiseks ja sellele, kuidas kõik see toimib, kui teenus hakkab teenindama suurt, võimalik, isegi mitme miljoni kasutaja sihtrühma.”

„Kuidas panna inimesi koostööd tegema ja mõtlema sellele, mida teised teevad, mitte ainult oma ülesannetele keskenduma – see on suurim takistus, mille ületamine on vajalik. Kui see õnnestub, on teil suurepärased võimalused digitaalseks ümberkujundamiseks,” lisab Gur Staff.

5. DevOps – see on õige kombinatsioon inimestest, protsessidest ja automatiseerimisest

Jayne Groll, DevOps Instituudi tegevdirektor, tõi välja suurepärase analoogia DevOpsi selgitamiseks. Tema sõnul on „DevOps nagu retsept, kus on kolm põhikategooriat koostisosadest: inimesed, protsessid ja automatiseerimine. Enamik neist koostisosadest võib tulla teistest valdkondadest ja allikatest: Lean, Agile, SRE, CI/CD, ITIL, juhtimine, kultuur, tööriistad. DevOpsi saladus, nagu iga hea retsepti puhul, on õigete proportsioonide leidmine ja nende koostisosade segamine, et suurendada kiirus ja efektiivsus rakenduste loomisel ja vabastamisel.”

6. DevOps – see on siis, kui programmeerijad töötavad nagu F1 meeskond

„Võistlus ei ole planeeritud stardist finišini, vaid vastupidi, finišist starti.”

„Rääkides DevOps algatuse ootustest, toon ma näiteks NASCAR või F1 võistkonna,“ ütleb Chris Short, Red Hat pilveplatvormide turundusjuht ja DevOps’ish uudiskirja väljaandja. „Selle võistkonna juhil on üks eesmärk: saavutada võimalikult kõrge koht, arvestades võistkonna ressursse ja eesmisi väljakutseid. Samas plaanitakse võistlust mitte stardist finišisse, vaid vastupidi, finišist stardisse. Esiteks seatakse ambitsioonikas eesmärk ja seejärel määratakse viisid selle saavutamiseks. Seejärel jagatakse need väikeülesanneteks ja delegeeritakse meeskonna liikmetele.“

«Kogu nädala enne võistlust treenib meeskond pit-stop'e. Tegeletakse jõu- ja kardiotreeningutega, et olla vormis kurnaval võistluspäeval. Harjutatakse koos tegutsemist, et lahendada kõiki probleeme, mis võistluse ajal võivad tekkida. Samamoodi peab arendusmeeskond treenima uute versioonide sagedase väljalaskmise oskusi. Nende oskuste ja hästi toimiva turvasüsteemi olemasolul toimuvad uute versioonide tootmine ja tootmisse laskmine samuti sagedamini. Selle mõtteviisi kohaselt tähendab kiirus suurenenud turvalisust,» ütleb Short.

«Küsimus ei ole selles, et teha „õigeid asju“, – lisab Short, – vaid selles, et eemaldada võimalikult palju asju, mis takistavad soovitud tulemuse saavutamist. Koostööd tehke ja kohandage end reaalajas saadud tagasiside kohaselt. Olge valmis anomaaliateks ja töötage kvaliteedi parandamise nimel, et nende mõju eesmärgile minimaalne oleks. Just seda ootab meid DevOpsi maailmas».

Kuidas skaleerida DevOps: 10 nõuannet ekspertidelt

Lihtne DevOps ja massiline DevOps on täiesti erinevad asjad. Räägime sellest, kuidas ületada takistused teel esimesest teiseni.

Paljude organisatsioonide teekond DevOpsi juurde algab lihtsalt ja meeldivalt. Loobetakse väikseid entusiastlikke meeskondi, vanad protsessid vahetatakse uute vastu ning esimesed edusammud ei lase end kaua oodata.

Kahjuks on see vaid vale sära, edenemise illusioon, nagu ütleb Ben Grinnell, North Highlandi konsultatsiooni firma digitaalsete tehnoloogiate juht. Varased võidud on küll lootustandevad, kuid ei aita saavutada lõppeesmärki, nimelt DevOpsi laialdast kasutuselevõttu organisatsioonis.

On lihtne näha, et selle tulemusena kujuneb välja kultuur, mis jagab inimesi «meie» ja «nemad».

„Tihti käivitavad organisatsioonid selliseid pioneeriprojekte, arvates, et need rajavad tee massilisele DevOps-ile, mõtlemata, kas teised soovivad ja suudavad sellel teel edasi liikuda,” selgitab Ben Greennell. „Need projektide elluviimise meeskonnad koosnevad tavaliselt enesekehtestavatest 'vikingitest', kes on juba midagi sarnast teinud mujal, kuid on teie organisatsioonis uustulnukad. Samal ajal julgustatakse neid murdma ja hävitama reegleid, mis jäävad kohustuslikeks kõigile teistele. On lihtne näha, et selliseid olukordi tekib eraldumise kultuur ‘me’ ja ‘nemad’, mis takistab teadmiste ja oskuste jagamist.”

„Ja see kultuuriline probleem on vaid üks põhjus, miks DevOps-i on raske laieneda. DevOps-i meeskonnad kohtavad tehniliste keerukuste kasvu, mis on iseloomulik kiiresti arenevatele ettevõtetele, kes on panustanud IT-tehnoloogiatele,” ütleb Steve Newman, Scalyr'i asutaja ja juhatuse esimees.

Kaasaegses maailmas muutuvad teenused koheselt, kui tekib selline vajadus. Uute funktsioonide pidev rakendamine ja juurutamine on muidugi suurepärane, kuid selle protsessi koordineerimine ja tekkivate probleemide lahendamine on tõeline peavalu, – märgib Steve Newman. – Väga kiiresti arenevates organisatsioonides võitlevad insenerid ristfunktsionaalsete meeskondade koosseisus selle nimel, et säilitada võimalus jälgida muudatusi ja nende põhjustatud kaskadiefekte sõltuvuste tasandil. Veelgi enam, insenerid ei ole sugugi rahul, kui neid sellisest võimalusest ilma jäetakse, mistõttu muutub neil raskemaks mõista tekkivate probleemide olemust.

Kuidas ületada eespool nimetatud raskused ja liikuda suurettevõttes DevOps'i laialdase kasutamise poole? Eksperdid soovitavad varuda kannatust, isegi kui teie lõppeesmärk on kiirendada tarkvaraarenduse ja äriprotsesside tsükleid.

1. Pidage meeles, et kultuurimuutusteks on vajalik aeg.

Jayne Groll, DevOpsi Instituudi tegevjuht: Minu arvates peaks DevOps laienemine olema sama järkjärguline ja iteratiivne kui agile-arendus (ja sama hästi hõlmama kultuuri). Agile ja DevOps keskenduvad väikestele meeskondadele. Kuid kui selliste meeskondade arv kasvab ja nad integreeruvad, saame üha rohkem inimesi, kes rakendavad uusi töötamisviise, ja sellest tulenevalt toimub ulatuslik kultuuri transformatsioon.

2. Pühendage piisavalt aega planeerimisele ja platvormi valikule.

Eran Kinsbruner, Perfecto juhtiv tehniline evangelist: Selleks, et skalaarimine toimiks, peavad DevOps meeskonnad alguses õppima kombineerima traditsioonilisi protsesse, tööriistu ja oskusi ning seejärel aeglaselt kasvatama iga DevOps faasi ning stabiliseerima selle. Kõik algab hoolikast kasutajate lugude (user story) ja väärtusvoogude (value stream) planeerimisest, millele järgneb tarkvara kirjutamise ja versioonihalduse etapp, kasutades trunk-based developmentit või teisi lähenemisviise, mis sobivad kõige paremini koodi harude ja liitmise jaoks.

Seejärgmiseks on integreerimise ja testimise etapp, kus on juba vajalik skaleeritav automatiseerimisplatvorm. DevOpsi meeskondade jaoks on oluline valida õige platvorm, mis vastab nende oskuste tasemele ja projekti lõppeesmärkidele.

Järgmine etapp on produktsiooni keskkonda juurutamine, mis peab olema täielikult automatiseeritud orkestreerimis- ja konteineritööriistade abil. Oluline on omada virtualiseeritud keskkondi kõikides DevOps'i etappides (produksioonikeskkonna simulaator, kvaliteedikontrolli keskkond ja tegelik produktsioonikeskkond) ning alati kasutada testimiseks ainult kõige värskemaid andmeid, et saada asjakohaseid järeldusi. Analüütika peab olema nutikas ja suutma töödelda suuri andmeid kiire ja efektiivse tagasisidega.

3. Vabastage vastutus süüde maitsest

Gordon Haff (Gordon Haff), RedHat'i evangelist: «Katsesüsteemi ja keskkonna loomine, mis lubab ja julgustab katsetusi, võimaldab saavutada nii nimetatud edukaid ebaõnnestumisi agile-tarkvaraarenduses. See ei tähenda, et keegi ei vastuta ebaõnnestumise eest. Tegelikult on vastutaja leidmine isegi lihtsam, kuna 'olla vastutav' ei tähenda enam 'saada süüdistatavaks'. Seega vastutuse olemus muutub kvaliteetselt. Samas on äärmiselt olulised neli tegurit: ebaõnnestumise ulatus, lähenemisviisid, tootmisprotsessid ja stiimulid.» (Lisainfot nende tegurite kohta leiate Gordon Huffi artiklist 'DevOps lessons: 4 aspects of healthy experiments'.)

4. Puhastage tee ettepoole

Ben Grinnell, digitaalsete tehnoloogiate konsultatsioonifirma North Highland tegevjuht ja direktor: «Mastaapse arengu saavutamiseks soovitan koos esmakordsete projektidega käivitada 'tee puhastamise' programmi. Selle programmi eesmärk on eemaldada prügi, mis jääb DevOpsi esmakordsete praktiseerijate järel, nagu aegunud reeglid ja muud sellised asjad, et tee ettepoole jääks vabaks.»

Andke inimestele organisatsioonilist tuge ning edendage suhtlust, mis ulatub kaugemale pioneerigruppidest, tähistades laialdaselt uute töömeetodite edusamme. Koolitage inimesi, kes osalevad järgmise DevOps projektide lainega ning tunnevad ärevust DevOpsi esmakordsel kasutamisel. Ja pidage meeles, et need inimesed on väga erinevad pioneeridest.

5. Muutke tööriistad demokraatlikumaks

Steve Newman, ettevõtte Scalyr asutaja ja juhatuse esimees: «Tööriistu ei tohiks peita inimeste eest ning need peaksid olema suhteliselt lihtsad omandada neile, kes on valmis nende õppimiseks aega kulutama. Kui logide pärimiseks on õigus ainult kolmel inimesele, kes on selle tööriistaga ‘sertifitseeritud’, on teil alati maksimaalselt kolm inimest, kes saavad vastata vastavale probleemile, isegi kui teil on väga suur arvutuslik keskkond. Teisisõnu, siin tekib kitsaskoht, mis võib viia tõsistele (äri)tagajärgedele.»

6. Looge meeskonna tööks ideaalsed tingimused

Tom Clark, ITV telekompanii Common Platformi juht: „Saate teha kõike, aga mitte kõike korraga. Seega seadke suured eesmärgid, alustage väikesest ja liikuge edasi kiirete iteratsioonidega. Aja jooksul teenite te maine, et teie meeskonnal õnnestub, seetõttu soovivad teisedki teie meetodeid kasutada. Ja ärge püüdke luua kõrge tõhususe meeskonda. Selle asemel tagage inimestele ideaalne töökeskkond ning efektiivsus tuleb iseenesest.“

7. Ärge unustage Conway seadust ja kanban-tahvleid

Logan Daigle, CollabNetVersionOne tarkvaraarenduse ja DevOpsi strateegia direktor: „Oluline on mõista Conway seaduse tagajärgi. Minu libedalt kokkuvõttes ütleb see seadus, et tooted, mida me loome, ja protsessid, mida me kasutame, sealhulgas DevOps, on korraldatud sama viisil nagu meie organisatsioon.“

«Kui organisatsioonis valitseb suur killustatus ning tarkvara planeerimisel, loomisel ja väljaandmisel toimub juhtimine järjestikku erinevate kätesse, siis ei saavutata mastaabistumise efekti või see on lühiajaline. Kui aga organisatsioon loob toote ümber ristfunktsionaalseid tiime, mis on turule suunatud, siis tõusevad eduvõimalused oluliselt.»

«Teine oluline aspekt mastaabistumisel on kuvada kanban-tahvlitel kõik pooleliolevad tööd (WIP, work in progress). Kui organisatsioonis on koht, kus inimesed saavad selliseid asju näha, stimuleerib see koostööd väga palju, mis omakorda toetab mastaabistumist positiivselt.»

8. Otsige vana arm

Manuel Pais, DevOps konsultant ja raamatu „Team Topologies“ kaasautor: «DevOps'i praktikate viimine väljapoole DevOps'i enda raamistikku ja nende rakendamine teistesse funktsioonidesse ei ole tõenäoliselt optimaalne lähenemine. See toob muidugi teatud mõju (näiteks käsitsijuhtimise automatiseerimise tõttu), kuid palju rohkem saab saavutada, kui alustada tarnimise- ja tagasisideprotsesside mõistmisest.»

«Kui organisatsiooni IT-süsteemis on vanu arme – haldusprotseduurid ja mehhanismid, mis on rakendatud varasemate juhtumite tõttu, kuid on muutunud ebaoluliseks (toodete, tehnoloogiate või protsesside muutumise tõttu), siis tuleb need kindlasti eemaldada või siluda, mitte automatiseerida ebaefektiivseid või mittevajalikke protsesse».

9. Ära loo DevOps'i variante

Antony Edwards, Eggplanti tootmisdirektor: «DevOps on väga udune termin, seetõttu on igal meeskonnal oma variant DevOps'ist. Pole midagi hullemat, kui organisatsioonis on korraga 20 erinevat DevOps'i varianti, mis omavahel hästi ei sobi. Ei saa lubada, et igal kolmel arendustiimil on oma eriline liides arenduse ja tootemanageerimise vahel. Samuti ei saa lubada, et toodetel on oma, unikaalsed ootused tagasiside töötlemise osas, kui need viiakse tootmisüsteemi simulaatorisse. Muul juhul ei õnnestu teil kunagi DevOps'i skaleerida».

10. Rääkige DevOps'i väärtusest äri jaoks

Steve Newman, ettevõtte Scalyr asutaja ja juhatuse esimees: Töötage DevOpsi väärtuse tunnustamise nimel. Õppige ja ärge kartke rääkida sellest, kuidas teie töö on kasulik. DevOps säästab uskumatult aega ja raha (mõelge: vähem seisakuid, lühem keskmine taastumisaeg), seega peavad DevOps meeskonnad pidevalt rõhutama (ja propageerima) nende algatuste tähtsust äri eduks. Nii suudate laiendada oma järgijate ringi ja tugevdada DevOpsi mõju organisatsioonis.

BOONUS

VDS-l on võimalik installida: Red Hat Foorum Venemaa 13. septembril saabub meie oma DevOps – jah, Red Hat'il, tarkvaratootjana, on oma DevOps meeskonnad ja praktikad.

Meie insener Mark Birger, kes arendab sisemisi automatiseerimisteenuseid teistele gruppidele kogu organisatsioonis, räägib puhtas vene keeles oma lugu – kuidas Red Hati DevOps meeskond migreeris rakendusi virtuaalsetest keskkondadest Hat Virtualization, mida juhib Ansible, täieõiguslikku konteinerivormingusse OpenShift platvormil.

Kuid see pole veel kõik:

Pärast seda, kui organisatsioonid on oma töökoormused konteineritesse viinud, ei pruugi traditsioonilised rakenduste jälgimise meetodid enam toimida. Teises aruandes selgitame, miks me oma logimisviisi muutsime, ja näitame teed, mis viis meid kaasaegsete logimise ja jälgimise meetoditeni.

Allikas: habr.com