- SLI > SLO > SLA: az SLI a mért valóság, az SLO a belső cél, az SLA a vállalt (lazább) szint — mindig ebben a szigorúsági sorrendben.
- 99,9% ≈ 43 perc kiesés/hó; minden további 9-es ~tizedeli a megengedett kiesést, és többszörözi a költséget.
- Error budget = 100% − SLO: amíg van, lehet kockáztatni; ha elfogy, deploy-stop és stabilizálás.
- Burn-rate riasztás a nyers küszöb helyett — az üzleti hatással arányos, kevesebb vakriasztás.
- Három pillér: a metrika jelzi, HOGY baj van; a log és a trace, hogy MIÉRT (Prometheus · Loki · OpenTelemetry).
01A lényeg 30 másodpercben
A jó monitoring három dolgot tesz: (1) a felhasználói élményt méri (nem csak a CPU-t), (2) célt tűz rá (SLO), és (3) a riasztást az error budget fogyásához köti (burn-rate), nem a nyers metrika küszöbéhez. Így kevesebb a vakriasztás, és ami szól, az tényleg számít.
Ne a nyers metrika küszöbét figyeld, hanem a felhasználói élményt — a riasztást pedig kösd az error budget fogyásához. Ami éjjel felver, az legyen tényleg fontos.
- SLI = a mért valóság (pl. siker-arány).
- SLO = a belső cél (pl. 99,9%).
- SLA = az ügyfélnek vállalt, szerződéses szint (lazább, mint az SLO).
02SLI vs SLO vs SLA
A három fogalom egymásra épül — a leggyakoribb hiba, hogy összekeverik őket:
| Fogalom | Mi ez | Példa |
|---|---|---|
| SLI (Indicator) | A tényleges, mért mutató | Sikeres kérések aránya: 99,95% |
| SLO (Objective) | A belső cél a mutatóra | „99,9% kérés < 300 ms" |
| SLA (Agreement) | Szerződéses ígéret, következménnyel | „99,5% havonta, különben jóváírás" |
Aranyszabály: SLI > SLO > SLA szigorúságban — a vállalt SLA legyen lazább, mint a belső SLO, hogy legyen mozgástered, mielőtt az ügyfél felé hibáznál.
03A „9-esek" percben — mit ígérsz valójában
A rendelkezésre állás %-a megtévesztő — a megengedett kiesés havi percekben mond többet. Minden további 9-es nagyságrendileg tizedeli a megengedett kiesést:
04Error budget — a hiba is költségvetés
Az error budget az SLO komplementere: ha az SLO 99,9%, a megengedett hiba 0,1% — ez a „költségvetésed" a hibákra (pl. havi 43 perc kiesés). A logika:
- Amíg van budget: lehet kockáztatni — új kiadás, kísérlet, gyorsabb szállítás.
- Ha fogy a budget: lassíts — stabilizálás, alaposabb tesztelés.
- Ha elfogyott: deploy-stop, amíg vissza nem áll a megbízhatóság.
Az error budget feloldja a fejlesztés (gyorsaság) és az üzemeltetés (stabilitás) örök vitáját: nem nulla hibát céloz (ami végtelenül drága), hanem épp annyit, amennyi az üzletnek még elfogadható — és számszerű döntési szabályt ad.
05Burn-rate riasztás — a zaj helyett a hatás
A klasszikus küszöb-riasztás (pl. „CPU > 90%") sok vakriasztást ad, és éjjel felver olyasmiért, ami nem számít. A burn-rate ehelyett azt méri, milyen gyorsan fogy az error budget — és csak akkor szól, ha a fogyás üteme veszélyezteti a periódust:
Ha minden metrikára külön küszöb-riasztás szól, a riasztási fáradtság miatt a valóban fontos jelet elnyeli a zaj, és éjjel felver olyasmiért, ami nem számít. A burn-rate az error budget fogyásához köti a riasztást, így az üzleti hatással arányos.
06A megfigyelhetőség három pillére
Az observability három, egymást kiegészítő adattípuson áll — a metrika megmondja, HOGY baj van, a log és a trace azt, MIÉRT:
| Pillér | Mit ad | Tipikus eszköz |
|---|---|---|
| Metrikák | Numerikus idősorok (kérés/mp, hibaarány, válaszidő) | Prometheus |
| Logok | Esemény-rekordok szöveges kontextussal | Loki, ELK |
| Trace-ek | Egy kérés útja a szolgáltatásokon át | Tempo, Jaeger, OpenTelemetry |
A kulcs a korreláció: egy felületen (pl. Grafana) a riasztástól a metrikán, logon és trace-en át a gyökérokig gyors az út. A 24/7 NOC szolgáltatásunk pont ezt a stacket üzemelteti, SLO-alapú riasztással.
07SLO beállítása a gyakorlatban
- Kritikus felhasználói utak: válaszd ki a fontos folyamatokat (bejelentkezés, fizetés, keresés) — ne mindent mérj.
- SLI definíció: mindegyikre egy mutató (siker-arány, válaszidő-percentilis, pl. p95 < 300 ms).
- Mérés: néhány hét tényleges adat — a baseline.
- SLO kitűzés: a baseline-nál kicsit szigorúbb, de tartható cél (ne 100%).
- Error budget + burn-rate riasztás rákötése.
- Negyedéves felülvizsgálat — az SLO élő dokumentum.
Ne 100%-ot célozz — az végtelenül drága és felesleges. Mérd néhány hétig a tényleges teljesítményt, és a baseline-nál épp csak szigorúbb, de tartható SLO-t tűzz ki; a célt negyedévente vizsgáld felül.
A vállalt SLA mindig lazább, mint a belső SLO — és kapcsolódik a DR-célokhoz (RTO/RPO) és a megfelelőséghez (a DORA és NIS2 is monitoringot és incidens-folyamatot vár).
08Gyakori hibák
- 100% célzása: végtelenül drága és felesleges; az error budget épp azt mondja meg, mennyi hiba elfogadható.
- Küszöb-riasztás-özön: minden metrikára riasztás → riasztási fáradtság, a fontosat elnyeli a zaj. Burn-rate kell.
- Infrastruktúra-metrika ≠ élmény: a CPU lehet zöld, miközben a felhasználó hibát kap. A felhasználói SLI a mérvadó.
- SLA = SLO: ha a vállalt SLA ugyanaz, mint a belső cél, nincs mozgástér — az SLA legyen lazább.
- Csak metrika, log/trace nélkül: tudod, hogy baj van, de nem tudod, miért — a három pillér együtt kell.
09GYIK
Mi a sorrend: SLI, SLO vagy SLA jön először?
Mérési oldalról az SLI (a valóság), abból tűzöd az SLO-t (a célod), és az SLA (a vállalás) legyen lazább, mint az SLO. Bevezetéskor a kritikus felhasználói úttól indulj, arra definiálj SLI-t, mérj, majd SLO-t tűzz.
Mennyi 9-es kell nekem?
Amennyit az üzlet megkövetel és megfizet. A legtöbb belső rendszernek 99,9% (havi ~43 perc kiesés) elég; a 99,99% (havi ~4 perc) már komoly redundanciát, automatizálást és 24/7 ügyeletet igényel. Ne a 9-esek számát maximalizáld, hanem az üzleti igényhez illeszd.
Mi a különbség a monitoring és az observability között?
A monitoring az ismert kérdésekre figyel (előre definiált metrikák, dashboardok). Az observability tágabb: a rendszer kimenetéből (metrika+log+trace) ismeretlen kérdésekre is választ tudsz adni — „miért lassú ez a konkrét kérés?". A modern gyakorlat a kettő ötvözete, SLO-alapon.
Kell ehhez drága eszköz?
Nem feltétlenül. A Prometheus + Grafana + Loki + OpenTelemetry nyílt forráskódú, éles-érett stack, amely SLO-t, error budgetet és burn-rate riasztást is tud. A költség inkább a helyes beállításban és az üzemeltetésben van — ezt egy managed NOC leveszi a válladról.
Mi a különbség az SLI, SLO és SLA között?
Az SLI (Service Level Indicator) a tényleges, mért mutató — pl. a sikeres kérések aránya vagy a válaszidő. Az SLO (Service Level Objective) a belső cél, amit erre a mutatóra kitűzöl — pl. „a kérések 99,9%-a 300 ms alatt”. Az SLA (Service Level Agreement) a szerződésben rögzített, ügyfél felé vállalt szint, jellemzően következménnyel (pl. jóváírás), ha nem teljesül. Sorrend: az SLI a valóság, az SLO a célod (általában szigorúbb az SLA-nál), az SLA a jogi ígéret. Először az SLI-t mérd, abból tűzz SLO-t, és az SLA legyen lazább, mint az SLO — így van mozgástered.
Mit jelent a 99,9% rendelkezésre állás percekben?
A megengedett kiesés havonta: 99% ≈ 7,2 óra/hó, 99,9% (három 9-es) ≈ 43 perc/hó, 99,95% ≈ 22 perc/hó, 99,99% (négy 9-es) ≈ 4,3 perc/hó. Minden további 9-es nagyságrendileg tizedére csökkenti a megengedett kiesést — és többszörösére a költséget (redundancia, automatizálás, ügyelet). Ezért a 9-esek számát az üzleti igényhez kell szabni: a legtöbb belső rendszernek a 99,9% bőven elég, a négy 9-es már komoly mérnöki és pénzügyi elkötelezettség.
Mi az az error budget?
Az error budget (hibakeret) az SLO komplementere: ha az SLO 99,9%, akkor a megengedett hiba 0,1% — ez a „költségvetésed” a hibákra egy adott időszakra (pl. havi 43 perc kiesés). Amíg van budget, lehet kockáztatni (új kiadás, kísérlet); ha elfogy, fékezni kell (deploy-stop, stabilizálás). Az error budget oldja fel a fejlesztés (gyorsaság) és az üzemeltetés (stabilitás) közötti feszültséget: nem nulla hibát céloz, hanem épp annyit, amennyi az üzletnek még elfogadható.
Mi a burn-rate riasztás?
A burn-rate (égési ráta) azt méri, milyen gyorsan fogyasztod az error budgetet. A klasszikus küszöb-riasztás (pl. „CPU > 90%”) sok zajt és vakriasztást ad; a burn-rate riasztás ehelyett arra figyel, hogy a hibák olyan ütemben fogynak-e, ami a budgetet a periódus vége előtt kimerítené. Gyakorlatban több ablakot kombinálnak: gyors égés (pl. 1 óra alatt a havi budget ~2%-át elégeti, ez ~14-szeres égési ütem) → azonnali, lapozós riasztás; lassú égés (több óra/nap) → tiketet generál. Így a riasztás az üzleti hatással arányos, nem a nyers metrikával.
Mi a megfigyelhetőség (observability) három pillére?
A három pillér: metrikák (numerikus idősorok — pl. kérés/mp, hibaarány, válaszidő; eszköz: Prometheus), logok (esemény-rekordok szöveges kontextussal; eszköz: Loki, ELK), és trace-ek (egy kérés útja a szolgáltatásokon át, elosztott rendszerben; eszköz: Tempo, Jaeger, OpenTelemetry). A metrika megmondja, HOGY baj van; a log és a trace azt, MIÉRT. Egy jó observability-stack mindhármat korrelálja egy felületen (pl. Grafana), hogy a riasztástól a gyökérokig gyors legyen az út.
Hogyan állítsak be reális SLO-t?
Indulj a felhasználói élményből, ne a technikából: válaszd ki a kritikus felhasználói utakat (pl. bejelentkezés, fizetés), és azokra definiálj SLI-t (siker-arány, válaszidő). Mérd néhány hétig a tényleges teljesítményt, és abból tűzz olyan SLO-t, ami kicsit szigorúbb a jelenleginél, de tartható. Ne célozz 100%-ot — az végtelenül drága és felesleges. Az SLO-hoz rendelj error budgetet és burn-rate riasztást, és negyedévente vizsgáld felül. A vállalt SLA mindig legyen lazább, mint a belső SLO.
10Konzultáció
Ha túl sok a vakriasztás, vagy nincs SLO-d és error budgeted, egy felmérés rendet tesz. Egy 30 perces ingyenes konzultáció után kijelöljük a kritikus felhasználói utakat, SLI/SLO-javaslatot és burn-rate riasztási tervet adunk — működő Prometheus/Grafana/Loki stacken.
A kivitelezést és a 24/7 ügyeletet a Monitoring & NOC és az IT Infrastruktúra szolgáltatásaink keretrendszerével adjuk — banki éles tapasztalatból, MTTA < 5 perc / MTTR < 30 perc vállalással.
Belső IT vs. kiszervezett NOC · RTO és RPO — DR-tervezés · DORA megfelelőség