إجراءات التشغيل الموحدة

1) ما هو SOP ولماذا هو مطلوب

SOP (إجراء التشغيل الموحد) هو تسلسل رسمي ومعتمد من الخطوات للعمليات القابلة للتكرار مع مدخلات/مخرجات مفهومة، وأدوار، ومعايير الجودة.

• تقليل تقلب التنفيذ والمخاطر.
• الحد من MTTA/MTTR من خلال الإجراءات الجاهزة.
• الامتثال ومراجعة الحسابات: قابلية التكاثر والتتبع.
• على متن الطائرة: تسريع التعلم والظل → بمفرده.

SOP ≠ playbook: playbook - decision tree with forks, SOP - linear rules for a secendario (or playbook branch).

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».
بطاقة المالك: فريق، جهات اتصال واجب، مالك احتياطي.
أهمية جيش تحرير السودان (على سبيل المثال كل ≤90 أيام أو بعد الحادث/الإفراج).
محدد/مصدق SOP (CI): التحقق من الهيكل، الوصلات، المالكين، فترة الاستعراض.

5) دورة حياة SOP

1. البدء (بعد الحادث/الحفر/العملية الجديدة).
2. المسودة (المؤلف = مالك الخدمة/العملية).
3. مراجعة (SRE/Security/Legal/Comms - حسب المجال).
4. Pilot (tabletop/game day): قياس الوقت، والعثور على تعديلات →.
5. النشر (النسخة، التاريخ، الرقم، النماذج في كتالوج CMDB/الخدمة).
6. التطبيق التشغيلي (الشروح في التذاكر/الدردشات، جمع الأدلة).
7. تحديث (بواسطة RCA/CAPA، حسب الموعد النهائي للاستعراض، حسب التغييرات المعمارية).
8. المحفوظات/الاستنفاد (يستعاض عنها بكتيب جديد لإجراءات التشغيل الموحدة/قواعد اللعبة).

6) الاتصالات مع القطع الأثرية المجاورة

كتب اللعب: SOP - «فرع خطي» داخل كتاب اللعب ؛ من الخطوات.
Runbook 'و: توضع التفاصيل/النصوص التقنية في دفتر التشغيل، يشير SOP.
السياسات (السياسة كرمز): بوابات الدخول، الأذونات، المكتب الإقليمي لآسيا والمحيط الهادئ - وصلات إلزامية.
SLO/SLI: معايير النجاح والسكك الحديدية.
مصفوفة التصعيد: الأدوار/التوقيت عندما يفشل تنفيذ SOP.
نوافذ الصيانة: متطلبات الفتحة/الفاصلة لـ SOP عالية الخطورة.

7) مقاييس أداء SOP

وقت التنفيذ (متوسط/p95) - كم من الوقت يستغرق الإجراء.
معدل النجاح - معدل النجاح بدون تصعيد/تراجع.
الدليل الاكتمال - امتلاء القطع الأثرية.
تأثير SLO - هل هناك أي تدهور أثناء/بعد الخطوة (دقائق حرق).
كثافة العيوب - مراجعة/ملاحظات التمرين عند 10 SOPs.
النضارة هي نسبة SOPs مع مراجعة ≤90 أيام.
الاعتماد - كم عدد التنبيهات/النوافذ المرتبطة بالفعل بـ SOP.

8) قائمة مراجعة مؤلف SOP

• حدود الغرض والتطبيق المحددة.
• الأدوار والوصول والنوافذ - موصوفة.
• بوابات الجودة و SLO قابلة للقياس، وهناك مصادر إشارة.
• خطوات قابلة للتنفيذ: أوامر/نصوص، نتائج متوقعة، تحقق.
• معايير التراجع/التراجع والإطلاق - واضحة.
• تم إرفاق نماذج comm.
• قائمة الأدلة منظمة.
• النسخة/التاريخ/المالك/الاستعراض محدد.

9) قائمة SOP المرجعية

• تم تأكيد الشروط المسبقة والوصول إلى JIT/JEA.
• التذاكر/غرف الحرب مفتوحة وتدرج الشروح.
• إمكانية الملاحظة: لوحات التحكم/التنبيهات اللازمة مفتوحة.
• أتبع الخطوات المطلوبة ؛ بعد كل - التحقق.
• في حالة انتهاك الحدائق - التراجع الفوري والتصعيد.
• الأدلة كاملة ؛ فحص SLO/business 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/gates/comma block.
مؤدي الروبوت: خطوات مع صناديق الاختيار، وأجهزة التوقيت، وتذكيرات الإيقاع، وجمع الأدلة تلقائيًا.
يحتوي التكامل مع CMDB/Catalog - Service على قائمة من SOPs ذات الصلة.
شروح القياس عن بعد: «SOP-RUN: <ID> step N» → التحليل السريع.
سياسات القبول: يبدأ النشر/النافذة فقط ببوابات SOP خضراء.

12) الأنماط المضادة

SOP بدون مراجعة المالك/التاريخ - وثيقة «ميتة».
تعليمات منتفخة بدون معايير النجاح والنسخ الاحتياطي.
الأوامر/المفاتيح غير المتسقة - مخاطر الأخطاء والتسريبات.
الإصدارات المختلفة في الويكي وفي المستودع هي تباين في مصادر الحقيقة.
لا يوجد دليل - لا شيء لتأكيد الجودة/الامتثال.
«SOP واحد لجميع الحالات» - فقدان قابلية التنفيذ.

13) خارطة طريق التنفيذ (4-6 أسابيع)

1. نيد. 1: الموافقة على نموذج SOP والبطانة والفهرس ؛ اختر سيناريوهات 10 العليا.
2. نيد. 2: كتابة SOP للإصدارات/التراجع/المزود/النسخ الاحتياطية ؛ طيارو الطاولة.
3. نيد. 3: ربط روبوت ChatOps وشروح القياس عن بُعد ؛ تنبيهات الارتباط مع SOPs.
4. نيد. 4: جدول الاستعراض الفصلي ؛ أدخل مقاييس معدل النضارة/النجاح.
5. نيد. 5-6: تغطية 90 في المائة من العمليات الحرجة ؛ DR/Security-SOP ؛ أتمتة جمع الأدلة.

14) خلاصة القول

يجعل SOP العمليات قابلة للتنبؤ والتحقق منها: بوابات جودة موحدة، وخطوات مفصلة، وأدوار صريحة، وقابلية للعكس. بالاقتران مع كتب اللعب والسياسيين و SLO والأتمتة، يحول هذا التشغيل إلى خط إنتاج موثوق - ردود فعل سريعة، الحد الأدنى من المخاطر والمسؤولية المفهومة.