Az IT-csapatok többsége tudja, mikor áll le a szerver. Azt már kevesebben látják, hogy a felhasználó mit tapasztal a képernyőjén. Pedig a dashboard sokszor akkor is zöldet mutat, amikor a felhasználó által tapasztalt valóság más. Ez a cikk arról szól, hogyan változtatja meg ezt az observability.
Miért monitorozunk?
A legtöbb IT-csapat azt mondja: azért monitoroz, hogy értesüljön, ha valami megáll. Ez érthető, de nem elég. A monitoring valódi célja nem a rendelkezésre állás mérése. A cél az, hogy a felhasználók megfelelő minőségű szolgáltatást kapjanak. A rendelkezésre állás csak egy proxy – fontos, de nem azonos a végcéllal. Ha ezt a szemléletet vesszük alapul, azonnal más kérdések kerülnek előtérbe: megfelelő-e a válaszidő, hol telik el az idő a kiszolgálási láncban, és a felhasználók hány százaléka kap hibátlan választ.
Az uptime-csapda
A rendelkezésre állási mutatók – a „kilences” SLA-számok – látszólagos biztonságot adnak. 99,9% rendelkezésre állás meggyőzően hangzik. De mit nem mér?
Nem méri, hogy a válaszidő elfogadható-e. Nem méri, hogy a mobilalkalmazás összeomlik-e bizonyos eszközökön. Nem méri, hogy egy adott internetszolgáltató hálózatán keresztül csatlakozó felhasználók lassabb kiszolgálást kapnak-e, mint akik más hálózatról érnek el.
A szerver „működik”, de a felhasználó élménye ettől még lehet elfogadhatatlan. Ez az uptime-csapda: a mérőszám zöld, miközben a valóság más képet mutat.
„Nálunk minden zöld” – a felhasználók mégis panaszkodnak
Az informatika sokszor a call centertől értesül arról, hogy valami nem működik megfelelően. Mire a helpdesk jelez, a felhasználók már percek vagy órák óta tapasztalják a problémát.
A hagyományos monitoring eszközök a saját rendszerhatáron belül mérnek. Azt jelzik, ha egy szerver nem válaszol, de azt nem látják, hogy a felhasználó mit tapasztal a képernyőjén. Egy mobilalkalmazás adott eszközökön rendszeresen összeomolhat anélkül, hogy egyetlen riasztás is keletkezne. Egy adott mobilszolgáltató hálózatáról érkező felhasználók lassabb kiszolgálást kaphatnak, mint mások, miközben szerver oldalon minden mutató normálisnak látszik.
Az observability a teljes kiszolgálási láncot teszi láthatóvá: a felhasználó kérésétől egészen addig, ahogy a válasz megjelenik a képernyőjén. Ez az a látótér, ami alapján az IT-csapat ténylegesen a felhasználó szemével lát.
Az ESZFK esete – amikor a felhasználói élmény tétje nagyon magas
Az ESZFK az EESZT-t és az EgészségAblak alkalmazást fejleszti és üzemelteti. A rendszeren naponta átlagosan 950 000 e-recept fordul meg – december elején ez elérheti az 1,3 milliót is, hónap elején jellemzően 20 százalékos forgalmi felfutással.
Egy lassulás ebben a környezetben nem elvont teljesítménymutatók romlása: a patikus tovább vár a receptre, a beteg tovább áll a pult előtt. A rendszer „működik”, de a következmény a felhasználónál jelentkezik.
Az observability ebben a környezetben stratégiai eszköz. A csapat látja, ha egy új release után több crash jelentkezik a mobilalkalmazásban, még mielőtt bárki panaszt tett volna. Látja, hogy egy adatbázis-upgrade valóban javított-e a válaszidőkön. És látja, ha egy adott mobilszolgáltató hálózatáról lassabb kiszolgálást kapnak a felhasználók, akkor is, ha szerver oldalon minden rendben van.
Mit ad az observability a szervezetnek?
Az observability három területen hoz érdemi változást. Láthatóvá teszi a felhasználói élmény valódi állapotát – nem csak azt, hogy a szerver válaszolt-e. Megmutatja, hol keletkezik a probléma, mielőtt a helpdesk jelezne. És közös képet ad az érintett csapatoknak, ami gyorsabb, hatékonyabb hibaelhárítást tesz lehetővé.
A felhasználói élmény valódi állapotának ismerete azt jelenti, hogy az IT-csapat nem a szerver belső mutatóit figyeli, hanem azt, amit a felhasználó ténylegesen tapasztal: válaszidőket, alkalmazáshibákat, kiszolgálási minőséget. Ez alapvető különbség: egy rendszer lehet belülről „egészséges”, miközben a felhasználó élménye elfogadhatatlan.
A proaktív hibafelismerés azt teszi lehetővé, hogy a csapat ne utólag reagáljon. Egy adatbázis-lekérdezés lassulása, egy mobilalkalmazás növekvő hibaaránya, egy forgalmi csúcs előtt kialakuló teljesítménycsökkenés – mind észlelhető még azelőtt, hogy a felhasználó érezné. Ez az az időablak, amiben beavatkozni lehet.
A közös adatkép incidens esetén azt jelenti, hogy az érintett csapatok ugyanazt látják: a teljes kiszolgálási láncot, valós időben. A diagnózis gyors, a felelősség egyértelmű, a hibaelhárítás fókuszált. Az IT kevesebb időt tölt tűzoltással, és többet fordíthat arra, hogy a rendszer valóban jól működjön a felhasználó szemszögéből.
Observability – a felhasználó szemével
A felhasználók számára egyetlen dolog számít: a szolgáltatás megfelelően működjön. A monitoring eszközök azonban elsősorban a rendszerek állapotát mérték. A felhasználó tényleges élményére sokáig nem volt rálátás.
Az observability nem új célt ad az IT-nek, hanem visszavezet az eredeti célhoz. Láthatóvá teszi azt, amit eddig csak sejteni lehetett: mit tapasztal a felhasználó a képernyőjén, hol vész el az idő a kiszolgálási láncban, és hol érdemes beavatkozni.
Ez a szemléletváltás nem csak technikai kérdés. Megváltoztatja, hogy mit mér az IT-csapat, hogyan kommunikál a fejlesztőkkel, és hogyan tud az üzemeltetés a vezetőség felé is értelmes képet adni a rendszer valódi állapotáról.
Ha van egy közös mérce – a felhasználói élmény –, akkor egyszerre válik egyértelműbbé a prioritás, gyorsabbá a hibaelhárítás, és értelmesebbé a fejlesztés.
Erről a témáról részletesebben is szó esett a VISZcast legújabb epizódjában, ahol Mester Sándor Kiss-Lajos Zoltánnal, az ESZFK ágazati rendszerek igazgatójával és Darabos Tamással beszélgetett. Itt meghallgatható:
Forrás:
Kiss-Lajos Zoltán, az ESZFK Nonprofit Kft. ágazati rendszerek igazgatója – VISZcast podcast, 2. epizód (Telvice × VISZ megfigyelési sorozat)
