روش های عملیاتی استاندارد

1) SOP چیست و چرا مورد نیاز است

SOP (روش عملیاتی استاندارد) یک دنباله رسمی و معتبر از مراحل برای عملیات قابل تکرار با ورودی/خروجی قابل فهم، نقش ها و معیارهای کیفیت است.

• کاهش تنوع اعدام و خطرات.
• MTTA/MTTR را از طریق اقدامات خارج از قفسه کاهش دهید.
• انطباق و حسابرسی: تکرارپذیری، ردیابی.
• Onboarding: تسریع یادگیری و سایه → انفرادی

راهکار ≠ SOP: playbook - درخت تصمیم با چنگال، SOP - قوانین خطی برای یک سناریوی خاص (یا شاخه playbook).

2) اصول SOP خوب

نتیجه محور: تمرکز بر نتیجه (معیارهای SLO/کسب و کار)، نه فقط مراحل.
ابهام: دستورات، پارامترها، اثرات مورد انتظار و نقاط کنترل.
امنیت به طور پیش فرض: دروازه ها، محدودیت ها، عقب/عقب نشینی ثبت می شوند.
حداقل زمینه: یادداشت های کوتاه + لینک به کتاب های دقیق/تشخیص.
ارتباط: تاریخ بررسی، مالک، نسخه، تاریخ انقضا.
قابلیت اجرا: دسترسی JIT/JEA، چک های پیش شرط، قالب های مصنوعی.

3) ساختار استاندارد SOP (اسکلت)

ID/Version/Review Date
Name and short purpose (what and why)
Scope (Services/Regions/Tenants, SEV/Risk)
Roles and Responsibilities (RACI: R/A/C/I)
Preconditions (accesses, windows, stage, reserve, artifacts)
Materials/tools (dashboards, feature flags, repos, keys)
Quality gates (SLO-gardrails, quorum of probes, alerts)
Step-by-step instruction (step → command → expected result → verification)
Branches (if X - perform Y) [minimum]
Backout/Rollback (start conditions, steps, verification)
Communications (who, when, where; message templates)
Evidence (what to save: screenshots, logs, chexums, links)
Completion (success criteria, watching who closes the ticket)
Change History (What, By Whom, and Why)

4) دایرکتوری SOP و مالکیت

مخزن تنها (Docs-as-Code) با برچسب ها: «دامنه/عملیات»، «سرویس/پرداخت»، «خطر/بالا»، «ارائه دهنده/psp-a».
کارت مالک: تیم، مخاطبین وظیفه، صاحب پشتیبان.
ارتباط SLA (به عنوان مثال بررسی هر ≤90 روز یا پس از حادثه/آزادی).
اعتبار سنج خطی/SOP (CI): تأیید ساختار، پیوندها، صاحبان، دوره بررسی.

5) چرخه عمر SOP

1. شروع (پس از حادثه/تمرین/فرآیند جدید).
2. پیش نویس (نویسنده = صاحب خدمات/فرآیند).
3. بررسی (SRE/امنیت/حقوقی/Comms - توسط دامنه).
4. Pilot (tabletop/game day): زمان را اندازه گیری می کند، → ویرایش می کند.
5. انتشار (نسخه، تاریخ، شماره، قالب در کاتالوگ CMDB/خدمات).
6. کاربرد عملیاتی (حاشیه نویسی در بلیط/چت، جمع آوری شواهد).
7. به روز رسانی (توسط RCA/CAPA، با مهلت بررسی، با تغییرات معماری).
8. بایگانی/تخلیه (جایگزین یک SOP/playbook جدید).

6) ارتباط با مصنوعات همسایه

Playbooks: SOP - «شاخه خطی» در داخل playbook ؛ اشاره ای به قدم ها

Runbook "و: جزئیات فنی/اسکریپت ها در runbook قرار می گیرند، SOP اشاره دارد.
Policies (Policy-as-Code): دروازه های دسترسی، مجوزها، RBAC - لینک های اجباری.
SLO/SLI: معیارهای موفقیت و ریل های گاردی.
ماتریس تشدید: نقش ها/زمان بندی زمانی که اجرای SOP شکست می خورد.
پنجره های تعمیر و نگهداری: الزامات اسلات/کاما برای SOP با خطر بالا.

7) معیارهای عملکرد SOP

زمان اجرا (میانه/p95) - چه مدت طول می کشد.
میزان موفقیت - میزان موفقیت بدون تشدید/بازگشت.
شواهد کامل - کامل بودن مصنوعات.
SLO Impact - آیا در طول/بعد از مرحله (burn-minutes) تخریب وجود دارد.
تراکم نقص - یادداشت های مرور/تمرین در 10 SOPs.
تازگی نسبت SOP ها با بررسی ≤90 روز است.
پذیرش - چه تعداد هشدار/پنجره در واقع به SOP گره خورده است.

8) چک لیست نویسنده SOP

• مرزهای هدف و کاربرد تعریف شده است.
• نقش ها، دسترسی ها و پنجره ها - شرح داده شده است.
• دروازه های کیفیت و SLO قابل اندازه گیری هستند، منابع سیگنال وجود دارد.
• مراحل اجرایی: دستورات/اسکریپت ها، نتایج مورد انتظار، تأیید.
• بازگشت/عقبگرد و معیارهای راه اندازی - روشن است.
• قالب های comm متصل می شوند.
• لیست شواهد ساختار یافته است.
• نسخه/تاریخ/مالک/بررسی مشخص شده است.

9) چک لیست SOP

• پیش شرط JIT/JEA و دسترسی تایید شده است.
• بلیط/اتاق جنگ باز است و حاشیه نویسی گنجانده شده است.
• قابلیت مشاهده: داشبورد/هشدار لازم باز است.
• من مراحل را به ترتیب دنبال می کنم ؛ پس از هر - بررسی
• در صورت نقض گاردریل - عقب نشینی فوری و تشدید.

• بلیط بسته، صفحه وضعیت/comms به روز شد.

[شواهد پر است ؛ بررسی نهایی SLO/کسب و کار SLI.

10) نمونه های SOP (قطعات)

10. 1 SOP: رول عقب قناری (REL-ROLLBACK-01)

The goal: to return the stable version when the burn-rate is exceeded or the p99 grows.
Scope: checkout-api service (prod, EU).
Roles: Release (R), IC (A in SEV-1), P1 (R), Comms (I).
Preconditions: feature flags are ready; JEA accesses; release-annotations included.
Gates: slo. payment_success, http_p99; quorum synthetic EU/US + RUM.
Steps:
1) Freeze unrelated depleys.
2) rollback to tag v2. 3. 7 (command...) → waiting 5 minutes.
I expect: p99↓, error_rate↓, burn-rate <threshold.
3) Business SLI check (payment success, conversion) 10 min.
4) Remove the suppression of alerts; update release annotation.
Backout: if rollback does not help - escalate to IC, enable degrade-UX, consider failover.
Comms: "Rolled back; metrics stabilize; next update in 15 minutes."
Evidence: before/after screenshots, link to dashboards, command and output.
Completion: 30 min green SLOs; close the ticket; assign an RCA (if SEV-1).
Version: 1. 6 (2025-10-28)

10. 2 SOP: ارتقاء DB برنامه ریزی شده (MW-DB-UPGRADE-02)

Purpose: update PostgreSQL minor without data loss.
Area: payments-db (prod EU), 02: 00-04: 00 Europe/Kyiv.
Roles: DB Lead (R), SRE (C), Service Owner (A), Comms (R clients).
Preconditions: OK backups; replica in sync; Test upgrade passed.
Gates: lag≤30s, error_rate<0. 5%, p99 <400ms, SLO green 30m.
Steps:
1) Transfer traffic to canary replica 1%→5%→25%; SLI monitoring.
2) Consistently upgrade secondary nodes → switch over → upgrade of the former primary.
3) Restore replication, check consistency.
Backout: promote stable replica; return writer; rolling back packets.
Comms: T-7/-2 days and T-60/-15 min alert; updates q = 30m during the window.
Evidence: migration logs, checksums, p95/p99 graphs.
Completion: observation 60m without burn; MW report with evidence.
Version: 2. 1 (2025-09-12)

10. 3 SOP: سوئیچینگ ارائه دهنده PSP (PROV-PSP-SWITCH-01)

Objective: to maintain payment success_ratio in case of PSP-A degradation.
Trigger: PSP-A red/partial status + success_ratio% ≥2 drop.
Steps:
1) Install weights: PSP-A 30%, PSP-B 70%.
2) Turn on the degrade_payments_ux; enhance retrays (within SLA).
3) Monitor fraud_rate/chargeback-risk 30m.
Backout: Regain weights at green SLI 60m.
Comms: status page (first ≤15m, cadence 30m).

10. 4 SOP: بررسی بازیابی پشتیبان (DATA-BACKUP-RESTORE-CHECK-03)

Objective: weekly verification of recoverability.
Steps: lift from backup in isolation → hash control → consistency requests → report.
Success criterion: time-to-restore ≤ 45 min; 100% integrity.

11) اتوماسیون در اطراف SOPs

قالب بندی SOP: تولید اسکلت با بلوک RACI/دروازه/کاما.
عملکرد ربات: مراحل با جعبه چک, تایمر, یادآوری آهنگ, شواهد خودکار جمع آوری.
ادغام با CMDB/کاتالوگ - سرویس دارای لیستی از SOP های مربوطه است.
حاشیه نویسی تله متری: «SOP-RUN: <ID> مرحله N» → تجزیه سریع.
سیاست های پذیرش: استقرار/پنجره فقط با دروازه های SOP سبز شروع می شود.

12) ضد الگوهای

SOP بدون بررسی مالک/تاریخ - سند «مرده».
دستورالعمل های نفخ بدون معیارهای موفقیت و عقب نشینی.
دستورات/کلیدهای متناقض - خطر خطا و نشت.
نسخههای مختلف در ویکی و مخزن، واگرایی منابع حقیقت هستند.
بدون شواهد - هیچ چیز برای تایید کیفیت/انطباق.
«یک SOP برای همه موارد» - اجرایی از دست داده است.

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

1. «ند». 1: تایید قالب SOP، لینتر و کاتالوگ ؛ 10 سناریو برتر را انتخاب کنید.
2. «ند». 2: نوشتن SOP برای انتشار/بازگشت/ارائه دهنده/پشتیبان گیری ؛ خلبان هاي تبلتب.
3. «ند». 3: اتصال ربات ChatOps و حاشیه نویسی تله متری ؛ هشدارها را با SOP ها مرتبط کنید.
4. «ند». 4: برنامه بررسی سه ماهه ؛ معیارهای Freshness/Success Rate را وارد کنید.

5. «ند». 5-6: 90% عملیات حیاتی را پوشش میدهد ؛ DR/امنیت SOP ؛ جمع آوری خودکار مدارک

14) خط پایین

SOP عملیات را قابل پیش بینی و قابل اثبات می کند: دروازه های کیفیت یکنواخت، مراحل دقیق، نقش های صریح و برگشت پذیری. در ارتباط با playbooks، سیاستمداران، SLO و اتوماسیون، این عملیات را به یک خط تولید قابل اعتماد تبدیل می کند - واکنش سریع، حداقل خطر و مسئولیت قابل درک.