Оқиғалар мен SRE ойнатқыштары

1) Оқиға дегеніміз не және ол SLO-мен қалай байланысады

Инцидент - SLO/қызметтік функцияны бұзатын немесе бұзушылық тәуекелін тудыратын оқиға (қате бюджет тез тұтанады).
Классикалық метриктер: MTTD, MTTA, MTTR, MTBF.
Бюджет қатесі мен burn-rate эскалация терезелерінің басымдығын анықтайды.

2) Маңыздылық деңгейлері (SEV) және критерийлер

SEV триггерлері: 5xx% асуы, р95> табалдырық, төлем decline spike, Kafka-lag> табалдырық, NodeNotReady> X мин, TLS мерзімі <7 күн, DDoS/ағу сигналдары.

3) Рөлдер және жауапкершілік (RACI)

Incident Commander (IC) - жеке-дара шешім қабылдау, міндеттер ағынының менеджменті, SEV мәртебесін ауыстыру.
Ops Lead (Tech Lead) - техникалық стратегия, гипотезалар, фикстерді үйлестіру.
Communications Lead (Comms) - статус-апдейттер (ішкі/сыртқы), StatusPage/чат/пошта.
Scribe (Хронист) - таймлайн, шешімдер, артефактілер, графикаға/логиге сілтемелер.
On-call Engineers/SMEs - плейбуктер бойынша әрекеттерді орындау.
Security/Privacy - қауіпсіздік немесе PII инциденттері кезінде қосылады.
FinOps/Payments - биллингке/PSP/құнға әсер еткен кезде.

4) Оқыс оқиғаның өмірлік циклі

1. Детект (алерт/репорт/синтетика) → инцидент карточкасын авто жасау.
2. Триаж (IC тағайындалды, SEV берілді, ең аз контекст жинағы).
3. Тұрақтандыру (mitigation: фича/роллбэк/rate-limit/failover өшіру).
4. Тексеру (RCA-гипотезалар, фактілерді жинау).
5. Сервисті қалпына келтіру (validate SLO, қадағалау).
6. Коммуникация (ішкі/сыртқы, қорытынды есеп).
7. Постмортем (айыптаусыз, CAPA-жоспар, иелері, мерзімдері).
8. Prevention (тестілер/алерттар/плейбуктер/жалаулар, команданы толық оқыту).

5) Коммуникация және «war-room»

Инциденттің бірыңғай арнасы ('#inc -sev1-YYYYMMDD-hhmm'), тек фактілер мен әрекеттер.
Радио-протокол стиліндегі командалар: "IC: rollback нұсқасы 1. 24 → ETA 10 мин".
Статус-апдейттер: SEV-1 әрбір 15 минут сайын, SEV-2 - әрбір 30-60 минут сайын.
Status Page/сыртқы коммуникация - үлгі бойынша Comms Lead арқылы.
Тыйым салынған: параллель «тыныш» бөлмелер, жалпы арнаға тексерілмеген гипотезалар.

6) Алертинг және SLO-burn (ереже үлгісі)

Жылдам арна (1-5 мин) және баяу арна (1-2 сағ) burn-rate.
Көп сигналдар: бюджет қатесі, 5xx%, p95, Kafka-lag, төлем decline-rate, синтетика.
Бастапқы себептерді іздеу - симптомдарды тұрақтандырғаннан кейін ғана.

promql
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14.4

7) Плейбуктар vs ранбуктер

Плейбук - инцидент түрі бойынша іс-қимыл сценарийі (тармақталу, жағдайлар, тәуекелдер).
Ранбук - қадамдардың/командалардың нақты «картасы» (тексерулер, фикстер, верификация).
Ереже: плейбук бірнеше ранбуктарға (rollbacks, feature-flags, failover, масштабтау, трафикті бұғаттау және т.б.) сілтеме жасайды.

8) Инцидент карточкасының үлгісі

yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active    monitoring    resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

9) SRE-плейбук үлгісі (Markdown)

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

10) Типтік плейбуктер

10. 1 API 5xx Spike

Тұрақтандыру: проблемалық фичефлагты өшіру; API репликаларын арттыру; кэштеуді қосу; релизді қайтару.
Диагностика: diff релиз, логдағы қателер (top-exceptions), өсу p95, pressure БД/кэш.
Тәуекелдер: төлемдер/бэкендтердегі каскад.

10. 2 БД: replication lag / lock storm

Тұрақтандыру: ауыр кендірді/репортажды тоқтата тұру; оқуларды шеберге қайта бағыттау; wal_buffers/реплика-слоты ұлғайту.
Диагностика: сұрауларды бұғаттайтын ұзақ транзакциялар, жоспарды өзгерту.
Бекіту: индекстер/хинттер, джобтарды қайта жоспарлау, сұрауларды бөлу.

10. 3 Kafka consumer lag

Тұрақтандыру: consumer's уақытша масштабтау; критикалық емес сервистерден продюсингті төмендету; партияларды/квоталарды көбейту.
Диагностика: rebalances, баяу десериализация, GC-үзілістер.
Верификация: лаг → мақсатты мәнге, дроптар жоқ.

10. 4 K8s NodeNotReady/ресурстық дауыл

Тұрақтандыру: cordon + drain; жүктемені қайта бөлу; CNI/overlay бағдарламасын тексеру; дауысты DaemonSet 'терін өшіру.
Диагностика: disk pressure, OOM, throttling, network drops.
Профилактика: pod disruption budgets, ресурстық лимиттер/requests.

10. 5 TLS/сертификаттар мерзімі аяқталады

Тұрақтандыру :/ingress құпиясын мәжбүрлеп жаңарту; уақытша override.
Диагностика: сенім тізбегі, clock-skew.
Профилактика: аллергиялық T-30/T-7/T-1, авто-реньюал.

10. 6 DDoS/аномалды трафик

Тұрақтандыру: WAF/бот-ережелер, rate-limit/geo-сүзгілер, upstream shed load.
Диагностика: шабуыл профильдері (L3/4/7), көздер, «қолшатырлар».
Профилактика: anycast, autoscaling, кэширование, play-nice провайдерлермен.

10. 7 Төлем PSP-аутедж

Тұрақтандыру: баламалы PSP/әдістерге smart-routing; джиттермен retry көтеру; «жұмсақ» UI деградациясы.
Диагностика: spike кодтары бойынша істен шығулар, API мәртебелері/PSP мәртебе беттері.
Коммуникациялар: бизнес пен саппорт үшін ашық апдейттер, ND/конверсияның дұрыс статистикасы.

10. 8 Қауіпсіздік инциденті/PII ағуы

Тұрақтандыру: тораптарды оқшаулау/құпия-ротация, эксфильтрацияны бұғаттау, Legal Hold.
Диагностика: таймлайн қатынау, қозғалған субъектілер/өрістер.
Ескертулер: реттеушілер/әріптестер/пайдаланушылар юрисдикция талаптары бойынша.
Алдын алу: DLP/сегменттеуді күшейту, «least privilege».

11) Плейбуктерді автоматтандыру

ChatOps командасы: '/ic set sev 1 ', '/deploy rollback api 1. 23. 4`, `/feature off X`.
Runbook боттары: жартылай автоматты қадамдар (drain node, flip traffic, purge cache).
Self-healing huki: детектор → стандартты mitigation (rate-limit, restart, scale).
Алерттер мен командалардан авто-жасау карточкалары/таймлайны.

12) Плейбуктердің сапасы: чек-парақ

• Анық симптомдар мен детекторлар (метриктер/логтер/трассалар).
• Тәуекелді бағалаумен тұрақтандырудың жылдам қадамдары.
• Командалар/скрипттер өзекті, staging бағдарламасында тексерілді.
• SLO қалпына келтіруді тексеру.
• Сыртқы жаңартулардың коммуникациялық үлгілері мен өлшемдері.
• Постмортем-сілтеме және жабылғаннан кейін CAPA.

13) Постмортем (blameless) және CAPA

Мақсаты: кінәліні табу емес, үйрену.
Мазмұны: не болды, қалай жақсы/жаман болды, факторлардың үлесі (тех + процестер), алдын алу үшін іс-қимыл.
Мерзімі: SEV-1 - 48 сағат ішінде; SEV-2 - 3 жұмыс күні.
CAPA: нақты иелері, мерзімі, өлшенетін әсерлері (MTTR төмендеуі/MTTD өсуі).

14) Құқықтық аспектілер және дәлелдеу базасы

Legal Hold: логтарды/трассаларды/алерттерді, write-once қоймаларын мұздату.
Артефактілерді сақтау тізбегі: рөлдер бойынша қол жетімділік, тұтастығын бақылау.
Реттеушілік хабарламалар: юрисдикцияларға арналған мерзімдер/үлгілер (әсіресе төлемдер/PII қозғалған кезде).
Жекелік: талдау кезінде PII-ді барынша азайту және бүркемелеу.

15) Инциденттер процесінің тиімділік өлшемдері

MTTD/MTTA/MTTR тоқсандар мен домендер бойынша.
SEV (underrating/overrating) дұрыстығы.
Авто-митигейтпен болған инциденттердің үлесі.
Сценарийлердің топ-N плейбуктерімен жабу (> 90%).
CAPA-ны мерзімінде орындау.

16) Кезеңдер бойынша енгізу

1. Апта 1: SEV-матрица, on-call рөлдері, карточканың жалпы үлгісі, war-room регламенті.
2. Апта 2: Топ-5 белгілері үшін плейбуктер (5xx, БД-лаг, Kafka-lag, NodeNotReady, TLS).
3. Апта 3: ChatOps/боттар, автоматты түрде карточка жасау, коммуникация үлгілері/StatusPage.
4. Апта 4 +: Қауіпсіздік плейбуктері, PSP-аутейдждер, Legal Hold, тұрақты дрель/хаос ойындары.

17) «Жылдам» ранбуктер мысалдары (фрагменттер)

Rollback API (K8s)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Верификация:
kubectl -n prod top pods -l app=api

Drain node

bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10m

Feature-flag OFF (мысал)

bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'

18) Шағын FAQ

SEV-1 қашан көтеруге болады?
Негізгі SLO/бизнес функциясы (төлемдер, логин, ойын) зардап шеккен кезде, burn-rate бюджетті бір сағат бұрын «жейді».

Не маңызды - RCA немесе қалпына келтіру?
Әрқашан тұрақтандыру, содан кейін RCA. Тұрақтандыруға дейінгі уақыт - басты көрсеткіш.

Бәрін автоматтандыру керек пе?
Жиі және қауіпсіз қадамдарды автоматтандырыңыз; сирек/тәуекелді - жартылай авто және IC растау арқылы.

Жиынтық

Инциденттердің сенімді процесі үш бағанға сүйенеді: нақты рөлдер мен SEV-ережелер, автоматтандырылған сапалы плейбуктер/ранбуктер және айыптаусыз постмортем мәдениеті. Үлгілерді белгілеңіз, on-call жаттықтырыңыз, MTTR/қате бюджетті өлшеңіз және детекторлар мен ойнатқыштарды үнемі жақсартыңыз - бұл тікелей тәуекелдерді және бос тұру құнын төмендетеді.