Wdzięczna degradacja

1) W przedmiocie istoty podejścia

Wdzięczna degradacja jest zarządzanym przejściem systemu do prostszego, ale użytecznego trybu, gdy zasoby są rzadkie, zależność nie działa, lub szczyty obciążenia. Celem jest zachowanie rdzenia wartości użytkownika i odporności platformy poprzez poświęcenie drugorzędnych możliwości i jakości.

• Przewidywalność: wstępnie zdefiniowane scenariusze i „drabiny” degradacji.
• Promień trafienia ogranicznika: Odizolowane cechy i ograniczenia.
• Obserwowalność: metryki, kłody i ślady „jaki poziom degradacji jest aktywny i dlaczego”.
• Odwracalność: szybki powrót do normy.

2) Zasady i granice

1. Zapisz najważniejsze: główny SLA/SLO (np. „zakup”, „login”, „search”) - priorytet jest wyższy niż drugorzędny (awatary, rekomendacje, animacje).

• Bezpieczeństwo, płatności, prawa - nieudane zamknięcie (lepsza odmowa niż naruszenie).
• Zawartość buforowana, wskazówki, awatary - fail-open z folback.
• 3. Budżety czasu: odgórne czasy (klient
• 4. Kontrola kosztów: degradacja powinna zmniejszyć zużycie procesora/IO/sieci, a nie tylko „ukryć” błędy.

3) Poziomy degradacji

3. 1 Klient/UX

Szkielety/łożyska i „leniwe” ładowanie wtórnych widżetów.
Częściowe interfejs użytkownika: klocki krytyczne są ładowane, bloki wtórne są ukryte/uproszczone.
Pamięć podręczna po stronie klienta: last-known-good (LKG) oznaczona jako „dane mogły stać się nieaktualne”.
Tryb offline: kolejka poleceń z powtórzeniem później (idempotence!).

3. Brama 2 krawędzi/CDN/WAF/API

stale-while-revalidate: dajemy pamięć podręczną, aktualizujemy tło.
Ograniczenie prędkości i przelewanie obciążenia: podczas przeciążania zresetuj tło/anonimowy ruch.
Geofence/ważone trasy: ruch jest kierowany do najbliższego zdrowego regionu.

3. 3 Warstwa serwisowa

Częściowa odpowiedź: powrót części danych + „ostrzeżenia”.
Tryb tylko do odczytu: czasowo zakazać mutacji (flag).
Brownout: tymczasowe wyłączanie funkcji zasobochłonnych (zalecenia, wzbogacanie).
Współzależność adaptacyjna: dynamicznie zmniejszać współistnienie.

3. 4 Dane/Streaming

Cache jako źródło prawdy z TTL (tymczasowo): „lepsze w przybliżeniu niż nic”.
Zmniejszona dokładność modeli/algorytmów (szybka ścieżka vs dokładna ścieżka).
Defer/kolejka - przenieść ciężkie zadania do tła (outbox/job queue).
Kolejki priorytetowe: wydarzenia krytyczne - w osobnej klasie.

4) Drabiny degradacyjne (playbooks)

• L0 (normalny) → L1: ukryj personalizację i banery → L2: wyłączyć synonimy/zamazane wyszukiwanie → L3: ograniczyć rozmiar odpowiedzi i czas do 300 ms → L4: podać wyniki z pamięci podręcznej 5 minut → L5: „tylko do odczytu i buforowania” + kolejka wniosków o ponowne obliczenie.

• Wyzwalacze: przeciążenie procesora> 85% p95> cel, błędy> próg, Kafka> flaga progowa, flaga zależności.
• Akcje: włączyć flagę X, obniżyć równoległość do N, przełączyć źródło Y do pamięci podręcznej.
• Kryteria wyjścia: 10 minut zielonych metryk, zagłówek zasobów.

5) Polityka decyzyjna

5. 1 Błędny budżet i SLO

Użyj szybkości spalania błędu-budżetu jako wyzwalacza brownout/shedding.
Polityka: „jeśli szybkość spalania> 4 × w ciągu 15 min - włącz degradację L2”.

5. 2 Kontrola wjazdu

Ograniczamy przychodzący RPS na ścieżkach krytycznych, aby zagwarantować p99 i zapobiec upadkowi kolejki.

5. 3 Priorytety

Klasy: interaktywny> system> tło.
Priorytety dla jednego najemcy (złoto/srebro/brąz) i sprawiedliwość (sprawiedliwy udział).

6) Wzory i implementacje

6. 1 Przelanie obciążenia

Zrzuć prośby, zanim wezmą wszystkie zasoby.
Zwrot „429 ”/„ 503” z „Retry-After” i wyjaśnienie polityki (dla klientów).

Wysłannik (współistnienie adaptacyjne + złamanie obwodu)

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 (tymczasowe uproszczenie)

Pomysł: aby zmniejszyć „jasność” (koszt) funkcji, gdy zasoby się kończą.

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 Częściowa reakcja i ostrzeżenia

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

6. 4 Przewlekłe przedłużenie ważności na krawędzi (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 Przełącznik tylko do odczytu (Kubernetes + flaga)

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

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

6. 6 klas Kafka: klas podciśnienia i kolejki

Przełączyć ciężkich konsumentów na mniejsze 'max. sondaż. rejestrów ", limitu partii produkcyjnej i.
Oddzielne zdarzenia „krytyczne” i „luzem” według tematu/kwoty.

6. 7 interfejs użytkownika: graceful fallback

Ukryj „ciężkie” widżety, pokaż pamięć podręczną/szkielet i wyraźnie etykietować przestarzałe dane.

7) Przykłady konfiguracji

7. 1 Istio outlier + puli priorytetowe

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

7. 2 Nginx: Pierwszy ruch tła pod nożem

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 flagi funkcji/wyłączniki zabijania

Przechowywać w konfiguracji dynamicznej (ConfigMap/Consul), aktualizować bez zwolnienia.
Oddzielna funkcja i globalne flagi, aktywacje dziennika.

8) Obserwowalność

8. 1 Metryka

„degradation _ level {service}” oznacza obecny poziom.
'completed _ requests _ total {route, reason}' - ile jest zresetowane i dlaczego.
'stale _ responses _ total' - ile pamięci podręcznej zostało wydane.
'read _ only _ mode _ seconds _ total'.
'brownout _ activations _ total {feature}'.
Błędny budżet: wskaźnik oparzeń, odsetek naruszeń SLO.

8. 2 Odwzorowanie

Atrybuty przęseł: 'degraded = true', 'level = 2', 'reason = upstream _ timeout'.
Powiązania między przekaźnikami/zapytaniami zabezpieczanymi, aby zobaczyć wkład w ogony.

8. 3 dzienniki/wpisy

Degradacja poziomu przełączania zdarzeń ze zmianami przyczyn i właściciela.
Wpisy do „przyklejania” poziomu (degradacja trwa zbyt długo).

9) Zarządzanie ryzykiem i bezpieczeństwo

Nie degraduj uwierzytelniania/autoryzacji/integralności danych: lepsza awaria.
Maskowanie PII jest zachowane w dowolnym trybie.
Finansowanie/płatności: tylko transakcje idempotentne, rygorystyczne terminy i zwroty; wątpliwe - tylko do odczytu/wstrzymania.

10) Anty-wzory

Cicha degradacja bez wywoływania u użytkownika i bez telemetrii.
Burze retray zamiast przelania ładunku i krótkie czasy.
Globalne „przełączniki” bez segmentacji - ogromny promień wybuchu.
Mix prod i lekkie ścieżki w tym samym pamięci podręcznej/kolejce.
Wieczne degradacja: brownout jako „nowy normalny”, zapomniane kryteria wyjścia.
Stale-write: próby zapisu w oparciu o stałe dane.

11) Lista kontrolna wdrażania

• Zdefiniowane podstawowe wartości i krytyczne scenariusze użytkownika.
• Drabiny degradacyjne według usług/domeny z wyzwalaczami i wyjściami są kompilowane.
• Wprowadzono ograniczenia czasowe/ograniczenia czasowe i przesuwanie obciążenia po stronie serwera.
• Limity stawek i priorytetowe klasy ruchu są konfigurowane.
• Wdrożona częściowa reakcja, tylko do odczytu, nieustannie przedłużająca obowiązywanie.
• Zintegrowane flagi funkcji/wyłączniki zabijania z audytem.
• Wskaźniki/śledzenie/wpisy dotyczące poziomów i przyczyn degradacji.
• Regularne ćwiczenia dnia gry z symulowanym przeciążeniem/awariami.
• SLO udokumentowane i błędny budżet → polityka degradacji.

12) FAQ

P: Kiedy wybrać brownout i kiedy przelać?
Odp.: Jeśli celem jest zmniejszenie kosztów żądań bez awarii - brownout. Jeśli celem jest ochrona systemu, gdy nawet uproszczenie nie pomaga, przelanie logowania.

P: Czy zgłaszam użytkownikowi degradację?
Odp.: Dla scenariuszy krytycznych - tak (odznaka „ograniczony tryb”). Przejrzystość zmniejsza wsparcie i niezadowolenie.

P: Czy pamięć podręczna może być źródłem prawdy?
Odp.: Tymczasowo - tak, z wyraźnymi SLA i etykietami starzenia. Dla mutacji - zabronione.

P: Jak nie zrobić retrai „złamane”?
Odp.: Krótkie timeouts, wykładnicze backoff z jitter, idempotencja i próba limit; przekwalifikować tylko bezpieczne operacje.

13) Kwoty całkowite

Wdzięczna degradacja to kontrakt architektoniczny i zestaw kontrolowanych trybów działania, włączonych sygnałami metryki i błędnym budżetem. Odpowiednio zaprojektowane schody, rygorystyczne timeouts i shedding, cashback i brownout, plus silna obserwowalność - a platforma pozostaje przydatna i ekonomiczna nawet w burzy.