Öt nap alatt meg lehet érteni egy ismeretlen rendszert?

Amikor egy új rendszerrel kezdek foglalkozni, gyakran felmerül a kérdés:

Mit lehet erről egyáltalán megállapítani öt-tíz munkanap alatt?

A kérdés teljesen jogos. Egy összetett, évek óta működő rendszerbe sokszor hónapok vagy évek alatt épül be a tudás. Közben változnak az üzleti igények, cserélődnek a fejlesztők, új integrációk készülnek, és a rendszer olyan döntéseket is magán visz, amelyekre már senki nem emlékszik pontosan.

Egy rövid rendszerdiagnózis nem varázslat, és nem is egy teljes rendszerátvilágítás helyettesítője.

A célja más: rövid idő alatt használható, bizonyítékokon alapuló képet adni arról, hogy mi történik a rendszerben, hol vannak a legfontosabb kockázatok, és melyik következő lépésnek van valódi értelme.

Nem a kóddal kezdem

Az egyik leggyakoribb tévedés, hogy egy rendszerdiagnózis egyenlő a kód átnézésével.

A kód természetesen fontos. De önmagában nem mondja meg, hogy a rendszer mely részei okoznak valódi üzleti problémát.

Ezért az első beszélgetések során nem az a legfontosabb kérdés, hogy milyen frameworköt használtak, vagy hány sorból áll a kódbázis.

Inkább azt próbálom megérteni:

• mire használják a rendszert;
• kik támaszkodnak rá nap mint nap;
• mely folyamatok üzletkritikusak;
• mi romlott el vagy lassult le az utóbbi időben;
• milyen változtatásokat kerül a csapat;
• mely hibák térnek vissza rendszeresen;
• milyen döntés előtt áll most a vezetőség.

Volt olyan rendszer, amely technológiai szempontból első pillantásra nem tűnt különösebben modernnek, mégis stabilan kiszolgálta az üzletet.

Máskor egy korszerűnek látszó architektúrában találtunk olyan működési kockázatokat, amelyek sokkal fontosabbak voltak, mint bármelyik technológiai választás.

A diagnózis szempontjából az számít, hogy a rendszer hogyan viselkedik a valós használatban.

Az első napokban a történetet próbálom összerakni

Egy régi rendszernek általában nincs egyetlen története.

A fejlesztők mást látnak, mint az üzemeltetők. A vezetőség a szállítás lassulását érzékeli, az ügyfélszolgálat pedig ugyanennek a következményeit látja hibás adatok vagy elhúzódó ügyintézés formájában.

Az első napokban ezeket a nézőpontokat próbálom egymás mellé tenni.

Megnézem, hogyan érkezik be egy üzleti igény, hogyan jut el a fejlesztésig, hogyan kerül ki éles környezetbe, majd hogyan derül ki, ha valami nem működik megfelelően.

Ekkor gyakran előkerülnek olyan problémák, amelyek külön-külön nem tűnnek súlyosnak:

• egy kézi lépés a kiadási folyamatban;
• egy kevéssé dokumentált integráció;
• egy ritkán használt, de üzletileg fontos folyamat;
• egy olyan adatbázis-művelet, amely csak nagyobb terhelés mellett lassul le;
• egy riasztás, amely már olyan gyakran jelentkezik, hogy mindenki figyelmen kívül hagyja.

Ezekből áll össze a rendszer valós működése.

Mit vizsgálok meg egy rövid diagnózis során?

Nem minden rendszert lehet ugyanazzal a sablonnal megvizsgálni, de jellemzően öt területre figyelek.

1. A rendszer felépítése

Milyen fő komponensekből áll a rendszer? Hogyan kommunikálnak egymással? Hol vannak szoros függőségek? Mely részek változnak gyakran, és melyekhez évek óta nem nyúlt senki?

Nem az a cél, hogy minden osztályról és minden végpontról részletes dokumentáció készüljön. Azt kell megérteni, hol koncentrálódik a komplexitás és a változtatási kockázat.

2. A kritikus üzleti folyamatok

Egy technikai probléma súlyát nem a kódban elfoglalt helye határozza meg.

Egy apró komponens is lehet üzletileg kritikus, ha nélküle nem lehet számlázni, ügyfelet kiszolgálni vagy adatot továbbítani.

Ezért mindig megpróbálom összekötni a rendszer részeit az üzleti működéssel. Melyik hiba okoz kellemetlenséget, és melyik állítja le ténylegesen a vállalat működését?

3. A fejlesztés és a kiadás folyamata

Megnézem, hogyan jut el egy változtatás az ötlettől az éles rendszerig.

Hol kell várni? Mi történik automatikusan, és mit végeznek kézzel? Milyen tesztek futnak? Mennyire lehet biztonságosan visszavonni egy hibás kiadást?

Ezen a ponton sokszor már láthatóvá válik, hogy a lassulásnak van-e közvetlen technikai oka, vagy inkább a folyamatban van a probléma.

4. Az üzemeltetés és a megfigyelhetőség

Egy rendszer állapotáról nemcsak akkor kell tudni, amikor már hibázik.

Megnézem, milyen naplók, metrikák és riasztások állnak rendelkezésre, mennyire lehet visszakeresni egy incidens okát, és honnan derül ki, hogy a felhasználók valóban azt tapasztalják-e, amit a csapat feltételez.

Ha egy hiba csak ügyfélpanaszból válik láthatóvá, az önmagában fontos megállapítás.

5. A csapat tudása és működése

Egy rendszert nemcsak a kódja tart fenn. Legalább ennyire fontos, hogy ki érti, ki tudja megváltoztatni, és ki képes biztonságosan üzemeltetni.

Megnézem, mennyire koncentrálódik a tudás néhány embernél, mennyire követhetők a korábbi döntések, és milyen könnyű egy új fejlesztőnek bekapcsolódnia.

Ez nem személyek értékelése. A cél annak megértése, hogy a rendszer mennyire függ egyes emberek jelenlététől.

Mit ad át a diagnózis?

Egy jó diagnózis végén nem egy hosszú hibajegyzék marad.

A vezetőségnek és a csapatnak általában az alábbiakra van szüksége:

• rövid, közérthető összefoglaló;
• a legfontosabb technológiai és működési kockázatok;
• a kockázatok üzleti hatása;
• a problémák közötti függőségek;
• javasolt 30/60/90 napos következő lépések;
• becslés a szükséges ráfordításokról;
• annak megjelölése, mit nem érdemes most megváltoztatni.

Az utolsó pont sokszor különösen fontos.

Egy diagnózis nem attól értékes, hogy minél több problémát talál. Attól értékes, hogy segít megkülönböztetni a sürgős, a fontos és a jelenleg elhanyagolható kérdéseket.

Mit nem lehet megállapítani öt nap alatt?

Egy rövid diagnózisnak vannak világos korlátai.

Nem fog minden hibát megtalálni. Nem fog minden jövőbeli terhelési problémát pontosan megjósolni. Nem helyettesíti a hosszabb idejű üzemeltetési tapasztalatot, és nem adhat hamis bizonyosságot olyan kérdésekben, amelyekhez még hiányzik az adat.

A jó diagnózis ezeket a bizonytalanságokat is láthatóvá teszi.

Megmutatja, mit tudunk nagy biztonsággal, mit kell még ellenőrizni, és milyen kérdésekre érdemes a következő szakaszban választ keresni.

A cél nem a teljes rendszer megértése

Öt-tíz nap alatt nem kell a rendszer minden részletét megérteni.

Azt kell megérteni, hogy:

• mi tartja vissza jelenleg a fejlődést;
• mely kockázatok veszélyeztetik az üzleti működést;
• mely problémák oldhatók meg kis beavatkozással;
• mikor lenne indokolt nagyobb modernizáció;
• és mi legyen a következő felelős döntés.

Én ezért nem azzal kezdem a munkát, hogy mit kellene felépíteni.

Először azt próbálom megérteni, mi történik most, miért történik így, és mekkora változtatás szükséges ahhoz, hogy a rendszer újra megbízhatóbban támogassa az üzletet.

A rendszerdiagnózis nem a végső válasz minden technológiai kérdésre. De jó kiindulópont lehet ahhoz, hogy a következő döntés már ne feltételezésekre, hanem közös és bizonyítható képre épüljön.