Szolgáltatásminőség és rendelkezésre állás
Célok
A lecke végére meg tudod mondani, hogy a webes szolgáltatás minősége miért több mint a szerver állapota, ki tudod számolni, mennyi kiesést enged meg egy rendelkezésre állási cél, és el tudod különíteni az SLI-t, az SLO-t és az SLA-t.
Miért nem elég azt mondani, hogy „működik a szerver”?
Amikor valaki azt mondja, hogy „rossz volt a weboldal”, gyakran több, egymástól különböző problémát sűrít egy mondatba. Lehet, hogy az oldal nem nyílt meg. Lehet, hogy megnyílt, de a fizetésnél megállt. Az is lehet, hogy a főoldal gyorsan megjelent, de a képernyőolvasót használó látogató nem tudott továbblépni. A szolgáltatás minősége ezért nem egyetlen mérőszám, hanem egymással összefüggő tulajdonságok együttese.
Ide tartozik a funkcionális helyesség (azt teszi-e a rendszer, amit ígér?), a teljesítmény (9.4), a használhatóság és akadálymentesség (9. fejezet), a biztonság (8. fejezet) és az adatvédelem (9.6). A megbízhatóság azt fejezi ki, hogy a rendszer mennyire kiszámíthatóan viselkedik időben, nem csak egyetlen sikeres próbánál.
Ez a szemlélet segít elkerülni, hogy kizárólag a szerver állapotáról beszéljünk. Egy „zöld” szerver nem garantál jó élményt: a szerver lehet elérhető, miközben egy külső fizetési szolgáltató kiesett; az oldal visszaadhat 200-as választ, miközben egy JavaScript-hiba miatt a kosár gomb nem működik (2.4: a HTTP-siker nem üzleti siker); vagy a rendszer lehet gyors Budapestről, de használhatatlan egy lassú mobilhálózaton.
flowchart LR
U[Felhasználói feladat] --> K{Sikerül?}
K -->|igen| H[Helyes eredmény]
K -->|nem| V[Hiba és helyreállás]
H --> M[Szolgáltatásminőség mérése]
V --> M
Rendelkezésre állás: elérhető-e a szolgáltatás?
A rendelkezésre állás (availability) azt írja le, hogy a szolgáltatás a vizsgált időszakban milyen arányban használható rendeltetésszerűen. A „használható” és a „rendeltetésszerűen” a kulcsszavak: nem elég, hogy egy gép válaszoljon a hálózaton. Egy online tanulmányi rendszer akkor elérhető, ha a hallgató be tud lépni, meg tudja nézni a tárgyait, és végre tudja hajtani a szükséges műveleteket. A Google SRE-könyve (Site Reliability Engineering, a megbízhatósági mérnökség gyakorlata) az elérhetőséget úgy is méri, hogy a jól formált kérések mekkora hányada sikeres.
Az elérhetőséget gyakran százalékban adják meg. Hogy mit jelent a gyakorlatban, azt egy harmincnapos hónapra számoltuk ki:
| Cél |
Megengedett kiesés / hónap |
Megjegyzés |
| 90% |
72 óra (4 320 perc) |
több napos kiesés |
| 99% |
7,2 óra (432 perc) |
egy munkanapnyi kiesés |
| 99,9% |
43,2 perc |
„három kilences” |
| 99,99% |
4,3 perc (259 mp) |
„négy kilences” |
A több „kilences” ezért nem marketing: egyre szigorúbb elvárást jelent, és egyre drágább is, mert a kevés kiesés kevés emberi reagálási időt hagy. Az elérhetőségi százalék viszont nem mondja meg, mikor történt a kiesés. Egy ötperces hiba hajnali háromkor más következményű, mint ugyanaz a tárgyfelvétel nyitásakor.
Az is kérdés, mi számít kiesésnek. Ha a nyilvános főoldal működik, de bejelentkezés után senki nem tud menteni, akkor a szolgáltatás részlegesen kiesett. Ha csak az ajánlórendszer nem működik, de jelentkezni lehet, az is hiba, de más súlyú. A jó minőségi célok ezért a kritikus felhasználói utakból indulnak ki: bejelentkezés, keresés, jelentkezés, feltöltés, ügyintézés.
Megbízhatóság, ellenállóképesség, helyreállás
Három rokon, de nem azonos fogalom:
- megbízhatóság: a rendszer várhatóan hosszabb időn át helyesen működik;
- ellenállóképesség (reziliencia): hiba esetén is igyekszik a fontos szolgáltatást fenntartani vagy értelmesen korlátozni;
- helyreállíthatóság: milyen gyorsan és biztonságosan tér vissza a rendszer a megfelelő állapotba.
Képzeljünk el egy webáruházat. Ha az ajánló modul hibás, a reziliens rendszer továbbra is megmutatja a termékeket és lehetővé teszi a vásárlást, csak az ajánlások helyén őszintén jelzi, hogy ez a funkció átmenetileg nem elérhető. Ha viszont az ajánló hibája miatt a teljes főoldal üres marad, a rendszer túl szorosan kötötte össze a kevésbé fontos és a létfontosságú funkciókat. A cél nem az, hogy semmi ne romolhasson el, hanem hogy egy hiba hatása ne legyen nagyobb, mint feltétlenül szükséges.
A hibák nem kivételes események: hálózatok lassulnak, külső szolgáltatások késnek, konfigurációk tévesek lehetnek, emberek hibáznak. A minőségi gondolkodás nem az „örök hibátlanságra”, hanem arra épít, hogy a rendszer felismeri, kezeli és érthetően kommunikálja a hibát (10.2).
SLI, SLO és SLA: három hasonló rövidítés, három különböző szerep
A Google SRE-könyve szerint:
- Az SLI (Service Level Indicator, szolgáltatásszint-mutató) „gondosan meghatározott mennyiségi mérték a nyújtott szolgáltatás valamely szempontjáról”. Tipikus SLI a kérés késleltetése, a hibaarány, az áteresztőképesség (kérés/másodperc) és a rendelkezésre állás. Az SLI mérés, nem ígéret.
- Az SLO (Service Level Objective, szolgáltatásszint-cél) az SLI célértéke vagy célsávja. Például „a sikeres fizetések aránya havonta legalább 99,95%”, vagy „a keresések 95%-a két másodpercen belül válaszol”. Egy jó SLO konkrét: megmondja, mit mérünk, milyen küszöbbel és milyen időablakban.
- Az SLA (Service Level Agreement, szolgáltatásszint-megállapodás) szerződés a felhasználókkal, amelynek következménye van, ha a vállalást nem teljesítik. Az SRE-könyv hasznos próbája: kérdezd meg, mi történik, ha nem teljesül; ha nincs kimondott következmény, valószínűleg SLO-ról van szó.
A megjegyzéshez egy mondat: az SLI azt mondja meg, mi történt; az SLO azt, mit szeretnénk elérni; az SLA pedig azt, mit vállalunk mások felé. Nem jó gyakorlat, ha a külső szerződéses minimum azonos a belső céllal: akkor a legkisebb eltérés is szerződésszegés, és nincs mozgástér a romló tendencia észlelésére. Ezért az SLA általában óvatosabb, mint a belső SLO.
Hibakeret (error budget)
A 100%-os cél nem reális, és az innovációt is lassítja. Az SRE-könyv ezért hibakeretet (error budget) javasol: az SLO-ból az következik, mekkora arányban szabad hibázni, és ezt a keretet napokra-hetekre követik. Ha a keret hátralévő része nagy, bátrabban lehet új változatot kiadni; ha elfogyott, a stabilitás elsőbbséget élvez. Egy 99,9%-os havi cél hibakerete 43,2 perc kiesés.
Percentilis, nem átlag
Az SRE-könyv szerint az átlagok elrejtik a lassú kivételeket; a magas percentilisek (99., 99,9.) a hihető legrosszabb esetet mutatják, a medián (50.) a tipikusat. Kipróbáltunk egy tízelemű mintát: kilenc kérés 100 ms, egy pedig 10 másodperc.
átlag: 1090 ms; medián: 100 ms; max: 10000 ms
Az átlag (1,09 s) elfogadhatónak tűnik, a tizedik felhasználó számára viszont a szolgáltatás egyértelműen rossz volt. Ezért az SLI-k jó része percentilisre épül (például „a kérések 95%-a 2 másodpercen belül”).
Végigvezetett példa: a Kurzuspont tárgyfelvételi nyitása
A tárgyfelvétel hétfőn 10:00-kor nyílik. Az üzemeltető csak azt ellenőrzi, hogy a nyitóoldal válaszol-e. Ez kevés: a hallgatónak be kell lépnie, meg kell találnia a kurzust, és el kell mentenie a jelentkezést. Ha az első két lépés működik, de a mentés időtúllépés miatt hibát ad, a felhasználó szempontjából a kritikus szolgáltatás nem elérhető.
| Elem |
A Kurzuspontban |
| Kritikus út |
belépés → kurzus keresése → jelentkezés mentése |
| SLI |
A kezdeményezett jelentkezések hány százaléka zárul sikeresen, és a mentés válaszideje p95-ön |
| SLO |
A nyitást követő két órában a jelentkezések legalább 99,5%-a sikeres; a mentés p95 válaszideje legfeljebb 2 s |
| SLA |
Az egyetem és a szolgáltató közötti szerződés: óvatosabb, például havi 99,0%, következménnyel (díjjóváírás) |
| Hibakeret |
A 99,5%-os cél miatt a nyitási kérések 0,5%-a lehet sikertelen; ha ez hamarabb elfogy, leállítjuk a nem sürgős változtatásokat |
Ebből nem következik, hogy a maradék 0,5% minden hibája elfogadható: a hibák okait ettől még vizsgálni kell. A mutató csak abban segít, hogy a minőség megítélése ne anekdotákból vagy egyetlen szerverjelzésből történjen.
Gyakori tévhitek
| Állítás |
Pontosítás |
| „A 100%-os rendelkezésre állás reális alapelv.” |
Hosszú távon a nulla kiesés rendkívül drága; a helyes kérdés, mely funkciónál mekkora kiesés mekkora kárt okoz. |
| „Ha a szerver 200 OK-t küld, minden rendben van.” |
A HTTP-státusz kommunikációs jelzés; a mögötte lévő üzleti művelet hibás lehet. |
| „A magas rendelkezésre állás egyenlő a jó felhasználói élménnyel.” |
Egy lassú vagy nehezen használható szolgáltatás elérhető lehet, mégis kudarcot vall. |
| „Az SLA technikai mérőszám.” |
Szerződéses vállalás; tartalmazhat mérőszámot, de nem azonos a méréssel vagy a belső céllal. |
| „Az átlagos válaszidő jól jellemzi a minőséget.” |
Az átlag elrejti a lassú kivételeket. |
Röviden
- A minőség több tulajdonság együttese; a „zöld szerver” még nem jó szolgáltatás.
- A rendelkezésre állás százalékát kiesési időre kell lefordítani: 99,9% ≈ 43,2 perc/hó, 99,99% ≈ 4,3 perc/hó.
- SLI = mérőszám, SLO = belső cél, SLA = szerződéses vállalás következménnyel.
- A hibakeret megmondja, mennyi hiba fér a célba; a 100% nem reális cél.
- Átlag helyett percentilis, és a kritikus felhasználói utakra mérjünk.
Ellenőrző kérdések
- Mennyi kiesést enged meg havonta a 99,95%-os cél?
- Mi a különbség az SLI és az SLO között?
- Miért óvatosabb az SLA, mint a belső SLO?
- Miért vezet félre az átlagos válaszidő?
Tanulási források
Szolgáltatásminőség és rendelkezésre állás
Célok
A lecke végére meg tudod mondani, hogy a webes szolgáltatás minősége miért több mint a szerver állapota, ki tudod számolni, mennyi kiesést enged meg egy rendelkezésre állási cél, és el tudod különíteni az SLI-t, az SLO-t és az SLA-t.
Miért nem elég azt mondani, hogy „működik a szerver”?
Amikor valaki azt mondja, hogy „rossz volt a weboldal”, gyakran több, egymástól különböző problémát sűrít egy mondatba. Lehet, hogy az oldal nem nyílt meg. Lehet, hogy megnyílt, de a fizetésnél megállt. Az is lehet, hogy a főoldal gyorsan megjelent, de a képernyőolvasót használó látogató nem tudott továbblépni. A szolgáltatás minősége ezért nem egyetlen mérőszám, hanem egymással összefüggő tulajdonságok együttese.
Ide tartozik a funkcionális helyesség (azt teszi-e a rendszer, amit ígér?), a teljesítmény (9.4), a használhatóság és akadálymentesség (9. fejezet), a biztonság (8. fejezet) és az adatvédelem (9.6). A megbízhatóság azt fejezi ki, hogy a rendszer mennyire kiszámíthatóan viselkedik időben, nem csak egyetlen sikeres próbánál.
Ez a szemlélet segít elkerülni, hogy kizárólag a szerver állapotáról beszéljünk. Egy „zöld” szerver nem garantál jó élményt: a szerver lehet elérhető, miközben egy külső fizetési szolgáltató kiesett; az oldal visszaadhat
200-as választ, miközben egy JavaScript-hiba miatt a kosár gomb nem működik (2.4: a HTTP-siker nem üzleti siker); vagy a rendszer lehet gyors Budapestről, de használhatatlan egy lassú mobilhálózaton.flowchart LR U[Felhasználói feladat] --> K{Sikerül?} K -->|igen| H[Helyes eredmény] K -->|nem| V[Hiba és helyreállás] H --> M[Szolgáltatásminőség mérése] V --> MRendelkezésre állás: elérhető-e a szolgáltatás?
A rendelkezésre állás (availability) azt írja le, hogy a szolgáltatás a vizsgált időszakban milyen arányban használható rendeltetésszerűen. A „használható” és a „rendeltetésszerűen” a kulcsszavak: nem elég, hogy egy gép válaszoljon a hálózaton. Egy online tanulmányi rendszer akkor elérhető, ha a hallgató be tud lépni, meg tudja nézni a tárgyait, és végre tudja hajtani a szükséges műveleteket. A Google SRE-könyve (Site Reliability Engineering, a megbízhatósági mérnökség gyakorlata) az elérhetőséget úgy is méri, hogy a jól formált kérések mekkora hányada sikeres.
Az elérhetőséget gyakran százalékban adják meg. Hogy mit jelent a gyakorlatban, azt egy harmincnapos hónapra számoltuk ki:
A több „kilences” ezért nem marketing: egyre szigorúbb elvárást jelent, és egyre drágább is, mert a kevés kiesés kevés emberi reagálási időt hagy. Az elérhetőségi százalék viszont nem mondja meg, mikor történt a kiesés. Egy ötperces hiba hajnali háromkor más következményű, mint ugyanaz a tárgyfelvétel nyitásakor.
Az is kérdés, mi számít kiesésnek. Ha a nyilvános főoldal működik, de bejelentkezés után senki nem tud menteni, akkor a szolgáltatás részlegesen kiesett. Ha csak az ajánlórendszer nem működik, de jelentkezni lehet, az is hiba, de más súlyú. A jó minőségi célok ezért a kritikus felhasználói utakból indulnak ki: bejelentkezés, keresés, jelentkezés, feltöltés, ügyintézés.
Megbízhatóság, ellenállóképesség, helyreállás
Három rokon, de nem azonos fogalom:
Képzeljünk el egy webáruházat. Ha az ajánló modul hibás, a reziliens rendszer továbbra is megmutatja a termékeket és lehetővé teszi a vásárlást, csak az ajánlások helyén őszintén jelzi, hogy ez a funkció átmenetileg nem elérhető. Ha viszont az ajánló hibája miatt a teljes főoldal üres marad, a rendszer túl szorosan kötötte össze a kevésbé fontos és a létfontosságú funkciókat. A cél nem az, hogy semmi ne romolhasson el, hanem hogy egy hiba hatása ne legyen nagyobb, mint feltétlenül szükséges.
A hibák nem kivételes események: hálózatok lassulnak, külső szolgáltatások késnek, konfigurációk tévesek lehetnek, emberek hibáznak. A minőségi gondolkodás nem az „örök hibátlanságra”, hanem arra épít, hogy a rendszer felismeri, kezeli és érthetően kommunikálja a hibát (10.2).
SLI, SLO és SLA: három hasonló rövidítés, három különböző szerep
A Google SRE-könyve szerint:
A megjegyzéshez egy mondat: az SLI azt mondja meg, mi történt; az SLO azt, mit szeretnénk elérni; az SLA pedig azt, mit vállalunk mások felé. Nem jó gyakorlat, ha a külső szerződéses minimum azonos a belső céllal: akkor a legkisebb eltérés is szerződésszegés, és nincs mozgástér a romló tendencia észlelésére. Ezért az SLA általában óvatosabb, mint a belső SLO.
Hibakeret (error budget)
A 100%-os cél nem reális, és az innovációt is lassítja. Az SRE-könyv ezért hibakeretet (error budget) javasol: az SLO-ból az következik, mekkora arányban szabad hibázni, és ezt a keretet napokra-hetekre követik. Ha a keret hátralévő része nagy, bátrabban lehet új változatot kiadni; ha elfogyott, a stabilitás elsőbbséget élvez. Egy 99,9%-os havi cél hibakerete 43,2 perc kiesés.
Percentilis, nem átlag
Az SRE-könyv szerint az átlagok elrejtik a lassú kivételeket; a magas percentilisek (99., 99,9.) a hihető legrosszabb esetet mutatják, a medián (50.) a tipikusat. Kipróbáltunk egy tízelemű mintát: kilenc kérés 100 ms, egy pedig 10 másodperc.
Az átlag (1,09 s) elfogadhatónak tűnik, a tizedik felhasználó számára viszont a szolgáltatás egyértelműen rossz volt. Ezért az SLI-k jó része percentilisre épül (például „a kérések 95%-a 2 másodpercen belül”).
Végigvezetett példa: a Kurzuspont tárgyfelvételi nyitása
A tárgyfelvétel hétfőn 10:00-kor nyílik. Az üzemeltető csak azt ellenőrzi, hogy a nyitóoldal válaszol-e. Ez kevés: a hallgatónak be kell lépnie, meg kell találnia a kurzust, és el kell mentenie a jelentkezést. Ha az első két lépés működik, de a mentés időtúllépés miatt hibát ad, a felhasználó szempontjából a kritikus szolgáltatás nem elérhető.
Ebből nem következik, hogy a maradék 0,5% minden hibája elfogadható: a hibák okait ettől még vizsgálni kell. A mutató csak abban segít, hogy a minőség megítélése ne anekdotákból vagy egyetlen szerverjelzésből történjen.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Tanulási források