DORA metrikalari: DevOps samaradorligini qanday o‘lchash mumkin
Asoslar3 daqInnovialabs tahririyati
Qisqacha
DORA metrikalari dasturiy ta’minot yetkazib berishni to‘rtta raqam bilan o‘lchaydi: qanchalik tez-tez deploy qilasiz, commit prodga qanchalik tez yetadi, o‘zgarishlar prodni qanchalik tez-tez buzadi va qanchalik tez tiklanasiz; birgalikda ular tezlikni ham, barqarorlikni ham ko‘rsatadi.
Qisqa javob
DORA metrikalari DevOps Research and Assessment tadqiqot dasturidan kelib chiqqan va jamoa dasturiy ta’minotni qanchalik yaxshi yetkazib berishini ko‘rsatadi. Ular to‘rtta:
- Deployment frequency — o‘zgarishlarni prodga qanchalik tez-tez chiqarasiz.
- Lead time for changes — commit’dan prodgacha qancha vaqt o‘tadi.
- Change failure rate — deploylarning qancha ulushi tuzatish, orqaga qaytarish yoki hotfix talab qiladigan nosozlikka olib keladi.
- Time to restore service (failed deployment recovery time deb ham ataladi) — bunday nosozlikdan keyin tiklanish uchun qancha vaqt kerak.
Dastlabki ikkitasi tezlikni, oxirgi ikkitasi barqarorlikni o‘lchaydi. Asosiy g‘oya: kuchli jamoalar ikkala tomonni bir vaqtda yaxshilaydi, birini ikkinchisi uchun qurbon qilmaydi.
Har bir metrika nimani ko‘rsatadi
| Metrika | Qaysi savolga javob beradi | Odatda uni nima yaxshilaydi |
|---|---|---|
| Deployment frequency | Kichik o‘zgarishlarni tez-tez chiqara olamizmi? | Kichik pull request’lar, avtomatik pipeline, feature flag’lar |
| Lead time for changes | Tayyor o‘zgarish qancha kutadi? | Tez review, tez testlar, qo‘lda tasdiqlash navbatlarining yo‘qligi |
| Change failure rate | Relizlar foydalanuvchilarga qanchalik tez-tez zarar yetkazadi? | Testlar, kod review, bosqichma-bosqich chiqarish, monitoring |
| Time to restore | Prodni qanchalik tez tuzatamiz? | Oson rollback, alertlar, runbook’lar, observability |
Ularni Git va CI’dan qanday yig‘ish mumkin
Boshlash uchun alohida platforma shart emas: ma’lumotlarning katta qismi allaqachon vositalaringizda bor.
Deployment frequency
- CI’da (GitHub Actions, GitLab CI va shunga o‘xshashlar) prodga deploy job’ining muvaffaqiyatli ishga tushishlarini sanang.
- Yoki reliz teglarini yoki Git-xostingning deployments API orqali yozilgan deploylarni sanang.
Lead time for changes
- Har bir deploy uchun unga kirgan commit’larni oling.
- Lead time = deploy vaqti minus commit vaqti (yoki qulay bo‘lsa, pull request ochilgan vaqt).
- O‘rtacha emas, medianadan foydalaning: bir nechta eski commit o‘rtacha qiymatni buzadi.
Change failure rate
- Nima nosozlik hisoblanishini kelishib oling: rollback, hotfix, reliz bilan bog‘liq insident.
- Ularni bir xil belgilang: insidentdagi yorliq,
hotfixbranch prefiksi, revert commit. - Ulush = muvaffaqiyatsiz deploylar, davr ichidagi barcha deploylarga bo‘lingan.
Time to restore
- Insidentlarni insident trekeri yoki alerting tizimidan oling.
- Vaqt = bartaraf etilgan payt minus boshlangan payt (agar boshlanish noma’lum bo‘lsa, aniqlangan payt).
Reliz commit’larini vaqti bilan olishning oddiy usuli:
git log --format='%H %cI' v1.4.0..v1.5.0
Har bir commit vaqtini v1.5.0 deployi tugagan payt bilan solishtiring va relizlar bo‘yicha medianani oling.
Nimadan boshlash kerak
- Avval ta’riflarni kelishib oling: «prod» nima, «nosozlik» nima, insident qachon boshlanadi.
- Xulosa chiqarishdan oldin bir necha hafta ma’lumot yig‘ing.
- Boshqa kompaniyalar bilan taqqoslashga emas, o‘z jamoangiz dinamikasiga qarang.
- Bir vaqtda bitta tor joy ustida ishlang. Agar lead time review’lar kunlab kutgani uchun katta bo‘lsa, pipeline’ni emas, review’ni yaxshilang.
- Raqamlarni jamoa bilan retrospektivalarda muhokama qiling.
Metrikalarni o‘yinga aylantirmang
Metrika maqsadga aylanganda, odamlar natijani emas, raqamni optimallashtira boshlaydi. DORA’ni «sun’iy oshirish»ning odatiy usullari:
- Chastota uchun bitta o‘zgarishni ko‘plab mayda deploylarga bo‘lish.
- Nosozliklar ulushi pastroq ko‘rinishi uchun rollback va hotfix’larni nosozlik sifatida yozmaslik.
- Tiklanish vaqti chiroyli ko‘rinishi uchun insidentlarni muddatidan oldin yopish.
- Turli mahsulotli jamoalarni solishtirish va «sekin»ini jazolash.
Bunga qanday yo‘l qo‘ymaslik kerak:
- DORA metrikalarini hech qachon alohida xodimlarni baholash uchun ishlatmang.
- Har doim to‘rttasiga birga qarang: barqarorliksiz tezlik — xavotirli signal.
- Raqamlarni sifat signallari bilan to‘ldiring: dasturchilar fikri, mijozlar shikoyatlari, insidentlar tahlili.
- Hech kim raqamlarni qo‘lda kiritmasligi uchun yig‘ishni avtomatlashtiring.