Ťažko uchopiť podstatu, keď hovoríme o DevOps? Zhromaždili sme pre vás jasné analógie, úderné formulácie a rady od expertov, ktoré pomôžu preniknúť do podstaty aj laikom. Na konci vás čaká bonus – vlastný DevOps zamestnancov Red Hat.
Termín DevOps vznikol pred 10 rokmi a prešiel cestou od hashtag-u na Twitteri k mocnému kultúrnemu hnutiu vo svete IT, skutočnej filozofie, ktorá povzbudzuje vývojárov rýchlejšie dosahovať výsledky, experimentovať a postúpiť vpred metodou iterácií. DevOps sa stal neodmysliteľne spojený s pojmom digitálna transformácia. Ale ako to už býva s IT terminológiou, za desať rokov sa DevOps obohatil o množstvo definícií, výkladov a omylov.
Preto môžeme často počuť otázky o DevOps, ako napríklad, či je to to isté ako agile? Alebo je to nejaká špeciálna metodológia? Alebo je to len ďalší synonymum pre slovo „spolupráca“?
DevOps zahŕňa mnoho rôznych konceptov (nepretržitá dodávka, nepretržitá integrácia, automatizácia atď.), preto môže byť ťažké vybrať podstatu, najmä ak vám na téme záleží. Avšak, táto schopnosť je veľmi užitočná, bez ohľadu na to, či sa snažíte pretlačiť svoje nápady nadriadeným alebo len rozprávate o svojej práci niekomu z rodiny alebo známych. Preto odložíme na bok terminologické nuansy DevOps a zameriame sa na celkový obraz.
Čo je DevOps: 6 definícií a analógií
Požiadali sme odborníkov, aby vysvetlili podstatu DevOps čo najjednoduchsie a najstručnejšie, aby bola jej hodnota zrozumiteľná čitateľom s akoukoľvek úrovňou technickej prípravy. Z týchto rozhovorov sme vybrali najjasnejšie analógie a úderné formulácie, ktoré vám pomôžu zostaviť váš príbeh o DevOps.
1. DevOps – to je kultúrne hnutie
„DevOps – to je kultúrne hnutie, v rámci ktorého obe strany (vývojári softvéru a odborníci na prevádzku IT systémov) uznávajú, že softvér neposkytuje skutočný prínos, pokiaľ s ním nezačne niekto pracovať: objednávatelia, zákazníci, zamestnanci, to nie je podstatné,“ hovorí Evelina Oehrlich, vedúca analytik výskumu Inštitútu DevOps. „Preto tieto dve strany spoločne zabezpečujú rýchlu a kvalitnú dodávku softvéru.“
2. DevOps – to je to, čo dáva moc vývojárom
„DevOps umožňuje vývojárom mať kontrolu nad aplikáciami, ich nasadením a správou dodávky od začiatku až do konca“
„O DevOps sa zvyčajne hovorí ako o spôsobe, ako urýchliť dodávku aplikácií do produkcie prostredníctvom budovania a implementácie automatizovaných procesov,“ hovorí Jai Schniepp, riaditeľ platforiem DevOps v poisťovni Liberty Mutual. „Ale pre mňa je to oveľa fundamentálnejšia vec. DevOps umožňuje vývojárom mať kontrolu nad aplikáciami alebo určitými časťami softvéru, nad ich nasadením a správou dodávky od začiatku až do konca. DevOps odstráňuje chaos z zodpovednosti a vedie všetkých účastníkov procesu k vytváraniu automatizovanej a vývojárom riadenej infraštruktúry.“
3. DevOps je spolupráca pri vytváraní a dodávaní aplikácií
„Jednoducho povedané, DevOps je prístup k výrobe a dodávke softvéru, kde všetci pracujú spolu,“ poznamenáva Gur Staff, prezident a vedúci divízie automatizácie digitálneho podnikania vo firme BMC.
4. DevOps je výrobný proces
„Výrobné procesy sú možné len vtedy, ak všetky časti do seba zapadajú.“
„Porovnal by som DevOps s výrobou automobilov,“ pokračuje Gur Staff. „Idea spočíva v tom, že všetky časti by mali byť navrhnuté a vyrobené vopred tak, aby sa dali spolu zostaviť bez individuálneho prispôsobenia. Výrobné procesy sú možné len vtedy, ak všetky časti do seba zapadajú. Tí, ktorí navrhujú a vyrábajú motor, musia uvažovať o tom, ako ho pripevniť k karosérii alebo rámu. Tí, ktorí vyrábajú brzdy, musia premýšľať o kolesách, a tak ďalej. Rovnako by to malo byť aj so softvérom.
Vývojár, ktorý vytvára obchodnú logiku alebo používateľské rozhranie, by mal premýšľať o databáze, ktorá uchováva informácie o zákazníkoch, a o bezpečnostných prostriedkoch na ochranu užívateľských dát, ako aj o tom, ako to všetko bude fungovať, keď služba začne obsluhovať veľké, možno aj miliónové publikum užívateľov.“
„Urobiť to tak, aby ľudia spolupracovali a mysleli na tie časti práce, ktoré vykonávajú iní, a nie sa sústredili výlučne na svoje vlastné úlohy – to je najväčšia prekážka, ktorú treba prekonať. Ak sa to podarí, máte skvelé šance na digitálnu transformáciu,“ dodáva Gur Staff.
5. DevOps je správna kombinácia ľudí, procesov a automatizácie
Jayne Groll, výkonná riaditeľka Inštitútu DevOps, navrhla vynikajúcu analógiu na vysvetlenie DevOps. Podľa jej slov, „DevOps je ako kuchársky recept, v ktorom sú tri základné kategórie ingrediencií: ľudia, procesy a automatizácia. Väčšinu týchto ingrediencií je možné získať z iných oblastí a zdrojov: Lean, Agile, SRE, CI/CD, ITIL, leadership, kultúra, nástroje. Tajomstvo DevOps, rovnako ako každého dobrého receptu, spočíva v tom, ako správne doladiť proporcie a zmiešať tieto ingrediencie, aby sa zvýšila rýchlosť a účinnosť práce pri vytváraní a vydávaní aplikácií.“
6. DevOps je, keď programátori pracujú ako tím Formuly 1
„Preteky sa plánujú nie od štartu k cieľu, ale naopak, od cieľa k štartu.“
„Pokiaľ ide o to, čo očakávať od iniciatívy DevOps, dávam príklad pretekárskeho tímu NASCAR alebo Formuly 1,“ hovorí Chris Short, hlavný marketingový manažér cloudových platforiem Red Hat a vydavateľ bulletinu DevOps’ish. „Cieľom takého tímu je obsadiť čo najvyššie možné miesto na základe zdrojov, ktoré tím mal k dispozícii, a skúšok, ktorým čelil. Preteky sa plánujú nie od štartu k cieľu, ale naopak, od cieľa k štartu. Najprv sa stanoví ambiciózny cieľ a potom sa určia cesty k jeho dosiahnutiu. Potom sa rozdelia na podúlohy a delegujú členom tímu.“
„Celý týždeň pred pretekmi tím zdokonaluje pit-stop. Zaoberajú sa silovými a kardiotréninkami, aby boli vo forme v náročný deň pretekov. Cvičia spoločné akcie pri riešení akýchkoľvek problémov, ktoré sa môžu na pretekoch vyskytnúť. Podobne by sa vývojový tím mal cvičiť v schopnostiach častého uvoľňovania nových verzií. S takýmito zručnosťami a vyladeným bezpečnostným systémom sa nasadenie nových verzií do produkcie tiež uskutočňuje častejšie. V rámci tohto pohľadu rast rýchlosti znamená rast bezpečnosti,” hovorí Short.
„Nejde o to robiť ‚správne veci‘, – dodáva Short, – ale o to, aby ste odstránili čo najviac prekážok, ktoré stoja medzi vami a požadovaným výsledkom. Spolupracujte a prispôsobujte sa podľa spätnej väzby, ktorú dostávate v reálnom čase. Buďte pripravení na anomálie a pracujte na zvyšovaní kvality, aby ste minimalizovali ich vplyv na smerovanie k cieľu. To je to, čo nás čaká vo svete DevOps.“
Ako škálovať DevOps: 10 rád od expertov
Jednoduchý DevOps a masový DevOps sú úplne rôzne veci. Povieme vám, ako prekonať prekážky na ceste od jedného k druhému.
Pre mnohé organizácie je cesta k DevOps jednoduchá a príjemná. Vznikajú malé nadšené tímy, staré procesy sú nahradené novými a prvé úspechy nenechajú na seba dlho čakať.
Bohužiaľ, toto je len falošný lesk, ilúzia pokroku, ako hovorí Ben Grinnell, managing director a vedúci oblasti digitálnych technológií konzultačnej firmy North Highland. Skoré víťazstvá sú síce povzbudzujúce, ale nepomáhajú dosiahnuť konečný cieľ, ktorým je masové využívanie DevOps v organizácii.
Ľahko možno vidieť, že sa formuje kultúra rozdelenia na „my“ a „oni“.
„Organizácie často spúšťajú takéto priekopnícke projekty s presvedčením, že prelomia cestu k masovému DevOps, bez toho, aby premýšľali, či to ostatní budú ochotní a schopní urobiť,“ vysvetľuje Ben Greenell. „Tímy na realizáciu takýchto projektov sa zvyčajne skladajú z presvedčených „vikingov“, ktorí už podobné veci robili inde, ale sú nováčikmi vo vašej organizácii. Navyše sú povzbudzovaní, aby porušovali a rušili pravidlá, ktoré sú pre všetkých ostatných stále záväzné. Jednoducho je jasné, že takto sa formuje kultúra rozdeľovania na „my“ a „oni“, ktorá bráni prenosu znalostí a zručností.“
„A tento kultúrny problém je len jedna z príčin, prečo je ťažké škálovať DevOps. Tímy DevOps sa stretávajú s rastom čisto technických zložitostí, ktoré sú charakteristické pre rýchlo rastúce spoločnosti, ktoré stavili na IT technológie,“ hovorí Steve Newman, zakladateľ a predseda predstavenstva spoločnosti Scalyr.
„V modernej dobe sa služby menia hneď, len čo sa objaví taká potreba. Neustále implementovať a zavádzať nové funkcie je určite skvelé, ale koordinácia tohto procesu a riešenie vznikajúcich problémov sú naozaj veľkou hlavolamom,“ dodáva Steve Newman. „V rýchlo rastúcich organizáciách sa inžinieri v rámci krížovo-funkčných tímov snažia udržať si schopnosť sledovať zmeny a kaskádové efekty, ktoré z nich vyplývajú na úrovni závislostí. Navyše, inžinierom rozhodne nie je po chuti, keď sú o túto schopnosť pripravení, čo sťažuje porozumenie základným problémom.“
Ako prekonávať vyššie uvedené ťažkosti a prejsť na masové využívanie DevOps v veľkej organizácii? Odborníci vyzývajú k trpezlivosti, aj keď vaším konečným cieľom je urýchliť softvérový vývoj a obchodných procesov.
1. Pamätajte, že na zmeny v kultúre je potrebný čas
Jayne Groll, výkonná riaditeľka Inštitútu DevOps: Podľa mňa by rozšírenie DevOps malo byť rovnaké postupné a iteratívne, ako je agilný vývoj (a rovnako by sa malo dotknúť kultúry). V Agile a DevOps sa kladie dôraz na malé tímy. Avšak s rastom počtu a integráciou týchto tímov vidíme čoraz viac ľudí, ktorí uplatňujú nové pracovné metódy, a ako výsledok dochádza k rozsiahlej kultúrnej transformácii.
2. Venovať dostatok času plánovaniu a výberu platformy
Eran Kinsbruner, vedúci technický evanjelista spoločnosti Perfecto: Aby sa skalovanie úspešne uskutočnilo, musia sa tímy DevOps najprv naučiť kombinovať tradičné procesy, nástroje a zručnosti, a potom pomaly rozvíjať každú jednotlivú fázu DevOps a stabilizovať ju. Všetko to začína dôkladným plánovaním používateľských príbehov a tokov vytvárania hodnoty, po ktorom nasleduje etapa písania softvéru a správy verzií pomocou trunk-based development alebo iných prístupov, ktoré najlepšie vyhovujú pre vetvenie a zlúčenie kódu.
Následne prichádza fáza integrácie a testovania, kde je už potrebná škálovateľná platforma na automatizáciu. A tu je pre tímy DevOps dôležité zvoliť správnu platformu, ktorá zabezpečí ich úroveň zručností a konečné ciele projektu.
Nasledujúca fáza je nasadenie do produkčného prostredia, ktoré musí byť úplne automatizované s využitím orkestrátorských nástrojov a kontajnerov. Dôležité je mať virtualizované prostredia vo všetkých fázach DevOps (simulátor produkčného prostredia, prostredie kontroly kvality a samotné produkčné prostredie) a vždy na testovanie používať len najnovšie dáta, aby sme získali aktuálne závery. Analytika by mala byť inteligentná a schopná spracovávať veľké dáta s rýchlou a efektívnou spätnou väzbou.
3. Zbavte sa zodpovednosti bez pocitu viny
Gordon Haff, evanjelista RedHat: „Vytvorenie systému a atmosféry, ktorá povoľuje a povzbudzuje experimentovanie, umožňuje realizovať takzvané úspešné zlyhania v agile vývoji softvéru. Neznamená to však, že za zlyhania už nikto nezodpovedá. V skutočnosti je určiť zodpovedného ešte jednoduchšie, pretože „byť zodpovedným“ už neznamená „stať sa vinníkom havárie“. To znamená, že podstata zodpovednosti sa kvalitne mení. Pri tom sa mimoriadne dôležitými stávajú štyri faktory: rozsah zlyhania, prístupy, výrobné procesy a stimuly.“ (Viac o týchto faktoroch si môžete prečítať v článku Gordona Haffa „DevOps lessons: 4 aspects of healthy experiments“.)
4. Uvoľnite cestu vpred
Ben Grinnell, managing director a vedúci sekcie digitálnych technológií konzultantskej firmy North Highland: „Aby sa dosiahlo škálovanie, odporúčam spustiť program „uvoľňovania cesty“ spolu s priekopníckymi projektmi. Cieľom tohto programu je odstrániť odpad, ktorý zostáva za priekopníkmi DevOps, ako sú neaktuálne pravidlá a iné podobné záležitosti, aby cesta vpred zostala voľná.“
„Poskytnite ľuďom organizačnú podporu a povzbudzujte komunikáciu, ktorá presahuje skupinu priekopníkov, široko oslavujúc úspechy nových pracovných metód. Vzdelávajte ľudí zapojených do nasledujúcej vlny projektov DevOps, ktorí sa obávajú, že prvýkrát používajú DevOps. A pamätajte, že títo ľudia sa výrazne líšia od priekopníkov.“
5. Urobte nástroje prístupnejšími
Steve Newman, zakladateľ a predseda predstavenstva spoločnosti Scalyr: „Nástroje by nemali byť skryté pred ľuďmi a mali by byť relatívne jednoduché na zvládnutie pre každého, kto je ochotný venovať tomu čas. Ak je možnosť žiadať o logy poskytnutá iba trom ľuďom „certifikovaným“ na prácu s určitým nástrojom, vždy budete mať maximálne troch ľudí, ktorí sú schopní poradiť si s daným problémom, aj keď máte veľmi veľké výpočtové prostredie. Inými slovami, tu vzniká úzky bod, ktorý môže mať vážne (pre podnik) následky.“
6. Vytvorte ideálne podmienky na prácu tímu
Tom Clark, vedúci sekcie Common Platform v telekomunikačnej spoločnosti ITV: „Môžete robiť čokoľvek, ale nie všetko naraz. Preto si stanovte veľké ciele, začnite s malými krokmi a posúvajte sa vpred rýchlymi iteráciami. S časom si vybudujete reputáciu tímu, ktorý všetko zvláda, a tak budú chcieť aj ostatní využiť vaše metódy. A nehnajte sa za vytváraním vysoko výkonného tímu. Namiesto toho zabezpečte ľuďom ideálne podmienky na prácu a efektivita príde sama.“
7. Nezabúdajte na Conwayov zákon a kanbanové tabule
Logan Daigle, riaditeľ pre dodávanie softvéru a DevOps stratégiu spoločnosti CollabNetVersionOne: „Je dôležité uvedomiť si dôsledky Conwayovho zákona. V mojom voľnom preklade tento zákon hovorí, že produkty, ktoré vytvárame, a procesy, ktoré pri tom používame, vrátane DevOps, sú usporiadané rovnako ako naša organizácia.“
„Ak je v organizácii vysoká roztrhnutosť a pri plánovaní, vytváraní a vydávaní softvéru sa riadenie mnohokrát prenáša z rúk do rúk, efekt škálovania bude nulový alebo krátkodobý. Ak však organizácia vytvára krížovo-funkčné tímy okolo produktov financovaných s orientáciou na trh, šance na úspech rapídne vzrastajú.“
„Ďalší dôležitý aspekt škálovania spočíva v tom, aby všetky práce, ktoré sú v procese vykonávania (WIP, work in progress), boli viditeľné na kanbanových tabuliach. Keď sa v organizácii objaví miesto, kde môžu ľudia vidieť takéto veci, silno to stimuluje spoluprácu, čo pozitívne ovplyvňuje škálovanie.“
8. Hľadajte staré jazvy
Manuel Pais, konzultant pre DevOps a spoluautor knihy „Team Topologies“: „Zavádzať praktiky DevOps za hranice Dev a Ops a pokúšať sa ich aplikovať na iné funkcie nie je optimálny prístup. Toto určite prinesie určité účinky (napr. vďaka automatizácii ručného riadenia), ale oveľa viac možno dosiahnuť, ak začneme pochopením procesov dodávania a spätnej väzby“.
Ak v IT systéme organizácie existujú staré jazvy - postupy a mechanizmy riadenia, ktoré boli zavedené na základe predchádzajúcich incidentov, ale stratili aktuálnosť (kvôli zmene produktov, technológií alebo procesov), mali by sa bezpodmienečne odstrániť alebo vyhladiť, a nie automatizovať neefektívne alebo nepotrebné procesy.
9. Nepodporujte rôzne varianty DevOps
Antony Edwards, riaditeľ výroby spoločnosti Eggplant: „DevOps je veľmi neurčitý pojem, a preto má každé tím svoje vlastné varianty DevOps. A nie je nič horšie, keď v organizácii vznikne hneď 20 rôznych variantov DevOps, ktoré sa veľmi dobre nezhodujú. Nemôže to byť tak, že každé z troch vývojárskych tímov bude mať svoj špeciálny rozhranie medzi vývojom a riadením produktu. Rovnako nemôže byť, aby produkty mali svoje vlastné jedinečné očakávania týkajúce sa spracovania spätnej väzby pri presune do simulátora výrobného prostredia. Inak nikdy nebudete schopní škálovať DevOps.“
10. Propagujte hodnotu DevOps pre biznis
Steve Newman, zakladateľ a predseda predstavenstva spoločnosti Scalyr: „Pracujte na uznaní hodnoty DevOps. Naučte sa a nebojte sa hovoriť o užitočnosti toho, čo robíte. DevOps nesmierne šetrí čas a peniaze (len si pomyslite: menej prestojov, kratšia priemerná doba zotavenia), a tímy DevOps by mali neustále zdôrazňovať (a propagovať) dôležitosť týchto iniciatív pre úspech biznisu. Tak si môžete rozšíriť okruh stúpencov a posilniť vplyv DevOps v organizácii.“
BONUS
Na 13. septembra príde náš vlastný DevOps – áno, Red Hat má ako výrobca softvéru svoje vlastné DevOps tím a prax.
Náš inžinier Mark Birger, ktorý sa zaoberá vývojom služieb vnútornej automatizácie pre iné skupiny v celej organizácii, na čistej ruštine rozpráva svoju vlastnú príbeh – ako tím DevOps Red Hat migroval aplikácie z virtuálnych prostredí Hat Virtualization, spravovaných Ansible, do plnohodnotného kontajnerového formátu na platforme OpenShift.
Ale to ešte nie je všetko:
Akonáhle organizácie presunuli pracovné zaťaženia do kontajnerov, tradičné metódy monitorovania aplikácií môžu zlyhať. V druhej správe vysvetlíme našu motiváciu zmeniť spôsob registrácie a ukážeme pokračovanie cesty, ktorá nás priviedla k moderným metódam vedenia záznamov a monitorovania.
Zdroj: habr.com
