Je ťažké pochopiť hlavný bod, keď hovoríme o DevOps? Zozbierali sme pre vás živé analógie, nápadné formulácie a rady od odborníkov, ktoré pomôžu aj laikom dostať sa k veci. Bonusom sú nakoniec vlastné DevOps zamestnancov Red Hat.
Termín DevOps vznikol pred 10 rokmi a prešiel z hashtagu na Twitteri na silné kultúrne hnutie vo svete IT, čo je skutočná filozofia, ktorá nabáda vývojárov, aby robili veci rýchlejšie, experimentovali a opakovali sa vpred. DevOps sa stal neoddeliteľne spojený s konceptom digitálnej transformácie. Ale ako sa to často stáva s IT terminológiou, za posledných desať rokov DevOps získalo mnoho definícií, interpretácií a mylných predstáv o sebe.
Preto môžete často počuť otázky o DevOps, ako napríklad, je to rovnaké ako agile? Alebo je to nejaká špeciálna metodika? Alebo je to len ďalšie synonymum pre slovo „spolupráca“?
DevOps zahŕňa mnoho rôznych konceptov (nepretržité doručovanie, nepretržitá integrácia, automatizácia atď.), takže destilácia toho, čo je dôležité, môže byť náročné, najmä ak ste pre túto tému nadšení. Táto zručnosť je však veľmi užitočná, bez ohľadu na to, či sa snažíte sprostredkovať svoje nápady nadriadeným alebo jednoducho o svojej práci hovoríte niekomu z rodiny alebo priateľov. Odložme preto nateraz terminologické nuansy DevOps a zamerajme sa na celkový obraz.
Čo je DevOps: 6 definícií a analógií
Požiadali sme odborníkov, aby čo najjednoduchšie a najstručnejšie vysvetlili podstatu DevOps, aby bola jeho hodnota jasná čitateľom s akoukoľvek úrovňou technických znalostí. Na základe výsledkov týchto rozhovorov sme vybrali tie najpozoruhodnejšie analógie a nápadné formulácie, ktoré vám pomôžu vybudovať váš príbeh o DevOps.
1. DevOps je kultúrne hnutie
„DevOps je kultúrne hnutie, v ktorom obe strany (vývojári softvéru a špecialisti na prevádzku IT systémov) uznávajú, že softvér neprináša skutočné výhody, kým ho niekto nezačne používať: zákazníci, klienti, zamestnanci, nie to podstatné,“ hovorí Eveline Oehrlich, senior research. analytik inštitútu DevOps. "Preto obe tieto strany spoločne zabezpečujú rýchle a kvalitné dodanie softvéru."
2. DevOps je o posilnení postavenia vývojárov.
„DevOps umožňuje vývojárom vlastniť aplikácie, spúšťať ich a riadiť poskytovanie od začiatku do konca.“
„Zvyčajne sa o DevOps hovorí ako o spôsobe, ako urýchliť dodávanie aplikácií do výroby vytvorením a implementáciou automatizovaných procesov,“ hovorí Jai Schniepp, riaditeľ platforiem DevOps v poisťovni Liberty Mutual. "Ale pre mňa je to oveľa zásadnejšia vec." DevOps umožňuje vývojárom vlastniť aplikácie alebo špecifické časti softvéru, spúšťať ich a riadiť ich poskytovanie od začiatku do konca. DevOps eliminuje zmätok v zodpovednosti a vedie každého, kto sa podieľa na vytváraní automatizovanej infraštruktúry riadenej vývojármi.
3. DevOps je o spolupráci pri vytváraní a dodávaní aplikácií.
„Jednoducho povedané, DevOps je prístup k výrobe a dodávaniu softvéru, kde všetci spolupracujú,“ hovorí Gur Staf, prezident a vedúci automatizácie digitálneho podnikania v BMC.
4. DevOps je plynovod
"Montáž dopravníka je možná len vtedy, ak všetky diely do seba zapadajú."
„DevOps by som prirovnal k montážnej linke automobilov,“ pokračuje Gur Staff. – Myšlienkou je navrhnúť a vyrobiť všetky diely vopred, aby sa potom dali zmontovať bez individuálneho nastavovania. Montáž dopravníka je možná len vtedy, ak všetky diely do seba zapadajú. Tí, ktorí navrhujú a vyrábajú motor, musia zvážiť, ako ho namontovať na karosériu alebo rám. Tí, ktorí vyrábajú brzdy, musia myslieť na kolesá atď. To isté by malo platiť so softvérom.
Vývojár vytvárajúci obchodnú logiku alebo používateľské rozhranie musí myslieť na databázu, v ktorej sú uložené informácie o zákazníkoch, na bezpečnostné opatrenia na ochranu používateľských údajov a na to, ako to všetko bude fungovať, keď služba začne slúžiť veľkému publiku používateľov, ktoré má možno až niekoľko miliónov dolárov. ."
„Najväčšou prekážkou, ktorú treba prekonať, je primäť ľudí, aby spolupracovali a premýšľali o častiach práce, ktorú robia iní, namiesto toho, aby sa sústredili len na svoje vlastné úlohy. Ak to dokážete, máte skvelú šancu 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 DevOps Institute, ponúkla skvelú analógiu na vysvetlenie DevOps. Podľa jej slov „DevOps je ako recept s tromi hlavnými kategóriami ingrediencií: ľudia, proces a automatizácia. Väčšinu týchto zložiek je možné prevziať z iných oblastí a zdrojov: Lean, Agile, SRE, CI/CD, ITIL, vedenie, kultúra, nástroje. Tajomstvom DevOps, ako každého dobrého receptu, je, ako získať správne proporcie a mix týchto ingrediencií, aby ste zvýšili rýchlosť a efektivitu vytvárania a vydávania aplikácií.“
6. DevOps je, keď programátori pracujú ako tím Formuly 1
"Preteky nie sú plánované od začiatku do konca, ale naopak, od cieľa po štart."
„Keď hovorím o tom, čo očakávať od iniciatívy DevOps, mám na mysli pretekársky tím NASCAR alebo Formulu 1 ako príklad,“ hovorí Chris Short, senior manažér marketingu cloudových platforiem v Red Hat a vydavateľ bulletinu DevOps. – Líder takéhoto tímu má jediný cieľ: zaujať na konci pretekov čo najvyššie miesto, berúc do úvahy zdroje, ktoré má tím k dispozícii, a výzvy, ktoré ho postretli. Preteky sa v tomto prípade plánujú nie od začiatku do konca, ale naopak, od cieľa po štart. Najprv sa stanoví ambiciózny cieľ a potom sa určia spôsoby, ako ho dosiahnuť. Potom sú rozdelené na čiastkové úlohy a delegované na členov tímu.“
„Tím strávi celý týždeň pred pretekmi zdokonaľovaním zastávky v boxoch. Robí silový tréning a kardio, aby sa udržal vo forme na vyčerpávajúci deň pretekov. Trénuje spoluprácu pri riešení akýchkoľvek problémov, ktoré môžu nastať počas pretekov. Podobne by mal vývojový tím trénovať zručnosť častého vydávania nových verzií. Ak máte takéto schopnosti a dobre fungujúci bezpečnostný systém, aj spúšťanie nových verzií do výroby sa stáva častejšie. V tomto svetonázore zvýšená rýchlosť znamená zvýšenú bezpečnosť,“ hovorí Short.
„Nie je to o robení ‚správnej veci‘,“ dodáva Short, „je to o odstránení čo najväčšieho počtu vecí, ktoré stoja v ceste želanému výsledku. Spolupracujte a prispôsobujte sa na základe spätnej väzby, ktorú dostávate v reálnom čase. Buďte pripravení na anomálie a pracujte na zlepšení kvality, aby ste minimalizovali ich vplyv na pokrok smerom k vášmu cieľu. Toto nás čaká vo svete DevOps.“
Ako škálovať DevOps: 10 tipov od odborníkov
Ide len o to, že DevOps a hromadné DevOps sú úplne odlišné veci. Prezradíme vám, ako prekonať bariéry na ceste z prvej do druhej.
Pre mnohé organizácie sa cesta k DevOps začína jednoducho a príjemne. Vznikajú malé zapálené tímy, staré procesy sa nahrádzajú novými a prvé úspechy na seba nenechajú dlho čakať.
Bohužiaľ, toto je len falošný lesk, ilúzia pokroku, hovorí Ben Grinnell, výkonný riaditeľ a vedúci digitálnej poradenskej spoločnosti North Highland. Skoré výhry sú určite povzbudivé, ale nepomáhajú dosiahnuť konečný cieľ, ktorým je rozsiahle prijatie DevOps v celej organizácii.
Je ľahké vidieť, že výsledkom je kultúra rozdelenia medzi „my“ a „oni“.
„Organizácie často spúšťajú tieto priekopnícke projekty mysliac si, že vydláždia cestu pre mainstreamové DevOps, bez toho, aby zvážili, či ostatní budú schopní alebo ochotní ísť touto cestou,“ vysvetľuje Ben Grinnell. – Tímy na realizáciu takýchto projektov sa zvyčajne rekrutujú zo sebavedomých „varjagov“, ktorí už niečo podobné urobili na iných miestach, no vo vašej organizácii sú noví. Zároveň sa vyzývajú, aby porušovali a ničili pravidlá, ktoré zostávajú záväzné pre všetkých ostatných. Je ľahké vidieť, že výsledkom je kultúra „my“ a „oni“, ktorá bráni prenosu vedomostí a zručností.
„A tento kultúrny problém je len jedným z dôvodov, prečo je ťažké škálovať DevOps. Tímy DevOps čelia zvýšeným technickým výzvam, ktoré sú typické pre rýchlo rastúce IT spoločnosti,“ povedal Steve Newman, zakladateľ a predseda predstavenstva Scalyr.
„V modernom svete sa služby menia hneď, ako to bude potrebné. Je skvelé neustále implementovať a implementovať nové funkcie, ale koordinácia tohto procesu a odstraňovanie vzniknutých problémov je skutočnou bolesťou hlavy, dodáva Steve Newman. – Vo veľmi rýchlo rastúcich organizáciách sa inžinieri v tímoch s viacerými funkciami snažia udržať prehľad o zmenách a kaskádových efektoch na úrovni závislosti, ktoré vytvára. Navyše, inžinieri nie sú šťastní, keď sú zbavení tejto príležitosti, a v dôsledku toho je pre nich ťažšie pochopiť podstatu problémov, ktoré vznikajú.“
Ako prekonať tieto výzvy opísané vyššie a prejsť k masovému prijatiu DevOps vo veľkej organizácii? Odborníci vyzývajú na trpezlivosť, aj keď je vaším konečným cieľom urýchliť cyklus vývoja softvéru a obchodné procesy.
1. Pamätajte, že zmena kultúry si vyžaduje čas.
Jayne Groll, výkonná riaditeľka, DevOps Institute: „Podľa môjho názoru by expanzia DevOps mala byť rovnako postupná a iteratívna ako agilný vývoj (a rovnako by sa mala dotýkať kultúry). Agile a DevOps kladú dôraz na malé tímy. Ale ako tieto tímy rastú v počte a integrácii, končíme s tým, že viac ľudí si osvojuje nové spôsoby práce a výsledkom je masívna kultúrna transformácia.“
2. Venujte dostatok času plánovaniu a výberu platformy
Eran Kinsbruner, vedúci technický evanjelista v Perfecto: „Aby škálovanie fungovalo, musia sa tímy DevOps najprv naučiť kombinovať tradičné procesy, nástroje a zručnosti a potom pomaly vychovávať a stabilizovať každú jednotlivú fázu DevOps. Všetko to začína starostlivým plánovaním používateľských príbehov a hodnotových tokov, po ktorom nasleduje písanie softvéru a riadenia verzií pomocou vývoja na báze kmeňa alebo iných prístupov, ktoré sú najvhodnejšie na vetvenie a zlučovanie kódu.
„Potom prichádza fáza integrácie a testovania, kde je už potrebná škálovateľná platforma pre automatizáciu. Tu je dôležité, aby si tímy DevOps vybrali správnu platformu, ktorá vyhovuje ich úrovni zručností a konečným cieľom projektu.
Ďalšou fázou je nasadenie do produkcie, ktoré by malo byť plne automatizované pomocou nástrojov na orchestráciu a kontajnerov. Je dôležité mať virtualizované prostredia vo všetkých fázach DevOps (produkčný simulátor, QA prostredie a skutočné produkčné prostredie) a vždy používať len najnovšie dáta na testy na získanie relevantných záverov. Analytics musí byť inteligentná a schopná spracovať veľké dáta s rýchlou a praktickou spätnou väzbou.“
3. Zbavte sa viny zo zodpovednosti.
Gordon Haff, evanjelista RedHat: „Vytvorenie systému a atmosféry, ktorá umožňuje a podporuje experimentovanie, umožňuje to, čo je známe ako úspešné zlyhania pri vývoji agilného softvéru. To neznamená, že nikto iný nie je zodpovedný za zlyhania. V skutočnosti je identifikácia toho, kto je zodpovedný, ešte jednoduchšia, keďže „byť zodpovedný“ už neznamená „spôsobiť nehodu“. To znamená, že podstata zodpovednosti sa kvalitatívne mení. Štyri faktory sa stávajú kritickými: rozsah narušenia, prístupy, výrobné procesy a stimuly. (Viac o týchto faktoroch si môžete prečítať v článku Gordona Huffa „DevOps lekcie: 4 aspekty zdravých experimentov.“)
4. Vyčistite cestu vpred
Ben Grinnell, výkonný riaditeľ a vedúci digitálneho oddelenia v poradenskej spoločnosti North Highland: „Na dosiahnutie rozsahu odporúčam spustiť program „vyčistenia ciest“ spolu s priekopníckymi projektmi. Cieľom tohto programu je vyčistiť odpadky, ktoré po sebe zanechávajú priekopníci DevOps, ako sú zastarané pravidlá a podobné veci, aby cesta vpred zostala voľná.“
„Poskytnite ľuďom organizačnú podporu a dynamiku prostredníctvom komunikácie, ktorá ďaleko presahuje priekopnícku skupinu, a to širokým oslavovaním úspechov nových spôsobov práce. Trénujte ľudí, ktorí sú zapojení do ďalšej vlny projektov DevOps a sú nervózni z prvého použitia DevOps. A pamätajte, že títo ľudia sú veľmi odlišní od priekopníkov.“
5. Demokratizujte nástroje
Steve Newman, zakladateľ a predseda predstavenstva Scalyr: „Nástroje by nemali byť pred ľuďmi skryté a mali by sa dať relatívne ľahko naučiť pre každého, kto je ochotný venovať tomu čas. Ak je možnosť dotazovania sa v protokoloch obmedzená na troch ľudí „certifikovaných“ na používanie nástroja, vždy budete mať k dispozícii maximálne troch ľudí na riešenie problému, a to aj v prípade, že máte veľmi rozsiahle výpočtové prostredie. Inými slovami, je tu úzke miesto, ktoré môže viesť k vážnym (obchodným) dôsledkom.“
6. Vytvorte ideálne podmienky pre tímovú prácu
Tom Clark, vedúci spoločnej platformy v ITV: „Môžeš robiť čokoľvek, ale nie všetko naraz. Stanovte si teda veľké ciele, začnite v malom a napredujte v rýchlych iteráciách. Postupom času si vytvoríte povesť toho, že veci robíte, takže ostatní budú chcieť použiť aj vaše metódy. A nebojte sa vybudovať vysoko efektívny tím. Namiesto toho poskytnite ľuďom ideálne pracovné podmienky a efektivita bude nasledovať.“
7. Nezabudnite na Conwayov zákon a dosky Kanban
Logan Daigle, riaditeľ pre poskytovanie softvéru a stratégiu DevOps v CollabNetVersionOne: „Je dôležité pochopiť dôsledky Conwayovho zákona. Vo voľnej parafráze tento zákon uvádza, že produkty, ktoré vytvárame, a procesy, ktoré na to používame, vrátane DevOps, sú štruktúrované rovnakým spôsobom ako naša organizácia.“
„Ak je v organizácii veľa síl a riadenie pri plánovaní, budovaní a uvoľňovaní softvéru mnohokrát zmení majiteľa, efekt škálovania bude nulový alebo krátkodobý. Ak organizácia vybuduje multifunkčné tímy okolo produktov, ktoré sú financované so zameraním na trh, potom sa šance na úspech dramaticky zvýšia.“
„Ďalším dôležitým aspektom škálovania je zobrazenie všetkej nedokončenej práce (WIP, workinprogress) na tabuliach Kanban. Keď má organizácia miesto, kde ľudia môžu vidieť tieto veci, veľmi to podporuje spoluprácu, čo má pozitívny vplyv na škálovanie.“
8. Hľadajte staré jazvy
Manuel Pais, konzultant DevOps a spoluautor Topológie tímu: „Prevziať postupy DevOps nad rámec samotného Dev a Ops a pokúsiť sa ich aplikovať na iné funkcie je sotva optimálny prístup. Určite to bude mať určitý vplyv (napríklad automatizáciou manuálneho ovládania), ale oveľa viac sa dá 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 riadiace mechanizmy, ktoré boli implementované v dôsledku minulých incidentov, ale stratili svoj význam (v dôsledku zmien v produktoch, technológiách alebo procesoch) – potom ich určite treba odstrániť. alebo vyhladenie namiesto automatizácie neefektívnych alebo nepotrebných procesov.“
9. Nemnožte možnosti DevOps
Anthony Edwards, prevádzkový riaditeľ spoločnosti Eggplant: „DevOps je veľmi vágny pojem, takže každý tím skončí s vlastnou verziou DevOps. A nie je nič horšie, keď má organizácia zrazu 20 druhov DevOps, ktoré spolu veľmi nevychádzajú. Je nemožné, aby každý z troch vývojových tímov mal svoje vlastné špeciálne rozhranie medzi vývojom a správou produktov. Produkty by tiež nemali mať svoje vlastné jedinečné očakávania týkajúce sa spracovania spätnej väzby pri prenose do výrobného simulátora. V opačnom prípade nikdy nebudete môcť škálovať DevOps.“
10. Hlásajte obchodnú hodnotu DevOps
Steve Newman, zakladateľ a predseda predstavenstva Scalyr: „Pracujte na rozpoznaní hodnoty DevOps. Naučte sa a neváhajte hovoriť o výhodách toho, čo robíte. DevOps neuveriteľne šetrí čas a peniaze (len si pomyslite: menej prestojov, kratší stredný čas na zotavenie) a tímy DevOps musia neúnavne zdôrazňovať (a kázať) dôležitosť týchto iniciatív pre obchodný úspech. Takto môžete rozšíriť okruh prívržencov a zvýšiť vplyv DevOps v organizácii.“
BONUS
Na Naše vlastné DevOps dorazí 13. septembra – áno, Red Hat ako výrobca softvéru má svoje vlastné DevOps tímy a postupy.
Náš inžinier Mark Birger, ktorý vyvíja služby internej automatizácie pre ďalšie skupiny v rámci organizácie, porozpráva svoj vlastný príbeh v jasnej ruštine – ako tím Red Hat DevOps migroval aplikácie z virtuálnych prostredí Hat Virtualization spravovaných Ansible na plnohodnotný kontajnerový formát na platforma OpenShift.
Ale to nie je všetko:
Keď organizácie presunú pracovné zaťaženie do kontajnerov, tradičné metódy monitorovania aplikácií nemusia fungovať. V druhej prednáške vysvetlíme našu motiváciu zmeniť spôsob protokolovania a ukážeme pokračovanie cesty, ktorá nás priviedla k moderným metódam protokolovania a monitorovania.
Zdroj: hab.com