دفترچه های عملیاتی

1) playbook چیست و چه تفاوتی با runbook دارد ؟

Runbook یک دستورالعمل گام به گام خطی برای یک عملیات/هشدار معمولی («انجام یک، دو، سه») است.
Playbook یک درخت تصمیم گیری برای سناریوهایی با چنگال است: علائم مختلف → فرضیه های مختلف → شاخه های مختلف اقدامات. شامل معیارهای انتخاب، شرایط دروازه و شاخه های عقب است.
هدف از playbook کاهش MTTA/MTTR و سطح بداهه نوازی تحت عدم اطمینان است.

2) که در آن playbooks برای اولین بار مورد نیاز

حوادث: افت SLO (در دسترس بودن/تاخیر/موفقیت)، شکست SLI کسب و کار (تبدیل/موفقیت پرداخت).
تغییرات: انتشار، مهاجرت، پرچم ویژگی، پیکربندی (canary/rollback).
پنجره های تعمیر و نگهداری: ارتقاء پایگاه داده/کارگزار، چرخش گواهی.
ارائه دهندگان: PSP/KYC/CDN/IDP - تخریب و نوسان بیش از.
امنیت: کلید به خطر افتاده، فعالیت مشکوک.
DataOps: طراوت تاخیر، رانش مدار، تخریب خط لوله.

3) استانداردهای Playbook (حداقل ترکیب)

1. کارت: شناسه، نسخه/تاریخ، مالک (تیم/نقش)، خدمات/مناطق/مستاجران، سیاست های مرتبط/استانداردها.
2. شرایط هدف و راه اندازی: از کدام SLO/SLI محافظت می کنیم، کدام هشدارها/محرک ها قابل اجرا هستند.
3. علائم ↔ فرضیه ها: جدول مکاتبات، چگونگی قطع سریع فرضیه های نادرست.
4. درخت تصمیم: چنگال، دروازه های امنیتی، معیارهای توقف/ادامه.
5. اقدامات: بلوک های گام با دستورات/لینک به runbook 'و.
6. ارتباطات: قالب به روز رسانی (Impakt → Diagnostika → Deystviya → سورتمه. به روز رسانی)، کانال ها و فرکانس ها.
7. Rollback/folback: پاک کردن برنامه پشتیبان، محدودیت ها و پرچم تخریب UX.
8. معیارهای تکمیل: معیارها، پنجره های زمان مشاهده.
9. شواهد: چه چیزی را ذخیره کنید (سیاههها، نمودارها، تصاویر، شناسه بلیط).

10. تاریخچه تغییرات: تغییرات، محدودیت های شناخته شده

4) طبقه بندی کتاب بازی (به عنوان مثال کاتالوگ)

INC- - حوادث (SLO/SLI، ارائه دهندگان، زیرساخت ها).
REL- - نسخه های منتشر شده، رول بک ها، تنظیمات/پرچم ها.
MW- - پنجره های نگهداری (DB/صف/cert/OS).
SEC- امنیت (دسترسی، کلید، اقدامات مشکوک).
DATA- - طراوت/کیفیت/طرح.
PROV- - ارائه دهندگان خارجی (PSP/KYC/CDN/ایمیل/SMS).

5) چرخه زندگی و مالکیت

1. شروع: بر اساس حادثه/شبیه سازی/تغییر.
2. پیش نویس: نویسنده = صاحب خدمات ؛ بررسی: SRE/امنیت/داده ها (توسط دامنه).
3. خلبان: تبلت/روز بازی ؛ ضبط زمان گذر و نقص.
4. انتشار: در repo (Docs-as-Code)، نسخه، برچسب ها، لینک ها به داشبورد.
5. بروز: با توجه به RCA/CAPA، حداقل یک بار در سه ماهه ؛ تازگی SLA.
6. بایگانی/تخلیه: در صورت جایگزینی/از دست دادن ارتباط.

6) ادغام با ابزار

Alert → Playbook: هر قانون صفحه دقیقاً به یک playbook اساسی اشاره دارد.
ChatOps: '/play start <id> 'کارت را باز می کند، شواهد را برطرف می کند، تایمر به روز رسانی را تنظیم می کند.
CMDB/کاتالوگ: این سرویس دارای لیستی از playbooks مربوطه، صاحبان، SLO، داشبورد است.
GitOps: playbooks و runbooks در Git زندگی می کنند، دارای بررسی های PR و لینترها هستند.

7) معیارهای کیفیت Playbook

قابلیت اجرا: ≥ 90٪ از اجرا منجر به اقدامات خاص بدون افزایش ناخواسته می شود.
Time-to-first-action: یک یا دو دقیقه از صفحه به اولین گام معنی دار.
پوشش:٪ هشدار صفحه که یک playbook محدود (100٪ هدف).
تازگی: نسبت کتابهای بازی تازه تر از 90 روز است.
نرخ نقص: نظرات در بررسی/شبیه سازی برای 100 playbooks.
استفاده مجدد: چند بار playbook در واقع اعمال شده است (و چه نتایجی منجر به آن شده است).

8) ضد الگوهای

«Playbook Encyclopedia» با 20 صفحه بدون درخت تصمیم.

دستورات بدون انتظار از نتیجه («اجرای X» - چه چیزی باید تغییر کند ؟)

هیچ برنامه و محدودیتی وجود ندارد - خطر افزایش مشکل.
کانال های ارتباطی/فواصل نشان داده نمی شود - رشد خطرات PR.
Playbook بدون مالک/تاریخ به روز رسانی - هیچ کس به ارتباط آن اعتقاد ندارد.
ده ها playbooks مشابه به جای یک پارامتری.

9) کتابچه راهنمای مینی الگو (ایده YAML)

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) نمونه های آماده (قطعات)

الف) پرداخت: «ارائه دهنده در یک منطقه کاهش می یابد»

علائم: کاهش success_ratio گروه TR، افزایش زمان PSP-A.
راه حل: کاهش وزن PSP-A برای TR، فعال کردن کاهش UX، تقویت مجدد با بودجه ≤ SLA، آماده سازی به روز رسانی مشتری.
برگشت: وزن را در SLI سبز 60 دقیقه دوباره به دست آورید.

ب) DB: «رشد p99 و خطاهای اتصال»

علائم: p99↑، خطاهای تنظیم مجدد اتصال، رویدادهای انتظار رشد.
راه حل: فعال کردن اسکریپت فقط خواندنی, محدود کردن بار نوشتن, مقیاس استخر/کپی, در صورت لزوم - شکست داغ.
بازگشت به عقب: بازگشت پارامتر، replica-prime.

ج) کش: «خانم نرخ ↑ → بار پایگاه داده»

علائم: نرخ از دست رفته> 40٪، رشد CPU DB.
راه حل: سیاست تخلیه تعادل، افزایش حافظه/شاردینگ، به طور موقت فعال خواندن از طریق، محدود کردن RPS در کلید های داغ.
Backout: سیاست را برگردانید، shard مشکل ساز را دوباره ایجاد کنید.

D) CDN: «تخریب محتوای منطقه ای»

علائم: افزایش تاخیر/وقفه در یک کشور، شکایات RUM.
راه حل ها: تغییر نقشه مسیریابی/GSLB، دور زدن POP مشکل ساز، کاهش TTL، فعال کردن origin-shield.
Comms: به روز رسانی وضعیت با جغرافیای نفوذ.

ه) KYC: «شناسههای ناموفق»

علائم: کاهش میزان تایید، رشد vendor_error.
راه حل ها: بخشی از ترافیک را به یک ارائه دهنده جایگزین تغییر دهید، شدت قوانین را کاهش دهید (در چارچوب سیاست)، یک بررسی دستی برای VIP را آغاز کنید.
انطباق: ورود به سیستم از تمام تغییرات، خطر/اطلاعیه های حقوقی در صورت لزوم.

11) ارتباطات (قالب به روز رسانی)

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) چک لیست نویسنده کتاب

• هدف، صاحبان، SLO/SLI و عوامل مشخص شده است.
• یک جدول «علائم ↔ فرضیه ها» و یک درخت تصمیم گیری وجود دارد.
• مراحل اجرایی با نتایج مورد انتظار و دروازه های امنیتی.
• شرایط برگشت/عقب نشینی و بازگشت بیان شده است.
• قالب ارتباطی و فرکانس به روز رسانی.
• لینک به داشبورد/هشدار/ورود به سیستم جستجو/مسیرهای پیاده روی.
• بخش شواهد مورد نیاز و معیارهای تکمیل.
• نسخه، تاریخ، طراوت SLA، تاریخ را تغییر دهید.

13) چک لیست بررسی

• Playbook قابل پخش در تبلت/روز بازی است.
• مراحل امن هستند (محدودیت/canary/auto-rollback)، اسرار افشا نشده است.
• نقش ها و افزایش ها روشن است ؛ IC/comms نشان داده شده است.
• بدون تکثیر با playbooks مجاور ؛ پارامترهای حذف شده
• روشن است که چه زمانی برای متوقف کردن و رفتن به عقب/عقب نشینی.
• سند از هشدار در 1 کلیک در دسترس است.

14) پارامتری کردن و استفاده مجدد

انجام متغیرها (منطقه، ارائه دهنده، آستانه) در 'values. '.
مراحل عمومی (به عنوان مثال، «کاهش وزن ارائه دهنده»، «فعال کردن کاهش UX») باید در runbooks جداگانه صادر شود.
مولدهای پشتیبانی از قالبها: «plb new --type = INC --service = payments».

15) نقشه راه پیاده سازی (4-6 هفته)

1. موجودی هشدار صفحه → نقشه به هر playbook اساسی.
2. قالب ها: ساختار YAML/Markdown، چک لیست ها و لاینترها را تأیید کنید.
3. 5 سناریو برتر (پرداخت/DB/CDN/KYC/cache) → نوشتن/رول به tabletop.
4. یکپارچه سازی: لینک از هشدارها، دستورات ChatOps، ربات شواهد.
5. تمرین: هفتگی مینی تمرین یک playbook در یک زمان ؛ AAR → uluchsheniya.
6. SLA های تازه و بررسی های سه ماهه ؛ گزارش معیارهای کیفیت.

16) خط پایین

Playbooks سناریوهای عملیاتی با چنگال و نرده است که هرج و مرج «چه کاری باید انجام شود ؟» را به یک دنباله قابل پیش بینی از تصمیمات ترجمه می کند. هنگامی که کتابچه ها استاندارد شده، با هشدارها یکپارچه شده و به طور مرتب آموزش داده می شوند، تیم سریعتر پاسخ می دهد، خطرات کنترل می شوند و کسب و کار ثبات و بلوغ بهره برداری را می بیند.