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?
