Əməliyyat pleybukları

1) Playbook nədir və runbook-dan nə ilə fərqlənir

Runbook - standart əməliyyat/alert üçün xətti addım-addım təlimat ('bir, iki, üç ").
Playbook - müxtəlif simptomlar → fərqli fərziyyələr → fərqli fəaliyyət qolları ilə ssenarilər üçün həll ağacı. Seçim meyarları, qapı şərtləri və fallback filialları daxildir.
Playbukun məqsədi MTTA/MTTR və qeyri-müəyyənlik zamanı improvizasiya səviyyəsini azaltmaqdır.

2) Harada playbook ilk növbədə lazımdır

Hadisələr: SLO-nun düşməsi (availability/latency/success), biznes SLI-nin uğursuzluğu (çevirmə/ödənişlərin uğuru).
Dəyişikliklər: relizlər, miqrasiyalar, fiqa bayraqları, konfiqlər (canary/rollback).
Xidmət pəncərələri: DB/brokerlərin yeniləmələri, sertifikatların rotasiyası.
Provayderlər: PSP/KYC/CDN/IDP - deqradasiya və svich over.
Təhlükəsizlik: güzəştli açar, şübhəli fəaliyyət.
DataOps: təravətin gecikməsi, sxemin sürüklənməsi, paylaynın deqradasiyası.

3) Playbook standartları (minimum tərkibi)

1. Kart: ID, Versiya/Tarix, Sahibi (Komanda/Rol), Xidmətlər/Regionlar/Tenantlar, Əlaqəli Siyasət/Standartlar.
2. Başlanğıc məqsədi və şərtləri: hansı SLO/SLI qorunur, hansı alertlər/tetikləyicilər tətbiq olunur.
3. Simptomlar Hipotezlər: Uyğunluq cədvəli, necə tez yanlış hipotezləri kəsmək.
4. Ağac həlləri: çatlaklar, təhlükəsizlik geytaları, dayanma/davam meyarları.
5. Hərəkətlər: runbook 's komandaları/linkləri ilə addım-addım bloklar.
6. Kommunikasiyalar: yeniləmə şablonu (Impact → Diaqnostika → Fəaliyyət → İz. yeniləmə), kanallar və tezliklər.
7. Geri çəkilmə/folbek: aydın backout planı, limitlər və UX deqradasiya bayrağı.
8. Tamamlanma meyarları: metriklər, müvəqqəti müşahidə pəncərələri.
9. Evidence: nə saxlamaq (qeydlər, qrafiklər, ekran görüntüləri, biletlərin ID).
10. Dəyişiklik tarixi: changelog, məlum məhdudiyyətlər.

4) Pleybukların taksonomiyası (kataloq nümunəsi)

INC- insidentlər (SLO/SLI, provayderlər, infrastruktur).
REL- - buraxılışlar, geri çəkilmələr, konfiqlər/bayraqlar.
MW- - xidmət pəncərələri (DB/queue/cert/OS).
SEC- təhlükəsizlik (giriş, açar, şübhəli hərəkətlər).
DATA - təravət/keyfiyyət/sxemlər.
PROV- - xarici provayderlər (PSP/KYC/CDN/Email/SMS).

5) Həyat dövrü və sahiblik

1. Başlanğıc: hadisə/simulyasiya/dəyişiklik nəticələrinə görə.
2. Layihə: müəllif = xidmət sahibi; revyu: SRE/təhlükəsizlik/data (domain).
3. Pilot: tabletop/game-day; keçid vaxtı və qüsurları qeyd.
4. Post: repo (Docs-as-Code), versiyası, tags, dashboard linkləri.
5. Yeniləmə: RCA/CAPA, rübdə ən azı bir dəfə; SLA təravət.
6. Arxiv/deprekasiya: dəyişdirildikdə/aktuallığını itirdikdə.

6) Alətlərlə inteqrasiya

Alert → Playbook: Hər Page qaydaları düz bir əsas playbook istinad edir.
ChatOps: '/play start <id> 'kart açır, evidence qeyd edir, yeniləmə zamanlayıcılarını təyin edir.
CMDB/kataloq: xidmət müvafiq playbook siyahısı, sahibləri, SLO, dashboard.
GitOps: playbook və runbook 'və Git yaşayır, PR review və linters keçir.

7) Playbook keyfiyyət metrikası

Actionability: ≥ 90% -i «bilmədən» eskalasiyasız konkret hərəkətlərə səbəb olur.
Time-to-first-action: Səhifədən ilk mənalı addıma qədər bir-iki dəqiqə.
Coverage:% Page-alert bağlı playbook (hədəf 100%).
Freshness: pleybukların payı 90 gün təzədir.
Defect rate: 100 playbook üçün revyu/simulyasiyalar haqqında qeydlər.
Reuse: playbook həqiqətən neçə dəfə istifadə edilmişdir (və hansı nəticələrə səbəb oldu).

8) Anti-nümunələr

Ağac həllər olmadan 20 səhifəlik «Playbook-Ensiklopediyası».
Nəticəni gözləməyən komandalar («X yerinə yetirin» - və nə dəyişməlidir?).
Backout planı və limitləri yoxdur - problemin artması riski.
Kommunikasiya kanalları/intervalları göstərilməyib - PR risklərinin artması.
Sahibi/yeniləmə tarixi olmayan playbook - heç kim onun aktuallığına inanmır.
Bir parametrləşdirilən əvəzinə onlarla oxşar playbook.

9) Mini playbook şablon (YAML ideya)

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) Hazır nümunələr (fraqmentlər)

A) Ödənişlər: «Provayder bir bölgədə deqradasiya edir»

Simptomlar: TR-kohortların success_ratio azalması, PSP-A. zamanının artması

Həllər: TR üçün PSP-A çəkisini azaltmaq, degrade-UX-i yandırmaq, SLA ≤ büdcəsi ilə retrayları gücləndirmək, müştəri yeniləməsini hazırlamaq.
Backout: 60 dəqiqə yaşıl SLI ilə çəki geri.

B) BD: «Boy p99 və connection errors»

Simptomları: p99 ↑, səhv connection reset, böyümə wait events.
Həllər: read-only ssenariləri daxil edin, write yükünü məhdudlaşdırın, hovuz/replikaları ölçün, lazım gələrsə - isti faylover.
Backout: parametrlərin geri qaytarılması, prime replika.

C) Cache: «Miss rate ↑ → DB yükü»

Simptomları: miss rate> 40%, CPU BD artımı.
Həllər: eviction policy balans, yaddaş/charding artırmaq, müvəqqəti read-through aktiv, RPS isti açarları məhdudlaşdırmaq.
Backout: siyasəti geri qaytarmaq, problemli şard yenidən yaratmaq.

D) CDN: «Məzmunun regional deqradasiyası»

Simptomları: bir ölkədə latency/timeout artımı, RUM şikayətləri.
Həllər: routing map/GSLB dəyişdirmək, problemli POP-dan yan keçmək, TTL-i azaltmaq, origin-shield-i yandırmaq.
Comms: təsir coğrafiyası ilə status-update.

E) KYC: «identifikasiya uğursuzluğu»

Simptomlar: approve rate eniş, vendor_error artım.
Həllər: trafikin bir hissəsini alternativ provayderə keçmək, qaydaların sərtliyini azaltmaq (siyasət çərçivəsində), VIP üçün əl ilə review başlatmaq.
Compliance: bütün dəyişikliklərin log, zəruri hallarda Risk/Legal bildirişlər.

11) Rabitə (yeniləmə şablonu)

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) Pleybuk müəllifinin çek siyahısı

• Hədəf, sahibləri, SLO/SLI və tetikləyicilər göstərilir.
• Bir cədvəl var «Simptomlar hipotezlər» və ağac həllər.
• Gözlənilən nəticələr və təhlükəsizlik nişanları ilə yerinə yetirilə bilən addımlar.
• Yazılan backout/fallback və geri qaytarma şərtləri.
• Rabitə şablonu və yeniləmə tezliyi.
• Dashboard linklər/alert/log-axtarış/treys.
• Məcburi evidence bölməsi və tamamlanma meyarları.
• Versiyası, tarixi, SLA təravəti, dəyişiklik tarixi.

13) Yoxlayıcı siyahı

• Playbook tabletop/game-day oynayır.
• Addımlar təhlükəsizdir (limitlər/kanarya/otomatik geri), sirləri açıqlanmır.
• Rollar və eskalasiya aydındır; IC/Comms göstərilmişdir.
• Qonşu playbuklarla heç bir dublaj yoxdur; parametrləri verilmişdir.
• dayandırmaq və fallback/rollback keçmək zaman başa düşüləndir.
• Sənəd 1 kliklə alertdən mövcuddur.

14) Parametrləşdirmə və təkrar istifadə

Dəyişənləri (region, provayder, eşiklər) 'values.' -ə çıxarın.
Ümumi addımlar (məsələn, «provayderin çəkisini azaltmaq», «degrade-UX daxil etmək») ayrı runbook ilə tərtib edin.
Şablonlardan generatorları saxlayın: 'plb new --type = INC --service = payments'.

15) Yol xəritəsi (4-6 həftə)

1. Page-alert inventar → hər əsas playbook müqayisə.
2. Şablonlar: YAML/Markdown strukturu, çek vərəqləri və linterləri təsdiq edin.
3. Top 5 script (ödənişlər/DB/CDN/KYC/cache) → yazmaq/tabletop sürmək.
4. İnteqrasiya: alert linklər, ChatOps komanda, evidence bot.
5. Təlimlər: həftəlik mini-drill bir pleybuk; AAR → təkmilləşdirilməsi.
6. SLA təravət və rüblük ağlama; keyfiyyət metrik hesabat.

16) Yekun

Playbucks, «nə etməli?!» xaosunu proqnozlaşdırıla bilən bir həll ardıcıllığına çevirən çatlamalar və məhəccərlərlə əməliyyat ssenariləridir. Pleybuklar standartlaşdırıldıqda, alertlərlə inteqrasiya olunduqda və müntəzəm olaraq məşq edildikdə, komanda daha sürətli reaksiya verir, risklər idarə olunur və biznes istismarın sabitliyini və yetkinliyini görür.