მოხდენილი დეგრადაცია

1) მიდგომის არსი

მოხდენილი დეგრადაცია არის სისტემის კონტროლირებადი გადასვლა უფრო მარტივ, მაგრამ სასარგებლო რეჟიმში, რესურსების ნაკლებობით, დამოკიდებულების გაუმართაობით ან დატვირთვის მწვერვალებით. მიზანია შეინარჩუნოს მომხმარებლისთვის ფასეულობების ბირთვი და პლატფორმის სტაბილურობა, შესწირა მეორეხარისხოვანი შესაძლებლობები და ხარისხი.

• პროგნოზირება: წინასწარ განსაზღვრული სცენარები და დეგრადაციის „კიბეები“.
• დაზიანების რადიუსის შეზღუდვა: ფიჩების იზოლაცია და დამოკიდებულებები.
• დაკვირვება: მეტრიკა, ლოგები და ტრეკები „რა დონის დეგრადაცია აქტიურია და რატომ“.
• შექცევადობა: სწრაფი ნორმის დაბრუნება.

2) პრინციპები და საზღვრები

1. შეინახეთ მთავარი: მისი მთავარი SLA/SLO (მაგ., „შეძენა“, „ლოგინი“, „ძებნა“) პრიორიტეტია მეორეხარისხოვან (ავატარები, რეკომენდაციები, ანიმაციები).

• უსაფრთხოება, გადახდა, უფლებები - ყალბი (უკეთესია უარი თქვას დარღვევაზე).
• გაჟღენთილი შინაარსი, მინიშნებები, ავატარები - fail-open ფოლბეკით.
• 3. დროებითი ბიუჯეტები: ტაიმაუტები ზემოდან ქვემოთ (კლიენტი <კარიბჭე <მომსახურება). ამის შემდეგ - ჭიდაობის ნაცვლად დეგრადაცია უსასრულობამდე.
• 4. ღირებულების კონტროლი: დეგრადაციამ უნდა შეამციროს CPU/IO/ქსელის მოხმარება და არა მხოლოდ შეცდომების „დამალვა“.

3) დეგრადაციის დონე

3. 1 კლიენტი/UX

Skeletons/playsholders და მეორეხარისხოვანი ვიჯეტების „ზარმაცი“ დატვირთვა.
წვეულება UI: კრიტიკული ბლოკები იტვირთება, მეორადი - დამალვა/გამარტივება.
ქეში კლიენტის მხარეს: ბოლო-known-good (LKG), სადაც აღნიშნულია, რომ „მონაცემები შეიძლება მოძველდეს“.
Offline რეჟიმი: ბრძანებების ჯერი, რომელსაც აქვს გამეორება მოგვიანებით (იდემპოტენტობა!).

3. 2 Edge/CDN/WAF/API კარიბჭე

stale-while-revalidate: ჩვენ ვაძლევთ ქეშს, განაახლეთ ფონი.
Rate limiting & load shedding: გადატვირთვისას, ჩვენ ჩამოაგდეს ფონი/ანონიმური ტრაფიკი.
Geofence/გაწონასწორებული როუტინგი: ტრეფიკი მიედინება უახლოეს ჯანმრთელ რეგიონში.

3. 3 მომსახურების ფენა

Partial response: ჩვენ ვუბრუნებთ მონაცემების ნაწილს + 'warnings'.
Read-only რეჟიმი: მუტაციების დროებითი აკრძალვა (დროშები).
Brownout: რესურსის ინტენსიური ფირების დროებითი გათიშვა (რეკომენდაციები, გამდიდრება).
Adaptive Concurrency: დინამიურად ამცირებს პარალელიზმს.

3. 4 მონაცემები/ნაკადი

ქეში, როგორც TTL (დროებით) ჭეშმარიტების წყარო: „უკეთესია, ვიდრე არაფერი“.
მოდელების/ალგორითმების შემცირებული სიზუსტე.
Defer/queue: მძიმე დავალებების გადაცემა ფონში (outbox/job queue).
პრიორიტეტული ხაზები: კრიტიკული მოვლენები - ცალკეულ კლასში.

4) დეგრადაციის „კიბეები“ (playbooks)

• L0 (ნორმა) - L1: დამალვა პერსონალიზაციისა და ბანერების L2: გამორთეთ სინონიმები/ფაზის ძებნა L3: შეზღუდეთ პასუხის ზომა და ტაიმუტი 300 ms L4: მიეცით შედეგები 5 წთ-დან L5: „read-only & cached“ + გადაანგარიშების მოთხოვნის ხაზი.

• გამომწვევი: CPU- ს გადატვირთვა> 85% p95> სამიზნე, შეცდომები> ბარიერი, Kafka lag> ბარიერი, დამოკიდებულების flap.
• მოქმედებები: ჩართეთ დროშა X, შეამციროთ concurrence N- მდე, გადაიტანეთ წყარო Y ქეში.
• გასვლის კრიტერიუმები: 10 წუთი მწვანე მეტრიკა, რესურსების რეზერვი.

5) გადაწყვეტილების მიღების პოლიტიკა

5. 1 მცდარი ბიუჯეტი და SLO

გამოიყენეთ error-budget burn rate, როგორც brownout/shadding.
პოლიტიკა: „თუ burn-rate> 4 × 15 წუთის განმავლობაში - ჩართეთ L2 დეგრადაცია“.

5. 2 Admission control

ჩვენ შემოიფარგლება RPS- ით შემავალი კრიტიკულ გზებზე p99 გარანტიის უზრუნველსაყოფად და რიგების დაშლის თავიდან ასაცილებლად.

5. 3 პრიორიტეტიზაცია

კლასები: interactive> სისტემა> background.
პრიორიტეტების პერ-ტენანტი (Gold/Silver/Bronze) და სამართლიანობა (სამართლიანობა).

6) ნიმუშები და განხორციელება

6. 1 Load shedding (სერვერი)

შეაჩერეთ თხოვნები, სანამ ყველა რესურსს დაიკავებენ.
დაბრუნდით '429 '/' 503' s 'Retry-After' და პოლიტიკის ახსნა (მომხმარებლებისთვის).

Envoy (adaptive concurrency + circuit breaking)

yaml typed_extension_protocol_options:
envoy. filters. http. adaptive_concurrency:
"@type": type. googleapis. com/envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency gradient_controller_config:
sample_aggregate_percentile: 90 circuit_breakers:
thresholds:
- max_requests: 2000 max_pending_requests: 500 max_connections: 1000

6. 2 Brownout (დროებითი გამარტივება)

იდეა: შეამციროს „სიკაშკაშე“ (ღირებულება) fich, როდესაც რესურსები დასასრულს უახლოვდება.

kotlin class Brownout(val level: Int) { // 0..3 fun recommendationsEnabled() = level < 2 fun imagesQuality() = if (level >= 2) "low" else "high"
fun timeoutMs() = if (level >= 1) 150 else 300
}

6. 3 წვეულება და გაფრთხილებები

json
{
"items": [...],
"degradation": {
"level": 2,
"applied": ["cache_only", "no_personalization"],
"expiresAt": "2025-10-31T14:20:00Z"
}
}

6. 4 Stale-while-revalidate ზღვარზე (Nginx)

nginx proxy_cache_valid 200 10m;
proxy_cache_use_stale error timeout http_500 http_502 http_504 updating;
proxy_cache_background_update on;

6. 5 Read-only გადართვა (Kubernetes + დროშა)

yaml apiVersion: v1 kind: ConfigMap data:
MODE: "read_only"

The code should check MODE and block mutations with a friendly message.

6. 6 Kafka: backpressure და რიგების კლასები

შეცვალეთ heavy consumers უფრო მცირე max- ში. poll. ჩანაწერები ', შეზღუდეთ წარმოების batch-e

გაიზიარეთ „კრიტიკული“ და „ბულკის“ მოვლენები ტოპიკის/კვოტების მიხედვით.

6. 7 UI: graceful fallback

დამალეთ „მძიმე“ ვიჯეტები, აჩვენეთ კეში/ჩონჩხი და აშკარად აღნიშნეთ მოძველებული მონაცემები.

7) კონფიგურაციის მაგალითები

7. 1 Istio: პრიორიტეტული outlier + აუზი

yaml outlierDetection:
consecutive5xx: 5 interval: 10s baseEjectionTime: 30s maxEjectionPercent: 50

7. 2 Nginx: პირველი ფონის ტრაფიკი დანის ქვეშ

nginx map $http_x_priority $bucket { default low; high high; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s;
limit_req_status 429;

server {
location /api/critical/ { limit_req zone=perip burst=40 nodelay; }
location /api/background/ {
limit_req zone = perip burst = 5 nodelay; # stricter
}
}

7. 3 Feature flags / kill-switches

შეინახეთ დინამიური კონფიგურაცია (ConfigMap/Consul), განახლება გამოშვების გარეშე.
გააზიარეთ პერფორაცია და გლობალური დროშები, შეაფასეთ გააქტიურება.

8) დაკვირვება

8. 1 მეტრიკა

'degradation _ level {service' - მიმდინარე დონე.
'shed _ requests _ total {route, reason' - რამდენი დაიკარგა და რატომ.
'stale _ responses _ total' - რამდენი კეში გაიცემა.
`read_only_mode_seconds_total`.
`brownout_activations_total{feature}`.
არასწორი ბიუჯეტი: burn-rate, SLO დარღვევების წილი.

8. 2 ვაჭრობა

სპანების ატრიბუტები: 'degraded = true', 'level = 2', 'reason = upstream _ timeout'.
ლინკებს შორის retged/hedged მოთხოვნებს შორის, რათა ნახოთ წვლილი კუდებში.

8. 3 ლოგოები/ალერტები

დეგრადაციის დონის გადართვის მოვლენები ცვლილების მიზეზებთან და მფლობელთან.
ალერტას დონის „ჩამოსხმა“ (დეგრადაცია ძალიან დიდხანს გრძელდება).

9) რისკებისა და უსაფრთხოების მართვა

ნუ დაამახინჯებთ მონაცემთა ავთენტიფიკაციას/ავტორიზაციას/მთლიანობას: უმჯობესია უარი თქვათ.
PII- ის შენიღბვა შენარჩუნებულია ნებისმიერ რეჟიმში.
ფინანსები/გადასახადები: მხოლოდ idempotent ოპერაციები, მკაცრი ტაიმაუტები და გამოტოვება; ეჭვებით - read-only/hold.

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

მშვიდი დეგრადაცია მომხმარებლის მოთხოვნების გარეშე და ტელემეტრიის გარეშე.
Retray ქარიშხლები ნაცვლად load shedding და მოკლე Timauts.
სეგმენტის გარეშე გლობალური „გამაძლიერებლები“ უზარმაზარი blast radius.
ჩირაღდნის და „მსუბუქი“ ტრასების შერევა ერთ ქეში/რიგში.
მარადიული დეგრადაცია: brownout, როგორც „ახალი ნორმა“, დავიწყებული გამოსვლის კრიტერიუმები.
Stale-write: მოძველებული მონაცემების საფუძველზე ჩაწერის მცდელობები.

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

• განსაზღვრულია ღირებულების ბირთვი და კრიტიკული მომხმარებლის სცენარები.
• შედგენილია დეგრადაციის კიბეები სერვისების/სახლების საშუალებით ტრიგერებითა და გასასვლელებით.
• დაინერგა ტაიმაუტები/შეზღუდვები და სერვისის მხარე.
• განლაგებულია სარკინიგზო ლიმიტები და პრიორიტეტული ტრაფიკის კლასები.
• ხორციელდება partial response, read-only, stale-while-revalidate.
• ინტეგრირებულია feature flags/kill-switches აუდიტით.
• მეტრიკი/ტრეისი/ალერტები დეგრადაციისა და მიზეზების დონისთვის.
• რეგულარული თამაშის დღე სავარჯიშოები გადატვირთვის/გაუმართაობის სიმულაციით.
• დოკუმენტირებულია SLO და error-budget პოლიტიკა.

12) FAQ

Q: როდის უნდა აირჩიოთ brownout და როდის - shedding?
A: თუ მიზანია შეამციროს მოთხოვნის ღირებულება უარის თქმის გარეშე - brownout. თუ მიზანია დაიცვას სისტემა, როდესაც გამარტივებაც კი არ უწყობს ხელს, შესვლაა.

Q: აცნობეთ მომხმარებელს დეგრადაციის შესახებ?
A: კრიტიკული სცენარისთვის - დიახ („შეზღუდული რეჟიმი“). გამჭვირვალობა ამცირებს მხარდაჭერას და უკმაყოფილებას.

Q: შესაძლებელია ქეშის ჭეშმარიტების წყარო?
A: დროებითი - დიახ, აშკარა SLA და მოძველებული ეტიკეტებით. მუტაციებისთვის - აკრძალულია.

Q: როგორ არ არის „გატეხილი“ რეტრატორების გაკეთება?
A: მოკლე Timauts, ექსპონენტური backoff ერთად ჯიტერი, idempotence და მცდელობების ლიმიტი; მხოლოდ უსაფრთხო ოპერაციების გადატვირთვა.

13) შედეგები

მოხდენილი დეგრადაცია არის არქიტექტურული კონტრაქტი და კონტროლირებადი ოპერაციული რეჟიმების ერთობლიობა, რომელიც შედის მეტრიკისა და არასწორი ბიუჯეტის სიგნალებით. სწორად შემუშავებული კიბეები, მკაცრი ტაიმაუტები და შედევრები, ქეშის ფოლბეკი და ბრაუნუტი, პლუს ძლიერი დაკვირვება - და თქვენი პლატფორმა რჩება სასარგებლო და ეკონომიური, თუნდაც ქარიშხალში.