Availability — tizimning kerakli vaqtda foydalanishga yaroqli va belgilangan xizmatni bajara olish darajasidir. U odatda ma’lum davrdagi muvaffaqiyatli xizmat vaqti yoki so‘rovlar ulushi bilan ifodalanadi. “Tizim ishlayapti” ta’rifi foydalanuvchi nuqtayi nazaridagi aniq SLI va maqsad SLO bilan belgilanmasa, availability raqami mazmunsiz bo‘lishi mumkin.
O‘lchash usullari
Vaqtga asoslangan formula ko‘pincha uptime / total time shaklida yoziladi. So‘rovga asoslangan o‘lchov muvaffaqiyatli va yetarlicha tez javoblar ulushini hisoblaydi. Qisman ishlashda, masalan, faqat checkout buzilib, katalog ishlaganda qaysi user journey muhimligi alohida ko‘rsatiladi.
99.9 foiz va 99.99 foiz o‘rtasidagi farq kichik ko‘rinsa ham ruxsat etilgan downtime keskin kamayadi. O‘lchov oynasi oy, chorak yoki rolling period bo‘lishi natijaga ta’sir qiladi. Planned maintenance hisobdan chiqariladimi, bu ham SLO hujjatida aniq yoziladi.
Ishonchlilik modellari
Availability ko‘pincha MTBF va MTTR bilan bog‘lanadi: nosozlik kamroq bo‘lishi va tiklanish tezroq kechishi xizmat vaqtini oshiradi. Serial bog‘langan komponentlardan bittasi ishlamasa butun xizmat to‘xtashi mumkin. Parallel redundant komponentlar esa bitta nosozlikni ko‘tara oladi.
Redundancy faqat nusxa soni emas. Ikki server bir rack, switch, quvvat yoki database’ga bog‘langan bo‘lsa umumiy failure domain qoladi. Zone va region darajasidagi dizayn biznes talabiga mos ravishda mustaqil tarmoq, quvvat va boshqaruv yo‘lini hisobga oladi.
Amaliy mexanizmlar
Health check nosog‘lom instance’ni load balancerdan chiqaradi. Failover trafficni standby yoki boshqa replika tomon yo‘naltiradi. Graceful degradation ikkilamchi funksiyani o‘chirib, asosiy xizmatni saqlaydi. Queue qisqa dependency uzilishini yutishi mumkin, lekin backlog uchun limit va recovery rejasi bo‘ladi.
Timeout, retry va circuit breaker ehtiyotkor sozlanadi. Haddan tashqari retry nosozlik paytida yukni ko‘paytiradi. Idempotency qayta yuborilgan yozuvning takroriy ta’sirini cheklaydi. Deployment canary yoki rolling shaklda bajarilib, xato metrikada avtomatik to‘xtatiladi.
Data availability
Xizmat javob berishi bilan ma’lumot to‘g‘riligi bir xil emas. Replication lag sabab eski ma’lumot ko‘rinishi, split-brain esa qarama-qarshi yozuv yaratishi mumkin. Consistency va availability o‘rtasidagi qaror network partition sharoitida aniq siyosat talab qiladi.
Backup availabilityni to‘g‘ridan-to‘g‘ri ta’minlamaydi, lekin katta buzilishdan tiklanish uchun zarur. RTO qancha vaqtda, RPO esa qancha ma’lumot yo‘qotish bilan tiklanish maqsadini bildiradi. Restore muntazam sinovdan o‘tmasa backupning mavjudligi amaliy kafolat emas.
Operatsion boshqaruv
Synthetic probe tashqaridan user journey’ni, real-user monitoring haqiqiy tajribani, ichki telemetry esa sababni kuzatadi. Error budget SLOdan qolgan ruxsat etilgan xatoni release tezligi bilan muvozanatlashtiradi. Incident review blame emas, aniqlash va tiklanish tizimini yaxshilashga qaratiladi.
Bog‘liq xizmatlar ta’siri
Bir user request ketma-ket beshta dependency’ning barchasiga muhtoj bo‘lsa, end-to-end availability har bir komponent ko‘rsatkichidan past bo‘lishi mumkin. Parallel redundant yo‘llar aksincha umumiy natijani oshiradi, lekin faqat failure’lar mustaqil bo‘lsa. Shared DNS, identity provider yoki control plane ko‘plab xizmat uchun yashirin umumiy nuqtaga aylanadi. Dependency budget har jamoaga kerakli SLOni ajratadi. Cache yoki stale read orqali dependency uzilganda qisman xizmat ko‘rsatish mumkin, ammo foydalanuvchiga ma’lumot eskiligi va cheklangan funksiya aniq ko‘rsatiladi.
Status page foydalanuvchi ta’sirini ochiq ko‘rsatadi, ammo ichki component health bilan aynan tenglashtirilmaydi; tashqi probe haqiqiy xizmat yo‘lini tekshiradi.
Bog‘liq tushunchalar
High availability, SLO, Error budget, MTTR, Fault tolerance, Disaster recovery