Operasyon oyun kitapları

1) Bir playbook nedir ve bir runbook'tan nasıl farklıdır?

Runbook, tipik bir işlem/uyarı için doğrusal bir adım adım talimattır ('bir, iki, üç ").
Playbook, çatallı senaryolar için bir karar ağacıdır: farklı semptomlar - farklı hipotezler - farklı eylem dalları. Seçim kriterleri, kapı koşulları ve geri dönüş dallarını içerir.
Oyun kitabının amacı MTTA/MTTR'yi ve belirsizlik altındaki doğaçlama seviyesini azaltmaktır.

2) Playbook'lara ilk ihtiyaç duyulan yer

Olaylar: SLO düşüşü (kullanılabilirlik/gecikme/başarı), iş SLI hatası (ödemelerin dönüşümü/başarısı).
Değişiklikler: sürümler, geçişler, özellik bayrakları, yapılandırmalar (kanarya/geri alma).
Bakım pencereleri: veritabanı/broker yükseltmeleri, sertifika rotasyonları.
Sağlayıcılar: PSP/KYC/CDN/IDP - bozulma ve sallanma.
Güvenlik: ele geçirilmiş anahtar, şüpheli aktivite.
DataOps: gecikmiş tazelik, devrenin sürüklenmesi, boru hattının bozulması.

3) Playbook standartları (minimum kompozisyon)

1. Kart: Kimlik, Sürüm/Tarih, Sahip (Takım/Rol), Hizmetler/Bölgeler/Kiracılar, İlgili Politikalar/Standartlar.
2. Amaç ve başlatma koşulları: Hangi SLO/SLI'yi koruyoruz, hangi uyarılar/tetikleyiciler uygulanabilir.
3. Semptomlar ↔ Hipotezler: yazışma tablosu, yanlış hipotezlerin hızlı bir şekilde nasıl kesileceği.
4. Karar ağacı: çatallar, güvenlik kapıları, durdurma/devam etme kriterleri.
5. Eylemler: komut içeren adım blokları/çalışma kitabına bağlantılar've.
6. İletişim: Güncelleme şablonu (Impakt, Diagnostika, Deystviya, Kızak). ), kanalları ve frekansları güncelleyin.
7. Geri alma/geri alma: net geri alma planı, limitler ve UX bozulması bayrağı.
8. Tamamlama kriterleri: metrikler, gözlem zamanı pencereleri.
9. Kanıt: ne kaydedilir (günlükler, grafikler, ekran görüntüleri, bilet kimliği).
10. Değişikliklerin tarihi: changelog, bilinen sınırlamalar.

4) Playbook taksonomisi (örnek katalog)

INC- - olayları (SLO/SLI, sağlayıcılar, altyapı).
REL - - yayınlar, geri dönüşler, yapılandırmalar/bayraklar.
MW- - bakım pencereleri (DB/queue/cert/OS).
SEC- - güvenlik (erişimler, anahtarlar, şüpheli eylemler).
DATA- - tazelik/kalite/şemalar.
PROV- - dış sağlayıcılar (PSP/KYC/CDN/E-posta/SMS).

5) Yaşam döngüsü ve mülkiyet

1. Başlatma: Olay/simülasyon/değişime dayanır.
2. Taslak: yazar = servis sahibi; İnceleme: SRE/güvenlik/veri (etki alanına göre).
3. Pilot: masa üstü/oyun günü; Geçiş zamanı ve kusurlarının kaydedilmesi.
4. Yayın: repo (Docs-as-Code), sürüm, etiketler, panolara bağlantılar.
5. Güncelleme: RCA/CAPA'ya göre, en az üç ayda bir; SLA tazeliği.
6. Arşiv/tükenme: değiştirme/alaka kaybı durumunda.

6) Araçlarla entegrasyon

Uyarı - Playbook: Her Sayfa kuralı tam olarak bir temel playbook'u referans alır.
ChatOps:'/play start <id> 'kartı açar, kanıtları düzeltir, güncelleme zamanlayıcılarını ayarlar.
CMDB/katalog: Hizmetin ilgili oyun kitaplarının, sahiplerinin, SLO'larının, gösterge tablolarının bir listesi vardır.
GitOps: playbook'lar ve runbook'lar Git'te yaşıyor, PR incelemeleri ve linkleri var.

7) Playbook kalite metrikleri

İşlem yapılabilirlik: Koşuların ≥ %90'ı, bilmeden tırmanmadan belirli eylemlerle sonuçlanır.
İlk harekete geçme süresi: Sayfa'dan ilk anlamlı adıma bir veya iki dakika.
Kapsam: % Bağlı bir oynatma kitabı olan sayfa uyarıları (%100 hedef).
Tazelik: Oyun kitaplarının oranı 90 günden daha taze.
Kusur oranı: 100 oyun kitabı için incelemeler/simülasyonlar hakkındaki yorumlar.
Yeniden kullanma: Oyun kitabının kaç kez uygulandığı (ve hangi sonuçlara yol açtığı).

8) Anti-desenler

"Playbook Encyclopedia", karar ağacı olmayan 20 sayfa.
Sonuç beklentisi olmayan komutlar ("X'i çalıştır" - ne değişmeli?).
Geri dönüş planı ve sınırları yoktur - sorunu tırmandırma riski.
İletişim kanalları/aralıkları belirtilmez - PR risklerinin büyümesi.
Sahibi/güncelleme tarihi olmayan Playbook - kimse alaka düzeyine inanmaz.
Parametrelendirilebilir yerine düzinelerce benzer oyun kitabı.

9) Playbook mini şablon (YAML fikri)

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 örnekler (parçalar)

A) Ödemeler: "Sağlayıcı bir bölgede bozulur"

Semptomlar: TR kohortunun success_ratio azalması, PSP-A sürelerinin artması.
Çözümler: TR için PSP-A'nın ağırlığını azaltın, degrade-UX'i etkinleştirin, SLA ≤ bir bütçe ile retrays'i güçlendirin, bir istemci güncellemesi hazırlayın.
Geri dönüş: 60 dakikalık yeşil bir SLI'da ağırlıkları yeniden kazanın.

B) DB: "Büyüme p99 ve bağlantı hataları"

Belirtiler: p99↑, bağlantı sıfırlama hataları, büyüme bekleme olayları.
Çözümler: salt okunur komut dosyalarını etkinleştirin, yazma yükünü sınırlayın, gerekirse havuzu/kopyaları ölçeklendirin - sıcak yük devretme.
Backout: parametre geri dönüşü, replica-prime.

C) Önbellek: "Miss rate ↑ - veritabanı yükü"

Belirtiler: kayıp oranı> %40, CPU DB'nin büyümesi.
Çözümler: Tahliye politikasını dengelemek, bellek/sharding'i artırmak, geçici olarak okumayı etkinleştirmek, kısayol tuşlarında RPS'yi sınırlamak.
Backout: politikayı geri döndürün, sorunlu parçayı yeniden oluşturun.

D) CDN: "Bölgesel içerik bozulması"

Semptomlar: Bir ülkede gecikme/zaman aşımında artış, RUM şikayetleri.
Çözümler: yönlendirme haritasını/GSLB'yi değiştirin, sorunlu POP'u atlayın, TTL'yi azaltın, origin-shield'i etkinleştirin.
İletişim: etki coğrafyası ile durum güncellemeleri.

E) KYC: "Başarısız tanımlamalar"

Belirtiler: düşüş onay oranı, vendor_error büyüme.
Çözümler: trafiğin bir kısmını alternatif bir sağlayıcıya geçirin, kuralların ciddiyetini azaltın (politika çerçevesinde), VIP için manuel bir inceleme başlatın.
Uyum: Tüm değişikliklerin günlüğü, gerekirse Risk/Yasal bildirimler.

11) İletişim (güncelleme ş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) Oyun Kitabı Yazar Kontrol Listesi

• Hedef, sahipler, SLO/SLI ve tetikleyiciler belirtilmiştir.
• Bir "Belirtiler ↔ Hipotezler" tablosu ve bir karar ağacı vardır.
• Beklenen sonuçlar ve güvenlik kapıları ile yürütülebilir adımlar.
• Backout/fallback ve iade koşulları yazılır.
• İletişim şablonu ve güncelleme sıklığı.
• Panolara/uyarılara/günlük aramalarına/izlere bağlantılar.
• Gerekli kanıt bölümü ve tamamlama kriterleri.
• Sürüm, tarih, SLA tazeliği, geçmişi değiştirin.

13) İnceleme kontrol listesi

• Playbook masa üstü/oyun gününde oynanabilir.
• Adımlar güvenlidir (sınırlar/kanarya/otomatik geri alma), sırlar açıklanmaz.
• Roller ve yükselmeler açıktır; IC/İletişim belirtilir.
• Bitişik oyun kitaplarıyla çoğaltma yok; Parametreler kaldırılır.
• Ne zaman durup fallback/rollback'e gidileceği açıktır.
• Belge 1 tıklamayla uyarıdan edinilebilir.

14) Parametrelendirme ve yeniden kullanım

Değişkenleri (bölge, sağlayıcı, eşikler) 'değerlerde gerçekleştirin. '.
Genel adımlar (örneğin, "sağlayıcının ağırlığını azaltma", "degrade-UX'i etkinleştirme") ayrı çalışma kitaplarında verilmelidir.
Şablonlardan jeneratörleri destekleyin: 'Plb new --type = INC -service = payments'.

15) Uygulama Yol Haritası (4-6 hafta)

1. Sayfa uyarılarının bir envanteri - her temel oyun kitabına harita.
2. Şablonlar: YAML/Markdown yapısını, kontrol listelerini ve satırları onaylayın.
3. En iyi 5 senaryo (ödemeler/DB/CDN/KYC/önbellek) - masa üstüne geri dönün/yazın.
4. Entegrasyon: uyarılardan bağlantılar, ChatOps komutları, kanıt botu.
5. Matkap: haftalık mini matkap bir seferde bir oyun kitabı; AAR - uluchsheniya.
6. Tazelik SLA'ları ve Üç Aylık İncelemeler; Kalite metrikleri raporu.

16) Alt satır

Oyun kitapları,'ne yapmalı?! "Kaosunu öngörülebilir bir karar dizisine dönüştüren çatallı ve korkuluklu operasyonel senaryolardır. Oyun kitapları standartlaştırıldığında, uyarılarla entegre edildiğinde ve düzenli olarak eğitildiğinde, ekip daha hızlı yanıt verir, riskler kontrol edilir ve işletme, sömürünün istikrarını ve olgunluğunu görür.