Operatsiyalar pleybuklari

1) Pleybuk nima va u runbook dan qanday farq qiladi

Runbook - namunaviy operatsiya/alert uchun chiziqli bosqichma-bosqich yo’riqnoma («bir, ikki, uch»).
Pleybuk - yoyilgan stsenariylar uchun yechimlar daraxti: turli alomatlar → turli gipotezalar → turli xil harakat tarmoqlari. Tanlash mezonlari, geyt shartlari va fallback tarmoqlarini o’z ichiga oladi.
Pleybukning vazifasi - MTTA/MTTR va noaniqlikda improvizatsiya darajasini kamaytirish.

2) Pleybuklar birinchi navbatda qayerda kerak

Hodisalar: SLO (availability/latency/success) ning qulashi, biznes-SLI ning muvaffaqiyatsizligi (konvertatsiya/to’lovlarning muvaffaqiyati).
O’zgartirishlar: relizlar, migratsiyalar, ficha-bayroqlar, konfiglar (canary/rollback).
Xizmat ko’rsatish oynalari: DB/brokerlarni yangilash, sertifikatlarni rotatsiya qilish.
Provayderlar: PSP/KYC/CDN/IDP - degradatsiyalar va svich-over.
Xavfsizlik: buzilgan kalit, shubhali faoliyat.
DataOps: yangilikning kechikishi, sxemaning dreyfi, payplaynning degradatsiyasi.

3) Pleybuk standartlari (minimal tarkibi)

1. Kartochka: Identifikator, Versiya/Sana, Egasi (jamoa/rol), Servislar/hududlar/tenantlar, Bog’liq siyosatlar/standartlar.
2. Ishga tushirish maqsadi va shartlari: qaysi SLO/SLIni himoya qilamiz, qaysi alertlar/triggerlar qo’llaniladi.
3. Simptomlar Gipotezalar: mos kelish jadvali, noto’g’ri gipotezalarni qanday tezda kesish kerak.
4. Yechimlar daraxti: chorrahalar, xavfsizlik geytlari, toʻxtash/davom etish mezonlari.
5. Amallar: runbook’larga buyruqlar/havolalar bilan bosqichma-bosqich bloklar.
6. Kommunikatsiyalar: yangilanish shabloni (Impakt → Diagnostika → Harakatlar → Izlar. ), kanallar va chastotalar.
7. Qaytish/folbek: aniq backout-reja, limitlar va UX degradatsiyasi bayrog’i.
8. Yakunlash mezonlari: metrika, vaqtinchalik kuzatish oynalari.
9. Evidence: nimani saqlash kerak (loglar, grafiklar, skrinshotlar, chiptalarning ID).
10. O’zgarishlar tarixi: changelog, ma’lum cheklovlar.

4) Pleybuklar taksonomiyasi (katalog namunasi)

INC- hodisalar (SLO/SLI, provayderlar, infratuzilma).
REL- relizlar, konkatlar, konfiglar/bayroqlar.
MW- - xizmat koʻrsatish oynalari (DB/queue/cert/OS).
SEC- xavfsizlik (kirish, kalitlar, shubhali harakatlar).
DATA - yangilik/sifat/sxema.
PROV- - tashqi provayderlar (PSP/KYC/CDN/Email/SMS).

5) Hayot sikli va egalik

1. Boshlash: hodisa/simulyatsiya/oʻzgarish natijalari boʻyicha.
2. Loyiha: muallif = servis egasi; revyu: SRE/xavfsizlik/maʼlumotlar (domen boʻyicha).
3. Uchuvchi: tabletop/game-day; o’tish vaqti va nuqsonlarni qayd etish.
4. Nashr: repoda (Docs-as-Code), versiya, teglar, dashbordlarga havolalar.
5. Dolzarblashtirish: RCA/CAPA bo’yicha, har chorakda kamida bir marta; SLA yangilik.
6. Arxiv/depreksiya: dolzarblik almashtirilganda/yo’qolganda.

6) Instrumentlar bilan integratsiya qilish

Alert → Playbook: har bir Page qoidalari aynan bitta asosiy pleybukga murojaat qiladi.
ChatOps: ’/play start <id>’kartochkasini ochadi, evidence oynasini tuzatadi, yangilanish vaqtini belgilaydi.
CMDB/katalog: servisda tegishli pleybuklar roʻyxati, egalari, SLO, dashbordlar mavjud.
GitOps: pleybuklar va runbook’lar Git’da yashaydilar, PR review va linterlardan oʻtadilar.

7) Pleybuklar sifati metrikasi

Actionability: ≥ 90% ishga tushirish «bilmasdan» keskinlashmasdan aniq harakatlarga olib keladi.
Time-to-first-action: Page dan birinchi mazmunli qadamgacha bir-ikki daqiqa.
Coverage:% Bogʻlangan pleybukga ega Page-alertlar (maqsad 100%).
Freshness: pleybuklar ulushi 90 kundan yangi.
Defect rate: 100 ta pleybukga moʻljallangan revyu/simulyatsiyadagi mulohazalar.
Reuse: pleybuk haqiqatan ham necha marta ishlatilgan (va qanday natijalarga olib kelgan).

8) Anti-patternlar

«Pleybuk-ensiklopediya» ning 20 sahifasi yechimsiz.
Natija kutilmagan buyruqlar («X bajarish» - nima oʻzgarishi kerak?).
Hech qanday backout-reja va limitlar yo’q - muammoning kuchayishi xavfi.
Aloqa kanallari/oraliqlari koʻrsatilmagan - PR-xavflarning oʻsishi.
Egasiz/yangilangan sanasiz pleybuk - hech kim uning dolzarbligiga ishonmaydi.
Bitta parametrlash o’rniga o’nlab o’xshash pleybuklar.

9) Pleybukning mini-shabloni (YAML g’oyasi)

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) Tayyor misollar (parchalar)

A) To’lovlar: «Provayder bir mintaqada tanazzulga uchraydi»

Alomatlar: TR-kogortalar success_ratio pasayishi, PSP-A taymautlarining o’sishi

Yechimlar: TR uchun PSP-A ogʻirligini kamaytirish, degrade-UXni yoqish, SLA ≤ byudjeti bilan retrani kuchaytirish, mijozlar yangilanishini tayyorlash.
Backout: 60 daqiqa davomida yashil SLI bilan og’irlikni tiklash.

B) DB: «O’sish p99 va connection errors»

Simptomlar: p99 ↑, connection reset xatolari, wait events oʻsishi.
Yechimlar: o’qish-only stsenariylarni yoqish, write-yuklamani cheklash, pulni/replikalarni, kerak bo’lganda - issiq fayloverni ko’paytirish.
Backout: parametrlar qaytishi, praym nusxasi.

C) Kesh: «Miss rate ↑ → DBga yuk»

Alomatlar: miss rate> 40%, CPU DB o’sishi.
Yechimlar: eviction policy ni muvozanatlash, xotira/shardingni ko’paytirish, vaqtincha read-through ni yoqish, issiq kalitlarda RPSni cheklash.
Backout: siyosatni qaytarish, muammoli shardni qayta yaratish.

D) CDN: «Kontentning mintaqaviy tanazzulga uchrashi»

Alomatlar: bir mamlakatda latency/timeout o’sishi, RUM shikoyatlari.
Yechimlar: routing map/GSLBni o’zgartirish, muammoli POPni chetlab o’tish, TTLni kamaytirish, origin-shield’ni yoqish.
Komms: ta’sir geografiyasi bo’lgan maqom-apdeytlar.

E) KYC: «Identifikatsiyalarning muvaffaqiyatsizligi»

Alomatlar: approve rate pasayishi, vendor_error o’sishi.
Yechimlar: trafikning bir qismini muqobil provayderga o’tkazish, qoidalarning qattiqligini pasaytirish (siyosat doirasida), VIP uchun qo’lda review boshlash.
Compliance: barcha o’zgarishlar jurnali, zarurat bo’lganda Risk/Legal xabarnomalari.

11) Kommunikatsiyalar (yangilanish shabloni)

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 muallifining chek-varaqasi

• Maqsad, egalari, SLO/SLI va triggerlar koʻrsatilgan.
• «Gipoteza belgilari» jadvali va yechimlar daraxti mavjud.
• Kutilgan natijalar va xavfsizlik yorliqlari bilan bajariladigan qadamlar.
• Backout/fallback va qaytarish shartlari yozilgan.
• Aloqa va yangilanish chastotasi namunasi.
• Dashbord/alert/log-qidiruv/treyslarga havolalar.
• Majburiy evidence seksiyasi va yakunlash mezonlari.
• Versiya, sana, yangilik SLA, o’zgarishlar tarixi.

13) Revyuerning chek-varaqasi

• Pleybukni tabletop/game-day da takrorlaymiz.
• Qadamlar xavfsiz (limitlar/kanareyka/avto-qaytarish), sirlar oshkor qilinmaydi.
• Rollar va eskalatsiyalar aniq; IC/Comms koʻrsatilgan.
• Qoʻshni pleybuklar bilan takrorlash yoʻq; parametrlar chiqarildi.
• Qachon to’xtatish va fallback/rollbackga o’tish kerakligi aniq.
• Hujjat alertdan 1 ta bosishda mavjud.

14) Parametrlashtirish va qayta foydalanish

Oʻzgaruvchilarni (mintaqa, provayder, chegaralar)’values.’ga olib chiqing.
Umumiy qadamlar (masalan, «provayderning vaznini kamaytirish», «degrade-UX ni yoqish») alohida runbook bilan rasmiylashtiriladi.
’plb new --type = INC --service = payments’ shablonlaridan foydalaning.

15) Joriy etish yo’l xaritasi (4-6 hafta)

1. Page-alertlarni inventarizatsiya qilish → har bir bazaviy pleybukni taqqoslash.
2. Namunalar: YAML/Markdown tuzilishi, chek varaqlari va linterlarni tasdiqlash.
3. Top-5 stsenariy (to’lovlar/BD/CDN/KYC/kesh) → yozish/tabletopga haydash.
4. Integratsiya: alertlar, ChatOps buyruqlari, evidence-bot.
5. Mashqlar: haftalik mini-drill bir pleybukdan; AAR → yaxshilash.
6. SLA yangilik va choraklik shovqin; sifat metrikasi bo’yicha hisobot.

16) Jami

Pleybuklar - bu «nima qilish kerak?!» xaosini oldindan aytib bo’ladigan qarorlar ketma-ketligiga o’tkazadigan operatsion ssenariylardir. Pleybuklar standartlashtirilganda, alertlar bilan integratsiyalashilganda va muntazam mashq qilinganda, jamoa tezroq harakat qiladi, xavflar nazorat qilinadi, biznes esa foydalanishning barqarorligi va yetukligini ko’radi.