Resilience Engineering — Senior chuqurlik

Sliding window — qaror qanday qilinadi

Breaker "ochilishni" har xatoda emas, oyna (sliding window) statistikasi asosida hal qiladi: oxirgi N chaqiruv (count-based) yoki oxirgi T vaqt (time-based) ichidagi xato foizi. Bu tebranishni silliqlaydi.

# Circuit breaker ichki sozlamalari (resilience4j uslubi)
slidingWindowType: COUNT_BASED         # oxirgi N chaqiruv oynasi (yoki TIME_BASED)
slidingWindowSize: 100                  # 100 ta chaqiruv kuzatiladi
minimumNumberOfCalls: 20                # kamida 20 ta bo'lmasa OCHILMAYDI (kam namunaga trip yo'q)
failureRateThreshold: 50                # 50% xato -> OPEN
slowCallRateThreshold: 80               # 80% "sekin" ham -> OPEN (xato bo'lmasa ham!)
slowCallDurationThreshold: 2s           # 2s dan uzoq = "sekin"
waitDurationInOpenState: 10s            # OPEN'da 10s kutadi -> keyin HALF-OPEN
permittedNumberOfCallsInHalfOpenState: 5 # HALF-OPEN'da 5 ta sinov

Adaptiv timeout

Belgilangan raqam o‘rniga — kuzatilgan kechikishga qarab: masalan, timeout = p99 × 1.5. Xizmat sekinlashsa, timeout ham moslashadi. Bu normal o‘zgaruvchanlikni kesmasdan, haqiqiy osilishni ushlaydi.

Deadline propagation — behuda ishni yo‘qotish

Yechim: so‘rovga umumiy deadline (absolyut vaqt) ber; har hop qolgan vaqtni hisoblab, undan ko‘p ishlamaydi va keyingisiga uzatadi:

// DEADLINE PROPAGATION: umumiy muddat; har hop QOLGANini uzatadi
async function callWithDeadline(deadline: number) {   // deadline = absolyut vaqt (ms)
  const remaining = deadline - Date.now();
  if (remaining <= 0) throw new DeadlineExceeded();    // vaqt tugadi -> ishlamay xato ber

  return this.http.get(url, {
    timeout: remaining,                                // qolgan vaqtdan ko'p kutma
    headers: { "x-deadline": String(deadline) },       // keyingi xizmat ham QOLGANini biladi
  });
}
// -> hech bir xizmat "chaqiruvchi allaqachon voz kechgan" so'rovga ishlamaydi (behuda ish yo'q)

Retry budget — bo‘ronni matematik to‘xtatish

"3 marta retry" yetarli emas: ommaviy nosozlikda har mijoz 3x yuboradi → yuk 4x. Retry budget — retry’larni umumiy trafikning foizi sifatida cheklaydi (masalan, 10%). Byudjet tugasa — retry qilinmaydi, tizim himoyalanadi:

// RETRY BUDGET: retry'lar umumiy trafikning ~10%idan oshmasin (retry storm'ni to'sadi)
if (this.retryBudget.tryAcquire()) {        // token bucket: har request byudjet qo'shadi
  await retryWithBackoff(() => call());
} else {
  throw err;                                // byudjet tugadi -> retry YO'Q (tizimni himoya)
}

Hedged requests — tail latency’ga qarshi

p99 kechikish odatda bitta sekin replika tufayli. Hedged (backup) request: birinchi so‘rov p95’dan sekinlashsa — ikkinchisini boshqa replikaga yuborasan, qaysi biri oldin kelsa — o‘shani olasan:

// HEDGED REQUEST: birinchi so'rov p95'dan sekinlashsa -> ikkinchisini boshqa replikaga
async function hedged<T>(call: () => Promise<T>): Promise<T> {
  const first = call();
  const backup = delay(P95_MS).then(() => call());   // p95'dan keyin ikkinchi urinish
  return Promise.race([first, backup]);              // qaysi biri OLDIN kelsa -> o'sha
}
// tail latency (p99)'ni keskin kamaytiradi; qo'shimcha yuk CHEGARALANGAN (faqat sekinlarga)

Bulkhead o‘lchamlash — Little qonuni

"Nechta bir vaqtli chaqiruvga ruxsat berish?" tasodifan tanlanmaydi. Little qonuni: concurrency = throughput × latency. Agar bog‘liqlik 100 req/s ni 50ms’da bajarsa — ~5 bir vaqtli slot yetadi. Buni bilib, semaphore o‘lchamini to‘g‘ri qo‘yasan:

// BULKHEAD (semaphore): har bog'liqlikka bir vaqtda ruxsat etilgan max chaqiruv
// O'LCHAM (Little's Law):  concurrency = throughput * latency
//   masalan 100 req/s * 0.05s = 5  ->  ~5-10 slot yetarli
const paymentBulkhead = new Semaphore(10);   // to'lovga bir vaqtda max 10 chaqiruv

const ok = await paymentBulkhead.tryAcquire(50 /*ms kut*/);
if (!ok) throw new BulkheadFullException();   // to'lgan -> DARHOL rad (fail fast)
try { return await this.payment.charge(); }
finally { paymentBulkhead.release(); }

Backpressure — "sekinlash" signali

Oddiy rate limit yetarli emas

Qat’iy "sekundiga 1000 so‘rov" cheklovi qo‘pol: yuk past bo‘lsa ham keraksiz rad etadi, tizim allaqachon cho‘kayotgan bo‘lsa — kech qoladi. Aqlliroq yondashuvlar:

Self-healing halqasi

Aniqla → izolyatsiya qil → tikla → qayta qo‘sh. Amalda bu oldingi mavzular birlashmasi:

• Health check (5-mavzu) — o‘lik/sog‘lom instance’ni aniqlaydi; liveness buzilsa — pod avtomatik qayta ishga tushadi.
• Outlier detection (5-mavzu Deep) — tinmay xato beradigan instance’ni trafikdan avtomatik chiqaradi, tuzalsa qaytaradi.
• Autoscaling (5-mavzu Deep) — yuk oshsa avtomatik ko‘proq instance.
• Circuit breaker (bu mavzu) — o‘layotgan bog‘liqlikni avtomatik uzadi va half-open bilan tuzalishini o‘zi sinaydi.

Idempotency key qanday ishlaydi

Mijoz har amalga noyob kalit yuboradi (masalan, Idempotency-Key header). Server: bu kalit ko‘rilganmi? Ha bo‘lsa — saqlangan natijani qaytar (qayta bajarmasdan); yo‘q bo‘lsa — bajar, natijani kalit bilan saqla:

// IDEMPOTENCY KEY: mijoz noyob kalit yuboradi; server dedup qiladi (retry xavfsiz)
async function handle(key: string, body: any) {
  const existing = await this.store.get(key);
  if (existing) return existing.result;              // TAKROR -> saqlangan natijani qaytar

  const locked = await this.store.acquireLock(key);  // parallel takrorni to'sish (SETNX)
  if (!locked) throw new ConflictException("In progress");

  const result = await this.process(body);           // FAQAT bir marta bajariladi
  await this.store.save(key, result, { ttl: "24h" });
  return result;
}

Chaos engineering amaliyoti

• Gipoteza: "To‘lov xizmati o‘lsa, buyurtma fallback bilan ishlashda davom etadi" — deb taxmin qil.
• Steady-state metrika: normal holatni o‘lchab ol (SLO, 12-mavzu).
• Nosozlik kirit: ataylab xizmatni o‘chir, kechikish qo‘sh, tarmoqni uz.
• Blast radius nazorati: avval kichik (bitta instance, oz trafik), ishonch ortsa kengaytir.
• Natija: gipoteza tasdiqlansa — yaxshi; buzilsa — zaiflik topildi, tuzatiladi (incidentdan oldin).

Senior tayyorlik cheklisti