Što zapravo znače „devetke”
Dostupnost (availability, uptime) udio je vremena u kojem usluga radi. Dopušteni zastoj izračunava se jednostavno: dopušteni zastoj = (100 % − dostupnost) × duljina razdoblja. Na papiru je razlika između 99,9 % i 99,99 % samo jedna devetka, a u praksi deset puta manje dopuštenog zastoja.
| Dostupnost | Dnevno | Mjesečno (30 dana) | Godišnje (365 dana) |
|---|---|---|---|
| 99 % | 14 min 24 s | 7 h 12 min | 3 d 15 h 36 min |
| 99,5 % | 7 min 12 s | 3 h 36 min | 1 d 19 h 48 min |
| 99,9 % | 1 min 26 s | 43 min 12 s | 8 h 45 min 36 s |
| 99,95 % | 43 s | 21 min 36 s | 4 h 22 min 48 s |
| 99,99 % | 8,6 s | 4 min 19 s | 52 min 34 s |
| 99,999 % | 0,86 s | 26 s | 5 min 15 s |
Većina SLA ugovora mjeri dostupnost po kalendarskom mjesecu, pa je dopušteni zastoj u veljači kraći nego u siječnju. Godišnja brojka korisna je za usporedbu, ali u ugovoru vrijedi mjesečna. Točne vrijednosti za bilo koji postotak i razdoblje izračunajte SLA kalkulatorom na ovoj stranici.
SLA, SLO i SLI: tri kratice, tri različite stvari
Pojmovi se često miješaju, ali opisuju različite razine. Googleova knjiga Site Reliability Engineering razlikuje ih ovako:
- SLI (Service Level Indicator) izmjerena je vrijednost, na primjer udio uspješnih zahtjeva, udio minuta u kojima usluga odgovara ili vrijeme odziva.
- SLO (Service Level Objective) ciljna je vrijednost tog pokazatelja, na primjer 99,95 % uspješnih zahtjeva u kalendarskom mjesecu. To je interni cilj tima.
- SLA (Service Level Agreement) ugovor je s korisnikom koji sadrži obećanu razinu i posljedice ako ona nije postignuta, najčešće kompenzaciju (service credit).
Interni SLO stoga je u pravilu stroži od SLA-a koji obećavate korisnicima. Razliku između cilja i stvarnog stanja SRE naziva proračunom pogrešaka (error budget): dok ga ima dovoljno, tim može uvoditi promjene, a kad ga ponestane, prednost ima stabilnost.
Što SLA obično ne računa
Postotak u ugovoru samo je pola informacije. Druga polovica je definicija zastoja i popis iznimaka. Pri čitanju SLA ugovora posebno provjerite:
- Planirano održavanje. Mnogi pružatelji unaprijed najavljena razdoblja održavanja izuzimaju iz izračuna. Za korisnike je usluga tada ipak nedostupna, pa provjerite koliko su ta razdoblja duga i česta te jesu li izvan vašeg radnog vremena.
- Definiciju zastoja. Računa li se samo potpuni prekid ili i djelomični? AWS primjerice kod regionalne dostupnosti EC2 zastoj računa tek kada sve vaše pokrenute instance u dvije ili više zona dostupnosti istodobno izgube vanjsku povezanost.
- Razdoblje mjerenja. Mjesečno, tromjesečno ili godišnje. Uz godišnje razdoblje jedan dugi zastoj može se „razrijediti” na cijelu godinu.
- Tko mjeri. Vrijedi li nadzor pružatelja ili vaš i koliko brzo morate prijaviti zastoj.
- Iznimke. Viša sila, pogreške na strani korisnika, mrežni problemi izvan područja pružatelja i usluge u pretpregledu gotovo su uvijek izuzeti.
Kompenzacije nisu osiguranje
Ako pružatelj ne postigne obećanu razinu, obično vam pripada kompenzacija, odnosno djelomični povrat mjesečne naknade za pogođenu uslugu. Kod usluge Amazon EC2 primjerice iznosi 10 % kada mjesečna dostupnost padne ispod obećane razine, 30 % ispod 99 % i 100 % ispod 95 %, a zahtjev treba podnijeti do kraja drugog obračunskog razdoblja nakon incidenta.
Primjer: usluga stoji 2.000 EUR mjesečno, a zastoj traje 4 sata u mjesecu od 30 dana. Dostupnost pada na 99,44 % i dobivate kompenzaciju od 10 %, dakle 200 EUR. Ako vas sat zastoja stoji 1.500 EUR, šteta iznosi 6.000 EUR. Kompenzacija je poticaj za pružatelja, a ne naknada za vas. Pri odabiru pružatelja zato je važnija arhitektura koja sprječava zastoje nego visina kompenzacije.
Dostupnost cijelog sustava: lanci i redundancija
Web trgovina treba internetsku vezu, aplikacijski poslužitelj i bazu podataka. Ako otkaže bilo koja karika, trgovina ne radi. Za komponente u seriji dostupnosti se množe: A = A₁ × A₂ × … × Aₖ. Tri komponente s 99,9 %, 99,9 % i 99,95 % zajedno daju 99,75 %, što znači gotovo 22 sata zastoja godišnje umjesto 8 sati i 46 minuta. Svaka dodatna komponenta smanjuje dostupnost.
Redundancija djeluje obrnuto. Za skupinu od n jednakih instanci u kojoj je dovoljna jedna vrijedi A = 1 − (1 − a)ⁿ. Dva poslužitelja s po 99 % zajedno postižu 99,99 %, a dva s po 99,9 % čak 99,9999 %. Uvjet je da otkazuju neovisno jedan o drugome. Zajedničko napajanje, isti preklopnik, ista neispravna verzija softvera ili neuspjelo automatsko prebacivanje ruše tu pretpostavku, pa je stvarna dostupnost redundantnih sustava niža od izračunane.
Praktičan savjet: najprije pronađite najslabiju kariku jer njezino poboljšanje najviše podiže sustav. Često to nije poslužitelj, nego jedna jedina internetska veza, jedan vatrozid ili baza podataka bez replike.
SLA te RPO i RTO
SLA određuje koliko je zastoja dopušteno u razdoblju. RTO (Recovery Time Objective) određuje koliko brzo sustav mora ponovno raditi nakon pojedinog incidenta, a RPO (Recovery Point Objective) koliko podataka smijete izgubiti. Brojke moraju biti usklađene: ako je RTO za kritični sustav 4 sata, jedan veći incident potroši više nego što dopušta mjesečni SLA od 99,9 % (43 minute). Visok SLA zato zahtijeva replikaciju i brzo prebacivanje, a ne samo dobre sigurnosne kopije.
Kako odrediti RPO i RTO po skupinama sustava i provjeriti postiže li ih vaš oporavak, pročitajte u vodiču sigurnosna kopija, RPO i RTO.
Kontrolni popis za SLA ugovor
- S upravom odredite koliko vas stoji sat zastoja i koliko je zastoja mjesečno još prihvatljivo.
- Ucrtajte ovisnosti usluge i izračunajte dostupnost cijelog lanca, a ne samo pojedinih komponenti.
- Provjerite definiciju zastoja, razdoblje mjerenja i način mjerenja.
- Provjerite trajanje, učestalost i vrijeme planiranih razdoblja održavanja.
- Pročitajte popis iznimaka te postupak i rok za ostvarivanje kompenzacije.
- Osim dostupnosti zatražite i vrijeme odziva podrške te vrijeme rješavanja po prioritetima.
- Uskladite SLA s RPO-om, RTO-om i planom oporavka od katastrofe.
- Uvedite vlastiti neovisni nadzor dostupnosti i mjesečno izvještavanje.
Humanfrog upravlja infrastrukturom u podatkovnim centrima razine TIER III u Sloveniji te projektira redundantne arhitekture i nadzor. Ako želite rezultate kalkulatora provjeriti sa stručnjakom ili pregledati postojeći SLA ugovor, javite nam se.
