Rendszeresen feltűnnek és elterjednek IT-varázsszók, a vállalkozásoktól kezdve a nagyvállalatokig felkapottá válnak, és ki-ki a maga módján igyekszik értelmezni és integrálni azokat. Az elmúlt hónapokban a „DevOps” nőtt ilyen varázsszóvá. Arra voltunk tehát kíváncsiak, hogy mikor és miért van értelme bevezetni a működésmódot, és az ideális DevOps-szakember profiljáról is képet kaptunk két, a témában jártas szakembertől.
Mielőtt egy cég a bevezetés mellett teszi le a voksát „a DevOpsot, mint annyi informatikai alap platformot, csak megfelelő üzleti elvárásoknak való megfelelés miatt szabad bevezetni. Mindemellett nagyon fontos, hogy az üzleti elvárások kellően pontosak legyenek és az üzleti képviselők a saját szakterületükön értsék is a lehetőségeket és a korlátokat, no meg a rájuk háruló feladatokat is”, fogalmazta meg Gazdag Ferenc, az MVM Digitalizációs Transzformációs Központ vezetője.
Ugyanakkor a szervezet mérete és típusa sem mindegy. „Alapvetően egy kisebb szervezetnél, ahol a szerepköri határok jobban összemosódnak, könnyebb bevezetni a »tiszta« DevOps-szemléletet. Minél szigorúbban elhatárolt a fejlesztés és az üzemeltetés egymástól, annál többet kell a »tiszta« szemléleten változtatni. A K&H esetében a fejlesztés és az üzemeltetés külön szervezeti egységek alá tartoznak például a pénzügyi, információbiztonsági és törvényi elvárások miatt is. Itt azt a »tiszta« szemléletet, hogy aki fejleszt, az akár üzemeltessen is, rendkívül nehéz alkalmazni. Persze attól, hogy a DevOps-szemlélet az eredetileg definiált módon egy az egyben nem alkalmazható ránk, még magunkra igazíthatjuk”, mondta Ozorai Dénes, a K&H Csoport CIO-ja.
A DevOpshoz vezető út szervezeti változással van kikövezve
A meghatározott bevezetési célon túl szükség van arra is, hogy a szervezet „megérjen” arra a változásra, amelyet a DevOps-szemlélet magával hoz. Mindenekelőtt fontos definiálni, hogy a szervezet számára mit jelent a DevOps-szemlélet, -működés, a szervezet lehetőségeihez mérten meg kell vizsgálni, hogy hová szeretne, tud eljutni DevOps-érettségben, és ehhez milyen technikai, folyamati, szervezeti és egyéb változások szükségesek.
„Ebben segíthet egy kezdeti DevOps-érettégi vizsgálat, amely segít annak eldöntésében, hogy hol tartunk most, és ezt a kitűzött céllal összevetve kialakulhat, hogy milyen szervezeti, kulturális, technológiai, irányítási változások szükségesek és milyen léptékben a DevOps-működés megvalósításához. Kézenfekvőnek tűnik a szemlélet nevében lévő két szerepkör együttműködési határainak újra gondolása és alapvetően túl kell lépni az autokratikus ragaszkodáson, azaz az »én területem, üljenek velem, csinálják, amit mondok« működésen”, mondta Ozorai Dénes.
Mindezek mellett ki kell alakítani a kollégák között egy platformot, amelyen keresztül egymáshoz közelebb kerülhetnek, akár egy helyen ülhetnek, amit manapság, az online meetingek térnyerésével nagyságrendekkel egyszerűbb megvalósítani.
„Véleményem szerint a DevOps igazából egy technológiai környezet. Ha szigorúan vesszük, akkor ennek bevezetésénél, használatba vételénél akár ki is hagyhatjuk a szervezeti változást. De természetesen nem érdemes, hiszen a helyesen használt technológia nyújtja az igazi hatékonyságnövekedést. Mindenképpen célszerű egy ilyen rendszer bevezetését valamilyen üzleti eseményhez, bevezetéshez kötni, s nem »l’art pour l’art« bevezetni. Egy kisebb vagy közepes projekt kapcsán mind az üzleti terület, mind az informatikai terület menet közben ráérezhet az újdonság varázsa után az igazi értékeire”, mondta el Gazdag Ferenc.
Ozorai Dénes szerint a bevezetés egy másik aspektusa a munkahely féltése, ami tipikusan az üzemeltetési (Ops) kollégáknál jelentkezik: „kellek én még a jövőben, ha minden automatizált?” Ez is jól mutatja, hogy nemcsak szervezeti, hanem szemléletváltásra is szükség van. Ebben az esetben például meg kell értetni a kollégákkal, hogy az automatizáció ugyan valóban kivált bizonyos (repetitív) tevékenységeket, de hoz is be új feladatokat: például az automatizációhoz szükséges szoftvereszközök írása, karbantartása.
A sikeres bevezetés kulcsa, hogy egy adott szervezetben egy lépésben csak akkora változtatást vigyenek véghez, amekkorát a szervezet még elfogad, és a teljes változtatást kisebb állomásokra bontva érdemes végrehajtani. „Ennek kiteljesüléséhez szükséges, hogy a vezetői kompetenciákban is erőteljesen megjelenjen a felhatalmazás, delegálás témaköre, hiszen semmit nem ér egy gyorsításra létrehozott rendszer, amelyben a kiadáskezelés jóváhagyása továbbra is hetekig tart”, hangsúlyozta Gazdag Ferenc.
A DevOps fejlesztő/üzemeltető profilja, avagy kiből lehet jó DevOps-os?
„A jelölt elvárt hard skillje, hogy értse az üzemeltetési környezetet sajátosságait, például az Openshiftet, képes legyen a programtervezési alapelvein módosítani a jobb automatizálhatóságot és üzemeltethetőséget szem előtt tartva. Értse a scriptelési és monitorozhatósági korlátokat. Soft skillek tekintetében legyen egy sokkal szélesebb spektrumú csapat játékosa, az üzemeltetési és fenntarthatósági aspektusokra legyen nyitott, érzékeny”, véli Ozorai Dénes, aki hozzátette, hogy a fejlesztési képességeken (skilleken) túl elengedhetetlen, hogy nyitottnak kell lenni az üzemeltetési aspektusokra és azok támogatására. Egy olyan fejlesztő, aki kizárólag az üzleti igényekre fókuszál, és az általa fejlesztett alkalmazás automatizálhatóságát, monitorozhatóságát nem tartja szem előtt, nem lesz megfelelő.
Gazdag Ferenc szerint sem kell teljesen más profilú kolléga. „Természetesen, a technikai tudásnak birtokában kell lennie, hogy miként működik a rendszer és ki kell lépni az elefántcsonttornyából, és valakinek kell éreznie magát, amikor valami napi szintű, rendszeres üzemeltetési feladatot kell valakinek ellátnia.”
Ami pedig az átképzést illeti, van nyitottság arra, hogy a hagyományos működéshez szokott fejlesztő a DevOps közegében érvényesüljön, és ugyanez igaz az üzemeltetőkre is, ehhez azonban meg kell ismerniük a saját és társterületük működési határait, valamint megfelelően kell érzékenyíteni a fejlesztőket az üzemeltetési problémákra, az üzemeltetőket a fejlesztési nehézségekre.
Kiss Franciska
