Räägime DevOps'ist arusaadavas keeles

Raskus on tuvastada põhiteema, rääkides DevOpsist? Oleme kogunud teile silmapaistvaid analooge, tabavaid väljendeid ja ekspertide nõuandeid, mis aitavad ka mittespetsialistidel mõista, milles asi. Lõpus on boonus – Red Hati töötajate isiklik DevOps.

Termin DevOps ilmus 10 aastat tagasi ning on läbinud teekonna Twitteri hästagist võimsa kultuurilise liikumiseni IT-maailmas, tõeliseks filosoofiaks, mis julgustab arendajaid kiiremini tulemusi saavutama, katsetama ning liikuma edasi iteratiivsete meetoditega. DevOps on muutunud lahutamatuks osaks digitaalsest transformatsioonist. Kuid nagu sageli IT-terminoloogiaga juhtub, on DevOps aastatega kogunud hulgaliselt määratlusi, tõlgendusi ja väärarusaamu.

Seetõttu võite DevOpsist sageli kuulda küsimusi nagu: kas see on sama, mis agile? Või on see mingi eriline metoodika? Või on see lihtsalt sünonüüm sõnale „koostöö“?

DevOps hõlmab palju erinevaid kontseptsioone (pidev kohaletoimetamine, pidev integreerimine, automatiseerimine jne), seetõttu võib peamise eristamine osutuda keeruliseks, eriti kui teema on teile oluline. Siiski on see oskus väga kasulik, olgu te siis püüdes oma ideid ülemusele edastada või lihtsalt rääkides oma tööst pereliikmetele või tuttavatele. Seega, lükake DevOps'i terminoloogilised nüansid hetkeks kõrvale ja keskenduge üldisele pildile.

Mis on DevOps: 6 määratlust ja analoogiat

Palusime spetsialistidel selgitada DevOps'i olemust nii lihtsalt ja lühidalt, et selle väärtus oleks mõistetav iga tasemega tehnilise ettevalmistusega lugejale. Nende vestluste tulemuseks valisime välja kõige silmapaistvamad analoogiad ja tabavad väljendid, mis aitavad teil oma lugu DevOps'ist üles ehitada.

1. DevOps on kultuuriline liikumine

„DevOps on kultuuriline liikumine, kus mõlemad osalised (tarkvaraarendajad ja IT-süsteemide haldajad) tunnistavad, et tarkvara ei too reaalselt kasu, kuni seda ei hakata kasutama: olgu need kliendid, tellijad või töötajad – ütleb Eveline Oehrlich, DevOps Instituudi vanemanalüütik. – Seetõttu tagavad mõlemad pooled koos kiire ja kvaliteetse tarkvara kohaletoimetamise.“

2. DevOps on see, mis annab arendajatele volitused

„DevOps annab arendajatele volitused rakenduste omanikkonnaks, nende käivitamiseks ja juhtimiseks alates algusest kuni lõpuni“

„Tavaliselt räägitakse DevOpsist kui viisist kiirendada rakenduste kohaletoimetamist tootmisse, ehitades ja kasutades automatiseeritud protsesse,“ ütleb Jai Schniepp, Liberty Mutuali kindlustusettevõtte DevOps platvormide direktor. „Kuid minu jaoks on see palju fundamentaalsem asi. DevOps annab arendajatele volitused rakenduste või teatud tarkvarade osade omanikkonnaks, nende käivitamiseks ja kohaletoimetamise juhtimiseks alates algusest kuni lõpuni. DevOps kaotab segaduse vastutuses ja suunab kõik osalised protsessi loomise suunas, milleks on automatiseeritud ja arendaja juhitud infrastruktuur.”

3. DevOps on koostöö rakenduste loomisel ja kohaletoimetamisel

„Lihtsamalt öeldes on DevOps lähenemine tarkvara tootmisele ja kohaletoimetamisele, kus kõik töötavad koos,“ märgib Gur Staff, BMC digitaalsete äriprotsesside automatiseerimise president ja juht.

4. DevOps on konveier

„Konveierikogumine on võimalik ainult siis, kui kõik osad sobivad üksteisega.“

„Võrreldes DevOpsit autotootmise konveieriga,“ jätkab Gur Staff. „Idee on eelnevalt projekteerida ja valmistada kõik osad nii, et need oleksid hiljem võimalik kokku panna ilma individuaalse kohandamiseta. Konveierikogumine on võimalik ainult siis, kui kõik osad sobivad üksteisega. Need, kes projekteerivad ja valmistavad mootorit, peavad mõtlema sellele, kuidas see kinnitada kerele või raami. Need, kes valmistavad pidureid, peavad mõtlema ratastele ja nii edasi. Samuti peaks olema ka tarkvaraga.

Arendaja, kes loob äriülevaate või kasutajaliidese, peab mõtlema andmebaasile, mis sisaldab teavet klientide kohta, andmete kaitseks mõeldud turvameetmetele, samuti sellele, kuidas see kõik töötab, kui teenus hakkab teenindama suurt, võib-olla isegi miljonite kasutajate hulka.

„Teha nii, et inimesed teeksid koostööd ja mõtleksid nende tööosade peale, mida teised teevad, mitte ei keskenduks ainult omaenese ülesannetele – see on suurim takistus, mis tuleb ületada. Kui see õnnestub, on teil suurepärased võimalused digitaalseks transformatsiooniks,“ lisab Gur Staff.

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

Jayne Groll, DevOpsi Instituudi tegevjuht, pakkus suurepärase analoogia DevOpsi seletamiseks. Tema sõnul on „DevOps nagu kulinaarne retsept, milles on kolm peamist koostisosade kategooriat: 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 igas heas retseptis, seisneb selles, kuidas õigesti valida proportsioonid ja segada neid koostisosade, et suurendada töö efektiivsust ja tulemuslikkust rakenduste loomisel ja väljalaskmisel.”

6. DevOps on siis, kui programmeerijad töötavad nagu vormel-1 meeskond.

„Võistlust planeeritakse mitte stardist finišisse, vaid vastupidi, finišist stardisse.“

„Rääkides sellest, mida oodata DevOpsi algatuselt, toon ma näitena NASCAR või vormel-1 võistkonna,“ ütleb Chris Short, Red Hat'i pilveteenuste turundusjuht ja DevOps’ish uudiskirja toimetaja. „Selle võistkonna juhil on üks eesmärk: saavutada võidusõidu lõpus maksimaalne võimalik koht, arvestades võistkonna ressursse ja katsumusi, mis talle on osaks saanud. Sellega seoses on võistlust planeeritud mitte stardist finišisse, vaid vastupidi, finišist stardisse. Alguses seatakse ambitsioonikas eesmärk ja seejärel määratakse vastavad teed selle saavutamiseks. Seejärel jagatakse need alamülesanneteks ja delegatakse tiimiliikmetele.“

„Kogu nädala enne võistlust lihvib meeskond pit-stop'pe. Tegeletakse jõu- ja kardiotreenidega, et olla vormis pingelisel võistluspäeval. Harjutatakse koostööd, et lahendada mis tahes probleeme, mis võivad võistluse ajal tekkida. Samamoodi peavad arendajate meeskonnad harjutama oskusi uute versioonide sagedaseks väljalaskmiseks. Kui need oskused on olemas ja turvasüsteem on paika pandud, toimub uute versioonide lansseerimine tootmisse samuti sagedamini. Selle maailmavaate raames tähendab kiirus tõusu ka turvalisust,“ ütleb Short.

„Asi ei ole teha 'õigeid asju',“ lisab Short, „vaid pigem kõrvaldada võimalikult palju takistusi, mis seisavad tee peal soovitud tulemuse saavutamisele. Koostööd tehke ja kohaneda tuleb tagasisidega, mida saad reaalajas. Olge valmis anomaaliateks ja töötage kvaliteedi tõstmise nimel, et vähendada nende mõju sihile liikumisele. Just seda ootame me DevOpi maailmas.“

Kuidas skaleerida DevOps: 10 ekspertide nõuannet

Lihtne DevOps ja massiline DevOps on täiesti erinevad asjad. Räägime, kuidas ületada takistused selle kahe vahel.

Paljude organisatsioonide jaoks algab tee DevOps'ini lihtsalt ja meeldivalt. Luua saab väikseid kirglikke meeskondi, vanad protsessid asendatakse uutega ja esimesed edusammud ei lase kaua oodata.

Kahjuks on see vaid vale sära, progressi illusioon, nagu ütleb Ben Grinnell, North Highlandi konsultatsioonifirma digitaalsete tehnoloogiate juht. Varajased võidud on kindlasti julgustavad, kuid need ei aita saavutada lõppeesmärki, milleks on DevOps'i massiline kasutuselevõtt organisatsioonis.

On lihtne näha, et selle tulemuseks tekib kultuur, kus jagunetakse 'me' ja 'nemad'.

«Sageli käivitavad organisatsioonid selliseid pioneerprojekte, arvates, et need rajavad teed laialdasele DevOps'ile, mõtlemata sellele, kas teised soovivad ja suudavad sellel teel käia, - selgitab Ben Greennell. - Need projektide meeskonnad koosnevad tavaliselt enesekindlatest "väravatest", kes on varem sarnaseid asju teinud, kuid on teie organisatsioonis alles algajad. Neid julgustatakse rikkuma ja hävitama reegleid, mis kehtivad kõigile teistele. On lihtne näha, et selle tulemusena tekib "meie" ja "nemad" kultuur, mis takistab teadmiste ja oskuste jagamist."

«Ja see kultuuriline probleem on vaid üks põhjustest, miks DevOps'i on keeruline skaleerida. DevOps'i meeskonnad seisavad silmitsi tehniliste keerukustega, mis on iseloomulikud kiiresti arenevatele ettevõtetele, kes on panustanud IT-tehnoloogiale,« ütleb Steve Newman, ettevõtte Scalyr kaasasutaja ja juhatuse esimees.

«Kaasaegses maailmas muutuvad teenused kohe, kui tekib vajadus. Uute funktsioonide pidev rakendamine ja juurutamine on muidugi suurepärane, kuid selle protsessi koordineerimine ja tekkivate probleemide lahendamine on tõeline peavalu,« lisab Steve Newman. - Väga kiiresti kasvavates organisatsioonides võitlevad insenerid ristfunktsionaalsetes meeskondades võimaluse nimel jälgida muudatusi ja nende tekitatud kaskaade sõltuvustasandil. Veelgi enam, inseneridele ei meeldi, kui nad sellest võimalusest ilma jäävad ja seetõttu on neil raskem aru saada tekkivate probleemide olemusest."

Kuidas ületada eespool kirjeldatud raskused ja liikuda DevOps'i massilise kasutuselevõtu poole suure organisatsiooni raames? Eksperdid kutsuvad üles olema kannatlikud, isegi kui teie lõppeesmärk on kiirendada tarkvaraarenduse ja äriprotsesside tsüklit.

1. Pidage meeles, et kultuuri muutmiseks on vaja aega

Jayne Groll, DevOpsi instituudi tegevjuht: Minu arvates peaks DevOps'i laienemine olema sama järkjärguline ja iteratiivne kui agile-arendamine (ning mõjutama kultuuri sama palju). Agile'is ja DevOps'is keskendutakse väikestele meeskondadele. Kuid kui nende meeskondade arv kasvab ja nad integreeruvad, on üha rohkem inimesi, kes rakendavad uusi töömeetodeid, ja sellest tulenevalt toimub ulatuslik kultuuriline transformatsioon.

2. Pöörake piisavalt aega planeerimisele ja platvormi valimisele

Eran Kinsbruner, Perfecto juhtiv tehniline evangelist: „Et skaleerimine töötaks, peavad DevOps'i meeskonnad alguses õppima kombineerima traditsioonilisi protsesse, tööriistu ja oskusi ning seejärel järk-järgult kasvatama igat DevOps'i etappi ja stabiliseerima seda. Kõik algab hoolikast kasutajate lugude (user story) ja väärtuse loomise voogude (value stream) planeerimisest, millele järgneb tarkvara kirjutamine ja versioonihaldus trunk-based development'i või teiste lähenemisviiside abil, mis on kõige sobivamad koodi harude ja sulandumise jaoks.”

„Järgneb integratsiooni ja testimise etapp, kus on juba vajalik skaleeritav automaatikaplatvorm. Siin on DevOps'i meeskondade jaoks oluline valida õige platvorm, mis vastab nende oskuste tasemele ja projekti lõppeesmärkidele.

Järgmine etapp on juurutamine tootmiskeskkonnas, mis peaks olema täielikult automatiseeritud, kasutades orkestreerimise ja konteinerite tööriistu. Oluline on omada virtualiseeritud keskkondi kõigis DevOps'i etappides (tootmiskeskkonna simulaator, kvaliteedikontrolli keskkond ja tegelik tootmiskeskkond) ning alati kasutada testimisteks vaid kõige värskemaid andmeid, et saada asjakohaseid järeldusi. Analüütika peab olema nutikas ja suutma töödelda suuri andmeid kiire ja tõhusaga tagasiside saamiseks.”

3. Vabastage vastutus süü eest

Gordon Haff, RedHati evangelist: „Süsteemi ja atmosfääri loomine, mis lubab ja julgustab katsetamist, võimaldab saavutada nn edukaid ebaõnnestumisi agile tarkvaraarenduses. See ei tähenda, et keegi ei vastuta ebaõnnestumiste eest. Tegelikult on vastutuse määramine isegi lihtsam, kuna „vastutav” ei tähenda enam „õnnetuse põhjustaja” olemist. Seega vastutuse olemus muutub kvaliteetselt. Samuti saavad äärmiselt tähtsaks neli tegurit: ebaõnnestumise ulatus, lähenemisviisid, tootmisprotsessid ja stiimulid“. (Nende tegurite kohta saab lähemalt lugeda Gordon Huffs artiklist „DevOps lessons: 4 aspects of healthy experiments“.)

4. Puhastage tee edasi

Ben Grinnell, North Highlandi konsultatsioonifirma digitaalsete tehnoloogiate direktor: „Skaaleerimise saavutamiseks soovitan koos esmakordsete projektidega käivitada „tee puhastamise” programmi. Selle programmi eesmärk on eemaldada prügi, mis jääb DevOpsi esmakordsetelt, nagu aegunud reeglid ja muud sarnased asjad, et tee edasi jääks vaba.“

„Andke inimestele organisatsioonilist tuge ja andke hoogu suhtlusega, mis ulatub kaugele esmakordsete rühmadest, tähistades uute töötamisviiside edusamme laialdaselt. Koolitage inimesi, kes on järgmise DevOpsi projektide laine sees ja tunnevad ärevust, kuna nad kasutavad DevOpsit esmakordselt. Ja pidage meeles, et need inimesed on väga erinevad esmakordsetest.“

5. Tehke tööriistad demokraatlikumaks

Steve Newman, Scalyr'i asutaja ja juhatuse esimees: „Tööriistu ei tohi inimestelt varjata ja need peaksid olema suhteliselt lihtsad igaleühele, kes on valmis aega investeerima. Kui logide pärimise võimalus on antud vaid kolmele inimesele, kellel on „sertifikaat” mõne tööriista kasutamiseks, on teil alati maksimaalselt kolm inimest, kes suudavad lahendada vastava probleemi, isegi kui teil on väga suur arvutikeskkond. Teisisõnu, see tekitab kitsas koha, mis võib tuua tõsiseid (äri)tagajärgi.“

6. Looge ideaaltingimused meeskonna tööks

Tom Clark, ITV Common Platformi juht: „Saate teha, mida iganes soovite, kuid mitte kõike korraga. Seetõttu seadke endale suured eesmärgid, alustage väikesest ja liikuge kiirete iteratsioonidega edasi. Aja jooksul teenite maine meeskonnana, kellel kõik õnnestub, mistõttu tahavad teisedki kasutada teie meetodeid. Ja ärge püüdke luua kõrgelt efektiivset meeskonda. Keskenduge sellele, et pakkuda inimestele ideaalsed töötingimused, ja efektiivsus tuleb iseenesest.“

7. Ärge unustage Conway seadust ja kanbani tahvleid

Logan Daigle, CollabNetVersionOne'i tarkvaratoote ja DevOpsi strateegia direktor: „Oluline on teadvustada Conway seaduse tagajärgi. Minu vabas tõlkes ütleb see seadus, et tooted, mida me loome, ja protsessid, mida me selle käigus rakendame, sealhulgas DevOps, on organiseeritud samamoodi nagu meie organisatsioon.”

„Kui organisatsioonis on kõrge killustatus ning tarkvaraarenduse planeerimisel, loomisel ja väljaandmisel vahetatakse juhtimine korduvalt käest käesse, siis on skaleerimise efekt null või lühiajaline. Kui aga organisatsioon loob ristfunktsionaalsed meeskonnad toodete ümber, mis on finantseeritud turule orienteeritult, siis tõuseb eduvõimalus järsult.”

„Veel üks oluline aspekt skaleerimises on kuvada kanbani tahvlitel kõik tööd, mis on pooleli (WIP, work in progress). Kui organisatsioonis on koht, kus inimesed saavad neid asju näha, stimuleerib see tugevalt koostööd, mis omakorda avaldab positiivset mõju skaleerimisele.”

8. Otsige vanu arme

Manuel Pais, DevOpsi konsultant ja raamat „Team Topologies” kaasautor: „DevOps praktikate viimine väljapoole DevOps'i endi ja nende rakendamine teistesse funktsioonidesse ei ole ilmselt optimaalne lähenemine. See toob kindlasti mõningast kasu (nt tänu käsitsi haldamise automatiseerimisele), kuid palju rohkemat saab saavutada, kui alustada arusaamisest toimetamise ja tagasiside protsessidest.”

Kui organisatsiooni IT-süsteemis on vanad armid – haldusprotseduurid ja mehhanismid, mis on ellu viidud möödunud intsidendi tagajärjel, kuid on oma kehtivuse kaotanud (toodete, tehnoloogiate või protsesside muutumise tõttu), siis tuleb need kindlasti eemaldada või siluda, mitte automatiseerida ebaefektiivseid või tarbetuid protsesse.

9. Ärge looge DevOps'i erinevaid variante.

Antony Edwards, Eggplant'i tootmisdirektor: „DevOps on äärmiselt ebamugav termin, mistõttu iga meeskond tõlgendab seda omamoodi. Pole midagi hullemat kui see, et organisatsioonis on korraga 20 erinevat DevOps'i varianti, mis ei suudagi hästi koos eksisteerida. Ei tohi lubada, et igal kolmel arendajameeskonnal on oma ainulaadne liides arenduse ja tootehalduse vahel. Samuti ei tohi lasta toodetel omada unikaalseid ootusi tagasiside töötlemisel tootmisimulatsiooni keskkonda üleviimisel. Vastasel juhul ei suuda te kunagi DevOps'i skaleerida.”

10. Tutvustage DevOps'i väärtust äri jaoks.

Steve Newman, Scalyr'i asutaja ja juhatuse esimees: „Töötage DevOps'i väärtuse tunnustamise nimel. Õppige ja ärge kartke rääkida, kui kasulik see, mida teete, on. DevOps säästab uskumatult aega ja raha (kõigest mõelge: vähem seisaegasid, lühem keskmine taastumisaeg), ja DevOps'i meeskonnad peavad pidevalt rõhutama (ja esitlema) nende algatuste tähtsust ettevõtte edule. Nii saate laiendada DevOps'i pooldajaid ja suurendada selle mõju organisatsioonis.”

BONUS

Pealehe Red Hat Foorum Venemaa 13. septembril tuleb meie enda DevOps - jah, Red Hat'il, kui tarkvaratootjal, on omad DevOps'i meeskonnad ja praktika.

Meie insener Mark Birger, kes tegeleb sisemiste automatiseerimisteenuste arendamisega teistele rühmadele kogu organisatsioonis, räägib puhtal vene keeles oma loo - kuidas Red Hat'i DevOps'i meeskond migreeris rakendused virtuaalsetest keskkondadest Hat Virtualization, mida haldab Ansible, täisväärtuslikku konteineriformaati OpenShift'i platvormil.

Kuid see pole veel kõik:

Pärast seda, kui organisatsioonid on oma töökoormused konteineritesse viinud, võivad traditsioonilised rakenduste jälgimise meetodid mitte töötada. Teises aruandes selgitame, miks me otsustasime registreerimise viisi muuta, ja näitame teed, mis viis meid kaasaegsete logimise ja jälgimise meetoditeni.

Allikas: habr.com