Hadisələr və SRE playbook

1) Hadisə nədir və SLO ilə necə əlaqəlidir

Hadisə - SLO/xidmət funksiyasını pozan və ya pozulma riski yaradan hadisə (səhv büdcə qəbuledilməz dərəcədə tez yandırılır).
Klassik metriklər: MTTD, MTTA, MTTR, MTBF.
Büdcə səhv və burn-rate prioritet və eskalasiya pəncərələri müəyyən edir.

2) Ciddilik səviyyələri (SEV) və meyarlar

SEV tetikləyiciləri: aşan 5xx%, p95> eşik, ödəniş decline spike, Kafka-lag> eşik, NodeNotReady> X min, TLS <7 gün, DDoS/sızıntı siqnalları.

3) Rollar və məsuliyyət (RACI)

Incident Commander (IC) - fərdi qərar qəbulu, tapşırıq axını menecmenti, SEV statusunun dəyişdirilməsi.
Ops Lead (Tech Lead) - texniki strategiya, hipotezlər, fikslərin koordinasiyası.
Communications Lead (Comms) - status-update (daxili/xarici), StatusPage/chat/poçt.
Scribe (Xronist) - taymline, həllər, artefaktlar, qrafiklərə/loqilərə istinadlar.
On-call Engineers/SMEs - pleybuklar üzrə hərəkətlərin icrası.
Security/Privacy - təhlükəsizlik və ya PII hadisələri zamanı aktivləşdirilir.
FinOps/Payments - billing/PSP/dəyəri təsir.

4) Hadisənin həyat dövrü

1. Detekt (alert/report/sintetika) → hadisə kartının avtomatik yaradılması.
2. Triaj (IC təyin, SEV təyin, minimum kontekstin toplanması).
3. Stabilizasiya (mitigation: fichu/rollback/rate-limit/failover).
4. Araşdırma (RCA-fərziyyələr, faktların toplanması).
5. Xidmətin bərpası (SLO validate, müşahidə).
6. Rabitə (daxili/xarici, yekun hesabat).
7. Postmortem (ittihamsız, CAPA planı, sahibləri, şərtlər).
8. Prevention (testlər/alertlər/playbuklar/bayraqlar, komandanın əlavə təlimi).

5) Rabitə və «war-room»

Vahid hadisə kanalı ('#inc -sev1-YYYMMDD-hhmm'), yalnız faktlar və hərəkətlər.
Radio protokol üslubunda komandalar: "IC: rollback versiyası 1 təyin. 24 → ETA 10 dəq".
Status-update: SEV-1 hər 15 dəqiqə, SEV-2 - hər 30-60 dəqiqə.
Status Page/xarici rabitə - şablona uyğun olaraq Comms Lead vasitəsilə.
Qadağan: paralel «sakit» otaqlar, ümumi kanala yoxlanılmamış fərziyyələr.

6) Alerting və SLO-burn (nümunə qaydaları)

Sürətli kanal (1-5 dəqiqə) və yavaş kanal (1-2 saat) burn-rate.
Multi-siqnallar: büdcə xətası, 5xx%, p95, Kafka-lag, ödəniş decline-rate, sintetika.
Əsas səbəbin axtarışı yalnız simptomların sabitləşməsindən sonra.

promql
Error rate 5xx> SLO sum (rate (http_requests_total{status=~"5"..}[5m]) )/sum (rate (http_requests_total[5m]))> 0. 01

Burn-rate fast (example)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14. 4

7) Playbook vs ranbook

Playbook - hadisə tipinə görə fəaliyyət ssenarisi (budaqlar, şərtlər, risklər).
Ranbuk - addımların/komandaların konkret «xəritəsi» (yoxlamalar, fikslər, yoxlama).
Qayda: playbook bir neçə ranbuklara istinad edir (rollbacks, feature-flags, failover, miqyas, trafikin bloklanması və s.).

8) Hadisə kartı şablonu

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: <name>
comms_lead: <name>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx = 12% (usually <0. 5%), deposit conversion -20%"
mitigation: "rollback to 1. 23. 4, rate-limit 2k rps on, feature X off"
timeline:
- "17:42: alert SLO burn-rate fast"
- "17:46: IC appointed, war-room open"
- "17:52: release 1 found. 24 as a candidate"
- "18:02: Rollback complete, 5xx back to 0. 3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "another surge is possible when turning on feature X"
next_steps: "canary release, tests, postmortem until 2025-11-05"

9) SRE playbook şablonu (Markdown)

markdown
Playbook: <title>
Area/symptoms
List of detectors, signatures in metrics/logs/traces.

Triage & Mitigation
- [] Restrict traffic/enable WAF rule/OFF feature
- [] Rollback/canary release/roll out configuration fix
- [] Enable degradation mode (read-only, cache force)

Diagnostics (RCA hints)
- Metrics:... Logs:... Trails:...
- Common Root Causes/Hypothesis Checklist

Risks and communications
- Internal/external updates, SLA obligations

Verification
- [] SLO restored (threshold/window time)
- [] No recourse for related services

Follow-up
- CAPA, tasks in backlog, updating alerts/dashboards/playbook

10) Tipik pleybuklar

10. 1 API 5xx Spike

Stabilizasiya: problemli fitzeflagı söndürmək; API replikalarını artırmaq; caching daxil; geri buraxılış.
Diaqnostika: diff reliz, log səhvləri (top-exceptions), böyümə p95, pressure BD/cache.
Risklər: ödənişlərdə/arxalarda kaskad.

10. 2 БД: replication lag / lock storm

Sabitləşmə: ağır jobların/reportajların dayandırılması; oxu master yönləndirmək; wal_buffers/replika-sloty artırmaq.
Diaqnostika: uzun əməliyyatlar, sorğuları bloklamaq, plan dəyişiklikləri.
Fiksasiya: indekslər/xintlər, cob yenidən planlaşdırılması, sorğuların bölünməsi.

10. 3 Kafka consumer lag

Sabitləşdirmə: consumer 's müvəqqəti ölçmək; kritik olmayan xidmətlərdən istehsalını azaltmaq; partiyalar/kvotaları artırmaq.
Diaqnostika: rebalances, yavaş deserialization, GC fasilələr.
Doğrulama: lag → hədəf dəyərinə, heç bir damcı.

10. 4 K8s NodeNotReady/resurs fırtına

Stabilizasiya: cordon + drain; yükləri yenidən bölüşdürmək; CNI/overlay yoxlamaq; səs-küylü DaemonSet-i söndürmək.
Diaqnostika: disk pressure, OOM, throttling, network drops.
Profilaktika: pod disruption budgets, resurs limitləri/requests.

10. 5 TLS/sertifikatların müddəti başa çatır

Sabitləşdirmə: gizli/ingress məcburi yeniləmə; müvəqqəti override.
Diaqnostika: etimad zənciri, clock-skew.
Profilaktika: alert T-30/T-7/T-1, avto-renyual.

10. 6 DDoS/anormal trafik

Sabitləşdirmə: WAF/bot qaydaları, rate-limit/geo-filtrlər, upstream shed load.
Diaqnostika: hücum profilləri (L3/4/7), mənbələr, «çətirlər».
Profilaktika: anycast, autoscaling, caching, play-nice provayderləri ilə.

10. 7 Ödəniş PSP Autage

stabilizasiya: alternativ PSP/metodları smart-routing; jitter ilə retry qaldırmaq; «yumşaq» deqradasiya UI.
Diaqnostika: spike kodları, API statusları/PSP status səhifələri.
Rabitə: şəffaf biznes və sapport yeniləmələri, düzgün ND/dönüşüm statistikası.

10. 8 Təhlükəsizlik hadisəsi/PII sızması

Stabilizasiya: düyün izolyasiyası/gizli rotasiya, ekstrilasiya kilidi, Legal Hold.
Diaqnostika: time line giriş, təsir subyektlər/sahələr.
Bildirişlər: tənzimləyicilər/tərəfdaşlar/istifadəçilər yurisdiksiya tələblərinə görə.
Profilaktika: DLP/seqmentasiya gücləndirilməsi, «least privilege».

11) Pleybukların avtomatlaşdırılması

ChatOps komandaları: '/ic set sev 1 ', '/deploy rollback api 1. 23. 4`, `/feature off X`.
Runbook-botlar: yarı avtomatik addımlar (drain node, flip traffic, purge cache).
Self-healing huki: dedektor → standart mitigation (rate-limit, restart, scale).
Alertlər və komandalardan avtomatik kartların/zaman xəttinin yaradılması.

12) Playbook keyfiyyəti: çek siyahısı

• Aydın simptomlar və detektorlar (metriklər/loqlar/yollar).
• Risk qiymətləndirilməsi ilə sürətli sabitləşdirmə addımları.
• Komandalar/skriptlər aktualdır, staging-də yoxlanılır.
• SLO bərpa təsdiqlənməsi.
• Rabitə şablonları və xarici yeniləmə meyarları.
• Post-mortem link və CAPA bağlandıqdan sonra.

13) Postmortem (blameless) və CAPA

Məqsəd: günahkar tapmaq deyil, öyrənmək.
Məzmun: Nə oldu ki, nə yaxşı/pis idi, amillərin töhfəsi (tech + proseslər), qarşısını almaq üçün fəaliyyət.
Müddət: SEV-1 - 48 saat ərzində; SEV-2 - 3 iş günü.
CAPA: xüsusi sahibləri, vaxt, ölçülə bilən effektlər (MTTR azaldılması/MTTD artımı).

14) Hüquqi aspektlər və sübut bazası

Legal Hold: Log/Trail/Alert, write-once saxlama dondurma.
Artefaktların saxlama zənciri: rollara daxil olmaq, bütövlüyə nəzarət.
Tənzimləyici bildirişlər: yurisdiksiyalar üçün son tarixlər/şablonlar (xüsusilə təsirlənmiş ödənişlər/PII).
Gizlilik: təhlil zamanı PII-nin minimallaşdırılması və maskalanması.

15) Hadisə prosesinin effektivliyinin metrikası

MTTD/MTTA/MTTR kvartallar və domenlər üzrə.
SEV düzgünlüyü (underrating/overrating).
Avto-mitiqeyt hadisələrinin nisbəti.
Top-N ssenarilərin pleybukları (> 90%).
CAPA vaxtında icra.

16) Mərhələlər üzrə tətbiq

1. Həftə 1: SEV matrisi, on-call rolları, ümumi kart şablonu, war-room qaydaları.
2. Həftə 2: Top 5 simptomlar üçün playbook (5xx, BD-lag, Kafka-lag, NodeNotReady, TLS).
3. Həftə 3: ChatOps/botlar, avtomatik kart yaradılması, rabitə şablonları/StatusPage.
4. Həftə 4 +: Təhlükəsizlik Playbook, PSP Autage, Legal Hold, müntəzəm drill/xaos oyunları.

17) «Sürətli» ranbukların nümunələri (fraqmentlər)

Rollback API (K8s)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Verification:
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 (nümunə)

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

18) Mini-FAQ

Nə zaman SEV-1 qaldırmaq?
Əsas SLO/biznes funksiyası əziyyət çəkəndə (ödənişlər, giriş, oyun) və burn-rate büdcəni qabaqcadan «yeyir».

Hansı daha vacibdir - RCA və ya bərpa?
Həmişə sabitləşmə, sonra RCA. Sabitləşməyə qədər olan vaxt əsas göstəricidir.

Hər şeyi avtomatlaşdırmaq lazımdırmı?
Tez-tez və təhlükəsiz addımları avtomatlaşdırın; nadir/riskli - yarı avtomobil və IC təsdiqi vasitəsilə.

Yekun

Hadisələrin etibarlı prosesi üç sütuna əsaslanır: aydın rollar və SEV qaydaları, avtomatlaşdırma ilə keyfiyyətli playbook/ranbook və ittihamsız postmortem mədəniyyəti. Şablonları düzəldin, on-call məşq edin, MTTR/səhv büdcəni ölçün və detektorları və playbukları daim təkmilləşdirin - bu birbaşa riskləri və fasilələrin dəyərini azaldır.