Devops, vagy ITIL, alapú IT üzemeltetés egy Agilis környezetben. Hogyan bontsuk le a falakat, ha azok (még) meg sem épültek?

 

Napjaink egyik Informatikai menedzsmentet érintő slágertémája a DevOps. Minden vállalat gyorsítani akarja a fejlesztési folyamatait, csökkenteni az átfutási időt és javítani a fejlesztés minőségét. De aki csökkenteni akarja az üzemeltetés során felmerült problémákat szembekerül azzal a dilemmával, hogy a fejlesztési folyamatait változtassa meg, vagy az üzemeltetési folyamatait módosítsa.

 

A fejlesztők -agilisen vagy nem- de általában természetesen jól meghatározott módszertanok alapján dolgoznak. Munkájuk eredményét letesztelt, végletekig optimalizált fejlesztési termékként átadva vágnak a következő feladatba. Nekem van azért olyan ismerősöm, akinek a munkahelyén ezek a célok csak részben teljesülnek és az átadás inkább egy kerítésen való átdobáshoz hasonlítható.

Az üzemeltetők jó esetben ITSM rendszerben (ITIL szerint) végzik a dolgukat. Jól bejáratott optimalizált folyamataik vannak, a folyamat paraméterek részletesen mérhetők, ezért könnyen ki tudják mutatni, hogy a munkájuk nagy része a fejlesztési hiányosságok, hibák kijavítása. Ismerősöm meséli, hogy náluk az üzemeltetés azt a bizonyos kerítést jó magasra emelte, hogy csak az igazán jó vagy fifikásan előkészített fejlesztések jussanak át rajta. Ennél a vállaltnál az üzemeltetés gyakran a fejlődés kerékkötője szerepben találja magát, pedig csak stabilitásra törekszik. 

Ismerős a helyzet?

A DevOps azt ígéri, hogy a vállalti kultúra megváltoztatásával, a fejlesztés és az üzemeltetés közötti falak lebontásával, a folyamatok és nem egyszer a szervezetek integrálásával valamint nem utolsósorban a támogató eszközök, automatizmusok bevezetésével lebontja ezeket a falakat. 

Ennek bevezetése bizony szervezeti változás annak minden aspektusával együtt, amiről változásmenedzsment szakirodalom sokasága szól, a szervezet természetes ellenállásától kezdve a stakeholder menedzsmenten át a kongruencia modellig. Ez a cikk azonban nem a változás menedzsmentről szól. Korrigálok, csupán annyiban szól a változás menedzsmentről amennyire az élet általában a változásról szól.

 

 

A kerítés két oldalán

Ha a különböző módszertanokat az emberek, a folyamatok és az eszközök által meghatározott térben vizsgáljuk a következőket találjuk. Először is itt van az…

Az ITIL különböző verziói leginkább a folyamatokra koncentrálnak. A különböző jól definiált, testreszabott folyamatok pontos betartása az ígéret szerint garantálja a sikert. A KPI-ok mentén mérhető célok fogalmazhatók meg, a fejlődésnek megvannak az alapjai. Az emberek az ITIL szerint leginkább a folyamatok végrehajtói. A pontosan meghatározott lépések a feladatkör és felelősség sokakat nyomaszt, mások viszont élvezik a pontos munkaköri definíciókat. Ugyanakkor a rosszul implementált ITSM folyamat nem egyszer hátráltatja a működést. (a már emlegetett ismerősünknek is megvan a rendszergazda mobilszáma, ha a service desk esetleg nem lenne elég gyors) Az ITIL-re alapuló támogató eszközök, rendszerek leginkább a folyamatra fókuszálnak.

Hozok egy szándékosan sarkított analógiát. A fotózás akkor sem egy nagyon összetett folyamat, ha nem teljesen automata kamerát használunk hanem különös gondot fordítunk arra, hogy nagyon szépek legyenek a képeink. Először is témát választunk, majd felmérjük a fényviszonyokat. A fényhez és a témához beállítjuk a megfelelő záridőt, ha túl hosszú akkor állványt használunk, esetleg vakut. Beállítjuk a rekeszt is, ez utóbbival meghatározzuk a mélységélességet. A fénynek megfelelő rekeszt és a záridőt ma már nem számoljuk táblázatokkal, ezt az automata megteszi helyettünk. Megkomponáljuk a képet és a megfelelő pillanatban kattintunk. Aztán elkészül egy technikailag tökéletes fotó. Ha szerencsénk van a célközönségünknek is tetszik.

Ugye milyen egyszerű? Csak 3 paraméter. Tegye fel a kezét, aki így fényképez! Nincsenek sokan.

 

 

A másik módszertan, ami a fejlesztések, de már a szervezeti működés témájában is szembejön az …

Az Agilis fejlesztési módszertanok motorja a kreatív ember, aki szabad kezet kap, próbálkozik, kommunikál, együttműködik, alkot. Ha kell módosítja a célját, alkalmazkodik a körülményekhez, rugalmas.

Az agilis metodológia módszereket ajánl, amelyek a hatékony együttműködést segítik elő, kanban táblákkal, standup és retrospektiv meetingekkel, user story-kkal, sprint szervezési tanácsokkal. Az agilis módszertanok ritkán definiálják pontosan a be és kimenteket, de az együttműködés módszerei mentén ezek végül mindig kialakulnak. A felhasznált támogató eszközök hatékonyan segítik a munkát, mérhetőséget, kommunikációt és vizualitást biztosítanak.

A fotós analógiát erre alkalmazva a fényképező gép alap beállítása után (out of the box) lövünk egy képet majd megmutatjuk a célközönségünknek. Közösen elemezzünk hogyan lehetne a képünk szebb, használhatóbb, majd lövünk egy újat. Ezt is megmutatjuk, elemezzük, finomítjuk. Néhány kör után eljutunk odáig, hogy az eredmény tökéletesen megfelel az igényeknek. Ugyanakkor már az első képünk megfelelt az alapelvárásnak és használható volt. Profi fotózásokon láthatunk ehhez némileg hasonló módszert, persze ők ismerik használják azt a bizonyos három paramétert.

 Végül, de nem utolsósorban jöjjön a …

 

A DevOps nem kevesebbet ígér, minthogy a fejlesztés és az üzemeltetés közötti falak lebontásával, az end to end gondolkodás és felelősség kultúrájának elterjesztésével, különböző módszerek alkalmazásával valamint -nem utolsósorban- a tesztelési, többszintű monitoring és automatizálási eszközök széles körű használatával lerövidíti a fejlesztéshez szükséges időt, növeli a
fejlesztések minőségét és ezáltal stabilabb lesz az üzemeltetés, az alkalmazások rendelkezésre állás megnő. 

 

A DevOps is érinti az emberek a folyamatok és az eszközök által meghatározott koordinátarendszer mindhárom irányát, mégis inkább az eszközök oldalán erős igazán. 

A fotós példa kapcsán nekem a mai mobil telefonok jutnak eszembe. 4-5 különböző objektív is van bennük, egy kattintásra objektívenként 5-10 képet csinálnak. Ebből a 20-50 képből egy erős processzorral megtámogatott alkalmazás még a telefonban összerak egy fotót, elképesztő technológiai hátteret, mérnöki, programozói tudást felhasználva. Az eredmény általában technikai és a téma szempontjából is jó. Aztán miután a fotó felkerül a szolgáltató cloud tárhelyére a különböző algoritmusok és AI motorok hada még
elemzi azt, hogy a következő verziójú alkalmazás a telefonban még jobb legyen. Csak ezután következnek a közösségi platformok témaspecifikusra programozott szűrői, akik még tovább igazítják a beállításokat, teljesen automatán.

Az emberek nagy része a programozók, AI algoritmusok, témaspecifikusra programozott szűrők segítségében bízva vakuzik bele a Napba, ha naplementét fényképez. Pedig csak azt a 3 paramétert kellene ismerni és máris kevesebb mérnökórára és processzor időre lenne szükség. 

De mi a megoldás?

Van annak a kérdésnek értelme, hogy Agilis módszertan helyett DevOps? Természetesen nincs, teljesen másra való a két módszertan. Mint ahogy az sem értelmes kérdés, hogy ITIL helyett DevOps. 

 

Mindegyik módszertan természetesen mindhárom vizsgált aspektusra kitér azokra megoldásokat ad, a hangsúly azonban máshol van.

 

Lehetséges olyan IT szervezetet építeni, amely az említett világokból az erősségeket használja fel – természetesen megőrizve a módszertanok konzisztenciáit.

  • Fejlesszünk agilisen és a jól bevált együttműködési, munkaszervezési elemeket vigyük tovább az üzemeltetési területre.
  • Teremtsük meg az ITIL alapú üzemeltetés minden szükséges részelemét, hiszen azok alkotnak zárt jól működő folyamati struktúrát, viszont mindent amit lehet automatizáljunk, gyorsítsunk fel.
  • Bontsuk le a falakat, DevOps gondolkodással, sőt ha lehet inkább meg se építsük őket. 

Hogy hogyan, mondok rá egy példát:

Egy nagy, nemzetközi cloud szolgáltató üzemeltetési munkatársával a release menedzsmentről beszélgettünk. Nagyon csodálkozott amikor elmondtam neki, hogy a már említett ismerősöm cégénél a release menedzsmentet nem szeretik a fejlesztők, mert úgy érzik gátolja, lassítja a munkájukat és a felesleges adminisztráció meg a zabhegyező jellegű release board meetingek miatt csúsznak az élesítések. Elmondása szerint náluk a release menedzsment az egyik legfontosabb és legszigorúbban betartott folyamat. Nem is lehetne ezt máshogy csinálni mondta, hiszen nagy számú release élesedik minden egyes nap. Emiatt megtámogatták a folyamatot automatizmusokkal, tesztautomatákkal, scriptekkel, viszont nem mehet ki olyan fejlesztés, ami nem megy át a release folyamaton. A release folyamat megalapozásához szükséges a CMDB és architektúra nyilvántartás, mert anélkül mégis hogyan terveznél meg egy csomagot. Az release-t az esetek többségében először csak egy bizonyos felhasználói kör kapja meg jelentős telemetriával, monitoringgal megtámogatva. Az incidens menedzsment által kezelt hibák gyökérokait a problem menedzsment csapat a telemetria adatokra támaszkodva hamar kideríti és csatolja vissza szükség szerint a fejlesztőknek, akik már teszik is bele a sprintbe. A Blue/Green módszertan miatt az élesítés és az esetleges rollback is percek alatt megvan.

  • ITIL alapú? Igen.
  • Agilisen működő? Természetesen.
  • DevOps módszertant alkalmazó? Nyilván.

Hát így valahogy.

Nemrég olvastam egy cikket Máté Bence világhírű természetfotós munkamódszeréről. Bence hosszan tanulmányozza az állatok viselkedését, majd ehhez megfelelő lest épít. Fejben képet komponál, beállítja a fényviszonyokhoz a rekeszt meg a záridőt, vár a pillanatra, igazítja, finomítja a paramétereket, vár, vár, vár, majd a megfelelő pillanatban a professzionális technikát kihasználva ellő néhány tucat képet egy témára. Ezután a feldolgozási szakaszban a jelenleg rendelkezésére álló összes szoftveres technológiát felhasználva elemzi, finomítja és tökéletesíti a képet.

Majd általában nyer egy díjat a fotóval.

A megoldás folyamat, az ember és a technológia egyensúlya. Van olyan ismerősötök, akinek a munkahelyén ezt igy csinálják?

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük