Chaos Engineering: жүйелердің тұрақтылығы

Chaos Engineering: жүйелердің тұрақтылығы

1) Неліктен хаос-инженерия

• жүйенің мінез-құлқы туралы гипотезаларды тексеру және SLO валидациялау;
• жасырын SPOF, қате таймауттар/ретрациялар, каскадты әсерлерді табу;
• командаларды жаттықтыру: game-days, runbook's, коммуникация;
• «жақсыға үміттенеміз» емес, «әдеттегі тұрақтылық» мәдениетін қалыптастыру.

Маңызды: Chaos Engineering «бәрін сындыруға» ≠. Бұл ғылыми әдіс: steady-state → гипотеза → эксперимент → қорытындылар → жақсарту.

2) Эксперименттің базалық циклі

1. Steady-state (базалық желі): қандай SLI тұрақты? (мысалы, табыс ≤ 500 мс 99. 95%).
2. Гипотеза: бір AZ p95 жоғалтқан кезде <10% өседі, ал қолжетімділік 99 ≥. 9%.
3. Эксперимент: шектеулі blast radius және stop-критерийлері бар жоспарланған фолт.
4. Бақылау: метриктер/трейстер/логи, burn-rate SLO, бизнес-SLI (мысалы, табысты депозиттер).
5. Жақсартулар: табыстарды тіркейміз, таймауттарды/лимиттерді/маршрутизацияны өзгертеміз, runbook жаңартамыз.
6. Автоматтандыру/регресс: кестеде қайталаймыз, CI/CD және game-days күнтізбелеріне қосамыз.

3) Қауіпсіздік қанаттары (safety first)

Blast radius: тар жолдан бастаймыз - бір pod/инстанс/маршрут/namespace.
Guardrails: SLO burn-rate (жылдам/баяу), ретра лимиттері, QPS шектеуі, инцидент бюджеті.
Stop-критерийлер: «егер error-rate> X% немесе p99> Y мс N минут - бірден stop және rollback».
Терезелер: on-call жұмыс сағаттары, ескертілген стейкхолдерлер, мұздатылған релиздер.
Коммуникация: IC/Tech lead/Comms, нақты арна (War-room), хабарламалар үлгісі.

4) Бас тарту кластары және гипотеза идеялары

Желі: кідіріс/джиттер/жоғалту, порттардың ішінара тармақталуы, сервистер/PSP арасындағы «жарқылдақ» байланыс.
Компьютер/тораптар: процестерді өлтіру, CPU қызып кету, файлдық дескрипторлардың таусылуы, қосылыстардың тар пулдары.
Қоймалар және БД: дискілердің latency өсуі, lag репликалары, бір шоқтың/көшбасшының тоқтауы, split-brain.
Тәуелділік: сыртқы API деградациясы, провайдерлердің лимиттері, 5xx/429 жарылыс.
Өзгерістерді басқару: сәтсіз релиз, жаман фича-жалау, partial rollout.
Периметр: CDN деградацияланады, DNS/Anycast дрифт, WAF/бот-қорғау сәтсіздігі.
Аймақ/AZ: толық жоғалту немесе «ішінара» инцидент (сәл нашар және болжанбайтын).

5) Құралдар мен техникалар

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Бұлттар: AWS Fault Injection Simulator (FIS), бұлттар жанындағы Fault Domains.
Желі/прокси: Toxiproxy (TCP-улы), tc/netem, iptables, Envoy fault (delay/abort), Istio fault injection.
Процестер/тораптар: 'stress-ng', cgroups/CPU-throttle, disk fill.
Трафик-бағыттау: GSLB/DNS weights, canary/blue-green фейловер-тексеру үшін ауыстырып қосу.

6) Сценарий үлгілері (Kubernetes)

6. Маршрутта 1 Delay/abort (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

Гипотеза: клиенттік таймауттар/ретраилер және CB p95 <300 мс және error-rate <0 ұстап тұрады. 5%.

6. 2 Pod Kill (Chaos Mesh)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

Гипотеза: теңгеруші мен HPA p99> 20% өсімсіз бір дананың loss орнын толтырады.

6. 3 Желілік хаос (ДБ кідірісі)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

Гипотеза: пулдар/таймауттар/кэш әсерін төмендетеді; p95 төлемдер SLO ≤ қалады.

6. 4 Дискіні толтыру

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

Гипотеза: логтардың/квоталардың/алерталардың ротациясы маршруттардың тозуына дейін жұмыс істейді.

7) K8s тыс эксперименттер

7. 1 Toxiproxy (жергілікті/интеграциялық)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7. 2 Envoy HTTP fault (периметр/mesh)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7. 3 AWS FIS (идея үлгісі)

Auto Scaling Group-та N% EC2 «өлтіру» тәжірибесі, EBS-latency-ді жасанды түрде көтеру, NAT-GW-ді бір AZ-да өшіру.
CloudWatch SLO-метриктер бойынша орнатылған тоқтату өлшемдері.

8) Хаос кезіндегі бақылау өлшемдері

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
Критикалық бағыттар бойынша RED-модель (Rate, Errors, Duration).
Пулы: p95, utilization қосылысын күту.
БД: lag реплика, locks, дрейф p95 сұрау.
Желі: retransmits, RTT, dscp/ecn мінез-құлық.
Бизнес-SLI: транзакциялардың табысы (депозиттер/чекаут), қайтарымдар/қателер%.
Трассировка: таңдамалы трестер (exemplars), релиз-аннотацияларды корреляциялау.

9) SLO/Error-budget интеграциясы

Қателіктер бюджетінің шеңберінде эксперименттерді жоспарлаңыз: хаос тоқсандық мақсаттарды «бұзбауы» тиіс.
Burn-rate алерта автоматты kill-switch ретінде.
Есептілік: «қанша бюджетті өртеген», «қандай девиациялар steady-state».

10) Game-days (жаттығулар)

Сценарий: қысқаша аңыз (мысалы, «өңір-Шығыс жоғалды»), инъекция қадамдары, SLO мақсаттары, рөлдері, уақыты.
Бағалау: RTO/RPO нақты, коммуникация сапасы, runbook дұрыстығы.
Ретро: иелерімен және мерзімдерімен жақсартулар тізімі, құжаттаманы/дашбордтарды жаңарту.

11) Автоматтандыру және CI/CD

Smoke-chaos: әрбір релизде staging бойынша қысқа тесттер (мысалы, бір маршрутқа 1 pod-kill + 200 mс delay).
Түнгі/апталық: есеппен неғұрлым ауыр сценарийлер (5-15 мин).
Промо-гейттер: егер р95/қателер> canary табалдырығы - авто-кері қайту.
Эксперименттер каталогы бар репозиторийлер (YAML + runbook + SLO-thresholds).

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

«Сүйенішсіз сынықтарды сындыру»: stop-критерийлер жоқ, on-call → нағыз оқыс оқиғаның қаупі жоқ.
Процестің орнына бір реттік акция.
steady-state жоқ хаос: табыс/сәтсіздік деп есептеген не түсініксіз.
Кідірістерді инъекциялау кезінде өздігінен DDoS артық ретраялары.
Бизнес-SLI елемеу: төлемдердің/тапсырыстардың сәтсіздігі кезіндегі «техникалық» табыстар.
Постталдаудың және жақсартулар иелерінің болмауы.

13) Енгізу чек-парағы (0-45 күн)

0-10 күн

steady-state SLI (пайдаланушы + бизнес).
Құралды таңдау (Chaos Mesh/Litmus/Toxiproxy/FIS).
Сүйеніштерді сипаттау: blast radius, stop-критерийлер, терезелер, рөлдер.

11-25 күн

Алғашқы эксперименттерді іске қосу: pod-kill, 100-200 мс delay критикалық апстримге, drop 1% пакеттер.
burn-rate алаңдарын баптау, kill-switch-ті stop-критерийлерімен байланыстыру.
Бірінші game-day өткізу, ретро және фикстер жинау.

26-45 күн

AZ/тәуелділік деңгейін қосу (сыртқы PSP, БД-lag).
staging-те nightly-хаосты автоматтандыру; маусымдық сценарийлер (шыңдар) дайындау.
/ SRE нұсқауы үшін эксперименттер каталогы және тұрақты есептер.

14) Жетілу метрикасы

Сыни бағыттардың 80% ≥ сипатталған эксперименттер мен steady-state метрикасы бар.
Авто kill-switch p99/error-rate шегінен асқанда іске қосылады.
Тоқсан сайын - AZ/өңір деңгейіндегі game-day; ≥ 1 рет/ай - тәуелділіктің мақсатты сценарийі.
MTTR жақсартулар циклынан кейін төмендейді, «релиздік инцидент» корреляциясы азаяды.
Нақты іркілістер кезінде «күтпеген» құлдыраулар үлесі → нөлге ұмтылады.
Дашбордтар KPI (burn-rate, қалпына келтіру уақыты, табысты DR-әрекеттердің үлесі) ретінде «тұрақтылықты» көрсетеді.

15) guardrails мысалдары және stop триггерлері

Stop: 'http _ req _ failed> 1%' 3 минут, 'p99> 1000 мс' 3 терезе, 'deposit _ success <99. 5%`.
Blast radius төмендеуі: манифестің авто-кері қайтуы, GSLB таразыларының қайтуы, fault-инъекцияларды ажырату.
Stop пәрмені: себептері жазылған бір түймешік/скрипт.

16) Мәдениет және процестер

Хаос - бұл «экстрим» емес, SRE ырғағының бір бөлігі.
Ашық есептер, осалдықтарды тану, түзетуші әрекеттер.
On-call оқыту, клиенттермен/әріптестермен коммуникацияларды симуляциялау.
SLA/SLO-мен және бюджеттермен байланыс: хаос сенімділікті бұзбай, көтеруі тиіс.

17) Қорытынды

Chaos Engineering «тоғызға үміт» дәлелденетін тұрақтылыққа айналдырады. steady-state формуласын жасаңыз, сүйеніштерді қойыңыз, шағын және бақыланатын бөлшектерді сындырыңыз, SLO және бизнес-SLI қадағалаңыз, жақсартуларды белгілеңіз және автоматтандырыңыз. Сонда нақты іркілістер басқарылатын оқиғаларға айналады: болжамды RTO, қорғалған error-budget және команданың үрей тудырмай әрекет етуге дайындығы.