Операциялар ойнатқыштары

1) Playbook дегеніміз не және ол runbook айырмашылығы қандай

Runbook - типтік операция/алерт үшін сызықтық қадамдық нұсқаулық («бір, екі, үш»).
Плейбук - сценарийлерге арналған шешімдер ағашы: түрлі симптомдар → әртүрлі гипотезалар → әртүрлі іс-қимылдар. Таңдау критерийлерін, гейт-шарттарды және fallback-тармақтарын қамтиды.
Плейбуктың мақсаты - белгісіздік кезінде MTTA/MTTR және импровизация деңгейін азайту.

2) Плейбуктер бірінші кезекте қажет

Оқиғалар: SLO-ның құлауы (availability/latency/success), бизнес-SLI-ның сәтсіздігі (конверсия/төлемдердің табысы).
Өзгерістер: релиздер, көші-қон, фича-жалаулар, конфигалар (canary/rollback).
Қызмет көрсету терезелері: ДБ/брокерлердің апгрейдтері, сертификаттарды ротациялау.
Провайдерлер: PSP/KYC/CDN/IDP - деградация және свич-овер.
Қауіпсіздік: сындырылған кілт, күдікті белсенділік.
DataOps: жаңаруды кешіктіру, схеманың дрейфі, пайплайнның тозуы.

3) Плейбук стандарттары (ең аз құрамы)

1. Карточка: Идентификатор, Нұсқа/Күні, Иесі (команда/роль), Сервистер/өңірлер/тенанттар, Байланысты саясат/стандарттар.
2. Іске қосу мақсаты мен шарттары: қандай SLO/SLI қорғаймыз, қандай триггерлер/триггерлер қолданылады.
3. Симптомдар Гипотезалар: дұрыс емес гипотезаларды қалай тез кесу керектігі туралы кесте.
4. Шешімдер ағашы: айрықтар, қауіпсіздік гейттері, тоқтату/жалғастыру өлшемдері.
5. Әрекеттер: runbook 'і. командалары/сілтемелері бар қадамдық блоктар.
6. Коммуникация: апдейт үлгісі (Импакт → Диагностика → Әрекеттер → Ізі. апдейт), арналар мен жиіліктер.
7. Кері/фолбэк: нақты backout-жоспар, лимиттер және UX тозу жалауы.
8. Аяқтау өлшемдері: метрика, уақытша бақылау терезелері.
9. Evidence: не сақтау керек (логтар, графиктер, скриншоттар, ID тикеттер).
10. Өзгерістер тарихы: changelog, белгілі шектеулер.

4) Плейбуктардың таксономиясы (каталог мысалы)

INC- инциденттер (SLO/SLI, провайдерлер, инфрақұрылым).
REL- релиздер, сырғанаулар, конфигалар/жалаулар.
MW- - қызмет көрсету терезелері (DB/queue/cert/OS).
SEC- қауіпсіздік (рұқсаттар, кілттер, күдікті әрекеттер).
DATA - жаңалық/сапа/сұлба.
PROV- - сыртқы провайдерлер (PSP/KYC/CDN/Email/SMS).

5) Өмірлік цикл және игеру

1. Бастамалау: инцидент/симуляция/өзгеріс нәтижелері бойынша.
2. Жоба жобасы: автор = сервистің иесі; SRE/қауіпсіздік/деректер (домен бойынша).
3. Ұшқыш: tabletop/game-day; өту уақыты мен ақауларды тіркеу.
4. Жариялау: репода (Docs-as-Code), нұсқа, тегтер, дашбордтарға сілтемелер.
5. Өзектендіру: RCA/CAPA бойынша, кем дегенде тоқсанына бір рет; Жас SLA.
6. Мұрағат/депрекация: ауыстыру/өзектілігін жоғалту кезінде.

6) Құралдармен интеграциялау

Alert → Playbook: әрбір Page ережелері дәл бір негізгі ойнатқышқа сілтеме жасайды.
ChatOps: '/play start <id> 'карточканы ашады, evidence тіркейді, жаңартулардың таймерлерін орнатады.
CMDB/каталог: сервисте релевантты плейбуктер тізімі, иелері, SLO, дашбордтар бар.
GitOps: ойнатқыштар мен runbook 'және Git-те тұрады, PR-ревьтен және линтерлерден өтеді.

7) Плейбуктер сапасының өлшемдері

Actionability: 90% ≥ іске қосулар «білімсіздік бойынша» эскалациясыз нақты әрекеттерге әкеледі.
Time-to-first-action: Page-тен бірінші мағыналы қадамға дейін екі минут.
Coverage: Байланған ойнатқышы бар% Page-алерт (мақсаты 100%).
Freshness: плейбуктердің үлесі 90 күннен жас.
Defect rate: 100 ойнатқышқа ревью/симуляциядағы ескертулер.
Reuse: плейбук нақты қанша рет қолданылды (және қандай нәтижелерге әкелді).

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

«Плейбук-энциклопедия» 20 бет ағашсыз шешім.
Нәтиже күтілмеген пәрмендер («X орындау» - не өзгеруі керек?).
Backout-жоспар мен лимиттер жоқ - проблеманың шиеленісу қаупі.
Коммуникация арналары/аралықтары көрсетілмеген - PR-тәуекелдердің өсуі.
Иесі/жаңартылған күні жоқ плейбук - оның өзектілігіне ешкім сенбейді.
Бір параметрдің орнына ондаған ұқсас ойнатқыштар.

9) Шағын плейбук үлгісі (YAML идеясы)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) Дайын мысалдар (фрагменттер)

A) Төлемдер: «Провайдер бір өңірде құлдырайды»

Белгілері: TR-когорта success_ratio төмендеуі, PSP-A таймауттарының өсуі

Шешімдер: TR үшін PSP-A салмағын азайту, degrade-UX қосу, SLA ≤ бюджетімен ретрацияны күшейту, клиенттік жаңартуды дайындау.
Backout: жасыл SLI 60 минут салмағын қайтару.

B) БД: «p99 өсуі және connection errors»

Белгілері: p99 ↑, қателер connection reset, өсу wait events.
Шешімдер: read-only сценарийлерін қосу, write-жүктемені шектеу, пул/репликаны масштабтау, қажет болған жағдайда - ыстық фейловер.
Backout: параметрлерді қайтару, реплика-прайм.

С) Кэш: «Miss rate ↑ → ДБ жүктеме»

Белгілері: miss rate> 40%, CPU өсуі БД.
Шешімдер: eviction policy теңестіру, жады/шардингті ұлғайту, уақытша read-through қосу, ыстық кілттерде RPS шектеу.
Backout: саясатты қайтару, проблемалық shard қайта құру.

D) CDN: «Контенттің аймақтық тозуы»

Симптомдары: бір елде latency/timeout өсуі, RUM шағымдары.
Шешімдер: routing map/GSLB өзгерту, проблемалық POP айналып, TTL төмендету, origin-shield қосу.
Коммс: әсер ету географиясы бар статус-апдейттер.

E) KYC: «Сәйкестендірудің сәтсіздігі»

Симптомдары: approve rate құлдырауы, vendor_error өсуі.
Шешімдер: трафиктің бір бөлігін баламалы провайдерге ауыстыру, ережелердің қатаңдығын төмендету (саясат шеңберінде), VIP үшін қолмен review бастама жасау.
Compliance: барлық өзгерістер журналы, қажет болған жағдайда Risk/Legal хабарламалары.

11) Коммуникация (апдейт үлгісі)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) Плейбук авторының чек-парағы

• Мақсаты, иелері, SLO/SLI және триггерлері көрсетілген.
• «Гипотеза белгілері» кестесі және шешімдер ағашы бар.
• Күтілетін нәтижелермен және қауіпсіздік белгілерімен орындалатын қадамдар.
• backout/fallback және қайтару шарттары жазылған.
• Коммуникация үлгісі және жаңартулар жиілігі.
• Дашбордтарға/алерттерге/лог-іздеулерге/трейстерге сілтемелер.
• evidence міндетті секциясы және аяқтау критерийлері.
• Нұсқа, күні, жаңалық SLA, өзгерістер тарихы.

13) Ревьюердің чек-парағы

• Ойнатқышты tabletop/game-day бағдарламасында ойнатамыз.
• Қадамдар қауіпсіз (лимиттер/канарейка/авто-кері қайту), құпиялар ашылмайды.
• Рөлдері мен өршуі анық; IC/Comms келтірілген.
• Көршілес ойнатқыштармен қайталау жоқ; параметрлері шығарылды.
• Қашан тоқтату және fallback/rollback көшу түсінікті.
• Құжат 1 басу арқылы алертадан қол жетімді.

14) Параметрлеу және қайта пайдалану

'values.' дегенге айнымалыларды (өңір, провайдер, шектер) шығарыңыз.
Жалпы қадамдарды (мысалы, «провайдердің салмағын азайту», «degrade-UX қосу») жеке runbook 'термен ресімдеңіз.
'plb new --type = INC --service = payments' үлгісіндегі генераторларды қолдаңыз.

15) Енгізудің жол картасы (4-6 апта)

1. Page-алерттерді түгендеу → әрқайсысына базалық плейбук салыстыру.
2. Үлгілер: YAML/Markdown құрылымын, чек парақтарын және линтерлерді бекіту.
3. Топ-5 сценарийлер (төлемдер/ДБ/CDN/KYC/кэш) → жазу/tabletop-ке шығару.
4. Интеграция: сілтемелер, ChatOps командасы, evidence-бот.
5. Жаттығулар: апта сайын бір плейбуктен mini-drill; AAR → жақсарту.
6. SLA жас және тоқсандық ревью; сапа өлшемдері бойынша есеп.

16) Жиынтық

Плейбуктер - бұл «не істеу керек?!» хаосын болжамды шешімдер тізбегіне айналдыратын жақтаулары мен қанаттары бар операциялық сценарийлер. Плейбуктер стандартталған, алертпен интеграцияланған және үнемі жаттығатын кезде команда жылдам әрекет етеді, тәуекелдер бақыланады, ал бизнес пайдаланудың тұрақтылығы мен жетілгендігін көреді.