SLO-sablonok — kész célok és error budget

01A lényeg 30 másodpercben

Az SLO (Service Level Objective) egy mérhető szolgáltatási cél — de a legtöbb csapatnál azon bukik el, hogy túl bonyolult vagy soha nem készül el. Itt kész, egyoldalas sablonok vannak, amiket másolhatsz:

• Hat sor egy SLO: szolgáltatás · SLI · célérték · mérési ablak · error budget · riasztás.
• Error budget = 100% − cél, percben kifejezve (99,9% ≈ 43,8 perc/hó).
• Burn-rate riasztás a sima küszöb helyett — kevesebb téves riasztás.
• Kezdj kicsiben: 1–2 SLI a kritikus szolgáltatásra, a mért adatból.

Az elméleti hátteret (SLI/SLO/SLA, burn-rate) a Monitoring 101 adja; ez a cikk a kitölthető sablonokra fókuszál.

02Egy SLO felépítése — a hat sor

Egy működő SLO elfér egy oldalon. Ennél több ritkán kell a kezdéshez:

Kulcselv: az SLI legyen felhasználói szempontból fontos (amit az ügyfél tényleg érez), és mérhető azzal, amid van. Ne tucatnyi SLI legyen, hanem 1–2 jó.

Egy jó SLO elfér egy oldalon, hat sorban. A túl bonyolult sablont soha senki nem tartja karban; a kevés, de értelmes mutató nyer.

03Error budget — mennyi kiesés fér bele?

Az error budget a megengedett hiba: 100% − célérték, átlagos (≈30,4 napos) hónapra vetítve. Minden további „kilenc" nagyjából tizedére csökkenti a keretet — és sokszorozza a működési szigort és a költséget:

04Kész SLO-sablonok

Három tipikus szolgáltatás-típus, indikatív kiindulási SLO-kkal — másold, és a mért adatodból finomítsd:

Megjegyzés: a válaszidő-SLO általában lazább cél, mint a rendelkezésre állás — egy lassú kérés még nem kiesés. A batch-nél a sikerráta + határidő a jó SLI, nem a „uptime".

05Burn-rate riasztás — a sablon

A burn-rate azt méri, milyen gyorsan fogy az error budget. 1-es burn-rate = az ablak végére pont elfogy; 14-es = ~14-szer gyorsabban. A többablakos riasztás kevés téves riasztással fogja meg a fontos eseteket:

Ez az SRE-gyakorlat alapértelmezése: a „csengess minden hibára" helyett a gyorsan romló helyzetekre koncentrál. A részletes burn-rate-mechanikát a Monitoring 101 magyarázza; az üzemeltetési oldalt a Monitoring & NOC szolgáltatásunk fedi.

06Bevezetés lépésről lépésre

1. Válassz 1–2 SLI-t szolgáltatásonként (felhasználói szempontból fontosat).
2. Mérj néhány hétig — lásd a valós szintet, mielőtt célt tűzöl.
3. Tűzz ki reális SLO-t a mért adatból (ne a vágyból).
4. Számold ki az error budgetet és állíts be többablakos burn-rate riasztást.
5. Egyszerű budget-politika: mi történik, ha elfogy (pl. feature-fagyasztás stabilizálásig).
6. Havi review — finomítsd. Kezdj a kritikus szolgáltatással.

07Gyakori hibák

• Túl sok SLI: tucatnyi mutató → senki nem tartja karban. 1–2 jó elég.
• Alá nem támasztott cél: „legyen minden 99,99%" — mérés nélkül üres ígéret.
• Belső SLO = külső SLA: az SLA legyen lazább, legyen mozgástér (kötbér!).
• Sima küszöb-riasztás: téves riasztás-áradat; burn-rate kell.
• Error budget figyelmen kívül: a keret arra való, hogy döntsetek (fejlesztés vs stabilitás), nem dísznek.

08GYIK

28 vagy 30 napos ablak legyen?

A 28 napos gördülő ablak előnye, hogy mindig pontosan 4 hét (azonos napszám-eloszlás), ezért stabilabb. A 30 nap a „havi" intuícióhoz közelebb áll. Bármelyik jó — a lényeg a gördülő (rolling), nem naptári hónap.

Mit mérjek SLI-nek, ha nincs sok eszközöm?

Kezdj a legegyszerűbbel: a sikeres kérések aránya (request success rate) a belépő ponton. Ez gyakran már a meglévő logokból/load balancer-metrikákból kinyerhető — nem kell teljes observability-stack az első SLO-hoz.

SLA-t is adjak az ügyfélnek?

Csak ha tudod tartani — és mindig lazábban, mint a belső SLO. Előbb mérj és tartsd az SLO-t hónapokig, és csak utána ígérj kifelé SLA-t kötbérrel.

Kell hozzá külső segítség?

Az SLI helyes megválasztása és a burn-rate-riasztás beállítása tapasztalatot kíván — egy felmérés + a kritikus szolgáltatások SLO-inak felállítása gyorsan kevesebb, de értelmes riasztást ad. Pont ezt csináljuk: banki SRE-tapasztalatból, KKV-léptékre szabva.

Mi egy jó SLO-sablon felépítése?

Egy használható SLO-sablon hat elemből áll: (1) a szolgáltatás és a felhasználói szempontból fontos viselkedés megnevezése; (2) az SLI — a konkrét, mérhető mutató (pl. sikeres HTTP-kérések aránya, vagy a 300 ms alatti válaszidő aránya); (3) a célérték (pl. 99,9%); (4) a mérési ablak (jellemzően 28 napos gördülő); (5) az error budget — a megengedett hiba (100% mínusz a cél), percben/órában kifejezve; (6) a riasztási politika — többablakos burn-rate riasztás (gyors és lassú égés). Ez a hat sor egy oldalon elfér, és pont elég a kezdéshez — a túl bonyolult SLO-t senki nem tartja karban.

Mennyi az error budget 99,9%-nál?

Az error budget a megengedett kiesés: 100% mínusz a célérték. Átlagos (≈30,4 napos) hónapra vetítve: 99% cél ≈ 7 óra 18 perc megengedett kiesés; 99,5% ≈ 3 óra 39 perc; 99,9% ≈ 43,8 perc; 99,95% ≈ 21,9 perc; 99,99% ≈ 4,4 perc. Jól látszik, hogy minden további »kilenc« nagyjából tizedére csökkenti a hibakeretet — és nagyjából tízszerezi a költséget és a működési szigort. Ezért a cél nem a maximális kilencek száma, hanem az üzletileg indokolt szint: a legtöbb belső rendszernek a 99,5%–99,9% bőven elég, a négy kilenc (99,99%) komoly mérnöki és pénzbeli elköteleződés.

Milyen SLO-célt válasszak a szolgáltatásomnak?

Az üzleti hatás dönt, nem a divat. Indikatív kiindulás: kritikus, ügyfél felé néző webes/API-szolgáltatás 99,9%; belső, munkaidős eszköz 99,5%; háttér- és batch-feldolgozás inkább sikerráta-alapú SLO (pl. a futások 99,5%-a határidőre, sikeresen). Fontos elv: az SLO-t a tényleges mért teljesítményből kiindulva állítsd be (ne ígérj olyat, amit nem mérsz), és inkább szigorítsd fokozatosan. A túl magas, alá nem támasztott cél (»minden legyen 99,99%«) csak felesleges riasztást és kiégést szül — a hibakeret pont arra való, hogy a fejlesztés és a stabilitás közt egyensúlyozz.

Mi a burn-rate riasztás és miért jobb a sima küszöbnél?

A burn-rate azt méri, milyen gyorsan fogyasztod az error budgetet. Egy 1-es burn-rate azt jelenti, hogy a mérési ablak végére pont elfogy a keret; 14-es burn-rate azt, hogy 14-szer gyorsabban — vagyis nagyjából két nap alatt elfogy a teljes havi keret. A többablakos riasztás (pl. gyors égés: 2% keret 1 óra alatt → azonnali, oldal-szintű riasztás; lassú égés: 5% keret 6 óra alatt → ticket) sokkal kevesebb téves riasztást ad, mint a »minden hibára csengess« megközelítés, és a tényleg fontos, gyorsan romló helyzetekre koncentrál. Ezért lett ez az SRE-gyakorlat alapértelmezése.

Mi a különbség SLI, SLO és SLA között?

Az SLI a mért mutató (pl. a sikeres kérések aránya). Az SLO a belső célérték erre a mutatóra (pl. 99,9% 28 napon). Az SLA a külső, ügyféllel kötött szerződéses ígéret, jellemzően kötbérrel — és mindig lazább, mint a belső SLO, hogy legyen mozgástér. A sorrend: előbb mérj (SLI), tűzz ki reális belső célt (SLO), és csak utána ígérj kifelé (SLA). A részletes magyarázatot lásd a Monitoring 101 cikkünkben; ez a cikk a kész, kitölthető SLO-sablonokra fókuszál.

Hogyan vezetem be az SLO-kat a gyakorlatban?

Józan sorrend: (1) válassz 1–2 felhasználói szempontból fontos SLI-t szolgáltatásonként (ne tucatnyit); (2) mérd néhány hétig, hogy lásd a valós szintet; (3) tűzz ki reális SLO-t a mért adatból; (4) számold ki az error budgetet és állíts be többablakos burn-rate riasztást; (5) vezess be egy egyszerű hibakeret-politikát (mi történik, ha elfogy — pl. feature-fagyasztás stabilizálásig); (6) havonta nézd át és finomítsd. Kezdj kicsiben, a kritikus szolgáltatással — a cél a kevesebb, de értelmes riasztás és a tárgyalható stabilitás-kép, nem a tökéletes fedés első nap.

09Konzultáció

Ha SLO-kat vezetnél be (vagy a meglévő riasztás-zajt csökkentenéd), egy felmérés a szolgáltatásaid és a meglévő metrikáid alapján kijelöli az 1–2 fontos SLI-t szolgáltatásonként, és felállítja a hibakeret + burn-rate riasztást. Egy 30 perces ingyenes konzultáció után kész SLO-sablonokat és riasztási politikát adunk.

Az üzemeltetést a Monitoring & NOC (24/7, <5 perc reakció), az infrastruktúrát az IT Infrastruktúra szolgáltatásunk fedi — banki SRE-tapasztalatból, KKV-méretre szabva.

Ingyenes 30 perces konzultáció