Əməliyyatlar və İdarəetmə → Xidmətlərin asılılığı

Xidmətlərin asılılığı

1) Niyə lazımdır

Hər hansı bir istehsal platforması qrafikdir: istifadəçilər → Edge/API → domen xidmətləri → növbələr/axınlar → BD/caches → xarici provayderlər (ödənişlər, KYC, oyun provayderləri). Qrafın bir qabırğasında səhv tez-tez bütün şəbəkədə «gəzir»: gecikmələr artır, retralar işləyir, növbələr bağlanır, kaskad uğursuzluqlar baş verir. Asılılığın idarə edilməsi «partlayış radiusunu» azaldır və buraxılışları proqnozlaşdırıla bilən edir.

• Zənglərin tam qrafikini görmək və kimin kimdən asılı olduğunu başa düşmək.
• Kaskad nasazlıqların və «retraj fırtınasının» qarşısını almaq.
• Uyğunluq və SLO təbliğatını nəzərə alaraq buraxılışları planlaşdırın.
• MTTR artırın: daha sürətli əsl əsas qovşağı (root cause) tapın.

2) Asılılıq növləri

Sinxron (RPC: REST/gRPC/GraphQL): gizli/əlçatanlığa görə sərt əlaqə. Taymautlar, breykerlər, retraj büdcəsi lazımdır.
Asenkron (Event/Stream: Kafka/Rabbit/Pulsar): daha davamlı əlaqə, lakin lag/backlog və çatdırılma semantikası (at-least-once, idempotency) var.
Depolama (DB/Cache/Object store): paylaşılan resurslar → kontenşn, bağlanma limitləri/IOPS, eviction, replikasiya.
Xarici provayderlər (PSP/KYC/oyun provayderləri): kvotalar, ödənişli zənglər, xidmət pəncərələri, hüquqi SLA.
Əməliyyat (relizlər, fitness, konfiqlər): parametrlər, sirlər, schema registry vasitəsilə dolayı asılılıqlar.

3) Xidmətlər kataloqu və asılılıq qrafikləri

• Sahibləri (Squad/chat/On-call rota), repo, mühit, artefaktlar.
• API müqavilələri (OpenAPI/AsyncAPI), versiyalar, uyğunluq (back/forward).
• Tip (sync/async), kritik, SLO gözləntiləri ilə gələn/gedən asılılıqlar (upstream/downstream).
• Vaxt/retraut büdcəsi, breykerlər, bulkhead hovuzları.
• Xarici inteqrasiya kvotaları və limitləri haqqında məlumatlar.

• `service: payments-api`
• Upstream: `user-profile` (sync), `risk-score` (async).
• Downstream: `PSP-X` (sync, квота 2k RPS), `ledger` (async).
• SLO: p99 ≤ 300 ms, 99. 9% uptime.
• Vaxtlar: 200 ms k 'PSP-X', 150 ms k 'user-profile'.
• Retrailer: 2 eksponensial gecikmə, jitter.
• Braker: açıq 30 s 5% səhv/10 s

4) SLO-təbliğat və «gizli büdcə»

Sinxron zənglər zənciri zamanı son SLO gecikmələr və uğursuzluq ehtimallarının cəmindən formalaşır.

• Tələb büdcəsi yuxarıdan aşağıya bölünür: ön SLO 500 ms → Edge 50 ms → API 150 ms → domen xidmətləri 200 ms → provayder 100 ms.
• Zamautlar «içəridən daha qısadır»: zombi çağırışlarını yığmaqdansa, resursların yenilənməsi üçün çağıranın daxili taymautu daha azdır.
• Retrains yalnız təhlükəsiz kodlar/istisnalar və jitter ilə; dar yerlərin taymautları üçün retras olmadan (əks halda «fırtına»).

5) Müqavilələr və uyğunluq

API versiyası: müqavilələr üçün SemVer; «optional» sahələri vasitəsilə backward-compatible dəyişikliklər, sxem genişləndirilməsi; çıxarılması - yalnız «deprekeyt dövrü» vasitəsilə.
Consumer-driven contracts (CDC): İstehlakçı testləri (Pact kimi) CI provayderinə qarşı başlayır; uyğunsuzluq zamanı buraxılış bloklanır.
Sxem-registrlər (Async): top/hadisə versiyası, sxemlərin təkamülü (Avro/JSON-Schema), «can-read-old/can-write-new» siyasəti.

6) Dayanıqlılıq mühəndislik nümunələri

Timeouts: SLA biznesini texniki gözləntilərdən ayırırıq; hər bir çıxış bağlantısı - aydın vaxt.
Retries + backoff + jitter: İdempotentliyi nəzərə alaraq 2-3 cəhddən çox deyil.
Circuit Breaker: downstream deqradasiya «sürətli eniş»; half-open testlər.
Bulkhead (hovuz izolyasiyası): müxtəlif alt axınlar üçün - ayrı-ayrı axınlar/pod/birləşmələr hovuzları.
Rate-limit/Leaky-bucket: zirvə zamanı downstream öldürmək deyil.
Idempotency & deduplication: sorğu/mesaj səviyyəsində idempotentlik açarı; leyterlər və retraj növbələri.
Caching və follback: yerli/paylanmış caches, «stale-while-revalidate» statusları, məzmun deqradasiyası.

outbound:
psp-x:
timeout_ms: 200 retries: 2 retry_on: [5xx, connect_error]
backoff: exponential jitter: true circuit_breaker:
error_rate_threshold: 0. 05 window_s: 10 open_s: 30 pool: dedicated-psp (max_conns: 200)

7) Asılılıq müşahidə

Paylanmış izlər (TraceID, Baggage): linklər üzrə sorğu yolunu görmək; 'peer. service`, `retry`, `timeout`.
Метрики per-dependency: `outbound_latency_p99`, `outbound_error_rate`, `open_circuit`, `retry_count`, `queue_lag`.

• SLO və səhv qabırğaların rəng göstəricisi ilə xidmətlərin xəritəsi.
• Son bir həftə ərzində «Top N problemli asılılıqlar».
• «Blast radius» - X. düşdükdə zərər çəkəcək xidmətlərin siyahısı.
• Korrelyasiya qeydləri: 'trace _ id '/' span _ id' jurnallarına daxil edin.

8) Asılılıqları nəzərə alaraq buraxılışların idarə edilməsi

Dependency-aware payplayns: CDC istehlakçı testləri qırmızı olduqda provayder buraxılışı bloklanır.
Tədricən aktivləşdirmə (fitness): yeni sahələr/endointlər → 1% istehlakçılar üçün → 10% → 100%.
Kanarya buraxılışları: əsas asılılıqları və trafikin payına görə «gecikmə büdcəsini» yoxlayırıq.
Sxemlərin uyğunluğu: prodüser yazır 'vNew', konsumerlər oxuyur 'vOld/vNew'; keçiddən sonra - köhnə sahələrin «zibil yığımı».

9) Hadisə və eskalasiya

«Əsl günahkarı» müəyyənləşdiririk: alert-korrelyasiya - əgər «PSP-X» deqradasiya edilibsə, bütün «ödəmə kolu» peycim deyil, inteqrasiyanın sahibidir.
Avtodeqradasiya: «minimal rejim» (daha az ağır end nöqtələri, kəsilmiş bandllar, kritik olmayan fiqurların bağlanması).
Kaskadlardan qardlar: paralelliyi məhdudlaşdırırıq, retrayları isti xətdə söndürürük, breykeri əvvəlcədən açırıq (pre-open).

• Diaqnostika: hansı dashboard/metrik, kvota/limitləri yoxlamaq üçün necə.
• Fəaliyyət: RPS azaltmaq, ehtiyat provayder keçid, müvəqqəti cache cavabları yandırmaq.
• Geri və validasiya: parametrləri geri qaytarın, p95/p99 və error-rate normasına əmin olun.

10) Asılılıq kritikliyi matrisi

• «Kritik» üçün - ikiqat provaydinq, breykerlər, ayrı hovuzlar, xaos testləri.
• «Yüksək» üçün - ən azı deqradasiya və «yaşıl düymə» fiçi söndürmək.
• «Orta/aşağı» üçün - retraya limitlər və növbə büdcəsi.

11) Proses: inventarizasiyadan istismara qədər

1. Qrafın xəritəsi: kataloqdan faktiki çağırışlar (izlər) + deklarativ asılılıqları toplayın.
2. Sahibləri təyin edin: hər bir xidmət və xarici inteqrasiya üçün - on-call cavabdeh.
3. SLO və büdcələri müəyyən edin: gecikmə/səhvlər, vaxt/retraut/hovuzlar.
4. Müqavilələri rəsmiləşdirin: OpenAPI/AsyncAPI, sxemlər və CDC.
5. Dayanıqlıq nümunələrini daxil edin: timeouts/retries/circuit/bulkhead.
6. Daşbordları və per-dependency alertlərini konfiqurasiya edin.
7. Buraxılış geytaları qoyun: CDC/uyğunluq/kanarya ilə blok.
8. Müntəzəm game-days: Əsas qabırğaların düşməsi üçün xaos təcrübələri.
9. Postmortemlər əlaqələrə diqqət yetirir: kaskadı gücləndirən şey radiusu necə daraltmaqdır.

12) Asılılıq (qaydaların ideyaları)

• `outbound_error_rate{to="X"} > 3% FOR 10m` → warning; `>5% FOR 5m` → critical.
• `outbound_p99_latency{to="X"} > SLO1. 3 FOR 10m` → warning.

• ' circuit _ open {to =» X»} = = 1 FOR 1m' → page inteqrasiya sahibidir.

• ' retry _ rate {to =» X»}> baseline2 ÜÇÜN 5m' + 'outbound _ rps> 0' → fırtına riski.

• `consumer_lag{topic="Y"} growth > threshold FOR 10m` + `hpa at max` → крит.

• ' usage _ quota {provider =» PSP-X «}> 90% window '→ xəbərdarlıq, marşrutların avtomatik açılması.

13) Anti-nümunələr

«Bütün alt axınlarda bir ümumi axın hovuzu». Cəmi: head-of-line blocking. Pulları bölüşün.
Heç bir zaman/sonsuz retras. Beləliklə, fırtına yaranır.
Qeyri-idempotent əməliyyatların kor retrayaları. Debet/bahis Dubley.
Əlaqə nöqtəsi kimi gizli «ümumi DB». Güclü rəqabət və bloklama.
API versiyası CDC və deprekeyt planı olmadan dəyişir. Kütləvi enişləri tutun.
Yalnız xidmətlərdə müşahidə olunur, əlaqələrdə deyil. Zəncirin harada qırıldığı görünmür.

14) Dashboard: minimum dəsti

Service Map: latency/error/volume metrləri ilə interaktiv xidmət xəritəsi.
Upstream/Downstream Overview: xidmət sahibi üçün - daxil olan asılılıqlar (kim zəng edir), gedən (kimə zəng edirik), «top problem».
Dependency Drilldown: xüsusi rabitə kartı: p50/p95/p99, sinif səhvləri, açıq breyker faizi, retralar, qoşulma hovuzu, kvota/cost.
Release Context: asılılıq cədvəllərində relizlərin/fitzeflagların şərhləri.

15) Giriş çek siyahısı

• Sahibləri və müqavilələri olan xidmətlər kataloqu (OpenAPI/AsyncAPI).
• İzləmələrdən asılılığın tam qrafiki (gündəlik yenilənir).
• SLO xidmət və «gecikmə büdcələri» zəncir aşağı.
• Açıq vaxt, retrailer, brakerlər, bulkhead-izolyasiya.
• CI-də CDC testləri buraxılış qapısı kimi.
• Dashboard per-dependency və xidmət kartı.
• Qabırğalarda alertlər + ilkin səbəbə görə suppression.
• Game-days: provayder/klaster/topik düşməsi və deqradasiya yoxlama.
• Deqradasiya planı: hansı fiçləri söndürürük, hansı keşləri açırıq.
• Mütəmadi postmortemlər əlaqəni azaltmaq üçün hərəkətlərlə.

16) KPI asılılıq idarəetmə keyfiyyəti

Dependency MTTR: median qabırğa bərpa.
Blast Radius Index: biri düşdükdə təsirlənən xidmətlərin orta sayı.
Coupling Score: bütün arasında sync asılılıq payı; azalma tendensiyası.
CDC Pass Rate: müqavilələri pozmadan% buraxılışlar.
Retry Storms/ay: hədəf → 0.
Cost of External Calls: 1k RPS xarici zənglərin dəyəri (caching effect/follback görmək).

17) Sürətli başlanğıc (defolt)

Taymautlar: 70-80% budjet link; üst vaxt sorğu <daxili məbləğ.
Retrains: max 2, yalnız idempotent 5xx/şəbəkə, backoff + jitter ilə.
Breaker: 10 saniyədə 5% səhv həddi, open = 30 saniyə, half-open sınaqları.
Bulkhead: Hər downstream üçün xüsusi hovuzlar/bağlantı limitləri.
CDC: Bütün ictimai API və topiklər üçün məcburidir.
Async-preferens: harada - hadisələrə/növbələrə keçid (vaxt qovşağı).

18) FAQ

Q: Hansı daha vacibdir: retray və ya breyker?
A: Hər ikisi. Retrailer qısamüddətli uğursuzluqlardan xilas olur, breyker daimi deqradasiya və fırtınalardan qoruyur.

S: Əlaqənin «çox kövrək» olduğunu necə başa düşmək olar?
A: Yüksək səhv korrelyasiyası, aşağı vaxt ehtiyatı, tez-tez retralar, heç bir fol/cache, sinxron uzun zəncirlər.

Q: Biz inteqrasiya testləri varsa CDC niyə?
A: CDC istehlakçının gözləntilərini qeyd edir və uyğunsuzluqda provayderin buraxılışını pozur - kodun prod-a düşməsindən əvvəl.