נהלי הפעלה סטנדרטיים

1) מהו SOP ומדוע הוא נחוץ

SOP (ראשי תיבות של Standard Operating Procedure) הוא רצף של צעדים שניתן לאמת אותם לפעולות חוזרות ונשנות, עם קלט/יציאות מובנות, תפקידים וקריטריונים איכותיים.

• הפחתת שינויי ביצוע וסיכונים.
• הפחתת MTTA/MTR באמצעות פעולות מחוץ למדף.
• ציות וביקורת חשבונות: רבייה, איתור.
• על הסיפון: להאיץ למידה וצל = סולו.

SOP - ספר מהלכים: ספר מהלכים - עץ החלטה עם מזלגות, SOP - כללים ליניאריים לתרחיש מסוים (או ענף חוברות משחקים).

2) עקרונות SOP טובים

תתמקד בתוצאה (SLO/Business critery) ולא רק בצעדים.
אי בהירות: פקודות, פרמטרים, אפקטים צפויים ונקודות שליטה.
אבטחה כברירת מחדל: שערים, גבולות, גיבוי/רולבק רשומים.
הקשר מינימלי: הערות קצרות + קישורים לספרי הפעלה/אבחון מפורטים.
רלוונטי: תאריך סקירה, בעלים, גרסה, תאריך תפוגה.
יכולת הפעלה: גישות 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) עם תגיות: ”domain/ops',” service/checkout', ”risk/high”, ”domain/psp-a”.
כרטיס בעלים: צוות, אנשי קשר חובה, בעל גיבוי.
רלוונטיות SLA (למשל: סקירה כל 90 יום או אחרי אירוע/שחרור).
לינטר/SOP תוקף (CI): אימות של מבנה, קישורים, בעלים, תקופת ביקורת.

5) מחזור חיים של SOP

1. חניכה (לאחר תקרית/תרגיל/תהליך חדש).
2. טיוטה (מחבר = בעל שירות/תהליך).
3. סקירה (SRE/Security/Legal/Comms - by Domain).
4. פיילוט (יום שולחן/משחק): זמן מדידה, מוצא עריכה.
5. פרסום (גרסה, תאריך, מספר, תבניות בקטלוג CMDB/שירות).
6. יישום תפעולי (הערות בכרטיסים/צ 'אטים, אוסף ראיות).
7. עדכון (על ידי RCA/CAPA, על ידי סקירה של המועד האחרון, על ידי שינויים בארכיטקטורה).
8. ארכיון/ריקון (הוחלף ב SOP/Playbook) חדש.

6) קשרים עם חפצים שכנים

ספרי שעשועים: SOP - ”ענף לינארי” בתוך ספר המהלכים; התייחסות ממדרגות.
”Runbook” ו-: פרטים טכניים/תסריטים ממוקמים בספר ההפעלה, SOP מתייחס.
מדיניות (Policy-as-Code): שערי גישה, הרשאות, RBAC - קישורים מחייבים.
קריטריוני הצלחה ומסילות גארד.
מטריצת הסלמה: תפקידים/זמן כאשר ביצוע SOP נכשל.
חלונות תחזוקה: חריץ/פסיק עבור SOP בסיכון גבוה.

7) מדדי ביצועים של SOP

זמן לביצוע (חציוני/p95) - כמה זמן התהליך לוקח.
אחוזי הצלחה - אחוזי הצלחה ללא הסלמה/rollback.
ראיות שלמות - מלאות של חפצים.
אימפקט SLO - האם יש הידרדרות במהלך/לאחר הצעד (שרפה-דקות).
פגם בצפיפות - סקירה/תרגול הערות ב-10 צפיפות.
רעננות היא הפרופורציה של SOPs עם סקירה של 90 יום.
אימוץ - כמה התראות/חלונות קשורים למעשה ל-SOP.

8) רשימת המחברים של SOP

[ ] גבולות תכלית ויישום מוגדרים.

[ ] תפקידים, נגישות וחלונות ".

[ שערי איכות ] ו-SLO ניתנים למדידה, יש מקורות איתות.

[ ] צעדים ניתנים להפעלה: פקודות/תסריטים, תוצאות צפויות, אימות.

[ ] Backout/rollback וקריטריון השיגור - ברור.

[ ] תבניות התקשורת מחוברות.

[ ] רשימת הראיות מובנית.

[ ] צוין גרסה/תאריך/בעלים/סקירה.

9) רשימת בדיקות SOP

[ ] JIT/JEA אושרו.

[ ] כרטיס/חדר מלחמה הוא פתוח והערות כלולות.

[ ] תצפית: לוחות המחוונים/התראות הדרושים פתוחים.

[ ] אני פועל לפי הסדר; אחרי כל אימות.

[ ] במקרה של הפרת מעקה גינון - גיבוי מיידי והסלמה.

[ ] הראיות מלאות; בדיקת SLO סופית/עסקית.

[ כרטיס ] סגור, עמוד סטטוס/תקשורת מעודכן.

10) דוגמאות SOP (שברים)

10. 1 SOP: שחרור קנרי rollback (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 גיבוי (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/Catalog - לשירות יש רשימה של SOP רלוונטיים.
אנוטציות טלמטריה: ”SOP-RUN: <ID> צעד N” = פירוק מהיר.
מדיניות הכניסה: הפריסה/חלון מתחילה רק עם שערי SOP ירוקים.

12) אנטי דפוסים

SOP ללא סקירת בעלים/תאריך - מסמך ”מת”.
הוראות נפוחות ללא קריטריוני הצלחה וחזרה.
פקודות/מפתחות לא עקביות - סיכון לשגיאות ודליפות.
גרסאות שונות בוויקי ובמאגר הן סטייה ממקורות האמת.
אין ראיות - שום דבר כדי לאשר איכות/ציות.
”סופ אחד לכל המקרים” - יכולת ההרצה אבדה.

13) מימוש מפת דרכים (שבועות 4-6)

1. נד. 1: לאשר תבנית SOP, לינטר וקטלוג; בחר תרחישים 10 ביותר.
2. נד. 2: לכתוב SOP עבור שחרור/rollback/ספק/גיבויים; טייסי שולחן.
3. נד. 3: לחבר בין צ 'אטופס בוט וטלמטריה; התראות שותפים עם SOPs.
4. נד. 4: לוח הזמנים הרבעוני; הכנס מדדי רעננות/הצלחה.
5. נד. 5-6: לכסות 90% של פעולות קריטיות; DR/Security-SOP; אוסף ראיות אוטומטי.

14) השורה התחתונה

SOP הופך את המבצעים לבלתי צפויים ובלתי ניתנים לאימות: שערי איכות אחידים, צעדים מפורטים, תפקידים מפורשים יחד עם חוברות משחקים, פוליטיקאים, SLO ואוטומציה, הדבר הופך את הפעילות לקו ייצור אמין - תגובות מהירות, סיכון מינימלי ואחריות מובנת.