Miért kritikus az observability a belső rendszerekben

A belső rendszerekben azért kritikus az observability, mert a teljesítményproblémák ritkán jelennek meg hibaként. Sok szervezetben a belső alkalmazásokat másképp kezelik, mint az ügyfelek által használt rendszereket. Kevesebb felhasználójuk van, kevésbé vannak szem előtt, és üzleti szempontból ritkán tekintik őket kritikusnak. Emiatt a teljesítményt fejlesztés közben gyakran nem kezelik prioritásként. Amíg a rendszer működik, és a felhasználók el tudják végezni a feladataikat, az általános állapot elfogadhatónak számít.

Ebből a szempontból az observability nem a hibák észleléséről szól. Arról szól, hogy akkor is értsük a rendszer működését, amikor semmi sem romlott el látható módon. Ez a különbség azért számít, mert a belső rendszerekben a teljesítményproblémák ritkán jelennek meg hibaként vagy riasztásként. Ehelyett alkalmi lassulásként vagy akadozásként jelentkeznek, és semmi sem jelzi egyértelműen, hogy valami nincs rendben.

A probléma az, hogy idővel ez a lassú működés válik az új normává.

Fejlesztés közben:

• a teljesítményt nem veszik kifejezetten figyelembe
• a valós használati helyzeteket nem tesztelik
• a szélsőséges eseteket nem ellenőrzik valós felhasználói folyamatokkal

Ekkor ezt még senki sem tekinti problémának. A funkció működik, a logika helyes, és a rendszer kezeli a várt eseteket.

Amint azonban a rendszert valós körülmények között használják, a komplexitás nő.

• A munkafolyamatok hosszabbak lesznek.
• Az adatmennyiség nő.
• Az üzleti logika bővül.

És ekkor kezdenek felhalmozódni a hatékonysági problémák.

Ez a folyamat tipikusan kiszámítható mintát követ.

A rendszer kezdetben gyors, amikor az adatmennyiség kicsi és a munkafolyamatok egyszerűek. A további funkciók több komplexitást hoznak, a végrehajtási utak hosszabbak lesznek.

Idővel a kis hatékonysági hiányok összeadódnak. Végül ez a lassabb működés válik az elfogadott kiindulási szintté.

A belső rendszerek egyik legnagyobb különbsége a felhasználói viselkedés. Amikor egy backoffice vagy belső alkalmazás lelassul:

• a felhasználók alkalmazkodnak
• normálisnak feltételezik
• abbahagyják a problémák jelentését

Még ha jeleznek is egy problémát, gyakran nehéz érdemben foglalkozni vele. Rendszerszempontból nincs egyértelmű hiba:

• nincsenek hibák
• nincsenek összeomlások
• nincsenek látható riasztások

A rendszer csak lassú.

Mivel nincs egyértelmű jel, a vizsgálat nehézkes, vagy egyszerűen hátrébb kerül a prioritási listán.

Ezt nevezhetjük jelzési szakadéknak.

Műszaki szempontból semmi sem jelzi egyértelműen, hogy valami nincs rendben. A felhasználó szempontjából viszont a rendszer következetesen lassú. Mivel ez a két nézet nincs összekötve, a probléma láthatatlan marad. Az üzemeltetési dashboardok alapján a rendszer egészségesnek tűnik. Közben egyre több hatékonysági probléma halmozódik fel benne, és nincs olyan jel, amely vizsgálatot indítana.

Sok esetben a kiváltó ok nem az infrastruktúra. Az infrastruktúra-metrikák gyakran elfogadhatónak tűnnek:

• nincs magas CPU-használat
• nincs nyilvánvaló adatbázis-túlterhelés
• nincs nagy rendszerszintű szűk keresztmetszet

A valódi probléma jellemzően az alkalmazás- vagy szolgáltatásrétegben található.

Ezek a hatékonysági hiányok ritkán léteznek elszigetelten. Hajlamosak a kérés végrehajtási útja mentén összeadódni.

Egyetlen felhasználói művelet gyakran szinkron műveletek láncát indítja el több szolgáltatáson keresztül. Minden lépés késleltetést tesz hozzá, így még a kis hatékonysági hiányok is érezhető késéssé adódnak össze. Ezt gyakran késleltetés-halmozódásnak nevezik.

Emellett sok belső rendszer olyan mintákra támaszkodik, amelyek felerősítik ezt a hatást:

• ismételt hívások ciklusokon belül
• túl sok apró üzenetváltás a szolgáltatások között
• szükségtelen szerializáció és adattranszformáció

Mindez növeli egyetlen kérés költségét.

Ezek a mechanizmusok nem okoznak hibát. Egyszerűen megnövelik egy munkafolyamat végrehajtási idejét, gyakran úgy, hogy ez kérésszintű elemzés nélkül nem is derül ki.

Gyakori a nem hatékony feldolgozási logika, például az ismételt API-hívások vagy a szükségtelen adatbázis-lekérdezések. Az N+1 minta tipikus példa, de csak egy tágabb problémakör egyik megjelenése.

Ezeknek a hatékonysági hiányoknak sajátos jellemzőjük van: helyesen működnek, de rosszul skálázódnak.

A nehézséget nemcsak maga a hatékonysági probléma okozza, hanem az is, hogy körülötte hiányzik az observability. Sok belső rendszerben:

• nincs felhasználóiélmény-monitoring
• a kérésszintű láthatóság korlátozott
• a teljesítményviselkedést nem mérik végfelhasználói szemszögből

Emiatt nem lehet egyértelműen összekapcsolni a felhasználói viselkedést és a rendszer működését. Nem nyilvánvaló, hol telik el valójában az idő.

Teljesítményproblémák vizsgálatakor a csapatok jellemzően a szerverek, az adatbázisok és a skálázási viselkedés ellenőrzésével kezdik. Ha ezek a metrikák elfogadhatónak tűnnek, a következtetés gyakran az, hogy alapvetően nincs semmi baj.

Így előáll az a helyzet, hogy a rendszer objektíven lassú, de infrastruktúraszinten nincs rá egyértelmű magyarázat. A valóságban a probléma gyakran máshol van.

Ezért a csapatok olyan megoldások felé fordulnak, amelyek logikusnak tűnnek, de nem a kiváltó okot kezelik. Az infrastruktúrát skálázzák, a CPU- vagy memóriakiosztást növelik, vagy az adatbázis teljesítményét hangolják. Ezek a változtatások átmenetileg csökkenthetik a késleltetést, de nem szüntetik meg az alkalmazásréteg hatékonysági hiányait.

Más esetekben csak felszíni javításokat végeznek. Új felületet vezetnek be, vagy kliensoldali optimalizációt alkalmaznak, miközben ugyanazok a backend folyamatok változatlanok maradnak. Így a rendszer általános viselkedése alapvetően nem javul.

A gyorsítótárazást is gyakran vezetik be gyors javításként. Bizonyos helyzetekben hatékony lehet, gyakran azonban csak elrejti a teljesítményproblémákat, ahelyett, hogy megoldaná őket, különösen akkor, ha a kérésminták és az adatáramlás alapos megértése nélkül alkalmazzák.

Ezekben közös, hogy a probléma tüneteit kezelik, nem az okát. Ha nem látható, hogyan futnak le a kérések a rendszerben, a javítások hatása korlátozott és átmeneti marad.

Az elemzés az infrastruktúra-metrikák helyett az egyes kérésekre és felhasználói műveletekre irányul. Egy lassú API-hívás belépési pont a teljes végrehajtási út megértéséhez, és megmutatja, hol telik el valójában az idő a szolgáltatások, az adatbázis-műveletek és a belső logika között.

Ez közvetlen kapcsolatot teremt a felhasználói élmény és a rendszer viselkedése között. A késleltetés többé nem absztrakt metrika, hanem követhető lépéssor, ahol a hatékonysági hiányok a válaszidő látható és mérhető összetevőivé válnak.

Ezzel a láthatósággal a javítások nem feltevésekre épülnek. A csapatok megtalálhatják és kezelhetik a késés valódi forrásait, ahelyett, hogy felszíni optimalizálással csak elfednék a problémát.

Idővel ez azt is megváltoztatja, hogyan épülnek a rendszerek. A teljesítmény a visszacsatolás részévé válik, amelyet folyamatosan figyelnek és értenek, ahelyett, hogy csak akkor foglalkoznának vele, amikor élesben problémát okoz.

Amint az elemzés eléri a szolgáltatásréteget, ugyanazok a problémák jelennek meg újra és újra. Ezek nem feltétlenül összetett rendszerhibák, hanem felhalmozott hatékonysági hiányok:

• ismételt hívások ciklusokon belül
• szükségtelen adatbetöltés
• a kötegelés hiánya
• szinkron végrehajtás ott, ahol nincs rá szükség

Ezek a problémák gyakran egyszerűen azért kerülnek be fejlesztés közben, mert akkor nem vették figyelembe a teljesítményt.

Az alapvető probléma abban gyökerezik, hogyan tervezték és építették ezeket a rendszereket.

Ha a teljesítmény nem része a fejlesztési döntéseknek, a hatékonysági hiányok maguktól bekerülnek.

Ez ritkán derül ki, mert a rendszereket elsősorban a helyes működésre tesztelik, nem a valós használatra.

Így a problémák fejlesztés közben rejtve maradnak, és csak akkor válnak láthatóvá, amikor a rendszereket valós körülmények között használják. Addigra már a mindennapi munkafolyamatok részei, és lényegesen nehezebb elkülöníteni őket.

A gyakorlatban ezeknek a problémáknak jó részét viszonylag egyszerű módszerekkel sokkal korábban meg lehetne találni.

A tesztelésnek nemcsak a helyes működést kell ellenőriznie, hanem a valós használati körülményeket is tükröznie kell. Ide tartozik a reális adatmennyiséggel végzett tesztelés, a teljes felhasználói munkafolyamatok lefuttatása, és a végponttól végpontig tartó válaszidők mérése az elszigetelt komponensek helyett.

Fontos azt is megfigyelni, hogyan viselkednek a rendszerek kevésbé gyakori, de még érvényes körülmények között. A szélső esetek, a hosszabb munkafolyamatok és az ismételt műveletek gyakran olyan hatékonysági hiányokat tárnak fel, amelyek a szokásos tesztesetekben rejtve maradnak.

Még az egyszerű mérések is adhatnak korai jeleket, például a kulcsfelhasználói műveletek vagy az API-kérések időtartamának követése tesztelés közben. Ezek a jelek nem feltétlenül hibát jeleznek, de kiemelik azokat a területeket, ahol a teljesítmény a komplexitás növekedésével romlik.

Ilyen visszacsatolás nélkül a hatékonysági hiányok csak sokkal később derülnek ki, amikor már beépültek a valós munkafolyamatokba, és nehezebb elkülöníteni őket.

Bár a belső rendszereket nem az ügyfelek használják, a hatásuk jelentős. A lassú rendszerek a következőkhöz vezetnek:

• hosszabb feladat-végrehajtási időkhöz
• kisebb hatékonysághoz a napi működésben
• nagyobb kognitív terheléshez a munkatársakon
• frusztrációhoz a backoffice és frontoffice csapatokban

Egyes esetekben a hatás közvetlenül látható az ügyfelek számára. Fizikai helyszínen, például ügyfélszolgálaton vagy kiskereskedelmi fiókban a lassú belső rendszerek lassabb és bonyolultabb ügyfélinterakciót eredményeznek.

Ez a szolgáltatásminőséget és az ügyfélélményt is érinti.

Idővel a munkatársak is azokat a rendszereket részesítik előnyben, amelyek gyorsabbak és megbízhatóbbak. A lassú rendszerek nemcsak a folyamatokban okoznak súrlódást, hanem a munkahelyi elégedettséget is rontják.

Ezekre a problémákra gyakori válasz egy új központi rendszer bevezetése, amelytől a teljesítményproblémák megoldását várják.

• Sok esetben azonban a mögöttes architektúra ugyanaz marad.
• A meglévő backend szolgáltatásokat újrahasználják.
• Ugyanaz a nem hatékony logika a helyén marad.
• Az observability továbbra is ott hiányzik, ahol számít.

Így az új rendszer ugyanazt a viselkedést örökli. A felület változhat, a teljesítményjellemzők viszont megmaradnak. Ha a mögöttes rétegeket nem kezelik, és nincs megfelelő observability, a probléma nem tűnik el.

A belső rendszerek ugyanolyan szemléletet igényelnek, mint a külsők, különösen a teljesítmény és az observability terén. Ha a teljesítményt fejlesztés közben nem veszik figyelembe, hatékonysági hiányok kerülnek be. Ha az observability hiányzik, ezek a hiányok rejtve maradnak. Ez a két tényező együtt olyan rendszereket hoz létre, amelyek lassúak, nehezen elemezhetők és nehezen javíthatók.

A legfontosabb nem az, hogy ezek a rendszerek lelassulnak, hanem az, hogy úgy lassulnak le, hogy senki nem érti tisztán, miért.

Observability nélkül és teljesítménytudatos fejlesztési döntések nélkül a hatékonysági hiányok csendben halmozódnak. Idővel a lassú működés a rendszer természetes részévé válik, ahelyett, hogy megkérdőjeleznék vagy kijavítanák.

Ezen a ponton a probléma már nemcsak műszaki. Azt érinti, hogyan dolgoznak az emberek, hogyan bíznak a rendszerekben, és mennyire nehéz változást bevezetni.

Amit korán kisebb hatékonysági hiányok sorozataként lehetett volna azonosítani, az szerkezeti korláttá válik, amelyet később sokkal nehezebb kezelni.

És addigra a rendszer javítása már nem optimalizálás kérdése, hanem évek láthatatlan komplexitásának kibogozása.