Még ritkán nevezik nevén a dolgot, de mostanában egyre gyakoribbá válhat, hogy egy vállalat azért megy csődbe, mert képtelen az ötleteit modern IT megoldásokra, szoftverre, kódra lefordítani. Ahogyan ahhoz is hozzászoktunk, hogy egy iparág új szereplője azzal tarolja le a piacot, hogy zseniálisan alakítja digitális termékké az ötleteit.
Az IT az egyik kulcstényező abban, hogy a vállalat rugalmas és gyors legyen, alkalmazkodjon a piaci igényekhez és az üzleti döntéshozók meghozott döntései időben és a várt minőségben landoljanak is az ügyfeleknél.
A nap végén minden ötlet és üzleti döntés egy IT megrendeléssé válik: biztosan lesz digitális termék, folyamat, szoftver és frontend/felhasználói felület is belőle.
Tisztán az 1-1 módszertan vagy technológia nem képes ezt a stabil rugalmasságot skálázhatóan és biztonságosan szállítani, ezért a ShiwaForceban az évek során megtanultuk a hagyományos projektmenedzsmentet, az agilitást és a DevOps területeket közösen termőre fordítani.
Ezek közül talán a legkevésbé ismert “varázsszó” a legtöbbeknek a DevOps. A DevOps a fejlesztés és az üzemeltetés szavak összeolvadásából ered és egy olyan IT kultúrát, aktív együttműködést, filozófiát takar, amelynek célja egy gyors, biztonságos és nem utolsó sorban gazdaságos IT szállítási lánc létrehozása. Üzleti oldalon mindhárom szempont rendkívül fontos.
Olyannyira, hogy a DevOps eszközök piaca a 2018-as 3,42 milliárdról 2023-ra 10,4 2026-ra pedig 15 milliárd dollárra fog nőni a legnagyobb elemzők előrejelzései alapján. (Gartner/Forrester)
Talán könnyebb megérteni az előnyét, ha azt nézzük meg, milyen hibákat rejt magában a DevOps nélküliség:
- instabilitás
- a tervezett eredményektől való folyamatos elmaradás
- óriási késések
- rengeteg manuális munka, hibakeresés
- feleslegesen elvégzett munkák
Mindezek közös tulajdonsága, hogy az ebből fakadó hatások extrém mértékben rontják az ügyfélélményt. Ha legközelebb egy kedvenc szolgáltatónknál azt tapasztaljuk, hogy nem az elvárt módon működik a szoftver, akkor gyanakodjuk nyugodtan, hogy ott nem elég fejlett még a DevOps szemlélet.
Hogyan képzeljük el ezt a gyarkolatban?
A DevOps folyamat leginkább egy fektetett nyolcassal mutatható be, melyben a következő elemek foglalnak helyet: az egyik ágon a tervezés, építés, integráció, a másik ágon az élesítés, megfigyelés, üzemeltetés, plusz a legfontosabb: a visszajelzés. Ez egy állandó és gyors ütemben zajló körforgás, ahol minden egyes fázis folyamatosan és rövid ciklusokban történik és az egyes fázisok képesek hatással lenni egymásra.
A végső cél az akadálymentes és gyors telepítés és üzemeltetés bármilyen szoftverelem esetében. Sokszor tapasztaljuk, hogy az ügyféloldalon nincs kapacitás, hogy beleálljanak a telepítés, integráció folyamatába. Ezért ma már törekszünk arra, hogy a lehető legtöbb konfigurálható automatizációval – “egygombos” megoldásokkal érkezzünk meg, senki nem szereti leállítani a rendszereit.
Ez a megoldás így nem csak gyorsabb, de kisebb a hibázási lehetőség is és magasabb a minőség. A Devops gyakorlatok elmélyítésével az eredetileg hónapokig tartó folyamatok levihetők hetekre, napokra, órákra, majd a végén már percekben számolhatunk. Ez óriási fejlemény!
A szofisztikált eszköztárral arra is képesek vagyunk, hogy az egyébként lassabban és kiszámíthatatlanul érkező nagyvállalatnál üzleti igények ellenére a fejlesztők folyamatosan szállítsanak szoftver modulokat, frissítsék a webes felületet, alkalmazásokat, úgy, hogy a megrendelő saját maga tudja eldönteni, hogy az adott funkciót mikor és kinek kapcsolja be. Az élesítés kontrollját az IT képes ma már átadni az üzleti oldalnak, marketingnek, ami ilyen formán egy kifinomultabb üzleti tervezést is lehetővé tesz. Eközben persze az IT is nyugodtabban, hatékonyabban dolgozhat. Win-win.
A ShiwaForce-ban és a hozzánk hasonló modern digitális vállalatokban már 5-10 éve dolgozunk az egyre fejlettebb DevOps megoldások begyakorlásán, csiszolásán. A DevOps azonban nem egy bináris jelenség, sajnos nem egy pirula, amit lenyelünk és a mátrixban találjuk magunkat és nem egy használom/nem használom kapcsoló. Van nagyon kevés, néhány százaléknyi elitista “éltanuló”, de a vállalatok több mint fele erős lemaradásban van. A State of DevOps globális felmérése szerint a DevOps-ban élen járó cégekhez képest a DevOpsban lemaradóknál 7X annyi esély van arra, hogy egy változtatás hibát okozzon, miközben egy kód teljes útja az üzleti igény érkezésétől a telepítésig átlagosan 106X lassabb.
A legtöbb szervezetnek azért akad meg a torkán a DevOps, mert egy IT keretrendszerként tekintenek rá és nem folyamatok és jó gyakorlatok összességeként. A DevOps alapja a megfelelő eszközök és technológiák beillesztése, de a siker az emberek és folyamatok közös kultúraváltozásán múlik.
Hasonló a helyzet, mint a dokumentum terjesztés fejlődésével: kódexmásolás, kézi szedésű nyomdagép, elektronikus szerkesztés és egy okos fénymásoló az irodád mellett.
| Nyomda | IT | IT jellemzők | |
| Low | Kódexmásoló | Manuális műveletek | Magas félelemszint, egy hibának óriási hatása lehet, Leállás órákra, negyedéves kiadás, minden egyszerre |
| Medium | Kéziszedésű nyomda | Scriptek | Havonta, kéthetente, Leállás negyedórákra, részenként telepítés |
| High | Elektronikus szerkesztés | Automata konfigurációk | Heti-napi kiadás, leállás percekre vagy nincs kimaradás, automatikus teszt, részenként telepítés |
| Elite | Okosfénymásoló | Egygombos telepítés | Nincs félelem, a hibát azonnal lehet javítani, Folyamatos a kiadás, nincs leállás, a teljes rendszert bármikor és bármilyen példányszában újra lehet automatikusan telepíteni |
Óriásit fejlődött, hogy milyen hatékonyan tudunk információt terjeszteni és megosztani, de az IT-ban ez nem 500 év alatt történt, hanem 10 év alatt. Ez valójában azt jelenti, mintha egyszerre lennének a piacon a kódexmásolók, kézi nyomdászok és a digitális másolók. Ez jelenti a problémát a piacon.
Az informatika bonyolult lett, de a DevOps-ot jól használó cégek, nem csak a partvonalról nézték a krízist, hanem jó ritmusban tudtak új üzleti ajánlatokat kitalálni, és piacra dobni is. Az alacsony szinten lévő cégeknek viszont más tipusú problémák jöttek elő: túlórák, napokig kimaradás, versenyképességi hátrány, irrelevánssá váló termékek, stb.
Ha egy vezető abban gondolkodik, hogy lemaradóként szeretne gyorsítani az IT szállítási képességén, az helyes döntés, de azzal tud hibát elkövetni, hogy elitista megoldásokat próbál meghonosítani a lemaradó szervezetében. Okosfénymásolót visz a kódexmásolóknak: az emberek megijednek, frusztrálttá válnak és gyakran elhagyják az adott céget. Tudatosan, pontosan kell definiálni, hol járunk, mert ahhoz képest kell megtenni a következő lépést.
A ShiwaForce-ban több éve csiszoljuk a saját gyakorlatunkat ebben, gyakran kérnek tőlünk ügyfelek is támogatást abban, hogy a lemaradóból a következő szintre tudjanak lépni.
Ha valaki megszólítva érzi magát, az még tud csatlakozni a szakértőink által szervezett (ingyenes) 8 részes Devops webinárium sorozatunkhoz, amit nem csak IT-soknak, de technológiához vonzódó üzleti vezetőknek is ajánlunk.
