Miért kell az observabilitynek a rendszerrel együtt változnia

Sok rendszerben az observability nem fejlődik a rendszerrel, pedig nem hiányzik teljesen. Egyszerűen hiányos. Ez fejlesztés közben ritkán derül ki, és élesben sem mindig azonnal.

Sok fejlesztési környezetben az observabilityt még mindig nem kezelik valódi fejlesztési követelményként. Olyasminek tekintik, amit a csapatok majd később adnak hozzá, vagy csak ott vezetnek be, ahol az adott pillanatban szükségesnek tűnik. A fejlesztési folyamat szempontjából ez gyakran működik. A funkciók elkészülnek, a szolgáltatások összekapcsolódnak, a rendszer a várt módon viselkedik. Ebben a szakaszban semmi nem tűnik hiányzónak. A probléma az, hogy a rendszerek nem maradnak az eredeti állapotukban. Folyamatosan változnak, és ha az observability nem változik velük, hiányosságok keletkeznek. Ezek nem válnak azonnal láthatóvá, de bizonyos körülmények között kritikussá válnak.

Fejlesztés közben a döntések a rendszer aktuális kontextusa alapján születnek. Egy szolgáltatást nem tartanak kritikusnak, ezért nem látják el mérőpontokkal. Egy örökölt komponens már létezik, ezért módosítás nélkül újrahasználják. Egy integráció egyszerűnek tűnik, ezért az observability nem kap prioritást. Ezek a döntések nem hibák. Az adott időben ésszerűek. A probléma az, hogy statikus rendszerkép alapján születnek, miközben maga a rendszer dinamikus. Idővel:

• új funkciók kezdenek meglévő szolgáltatásokra támaszkodni
• a korábban kis forgalmú komponensek több terhelést kapnak
• az integrációk olyan funkcionalitást aktiválnak, amelyet korábban ritkán használtak
• az üzleti logika olyan helyeken halmozódik, amelyeket nem erre terveztek

Ami egykor mellékes komponens volt, egy kritikus végrehajtási útvonal részévé válik. Az observability viszont pontosan ott marad, ahol eredetileg bevezették.

Egy gyakori helyzet jól szemlélteti ezt. Egy alkalmazás több backend szolgáltatásból áll. Az alapkomponensek már el vannak látva mérőpontokkal, így metrikák, naplók és trace-ek ott állnak rendelkezésre, ahol a csapatok a problémákra számítanak. Ugyanakkor egy konkrét szolgáltatás observability nélkül marad. Kezdetben ez nem okoz problémát, mert a szolgáltatás:

• korlátozott felelősséget lát el
• alacsony a használata
• nem teljesítményérzékeny

Emiatt az observability hozzáadása nem prioritás. Ahogy a rendszer változik, ez megváltozik. Új funkció jelenik meg, amely ettől a szolgáltatástól függ. A kérések mennyisége nő, és a szolgáltatás egy nagyobb végrehajtási folyamat része lesz. Fokozatosan mellékesből kritikussá válik. Az observability azonban továbbra is hiányzik.

A rendszer normálisan működik, amíg valami meg nem változik. Ez lehet új telepítés, viselkedésváltozás, vagy egyszerűen a szokásosnál magasabb terhelés. Ekkor kezdenek látszani a hatások. A válaszidők nőnek a rendszerben. Bizonyos műveletek érezhetően lelassulnak, és ott is időtúllépések jelentkeznek, ahol korábban minden problémamentesen működött. Rendszerszempontból a romlás általánosnak tűnik, nem lokalizáltnak. A csapatok abból indulnak ki, amit meg tudnak figyelni. Az API-késleltetést, a frontend viselkedését és a mérőpontokkal ellátott backend szolgáltatások teljesítményét vizsgálják. A dashboardok valódi problémákat mutatnak, de ezek csak egy rejtett hiba látható következményei. A probléma valódi forrása abban a szolgáltatásban van, amelyet soha nem láttak el mérőpontokkal. Mivel annak a komponensnek nincs metrikája, nem jelenik meg a trace-ekben, és nem ad értelmes naplót, vakfoltként viselkedik. Része a rendszernek, de hiányzik azokból az adatokból, amelyek alapján a rendszer működését értelmezik.

Amint a vizsgálat a valódi forrás láthatósága nélkül indul, a folyamat közvetetté válik. A csapatok nem a hibás komponenst elemzik, mert az egyetlen megfigyelhető folyamatban sem jelenik meg. Ehelyett a rendszer mérhető részeire figyelnek. Terhelés alatt álló szolgáltatásokat skáláznak, lassúnak tűnő komponenseket optimalizálnak, és kívülről próbálják stabilizálni a rendszert. Ezek a lépések hiányos információn alapulnak. Az eredmény nemcsak lassabb, hanem alapvetően kevésbé hatékony megoldás. A rendszer átmenetileg javul vagy részben stabilizálódik, de a mögöttes probléma megmarad. Amikor hasonló körülmények újra előállnak, ugyanaz a viselkedés visszatér. Itt jelenik meg a hiányzó observability valódi költsége. Nemcsak a hibaelhárításra fordított időben, hanem a javítás közben hozott döntések minőségében is.

A hiányzó observability hatása nem korlátozódik a lassabb műszaki elemzésre. Ha egy probléma forrása nem azonosítható tisztán:

• az incidensmegoldás tovább tart, és nő a szolgáltatásromlás időtartama
• a döntések hiányos információ alapján születnek, ami gyakran szükségtelen változtatáshoz vagy skálázáshoz vezet
• a problémák nagyobb eséllyel ismétlődnek, mert a kiváltó okot nem értik teljesen
• a rendszerbe vetett általános bizalom csökken, műszaki és üzleti szempontból is

Ezek a hatások összeadódnak. Idővel növelik az üzemeltetési költséget és a kockázatot is, még akkor is, ha a rendszer normál körülmények között stabilnak tűnik.

A legnagyobb kockázatot nem az új komponensek jelentik, hanem általában a rendszer azon részei, amelyeket soha nem vizsgáltak felül. Az örökölt vagy „elfelejtett” szolgáltatások különösen problémásak, mert nem a jelenlegi szerepükre tervezték őket. Más feltételezések mellett jöttek létre, gyakran anélkül, hogy nagy terhelésre, összetettségre vagy kritikus szerepre számítottak volna. Idővel ezek a szolgáltatások további felelősséget halmoznak. Új funkciók épülnek rájuk, az integrációk újrahasználják őket, a függőségek nőnek. Ahogy a szerepük tágul, a hatásuk nő, az observabilityjük viszont változatlan marad. Másik gyakori eset, amikor új integráció épül egy meglévő szolgáltatásra. A szolgáltatást változatlanul, mérőpontok hozzáadása nélkül használják újra. Kezdetben minden működik, mert a használat korlátozott. Később, ahogy az integráció fontosabbá válik, a terhelés nő, és ugyanaz a probléma jelentkezik. Amikor valami elromlik, pontosan ott romlik el, ahol hiányzik a láthatóság.

A kiváltó ok nem a műszaki összetettség, hanem a prioritások meghatározása. Az observabilityt gyakran nem kezelik formális fejlesztési követelményként, és nem kapja meg ugyanazt a súlyt, mint a funkcionalitás vagy a teljesítmény. Kiegészítő támogatásnak tekintik, nem pedig olyan tényezőnek, amely meghatározza, hogy a rendszer működése élesben megérthető-e. Ha az observabilityt fejlesztés közben nem írják elő kifejezetten, következetlenül vezetik be. Egyes szolgáltatásokba beépítik, mert kényelmes vagy kézenfekvő, másokba nem, mert nincs rá egyértelmű követelmény. Ez egyenetlen lefedettséghez vezet a rendszerben, és idővel ezek az egyenetlen területek vakfoltokká válnak.

Ha az observabilityt fejlesztési követelményként kezeljük, az nem azt jelenti, hogy később dashboardokat adunk hozzá, vagy idővel javítjuk a láthatóságot. Azt jelenti, hogy fejlesztés közben meghatározzuk, hogyan lesz egy komponens megfigyelhető, amint élesbe kerül. A gyakorlatban ez azt jelenti, hogy minden szolgáltatásnak tartalmaznia kell:

• strukturált és következetes naplózást, amely lehetővé teszi az értelmes elemzést
• alapvető metrikákat, amelyek a késleltetést, a hibaarányt és az áteresztést tükrözik
• nyomon követhetőséget az elosztott folyamatokban, hogy a kérések szolgáltatásokon át követhetők legyenek
• egyértelmű hibajelzéseket, amelyekkel a problémák megbízhatóan észlelhetők

Ezek az elemek nem finomítások. Részei annak, ami egy szolgáltatást teljessé tesz. Ha egy komponens nem figyelhető meg, üzemeltetési szempontból csak részben van megvalósítva.

A kulcsváltás elvben egyszerű, a gyakorlatban nehéz. Az observabilityt fejlesztés közben kell követelményként kezelni, nem később hozzáadandó javításként. Amikor egy szolgáltatást terveznek vagy módosítanak, az observabilityjét ugyanazon a szinten kell figyelembe venni, mint a funkcionalitását és a teljesítményjellemzőit. Ez azt jelenti, hogy amellett, hogy meghatározzuk, mit végez egy szolgáltatás, azt is világosan meg kell határozni, hogyan lesz élesben megfigyelhető. Ha egy komponens egy kritikus útvonal részévé válik, a viselkedésének mérhetőnek, követhetőnek és diagnosztizálhatónak kell lennie. Azt is jelenti, hogy az observabilitynek a rendszerrel együtt kell változnia. Ahogy a függőségek és a használati minták változnak, a korábban nem kritikus komponenseket újra kell értékelni. Ha a szerepük fontosabbá válik, az observabilityjüknek követnie kell. Ez nem egyszeri erőfeszítés, hanem folyamatos munka, amely ahhoz igazodik, ahogy maga a rendszer változik.

A fejlesztőcsapatok számára ez azt jelenti, hogy az observability a szolgáltatás szokásos definíciójának része. Ez tipikusan azt jelenti, hogy:

• az observability benne van az elfogadási feltételekben
• a szolgáltatástervezés figyelembe veszi, hogyan lesz a viselkedés mérve és elemezve
• a meglévő komponenseket újraértékelik, amikor a szerepük a rendszerben megváltozik
• az observabilityt kiterjesztik, amikor a szolgáltatások kritikus folyamatok részévé válnak

Azt is megköveteli, hogy felülvizsgálják a rendszer azon részeit, amelyeket más feltételezések mellett valósítottak meg. Azokat a komponenseket, amelyeket egyszer nem kritikusnak tekintettek, de azóta nélkülözhetetlenné váltak, observability szempontból is értékelni kell.

A hiányzó observability nem hoz létre azonnali hibákat. Olyan körülményeket teremt, amelyekben a hibákat nehéz megérteni.

A probléma csak akkor jelenik meg, amikor valami változik: amikor a terhelés nő, amikor a viselkedés eltolódik, vagy amikor hibát vezetnek be. Ekkor a rendszer observability nélküli része szab határt annak, milyen gyorsan és pontosan oldható meg a probléma. A rendszer megfigyelhetőnek tűnhet, a gyakorlatban azonban csak részben ismert a működése. És ezekben a helyzetekben a helyreállítás sebességét és a döntés minőségét a legkevésbé megfigyelhető komponens határozza meg, nem a legfejlettebb eszköz, amely a helyén van.

Az observability nemcsak javítja a rendszereket. Azt határozza meg, üzemeltethetők-e hatékonyan, amikor valami elromlik. Ha nem kezelik követelményként, pontosan ott fog hiányozni, ahol a leginkább számít. És amikor ez megtörténik, a rendszer nem mindenhol hibásodik meg.

Az observability hiánya nem látható hibákban mutatkozik meg. Hanem abban, hogy elveszíti a képességet annak megértésére, mi történik a rendszer belsejében.

Ott hibásodik meg, ahol nem lehet látni.