KTLO: Jelentése és használata szoftverfejleszési projektekben

Egy IT termék bevezetése csak a kezdet, hiszen folyamatosan biztosítani kell a stabilitását és a fejlesztését is. Éppen ezért komoly szervezetek nem lehetnek meg KTLO (Keep The Lights On, azaz Hagyd Égve A Villanyt) nélkül.

De hát mi az a KTLO, miért fontos a KTLO a projektmenedzsmentben, és miért kell a fejlesztőknek, valamint a cégtulajdonosoknak tudniuk róla? A NIX szakértői ebben a cikkben összeszedtek mindent, amit tudnod kell erről a témáról.

Mi az a KTLO?

A KTLO jelentése magában foglal minden olyan folyamatot, amely biztosítja a szoftverrendszerek állandó stabilitását és megbízhatóságát a nap huszonnégy órájában, valamint infrastruktúrájuk rendszeres karbantartását.

Bár a KTLO nem nyújt új funkciókat a termékhez, az IT csapatok feladatainak lényeges részét képezi. Ez a munka azonban időigényes lehet, ami potenciálisan lelassíthatja az innovációt, és a fejlesztők kiégéséhez vezethet a sok rutinfeladat miatt.

Mi tartozik a KTLO alá?

A Keep The Lights On tevékenységek igen változatosak. Egyrészt ezek a karbantartási intézkedések a reaktív feladatokat – az incidensekre való reagálást – fedik le. 

Másrészt vannak proaktív feladatok, amelyek a problémák megelőzésére, és a fejlesztők munkaterhelésének csökkentésére összpontosítanak.

Jellemzően a KTLO a projektmenedzsmentben az alábbiakat foglalja magába:

• Infrastruktúra támogatás: Az alapszintű infrastruktúra, a szerverek, a hálózat, az operációs rendszer, az adatbázisok karbantartása. Ezeket felügyelni, frissíteni és biztosítani kell.
• Biztonsági mentések készítése: A projekteknek rendelkezniük kell eszközökkel az adatmentéshez, és az informatikai erőforrások telepítéséhez, hogy a rendszer növelhető legyen.
• Rendszerfelügyelet: A teljesítményproblémákat, anomáliákat és meghibásodásokat nyomon kell követni, riasztásokat kell beállítani, és valós idejű incidensekre kell reagálni.
• Hibajavítás: Minden szoftverben vannak hibák. Ezeket azonosítani és javítani kell, hogy a lehető legkisebb legyen a leállási idő.
• Standard frissítések: Ezek a fejlesztések magukban foglalják a biztonsági javítások telepítését, és a partner API-változásokhoz való alkalmazkodást a stabil működés fenntartása érdekében.
• Előírások betartásának biztosítása: Minden szervezetnek frissítenie kell a termékét, hogy megfeleljen a biztonsági szabványoknak, a vállalati irányelveknek, és a szabályozási követelményeknek.

Ha jobban meg akarjuk érteni, hogy mi az a KTLO, nem szabad megfeledkeznünk a reaktivitás és a proaktivitás közötti egyensúly fontosságáról.

Egyetlen rendszer sem eseménymentes, de nem lehet mindig csak reagálni a problémákra. A megelőzés kevesebbe kerül, mint a következmények kezelése, nem is beszélve az ügyfélelégedettségről, és a csapat moráljáról a válsághelyzetekben.

A KTLO jelentése a szoftverfejlesztésben

Bár a KTLO jelentése a mindennapi üzemeltetési feladatok összességének tűnhet, mégis igényli a szoftverfejlesztők részvételét. Ez nem csak a kisvállalkozásokra, projektekre, vagy a speciális szerepkörökkel nem rendelkező startupokra igaz. 

A modern rendszerek, különösen a mikroszolgáltatás-alapúak, egyre összetettebbek. Az incidenskockázatuk növekszik, miközben a megszakítás nélküli szolgáltatásra vonatkozó követelmények egyre szigorúbbak. Mindez mély termékismeretet igényel.

A KTLO szoftverek esetében a fejlesztők bevonása az alábbi előnyökkel jár:

• Jobb rendszerismeret: Az üzemeltetési munkatársakkal ellentétben a fejlesztők ismerik a termékarchitektúra árnyalatait és korlátait, mélyebben értik az üzleti logikát, és több száz kódfüggőséget is felfognak. Egyes feladatok ilyen ismeretek nélkül lehetetlenek.
• Hatékonyabb hibajavítás: A rendszer összetettsége miatt egyes hibákat nehéz vagy időigényes a támogatási szinten kezelni. Strukturális kódmódosításokra lehet szükség az incidensek megismétlődésének megelőzése és a stabilitás biztosítása érdekében.
• Technikai adósság megoldása: A technikai adósság az iteratív szoftverfejlesztés velejárója, de gyakran elhanyagolják. A proaktív KTLO lehetővé teszi a problémás kód- vagy adatbázis-struktúra módosítások kezelésére szánt integrációs időt.
• DevOps integráció: Ez a módszertan elmossa a határokat a fejlesztés, és a támogatás között. A KTLO-val az együttműködés olyan szintet ér el, amely jobban fenntartja a termék stabilitását, mivel a fejlesztők részt vesznek a CI/CD folyamatok létrehozásában, a monitorozás optimalizálásában és az automatikussá tételében.
• Új funkciók fejlesztése: A KTLO a projektmenedzsmentben strukturális változásokat ad a fejlesztési folyamathoz, segítve a szoftverek alapvető újításainak gyorsabb megvalósítását. Például a fejlesztési infrastruktúra hosszú távon javulhat, és rendszeres refaktorálásra kerülhet sor.

Fontos tipp: az egész csapatnak értenie kell, hogy mi az a KTLO. Csak így tudja egy szervezet hatékonyan elosztani a szerepeket, felelősségeket és erőforrásokat. 

Például a technikai támogatás kezeli a kezdeti incidensek feldolgozását, és a felhasználói interakciókat. 

Az üzemeltetési csapatok a karbantartási és támogatási intézkedésekre, az infrastruktúra rendelkezésre állására, és a tipikus problémák megoldására összpontosítanak. 

A fejlesztők az alapvető kódmódosításokat igénylő feladatokat, az innovációk és az automatizálás bevezetését, valamint a technikai adósságok kezelését végzik. 

A projektmenedzserek pedig felügyelik a folyamatokat, hogy minden a tervek szerint haladjon. Ha van affinitásod a sokféle feladat kezeléséhez, és szívesen lennél te is projektmenedzser, nézz körül az állásajánlataink között: PM álláslehetőségek.

A KTLO jelentése a projektmenedzsmentben

Ezen a ponton felmerül a kérdés, hogy rendben, a karbantartási feladatokra szükség van, és a fejlesztők foglalkoznak velük. De tényleg szükség van a KTLO elkülönítésére? A válasz igen, ez elengedhetetlen. 

A KTLO a projektmenedzsmentben segít a PM-nek:

• Átlátni a csapat terhelését: A KTLO feladatokra bontása segít láthatóvá tenni, hogy a rutinfeladatok mennyi időt emésztenek fel. Például az olyan globális IT-cégek, mint a Google, problémásnak tartják, ha a stabilitás karbantartása a fejlesztők idejének több mint 50%-át veszi igénybe, ami azt jelzi, hogy szükség van a szervezeti átszervezésre.
• Megtervezni az erőforrások felhasználását: Ha a KTLO feladatok emésztik fel a fejlesztők legtöbb energiáját, az indokolttá teheti egy külön csapat létrehozását. Ez különösen fontos az aktív növekedést tapasztaló, nagy terhelésű rendszerek esetében, például a stabil működési szintet elért startupoknál.
• Meghatározni a prioritásokat: A KTLO koncepció segít a vállalatoknak jobban megérteni az egyes tevékenységek értékét. Egyes rendszerkarbantartási feladatok kritikusak és nem halaszthatók, míg mások várhatnak a fontosabb új funkciók mögött.
• Fejleszteni a folyamatokat: A KTLO megértése nélkül ezek a feladatok gyakran láthatatlan problémává válnak. Ha a projektmenedzser tisztán látja ezt a munkaterhelést, akkor elkezd többet gondolkodni az automatizálási eszközökről, az adósságcsökkentésről, az architektúra felülvizsgálatáról, és a csapatok folyamatos fejlesztéséről.
• Felosztani a feladatokat: A KTLO munka könnyen „senki munkájává” válhat. A fejlesztők átadják az üzemeltetésnek, akik továbbadják a technikai támogatásnak, és fordítva. A rendszer stabilitásának fenntartása azonban egyértelmű felelősségkiosztást igényel, és szükség esetén a DevOps és SRE mérnökök szerepkörének hozzáadását a KTLO csapatokhoz.
• Kezelni az üzleti elvárásokat: A vezetők és az ügyfelek talán nem értik, miért tart olyan sokáig az iteratív funkciófejlesztés. A KTLO segítségével a PM konkrét adatokkal rendelkezik majd, amelyek megmutatják, hogy hova mennek az erőfeszítések, és bizonyítják, hogy miért kell az erőforrásokat refaktorálásra és architektúra-optimalizálásra fordítani.

Mikor van szükség külön KTLO csapatra

Néha jobb, ha nem vonjuk el a fejlesztők figyelmét az alapvető feladatokról, és a Keep The Lights On tevékenységeket inkább az erre szakosodott csapatokra bízzuk. Ezt a döntést azonban gondosan mérlegelni kell szervezeti és pénzügyi szempontból. 

Akkor indokolt, ha:

• A fejlesztők túlterheltek: A rendszerkarbantartásra összpontosító szakemberek erőforrásokat szabadítanak fel a termékfejlesztésre és az innovációra. Hosszú távon a szervezet kompenzálja a külön csapat költségeit.
• A rendszer stabilitása kulcsfontosságú: Egyes területeken a megbízhatóság közvetlenül befolyásolja az üzleti nyereségességet, például az e-kereskedelemben és a pénzügyekben. Egy külön rendszerkarbantartásra létrehozott csapat minimalizálhatja a problémamegoldási időt, és az állásidőt.
• Szigorúak az SLA (Service Level Agreements) követelmények: A szolgáltatási szint megállapodások kritikusak bizonyos üzleti irányok esetében. Például, ha egy terméknek 99,9%-os rendelkezésre állási időre van szüksége. Egy KTLO feladatokra dedikált csapat jobban tudja kezelni ezeket a kockázatokat.
• A rendszer bővül: Amikor több millió felhasználó használja a szoftvert, a karbantartása összetettebbé válik, és az infrastruktúra több incidenssel szembesül. Ilyen esetekben a KTLO feladatok elegendőek ahhoz, hogy indokolttá váljon egy dedikált csapat létrehozása.

De még ha ezek a tényezők jelen vannak is, fontos, hogy pénzügyileg is igazolt legyen a stabil működés fenntartására szakosodott csapat fenntartása.

A ROI (Return on Investment) segíthet az érték bizonyításában. A ROI-számítás egy külön téma, amely a projektmenedzsment könyvekben jelentős figyelmet kap. 

Egyelőre maradjunk az alapoknál: 

1. Tegyük fel, hogy ki kell számolnod, hogy a KTLO tevékenységekre fordított fejlesztői csapat erőforrásai mennyibe kerülnek egy adott időszakban. 
2. Ezután határozd meg az ugyanezen időszak alatt a leállásokból származó üzleti veszteségeket.
3. Vetítsd előre a KTLO csapat méretét és költségvetését. Általában ezek a szakemberek kevesebbe kerülnek, mint a csúcsfejlesztők.
4. Ideális esetben adj hozzá számításokat a potenciális előnyökre – hiszen így az innovációk gyorsabban tudnak megjelenni.

Hogyan előzheted meg a külön KTLO csapattal járó problémákat

Ha a projektvezetők formálisan közelítik meg a rendszerkarbantartást, akkor bizonyos problémákkal szembesülhetnek. 

Egyrészt ezek a szakemberek, mint például az üzemeltetés vagy a műszaki támogatás, nem biztos, hogy mély termékismeretre tesznek szert. 

Másrészt fennáll a kiégés és a fókuszvesztés veszélye. Ahhoz, hogy az ilyen csapatok értékesek legyenek, a szoftverfejlesztést megfelelően kell strukturálni:

• Szervezd meg az együttműködést: A KTLO szakembereket be kell vonni az olyan tevékenységekbe, mint a kódellenőrzések. Ez segít nekik jobban megérteni, hogy az új funkciók hogyan hatnak a termékre. A gyors konzultációkhoz kommunikációs eszközökre is szükség van. Összetett esetekben a fejlesztőknek segíteniük kell a kódmódosításokban.
• Vezess be rotációt: Ez egy jó szabály a stabil működés fenntartásához még dedikált csapat nélkül is. A fejlesztők és a KTLO szakemberek közötti rendszeres rotáció javítja a tudásmegosztást és csökkenti az ismétlődő feladatokból eredő fáradtságot.
• Tarts fenn minőségi dokumentációt: A tudásátadás minden projekt esetében fontos. A KTLO rendszerkarbantartó csapatok esetében azonban különösen fontossá válik az architektúra leírása, a kódbázissal, és az infrastruktúrával való munka elvei, és a tipikus problémák kezelése. Az újonnan érkezők számára ezek az információk felbecsülhetetlen értékűek.

Rendszerkarbantartás – a “Keep the lights on” tevékenységek folyamata 8 lépésben

1. Helyzetelemzés: A KTLO-tevékenységek hatókörének és a csapatokra gyakorolt hatásuknak a megértése. Értékeld az olyan feladatok számát, mint a hibajavítások, frissítések, és a felügyelet egy adott időszak alatt. Ez segít azonosítani a problémákat – azokat a területeket, amelyekre az IT-csapat a legtöbb időt fordítja.
2. Strukturálás: Oszd fel a feladatokat reaktív (incidensekre való reagálás), proaktív (refaktorálás, optimalizálás és automatizálás, amelyek segítenek elkerülni a potenciális problémákat), és rendszeres infrastruktúra- és rendszerkarbantartásra. A KTLO a projektmenedzsmentben leegyszerűsíti a tervezést.
3. Tervezés: Számítsd ki az erőforrásokat. Amikor a rendszerkarbantartás számos feladatot foglal magában, egy dedikált csapatra van szükség. Ha a stabilitás fenntartása az idő 20-30%-át veszi igénybe, a vállalat megszervezheti a fejlesztők rotációját. Emellett KPI-ok is szükségesek, például az üzemidő javítása, vagy az incidensek csökkentése.
4. Folyamatok beállítása: Alapvető forgatókönyvekre van szükség az incidensfeldolgozási algoritmusokkal és szerepekkel. Például, hogy ki milyen adatokat felügyel, és hogyan reagáljon az alkalmazás hibáira. Azt is meg kell határozni, hogy az ilyen feladatokat hogyan jelölik a nyomkövetőkben. Ez kiszámíthatóbbá teszi a KTLO-t.
5. Automatizálás: A kevesebb kézi munka gyorsabb reagálást és jobb csapatelégedettséget jelent. A felügyeletet, a biztonsági mentést, és a szabványos frissítéseket lehet a legkönnyebben automatizálni. Fontold meg az öngyógyító rendszerek eszközeit az ismert hibák automatikus megoldására.
6. Technikai adósság csökkentése: E nélkül a stabil működés fenntartása nehézkes. Egyszerűsíti a rendszert és csökkenti az incidensek kockázatát. Hozz létre egy hátralékos feladatlistát, és határozz meg prioritásokat a hibás területeken. A rendszeres refaktorálás megszervezése is segít.
7. Tudástranszfer: Még egy dedikált csapat esetén sem szabad, hogy a KTLO-munka csak néhány emberen múljon. Képezz ki minél több fejlesztőt (különösen az újonnan érkezőket). Például tarts képzést a felügyeletről, és az incidensekre való reagálásról. Készíts és tarts fenn dokumentációt is.
8. Monitoring: Ne kezeld a KTLO-t a projektmenedzsmentben statikusnak. Az igazi informatikai vezetők keresik a folyamatos rendszerfejlesztés módjait. Ezt a célt segíti a KTLO hatékonyságának elemzése, a termék állapotának értékelése, valamint a csapatmegbeszélések.

Ezt a listát követve megvalósítható a KTLO szoftverek esetében. Ezt azonban adaptálhatod és bővítheted.

Az erőforrások időarányos felosztása például így nézhet ki: 

• 40% a rendszerkarbantartási és támogatási tevékenységekre, 
• 30% a hibajavításokra, 
• 20% a technikai adósságok megoldására, 
• és 10% az optimalizálásra.

Ezek az arányok azonban nagyban függnek a szoftverfejlesztési projekt egyedi igényeitől. Például az érett, ritkán innováló termékek jellemzően inkább a napi üzemeltetési feladatokra összpontosítanak. 

Ezzel szemben a fiatalabb temékek esetében gyakran a hibajavításra, és a technikai adósságok megoldására kell helyezni a hangsúlyt. 

Ezért kulcsfontosságú a konkrét üzleti környezet elemzése, beleértve az értékteremtési ajánlatot, az igényeket, és a tipikus rendszerteljesítmény-kihívásokat. Ha többet szeretnél tudni ennek a munkának az árnyalatairól és előnyeiről, ez az ingyenes projektmenedzsment képzés neked való!

Összefoglaló a KTLO sikeres végrehajtásáról

A KTLO tevékenységek a szoftver életciklus-menedzsment szerves részét képezik, és elengedhetetlenek a stabil működés fenntartásához. Ezek biztosítják az innováció, és a folyamatos rendelkezésre állás közötti egyensúlyt, hogy a rutinfeladatok ne akadályozzák a fejlesztést. 

A gondos szervezés, az automatizálás, és a proaktív megközelítés csökkentik a problémák számát és azok üzleti hatását. Az ezekre való összpontosítás tehát segít a csapatodnak beosztani az erőforrásokat és hatékonyan megvalósítani a rendszerkarbantartást. 

Ez a titka a zavartalan működés biztosításának – legyen szó bármilyen szoftverről.