A cél az, hogy tudj meg arról, hogy a rendszered nem működik megfelelően, mielőtt a felhasználóid szólnának róla. A jó observability lehetővé teszi, hogy olyan kérdésekre válaszolj, amelyekre nem számítottál, nem csak egy rögzített készlet dashboard-ot ellenőrzöl. Tech leadként ezt az incidens előtt állítod fel, nem pedig alatt.
Az alerteket arra alapozd, amit a felhasználó érez, nem az belső rezgésekre. Helyezd az alerteket az SLO-k köré: error rate, latency (p95/p99), és availability. A CPU-csúcs nem incidens; az, hogy a vásárlás 2% felhasználónál meghiúsul, az igen.
| Erre figyelmeztetni | Erre ne figyelmeztetni |
|---|---|
| Error rate SLO megsértése | Egy CPU-csúcs |
| p99 latency költségvetésen felül | Egy lassú request |
| Meghiúsult health checks | Lemez 60%-on |
Minden alert sürgős, valós és cselekvésre alkalmas legyen — a nevén nevezze meg, hogy mi történt, és mutasson a következő lépésre. Az állandóan aktiválódó alertek betanítják a csapatot, hogy figyelmen kívül hagyjuk azokat; az alert fatigue az, ahogy a valódi incidensek elmaradnak. Adj hozzá health checkeket és dashboard-okat, amelyek a golden signalok első pillantásra láthatóak.
Azok a csapatok, amelyek csak az incidens után figyelnek, vakrepülésben vannak: az kimaradásokról dühös ügyfelektől tudnak meg, és találgatásokkal debugolnak. Az observability kezdettől fogva történő befektetése az 3 órai rejtélyeket 5 perces diagnosztikává alakítja, csökkenti a leállási időt, és felszabadítja a csapatot, hogy szállítson ahelyett, hogy tüzeket oltana.