MTTR (mean time to recovery tai repair, keskimääräinen palautumis- tai korjausaika) on keskimääräinen aika häiriön alusta siihen, kun palvelu toimii taas. MTTA (mean time to acknowledge, keskimääräinen kuittausaika) on keskimääräinen aika hälytyksestä siihen, kun joku vahvistaa ottaneensa asian hoitaakseen. MTBF (mean time between failures, keskimääräinen vikaväli) on keskimääräinen aika, jonka palvelu toimii normaalisti häiriöiden välillä. Yhdessä ne kuvaavat luotettavuutta: MTBF kertoo, kuinka usein jokin hajoaa, MTTA kuinka nopeasti reagoit ja MTTR kuinka kauan asiakkaat kärsivät.
Tämä opas käy läpi määritelmät, kaavat, numeroin lasketun esimerkin, kerättävät aikaleimat ja käytännön muutokset, jotka parantavat kutakin mittaria.
Mittarit ja mitä ne mittaavat
MTTR: neljä merkitystä, yksi lyhenne
MTTR on siteeratuin häiriömittari ja samalla sekavin, koska R tarkoittaa eri asioita sen mukaan, kuka sitä käyttää:
Mean time to repair (korjausaika): korjaustyön alusta siihen, kun korjaus on paikallaan. Yleinen laitteistossa ja kunnossapidossa.
Mean time to recovery tai restore (palautumisaika): katkon alusta siihen, kun palvelu toimii taas käyttäjille. Hyödyllisin versio verkkosivustoille ja API-rajapinnoille.
Mean time to respond (reagointiaika): hälytyksestä siihen, kun tiimi alkaa toimia. Lähellä MTTA:ta.
Mean time to resolve (ratkaisuaika): siihen asti, kun häiriö on kokonaan suljettu, mukaan lukien jatkotoimet, joilla sen toistuminen estetään.
Mikään niistä ei ole väärä. Tärkeintä on valita yksi, kirjata määritelmä ylös ja käyttää sitä johdonmukaisesti. Oman ”recovery”-lukusi vertaaminen jonkun toisen ”repair”-lukuun ei kerro mitään. Tässä artikkelissa MTTR tarkoittaa palautumisaikaa: siitä, kun palvelu hajosi, siihen, kun se toimi taas.
MTTD ja MTTA: reagointi ennen korjausta
MTTD (mean time to detect, keskimääräinen havaitsemisaika) on aika häiriön alusta siihen, kun valvonta hälyttää. MTTA on aika tuosta hälytyksestä siihen, kun ihminen kuittaa sen. Molemmat sisältyvät MTTR:ään, ja siksi ne ovat niin tärkeitä: kukaan ei voi korjata ongelmaa, josta ei ole kuullut.
MTBF: kuinka usein jokin hajoaa
MTBF on keskimääräinen toiminta-aika häiriöiden välillä. Mitä suurempi luku, sitä parempi. Sen sukulaista MTTF:ää (mean time to failure) käytetään asioille, jotka vaihdetaan korjaamisen sijaan, kuten levyille. Verkkopalveluissa tarvitset MTBF:n.
Kaavat
MTTD = häiriön alusta hälytykseen kulunut aika yhteensä / häiriöiden määrä
MTTA = hälytyksestä kuittaukseen kulunut aika yhteensä / häiriöiden määrä
MTTR = häiriön alusta palautumiseen kulunut aika yhteensä / häiriöiden määrä
MTBF = häiriötön toiminta-aika yhteensä / häiriöiden määrä
Käytettävyys = MTBF / (MTBF + MTTR)
Viimeinen rivi näyttää, miksi molemmat puolet ovat tärkeitä. Käytettävyyttä voi parantaa vähentämällä häiriöitä (suurempi MTBF) tai lyhentämällä niitä (pienempi MTTR). Lyhentäminen on usein paljon edullisempaa.
Laskuesimerkki
Tässä on esimerkkikuukausi verkkokaupalle, jossa sattui neljä häiriötä. Luvut on keksitty havainnollistamaan, mutta aikaleimat ovat sellaisia, joita mikä tahansa valvontatyökalu antaa.
HäiriöAlkoiHälytysKuitattuPalautuiHavaitseminenKuittausPalautuminenKassa 50303:1203:1303:1603:191 min3 min7 minAPI-aikakatkaisut10:0510:0610:0810:411 min2 min36 minKirjautumisvirheet14:3014:3114:4515:021 min14 min32 minHaku alhaalla22:5022:5122:5623:151 min5 min25 min
Sovelletaan nyt kaavoja:
MTTD = (1 + 1 + 1 + 1) / 4 = 1 minuutti.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 minuuttia.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 minuuttia.
MTBF: 30 päivän kuukaudessa on 43 200 minuuttia. Kun siitä vähennetään 100 minuuttia katkoja, jää 43 100. Jaettuna neljällä häiriöllä MTBF on 10 775 minuuttia, noin 7,5 päivää.
Käytettävyys = 10 775 / (10 775 + 25) = 99,77 %.
Kaksi asiaa erottuu. Kirjautumishäiriön 14 minuutin kuittaus nostaa MTTA:n noin 3 minuutista 6 minuuttiin, joten kannattaa kysyä, miksi kukaan ei tarttunut siihen hälytykseen. Lisäksi 99,77 %:lla tämä kauppa jää selvästi 99,9 %:n tavoitteesta, joka sallii vain 43 minuuttia kuukaudessa. Jos asetat tällaisia tavoitteita, lue SLA vs. SLO vs. SLI, niin näet, miten ne liittyvät toisiinsa.
Kuvittele nyt sama kuukausi viiden minuutin tarkistuksilla ja ilman vahvistusvaihetta. Havaitseminen voisi kestää yhden minuutin sijaan jopa viisi minuuttia, mikä lisää jokaiseen häiriöön jopa neljä minuuttia. MTTR nousee 25 minuutista jopa 29 minuuttiin, ennen kuin kukaan on tehnyt mitään toisin.
Mitkä aikaleimat kerätä
Tarvitset neljä aikaleimaa häiriötä kohden. Useimmat niistä saat suoraan valvonnasta:
Alku: ensimmäinen epäonnistunut tarkistus. Ulkoinen valvonta kirjaa sen, vaikka palvelimesi eivät lokittaisi mitään.
Hälytys: kun vika vahvistettiin ja ilmoitus lähti.
Kuitattu: kun joku ilmoitti hoitavansa asian. Jos sinulla ei ole päivystystyökalua, vastaus häiriökanavalla käy; merkitse aika muistiin. Uptimecheckissä kuittaat häiriön sovelluksessa tai Slack-sovelluksen kanssa Slackin painikkeella, ja aika tallentuu.
Palautui: ensimmäinen onnistunut tarkistus häiriön jälkeen, jolloin myös palautumisilmoitus lähtee.
Uptimecheckissä jokaisella häiriöllä on aikajana: milloin se alkoi, kenelle ja milloin hälytettiin, kuittaukset (myös Slackin painikkeella, kun käytät Slack-sovellusta), muistiinpanot ja palautuminen. MTTA ja MTTR lasketaan puolestasi, ja raportin CSV-vienti antaa taulukkolaskentaan jokaisen valvonnan häiriömäärän, katkoajan ja pisimmän häiriön. Kirjaa opitut asiat jälkianalyysiin.
Käytännön varoitus: keskiarvot piilottavat poikkeamat. Yhden kuuden tunnin häiriön ja yhdeksän minuutin mittaisen notkahduksen keskiarvo on noin 37 minuuttia, mikä ei kuvaa kumpaakaan. Katso keskiarvon rinnalla mediaania ja pisintä häiriötä, ja käy hitaimmat häiriöt läpi yksi kerrallaan.
Miten havaitsemisaikaa lyhennetään
Tarkista joka minuutti
Tarkistusväli on havaitsemisaikasi yläraja. Minuutin välein tehtävät tarkistukset kaikkeen, mikä tuo rahaa tai palvelee asiakkaita, on yksittäisistä parannuksista edullisin tapa lyhentää MTTR:ää. Käytä minuutin välein tehtävää käytettävyyden valvontaa jokaiselle kriittiselle sivulle ja päätepisteelle.
Tarkista, mikä hajoaa, eikä vain sitä, mikä latautuu
Häiriöt, joita valvonta ei näe, huomaavat asiakkaat, usein tunteja myöhemmin. Tarkista tärkeiden sivujen sisältö, valvo API-päätepisteitä, joista sovellukset ovat riippuvaisia, ja lisää ajastetuille töille heartbeat-valvonta. Jokainen häiriö, josta asiakas ilmoittaa ensin, on aukko valvonnassasi.
Miten kuittausaikaa lyhennetään
Lähetä vain vahvistettuja hälytyksiä
Hidas kuittaus on yleensä luottamusongelma. Jos puolet hälytyksistä on vääriä, ihmiset oppivat odottamaan ja katsomaan. Vahvista jokainen vika toisella tarkistuksella ennen hälytystä, ja poista valvonnat, jotka hälyttävät ilman, että kenenkään tarvitsee tehdä mitään. Oppaamme väärien hälytysten vähentämisestä kertoo yksityiskohdat.
Ohjaa hälytykset oikeaan kanavaan
Kello 03:12 tullut sähköposti luetaan kello 07:30. Lähetä kriittiset valvonnat kanavaan, joka tavoittaa päivystäjän puhelimen, ja tiimichattiin kaikille muille, ja pidä vähemmän kiireelliset valvonnat sähköpostissa. Uptimecheckissä valitset hälytyskanavat valvontakohtaisesti: sähköposti, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhookit ja push-ilmoitukset puhelimeen, kaikissa paketeissa. Eskalointi voi pidättää kanavaa 5–60 minuuttia ja hälyttää vain, jos katko jatkuu eikä kukaan ole kuitannut sitä.
Tee vastuut selviksi
Viidelle ihmiselle lähetettyä hälytystä ei usein kuittaa kukaan. Nimeä jokaiselle palvelulle yksi omistaja ja jokaiseen vuoroon yksi päivystäjä. Kaikki muut saavat tiedon, eivät vastuuta. Uptimecheckin päivystysvuoroissa ihmiset vuorottelevat, sairauspäiville ja vuoronvaihdoille on poikkeukset, ja push-hälytykset tavoittavat sen, joka päivystää juuri nyt.
Miten korjausaikaa lyhennetään
Kirjoita toimintaohjeet tunnetuille vioille
Useimmat häiriöt toistuvat. Levy täyttyy, worker-pooli loppuu, varmenteen uusiminen epäonnistuu. Lyhyt toimintaohje (runbook) jokaiselle valvonnalle muuttaa puoliunisen selvittelyn tarkistuslistaksi:
Toimintaohje: kassa palauttaa 503
1. Tarkista palvelimen kojelauta: CPU, muisti ja levy palvelimilla web-01 ja web-02.
2. Tarkista PHP-FPM:n tila: sudo systemctl status php8.3-fpm
3. Jos workerit ovat loppuneet: sudo systemctl restart php8.3-fpm
4. Etsi pitkään käynnissä olevia töitä: ps aux –sort=-%cpu | head
5. Vieläkö vika jatkuu 10 minuutin jälkeen? Eskaloi pääkehittäjälle.
Pidä toimintaohjeen linkki siellä, minne hälytys tulee, esimerkiksi kiinnitettynä häiriökanavalle, jotta se on yhden napautuksen päässä.
Pidä syy ja oire rinnakkain
Kun verkkosivuston tarkistus epäonnistuu, ensimmäinen kysymys on yleensä, onko palvelimelta loppunut muisti, CPU tai levytila. Kun palvelinmittarit ovat käytettävyystarkistusten vieressä, tämä vaihe lyhenee SSH-istunnosta yhteen silmäykseen.
Pidä palautus edellisaan versioon helppona
Moni häiriö alkaa julkaisusta. Jos edelliseen versioon palaaminen on yksi komento, palautuminen vie minuutteja. Jos se vaatii palaverin, se vie tunnin.
Päivitä tilasivua ajoissa
Tilasivu ei lyhennä itse katkoa, mutta se lyhentää sitä osaa, jonka asiakkaat kokevat pahimpana: epätietoisuutta. Se myös estää asiakastukea hukkumasta yhteydenottoihin sillä aikaa, kun tiimi korjaa ongelmaa. Valvontoihisi yhdistetty tilasivu näyttää vaikutuksen alaisen komponentin heti, kun häiriö avautuu; lisää lyhyt huomautus siitä, mitä teet ja milloin päivität seuraavan kerran.
MTBF:n parantaminen
Häiriöitä tulee vähemmän, kun opit niistä, joita on jo sattunut. Kirjoita jokaisen merkittävän häiriön jälkeen syyllistämätön jälkianalyysi, sovi yhdestä tai kahdesta toimenpiteestä ja seuraa niitä, kunnes ne on tehty. Muutamassa kuukaudessa samat viat lakkaavat toistumasta ja MTBF kasvaa.
Aloita mittaaminen oikeilla aikaleimoilla. Kokeile Uptimecheckiä ilmaiseksi 14 päivää ilman luottokorttia.