Нәзік деградация

1) Тәсілдің мәні

Әдемі деградация - бұл ресурстардың жетіспеушілігі, тәуелділіктің тоқтауы немесе жүктеменің шыңы кезінде жүйенің неғұрлым қарапайым, бірақ пайдалы режимге басқарылатын ауысуы. Мақсаты - екінші дәрежелі мүмкіндіктер мен сапаны құрбандық ете отырып, пайдаланушы үшін құндылық өзегін және платформаның орнықтылығын сақтау.

• Болжамдылық: алдын ала анықталған сценарийлер және тозу «сатылары».
• Зақымдану радиусының шектелуі: фич пен тәуелділікті оқшаулау.
• Бақылау: метрика, логия және трассировка «қандай тозу деңгейі белсенді және неліктен».
• Қайтымдылық: нормаға жылдам оралу.

2) Қағидаттар мен шекаралар

1. Ең бастысы: өзіңіздің негізгі SLA/SLO (мысалы, «сатып алу», «логин», «іздеу») - екінші дәрежелі (аватарлар, ұсынымдар, анимациялар) басымдықтан жоғары.

• Қауіпсіздік, төлемдер, құқықтар - fail-closed (бұзудан бас тарту жақсы).
• Кешімделген мазмұн, кеңестер, аватарлар - фолбэкті fail-open.
• 3. Уақытша бюджеттер: жоғарыдан төмен таймауттар (клиент <шлюз <сервис). Аяқталғаннан кейін - ретрациялардың орнына шексіз деградация.
• 4. Құнды бақылау: тозу қателерді жай ғана «жасыру» емес, CPU/IO/желісін тұтынуды төмендетуі тиіс.

3) Тозу деңгейлері

3. 1 Клиент/UX

Skeletons/плейсхолдерлер және екінші дәрежелі виджеттерді «жалқау» жүктеу.
Partial UI: сындарлы блоктар тиеледі, екіншілері жасырылады/жеңілдетіледі.
Кэш клиент жағында: «деректер ескіруі мүмкін» деген белгісі бар last-known-good (LKG).
Оффлайн режимі: кейінірек қайталанатын командалар кезегі (іспеттілік!).

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 (уақытша) бар ақиқат көзі ретінде кэш: «ештеңеге қарағанда шамамен жақсы».
Модельдер/алгоритмдердің төмендетілген дәлдігі (fast path vs accurate path).
Defer/queue: ауыр тапсырмаларды фонға ауыстыру (outbox/job queue).
Басым кезектер: сыни оқиғалар - жеке сыныпта.

4) «Сатылар» деградациясы (playbooks)

• L0 (норма) → L1: дербестендіруді және баннерлерді жасыру → L2: синонимдерді/фаззи-іздеуді өшіру → L3: жауап мөлшерін және таймаутты 300 мс → L4: 5 мин кэшінен нәтижелерді беру → L5: «read-only & cached only» + қайта есептеу сұрауларының кезегі.

• Триггерлер: CPU> 85% p95> мақсатты жүктеме, қателер> табалдырық, лаг Kafka> табалдырық, тәуелділік флап.
• Әрекеттер: X жалаушасын қосу, concurrency N дейін төмендету, Y көзін кэшке ауыстыру.
• Шығу өлшемдері: 10 минут жасыл метрика, ресурстар бойынша қор.

5) Шешім қабылдау саясаты

5. 1 Қате бюджет және SLO

error-budget burn rate дегенді brownout/шеддинг триггері ретінде пайдаланыңыз.
Саясат: «егер burn-rate> 4 × 15 минут ішінде - L2 деградациясын қосу».

5. 2 Admission control

p99-ға кепілдік беру және кезектердің қирауына жол бермеу үшін критикалық жолдарда кіріс RPS шектейміз.

5. 3 Басымдылығы

Кластар: interactive> system> background.
Пер-тенант басымдықтары (Gold/Silver/Bronze) және әділеттілік (fair share).

6) Паттерндер және өткізу

6. 1 Load shedding (серверлік)

Сұрауларды олар барлық ресурстарды пайдаланғанға дейін тастаңыз.
'429 '/' 503' -пен '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 (уақытша оңайлату)

Идея: ресурстар аяқталған кезде фич «жарықтығын» (құнын) төмендету.

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 Partial response және ескертулер

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-консумерлерді кіші 'max' дегенге ауыстырыңыз. poll. records ', продюсерлік batch-іі шектеңіз.
«Сыни» және «bulk» оқиғаларын топиктер/квоталар бойынша бөліңіз.

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 Трейсинг

Span төлсипаттары: 'degraded = true', 'level = 2', 'reason = upstream _ timeout'.
Артқы жағына үлесін көру үшін ретрациялар/hedged-сұраулар арасындағы сілтемелер.

8. 3 Логтар/Алерталар

Өзгерістердің себептерімен және иесімен деградация деңгейлерін ауыстырып қосу оқиғалары.
Деңгейдің «жабысуына» алерталар (тозу тым ұзақ сақталады).

9) Тәуекелдерді басқару және қауіпсіздік

Аутентификация/авторизация/деректер тұтастығын төмендетпеңіз: бас тарту жақсы.
PII бүркемелеу кез келген режимдерде сақталады.
Қаржы/төлемдер: тек қана демпотенттік операциялар, қатаң таймауттар және қайтарымдар; күмәнданған кезде - read-only/hold.

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

Пайдаланушыға ескертусіз және телеметриясыз тыныш деградация.
Ретрай-дауылдар load shedding және қысқа таймауттар орнына.
Сегментациясыз жаһандық «ажыратқыштар» - үлкен blast radius.
Бір кэштегі/кезектегі prod және «жеңілдетілген» жолдарды араластыру.
Мәңгілік тозу: brownout «жаңа норма» ретінде, ұмытылған шығу критерийлері.
Stale-write: ескірген деректер негізінде жазу әрекеттері.

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

• Құндылықтың өзегі және сыни пайдаланушы сценарийлері анықталған.
• Триггерлері мен шығыстары бар сервистер/үйлер бойынша тозу сатылары жасалды.
• Таймауттар/шектеулер енгізілді және server-side load shedding.
• rate limits және басым трафик кластары теңшелген.
• Іске асырылған partial response, read-only, stale-while-revalidate.
• Аудитпен біріктірілген feature flags/kill-switches.
• Тозу деңгейлері мен себептері үшін өлшемдер/трейсинг/алерттар.
• Шамадан тыс жүктемені/қателерді симуляциялайтын тұрақты game day жаттығулары.
• SLO және error-budget → деградация саясаты құжатталған.

12) FAQ

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

Q: Пайдаланушыға тозу туралы хабарлау керек пе?
А: Сыни сценарийлер үшін - иә (бейдж «шектеулі режим»). Ашықтық қолдау мен наразылықты төмендетеді.

Q: Кэшті ақиқат көзі етуге бола ма?
А: Уақытша - иә, анық SLA және ескіру белгілері кезінде. Мутация үшін - тыйым салынған.

Q: Ретрацияны қалай «сынбау» керек?
А: Қысқа таймауттар, джиттермен экспоненциалды backoff, икемділік және әрекеттер лимиті; тек қауіпсіз операциялар ретраит.

13) Қорытынды

Грациозды деградация - бұл сәулеттік келісімшарт және метрика және қате бюджет сигналдары бойынша қосылатын басқарылатын жұмыс режимдерінің жиынтығы. Дұрыс жобаланған баспалдақтар, қатаң таймауттар және шеддинг, кэш-фолбэктер және brownout, плюс күшті бақылау - және сіздің платформаңыз дауыл кезінде де пайдалы және үнемді болып қалады.