Nehéz megérteni a lényeget, amikor a DevOps-ról beszélünk? Élénk analógiákat, frappáns megfogalmazásokat és szakértői tanácsokat gyűjtöttünk össze Önnek, amelyek még a nem szakembereknek is segítenek eljutni a lényegre. Végül a bónusz a Red Hat alkalmazottainak saját DevOps-ja.
A DevOps kifejezés 10 évvel ezelőtt keletkezett, és a Twitter hashtagből az IT-világ erőteljes kulturális mozgalmává vált, egy igazi filozófiává, amely arra ösztönzi a fejlesztőket, hogy gyorsabban végezzék el a dolgokat, kísérletezzenek és folytassanak előre. A DevOps elválaszthatatlanul összekapcsolódott a digitális átalakulás koncepciójával. De ahogy az IT-terminológiával lenni szokott, az elmúlt tíz év során a DevOps számos definíciót, értelmezést és tévképzetet szerzett magáról.
Ezért gyakran hallhatsz olyan kérdéseket a DevOps-szal kapcsolatban, mint az, hogy ez ugyanaz, mint az agilis? Vagy ez valami speciális módszertan? Vagy ez csak egy újabb szinonimája az „együttműködés” szónak?
A DevOps számos különféle koncepciót tartalmaz (folyamatos szállítás, folyamatos integráció, automatizálás stb.), így a fontos dolgok kiszűrése kihívást jelenthet, különösen, ha szenvedélyes a téma. Ez a készség azonban nagyon hasznos, függetlenül attól, hogy ötleteit próbálja átadni a feletteseinek, vagy egyszerűen csak elmondja valakinek a családjából vagy a barátaiból a munkáját. Ezért most tegyük félre a DevOps terminológiai árnyalatait, és koncentráljunk az összképre.
Mi az a DevOps: 6 definíció és analógia
Arra kértük a szakértőket, hogy a lehető legegyszerűbben és legrövidebben fejtsék ki a DevOps lényegét, hogy az értéke bármilyen szintű technikai tudással rendelkező olvasó számára is világos legyen. E beszélgetések eredményei alapján kiválasztottuk a legszembetűnőbb analógiákat és legmeglepőbb megfogalmazásokat, amelyek segítenek felépíteni a DevOps-ról szóló történetet.
1. A DevOps egy kulturális mozgalom
„A DevOps egy kulturális mozgalom, amelyben mindkét fél (szoftverfejlesztők és informatikai rendszer-üzemeltető szakemberek) felismeri, hogy a szoftver nem hoz valódi hasznot addig, amíg valaki el nem kezdi használni: ügyfelek, ügyfelek, alkalmazottak, nem a lényeg” – mondja Eveline Oehrlich, vezető kutató. a DevOps Institute elemzője. "Ezért mindkét fél közösen biztosítja a szoftverek gyors és magas színvonalú szállítását."
2. A DevOps a fejlesztők felhatalmazásáról szól.
"A DevOps lehetővé teszi a fejlesztők számára, hogy alkalmazásokat birtokoljanak, futtassák azokat, és az elejétől a végéig kezeljék a kézbesítést."
„A DevOps-ról általában úgy beszélnek, mint az alkalmazások termelésbe való eljuttatásának felgyorsítására automatizált folyamatok kiépítésével és megvalósításával” – mondja Jai Schniepp, a Liberty Mutual biztosítótársaság DevOps platformjaiért felelős igazgatója. – De számomra ez sokkal alapvetőbb dolog. A DevOps felhatalmazza a fejlesztőket arra, hogy alkalmazásokat vagy meghatározott szoftvereket birtokoljanak, futtassák azokat, és az elejétől a végéig kezeljék azok szállítását. A DevOps kiküszöböli a felelősségi zavarokat, és mindenkit irányít egy automatizált, fejlesztő által vezérelt infrastruktúra létrehozásában.”
3. A DevOps az alkalmazások létrehozásában és szállításában való együttműködésről szól.
„Egyszerűen fogalmazva, a DevOps a szoftvergyártás és -szállítás olyan megközelítése, amelyben mindenki együtt dolgozik” – mondja Gur Staf, a BMC elnöke és digitális üzleti automatizálási vezetője.
4. A DevOps egy folyamat
"A szállítószalag összeszerelése csak akkor lehetséges, ha minden alkatrész illeszkedik egymáshoz."
„A DevOps-ot egy autó-összeszerelő sorhoz hasonlítanám” – folytatja Gur Staff. – Az ötlet az, hogy minden alkatrészt előre meg kell tervezni és elkészíteni, hogy aztán egyedi beállítás nélkül össze lehessen szerelni. A szállítószalag összeszerelése csak akkor lehetséges, ha minden alkatrész illeszkedik egymáshoz. Azoknak, akik motort terveznek és építenek, meg kell fontolniuk, hogyan szereljék fel a karosszériára vagy a vázra. A fékezőknek gondolniuk kell a kerekekre és így tovább. Ugyanez a helyzet a szoftverrel.
Az üzleti logikát vagy felhasználói felületet létrehozó fejlesztőnek át kell gondolnia az ügyféladatokat tároló adatbázist, a felhasználói adatok védelmét szolgáló biztonsági intézkedéseket, és mindezt hogyan fog működni, amikor a szolgáltatás nagy, esetleg több millió dolláros felhasználói közönséget kezd kiszolgálni. ."
„Az a legnagyobb leküzdendő akadály, hogy az embereket arra késztessük, hogy együttműködjenek és gondolkodjanak el a munka mások által végzett részein, ahelyett, hogy kizárólag a saját feladataikra összpontosítanának. Ha ezt megteheti, kiváló esélye van a digitális átalakulásra” – teszi hozzá Gur Staff.
5. A DevOps az emberek, a folyamatok és az automatizálás megfelelő kombinációja
Jayne Groll, a DevOps Institute ügyvezető igazgatója nagyszerű analógiát kínált a DevOps magyarázatára. Szavai szerint: „A DevOps olyan, mint egy recept, amely három fő összetevő-kategóriát tartalmaz: emberek, folyamat és automatizálás. Ezen összetevők többsége más területekről és forrásokból is beszerezhető: Lean, Agile, SRE, CI/CD, ITIL, vezetés, kultúra, eszközök. A DevOps titka, mint minden jó receptnek, az, hogy hogyan lehet ezeket az összetevőket megfelelő arányban és keverékben elkészíteni az alkalmazások létrehozásának és kiadásának sebességének és hatékonyságának növelése érdekében.”
6. A DevOps az, amikor a programozók úgy dolgoznak, mint egy Forma-1-es csapat
„A versenyt nem az elejétől a végéig tervezzük, hanem éppen ellenkezőleg, a céltól a rajtig.”
„Amikor arról beszélek, hogy mit várhatok el egy DevOps-kezdeményezéstől, egy NASCAR vagy Formula 1-es versenycsapat jut eszembe példaként” – mondja Chris Short, a Red Hat felhőplatform-marketingért felelős vezető menedzsere és a DevOps hírlevelének kiadója. – Egy ilyen csapat vezetőjének egyetlen célja van: a lehető legmagasabb helyezést elérni a verseny végén, figyelembe véve a csapat rendelkezésére álló erőforrásokat és az azt érő kihívásokat. Ebben az esetben a versenyt nem az elejétől a célig tervezik, hanem éppen ellenkezőleg, a céltól a rajtig. Először egy ambiciózus célt tűznek ki, majd meghatározzák a megvalósítás módjait. Ezután részfeladatokra bontják őket, és delegálják a csapattagoknak."
„A csapat a verseny előtti egész hetet a boxkiállás tökéletesítésével tölti. Erősítő edzéseket és kardiót végez, hogy formában maradjon egy fárasztó versenynapon. Gyakorlatok közös munkával a verseny során felmerülő problémák megoldására. Hasonlóképpen, a fejlesztőcsapatnak képeznie kell az új verziók gyakori kiadásának készségét. Ha rendelkezik ilyen képességekkel és jól működő biztonsági rendszerrel, akkor az új verziók gyártásba helyezése is gyakrabban történik meg. Ebben a világnézetben a megnövekedett sebesség nagyobb biztonságot jelent” – mondja Short.
„Nem arról van szó, hogy a „helyes dolgot” tegyük – teszi hozzá Short –, hanem arról, hogy a lehető legtöbb dolgot kiküszöböljük, ami a kívánt eredmény útjában áll. Együttműködjön és alkalmazkodjon a valós időben kapott visszajelzések alapján. Készüljön fel az anomáliákra, és dolgozzon a minőség javításán, hogy minimálisra csökkentse azok hatását a célja felé haladva. Ez vár ránk a DevOps világában.”
A DevOps méretezése: 10 tipp szakértőktől
Csak arról van szó, hogy a DevOps és a tömeges DevOps teljesen különböző dolog. Megmondjuk, hogyan lehet leküzdeni az akadályokat az elsőtől a másodikig vezető úton.
Sok szervezet számára a DevOps-hoz vezető út könnyen és kellemesen kezdődik. Szenvedélyes kis csapatok jönnek létre, a régi folyamatokat újak váltják fel, és az első sikerek sem várnak sokáig.
Sajnos ez csak egy hamis csillogás, a haladás illúziója – mondja Ben Grinnell, a North Highland tanácsadó cég ügyvezető igazgatója és digitális részlegének vezetője. A korai győzelmek minden bizonnyal biztatóak, de nem segítik elérni a végső célt, a DevOps széles körű bevezetését a szervezetben.
Könnyen belátható, hogy az eredmény a „mi” és az „ők” közötti megosztottság kultúrája.
„A szervezetek gyakran indítják el ezeket az úttörő projekteket, és azt gondolják, hogy kikövezik az utat a mainstream DevOps számára, anélkül, hogy mérlegelnék, hogy mások képesek-e vagy hajlandóak-e követni ezt az utat” – magyarázza Ben Grinnell. – Az ilyen projektek megvalósítására szolgáló csapatokat általában magabiztos „varangiakból” toborozzák, akik már máshol csináltak hasonlót, de újak az Ön szervezetében. Ugyanakkor arra ösztönzik őket, hogy szegjék meg és semmisítsék meg azokat a szabályokat, amelyek mindenki másra nézve kötelezőek. Könnyen belátható, hogy az eredmény a „mi” és az „ők” kultúrája, amely gátolja a tudás és készségek átadását.”
„És ez a kulturális probléma csak az egyik oka annak, hogy a DevOps nehezen méretezhető. A DevOps csapatai megnövekedett technikai kihívásokkal néznek szembe, amelyek jellemzőek a gyorsan növekvő IT-első cégekre” – mondta Steve Newman, a Scalyr alapítója és elnöke.
„A modern világban a szolgáltatások azonnal megváltoznak, amint szükség van rá. Nagyon jó dolog folyamatosan új funkciókat bevezetni és bevezetni, de ennek a folyamatnak a koordinálása és a felmerülő problémák kiküszöbölése komoly fejtörést okoz – teszi hozzá Steve Newman. – A nagyon gyorsan növekvő szervezetekben a többfunkciós csapatok mérnökei küzdenek azért, hogy megőrizzék láthatóságukat a változásban és az általuk létrehozott függőségi szintű lépcsőzetes hatásokban. Ráadásul a mérnökök nem örülnek, ha megfosztják őket ettől a lehetőségtől, és ennek következtében nehezebben értik meg a felmerülő problémák lényegét.”
Hogyan lehet leküzdeni ezeket a fent leírt kihívásokat, és hogyan lehet áttérni a DevOps tömeges elfogadására egy nagy szervezetben? A szakértők türelmet kérnek, még akkor is, ha a végső cél a szoftverfejlesztési ciklus és az üzleti folyamatok felgyorsítása.
1. Ne feledje, hogy a kultúraváltáshoz idő kell.
Jayne Groll, ügyvezető igazgató, DevOps Institute: „Véleményem szerint a DevOps bővítésének éppoly inkrementálisnak és iteratívnak kell lennie, mint az agilis fejlesztésnek (és ugyanúgy érintenie kell a kultúrát). Az Agilis és a DevOps a kis csapatokra helyezi a hangsúlyt. De ahogy ezeknek a csapatoknak a száma és az integráció növekszik, egyre többen alkalmaznak új munkamódszereket, és ennek eredményeként hatalmas kulturális átalakulás megy végbe.”
2. Szánjon elegendő időt a tervezésre és a platform kiválasztására
Eran Kinsbruner, a Perfecto vezető műszaki evangélistája: „A skálázás működéséhez a DevOps csapatoknak először meg kell tanulniuk kombinálni a hagyományos folyamatokat, eszközöket és készségeket, majd lassan ápolniuk és stabilizálniuk kell a DevOps egyes fázisait. Minden a felhasználói történetek és értékfolyamok gondos megtervezésével kezdődik, majd a szoftverek megírásával és a verzióvezérléssel trönkalapú fejlesztéssel vagy más, a kód elágazásához és egyesítéséhez legalkalmasabb megközelítéssel kezdődik.”
„Ezután jön az integráció és a tesztelés szakasza, ahol már szükség van egy méretezhető platformra az automatizáláshoz. Itt fontos, hogy a DevOps csapatok a tudásszintjüknek és a projekt végső céljainak megfelelő platformot válasszák.
A következő fázis a termelésbe való bevezetés, és ezt teljesen automatizálni kell hangszerelési eszközök és konténerek segítségével. Fontos, hogy a DevOps minden szakaszában legyen virtualizált környezet (termelési szimulátor, minőségbiztosítási környezet és tényleges termelési környezet), és mindig csak a legfrissebb adatokat használjuk a tesztekhez a releváns következtetések levonásához. Az Analyticsnek intelligensnek kell lennie, és képesnek kell lennie nagy adatok feldolgozására gyors és hatékony visszajelzéssel.”
3. Vegye ki a bűntudatot a felelősség alól.
Gordon Haff, a RedHat evangélista: „A kísérletezést lehetővé tevő és ösztönző rendszer és légkör létrehozása lehetővé teszi az úgynevezett sikeres kudarcokat az agilis szoftverfejlesztésben. Ez nem jelenti azt, hogy senki más nem felelős a kudarcokért. Valójában a felelős személy azonosítása még könnyebbé válik, mivel a „felelősnek lenni” már nem azt jelenti, hogy „balesetet okozunk”. Vagyis minőségileg megváltozik a felelősség lényege. Négy tényező válik kritikussá: a zavar mértéke, a megközelítések, a termelési folyamatok és az ösztönzők.” (Ezekről a tényezőkről bővebben Gordon Huff „DevOps leckék: Az egészséges kísérletek 4 aspektusa” című cikkében olvashat.)
4. Tisztítsa meg az utat előre
Ben Grinnell, a North Highland tanácsadó cég ügyvezető igazgatója és digitális részlegének vezetője: „A méretarány eléréséhez javaslom egy „úttisztítási” program elindítását úttörő projektekkel együtt. Ennek a programnak a célja a DevOps úttörői által hátrahagyott szemét, például az elavult szabályok és hasonló dolgok eltakarítása, hogy a továbblépési út szabad maradjon.”
„Adjon az embereknek szervezeti támogatást és lendületet olyan kommunikációval, amely jóval túlmutat az úttörő csoporton, és széles körben ünnepli az új munkamódszerek sikereit. Tanítson olyan embereket, akik részt vesznek a DevOps projektek következő hullámában, és idegesek a DevOps első használatától. És ne feledje, hogy ezek az emberek nagyon különböznek az úttörőktől.”
5. Demokratizálja 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 könnyen elsajátíthatónak kell lenniük bárki számára, aki hajlandó időt szánni rá. Ha a naplók lekérdezésének képessége három olyan személyre korlátozódik, akik „tanúsítvánnyal rendelkeznek” egy eszköz használatára, akkor mindig legfeljebb három ember áll rendelkezésére a probléma kezelésére, még akkor is, ha nagyon nagy számítási környezettel rendelkezik. Vagyis itt van egy szűk keresztmetszet, amely súlyos (üzleti) következményekkel járhat.”
6. Teremts ideális feltételeket a csapatmunkához
Tom Clark, az ITV Common Platform vezetője: „Bármit megtehetsz, de nem mindent egyszerre. Tehát tűzz ki nagy célokat, kezdd kicsiben, és haladj előre gyors iterációkkal. Idővel hírnevet szerez a dolgok elvégzése terén, így mások is használni fogják a módszereidet. És ne aggódjon egy rendkívül hatékony csapat felépítése miatt. Ehelyett biztosítsunk az embereknek ideális munkakörülményeket, és a hatékonyság követni fogja.”
7. Ne feledkezzünk meg a Conway törvényről és a Kanban táblákról
Logan Daigle, a CollabNetVersionOne szoftverszállítási és DevOps-stratégiájáért felelős igazgatója: „Fontos megérteni a Conway-törvény következményeit. Az én laza parafrázisomban ez a törvény kimondja, hogy az általunk létrehozott termékek és az ehhez használt folyamatok, beleértve a DevOps-ot is, ugyanolyan felépítésűek, mint a szervezetünk.”
„Ha sok siló van egy szervezetben, és az irányítás sokszor gazdát cserél szoftverek tervezése, építése és kiadása során, akkor a méretezés hatása nulla vagy rövid életű. Ha egy szervezet többfunkciós csapatokat épít fel olyan termékek köré, amelyeket piacfókuszban finanszíroznak, akkor a siker esélye drámaian megnő.”
„A méretezés másik fontos szempontja az összes folyamatban lévő munka (WIP, workinprogress) megjelenítése a Kanban táblákon. Ha egy szervezetnek van olyan helye, ahol az emberek láthatják ezeket a dolgokat, az nagyban ösztönzi az együttműködést, ami pozitív hatással van a méretezésre.”
8. Keresse a régi hegeket
Manuel Pais, DevOps tanácsadó és a Team Topologies társszerzője: „A DevOps gyakorlatokat túllépni magán a Dev és az Ops-on, és megpróbálni más funkciókra alkalmazni, aligha az optimális megközelítés. Ennek minden bizonnyal lesz hatása (például a kézi vezérlés automatizálásával), de sokkal többet érhetünk el, ha a szállítási és visszacsatolási folyamatok megértésével kezdjük.”
„Ha egy szervezet informatikai rendszerében régi sebhelyek vannak – olyan eljárások és irányítási mechanizmusok, amelyeket múltbeli incidensek eredményeként vezettek be, de (a termékekben, technológiákban vagy folyamatokban bekövetkezett változások miatt) elvesztették relevanciájukat –, akkor ezeket mindenképpen el kell távolítani. vagy kisimítjuk, ahelyett, hogy automatizálnánk a nem hatékony vagy szükségtelen folyamatokat.”
9. Ne szaporítsd a DevOps opciókat
Anthony Edwards, az Eggplant műveleti igazgatója: „A DevOps egy nagyon homályos fogalom, így minden csapat a saját DevOps-verziójával zárul. És nincs is annál rosszabb, ha egy szervezetnek hirtelen 20 fajta DevOps van, amelyek nem jönnek ki jól egymással. Lehetetlen, hogy mind a három fejlesztőcsapatnak saját, speciális felülete legyen a fejlesztés és a termékmenedzsment között. A termékeknek nem lehetnek saját egyedi elvárásaik a visszajelzések kezelésével kapcsolatban, amikor átkerülnek egy gyártási szimulátorba. Ellenkező esetben soha nem lesz képes a DevOps méretezésére.”
10. Hirdesse a DevOps üzleti értékét
Steve Newman, a Scalyr alapítója és elnöke: „Dolgozz a DevOps értékének felismerésén. Tanuljon, és nyugodtan beszéljen a tevékenységének előnyeiről. A DevOps hihetetlenül időt és pénzt takarít meg (gondoljunk csak bele: kevesebb állásidő, rövidebb átlagos felépülési idő), és a DevOps csapatoknak fáradhatatlanul hangsúlyozniuk kell (és hirdetniük kell) e kezdeményezések fontosságát az üzleti siker szempontjából. Így bővítheted a hívek körét és növelheted a DevOps befolyását a szervezetben."
BONUS
tovább A saját DevOps-unk szeptember 13-án érkezik – igen, a Red Hat szoftvergyártóként saját DevOps csapatokkal és gyakorlatokkal rendelkezik.
Mérnökünk, Mark Birger, aki belső automatizálási szolgáltatásokat fejleszt más csoportok számára a szervezeten belül, tisztán oroszul meséli el saját történetét – hogyan migrálta át a Red Hat DevOps csapata az alkalmazásokat az Ansible által kezelt Hat Virtualization virtuális környezetekből egy teljes értékű konténer formátumba. az OpenShift platform.
De ez még nem minden:
Miután a szervezetek áthelyezték a munkaterheléseket tárolókba, előfordulhat, hogy a hagyományos alkalmazásfigyelési módszerek nem működnek. A második előadásban elmagyarázzuk a naplózási mód megváltoztatásának motivációit, és bemutatjuk annak az útnak a folytatását, amely elvezetett minket a modern naplózási és megfigyelési módszerekhez.
Forrás: will.com