Операциялар және басқару → Сервистерге тәуелділік

Сервистердің тәуелділігі

1) Бұл не үшін қажет

Кез келген продакшн-платформа - бұл бағандар: пайдаланушылар → Edge/API → домендік қызметтер → кезектер/ағымдар → ДБ/кэштер → сыртқы провайдерлер (төлемдер, KYC, ойын провайдерлері). Бағанның бір қабырғасындағы қателік бүкіл желі бойынша жиі «жүреді»: кідірістер артады, ретрациялар іске қосылады, кезектер жабылады, каскадтық істен шығулар болады. Тәуелділіктерді басқару «жарылыс радиусын» төмендетеді және релиздерді болжауға болады.

• Шақырулардың толық бағанын көру және кімнің кімге тәуелді екенін түсіну.
• Каскадты істен шығуларды және «ретрайлардың дауылын» болдырмау.
• Үйлесімділік пен SLO-насихатты ескере отырып, релиздерді жоспарлау.
• MTTR жоғарылату: шынайы негізгі түйінді тез табу (root cause).

2) Тәуелділік түрлері

Синхронды (RPC: REST/gRPC/GraphQL): жасырындылық/қол жетімділік бойынша қатаң байланыс. Таймауттар, брейкерлер, ретрайлардың бюджеті қажет.
Асинхронды (Event/Stream: Kafka/Rabbit/Pulsar): тұрақты байланыс, бірақ lag/backlog және жеткізу семантикасы (at-least-once, idempotency) бар.
Сақтау орындары (DB/Cache/Object store): бөлінетін ресурстар → контеншн, коннектілер лимиттері/IOPS, eviction, репликация.
Сыртқы провайдерлер (PSP/KYC/ойын провайдерлері): квоталар, ақылы қоңыраулар, қызмет көрсету терезелері, заңды SLA.
Операциялық (релиздер, фичефлагтар, конфигалар): баптаулар, құпиялар, schema registry арқылы жанама тәуелділіктер.

3) Сервистер каталогы және тәуелділік бағандары

• Иелері (Squad/чат/On-call rota), репо, орта, артефактілер.
• API келісімшарттары (OpenAPI/AsyncAPI), нұсқалары, үйлесімділігі (back/forward).
• Кіріс/шығыс тәуелділіктері (upstream/downstream) түрі (sync/async), сындылығы, SLO күту.
• Таймауттар/ретрайлардың бюджеті, брейкерлер, bulkhead-пулдар.
• Сыртқы интеграцияның квоталары мен лимиттері туралы деректер.

• `service: payments-api`
• Upstream: `user-profile` (sync), `risk-score` (async).
• Downstream: `PSP-X` (sync, квота 2k RPS), `ledger` (async).
• SLO: p99 ≤ 300 мс. 99. 9% uptime.
• Таймауттар: 200 мс к 'PSP-X', 150 мс к 'user-profile'.
• Ретра: экспоненциалды кідіріспен 2, джиттер.
• Брейкер: ашық 30 с 5% қате/10 с

4) SLO-насихат және «жасырындылық бюджеті»

Синхронды шақырулар тізбегі кезінде қорытынды SLO кідірістер мен істен шығу мүмкіндіктерінің сомасынан қалыптастырылады.

• Сұрау бюджеті жоғарыдан төмен бөлінеді: алдыңғы SLO 500 мс → Edge 50 мс → API 150 мс → домендік қызметтер 200 мс → провайдер 100 мс.
• Таймауттар «сыртқа қарай ішке қарағанда қысқа»: шақырушы таймаутта зомби-шақырулар жиналмауы үшін ресурстар жаңартылуы үшін ішкі таймаут қосындысы аз.
• Ретраи тек қауіпсіз кодтарға/ерекшеліктерге және джиттермен; жіңішке орындардың таймаутына ретрассыз (басқаша «дауыл»).

5) Келісімшарттар және үйлесімділік

Келісімшарттар үшін API: SemVer нұсқасы; «optional» өрістері арқылы backward-compatible өзгерістер, схеманы кеңейту; жою - тек қана «депрекейт-кезең» арқылы.
Consumer-driven contracts (CDC): тұтынушылар тестілері (Pact-ұқсас) CI-дегі провайдерге қарсы іске қосылады; сәйкессіздік кезінде шығарылым бұғатталады.
Схема-регистрлер (Async): топиктер/оқиғалардың нұсқасы, схемалардың эволюциясы (Euro/JSON-Schema), «can-read-old/can-write-new» саясаты.

6) Орнықтылықтың инженерлік паттерндері

Timeouts: SLA бизнесін техникалық күтулерден бөлеміз; әрбір шығыс қосылыс - айқын таймаут.
Retries + backoff + jitter: іспеттілігін ескере отырып, 2-3 талпыныстан артық емес.
Circuit Breaker: даунстрим деградациясы кезінде «тез құлдырау»; half-open сынамалары.
Bulkhead (пулдарды оқшаулау): әртүрлі даунстримдер үшін - ағындардың/табандардың/қосылыстардың жеке пулдары.
Rate-limit/Leaky-bucket: шыңдалған кезде даунстримді өлтірмеу үшін.
Idempotency & дедупликация: сұрау/хабарлама деңгейіндегі ұқсастық кілті; лейтерлер мен ретрай-кезектердің атасы.
Кэштеу және фоллбектер: жергілікті/бөлінген кэштер, «stale-while-revalidate» мәртебелері, мазмұнның тозуы.

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) Тәуелділіктің байқалуы

Бөлінген трассалар (TraceID, Baggage): буындар бойынша сұрау жолын көру; 'peer. service`, `retry`, `timeout`.
Метрики per-dependency: `outbound_latency_p99`, `outbound_error_rate`, `open_circuit`, `retry_count`, `queue_lag`.

• SLO және қате қабырғалардың түсті индикациясы бар сервистер картасы.
• Соңғы апта бойынша «Top N проблемалық тәуелділіктер».
• «Blast radius» - X. құлаған кезде зардап шегетін сервистердің тізімі.
• Корреляция логтары: 'trace _ id '/' span _ id' журналдарға қосу.

8) Тәуелділіктерді ескере отырып, релиздерді басқару

Dependency-aware пайплайндар: егер тұтынушылардың CDC тестілері қызыл болса, провайдердің шығарылымы бұғатталады.
Біртіндеп қосу (фичефлагтар): жаңа өрістер/эндоинттер → 1% тұтынушылар үшін → 10% → 100%.
Канареялық релиздер: негізгі тәуелділіктер мен трафик үлесіне «латенттілік бюджетін» тексереміз.
Схемалардың үйлесімділігі: продюсер 'vNew' деп жазады, консумерлер 'vOld/vNew' деп оқиды; көшкеннен кейін - ескі алқаптарды «қоқыс жинау».

9) Баған бойынша инциденттер мен эскалациялар

«Нағыз кінәліні» анықтаймыз: alert-корреляция - егер «PSP-X» деградацияланған болса, пейджим бүкіл «төлем бұтағы» емес, интеграция иесі.
Автодеградация: «ең төменгі режим» фичефлагы (ауыр емес эндпоинттер, қысқартылған бандлалар, сыни емес фичтерді ажырату).
Каскадтардан гардалар: параллелизмді шектейміз, ыстық тармақта ретрацияны өшіреміз, брейкерді алдын ала ашамыз (pre-open).

• Диагностика: қандай дашбордтар/метриктер, квоталарды/лимиттерді қалай тексеру керек.
• Әрекеттер: RPS төмендету, резервтік провайдерге ауысу, кэш жауаптарды уақытша қосу.
• Кері қайтару және валидация: параметрлерді қайтару, p95/p99 және error-rate нормаларына көз жеткізу.

10) Тәуелділіктің сындылық матрицасы

• «Сыни» үшін - қосарлы провайдинг, брейкерлер, жеке пулдар, хаос-тестілер.
• «Жоғары» үшін - деградация және фичті сөндірудің «жасыл түймесі».
• «Орташа/төмен» үшін - ретраға арналған лимиттер және кезектердің бюджеті.

11) Үдеріс: түгендеуден пайдалануға дейін

1. Бағанды картаға түсіру: каталогтан нақты шақыруларды (трассировкалар) + декларативтік тәуелділіктерді жинау.
2. Иелерін тағайындау: әрбір сервис пен сыртқы интеграцияға - жауапты on-call.
3. SLO мен бюджеттерді анықтау: жасырындылық/қателер, таймауттар/ретрациялар/пулдар.
4. Келісімшарттарды ресімдеу: OpenAPI/AsyncAPI, схемалар және CDC.
5. Тұрақтылық үлгілерін қосу: timeouts/retries/circuit/bulkhead.
6. per-dependency дашбордтары мен алерттерін баптау.
7. Релиз-гейттерді орнату: CDC/үйлесімділік/канарейка бойынша блок.
8. Тұрақты game-days: негізгі қабырғалардың құлауы бойынша хаос-эксперименттер.
9. Байланысқа назар аударатын постмортемалар: каскадты не күшейтті, радиусты қалай тарылтуға болады.

12) Тәуелділіктегі алерттар (ереже идеялары)

• `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 интеграция иесіне.

• ' retry _ rate {to =» X»}> baseline2 FOR 5m' + 'outbound _ rps> 0' → дауыл қаупі.

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

• ' usage _ quota {provider =» PSP-X «}> 90% window '→ ескерту, автоауыстыру.

13) Қарсы үлгілер

«Барлық даунстримдерге ағындардың бір ортақ пулы». Жиынтығы: head-of-line blocking. Пулды бөліңіз.
Үзіліссіз/шексіз ретралармен. Дауыл осылай пайда болады.
Демпотенттік емес операциялардың соқыр ретраиялары. Есептен шығару/ставкалар дублі.
Байланыстылық нүктесі ретінде жасырылған «жалпы БД». Күшті бәсекелестік және бұғаттау.
API нұсқасы CDC және депрекейт-жоспарсыз өзгереді. Жаппай құлдырауды ұстаңыз.
Тек қана сервистер бойынша, байланыстар бойынша емес. Шынжырдың қай жерде жарылып кеткені көрінбейді.

14) Дашбордтар: ең аз жиынтық

Service Map: қабырға өлшемдері бар интерактивті сервис картасы (latency/error/volume).
Upstream/Downstream Overview: сервистің иесі үшін - кіріс тәуелділіктері (кім қоңырау шалады), шығыс (кімге қоңырау шаламыз), «топ проблем».
Dependency Drilldown: нақты байланыс карточкасы: p50/p95/p99, кластар бойынша қателер, ашық брейкер пайызы, ретра, қосылыстар пулы, квота/кост.
Release Context: тәуелділік кестелеріндегі релиздер/фичефлагтар аңдатпалары.

15) Енгізу чек-парағы

• Иелері мен келісімшарттары бар сервистер каталогы (OpenAPI/AsyncAPI).
• Толық тәуелділік бағаны (күн сайын жаңарту).
• SLO қызмет көрсету және «жасырындылық бюджеттері» тізбегі бойынша төмен.
• Айқын таймауттар, джиттермен ретрациялар, брейкерлер, bulkhead-оқшаулау.
• Релизгейт ретінде СІ CDC тестілері.
• Дашбордтар per-dependency және сервис картасы.
• Қабырғалардағы алерталар + бастапқы себеп бойынша suppression.
• Game-days: провайдердің/кластердің/топиктің құлауы және құлдырауларды тексеру.
• Деградация жоспары: қандай фичтерді өшіреміз, қандай кэштерді қосамыз.
• Байланыстылықты азайту әрекеттері бар тұрақты постмортемалар.

16) Тәуелділіктерді басқару сапасының KPI

Dependency MTTR: қабырға бойынша қалпына келтіру медианы.
Blast Radius Index: біреуі құлаған кезде қозғалған сервистердің орташа саны.
Coupling Score: барлығы арасында sync-тәуелділіктің үлесі; төмендеу тренді.
CDC Pass Rate:% келісімшарттар бұзылмаған релиздер.
Retry Storms/ай: мақсатты мән → 0.
Cost of External Calls: 1k RPS сыртқы қоңыраулардың құны (кэштеу/фоллбектер әсерін көру).

17) Жылдам бастау (дефолттар)

Таймауттар: буын бюджетінен 70-80%; сұраудың жоғарғы таймауты <ішкі сома.
Ретраи: max 2, тек демпотенттік 5хх/желілік, backoff + джиттер.
Брейкер: 10 с, open = 30 с, half-open сынамаларында 5% қате шегі.
Bulkhead: әрбір даунстримге бөлінген пулдар/қосылыстар лимиттері.
CDC: барлық көпшілік API және топиктер үшін міндетті.
Async-преференс: мұнда - оқиғаларға/кезекке көшу (уақыт бойынша ажырату).

18) FAQ

Q: Не маңызды: ретраи немесе брейкер?
А: Екеуі де. Ретраяларды қысқа мерзімді іркілістерден құтқарады, брейкер үздіксіз тозудан және дауылдан қорғайды.

Q: Байланыстың «тым нәзік» екенін қалай түсінуге болады?
A: Қателердің жоғары корреляциясы, таймауттардың төмен қоры, жиі ретрациялар, фоллбектер/кэштердің болмауы, синхронды ұзын тізбектер.

Q: Егер бізде интеграциялық тестілер болса, CDC неге керек?
A: CDC тұтынушының күтулерін тіркейді және провайдердің шығарылымын сәйкес келмеген жағдайда - кодтың өнімге түсуінен бұрын бұзады.