Операциялар жана башкаруу → Кызматтардын көз карандылыгы

Кызматтардын көз карандылыгы

1) Эмне үчүн керек

Ар кандай өндүрүш аянтчасы - бул графа: колдонуучулар → Edge/API → домендик кызматтар → кезектер/агымдар → BD/кэштер → тышкы провайдерлер (төлөмдөр, KYC, оюн провайдерлери). Бир кабыргасында ката көп учурда тармак боюнча "сейилдеп": кечигүү, retrais иштеп, кезек тыгылып, каскаддык мүчүлүштүктөр бар. Көз карандылыкты башкаруу "жарылуу радиусун" азайтат жана релиздерди алдын ала айтууга болот.

• Толук чакырыктарды көрүү жана ким кимге көз каранды экенин түшүнүү.
• Каскаддык мүчүлүштүктөрдү жана "ретрайлардын бороонун" алдын алуу.
• Релиздерди шайкештикти жана 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.
Операциялык (релиздер, фичефлагдар, конфигалар): орнотуулар, сырлар, схемалар аркылуу кыйыр көз карандылык.

3) Кызмат көрсөтүүлөрдүн каталогу жана көз карандылык графалары

• Ээлери (Squad/чат/On-call rota), репо, айлана-чөйрө, экспонаттар.
• API келишимдери (OpenAPI/AsyncAPI), версиялары, шайкештиги (back/forward).
• Кирүүчү/чыгуучу көз карандылыктар (upstream/downstream) түрү менен (sync/async), criticity, SLO күтүүлөр.
• Бюджет тайм/retraights, breakers, bulkhead пулдар.
• Тышкы интеграциялардын квоталары жана лимиттери жөнүндө маалыматтар.

• `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.
• Таймауттар: 200 мс к 'PSP-X', 150 мс к 'user-profile'.
• Retrais: 2 экспоненциалдык кечигүү менен, життер.
• Брейкер: ачык 30 с 5% ката/10 б.

4) SLO-пропаганда жана "жашыруун бюджет"

Синхрондуу чалуулар чынжырында жыйынтыктоочу SLO кечигүүлөрдүн суммасынан жана мүчүлүштүктөрдүн ыктымалдыгынан түзүлөт.

• Бюджет сурам жогорудан төмөн бөлүнөт: алдыңкы SLO 500 мс → Edge 50 мс → API 150 мс → домен кызматтары 200 мс → провайдер 100 мс.
• Таймауттар "ичине караганда сыртка кыска": зомби чалуулар топтолбостон, ресурстарды жаңылоо үчүн жалпы ички таймаут азыраак.
• Retrains гана коопсуз коддору/өзгөчөлүктөрү жана Jitter менен; тайм-аут тар жерлерге (болбосо "бороон").

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: downstream деградация менен "тез түшүү"; half-open үлгүлөрү.
Bulkhead (Pool изоляция): ар кандай downstream үчүн - өзүнчө Pool агымдар/этек/байланыштар.
Rate-limit/Leaky-bucket: чокуларда downstream өлтүрүп жок.
Idempotency & deduplication: суроо-талап/билдирүү деъгээлинде idempotency ачкычы; чоң ата лейтерлер жана ретрай кезектери.
Кэширование жана follbeky: жергиликтүү/бөлүштүрүлгөн кэштер, "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 (TraceID, Багаж): шилтемелер боюнча сурам жолун көрүү; '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 керектөөчүлөрдүн тесттер кызыл болсо, бошотуу жөнөтүүчү бөгөттөлгөн.
Акырындык менен киргизүү (phicheflags): жаңы талаалар/endoints → керектөөчүлөрдүн 1% үчүн → 10% → 100%.
Канар релиздери: негизги көз карандылыктарды жана трафиктин үлүшү боюнча "жашыруун бюджетти" текшеребиз.
Схемалардын шайкештиги: продюсер 'vNew' деп жазат, консумерлер 'vOld/vNew' деп окушат; кийин - эски талаалардын "таштандыларын чогултуу".

9) Окуя жана эскалация

"Чыныгы күнөөкөрдү" аныктайбыз: alert-корреляция - эгерде "PSP-X" деградацияланган болсо, пейджим бүтүндөй "төлөм бадалы" эмес, интеграциянын ээси.
Autodegradation: ficheflag "минималдуу режими" (анча оор эмес end-point, кыскартылган Бандла, өчүрүү эмес-маанилүү fich).
Каскаддардан гардалар: параллелизмди чектейбиз, ысык линиядагы ретраларды өчүрөбүз, брейкерди алдын ала ачабыз (алдын ала ачык).

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

10) Көз карандылыктын критикалык матрицасы

• "Сынчылар" үчүн - кош провайдинг, брейкерлер, жеке бассейндер, башаламандык тесттери.
• "Бийик" үчүн - жок дегенде деградация жана "жашыл баскычты" өчүрүү.
• "Орто/төмөн" үчүн - ретрага лимиттер жана кезек бюджети.

11) Процесс: инвентаризациядан эксплуатацияга чейин

1. Graph Carting: иш жүзүндөгү чалууларды чогултуу (tracking) + каталогдон декларативдик көз карандылыктар.
2. ээлерин дайындоо: ар бир кызмат жана тышкы бириктирүү үчүн - жооптуу on-call.
3. SLO жана бюджеттерди аныктоо: жашыруун/каталар, таймауттар/ретрациялар/пулдар.
4. Контракттарды тариздөө: OpenAPI/AsyncAPI, схемалар жана CDC.
5. Туруктуулук үлгүлөрүн киргизүү: timeouts/retries/circuit/bulkhead.
6. Дашбордддорду жана per-dependency алерталарын орнотуу.
7. Gate релиз: CDC/шайкештик/канарейка боюнча блок.
8. Үзгүлтүксүз оюн-күн: негизги кабыргалардын кулашы боюнча башаламандык эксперименттер.
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 ҮЧҮН 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) Dashbord: минималдуу топтому

Service Map: кабыргалардын метриктери менен кызматтардын интерактивдүү картасы (latency/error/volume).
Upstream/Downstream Overview: сервистин ээси үчүн - кирүүчү көз карандылыктар (ким чакырат), чыгуучу (кимге чалабыз), "топ көйгөйлөр".
Dependency Drilldown: конкреттүү байланыш карта: p50/p95/p99, класстары боюнча каталар, ачык брейкер пайызы, retry, байланыш бассейни, квота/кост.
Release Context: көз карандылык диаграммаларында релиздер/phicheflags аннотациялары.

15) Киргизүү чек-тизмеси

• Ээлери жана келишимдери менен кызматтардын каталогу (OpenAPI/AsyncAPI).
• Толук сызык көз карандылыгы (күн сайын жаңыртып).
• SLO кызмат жана "жашыруун бюджеттер" чынжыр боюнча төмөн.
• Ачык таймауттар, джиттер менен ретрациялар, брейкерлер, булгоочу изоляция.
• CDC тесттер релиздик дарбазасы катары CI.
• Dashboard per-dependency жана тейлөө картасы.
• кабыргалары боюнча Alerty + suppression баштапкы себеби боюнча.
• Оюн-күндөр: провайдердин/кластердин/топиктин кулашы жана деградацияны текшерүү.
• Деградация планы: Кайсы чиптерди өчүрөбүз, кайсы кэштерди күйгүзөбүз.
• байланыш азайтуу иш-аракеттери менен үзгүлтүксүз postmortemy.

16) KPI көз карандылыкты башкаруу сапаты

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

17) Тез баштоо (демейки)

Таймауттар: звено бюджетинин 70-80%; жогорку суроо-убакыт <ички суммасы.
Retrains: max 2, гана idempotent 5xx/network, менен backoff + Jitler.
Breaker: босого 5% 10 с ката, open = 30 с, half-open үлгүлөрү.
Bulkhead: ар бир downstream үчүн атайын бассейндер/байланыштар чектери.
CDC: бардык коомдук API жана топиктер үчүн милдеттүү.
Async-преференциясы: кайда болот - окуяларга/кезекке өтүү (убакыттын өтүшү).

18) FAQ

Q: Эмне маанилүү: retrailer же брейкер?
A: экөө тең. Retrailer кыска мөөнөттүү бузулуулардан сактайт, брейкер туруктуу бузулуудан жана бороон-чапкындан коргойт.

Q: байланыш "өтө морт" экенин кантип түшүнүүгө болот?
A: Жогорку ката корреляциясы, таймауттардын төмөн запасы, тез-тез ретрациялар, follbeks/кэш жоктугу, синхрондуу узун чынжырлар.

Q: Биз интеграциялык тесттер бар болсо, эмне үчүн CDC?
A: CDC керектөөчүнүн күтүүлөрүн жаздырат жана шайкеш келбеген учурда провайдердин релизин бузат - код прод.