SOP: <פעולה מהירה/מטרה>

סטנדרטיזציה של נהלי הפעלה

1) למה אתה צריך את זה

SOP היא מערכת ההפעלה של החברה. סטנדרטיזציה מסירה את הכאוס ואת ”סגנונות הפרט”, מפחיתה את MTTR,

• להפחית את השונות של פעולות בתקריות ושגרה.
• להאיץ אימונים ולשפר את איכות האיברים.
• הפוך תהליכים לנראים: ביקורת, מדדים, שיפורים בנתונים.
• ודא ציות לדרישות רגולטוריות ופנימיות.

2) עקרונות סטנדרטיזציה

1. תבנית אחידה ומינוח. סימון אחד, הגדרה אחת (SLO, ETA, בעלים).
2. בר-פעולה, לא אנציקלופדיה. רק צעדים ניתנים לאימות, קריטריוני הצלחה, וחזרה.
3. הסתעפות מינימלית. ברור אם/אז פתרונות במקום בהילוך חופשי.
4. ורסינינג ובעלות. לכל SOP יש בעלים, גרסה ותאריך שינוי.
5. אינטגרציה עם כלים. קישורים ללוחות מחוונים, כרטיסים, פישפלאגים, פקודות CLI.
6. זמינות בכוננות. חיפוש מהיר, קריאה, ביצוע עם קישור אחד.
7. שיפור מתמשך. לאחר המוות * משימות עדכון SOP.

3) מסגרת SOP (תבנית)

4) SOP classification

Incident: P1/P2 (critical), P3 (important).
Operational routines: releases, feature flags, database migrations, provider failover.
DR/BCP: disabling the region, restoring from backup, working offline.
Quality control/audit: revisions, readiness questionnaires, access.
Security/compliance: KYC/AML checks, log storage, privacy.

5) RACI: Ownership and Responsibility

Process    R (performer)    A (responsible)    C (consultant)    I (notify)
------------------------      ---------------      -----------------      ---------------      -------------
Create/Update SOP     Domain Owner       Head of Ops         SRE/Compliance      Teams
SLA Revision     Ops Enablement      Head of Ops        Domain leads     All
Use in an incident     On-call          Incident Manager      Domain Owner       Stakeholders

6) SOP lifecycle

1. Initiation: need from post-mortem/incident/audit.
2. Draft: by template, with specific artifacts and commands.
3. Review: Domain Owner + Head of Ops + specialized consultants.
4. Publishing: to portal/repository; annotations on dashboards.
5. Training: short training/screencast, knowledge test.
6. Application: recorded in ticket/incident.
7. Audit: by SLA revision or after a significant event.
8. Archiving: mark 'deprecated', indicate replacement.

7) Documentation as code (minimum standard)

We store SOP in Git (Markdown + YAML metadata), PR review, CI-lint.
Required fields are 'owner', 'version', 'last _ review', 'sla _ review'.
Link checker and structure validator in CI; auto-release portal after merge.
Significant changes - through changelog and notifications in the # ops channel.

8) SOP integrations

Incident Manager: Open SOP button when creating/escalating an incident.
Grafana/Observability: references from panels to relevant SOPs; release annotations.
Feature Flags/Release: canary step templates, SLO gates, rollback.
AI assistant: RAG search by SOP, TL; DR and proposals for action.
BCP/DR: DR-playbook automatically loaded by trigger.

9) SOP quality check (KPI and review)

KPI:
Coverage ≥ 90% of critical scenarios are closed by SOP.
Review SLA ≤ 180 days (share of overdue - 0).
Usage Rate ≥ 70% of overt SOP incidents.
DoD Pass Rate ≥ 90% of steps are closed with success criteria.
Broken Links = 0 (по CI).

Weekly monitoring:
Top 5 used and top 5 obsolete SOPs.
SOP communication ↔ postmortems: whether Preventive Actions have been performed.
Noisy SOPs (frequent rollback returns) are candidates for recycling.

10) Containment standards

Steps → specifics: commands/queries/parameters + expected effect in metric.
Time requirements: ETA for updates/next steps.
Escalation: clear matrix, contacts, backup channels.
Security: warnings, restrictions, PII/secrets - via vault/links.
Localization: in the on-call language (critical for distributed commands).

11) SOP examples (fragments)

SOP: Canary pause in SLO degradation

טריגרים: error_budget_burn> 4x 10m, api_p99> 1. 3 × קו בסיס 10 מ '

• 1) הפסק קנרית בכלי שחרור
• 2) בדוק לוחות ”שינוי בטיחות” ו ־ ”API p99” ‏
• 3) צור כרטיס REG- , ציין קו בסיס/חלון
• DoD: p99 מד 1. 1 × קו בסיס 15m, <קו בסיס × 1 שגיאות. 2
• תנטרל לחלוטין את הדגל, לאחר המוות, 72

SOP: PSP Provider Feilover

טריגרים: quota_usage>0. 9 או outbound_error_rate>2×baseline 5 מ '

• 1) אפשר ניתוב PSP-Y (הגדרה/כפתור)
• 2) בדוק המרת הפקדה ו ־ p95 PSP-Y
• 3) אנוטציות על גרפים, עדכון ב # תקרית-ערוץ
• משרד ההגנה: success_rate-99. 5%, p95 300ms 10ms
• רולבק: 20% החזר חלקי של התנועה בייצוב PSP-X

12) רשימות בדיקה

בדיקת מוכנות SOP:
[ ] המטרה והמעוררים ברורים וניתנים למדידה.
[ ] ישנם צעדים לפקודות/קישורים.
[ ] DoD/Rollback נוסח.
[ ] הסלמה וקשרים רלוונטיים.
[ ] Metadata מלא (בעלים, גרסה, last_review).
[ ] אישור אישור של בודק לינק ומודיע.

בדיקת היישומים של SOP (במקרה):
[ ] SOP נפתח מהקישור Incident Manager/panel.
[ ] השלבים הושלמו והתוצאות נרשמו.
[ ] משרד ההגנה הגיע/לא נבדק.
[ ] פעולות/חוסר עקביות נרשמות בכרטיס.
[ ] עדכוני SOP/שיפורים שנוצרו על ידי משימות (במקרה הצורך).

13) אימונים ועלייה למטוס

מיני קורסים במפתחות SOPs (תשלומים/הימורים/משחקים/KYC).
חובת צל עם שימוש חובה של SOP באימונים.
שבוע מרפאות SOP: 30 דקות של ניתוח/שיפור.
סימולציות (ימי משחק): פיתוח DR ותקרית SOPs.

14) ניהול שינויים ב ־ SOP

RFC באמצעות יחסי ציבור, תגיות ”מינור/מייג 'ור/שבירה”.
שבירת שינויים - עם הכשרת חובה והכרזה.
הודעה אוטומטית לבעלי תחומים ותורנות.
הפרד בין ”SOP-Release Notes” בסוף כל שבוע.

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

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

16) 30/60/90 - תוכנית יישום

30 ימים:
לאשר תבנית SOP וסטנדרטים מינימליים.
צור מאגר 'ops-sop/' (docs-as-code), אפשר קווי CI.
דיגיטציה 10-15 קריטי SOP (תקריות/משחרר/ספקים).
חבר מנהל תקריות ולוחות ראות לקישורי SOP.

60 ימים:
להגיע כיסוי 70% לתרחישים קריטיים.
השק שבועי ”מרפאות SOP” והכשרות תורניות.
הוספת חיפוש AI (RAG) על ידי SOP ו-TL; כרטיסי ד "ר.
הזן Review SLA (180 ימים) ודווח על מקרים קודמים.

90 ימים:
כיסוי ב-90%, שיעור השימוש ב-70% מהתקריות.
מוטבע DoD/Rollback בכל SOP, סגור קישורים שבורים (0).
קשירה של KPI לפקודה OKR (MTTR, שינוי קצב הכישלון).
רטרו ולהקליט השיפורים של הרבעון הבא.

17) FAQ

קיו: במה שונה SOP מאלבום ריצה? ‏
א. נוהל סטנדרטי (תקנה ”איך”). הוראות מפורטות לתיק/שירות ספציפי. לעתים קרובות, ה-SOP מתייחס לאלבום אחד או יותר.

קיו: כמה פרטים צריכים להיות בסופ "ש?
א ”: מספיק כדי שהמפעיל יבצע פעולות מבלי” לחפור ”בצ” אט. כל מה שלא משפיע על הפעולה הוא בחומרי התייחסות נפרדים.

קיו: כיצד לשמור על רלוונטיות? ‏
א ': תיקוני SLA (180 ימים), תזכורות אוטומטיות, תיקוני CI ו-Usage/DoD. כל תקרית סטייה * משימה עדכון SOP.