Hogyan tud egy cég gyorsan kiadni digitális termékeket anélkül, hogy elveszítené a szolgáltatásminőség feletti ellenőrzést?
A válasz a csapatok munkamódszerében bekövetkező változással kezdődik. A DevOps a közös tulajdonjog, az automatizálás és a gyors visszajelzés révén köti össze a fejlesztést és az üzemeltetést. Az ITIL 5 szélesebb keretet ad a digitális termékek és szolgáltatások teljes életcikluson keresztüli kezeléséhez.
Az ITIL 5 erősebb fókuszát helyezi a digitális termék- és szolgáltatásmenedzsmentre. Egy rendszerbe kapcsolja össze a termékfejlesztést, a szállítást, az üzemeltetést, a támogatást, a felügyeletet és a folyamatos fejlesztést. A DevOps biztosítja azt a munkahabituusokat és technikai folyamatot, amely ezt a rendszert működteti.
Az eredmény egy tisztább út az ötlettől a megbízható felhasználói élményig.
Az átadás problémája
Sok vállalat még mindig különálló szakaszokra osztja a munkát. A termékcsapatok meghatározzák az igényeket. A fejlesztők megírják a kódot. Az üzemeltetés fenntartja a rendszerek futtatását. A támogatás kezeli a felhasználói problémákat.
Minden szerepnek van érvényes célja. A probléma akkor kezdődik, amikor a munka egyik csoporttól a másikhoz kerül megosztott mércék vagy megosztott kontextus nélkül.
Egy termékcsapat kérhet egy új funkciót. A fejlesztés leadhatja azt a specifikáció szerint. Az üzemeltetés azonban utólag rájöhet, hogy a funkció terhelést vagy támogatási kockázatot okoz. A felhasználók a végeredményt egyetlen szolgáltatásként élik meg, de a cég több, egymástól elszakadt feladatként kezeli azt.
Ez késéseket és újrakezdéseket eredményez. Eltünteti továbbá a technikai munka és üzleti érték közötti kapcsolatot is.
A DevOps csökkenti ezt a rést, mivel a fejlesztést és az üzemeltetést ugyanazon szállítási folyamatba vonja be. Az ITIL 5 ehhez a folyamathoz menedzsment-struktúrát ad. Így a termékcsapatok csatlakozhatnak ugyanahhoz a rendszerhez ahelyett, hogy a munkát egy külön technikai sorban helyeznének el.
A kulcskérdés megváltozik: „Befejezte-e a csapat a feladatát?” helyett most az a kérdés: „Javult-e a szolgáltatás a felhasználó számára?”
Egy értéklánc az ötlettől a szolgáltatásig
Az értéklánc leírja, hogyan halad a munka egy szükségletből hasznos eredménnyé. Digitális működésben ez az út tartalmazhat felfedezést, tervezést, építést, tesztelést, kibocsátást, támogatást és fejlesztést.
A DevOps ezeket a lépéseket automatizációval köti össze. Egy folyamatos integrációs csatorna ellenőrzi a kódot annak módosulása során. Az automatizált tesztek korán megtalálják a hibákat. A biztonsági ellenőrzések ugyanabban a munkafolyamatban futnak. A szállítóeszközök az elfogadott módosításokat vezetik a kontrollált környezeteken keresztül.
Ez nem szünteti meg a felügyeletet. A felügyeletet a folyamatba helyezi át.
Egy kibocsátás kaphat jóváhagyást kockázat, szolgáltatási hatás vagy tesztelési bizonyítékok alapján. Egy alacsony kockázatú változás átmehet egy egyszerű automatizált úton. Egy magas kockázatú változás mélyebb felülvizsgálatot igényelhet. A szabály világos, mert a szállítási rendszer rögzíti a döntést.
Az ITIL 5 segít meghatározni ennek a folyamatnak a célját. Vezető elvei a munkát az értékre összpontosítják. A felügyelet határokat szab. Az értéklánc összeköti azokat a tevékenységeket, amelyek létrehozzák, szállítják és támogatják a digitális szolgáltatásokat. A folyamatos fejlesztés pedig az üzemeltetési visszajelzéseket alakítja az következő módosítások sorozatává.
Ez a struktúra fontos az AI-alapú termékek esetében. Egy új ajánlási modell, keresési funkció vagy automatizálási szabály megváltoztathatja a felhasználói viselkedést és a rendszerterhelést. A kibocsátási folyamatnak egyszerre kell figyelembe vennie a teljesítményt, a biztonságot, a megbízhatóságot és a felhasználói élményt.
A megbízhatóság részévé válik a termékfejlesztésnek
A megbízhatóság gyakran az üzemeltetés feladata. Ez gyenge visszacsatolási hurkot hoz létre. A fejlesztők csak akkor látják a incidenseket, miután a jelentéseket megírták. A termékcsapatok csak késleltetett üzleti áttekintéseken keresztül vehetik észre a szolgáltatási problémákat.
A Site Reliability Engineering (SRE) ezt a mintát úgy változtatja meg, hogy a megbízhatóságot mérhetővé teszi. Egy szolgáltatás használhat célokat az elérhetőségre, a keresési sebességre, a lejátszási sikerrelésre vagy az ajánlások frissességére. Ezeket a célokat szolgáltatásszintű céloknak (Service Level Objectives, SLO-k) nevezzük.
Egy SLO egy általános aggodalmat működő jelzéssé alakít. A csapatok megkérdezhetik, hogy a szolgáltatás megfelel-e egy meghatározott felhasználói igénynek. Összehasonlíthatják továbbá a szállítási sebességet a szolgáltatási kockázattal is.
A hibaköltségvetés támogatja ezt a döntést. Egy hibaköltségvetés azt a mennyiséget jelöli, amennyi megbízhatatlanságot egy SLO megenged. Amikor a szolgáltatás a célján belül teljesít, a csapatnak van tere a módosítások kibocsátására. Amikor a hibák kimerítik ezt az engedményt, a stabilitási munkának elsőbbsége van.
Ez megosztott nyelvet teremt a termék, az informatika és az üzemeltetés között. A termékdöntések tartalmazzák a szolgáltatási hatást. Az informatikai döntések tartalmazzák a rezilienciát. Az üzemeltetési adatok formálják a jövőbeli tervezést.
Az observabilitás (megfigyelhetőség) megerősíti a hurkot. A naplók, metrikák, nyomkövetések és felhasználói élményjelzések azt mutatják, ami történik a kibocsátás után. Ezek a jelek lassú kéréseket, sikertelen tranzakciókat, rossz modellasztásokat vagy olyan problémákat tárhatnak fel, amelyek csak egy ügyfélcsoportra korlátozódnak.
Az automatizáció ezután támogathatja a biztonságos cselekvést. Egy rendszer bővítheti az erőforrásokat, forgalmat irányíthat át, letilthat egy funkciókapcsolót, vagy visszavonhat egy kibocsátást. Ezekhez a cselekvésekhez világos szabályok és tesztelés szükséges. A határok nélküli automatizáció gyorsabban terjeszthet egy hibát.
A cél a kontrollált tanulás. Minden kibocsátás bizonyítékot szolgáltat arról, hogyan viselkedik a szolgáltatás valós körülmények között. Ez a bizonyíték táplálja a következő termék- és informatikai döntést.
Egy kis példa
Vegyük egy zenei szolgáltatást, amely új ajánlási modellt vezet be.
A termékcsapat jobb felfedezést szeretne. A mérnökök megépítik a modellt és előkészítik a kibocsátást. Az üzemeltetés azonosítja a számítási erőforrásokat és a monitorozást, amelyek a futtatáshoz kellenek.
Egy elszakított folyamatban a modell minden felhasználónál egyszerre indulhat el. A problémák ekkor támogatási jegyekben vagy egy hirtelen teljesítményesésben jelennek meg.
Egy integrált folyamatban a modell először egy termelés-szerű környezetben fut. Az automatizált ellenőrzések felülvizsgálják a kódját, a biztonságát, a késését és az erőforráshasználatát. Egy funkciókapcsoló korlátozott csoportnak adja ki. Az observabilitás követi az ajánlások frissességét, a kérések sebességét, a hibarátaikat és a szolgáltatás elérhetőségét.
A csapat egy válasziutat is definiál. Ha a modell lassú kéréseket vagy rossz szolgáltatási jeleket okoz, a kapcsoló kikapcsol vagy a kibocsátás visszavonásra kerül. A meglévő szolgáltatás továbbra is működik.
Az ITIL 5 biztosítja a menedzsment keretet. A változás egy termékcelt támogat. A felügyelet kibocsátási kontrollokat szab. Az üzemeltetés támogatja a élő szolgáltatást. A folyamatos fejlesztés az eredményeket használja az következő változás formálásához.
A DevOps biztosítja a szállítási mechanikákat. A csatorna, a tesztek, a funkciókapcsoló, a monitorozás és a visszavonás összeköti a munkát.
Nincs egyetlen csapat, amely egyedül birtokolná az egész kimenetelet. A rendszer teszi ezt.
Mit változtat meg ez a minta?
A DevOps és az ITIL 5 konvergenciája nem azt jelenti, hogy minden folyamat automatizálttá válik. Azt jelenti, hogy a csapatok a munkát egyetlen összefüggő értékláncként kezelik.
Ez számos mindennapi szokást megváltoztat:
- A termékcsapatok belefoglalják a megbízhatósági és támogatási igényeket a tervezésbe.
- A fejlesztők a termelési jeleket dizájn-bemenetként kezelik.
- Az üzemeltetés korábban csatlakozik, mielőtt a kibocsátási döntések véglegesülnének.
- A felügyelet a kockázatot és a bizonyítékot használja alapértelmezett helyett, nem pedig a lassú jóváhagyást.
- A támogatási adatok eljut azokhoz a csapatokhoz, amelyek építik és kezelik a szolgáltatást.
- A fejlesztési munka követi az élő rendszer viselkedését.
A minta egyben feltárja a gyenge pontokat is. Egy csatornát folyamatosnak nevezhetnek még akkor is, ha manuális átadások állítják meg minden kibocsátást. Egy monitorozási irányítópult megjelenítheti az infrastruktúra egészségét, de hiányozhat a felhasználói élmény. Egy incidensfolyamat helyreállíthatja a szolgáltatást anélkül, hogy megoldaná a kudarcot okozó dizájndöntést.
Egy hasznos teszt egyszerű: kövessünk vissza egy változást az eredeti szükségletétől a termelési kimenetelig. Jegyezzük fel, hol áll meg az információ áramlása. Ez a pont gyakran mutatja meg, ahol a termék, a DevOps és a szolgáltatásmenedzsment jobbra integrációt igényel.
A gyakorlati tanulság az, hogy válasszunk ki egy átadást és kössük össze megosztott bizonyítékkal. Egy termékkövetelmény tartalmazhat egy SLO-t. Egy kibocsátási csatorna tartalmazhat egy támogatási ellenőrzést. Egy incidens-áttekintés létrehozhat egy termék backlog elemet egyértelmű tulajdonossal.
Ez a kis kapcsolat láthatóvá teszi az értékláncot. Ugyanakkor közös helyet ad a csapatoknak a tanuláshoz.
Az EuroOp LLC ezt magasan alkalmazott K+F mintának tekinti: a megbízható digitális termékek akkor jönnek létre, amikor az építés, az üzemeltetés és a fejlesztés egy visszajelzési rendszerben történik. Az EuroOp Insights minden számában ezt a ugyanazt ígéretet viszi tovább: egy alkalmazott K+F minta és egy gyakorlati tanulság az EuroOp termékei mögötti csatornából.