Chaos Engineering

1) Базалық қағидаттар

Steady State бастапқы гипотеза ретінде. Норманы анық анықтаңыз (мысалы: p95 <200 мс. 3%, сыни флоу табыстылығы> 99. 5%).
Оқшауланған айнымалылар. Әсерді және жақсартуды себепті байланыстыру үшін бір уақытта мүмкіндігінше бір факторды өзгертіңіз.
Градустық. Қауіпсіз ортада шағын амплитудалардан бастаймыз → қамту мен қарқындылықты кеңейтеміз.
Guardrails. SLO/қателер/бюджет қателері бойынша нақты тоқтау шарттары.
Қайталануы. Эксперимент детерминирленген түрде орындалуы тиіс (скрипттер/манифесттер/IaC).
Этика және қауіпсіздік. Тәуекелді эксперименттерде ешқандай нақты дербес деректер мен қаржылық транзакциялар жоқ.

2) «Тұрақты жағдай» дегеніміз не?

• Негізгі эндпоинттердің жасырындылығы p50/p95/p99.
• Сәтті транзакциялардың үлесі және күрделі жолдардың конверсиясы.
• Error rate, таймауттар, «shed» сұраулардың үлесі (қаныққанда үзілген).
• Өзін-өзі қалпына келтіру жылдамдығы (MTTR), ретраға төзімділік (дауылсыз).
• Домен инварианттары: «баланста кемшіліктердің» болмауы, бір рет орындалған төлемдер, есептік тәуліктердің консистенттілігі және т.б.

3) Инъекция каталогы («сынамыз»)

Желі: кідіріс, джиттер, жоғалту/қайталау, өткізу қабілетінің шектелуі, TLS-үзілулер, DNS-флаппинг.
Есептеулер: CPU жүктемесі, жадыға қысым/GC, дескрипторлардың таусылуы, clock skew.
Сақтау орны: жоғары p95 I/O, ENOSPC, бас тарту/реплика, split-brain, созылмалы fsync.
Тәуелділіктер: 5xx/429, «баяу табыс», сыртқы API деградациясы, rate-limit.
Деректер: дубль/хабар жіберу, out-of-order, «лас» жазбалар, нұсқа қайшылығы.
Операциялар: сәтсіз релиз/ , фича-жалау, мерзімі өткен сертификат, кілттің ротациясы.
Адамдар мен процестер: жауаптылардың қол жетімсіздігі, қолмен апруның кідіруі, дұрыс емес runbook.

4) Эксперимент дизайны (шаблон)

1. Гипотеза: «Негізгі API p99 валюталық сервисіне + 300 мс кезінде <450 мс, брейкер ашылады, stale-жауап 15 минут бұрын ≤ беріледі».
2. Инъекция: істен шығу бейіні (түрі/амплитудасы/ұзақтығы) және нысаналы контур.
3. Метриктер/лог-тегтер: 'chaos. experiment_id`, `phase=inject|recover`.
4. Guardrails: abort кезінде 'error _ rate> 2%' немесе p99> SLA × 2 минуттан артық 1.
5. Нәтижелер/қорытынды: бақылаулардың, бағалардың, жақсартулардың тізімі, жұмыс жоспары және қайталап өту.

5) Бақылау: не міндетті

Трейсинг: тәуелділік арқылы сұрау жолы; деградациясы бар сегменттер белгіленген.
Ресурстардың өлшемдері: CPU, heap/GC, FD, дискілік IOPS/lat, желілік bandwidth, кезектердің тереңдігі.
Бизнес-метрика: операциялардың конверсиясы/табысы, өтелген транзакциялардың үлесі.
Оқиғалар логтары: брейкерлерді ашу/жабу, ретра және олардың бюджеті, ДБ көшбасшысын ауыстыру.
Эксперимент панелі: guardrails табалдырығы мен «қызыл түймешігі» бар live-дашборд.

6) Guardrails және қауіпсіздік

Техникалық: жоғарғы шектері error rate/latency, табысты операциялар үлесінің төмендеуі, DLQ өсуі.
Ұйымдастырушылық: on-call тартылған уақыт терезесі, «бір аймақ - бір эксперимент» қағидаты.
Деректер/комплаенс: тек синтетика немесе иесiздендiрiлген жиынтықтар; реттеуіштің бұзылуына әкелетін тестілерге тыйым салу.
Кері қайтару: дайын рәсімі rollback/disable ту/жұмсақ drain трафик.

7) Көрінуі тиіс орнықтылық паттерндері

Таймаут-бюджеттер және джиттер ретрайлары (дауылсыз).
Жартылай ашылатын (half-open) және экспоненциалды қалпына келтірілетін Circuit Breaker.
Bulkheads: сындылығы бойынша пулдарды оқшаулау (төлемдер vs талдау).
Backpressure және rate-limit: төмен басымдықты болжамды ажырату.
coalescing кэші, «қызу дауылынан» қорғау.
Жанама әсерлер мен сағалардың орнын толтыратын әсерлермен біркелкілігі.
Деректерді қалпына келтіру үшін кворумдар, фейловер және анти-энтропия.

8) Сценарий үлгілері (скетч)

8. 1 Баяу тәуелділік (YAML)

yaml experiment: slow-downstream target: svc:api inject:
dependency:
name: currency mode: add_latency p95_ms: 300 duration: 10m guardrails:
error_rate: "< 1. 5%"
p99_latency: "< 450ms"
expectations:
breaker_open: true stale_data_served: "<= 15m"

8. 2 БД көшбасшысының жоғалуы

Инъекция: көшбасшыны тоқтату/мәжбүрлеп қайта сайлау.
Күту: жазбаларға уақытша тыйым салу, кворумнан оқу, WAL/Outbox сақталуы, автоматты түрде репликалауды қалпына келтіру, қос жазбаның болмауы.

8. 3 ENOSPC лог-дискіде

Инъекция: 95-100% дейін дискіні толтыру.
Күту: логтардың авариялық ротациясы, сыни журналдардың сақталуы, сыни емес фичтерді өшіру, алерт және авто-ремедиация.

8. 4 Burst-трафик + шейдинг

Инъекция: ыстық эндпоинт бойынша 5 минутқа 3 RPS ×.
Күту: төмен басымдықты лақтыру, тұрақты p95 «ядро», ретрайлер каскадының болмауы.

9) CI/CD автоматтандыру

Әрбір релизге арналған стейджердегі Chaos-smoke (қауіпсіз амплитудаларға қысқа инъекциялар).
Эксперименттер каталогы бойынша түнгі аралықтар (матрица сервистері × істен шығу түрлері).
Гейттер: егер «тұрақтылық табалдырықтан төмен» болса (мысалы, табысты fallback үлесі <95%), релиз бұғатталады.
Артефактілер: есеп, трейстер, CPU/heap флеймграфтары, метриктер мен пішіндердің снапшоттары.

10) Гейм күндері (Game Days)

• Рөлдері: эксперимент жүргізушісі, метриктерді бақылаушы, кері қайтару операторы, бизнес өкілі.
• Сценарийлер: кэштің тозуы, АЗ/фейловер өңірінің ішінара істен шығуы, «нашар релиз», сыртқы провайдердің қол жетімсіздігі.
• Нәтижелер: runbook бағдарламасында табылған олқылықтар, тәуекелдерді жақсарту, SLO және ретра бюджеттерін түзету.

11) Деректер, оқиғалар және ML үшін хаос

Деректер ағыны: телнұсқаларға тесттер, рұқсатнамалар, out-of-order, кідірістер; идемпотенттік консумерлер мен DLQ-стратегияларды тексеру.
Сақтау орындары: индекстердің тозуы, hot-partition, блоктау қайшылығы, лагтың астында репликалау.
ML: фич-стордың кідіруі, baseline-модельге кері шегіну, кіріс деректері сапасының нашарлауы (drift) - жүйе құлдырайтын емес, «жұмсақ келеңсіз» болуы тиіс.

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

Бақылаусыз хаос: сіз «соқырсыз», қорытындылар алыпсатарлық.
Стейджерсіз және гвард-рейлерсіз бірден инъекция.
«Бір үлкен эксперимент» бәріне бірден - нақты не жұмыс істегені белгісіз.
Гипотезасыз және фикстен кейінгі ретестсіз жүйесіз хаос-акциялар.
Инфрақұрылымға ғана шоғырлану - бизнес-инварианттар ұмыт қалды.
Адамдарды/процестерді елемеу: алерта, on-call, runbook - жүйенің бір бөлігі.

13) Практиканың жетілгендігі (модель)

1. Ad-hoc: жергілікті бір реттік инъекциялар.
2. Стейдж-хаос: сценарийлер каталогы, қайталанатын прогондар, дашбордтар.
3. Релиз-хаос: әрбір релиздегі smoke-хаос, гейттер, есептер.
4. Шектеулері бар прод-хаос: шағын трафик, қатаң guardrails, дайын кері қайтару.
5. Үздіксіз тұрақтылық: авто-эксперименттер, SLO-басқару, жұмыс ағыны ретінде жақсарту.

14) Сәулет практикаларымен интеграциялау

Тұрақтылықты тестілеу: хаос-эксперименттер fault-инъекцияларды және тозу сценарийлерін толықтырады.
Жүктемелік тестілеу: «жүктеме + істен шығу» құрама эксперименттері ретрайлардың каскадтары мен дауылын анықтайды.
Policy as Code/RBAC/ABAC: guardrails, қайтару қадамдары мен лимиттерді саясат ретінде рәсімдеңіз.
Келісімдер/құпиялылықты басқару: деректерді өңдеу режимін бұзатын эксперименттерге жол бермеңіз.
Geo-сәулет: аймақтардың фейловерін хаос-тексеру және деректерді юрисдикцияларға байланыстыру.

15) Шағын рецептілер (жалған құжат)

Брейкер + деградация

if breaker. open():
return serve_stale(cache. max_age=15m)
try:
res = call(dep, timeout=250ms)
return res except Timeout:
breaker. trip()
return serve_stale()

Лимитер + шейдинг

if cpu. load() > 0. 85 or queue. depth() > HIGH:
if req. priority < HIGH: return 503_SHED limiter. acquire()

Демпотенттік жанама әсері

key = "payout:"+external_id if kv. exists(key): return kv. get(key)
res = side_effect()
kv. put(key, res, ttl=30d)
return res

16) Сәулетшінің чек-парағы

1. Steady State және guardrails анықталған ба?
2. Сценарийлер каталогы бар ма (желі/CPU/сақтау орны/тәуелділік/деректер/операциялар)?
3. Бақылау ресурстарды, латенттілік қалдықтарын, бизнес-инварианттарды жаба ма?
4. Таймауттар/ретрайлер/брейкерлер/лимитерлер/bulkheads қосылған және параметрленеді ме?
5. Runbook пен «қызыл түймешік» дайындалды ма?
6. Стейджде хаос-smoke және түнгі эксперименттер бар ма?
7. Ойын күндеріне «қауіпсіз» терезелер мен рөлдер жазылған ба?
8. Эксперименттер ойнатылады (IaC/скрипттер), нәтижелер нұсқаланады?
9. Жақсартулар міндеттермен белгіленеді, ретест жасалады ма?
10. Деректер мен ML-конвейерлер қамтылды ма, тек HTTP ғана емес?

Қорытынды

Chaos Engineering «күтпеген оқиғаларды» болжамды сценарийлерге айналдырады. Тұрақтылық гипотезасы, бақыланатын инъекциялар, қатаң guardrails, бай бақылау және ретест тәртібі - бұл релиздер тәуекелін төмендететін және платформаға сенімді арттыратын құралдар. Нәтижесінде, команда жүйенің шектерін түсінеді, әдемі деградация жасай алады және сервисті істен шыққан жағдайда да пайдаланушыға тез қайтара алады.