Miért kell az observability-nek a rendszerrel együtt változnia

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

Sok fejlesztési környezetben az observability-t 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 éppen szükségesnek látszik. 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 úgy tűnik, semmi sem hiányzik. 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 látszanak azonnal, de bizonyos körülmények között kritikussá válnak.

Fejlesztés közben a döntések a rendszer aktuális helyzete 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 pillanatban é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. Egy konkrét szolgáltatás viszont 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 is 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. Rendszerszinten a romlás általánosnak látszik, nem egy helyhez köthetőnek. 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, amelyekből a rendszer működését értelmezik.

Ha a vizsgálat a valódi forrás láthatósága nélkül indul, kerülő úton halad. 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 mutatkozik 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ő az üzemeltetési költség és a kockázat, 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 observability-jük viszont változatlan marad. Egy másik gyakori eset az, 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 az, hogyan állítják fel a prioritásokat. Az observability-t 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ő eszköznek tekintik, nem pedig olyan tényezőnek, amely meghatározza, hogy a rendszer működése élesben megérthető-e. Ha az observability-t 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 a lefedetlen részek vakfoltokká válnak.

Ha az observability-t 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. Fejlesztés közben meghatározzuk, hogyan lesz megfigyelhető egy komponens, amint élesbe kerül. A gyakorlatban 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 nem finomítások, hanem 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 legfontosabb változás elvben egyszerű, a gyakorlatban nehéz. Az observability-t 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 observability-jét ugyanazon a szinten kell figyelembe venni, mint a funkcionalitását és a teljesítményjellemzőit. Nemcsak azt kell meghatározni, mit csinál egy szolgáltatás, hanem azt is, hogyan lesz megfigyelhető élesben. 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. Az is következik belőle, hogy az observability-nek 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 observability-jüknek követnie kell. Ez nem egyszeri erőfeszítés, hanem folyamatos munka, amely követi a rendszer változásait.

A fejlesztőcsapatok számára az observability a szolgáltatás szokásos definíciójának része. Jellemzően ez a következőt jelenti:

• az observability benne van az elfogadási feltételekben
• a szolgáltatás tervezésekor figyelembe veszik, hogyan mérik és elemzik majd a viselkedését
• a meglévő komponenseket újraértékelik, amikor a szerepük a rendszerben megváltozik
• az observability-t kiterjesztik, amikor a szolgáltatások kritikus folyamatok részévé válnak

Felül kell vizsgálni a rendszer azon részeit is, amelyeket más feltételezések mellett valósítottak meg. Azokat a komponenseket, amelyeket valaha nem tekintettek kritikusnak, 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. Ilyenkor a helyreállítás sebességét és a döntések 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. Ha ez megtörténik, a rendszer nem mindenhol hibásodik meg.

Az observability hiánya nem látható hibákban mutatkozik meg. Abban mutatkozik meg, hogy már nem értjük, mi történik a rendszer belsejében.

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