ოპერაციები და სერვისების დამოკიდებულება

სერვისების დამოკიდებულება

1) რატომ არის ეს აუცილებელი?

ნებისმიერი წარმოების პლატფორმა არის გრაფიკი: Edge/API- ის მომხმარებლები - დომენის სერვისები - სტრიქონები/ნაკადები, BD/ქეში, გარე პროვაიდერები (გადახდები, KYC, თამაშების პროვაიდერები). გრაფიკის ერთ კიდეზე შეცდომა ხშირად „დადის“ მთელ ქსელში: იზრდება შეფერხებები, ხდება რეტრაები, ხდება რიგები, ხდება კასკადის უკმარისობა. დამოკიდებულების მენეჯმენტი ამცირებს „ასაფეთქებელ სხივს“ და გამოშვებებს პროგნოზირებს.

• დაინახეთ ზარის სრული რაოდენობა და გაიგეთ ვინ არის დამოკიდებული ვისზე.
• თავიდან აიცილეთ კასკადის უკმარისობა და „ქარიშხლის ქარიშხალი“.
• დაგეგმეთ გამოშვებები თავსებადობისა და SLO პროპაგანდის გათვალისწინებით.
• გაზარდეთ MTTR: უფრო სწრაფად იპოვოთ ნამდვილი ძირეული კვანძი (root cause).

2) დამოკიდებულების ტიპები

სინქრონული (RPC: REST/gRPC/GraphQL): ლატენტობის/წვდომის მკაცრი კავშირი. ჩვენ გვჭირდება ტაიმაუტები, ბრეიკერები, რეაგირების ბიუჯეტი.
ასინქრონული (Event/Stream: Kafka/Rabbit/Pulsar): უფრო სტაბილური კავშირი, მაგრამ არსებობს lag/backlog და მიწოდების სემანტიკა (at-least-once, idempotence).
საცავი (DB/Cache/Object store): გაყოფილი რესურსები - ჭურვი, კონექტების ლიმიტები/IOPS, მოვლენები, რეპლიკაცია.
გარე პროვაიდერები (PSP/KYC/თამაშის პროვაიდერები): კვოტები, ფასიანი ზარები, მომსახურების ფანჯრები, იურიდიული SLA.
ოპერაციული (გამოშვებები, ფიჩეფლაგები, კონფიგურაციები): არაპირდაპირი დამოკიდებულება პარამეტრების, საიდუმლოებების, სკოლის რეგისტრის საშუალებით.

3) სერვისების კატალოგი და დამოკიდებულების რაოდენობა

• მფლობელები (Squad/chat/On-call rota), რეპო, გარემო, არტეფაქტები.
• API კონტრაქტები (OpenAPI/AsyncAPI), ვერსიები, თავსებადობა (back/forward).
• შემომავალი/გამავალი დამოკიდებულება (upstream/downstream) ტიპით (sync/async), კრიტიკა, SLO მოლოდინები.
• Taimauts/retray- ის ბიუჯეტი, 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.
• Taimauts: 200 ms k 'PSP-X', 150 ms k 'user-profile'.
• Retrai: 2 ექსპონენციალური შეფერხებით, ჯიტერი.
• ბრეიკერი: ღია 30, 5% შეცდომით/10.

4) SLO პროპაგანდა და „ლატენტობის ბიუჯეტი“

სინქრონული ზარების ჯაჭვში, საბოლოო SLO იქმნება შეფერხებების ოდენობისა და უარის თქმის ალბათობისგან.

• მოთხოვნის ბიუჯეტი იშლება ზემოდან: წინა ხაზზე SLO 500 ms - Edge 50 ms - API 150 ms - დომენის მომსახურება 200 ms - 100 ms პროვაიდერი.
• ტაიმაუტები „გარედან უფრო მოკლეა, ვიდრე შიგნით“: გამომწვევი ტაიმუთი ნაკლებია, ვიდრე მთლიანი შიდა, რათა რესურსები განახლდეს და არ დაგროვდეს ზომბების გამოწვევები.
• Retrai მხოლოდ უსაფრთხო კოდები/გამონაკლისები და ჯიტერი; ვიწრო ადგილების ტაიმაუტების გარეშე (წინააღმდეგ შემთხვევაში „ქარიშხალი“).

5) კონტრაქტები და თავსებადობა

API ვერსია: SemVer კონტრაქტებისთვის; backward compatible ცვლილებები „optional“ ველების მეშვეობით, სქემის გაფართოება; მოცილება - მხოლოდ „დეპრესიის პერიოდის“ საშუალებით.
Consumer-driven კონტრაქტები (CDC): მომხმარებელთა ტესტები (Pact მსგავსი) იწყება CI- ში პროვაიდერის წინააღმდეგ; გამოშვება დაბლოკილია შეუთავსებლობის შემთხვევაში.
რეესტრის სქემა (Async): ტოპიკური/მოვლენების ვერსია, სქემების ევოლუცია (Avro/JSON-Schema), პოლიტიკა „can-read-old/can-write-new“.

6) ინჟინერიის სტაბილურობის ნიმუშები

Timeouts: ჩვენ SLA ბიზნესს გამოვყოფთ ტექნიკური მოლოდინებისგან; თითოეული გამავალი კავშირი აშკარა ტაიმაუტია.
Retries + backoff + jitter: idempotence- ის გათვალისწინებით არაუმეტეს 2-3 მცდელობა.
Circuit Breaker: „სწრაფი ვარდნა“ downstrim- ის დეგრადაციის დროს; ჰალფ-ღია ტესტები.
Bulkhead (ტყვიების იზოლაცია): სხვადასხვა downstrim- ისთვის - ცალკეული ნაკადები/პოდები/ნაერთები.
Rate-limit/Leaky-bucket: იმისათვის, რომ არ მოეკლათ შემოდგომაზე.
Idempotence & deaduplication: idempotence გასაღები მოთხოვნის/შეტყობინებების დონეზე; ბაბუა ლეიტენანტები და retray რიგები.
ქეშირება და ხალხური: ადგილობრივი/განაწილებული ქეში, „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 და მცდარი ნეკნები.
• „პრობლემური დამოკიდებულების ტოპ N“ გასული კვირის განმავლობაში.
• „Blast radius“ - სერვისების სია, რომლებიც დაზარალდება X- ის დაცემის დროს.
• კორელაციის ლოგოები: ჟურნალებში „trace _ id '/' span _ id“ ჩართვა.

8) განთავისუფლების მენეჯმენტი დამოკიდებულების გათვალისწინებით

papendence-aware payplines: პროვაიდერის გამოშვება დაბლოკილია, თუ CDC მომხმარებელთა ტესტები წითელია.
თანდათანობითი ჩართვა (ficheflagi): ახალი ველები/ენდოინები მომხმარებელთა 1% -სთვის 10% -დან 100% -მდე.
კანარის გამოშვებები: ჩვენ ვამოწმებთ საკვანძო დამოკიდებულებებს და „ლატენტობის ბიუჯეტს“ ტრაფიკის წილზე.
სქემების თავსებადობა: პროდიუსერი წერს 'vNew', კონსიუმერები კითხულობენ 'vOld/vNew'; გადასვლის შემდეგ - ძველი მინდვრების „ნაგვის შეგროვება“.

9) გრაფიკის ინციდენტები და ესკალაცია

ჩვენ განვსაზღვრავთ „ჭეშმარიტ დამნაშავეს“: ალერტის კორელაცია - თუ „PSP-X“ დეგრადირებულია, ჩვენ არ მივცემთ მთელ „გადახდის ბუჩქს“, არამედ ინტეგრაციის მფლობელს.
ავტომაგისტრალი: icheflag „მინიმალური რეჟიმი“ (ნაკლებად მძიმე endpoints, შემცირებული bandles, არაკრიტიკული შეცდომების გამორთვა).
კასკადების კარადები: ჩვენ შემოიფარგლება პარალელიზმით, გამორთეთ ბილიკი ცხელ ფილიალზე, წინასწარ ვხსნით შესვენებას (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. Dashbords და alerty per-dependency კონფიგურაცია.
7. გამოშვება: 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 FOR 5m' + 'outbound _ rps> 0' ქარიშხლის რისკს წარმოადგენს.

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

• ' usage _ íta {provider =“ PSP-X „> 90% window '- გაფრთხილება, მარშრუტების ავტოპარკი.

13) ანტი შაბლონები

„ერთი ზოგადი ნაკადის აუზი ყველა დასაშვებია“. სულ: head-of-line ბლოკირება. პაჱკაპაირვ ჟვ.
ტაიმაუტის გარეშე/გაუთავებელი ჭრილობებით. ასე რომ, ქარიშხალი იბადება.
არაიდემპოტენტური ოპერაციების ბრმა ჭრილობები. ჩამოწერის/განაკვეთების დუბლები.
ფარული „ზოგადი DD“, როგორც კავშირის წერტილი. ძლიერი კონკურენცია და დაბლოკვა.
API ვერსია იცვლება CDC და სადეპოზიტო გეგმის გარეშე. დაიჭირეთ მასიური ვარდნა.
დაკვირვება მხოლოდ სერვისებზე, არა კავშირებზე. არ ჩანს სად იშლება ჯაჭვი.

14) დაშბორდი: მინიმალური ნაკრები

Service Map: სერვისების ინტერაქტიული რუკა ნეკნების მეტრიკებით (latency/error/volume).
Upstream/Downstream Overview: სამსახურის მფლობელისთვის - შემომავალი დამოკიდებულებები (ვინ დარეკავს), გამომავალი (ვისთვისაც ზარი), „საუკეთესო პრობლემები“.
Drilldown Dependence: კონკრეტული საკომუნიკაციო ბარათი: p50/p95/p99, კლასების შეცდომები, ღია შესვენების, retrai, კავშირების აუზი, კვოტები/ლენტები.
Release Context: გამოშვების/ficheflage- ის ვიდეოები დამოკიდებულების გრაფიკებზე.

15) განხორციელების სია

• სერვისების კატალოგი მფლობელებთან და კონტრაქტებთან (OpenAPI/AsyncAPI).
• ტრეკებიდან დამოკიდებულების სრული გრაფიკი (ყოველდღიურად განახლება).
• SLO მომსახურებაზე და „ლატენტობის ბიუჯეტებზე“ ჯაჭვში.
• აშკარა ტაიმაუტები, ჯიტერი, ბრეიკერები, ბულკჰედის იზოლაცია.
• CDC ტესტები CI- ში, როგორც გამოშვება.
• Dashbords per-dependence და მომსახურების ბარათი.
• ალერტას ნეკნები + მხარდაჭერა ძირითადი მიზეზის გამო.
• თამაშის დღეები: პროვაიდერის/კლასტერის/ტოპიკის ვარდნა და დეგრადაციის შემოწმება.
• დეგრადაციის გეგმა: რა სახის ჩიპები გამორთეთ, რა ქეშებს მოიცავს.
• რეგულარული პოსტმორტემები დაკავშირების შემცირების მოქმედებებთან.

16) KPI დამოკიდებულების მართვის ხარისხი

Dependence MTTR: საშუალო აღდგენა ნეკნის გასწვრივ.
Blast Radius Index: დაზარალებული სერვისების საშუალო რაოდენობა ერთი ვარდნით.
Coupling Score: sync დამოკიდებულების წილი ყველას შორის; შემცირების ტენდენცია.
CDC Pass Rate: გამოშვების% ხელშეკრულებების დარღვევის გარეშე.
Retry Storms/თვე: მიზნის მნიშვნელობა 0.
External Calls: გარე ზარების ღირებულება 1k RPS- ზე (იხილეთ ქეშირების/ფოლბეკების ეფექტი).

17) სწრაფი დაწყება (ნაგულისხმევი)

ტაიმაუტები: კავშირის ბიუჯეტის 70-80%; მოთხოვნის ზედა ტაიმუტი <შინაგანი ჯამი.
Retrai: max 2, მხოლოდ idempotent 5xx/ქსელზე, backoff + gitter- დან.
ბრეიკერი: შეცდომების 5% -იანი ბარიერი 10 წამში, ღია = 30 წმ, ჰალფ-ღია ტესტები.
Bulkhead: გამოყოფილი აუზები/ნაერთების ლიმიტები თითოეული dowstrim- ისთვის.
CDC: სავალდებულოა ყველა საჯარო API და ტოპიკისთვის.
Async პრეფერენციები: სადაც შეგიძლიათ - მოვლენებზე/რიგზე გადასვლა (დროულად გადასვლა).

18) FAQ

Q: რა არის უფრო მნიშვნელოვანი: retrai ან braker?
ა: ორივე. Retrai იხსნის მოკლევადიანი წარუმატებლობებისგან, ბრეიკერი იცავს მუდმივი დეგრადაციისა და ქარიშხლისგან.

Q: როგორ გავიგოთ, რომ კავშირი „ძალიან მყიფეა“?
A: შეცდომების მაღალი კორელაცია, ტაიმაუტის დაბალი მარაგი, ხშირი ჭიდაობა, ფოლბეკების/ქეშების არარსებობა, სინქრონული გრძელი ჯაჭვები.

Q: რატომ CDC, თუ ჩვენ გვაქვს ინტეგრაციის ტესტები?
A: CDC აფიქსირებს მომხმარებლის მოლოდინს და არღვევს პროვაიდერის გამოშვებას შეუთავსებლობის შემთხვევაში - სანამ კოდი პროდუქტში მოხვდება.