Nehezen lehet megragadni a lényeget a DevOps kapcsán? Összegyűjtöttük Önnek a legmeghatározóbb analógiákat, frappáns megfogalmazásokat és szakértői tanácsokat, amelyek segítenek a lényeghez jutni még a nem szakemberek számára is. A végén egy bónusz – a Red Hat munkatársainak saját DevOps definíciója.
A DevOps kifejezés 10 évvel ezelőtt jelent meg, és fejlődése során a Twitteren használt hashtagből a világ IT területén egy erőteljes kulturális mozgalommá fejlődött, amely valódi filozófiát képvisel, ösztönözve a fejlesztőket, hogy gyorsabban érjenek el eredményeket, kísérletezzenek és iteratív módszerekkel haladjanak előre. A DevOps elválaszthatatlanul összefonódott a digitális transzformáció fogalmával. De ahogy az IT terminológiákkal gyakran előfordul, ezen évek alatt a DevOps sok definícióval, értelmezéssel és tévhittel gazdagodott.
Ezért a DevOps kapcsán gyakran hallani olyan kérdéseket, mint hogy ez ugyanaz, mint az agilis? Vagy egy külön metodológia? Vagy csupán a „együttműködés” szinonimája?
A DevOps sokféle koncepciót foglal magában (folytonos szállítás, folyamatos integráció, automatizálás stb.), ezért a lényeg kiemelése néha nehézkes lehet, főleg, ha érdeklődéssel viseltetik a téma iránt. Ennek ellenére ez a készség rendkívül hasznos, függetlenül attól, hogy próbálja-e megismertetni ötleteit a vezetőséggel vagy egyszerűen írja le a munkáját hazaiaknak vagy ismerősöknek. Ezért most félretehetjük a DevOps terminológiai finomságait, és a általános képére koncentrálunk.
Mi a DevOps: 6 definíció és analógia
Megkértük a szakértőket, hogy a lehető legegyszerűbben és rövidebben magyarázzák el a DevOps lényegét, hogy értéke érthetővé váljon bármilyen technikai háttérrel rendelkező olvasó számára. Ezekből a beszélgetésekből válogattuk ki a legszembetűnőbb analógiákat és frappáns megfogalmazásokat, amelyek segítenek felépíteni a saját elmesélését a DevOps-ról.
1. A DevOps egy kulturális mozgalom
„A DevOps egy kulturális mozgalom, amely keretein belül mindkét fél (a szoftverfejlesztők és az IT rendszerek üzemeltetői) elismeri, hogy a szoftver nem hoz valódi értéket, amíg valaki nem kezdi el használni: ügyfelek, felhasználók, munkatársak, ez számít – mondja Eveline Oehrlich, a DevOps Intézet vezető elemzője. – Ezért mindkét fél közösen biztosítja a szoftver gyors és minőségi szállítását.”
2. A DevOps az, ami hatalmat ad a fejlesztők kezébe
A DevOps felhatalmazza a fejlesztőket, hogy birtokolják az alkalmazásokat, indítsák azokat és irányítsák a szállítást a kezdetektől a végéig.
A DevOps-ról általában úgy beszélnek, mint a termékek gyorsabb szállításának módszeréről, automatizált folyamatok kialakításával és alkalmazásával – mondja Jai Schniepp, a Liberty Mutual biztosítótársaság DevOps platformokért felelős igazgatója. – De számomra ez sokkal alapvetőbb dolog. A DevOps felhatalmazza a fejlesztőket, hogy birtokolják az alkalmazásokat vagy a szoftver egyes részeit, indítsák azokat és irányítsák a szállítást a kezdetektől a végéig. A DevOps megszünteti a felelősséggel kapcsolatos zűrzavart, és minden résztvevőt arra vezet, hogy automatikus és fejlesztő által irányított infrastruktúrát hozzon létre.
3. A DevOps az együttműködés az alkalmazások készítése és szállítása során.
Egyszerűbb kifejezéssel a DevOps egy olyan megközelítés a szoftver gyártásában és szállításában, ahol mindenki együtt dolgozik – emeli ki Gur Staff, a BMC digitális üzleti automatizálásáért felelős elnöke.
4. A DevOps egy gyártósor.
A gyártósoros összeszerelés csak akkor lehetséges, ha minden részlet illeszkedik egymáshoz.
A DevOps-ot egy autószerelő gyártósorhoz hasonlítanám – folytatja Gur Staff. – Az elképzelés az, hogy előre megtervezzük és legyártjuk az összes alkatrészt, hogy azokat később egyedi illesztés nélkül lehessen összeszerelni. A gyártósoros összeszerelés csak akkor lehetséges, ha minden részlet illeszkedik egymáshoz. Akik a motort tervezik és készítik, figyelembe kell vegyék, hogyan rögzítik azt a karosszériához vagy vázhoz. Akik a fékeket készítik, figyelembe kell vegyék a kerekeket, és így tovább. Ugyanez a helyzet a szoftverekkel is.
A fejlesztő, aki az üzleti logikát vagy a felhasználói felületet létrehozza, figyelembe kell vegye az ügyfelek adatait tároló adatbázist, a felhasználói adatok védelmét szolgáló biztonsági intézkedéseket, valamint azt, hogyan működik mindez, amikor a szolgáltatás egy nagy, esetleg több millió felhasználót kiszolgáló közönséget fog megcélozni.
„Az emberek együttműködésének és a mások által végzett munka részére való odafigyelésének ösztönzése, ahelyett, hogy kizárólag a saját feladatokra koncentrálnának – ez a legnagyobb akadály, amelyet le kell küzdeni. Ha ez sikerül, nagyszerű lehetőségek nyílhatnak meg a digitális átalakulásra” – tette hozzá Gur Staff.
5. A DevOps a megfelelő emberek, folyamatok és automatizálás kombinációja.
Jayne Groll, a DevOps Intézet ügyvezető igazgatója nagyszerű analógiát ajánlott a DevOps magyarázatára. Azt mondta: „A DevOps olyan, mint egy recept, amely három fő összetevő kategóriát tartalmaz: emberek, folyamatok és automatizálás. A legtöbb összetevőt más területekről és forrásokból lehet beszerezni: Lean, Agile, SRE, CI/CD, ITIL, vezetés, kultúra, eszközök. A DevOps titka, akárcsak bármely jó recept esetén, abban rejlik, hogyan válasszuk ki a megfelelő arányokat és keverjük össze ezeket az összetevőket, hogy növeljük a munka sebességét és hatékonyságát az alkalmazások létrehozása és kiadása során.”
6. A DevOps az, amikor a programozók egy F1-es csapatként dolgoznak.
„A versenyt nem a rajtotól a célig, hanem éppen ellenkezőleg, a céltól a rajtig tervezik.”
„Amikor a DevOps kezdeményezéstől várhatókról beszélek, például egy NASCAR vagy Formula-1-es versenycsapatot hozok fel – mondja Chris Short, a Red Hat felhőplatformjainak marketingigazgatója és a DevOps’ish hírlevél kiadója. – Egy ilyen csapat vezetője egy célt tűz ki: a lehető legjobb helyezést elérni a verseny végén, figyelembe véve a csapat erőforrásait és a megpróbáltatásokat, amelyekre jutott. A versenyt viszont nem a rajtotól a célig, hanem a céltól a rajtig tervezik. Először egy ambiciózus célt tűznek ki, majd meghatározzák a végrehajtás módját. Ezt követően az alfeladatokat a csapattagokra delegálják.”
„Az egész hét során a verseny előtt a csapat finomítja a pit stopokat. Erősítő és kardió edzéseket végez, hogy formában legyen a fárasztó versenynapon. Gyakorolják a közös döntéshozatali folyamatokat bármilyen, a verseny során felmerülő probléma kezelésére. Hasonlóképpen a fejlesztőcsapatnak is gyakorolnia kell az új verziók gyakori kiadását. Ha a csapat rendelkezik ilyen készségekkel és szigorú biztonsági rendszerrel, akkor az új verziók bevezetése a termelésbe is gyakoribbá válik. Ebben a felfogásban a sebesség növekedése a biztonság növekedését is jelenti” – mondja Short.
„A kérdés nem az, hogy a „helyes dolgokat” csináljuk – teszi hozzá Short –, hanem az, hogy minél több olyan dolgot jutassunk el az úton, amelyek gátolják a kívánt eredmény elérését. Együttműködjünk és alkalmazkodjunk a valós idejű visszajelzésekhez. Legyünk felkészülve az anomáliákra, és dolgozzunk a minőség javításán, hogy minimalizáljuk hatásukat a cél felé vezető úton. Ez vár ránk a DevOps világában.”
A DevOps skálázása: 10 tipp szakértőktől
A sima DevOps és a tömeges DevOps teljesen más dolgok. Elmondjuk, hogyan lehet leküzdeni az akadályokat az elsőről a másodikra való átmenet során.
Sok szervezet számára a DevOps felé vezető út könnyedén és kellemesen indul. Kicsi, szenvedélyes csapatok jönnek létre, a régi folyamatokat újra cserélik, és az első sikerek nem váratnak magukra.
Sajnos ez csupán egy hamis csillogás, a fejlődés illúziója – mondja Ben Grinnell, a North Highland tanácsadó cég ügyvezető igazgatója és digitális technológiák vezetője. A korai győzelmek természetesen biztatóak, de nem segítenek elérni a végső célt, nevezetesen a DevOps tömeges alkalmazását a szervezeten belül.
Könnyen észlelhető, hogy ennek eredményeként egy „mi” és „ők” kultúra alakul ki.
Sok esetben a szervezetek olyan úttörő projekteket indítanak, abban a hitben, hogy azok utat mutatnak a tömeges DevOps felé, anélkül, hogy figyelembe vennék, hogy a többiek hajlandóak-e ezen az úton haladni - magyarázza Ben Greenell. - Az ilyen projektek megvalósítására általában öntudatos "vikingeket" toboroznak, akik már végeztek hasonló munkát máshol, de újak a szervezetükben. Emellett bátorítják őket arra, hogy törjék meg és rombolják le a szabályokat, amelyek mások számára kötelezőek. Könnyen észlelhető, hogy ennek következtében kialakul egy "mi" és "ők" közötti kulturális megosztottság, amely gátolja a tudás és készségek átadását.
Ez a kulturális probléma csupán egy oka annak, hogy a DevOps nehezen skálázható. A DevOps csapatok a gyorsan fejlődő, IT-technológiákra építő vállalatok jellemzően technikai nehézségeivel szembesülnek - mondja Steve Newman, a Scalyr alapítója és elnöke.
A modern világban a szolgáltatások azonnal megváltoznak, ahogy csak szükség van rá. Az új funkciók folyamatos megvalósítása és bevezetése természetesen nagyszerű, de a folyamat koordinálása és a felmerülő problémák megoldása valódi fejtörést okoz - teszi hozzá Steve Newman. - Nagyon gyorsan növekvő szervezetekben a keresztfunkcionális csapatok mérnökei küzdenek azért, hogy fenntartsák a képességüket a változások nyomon követésére és a függőségek szintjén keletkező következmények kezelésére. Ráadásul a mérnökök cseppet sem örülnek, ha megfosztják őket ettől a lehetőségtől, és ennek következtében nehezebbé válik számukra a felmerülő problémák lényegének megértése.
Hogyan lehet átlépni a fent említett nehézségeken, és átállni a DevOps tömeges használatára egy nagy szervezetben? A szakértők azt javasolják, hogy türelemmel készüljünk fel, még akkor is, ha a végső cél az, hogy felgyorsítsuk a szoftverfejlesztési ciklust és az üzleti folyamatokat.
1. Ne feledje, hogy a kulturális változásokhoz időre van szükség
Jayne Groll, a DevOps Intézet ügyvezető igazgatója: „Véleményem szerint a DevOps kiterjesztésének olyan fokozatosnak és iteratívnak kell lennie, mint az agile fejlesztésnek (és ugyanolyan mértékben érinteni kell a kultúrát). Az Agile és DevOps esetében a hangsúly a kis csapatokon van. De ahogy nő a csapatok száma és integrációjuk, egyre több ember alkalmaz új munkamódszereket, ami elkerülhetetlenül nagyszabású kulturális átalakulást eredményez.”
2. Szánjon elegendő időt a tervezésre és a platform kiválasztására
Eran Kinsbruner, a Perfecto vezető technikai evangelistája: „Ahhoz, hogy a skálázás működjön, a DevOps csapatoknak először meg kell tanulniuk kombinálni a hagyományos folyamatokat, eszközöket és készségeket, majd lassan ki kell építeniük a DevOps egyes fázisait és stabilizálniuk kell azokat. Minden a felhasználói történetek (user story) és az értékáramok (value stream) alapos tervezésével kezdődik, majd következik a szoftverírás és a verziókezelés trunk-alapú fejlesztés vagy más, a kódágazásra és összevonásra legjobban illeszkedő megközelítések alkalmazásával.
„Ezután következik az integráció és tesztelés fázisa, ahol már egy skálázható platform szükséges az automatizáláshoz. Itt a DevOps csapatoknak fontos kiválasztani a megfelelő platformot, amely megfelel készségeik szintjének és a projekt végső céljainak.
A következő fázis a telepítés éles környezetbe, és ennek teljesen automatizáltnak kell lennie az orkestráló és konténeres eszközök használatával. Fontos, hogy a DevOps minden fázisában virtualizált környezetek álljanak rendelkezésre (éles környezet szimulátor, minőségellenőrzési környezet és maga az éles környezet) és a teszteléshez mindig a legfrissebb adatokat használjuk, hogy aktuális következtetéseket nyerjünk. Az analitikának intelligensnek kell lennie, és képesnek kell lennie nagy adatok feldolgozására gyors és hatékony visszajelzéssel.”
3. Szabadítsa meg a felelősséget a bűntudattól
Gordon Haff, a RedHat evangelistája: A rendszer és atmoszféra létrehozása, amely lehetővé és ösztönzi a kísérletezést, megvalósítja a sikeres hibák ilyen vagy olyan formáját az agile szoftverfejlesztésben. Ez nem jelenti azt, hogy a hibákért senki sem vállalja a felelősséget. Valójában a felelős keresése még egyszerűbbé válik, mivel a "felelős lenni" már nem azt jelenti, hogy "a baleset okozója lettél". Tehát a felelősség lényege minőségileg megváltozik. Négy tényező válik emiatt rendkívül fontossá: a hiba mértéke, a megközelítések, a gyártási folyamatok és az ösztönzők. (Több információt ezekről a tényezőkről Gordon Huff cikkében olvashatsz, amelynek címe: "DevOps lessons: 4 aspects of healthy experiments.")
4. Tisztítsd meg az utat előre
Ben Grinnell, a North Highland tanácsadó cég ügyvezető igazgatója és digitális technológiákért felelős vezetője: „A lépték növeléséhez azt javaslom, hogy a kezdeményező projektek mellett indítsenek el egy "tiszta út programot". Ennek a programnak a célja, hogy eltávolítsa a szemetet, ami a DevOps úttörői mögött marad, mint a már elavult szabályok és egyéb hasonló dolgok, hogy az előrehaladás zavartalan maradjon.”
„Adjatok az embereknek szervezeti támogatást, és ösztönözzétek őket olyan kommunikációval, ami messze túlterjed a kezdeményező csoporton, széles körben ünnepelve az új munkamódszerek sikereit. Képezzétek a DevOps következő hullámában részt vevő embereket, akik először használják a DevOps-t, és idegesek emiatt. És ne feledjétek, hogy ezek az emberek nagyon eltérnek a kezdeményezőktől.”
5. Tegyétek demokratikusabbá az eszközöket
Steve Newman, a Scalyr alapítója és elnöke: „Az eszközöket nem szabad elrejteni az emberek elől, és viszonylag egyszerűen tanulhatóak kell legyenek bárki számára, aki hajlandó időt szánni rá. Ha a naplók lekérdezésének lehetősége csak három ember számára van fenntartva, akik "tanúsítottak" az adott eszközzel való munkavégzésre, akkor mindig maximum három ember fog tudni foglalkozni a megfelelő problémával, még ha nagyon nagy számítástechnikai környezetetek is van. Más szavakkal, ez egy szűk keresztmetszetet eredményezhet, ami komoly, vállalati következményekkel járhat.”
6. Hozzátok létre az ideális körülményeket a csapat munkájához
Tom Clark, az ITV Common Platform részlegének vezetője: «Bármit megtehet, de ne egyszerre mindent. Ezért állítson fel nagy célokat, kezdje kicsiben, és haladjon gyors iterációkkal. Idővel elnyeri a hírnevét annak a csapatnak, amelyik képes teljesíteni, így mások is szeretnék majd alkalmazni a módszereit. És ne az ügyes csapat felépítésére törekedjen. Ehelyett biztosítson ideális munkakörülményeket az emberek számára, és a hatékonyság magától meg fog jönni».
7. Ne feledkezzen meg Conway törvényéről és a kanban táblákról
Logan Daigle, a CollabNetVersionOne szoftver szállítási és DevOps stratégiáért felelős igazgatója: «Fontos tudni a Conway törvényének következményeit. Szabad fordításomban ez a törvény azt mondja, hogy a termékek, amelyeket létrehozunk, és a folyamatok, amelyeket használunk, beleértve a DevOps-t is, ugyanúgy szerveződnek, mint a mi szervezetünk».
«Ha a szervezetben nagy a szétszórtság, és a szoftver tervezése, létrehozása és kiadása során a vezetés sokszor váltogatja a kezeket, akkor a méretnövelés hatása nullára csökken vagy rövidtávú marad. Ha viszont a szervezet keresztfunkcionális csapatokat alakít a piaci orientációval finanszírozott termékek köré, a siker esélye drámaian megnő».
«Még egy fontos aspektus a méretnövelésben, hogy a kanban táblákon megjelenítjük az összes folyamatban lévő munkát (WIP, work in progress). Amikor a szervezetben van egy hely, ahol az emberek láthatják ezeket a dolgokat, az erősen ösztönzi az együttműködést, ami jótékony hatással van a méretnövelésre».
8. Keresd a régi hegeket
Manuel Pais, DevOps tanácsadó és a „Team Topologies” könyv társszerzője: «A DevOps gyakorlatok kiterjesztése saját Dev-re és Ops-ra, valamint azok más funkciókra való alkalmazása nem mondható optimális megközelítésnek. Bizonyára lesz némi hatása (például a kézi irányítás automatizálásával), de sokkal többet érhetünk el, ha a szállítási és visszajelzési folyamatok megértésével kezdjük».
Ha a szervezeti IT-rendszerben régóta fennálló hegek – a korábbi incidensek következményeként bevezetett eljárások és irányítási mechanizmusok, amelyek az új termékek, technológiák vagy folyamatok miatt elvesztették relevanciájukat – találhatók, akkor ezeket természetesen el kell távolítani vagy simítani, nem pedig hatástalan vagy szükségtelen folyamatokat automatizálni.
9. Ne hozzon létre DevOps változatokat
Antony Edwards, az Eggplant termelési igazgatója: "A DevOps egy nagyon homályos kifejezés, ezért minden csapatnak megvan a saját DevOps változata. Nincs is rosszabb, mint amikor egy szervezetben 20 különböző DevOps változat jelenik meg, amelyek nem igazán illeszkednek egymáshoz. Nem lehet, hogy a három fejlesztőcsapat mindegyikének legyen saját speciális interfésze a fejlesztés és a termék kezelés között. Ahogy az sem lenne megfelelő, ha a termékeknek egyedi elvárásaik lennének a visszajelzés feldolgozására a gyártási környezet szimulátorába való átvitel során. Különben soha nem fog sikerülni a DevOps skálázása."
10. Hirdesse a DevOps üzleti értékét
Steve Newman, a Scalyr alapítója és elnöke: "Dolgozzon a DevOps értékének elismertetésén. Tanulja meg, és ne szégyellje elmondani, mennyire hasznos, amit csinál. A DevOps hihetetlenül időt és pénzt takarít meg (gondoljunk csak arra: kevesebb leállás, rövidebb átlagos helyreállítási idő), és a DevOps csapatoknak folyamatosan hangsúlyozniuk kell (és hirdetniük), hogy ezek az kezdeményezések mennyire fontosak a vállalat sikeréhez. Így szélesebb körben terjesztheti a DevOps hírét és növelheti annak hatását a szervezeten belül."
BÓNUSZ
Ezen Szeptember 13-án érkezik a mi saját DevOps csapatunk – igen, a Red Hat-nél, mint szoftvergyártónál, saját DevOps csapataink és gyakorlati módszereink vannak.
Mérk Birger mérnökünk, aki a belső automatizálás szolgáltatásainak fejlesztésével foglalkozik a szervezeten belüli különböző csoportok számára, tiszta orosz nyelven mesélni fogja saját történetét – hogyan migrálta a Red Hat DevOps csapata az alkalmazásokat a Hat Virtualization virtuális környezeteiből, amelyek Ansible irányítása alatt állnak, egy teljes értékű konténerformátumra az OpenShift platformon.
De ez még nem minden:
Miután a szervezetek konténerekbe helyezték a munkaterheléseket, a hagyományos alkalmazásmonitorozási módszerek nem mindig működnek. A második jelentésünkben kifejtjük, mi motivált minket a nyilvántartás módjának megváltoztatására, és bemutatjuk azt az utat, amely a modern naplózási és monitoring módszerekhez vezetett.
Forrás: habr.com
