Sokféleképpen lehet csinálni, de muszáj csinálni: a fejlesztési és üzemeltetési csapat szervezett együttműködése, a DevOps mára a „jó, ha van” kategóriából átkerült az alapvető szükségletek közé. Ettől még számos szervezetnél küszködnek a megvalósítással, különösen, ami a DevOps szemléletű kultúra meghonosítását illeti.
◼︎ A DevOps már a vállalati Maslow-piramis alapját adja
Az üzleti környezetet és a bejövő igényeket most már évtizedek óta meghatározzák olyan trendek, mint a felhő vagy az AI és nem is számíthatunk arra, hogy ez a tempó lassulni fog. Az informatikának ezt le kell tudnia követni, sőt, sokszor vezetnie kell a változást. Három érdekelt felet lehet megkülönböztetni: az üzleti oldali megrendelőt, a kódot létrehozó fejlesztőket és az üzemeltetésért felelős informatikusokat.
Az üzlet és a fejlesztők közötti folyamatokat az agilis módszertanokkal a legtöbb helyen mára sikerült felpörgetni, és akár naponta lehet készíteni az újabb szoftververziókat. Igen ám, de ezeket éles üzembe is kell állítani, lehetőleg biztonságosan – vagyis a fejlesztők és az üzemeltetők közötti folyamatokat, együttműködést is fel kell turbózni.
„Itt jön képbe a DevOps, és ezért mondhatjuk, hogy mára a vállalati Maslow-piramis alapjára került. Ez a szemlélet és az eszköztár nélkülözhetetlen lett a vállalkozások folyamatos és biztonságos működéséhez, valamint a változó üzleti tényezőkre való gyors reagáláshoz és a versenyképesség megőrzéséhez”, fejti ki a változás legfőbb okát Mádi Gábor, a Shiwaforce CIO-ja és a DevOps Natives üzletág vezetője.
A nagyvállalatok többsége már elvár valamilyen felhőalapú és konténerizációs technológiát (Docker, Kubernetes, OpenShift), és gyakran előírják, hogy milyen formában kérik az új fejlesztéseket. Mádi Gábor egy analógiával él: nem egyszerűen a kívánt rakományt definiálják, hanem magát a vasútállomást is, amelyre csak a megfelelő vonat tud beállni. Így bármilyen IT projektben a fejlesztő cégeknél is megkerülhetetlen tényező lett ezen képességeknek megléte. Azokkal az IT beszállítókkal, ahol ez a tudás nincs meg vagy gyenge, kockázatos az együttműködés.
Nyomás alatt nincs kultúraváltás
A Shiwaforce saját ügyfél projekt tapasztalatai, az elmúlt évben a nyugat-európai piacon végzett saját kutatásai, illetve a globális elemzések tanulságai egybevágnak: a DevOps megvalósításának elsősorban nem anyagi, hanem kulturális akadályai vannak. Az eszközök, a technológia rendelkezésre áll. A két legelterjedtebb megoldás az Atlassian és a GitLab, előbbi itthon messze piacvezető, saját mérések alapján az IT cégek körülbelül 70 százaléka Atlassian stacket használ. A módszertanok is elérhetőek, tehát látszólag semmi akadálya annak, hogy a vállalatok felállítsák a saját DevOps csapataikat.
A szervezetekre azonban üzleti és technológiai nyomás nehezedik: „hol az árbevétel?”, „a jövő hétre már kész kell lennie!” Ez oda vezet, mondja Mádi Gábor, hogy többnyire csak folyamatos tűzoltásra van idő. „Szeretnének DevOps kultúrát kialakítani, de azonnal kell két Azure-hoz értő ember, különben nem halad a projekt”, érzékelteti a tipikus igényeket.
Érdekes módon a technológiailag előrébb járó nyugat-európai és skandináv piacokon ugyanazokkal a szakmai és technológiai nehézségekkel küzdenek a vállalatok, mint itthon. Ahogy Mádi Gábor fogalmaz, a cégek elvesznek a DevOps-kihívások Bermuda-háromszögében: hiányzik a csapatkohézió, elavult gyakorlatokat visznek tovább, miközben az egyre összetettebb biztonsági kihívásoknak is igyekeznek megfelelni. Ugyancsak nehézségekbe ütköznek, amikor hozzáértő DevOps- mérnököket szeretnének találni; ha pedig mégis sikerül, nagyon kell figyelni a munkatársak kiégésének elkerülésére.
Szakértő kell, azonnal, de milyen?
Számos vállalat igyekszik házon belül kialakítani a DevOps szakértői bázist, akár belső munkatársak átvételével, akár külső keresések révén. Szakértőből azonban hiány van, ezért túl sokáig tart megtalálni őket, túl sokba kerülnek és nehezen megoldható a szakmai tudás folyamatos karbantartása. Jó kérdés még, hogy az üzemeltetési vagy a fejlesztési szakemberből lesz jobb DevOps-mérnök. Mádi Gábor szerint a válasz attól függ, hogy milyen a csapat felépítése, és ott milyen feladatot lát el az illető. Ha tevékenysége inkább az infrastruktúrához, felhőautomatizációhoz áll közel, akkor az üzemeltető van előnyben; de ha mondjuk CI/CD szkripteket kell írni Jenkinsben, ott a fejlesztő fog jobban teljesíteni. „Annyiféle szakág van már, hogy nem beszélhetünk általában DevOps-szakemberről”, teszi hozzá.
Szintlépés külső facilitátorral
Bármennyire is szeretnék a vállalatok házon belül megvalósítani a DevOps működést, jól jöhet egy objektív külső szakértő. A Shiwaforce bevált gyakorlata, hogy először átvilágítja a fejlesztési értékáram egészét, és megkeresi, hogy mely lépéseknél és mely folyamatokban (tervezés, fejlesztés, tesztelés, élesítés) jelentkeznek leginkább a problémák. A felmérés eredményeiből jól látszik, ha hiányoznak eszközök, nem kommunikálnak, vagy akár nem is találkoznak egymással a fejlesztők és üzemeltetők, hiányzik a közös megértés.
| DevOps bennszülöttek
A Shiwaforce a tíz éves belső tapasztalataira építette fel az immár regionális piacon aktív DevOps Natives üzletágát. „A nemzetközi szakmai eseményeket körbejárva azt láttuk, hogy Észak- és Nyugat-Európában, de tőlünk délebbre is ugyanazokkal a problémákkal szembesülnek a vállalatok, mint itthon a mi ügyfeleink. Ez viszont azt is jelenti, hogy az itthon megszerzett tudásunk, kompetenciánk abszolút versenyképes a nyugat-európai piacon is. Mi valósítottuk meg a régió első Atlassian felhőmigrációs projektjét, ráadásul egy nyugat-európai bank hazai leányvállalatánál, így magabiztosan tudjuk támogatni más országok banki szereplőit is, akik most indulnak el ezen az úton”, mondja Mádi Gábor. |
A felméréssel párhuzamosan már folytatnak érzékenyítő tréningeket, ahol igyekeznek megtalálni a különböző csapatok közötti közös nyelvet és megmutatni nekik a technológiát. Mindezek mentén születik egy megvalósítási terv, amely nagyobb vállalatoknál akár több éves feladatokat is kijelölhet: az első év jellemzően a felmérés és a tervezés fázisa, a másodikban történik a bevezetés és az oktatás, és az ezt követő időszakban lehet kiterjeszteni az új működést a teljes szervezetre.
„Mindez persze nem megy erős felsővezetői felhatalmazás és támogatás nélkül, hiszen alkalomadtán fájdalmas szervezetátalakítási döntéseket kell meghozni. Akkor nem történik meg a varázslat, ha csak részfeladatokra fókuszálnak, vagy ha az üzemeltetők továbbra is a szerverterem mellett ülnek, a fejlesztők pedig home office-ban dolgoznak, és még csak nem is találkoznak egymással”, hívja fel a figyelmet egy fontos tényezőre Mádi Gábor.
Gépek, kódok, emberek együttműködése a jövő
A közeljövő egyik fontos trendje az lesz, hogyan lehet a mesterséges intelligenciát hatékonyan integrálni a DevOps folyamatokba. Már most is lehet CI/CD szkripteket generáltatni a nyelvi modellekkel – de azokban még lesznek hibák, hiányosságok. Ezeket ki kell javítani, különben óriási IT-biztonsági problémák adódhatnak, figyelmeztet Mádi Gábor.
A másik lényeges trendnek a szoftverpiacon régóta ismerős gyártói csapda, a „vendor lock-in” elkerülését látja a szakember. A vállalatok – éppen az üzleti nyomás miatt – sokszor azt az eszközt választják, amelyik együtt tud működni a már bevezetett megoldásokkal, nem pedig azt, amelyik a legmegfelelőbb lenne az adott célra. A kiutat azok a gyártók jelenthetik, amelyek többfelhős (multi-cloud) és az Open DevOps szemléletben működnek. Nagyon jól használhatók együtt például az Atlassian és a GitLab megoldásai. A szoftverfejlesztési projektek levezénylésére az Atlassian terméke, a Jira, de facto iparági szabvánnyá vált, de a beépített integrációs komponenseknek köszönhetően kiválóan együtt tud működni más gyártók, például a GitLab vagy a GitHub megoldásaival, ha valaki azokat használná a CI/CD folyamat kezelésére.
Ebben a témában a Shiwaforce Epic Stories Live Meetup novemberi alkalmán további hasznos és izgalmas részlet hangzik majd el: egy asztalhoz ül az Atlassian és a GitLab szakértője, valamint az egyik legnagyobb hazai pénzügyi vállalati felhasználó, aki mindkét gyártó termékét alkalmazza.
