Mit jelentenek valójában a „kilencesek”
A rendelkezésre állás (availability, uptime) az az időarány, amelyben egy szolgáltatás működik. A megengedett kiesés egyszerűen kiszámítható: megengedett kiesés = (100% − rendelkezésre állás) × az időszak hossza. Papíron a 99,9% és a 99,99% között csak egy kilences a különbség, a gyakorlatban viszont tizedannyi megengedett kiesés.
| Rendelkezésre állás | Naponta | Havonta (30 nap) | Évente (365 nap) |
|---|---|---|---|
| 99% | 14 perc 24 mp | 7 óra 12 perc | 3 nap 15 óra 36 perc |
| 99,5% | 7 perc 12 mp | 3 óra 36 perc | 1 nap 19 óra 48 perc |
| 99,9% | 1 perc 26 mp | 43 perc 12 mp | 8 óra 45 perc 36 mp |
| 99,95% | 43 mp | 21 perc 36 mp | 4 óra 22 perc 48 mp |
| 99,99% | 8,6 mp | 4 perc 19 mp | 52 perc 34 mp |
| 99,999% | 0,86 mp | 26 mp | 5 perc 15 mp |
A legtöbb SLA naptári hónaponként méri a rendelkezésre állást, ezért februárban rövidebb a megengedett kiesés, mint januárban. Az éves érték összehasonlításra jó, a szerződésben azonban a havi számít. Bármely százalékra és időszakra pontos értékeket kap az oldalon található SLA kalkulátorral.
SLA, SLO és SLI: három rövidítés, három különböző dolog
A fogalmakat gyakran összekeverik, pedig különböző szinteket írnak le. A Google „Site Reliability Engineering” című könyve így választja szét őket:
- SLI (Service Level Indicator): mért érték, például a sikeres kérések aránya, azon percek aránya, amelyekben a szolgáltatás válaszol, vagy a válaszidő.
- SLO (Service Level Objective): ennek a mutatónak a célértéke, például a kérések 99,95%-a sikeres egy naptári hónapban. Ez a csapat belső célja.
- SLA (Service Level Agreement): az ügyféllel kötött szerződés, amely tartalmazza a vállalt szintet és a nem teljesítés következményeit, leggyakrabban jóváírást (service credit).
A belső SLO ezért általában szigorúbb, mint az ügyfeleknek vállalt SLA. A cél és a tényleges állapot közötti különbséget az SRE hibakeretnek (error budget) nevezi: amíg van belőle elég, a csapat élesíthet változtatásokat, ha elfogy, a stabilitás kap elsőbbséget.
Amit az SLA általában nem számol bele
A szerződésben szereplő százalék csak az információ fele. A másik fele a kiesés definíciója és a kivételek listája. Az SLA olvasásakor különösen ezeket ellenőrizze:
- Tervezett karbantartás. Sok szolgáltató kizárja a számításból az előre bejelentett karbantartási ablakokat. A felhasználók számára a szolgáltatás ilyenkor is elérhetetlen, ezért nézze meg, milyen hosszúak és gyakoriak az ablakok, és munkaidőn kívül esnek-e.
- A kiesés definíciója. Csak a teljes leállás számít, vagy a részleges is? Az EC2 regionális rendelkezésre állásánál az AWS például csak akkor számol kiesést, ha két vagy több rendelkezésre állási zónában az összes futó példánya egyszerre elveszíti a külső kapcsolatot.
- A mérési időszak. Havi, negyedéves vagy éves. Éves időszaknál egyetlen hosszú kiesés az egész évre „szétteríthető”.
- Ki mér. A szolgáltató vagy az Ön felügyelete számít-e, és milyen gyorsan kell bejelentenie a kiesést.
- Kivételek. A vis maior, az ügyfél oldali hibák, a szolgáltató hatókörén kívüli hálózati problémák és az előzetes (preview) szolgáltatások szinte mindig ki vannak zárva.
A jóváírás nem biztosítás
Ha a szolgáltató nem teljesíti a vállalt szintet, általában jóváírás jár Önnek, vagyis az érintett szolgáltatás havidíjának részleges visszatérítése. Az Amazon EC2 esetében ez például 10%, ha a havi rendelkezésre állás a vállalt szint alá esik, 30% 99% alatt és 100% 95% alatt, az igényt pedig az incidenst követő második számlázási időszak végéig kell benyújtani.
Egy példa: a szolgáltatás havonta 2000 EUR, a kiesés egy 30 napos hónapban 4 órán át tart. A rendelkezésre állás 99,44%-ra csökken, és 10% jóváírást kap, azaz 200 EUR-t. Ha egy óra kiesés 1500 EUR-ba kerül Önnek, a kár 6000 EUR. A jóváírás ösztönző a szolgáltatónak, nem kártérítés Önnek. A szolgáltató kiválasztásánál ezért fontosabb a kieséseket megelőző architektúra, mint a jóváírás mértéke.
A teljes rendszer rendelkezésre állása: láncok és redundancia
Egy webáruháznak internetkapcsolatra, alkalmazásszerverre és adatbázisra van szüksége. Ha bármelyik láncszem kiesik, az áruház nem működik. Soros komponenseknél a rendelkezésre állások összeszorzódnak: A = A₁ × A₂ × … × Aₖ. Három komponens 99,9%, 99,9% és 99,95% értékkel együtt 99,75%-ot ad, ami évente csaknem 22 óra kiesést jelent 8 óra 46 perc helyett. Minden további komponens csökkenti a rendelkezésre állást.
A redundancia fordítva működik. Egy n azonos példányból álló csoportra, ahol egy példány is elég, A = 1 − (1 − a)ⁿ. Két 99%-os szerver együtt 99,99%-ot ér el, két 99,9%-os pedig 99,9999%-ot. A feltétel az, hogy egymástól függetlenül hibásodjanak meg. A közös áramellátás, ugyanaz a switch, ugyanaz a hibás szoftververzió vagy egy sikertelen automatikus átállás ezt a feltételezést megdönti, ezért a redundáns rendszerek valós rendelkezésre állása alacsonyabb a számítottnál.
Gyakorlati tanács: először a leggyengébb láncszemet keresse meg, mert annak javítása emeli leginkább a rendszert. Ez gyakran nem szerver, hanem egyetlen internetkapcsolat, egyetlen tűzfal vagy replika nélküli adatbázis.
Az SLA, az RPO és az RTO
Az SLA azt határozza meg, mennyi kiesés megengedett egy időszakban. Az RTO (Recovery Time Objective) azt, milyen gyorsan kell a rendszernek egy adott incidens után újra működnie, az RPO (Recovery Point Objective) pedig azt, mennyi adat veszhet el. Az értékeknek összhangban kell lenniük: ha egy kritikus rendszer RTO-ja 4 óra, egyetlen nagyobb incidens többet használ fel, mint amennyit egy havi 99,9%-os SLA megenged (43 perc). A magas SLA ezért replikációt és gyors átállást igényel, nem csak jó mentéseket.
Hogy hogyan határozza meg rendszercsoportonként az RPO-t és az RTO-t, és hogyan ellenőrizze, teljesíti-e őket a helyreállítás, azt a mentés, RPO és RTO útmutató írja le.
Ellenőrzőlista az SLA-szerződéshez
- Határozza meg a vezetőséggel, mennyibe kerül egy óra kiesés, és havonta mennyi kiesés elfogadható még.
- Térképezze fel a szolgáltatás függőségeit, és a teljes lánc rendelkezésre állását számítsa ki, ne csak az egyes komponensekét.
- Ellenőrizze a kiesés definícióját, a mérési időszakot és a mérés módját.
- Ellenőrizze a tervezett karbantartási ablakok hosszát, gyakoriságát és időpontját.
- Olvassa el a kivételek listáját, valamint a jóváírás igénylésének menetét és határidejét.
- A rendelkezésre állás mellett kérjen prioritásonkénti támogatási reakció- és megoldási időket is.
- Hangolja össze az SLA-t az RPO-val, az RTO-val és a katasztrófa utáni helyreállítási tervvel.
- Vezessen be saját, független rendelkezésre állás-felügyeletet és havi jelentést.
A Humanfrog TIER III szintű szlovéniai adatközpontokban üzemeltet infrastruktúrát, és redundáns architektúrákat, valamint felügyeletet tervez. Ha a kalkulátor eredményeit szakértővel ellenőrizné, vagy egy meglévő SLA-t nézetne át, írjon nekünk.
