Automatyczne gojenie i samo-uzdrawianie

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

Automatyczne uzdrawianie nie jest „magią Kubernetes”, ale zbiorem dyscyplin: poprawne próbki i limity, kontrolowane przekaźniki, izolacja błędnych instancji, automatyzacja SLO i akcje runabook za pomocą przycisku/bota. Celem jest zmniejszenie MTTR bez zatłoczenia śniegu i utrzymanie p95/p99, płatności i TTW nawet w szczytowym momencie.

1) Zasady samouzdrawiania

1. Fail-fast & izolat: Szybko zidentyfikować i odizolować złe strąki/instancje.
2. Backoff + jitter: każdy retray/skala out - z wykładniczym opóźnieniem i jitter.
3. SLO-aware: automatyzacja jest włączona/ulepszona przy pomocy budżetu na błąd szybkiego spalania.
4. Idempotence: Powtarzanie transakcji jest bezpieczne (zwłaszcza płatności/kolejki).
5. Głębokość obrony: próbki, kontyngenty, limity, wyłącznik, wyrzut obwodu, próg prędkości, tryb degradacji.

2) Podstawa w Kubernetes

2. 1 Próbki: pobudzenie/gotowość/uruchamianie

startupProbe chroni przed przedwczesnym ponownym uruchomieniem ciężkich usług.
czytnikSonda określa gotowość do ruchu (ciepłe bufory/połączenia).
Sonda ponownie uruchamia zawieszone procesy.

yaml readinessProbe:
httpGet: { path: /health/ready, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 3

livenessProbe:
httpGet: { path: /health/live, port: 8080 }
initialDelaySeconds: 20 periodSeconds: 10 failureThreshold: 3

startupProbe:
httpGet: { path: /health/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 30

2. 2 Limity, WPB i priorytety

wnioski/limity wykluczają „hałaśliwy sąsiad”.
PodDis Budget (PDB) zapobiega spadkowi wszystkich strąków w tym samym czasie.

yaml apiVersion: policy/v1 kind: PodDisruptionBudget spec:
minAvailable: 2 selector: { matchLabels: { app: payments-api } }

Klasa dla ścieżek krytycznych (płatności, brama).

2. 3 Strategia ponownego uruchomienia i wdrożenia

„maxNiedostępne: 0” dla usług krytycznych; rollAktualizacja w małych przyrostach.
Pod Powinowactwo przypisuje strąki do węzłów/stref.

3) Autoskalowanie i skalowanie zdarzeń

HPA (procesor/metryka użytkownika)

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
minReplicas: 3 maxReplicas: 30 metrics:
- type: Resource resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }
- type: Pods pods:
metric:
name: http_requests_per_second target:
type: AverageValue averageValue: "50"

VPA

Wykorzystanie do pracy w środowisku/zadań partii; w prod-API - ostrożnie (ponownie uruchamia).

KEDA (kolejki/wydarzenia zewnętrzne)

Wyzwalacze dla Kafka lag, RabbitMQ, Redis, Prometheus żądania - zwiększamy konsumentów, gdy praca gromadzi.

4) Obrona sieci: wyłącznik i wybijanie „źle”

Wykrywanie Envoy/Istio outlier (идей)

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

Wyłącznik ogranicza jednoczesne żądania/połączenia, aby nie zrzucać zależności.

Ograniczenie stawki

Ograniczyć połączenia wejściowe/trasy PSP/dostawców gier, aby fala retras nie zwiększyła wypadku.

5) Retrai, timeouts i backoff z jitterem

Zasada: najpierw czas, potem wycofać się, zawsze z jitter i ograniczone próby.

python def backoff(attempt, base=0. 1, cap=2. 0):
import random, math sleep = min(cap, base (2 attempt))
jitter = random. uniform(0, sleep 0. 4)
return sleep + jitter

Dla płatności - idempotent keys + deduplication.
Dla kolejek - martwe litery i odroczone ponowne próby.

6) Samouzdrawianie w kolejkach/strumieniowanie

Alerty DLQ + wzrostu; odizolowane ponowne przetwarzanie.
Opóźnienie sterowania: konsumenci na automatyczną skalę (KEDA), ciśnienie wsteczne dla producentów.
Dokładnie raz/co najmniej raz - wybrany świadomie; Operacje są idempotentne.

7) Gotówka i rozgrzewka

Klucze wersji ('v2:') dla bezpiecznej niepełnosprawności/cofnięcia.
Ciepłe baseny połączeń z DB/PSP; rozgrzewka przed przełączaniem (niebiesko-zielony/kanarkowy).
Stale-while-revalidate w celu zmniejszenia „zimnych” trafień bazy danych.

8) Automatyczne remediowanie przez SLO (działania sygnałowe)

• Zatrzymać kanaryjski/rollback мра fast-burn.
• Skala pracowników o wzroście „kolejki _ lag _ seconds”.
• Włączanie trybu degradacji (uproszczony UX, wyłączanie ciężkich funkcji).
• Przełączanie trasy PSP, gdy skoczy czas.
• Aktywuj funkcję-flag kill-switch.

yaml alert: WithdrawalsQueueLag labels: { action: "scale_workers", target: "withdrawals-consumers", by: "+5" }

9) Tryb degradacji (wdzięczna degradacja)

Uprość interfejs użytkownika (mniej żądań), wyłączyć „drogie” widżety.
Więcej buforowania, mniej wentylatorów/agregacji.
Dla LLM/zalecenia - zmniejszyć rozmiar kontekstu/modelu, włącz „szybką ścieżkę”.

10) Podejście GitOps do automatycznych poprawek

Wszystkie zasady i parametry automatycznej naprawy (timeouts, thresholds) są w Git.
Każda automatyczna akcja tworzy adnotację w Grafanie i wpis w dzienniku zmian.
Zasady kanaryjskie i bramy SLO są również kodem.

11) Inżynieria chaosu: sprawdzenie, czy prace lecznicze

Zastrzyki awarii: opóźnienia sieciowe, spadające słuchy, awaria emulatora PSP, opóźnienie kolejki.
Scenariusze dnia gry: mierzymy MTTR, jakość akcji automatycznych, obecność artefaktów.
Wyniki → aktualizacja runabooks, progi, phicheflags.

12) Obserwowalność do automatycznego uzdrawiania

Przykłady: Szybki skok z metryki p95 do toru.
Dzienniki z 'trace _ id' i polami' retry ',' attempt ',' degrade _ mode = true '.
Zwolnienie porównaj deski rozdzielcze (stabilne vs canary), karta SLO.
Audyt akcji automatycznych: who/what/when, source metrics, result.

13) Bezpieczeństwo i zgodność

Brak tajemnic w dziennikach/metrykach auto-remediacji.
W przypadku czynności płatniczych - podwójne potwierdzenie/rola.
Geo/PII - nie zabieraj ruchu do „niewłaściwego” regionu z feilover.

14) Praktyczne szablony

Reguła Istio - pula połączeń & outlier

yaml trafficPolicy:
connectionPool:
http: { http1MaxPendingRequests: 1000, maxRequestsPerConnection: 100 }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

Flagger - kanaryjski z automatycznym spłukiwaniem/wałkiem

yaml analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke

KEDA Sctp Object - Kafka lag

yaml triggers:
- type: kafka metadata:
topic: withdrawals bootstrapServers: broker:9092 consumerGroup: w-consumers lagThreshold: "5000"

15) Lista kontrolna wdrażania

1. Konfigurowane są punkty końcowe uruchamiania/gotowości/chęci i zdrowia.
2. Limity/żądania zasobów + PDB/anty-powinowactwo.
3. HPA/KEDA dla API i pracowników; mierniki opóźnienia/przepustowości.
4. Wyłącznik, wyrzut obwodowy, ograniczenie prędkości w bramce/siatce.
5. Retrai z backoff + jitter, idempotence transakcji płatniczych.
6. Bufory wersji i tryb degradacji.
7. Bramki SLO → automatyczne działania (rollback/scale/redoute/kill-switch).
8. Kod polityki GitOps + działania audytowe, publikacja adnotacji.
9. Testy chaosu i dzień gry na kluczowych scenariuszach.
10. MTTR/Alert Deski rozdzielcze jakości i raporty auto-remediacji.

16) Anty-wzory

Livity „paznokcie” proces ze względu na zależność czasu → klapowanie.
Retrai bez czasu/jitter → burza wniosków.
HPA przez CPU z usług zależnych od IO → „nigdzie”.
Wspólna pamięć podręczna bez wersji podczas wałków → uszkodzenie danych.
Automatyczne działania bez audytu/URL Runbook.
Brak DLQ/lag metrics → cicha akumulacja zadłużenia.
Mieszanie auto-gojenie i „problemy z ukrywaniem”: automatyka leczy objawy, korzeń nie jest eliminowany → powtarzanie incydentów.

Podsumowanie

Samouzdrawianie to dyscyplina inżynieryjna: wysokiej jakości próbki i limity, kompetentne przekaźniki i izolacje, automatyczne działania na sygnałach SLO, a także kontrole i audyty chaosu. Ten kontur sprawia, że platforma jest odporna na awarie, cięcia MTTR i oszczędza kluczowe metryki iGaming - p99, konwersji płatności i TTW - nawet w najgorętszych godzinach.