SLI (service level indicator, palvelutasoindikaattori) on mittari sille, miten palvelusi toimii, esimerkiksi onnistuneiden pyyntöjen osuus. SLO (service level objective, palvelutasotavoite) on tämän mittarin sisäinen tavoite, esimerkiksi että 99,9 % tarkistuksista onnistuu 30 päivän aikana. SLA (service level agreement, palvelutasosopimus) on asiakkaille annettu lupaus, yleensä SLO:ta matalammalla tavoitteella ja seuraamuksella, kuten hyvityksellä, jos tavoite jää saavuttamatta. Indikaattori on se, mitä mittaat, tavoite se, mihin pyrit, ja sopimus se, mihin sitoudut.
Tässä oppaassa käydään läpi jokainen termi esimerkein, näytetään, mitä käytettävyysprosentit tarkoittavat minuutteina, ja kerrotaan, miten valitset indikaattorit verkkosivustolle tai API:lle, päätät mikä lasketaan katkoksi ja kirjoitat SLA:n, jonka asiakkaat ymmärtävät.
Kolme termiä selkokielellä
SLI: mittari
Palvelutasoindikaattori on luku, jonka voit laskea todellisesta datasta. Se on lähes aina suhdeluku: onnistuneet tapahtumat jaettuna kaikilla tapahtumilla. Verkkosivustolla se voi olla niiden käytettävyystarkistusten osuus, jotka saivat odotetun vastauksen. API:lla se voi olla niiden pyyntöjen osuus, joihin vastattiin muulla kuin 5xx-tilakoodilla alle 500 millisekunnissa. SLI:hin ei liity tavoitetta. Se kertoo vain, mitä tapahtui.
SLO: tavoite
Palvelutasotavoite liittää SLI:hin tavoitteen ja aikaikkunan. ”99,9 % kassasivun tarkistuksista onnistuu liukuvan 30 päivän jakson aikana” on SLO. Se on sisäinen työkalu. Se kertoo tiimille, milloin luotettavuus on riittävällä tasolla uusien ominaisuuksien julkaisemiseen ja milloin on aika hidastaa ja korjata asioita.
SLA: sopimus
Palvelutasosopimus on ulospäin annettu lupaus, joka kirjataan sopimukseen tai käyttöehtoihin. Siinä nimetään palvelu, tavoite, mittaustapa, poikkeukset ja se, mitä asiakas saa, jos tavoite jää saavuttamatta. Kaikki palvelut eivät tarvitse SLA:ta, mutta jokainen SLA tarvitsee taakseen SLO:n. Muuten et saa mitään ennakkovaroitusta siitä, että olet rikkomassa sitä.
Miten SLI, SLO ja SLA liittyvät toisiinsa
Ajattele niitä kerroksina. SLI on raaka signaali. SLO on samaan signaaliin vedetty tiukempi sisäinen raja. SLA on samaan signaaliin vedetty löysempi ulkoinen raja. SaaS-tuotteen tyypillinen asetelma näyttää tältä (esimerkkiarvot):
SLI: niiden minuutin välein tehtävien app.lumenanalytics.io-tarkistusten osuus, jotka palauttavat tilakoodin 200 ja sisältävät kojelaudan otsikon.
SLO: 99,95 % kalenterikuukaudessa.
SLA: 99,9 % kalenterikuukaudessa, ja hyvitys, jos tavoite ei täyty.
Ero 99,95 %:n ja 99,9 %:n välillä on turvamarginaali. Jos tiimi huomaa SLO:n lipsuvan kuukauden toisella viikolla, sillä on vielä aikaa toimia ennen kuin sopimuksessa annettu lupaus on vaarassa.
Käytettävyysprosentit minuutteina
Käytettävyystavoitteet näyttävät paperilla lähellä toisiaan olevilta, mutta jokainen ylimääräinen yhdeksikkö pienentää sallittua katkoaikaa kymmenesosaan. Alla olevassa taulukossa käytetään keskimääräistä kuukautta (365,25 päivän vuosi jaettuna 12:lla), kuten käytettävyyslaskurissa; 30 päivän kuukausi sallii hieman vähemmän.
KäytettävyystavoiteSallittu katkoaika kuukaudessaSallittu katkoaika vuodessa99 %7 h 18 min 18 s3 vrk 15 h 39 min 36 s99,5 %3 h 39 min 9 s1 vrk 19 h 49 min 48 s99,9 min 49 s8 h 45 min 57 s99,95 min 54 s4 h 22 min 58 s99,99 %4 min 22 s52 min 35 s99,999 s5 min 15 s
Tästä seuraa kaksi käytännön asiaa. Ensinnäkin valvonnan on pystyttävä näkemään se katkoaika, jonka lupaat. Viiden minuutin tarkistuksilla et voi rehellisesti mitata 99,99 %:n kuukausitavoitetta, koska yksikin huomaamatta jäänyt katko voi kuluttaa koko budjetin. Toiseksi jokainen 99,9 %:n ylittävä tavoite jättää tuskin lainkaan tilaa manuaaliselle reagoinnille. 99,99 %:n tavoitteella yksi hitaasti hoidettu yöllinen häiriö pilaa koko kuukauden.
Virhebudjetit: SLO:sta päätöksiksi
Virhebudjetti on se määrä häiriöitä, jonka SLO sallii. 99,9 %:n kuukausittaisella SLO:lla budjetti on 0,1 % kuukaudesta, eli noin 43 minuuttia 49 sekuntia keskimääräisessä kuukaudessa (43 minuuttia 12 sekuntia 30 päivän kuukaudessa). Jokainen häiriö kuluttaa siitä osan.
Budjetti tekee luotettavuudesta yhteisen päätöksen kiistelyn sijaan. Yksinkertainen käytäntö, jota monet tiimit noudattavat:
Budjetista on jäljellä yli puolet: julkaise normaalisti.
Jäljellä alle puolet: käy riskialttiit julkaisut läpi ja ota tietokantamuutoksiin toinen tarkastaja.
Budjetti on käytetty: keskeytä palvelun ominaisuusjulkaisut ja korjaa viimeisimpien häiriöiden syitä, kunnes aikaikkuna alkaa alusta.
Esimerkki: harborlabs.dev-palvelun julkisella API:lla on 99,9 %:n kuukausittainen SLO. Kuun 9. päivänä virheellinen julkaisu aiheuttaa 18 minuuttia virheitä. Kuun 20. päivänä varmenneongelma aiheuttaa 9 minuuttia lisää. Se tekee 27 minuuttia 43:sta, ja kuukautta on jäljellä kymmenen päivää. Tiimi lykkää seuraavaa skeemamigraatiota uuteen kuukauteen, koska yksikin samankokoinen häiriö rikkoisi tavoitteen.
SLI:den valinta verkkosivustolle tai API:lle
Hyvät SLI:t kuvaavat sitä, mitä käyttäjät kokevat, eivät sitä, miltä palvelimista tuntuu. 90 %:n CPU-kuorma ei ole SLI. Epäonnistuva kassa on. Aloita kahdella tai kolmella indikaattorilla palvelua kohden:
Käytettävyys: onnistuneiden tarkistusten tai pyyntöjen osuus. Verkkosivustolla ”onnistunut” tarkoittaa oikeaa tilakoodia ja oikeaa sisältöä, ei pelkkää vastausta.
Viive: niiden pyyntöjen osuus, joihin vastataan raja-arvoa nopeammin, esimerkiksi 95 % alle 800 ms:ssa. Osuutta on helpompi tulkita kuin keskiarvoa, joka peittää hitaat poikkeamat.
Oikeellisuus: API:lla niiden vastausten osuus, jotka sisältävät odotetut kentät. Tilakoodi 200 tyhjällä vastausrungolla ei ole onnistuminen.
Mittaa niitä polkuja, joilla on merkitystä. Esimerkiksi northwind.shop-verkkokaupassa se tarkoittaa kassaa ja tuotesivuja, ei pelkkää välimuistista tarjoiltua etusivua. API:lla se tarkoittaa niitä päätepisteitä, joihin asiakkaat integroituvat, mieluiten health check -päätepisteen kautta, joka testaa tietokannan ja muut riippuvuudet. API-valvonta, joka validoi vastausrungon, tekee päätepisteestä SLI:n, johon voi luottaa.
Mikä lasketaan käytettävyyteen
Useimmat SLA-kiistat eivät koske itse lukua. Ne koskevat sitä, mikä lasketaan. Päätä nämä asiat ennen kuin julkaiset tavoitteen:
Suunniteltu huolto. Monet SLA:t jättävät ulkopuolelle etukäteen ilmoitetun huollon, esimerkiksi 72 tunnin ennakkoilmoituksella ja enintään neljä tuntia kuukaudessa. Jos rajaat huollon pois, kerro miten siitä ilmoitetaan ja aseta yläraja, muuten ”huollosta” tulee porsaanreikä.
Osittaiset katkot. Onko palvelu alhaalla, jos kirjautuminen toimii mutta kassa ei? Määrittele, mitkä komponentit kuuluvat sopimukseen ja lasketaanko yhden komponentin katko koko palvelun katkoksi.
Heikentynyt suorituskyky. Päätä, lasketaanko raja-arvoa hitaammat vastaukset epäonnistumisiksi. Jos sivun latautuminen kestää 30 sekuntia, käyttäjät pitävät sitä alhaalla olevana.
Syyt, joihin et voi vaikuttaa. Asiakkaan puolen verkko-ongelmat, väärinkäyttö ja ylivoimainen este rajataan yleensä pois. Oma hosting-palveluntarjoajasi ei yleensä ole poikkeus; asiakkaat ostivat palvelun sinulta.
Vähimmäiskesto. Jotkin SLA:t laskevat vain yli minuutin kestäneet tai useammalla kuin yhdellä tarkistuksella vahvistetut katkot, mikä vastaa tapaa, jolla valvonta vahvistaa virheet.
Sisäisesti on usein viisasta laskea suunniteltu huolto mukaan SLO:hon, vaikka SLA rajaisi sen pois. Käyttäjät eivät silti päässeet palveluun, ja SLO:n on tarkoitus heijastaa heidän kokemustaan.
Asiakkaille suunnatun SLA:n kirjoittaminen
Hyvä SLA on lyhyt ja täsmällinen. Sen pitää vastata kuuteen kysymykseen: mikä palvelu, mikä tavoite, miten mitataan, millä jaksolla, mitkä poikkeukset ja mitä tapahtuu, jos tavoite jää saavuttamatta. Tässä esimerkkiehto, jota voit muokata omiin tarpeisiisi:
Palvelu: Lumen Analytics -verkkosovellus osoitteessa app.lumenanalytics.io
ja julkinen API osoitteessa api.lumenanalytics.io.
Tavoite: 99,9 %:n käytettävyys kuukaudessa.
Mittaus: käytettävyys mitataan ulkoisilla tarkistuksilla minuutin välein.
Minuutti lasketaan katkoksi, kun palvelu palauttaa virheen (5xx)
tai ei vastaa lainkaan, ja toinen tarkistus vahvistaa tämän.
Poikkeukset: suunniteltu huolto, josta on ilmoitettu tilasivullamme
vähintään 72 tuntia etukäteen (enintään 4 tuntia kuukaudessa); ongelmat,
jotka johtuvat asiakkaan omasta verkosta tai järjestelmistä.
Hyvitykset: alle 99,9 %: 10 % kuukausimaksusta.
alle 99,0 %: 25 % kuukausimaksusta.
Asiakas pyytää hyvitystä 30 päivän kuluessa kuukauden päättymisestä.
Aseta SLA alemmaksi kuin mihin todellisuudessa yllät. Jos valvontahistoriasi näyttää 99,97 % viimeisen vuoden ajalta, 99,9 %:n lupaus on realistinen. Jos lupaat 99,99 %, koska se kuulostaa paremmalta, jokaisesta häiriöstä tulee sopimusongelma.
Pidä hyvitykset kohtuullisina ja hakemisen yksinkertaisena. Asiakkaat haluavat harvoin rahaa. He haluavat nähdä, että otat lupauksen vakavasti ja mittaat rehellisesti.
Mittaaminen ulkoisella valvonnalla
Omat lokisi eivät pysty mittaamaan katkoa, jossa palvelimesi ei koskaan saanut pyyntöä. DNS-virheet, vanhentuneet varmenteet, verkko-ongelmat ja kaatunut kuormantasaaja jättävät kaikki sisäiset mittarit hiljaisiksi. Siksi SLA-mittauksen pitää tulla ulkopuolelta, samaa reittiä kuin asiakkaatkin tulevat. Jos aihe on sinulle uusi, aloita oppaasta mitä käytettävyyden valvonta on ja miten se toimii.
Toimiva asetelma SLA-raportointiin:
Tarkista minuutin välein. Tarkistusväli määrää mittauksen tarkkuuden.
Vahvista jokainen virhe toisella tarkistuksella. Näin yksittäinen verkkohäiriö ei päädy katkolukuihisi.
Validoi sisältö. Tarkista sana tai kenttä, joka näkyy vain silloin, kun palvelu toimii.
Säilytä historia. Tarvitset häiriöiden alkamis- ja päättymisajat jokaiselta kuukaudelta, josta raportoit.
Julkaise se. Tilasivu, jolla on käytettävyyshistoria, näyttää asiakkaille samat luvut, jotka sinä näet.
Uptimecheck kattaa tämän: käytettävyyden valvonta jopa minuutin välein Tukholmasta, Lontoosta ja New Yorkista, SLA-raportit valvontakohteittain kuluvalta tai edelliseltä kuukaudelta tai viimeiseltä 7, 30 tai 90 päivältä tavoitettasi vasten, CSV-vienti kuukausittaista SLA-selvitystä varten sekä viikko- ja kuukausiraportit sähköpostiin. Samoihin valvontakohteisiin liitetty tilasivu näyttää asiakkaille lupauksesi taustalla olevan käytettävyyshistorian.
Käytettävyys on vain yksi luotettavuuden puoli. Se, kuinka nopeasti havaitset ja korjaat häiriöt, ratkaisee, kuinka paljon kukin niistä kuluttaa budjetista. Reagoinnin puolesta kerrotaan oppaassa MTTR, MTTA ja MTBF selitettynä.
Tarkistuslista: SLI:t, SLO:t ja SLA kuntoon
Listaa tärkeät käyttäjäpolut: kirjautuminen, kassa, pää-API.
Määrittele jokaiselle polulle yksi käytettävyys-SLI ja tarvittaessa yksi viive-SLI.
Mittaa kuukausi tai kaksi ennen kuin valitset tavoitteet.
Aseta SLO hieman alemmaksi kuin mihin tänään yllät, ja sopikaa virhebudjettikäytännöstä.
Aseta SLA SLO:n alapuolelle, selkein poikkeuksin ja kohtuullisin hyvityksin.
Mittaa ulkoisesti minuutin välein ja käy luvut läpi kuukausittain.
Mittaa lupaamaasi käytettävyyttä sieltä, missä asiakkaasi ovat. Kokeile Uptimecheckiä ilmaiseksi 14 päivää, luottokorttia ei tarvita.