Virhebudjetti (error budget) on se määrä epäluotettavuutta, jonka SLO sallii tietyllä jaksolla: 100 % miinus tavoite. 99,9 %:n SLO 30 päivän jaksolla jättää virhebudjetiksi 43 minuuttia 12 sekuntia katkoa eli yhden epäonnistuneen pyynnön tuhannesta. Niin kauan kuin budjettia on jäljellä, tiimi voi julkaista ja ottaa riskejä. Kun se loppuu, luotettavuustyö menee edelle, kunnes jakso palautuu.
Tämä yksi sääntö muuttaa luotettavuustavoitteen päätöksiksi. Tämä opas näyttää, miten virhebudjetti lasketaan, minkä pitäisi kuluttaa sitä ja minkä ei, miten näet kulutuksen tahdin ja miten kirjoitat toimintaperiaatteet sitä hetkeä varten, kun budjetti loppuu.
Näin lasket virhebudjetin
Tarvitset kaksi asiaa: SLO:n eli itsellesi asettamasi luotettavuustavoitteen ja jakson, jolta sitä mitataan. Virhebudjetti on se, mitä tavoitteen ja täydellisyyden väliin jää.
Error budget = (100% − SLO) × window
99,9 %:n SLO:lla 30 päivän jaksolla (43 200 minuuttia): 0,1 % × 43 200 = 43,2 minuuttia eli 43 minuuttia 12 sekuntia. Taulukko näyttää saman laskun yleisille tavoitteille sekunteihin alaspäin pyöristettynä.
SLOBudjetti 30 päivässäBudjetti 90 päivässä99 %7 h 12 min21 h 36 min99,5 %3 h 36 min10 h 48 min99,9 min 12 s2 h 9 min 36 s99,95 min 36 s1 h 4 min 48 s99,99 %4 min 19 s12 min 57 s
SLA- ja käytettävyyslaskuri laskee tämän mille tahansa tavoitteelle ja jaksolle. Se käyttää keskimääräistä kuukautta (vuosi jaettuna 12:lla), joten 99,9 %:lle se näyttää 43 minuuttia 49 sekuntia yllä olevan 30 päivän luvun sijaan.
Aikaan vai pyyntöihin perustuva
Virhebudjetin voi laskea kahdella yksiköllä sen mukaan, mikä SLI SLO:si taustalla on:
Aikaan perustuva: katkominuutit ulkopuolelta tehtävillä tarkistuksilla mitattuna. Se on yksinkertainen, helppo selittää ja vastaa sitä, miten useimmat asiakkaiden SLA:t on kirjoitettu. 99,9 %:n kuukausittainen SLO sallii noin 43 minuuttia.
Pyyntöihin perustuva: epäonnistuneiden pyyntöjen osuus kuormantasaajan tai sovelluksen lokeista laskettuna. Kun pyyntöjä on 2 miljoonaa kuukaudessa ja tavoite 99,9 %, budjetti on 2 000 epäonnistunutta pyyntöä. Se painottaa ruuhkatunteja enemmän kuin hiljaisia, mikä on lähempänä käyttäjien kokemusta, mutta vaatii lokitusta, johon voit luottaa.
Monet tiimit käyttävät molempia: ulkoisiin tarkistuksiin perustuvaa aikabudjettia koko palvelulle ja pyyntöihin perustuvia budjetteja tärkeimmille päätepisteille, kuten kassalle tai API:lle.
Miksi virhebudjetti ylipäätään
Ilman budjettia luotettavuus on väittelyä. Tuotetiimi haluaa julkaista, kehitystiimi hidastaa, ja viimeinen puhuja voittaa. Budjetti korvaa väittelyn luvulla, josta molemmat osapuolet ovat sopineet etukäteen.
Se tekee 100 %:sta väärän tavoitteen. 100 %:n tavoite ei jätä budjettia lainkaan, joten jokainen julkaisu on riski, jota kukaan ei saa ottaa. Käyttäjät eivät omien Wi-Fi- ja mobiiliyhteyksiensä läpi edes erota 99,99 %:a 100 %:sta.
Se tekee riskistä käytettävän. Ison siirron, uuden alueen tai riskialttiin julkaisun voi ajoittaa niin, että se mahtuu tämän kuun jäljellä olevaan budjettiin.
Se päättää prioriteetit puolestasi. Kun budjetti on käytetty, toimintaperiaatteet kertovat, mitä seuraavaksi tapahtuu, joten kenenkään ei tarvitse voittaa palaveria saadakseen luotettavuustyön tiekarttaan.
Mikä kuluttaa budjettia
Kaikki, minkä SLI laskee huonoksi, kuluttaa budjettia. Päätä tämä SLO:ta kirjoittaessasi, älä häiriön aikana.
Vahvistetut katkot: palvelu ei vastannut, vastasi virheellä tai vastasi väärällä sisällöllä.
Hitaat vastaukset, jos SLI:si mukaan rajaa hitaampi pyyntö lasketaan epäonnistuneeksi. 30 sekuntia latautuva sivu on pystyssä, mutta ei käyttökelpoinen.
Epäonnistuneet julkaisut ja palautukset niiltä minuuteilta, joina käyttäjät näkivät virheitä.
Palveluntarjoajiesi katkot. Jos maksupalvelusi tai DNS-palveluntarjoajasi pettää, käyttäjäsi eivät silti pääse kassalle. Se kuluttaa budjettiasi, vaikka korjaus ei olekaan sinun käsissäsi, ja se on hyvä syy valvoa palveluita, joista olet riippuvainen.
Suunnitellut huollot vain, jos SLO niin sanoo. Monet tiimit jättävät ilmoitetut huoltoikkunat laskematta, kuukausikohtaisella ylärajalla.
Mikä ei saisi kuluttaa sitä: väärät hälytykset. Yksittäinen verkkohäiriön aiheuttama epäonnistunut tarkistus ei ole katko. Vahvista virhe toisella tarkistuksella ennen kuin lasket sen mukaan, tai budjettisi valuu ongelmiin, joita käyttäjät eivät koskaan nähneet.
Burn rate: kuinka nopeasti budjetti kuluu
Budjetti kertoo, kuinka paljon virheitä sinulla on varaa tehdä. Burn rate eli kulutusnopeus kertoo, kuinka nopeasti sitä käytät. Googlen SRE workbook määrittelee sen nopeudeksi, jolla palvelu kuluttaa virhebudjettia suhteessa SLO:hon (Alerting on SLOs).
Kulutusnopeudella 1 koko budjetti kuluu täsmälleen jakson lopussa.
Kulutusnopeudella 2 se kuluu puolessa jaksossa: 15 päivässä 30 päivän kuukaudesta.
Täydellinen katko kuluttaa 99,9 %:n SLO:ta vastaan nopeudella 1 000, koska jokainen katkominuutti on tuhatkertainen sallittuun tahtiin nähden. Kaksikymmentä minuuttia sitä kuluttaa 46 % 30 päivän budjetista.
Workbookin suosittelema lähtökohta 99,9 %:n SLO:lle hälyttää päivystäjän, kun 2 % 30 päivän budjetista kuluu tunnissa (kulutusnopeus 14,4) tai 5 % kuudessa tunnissa (kulutusnopeus 6), ja avaa tiketin, kun 10 % kuluu kolmessa päivässä (kulutusnopeus 1). Jokainen hälytys tarkistaa myös lyhyen ikkunan, joten se lakkaa laukeamasta pian sen jälkeen, kun ongelma on ohi.
Täydellisessä katkossa burn rate -hälytys ja tavallinen ”sivusto on alhaalla” -hälytys laukeavat suunnilleen samaan aikaan. Kulutusnopeus osoittaa arvonsa osittaisissa häiriöissä: kun 3 % pyynnöistä epäonnistuu tuntikausia, sivusto ei koskaan kaadu, mutta kuukauden budjetti on huomaamatta lopussa jo keskiviikkona.
Kirjoita virhebudjetin toimintaperiaatteet
Budjetti ilman toimintaperiaatteita on pelkkä luku kojelaudalla. Toimintaperiaatteet kertovat etukäteen, mitä tiimi tekee kullakin kulutustasolla. Sopikaa niistä tuote- ja kehitystiimin kesken yhdessä ja kirjatkaa ne paikkaan, josta molemmat löytävät ne. Google julkaisee esimerkin virhebudjetin toimintaperiaatteista, joka kannattaa lukea ennen omien kirjoittamista.
Yksinkertainen pohja aloittamiseen
Budjettia jäljellä: julkaise normaalisti. Suunniteltu riskialtis työ etenee.
Puolet käytetty ennen jakson puoliväliä: päivystyksen vetäjä käy läpi tähänastiset häiriöt ja nimeää suurimman syyn.
Budjetti käytetty: vain bugikorjaukset ja luotettavuustyö julkaistaan, kunnes jakso palautuu. Riskialttiit siirrot odottavat.
Yksittäinen häiriö käytti yli viidesosan budjetista: siitä kirjoitetaan jälkianalyysi, jossa on vähintään yksi toimenpide.
Poikkeuksista päättävät nimetyt henkilöt, esimerkiksi kehitysjohtaja ja tuotejohtaja yhdessä, ja päätökset kirjataan.
Raja-arvot ovat esimerkkejä, eivät sääntöjä. Valitse sellaiset, joita tiimisi oikeasti noudattaa. Toimintaperiaatteet, joista lipsutaan heti ensimmäisellä kerralla, ovat huonommat kuin ei mitään, koska ne opettavat kaikille, ettei SLO:lla ole väliä.
Yleiset virheet
SLO asetetaan samaksi kuin SLA. Silloin budjetti loppuu samalla hetkellä, kun olet asiakkaille velkaa hyvityksiä. Pidä SLO tiukempana kuin SLA, niin sisäinen hälytys soi ensin. SLA vs. SLO vs. SLI selittää, miten nämä kolme liittyvät toisiinsa.
Liian lyhyt jakso. Viikkobudjetti nollautuu ennen kuin huono viikko ehtii muuttaa mitään. Tavallinen valinta on 30 päivää, liukuvana tai kalenterikuukausittain.
Unohdetaan, miten jakso nollautuu. Kalenterikuukausi alkaa puhtaalta pöydältä 1. päivä, joten huono viimeinen viikko unohtuu päivissä. Liukuva 30 päivän jakso muistaa sen kuukauden, mikä on tiukempaa ja reilumpaa.
Katsotaan vain kokonaismäärää. Yksi 40 minuutin katko ja neljäkymmentä minuutin katkoa kuluttavat saman budjetin, mutta jälkimmäinen haittaa käyttäjien työtä joka päivä. Seuraa budjetin rinnalla häiriöiden määrää ja MTTR:ää.
Mitataan vain sisältä. Palvelimen lokit eivät voi kirjata pyyntöjä, jotka eivät koskaan saapuneet. Vanhentunut varmenne tai rikkinäinen DNS-tietue kuluttaa budjettia, jonka vain ulkoinen tarkistus näkee.
Aikaan perustuvan virhebudjetin seuranta Uptimecheckillä
Uptimecheck antaa luvut, joita aikaan perustuva budjetti tarvitsee. Käytettävyyden valvonta tarkistaa jopa minuutin välein Tukholmasta, Lontoosta ja New Yorkista ja vahvistaa jokaisen epäonnistuneen tarkistuksen toisesta sijainnista, joten yksittäinen häiriö ei kuluta budjettia. Huoltoikkunat ja keskeytetty aika eivät heikennä käytettävyyslukua.
Raportit näyttävät käytettävyyden, katkot ja häiriöt valvontakohtaisesti tältä kuulta, viime kuulta tai viimeisiltä 7, 30 tai 90 päivältä SLA-tavoitetta 99 %, 99,5 %, 99,9 %, 99,95 % tai 99,99 % vasten, ja ne voi ladata CSV-tiedostona. Jäljellä oleva budjetti on sallittu katkoaika miinus raportin katkoaika. Katso näin teet raportteja SLA-tavoitetta vasten.
Häiriöt säilyttävät todisteet ja aikajanan jokaisesta tarkistuksesta, hälytyksestä ja muistiinpanosta, eli juuri sen, mitä jälkianalyysi tarvitsee. Katso häiriöiden hallinta.
Huoltoikkunat pitävät suunnitellun työn poissa luvuista. Katso näin ajoitat huoltoikkunat.
Jos haluat hinnoitella käyttämäsi budjetin, kokeile katkon kustannuslaskuria. Jos haluat nähdä, mitä kukin tavoite sallii, lue mitä 99,9 %:n käytettävyys tarkoittaa.
Tiedä, paljonko budjettia on jäljellä, ennen kuin kuukausi on ohi. Kokeile Uptimecheckiä ilmaiseksi 14 päivää, luottokorttia ei tarvita.