DORA-mittarit ja CI/CD:n tila

Julkaisutiheys mittaa, kuinka usein organisaatiosi julkaisee koodia onnistuneesti tuotantoon. Se kertoo, kuinka nopeasti voit tuottaa arvoa käyttäjillesi.

Suurempi julkaisutiheys tarkoittaa usein pienempien ja vähemmän riskialttiiden muutosten julkaisemista, mikä nopeuttaa palautesyklejä ja jatkuvaa parantamista.

Voit seurata julkaisutiheyttä laskemalla tietyn ajanjakson (esimerkiksi päivän, viikon tai kuukauden) aikana tuotantoympäristöön onnistuneesti tehtyjen julkaisujen määrän.

• Esimerkki: Jos tiimisi julkaisee viikon aikana 15 kertaa, DF on 15 viikossa.
• Tavoite: Kasvata tätä lukua. Parhaiten suoriutuvat tiimit julkaisevat useita kertoja päivässä.

Muutosten läpimenoaika tarkoittaa aikaa, joka kuluu koodimuutoksen commitista siihen, että muutos toimii onnistuneesti tuotannossa. Se mittaa koko kehitysputken nopeutta.

Tämä mittari kuvaa kehitysprosessin tehokkuutta, mukaan lukien koodaus, testaus, katselmointi ja julkaiseminen.

LTFC alkaa, kun kehittäjä tekee commitin, ja päättyy, kun koodi on käyttäjien saatavilla. Se mitataan yleensä tunteina tai päivinä.

• Esimerkki: Maanantaiaamuna commitoitu ominaisuus, joka on tuotannossa tiistai-iltaan mennessä, tuottaa LTFC-arvoksi noin 36 tuntia.
• Tavoite: Lyhennä tätä aikaa. Lyhyempi läpimenoaika tarkoittaa nopeampaa toimitusta ja nopeampia iteraatioita.

Keskimääräinen palautumisaika (MTTR) mittaa aikaa, joka kuluu palvelun palauttamiseen tuotantohäiriön tai -vian jälkeen. Se kuvaa tiimisi kykyä reagoida ongelmiin ja palautua niistä.

Matala MTTR kertoo vahvasta toimintakyvystä häiriötilanteissa ja tehokkaista häiriötilanteiden hallintamenettelyistä.

MTTR lasketaan häiriön havaitsemishetkestä siihen asti, kunnes palvelu on täysin palautettu. Se mitataan yleensä minuutteina tai tunteina.

• Esimerkki: Jos sovelluskatkoksen tunnistamiseen, vianmääritykseen ja korjaamiseen kuluu kaksi tuntia, kyseisen häiriön MTTR on kaksi tuntia.
• Tavoite: Lyhennä tätä aikaa. Nopeampi palautuminen vähentää käyttäjiin kohdistuvia vaikutuksia ja liiketoiminnan häiriöitä.

Muutosten epäonnistumisaste on niiden tuotantoon tehtyjen muutosten prosenttiosuus, jotka heikentävät palvelua, edellyttävät palautusta aiempaan versioon tai vaativat muulla tavoin välittömiä korjaustoimia.

Tämä mittari on tärkeä julkaisuprosessin vakauden ja luotettavuuden ymmärtämiseksi. Korkea CFR viittaa testauksen tai julkaisemisen käytäntöjen ongelmiin.

CFR lasketaan jakamalla epäonnistuneiden julkaisujen määrä kaikkien tietyn ajanjakson julkaisujen määrällä ja kertomalla tulos sadalla.

• Esimerkki: Jos sadasta julkaisusta viisi aiheuttaa tuotantohäiriön, CFR on 5 %.
• Tavoite: Pidä luku mahdollisimman pienenä. Parhaiten suoriutuvilla tiimeillä CFR on usein alle 15 %.

Onnittelut! Olette tutustuneet neljään DORA-mittariin:

• Käyttöönottojen tiheys: Kuinka usein julkaisuja tehdään.
• Muutosten läpimenoaika: Kuinka nopeasti koodi siirtyy tuotantoon.
• Keskimääräinen palautusaika: Kuinka nopeasti ongelmat korjataan.
• Muutosvirheprosentti: Kuinka usein käyttöönotot aiheuttavat ongelmia.

Seuraamalla näitä mittareita saatte syvällistä tietoa CI/CD-prosessinne tilasta ja voitte edistää DevOps-käytäntöjen jatkuvaa parantamista.