Nafis degradatsiya

1) yondashuvning mohiyati

Zerikarli degradatsiya - bu tizimning resurslar yetishmasligi, qaramlik buzilishi yoki yuklamaning eng yuqori cho’qqilarida boshqariladigan sodda, ammo foydali rejimga o’tishidir. Maqsad - ikkinchi darajali imkoniyat va sifatni qurbon qilib, foydalanuvchi uchun qadriyatni va platformaning barqarorligini saqlab qolishdan iborat.

• Bashorat qilinishi mumkin: oldindan belgilangan stsenariylar va degradatsiya «zinapoyalari».
• Shikastlanish radiusini cheklash: fich va qaramliklarni izolyatsiya qilish.
• Kuzatish: metrika, loglar va trasirovkalar «tanazzulning qaysi darajasi faol va nima uchun».
• Qaytaruvchanlik: tezda normal holatga qaytish.

2) Prinsiplar va chegaralar

1. Asosiy narsani saqlab qolish: asosiy SLA/SLO (masalan, «sotib olish», «login», «qidirish») - ikkinchi darajali (avatarlar, tavsiyalar, animatsiyalar) dan ustun.

• Xavfsizlik, to’lovlar, huquqlar - fail-closed (qoidabuzarlikdan ko’ra rad etish yaxshiroqdir).
• Folback bilan joʻnatiladigan kontent, maslahatlar, avatarlar - fail-open.
• 3. Vaqtinchalik byudjetlar: taymautlar yuqoridan pastga (mijoz
• 4. Qiymat nazorati: degradatsiya xatolarni shunchaki «yashirish» emas, balki CPU/IO/tarmoq isteʼmolini kamaytirishi kerak.

3) Degradatsiya darajalari

3. 1 Mijoz/UX

Skeletons/pleysholderlar va ikkinchi darajali vidjetlarni «dangasa» yuklash.
Partial UI: tanqidiy bloklar yuklanadi, ikkilamchi bloklar yashiriladi/soddalashtiriladi.
Mijoz tomonidagi kesh: last-known-good (LKG) «maʼlumotlar eskirishi mumkin».
Oflayn rejim: qaytadan buyruqlar navbati (idempotentlik!).

3. 2 Edge/CDN/WAF/API-shlyuz

stale-while-revalidate: kesh beramiz, fon yangilaymiz.
Rate limiting & load shedding: ortiqcha yuklashda orqa fon/anonim trafikni tashlaymiz.
Geofence/muvozanatli routing: trafik eng yaqin sog’lom mintaqaga olib ketilmoqda.

3. 3 Servis qatlami

Partial response: maʼlumotlarning bir qismini +’warnings’ga qaytaramiz.
Read-only rejimi: mutatsiyalarni vaqtincha taqiqlash (bayroqlar).
Brownout: resurslarni talab qiladigan fazalarni vaqtincha uzib qo’yish (tavsiyalar, boyitish).
Adaptive concurrency: parallellikni dinamik ravishda kamaytiramiz.

3. 4 Ma’lumotlar/striming

TTL bilan haqiqat manbai sifatida kesh (vaqtincha): «Hech narsadan yaxshiroq».
Model/algoritmlarning aniqligi pasaygan (fast path vs accurate path).
Defer/queue: ogʻir vazifalarni fonga koʻchirish (outbox/job queue).
Ustuvor navbatlar: tanqidiy voqealar - alohida sinfda.

4) Degradatsiya «zinapoyalari» (playbooks)

• L0 (norma) → L1: shaxsiylashtirish va bannerlarni yashirish → L2: sinonimlarni o’chirish/fazzi-qidirish → L3: javob va vaqtni 300 ms gacha cheklash → L4: 5 daqiqa keshdan natijalarni berish → L5: «read-only & cached only» + qayta hisoblash uchun so’rovlar navbati.

• Triggerlar: CPUni ortiqcha yuklash> 85% p95> maqsadli, xatolar> chegara, lag Kafka> chegara, qaramlik fap.
• Amallar: X bayrogʻini yoqish, concurrency ni N ga tushirish, Y manbasini keshga oʻtkazish.
• Chiqish mezonlari: 10 daqiqa yashil metriklar, resurslar bo’yicha zaxiralar.

5) Qarorlar qabul qilish siyosati

5. 1 Xato budjet va SLO

brownout/shedding triggeri sifatida error-budget burn rate’dan foydalaning.
Siyosat: «agar burn-rate> 4 × 15 daqiqa ichida - L2 degradatsiyani yoqish».

5. 2 Admission control

Kelayotgan RPSni p99 ni kafolatlash va navbatlarning qulashiga yo’l qo’ymaslik uchun tanqidiy yo’llarda cheklaymiz.

5. 3 Ustuvorlik

Sinflar: interactive> system> background.
Per-tenant ustuvorliklar (Gold/Silver/Bronze) va adolat (fair share).

6) Patternlar va realizatsiya qilish

6. 1 Load shedding (server)

So’rovlarni ular barcha resurslarni egallashidan oldin tashlang.
’429 ’/’ 503’ s’Retry-After’ni qaytaring va siyosatni tushuntiring (mijozlar uchun).

Envoy (adaptive concurrency + circuit breaking)

yaml typed_extension_protocol_options:
envoy. filters. http. adaptive_concurrency:
"@type": type. googleapis. com/envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency gradient_controller_config:
sample_aggregate_percentile: 90 circuit_breakers:
thresholds:
- max_requests: 2000 max_pending_requests: 500 max_connections: 1000

6. 2 Brownout (vaqtincha soddalashtirish)

G’oya: resurslar tugayotganda «yorqinlik» ni (qiymat) kamaytirish.

kotlin class Brownout(val level: Int) { // 0..3 fun recommendationsEnabled() = level < 2 fun imagesQuality() = if (level >= 2) "low" else "high"
fun timeoutMs() = if (level >= 1) 150 else 300
}

6. 3 Partial response va ogohlantirishlar

json
{
"items": [...],
"degradation": {
"level": 2,
"applied": ["cache_only", "no_personalization"],
"expiresAt": "2025-10-31T14:20:00Z"
}
}

6. 4 Chekkada stale-while-revalidate (Nginx)

nginx proxy_cache_valid 200 10m;
proxy_cache_use_stale error timeout http_500 http_502 http_504 updating;
proxy_cache_background_update on;

6. 5 Read-only (Kubernetes + bayroq)

yaml apiVersion: v1 kind: ConfigMap data:
MODE: "read_only"

The code should check MODE and block mutations with a friendly message.

6. 6 Kafka: backpressure va navbat sinflari

Heavy-konsumerlarni kichikroq’max’ga oʻtkazing. poll. records’, ishlab chiqarish batch-i cheklang.
Topiklar/kvotalar boʻyicha «tanqidiy» va «bulk» hodisalarini ajrating.

6. 7 UI: graceful fallback

Og’ir vidjetlarni yashiring, kesh/skeletni ko’rsating va eskirgan ma’lumotlarni aniq belgilang.

7) Konfiguratsiya namunalari

7. 1 Istio: outlier + ustuvor pullar

yaml outlierDetection:
consecutive5xx: 5 interval: 10s baseEjectionTime: 30s maxEjectionPercent: 50

7. 2 Nginx: birinchi marta pichoq ostidagi fon trafigi

nginx map $http_x_priority $bucket { default low; high high; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s;
limit_req_status 429;

server {
location /api/critical/ { limit_req zone=perip burst=40 nodelay; }
location /api/background/ {
limit_req zone = perip burst = 5 nodelay; # stricter
}
}

7. 3 Feature flags / kill-switches

Dinamik konfiguratsiyada saqlang (ConfigMap/Consul), yangilanish chiqarilmasdan.
Per-fich va global bayroqlarni baham ko’ring.

8) Kuzatish

8. 1 Metrika

’degradation _ level {service}’ - joriy daraja.
’shed _ requests _ total {route, reason}’ - qancha va nima uchun tashlangan.
’stale _ responses _ total’ - qancha kesh berilgan.
`read_only_mode_seconds_total`.
`brownout_activations_total{feature}`.
Noto’g "ri budjet: burn-rate, SLO buzilishlari ulushi.

8. 2 Treysing

Span atributlari:’degraded = true’,’level = 2’,’reason = upstream _ timeout’.
Retrajlar/xedged-soʻrovlar orasidagi linklar.

8. 3 Logi/alertlar

Tanazzul darajasini oʻzgartirish sabablari va egasi bilan almashtirish hodisalari.
Alertlar «yopishish» darajasida (tanazzul juda uzoq davom etadi).

9) Xavflarni boshqarish va xavfsizlik

Autentifikatsiya/avtorizatsiya/ma’lumotlar yaxlitligini buzmang: rad etish yaxshiroqdir.
PII kamuflyaj har qanday rejimlarda saqlanadi.
Moliya/to’lovlar: faqat idempotent operatsiyalari, qat’iy taymautlar va qaytarmalar; shubha tug’ilganda - read-only/hold.

10) Anti-patternlar

Foydalanuvchiga maslahatsiz va telemetriyasiz jim degradatsiya.
Load shedding va qisqa taymautlar o’rniga retray bo’ronlar.
Segmentatsiyasiz global «kesuvchilar» - ulkan blast radius.
Prod va engillashtirilgan yoʻllarni bitta kesh/navbatda aralashtirish.
Abadiy tanazzul: brownout «yangi norma» sifatida, unutilgan chiqish mezonlari.
Stale-write: eskirgan maʼlumotlar asosida yozishga urinishlar.

11) Joriy etish chek-varaqasi

• Qiymatning yadrosi va tanqidiy foydalanuvchi stsenariylari aniqlandi.
• Triggerlar va chiqish joylari bo’lgan servislar/uylar bo’yicha degradatsiya zinapoyalari tuzilgan.
• Taymautlar/cheklovlar va server-side load shedding joriy etildi.
• rate limits va ustuvor trafik sinflari moslashtirilgan.
• Partial response, read-only, stale-while-revalidate amalga oshirildi.
• Audit bilan integratsiyalashgan feature flags/kill-switches.
• Degradatsiya darajalari va sabablari uchun metriklar/treysing/alertlar.
• Ortiqcha yuk/nosozliklar simulyatsiyasi bilan muntazam game day mashqlari.
• SLO va error-budget → degradatsiya siyosati hujjatlashtirilgan.

12) FAQ

Q: Qachon brownout, qachon shedding?
A: Agar maqsad - so’rovlar narxini rad etmasdan kamaytirish bo’lsa - brownout. Agar maqsad tizimni himoya qilish bo’lsa, hatto soddalashtirish ham yordam bermasa - kirish shedding.

Q: Buzilish haqida foydalanuvchiga xabar berish kerakmi?
A: Tanqidiy ssenariylar uchun - ha («cheklangan rejim» nishoni). Shaffoflik qoʻllab-quvvatlash va norozilikni kamaytiradi.

Q: Keshni haqiqat manbai qilish mumkinmi?
A: Vaqtincha - ha, aniq SLA va eskirish belgilari bilan. Mutatsiyalar uchun - taqiqlangan.

Q: Qanday qilib retrajlarni «buzilmagan» qilish mumkin?
A: Qisqa taymautlar, jitter bilan eksponensial backoff, idempotentlik va urinishlar limiti; retrayt faqat xavfsiz operatsiyalardir.

13) Yakunlar

Zerikarli degradatsiya - bu me’moriy kontrakt va metrika va noto’g "ri byudjet signallari bo’yicha qo’shiladigan boshqariladigan ish rejimlari to’plami. To’g’ri ishlab chiqilgan zinapoyalar, qat’iy taymautlar va shedding, kesh-folbeklar va brownout, shuningdek, kuchli kuzatuv - va platformaniz bo’ron paytida ham foydali va tejamkor bo’lib qoladi.