Incident Management Architecture: איך בונים תהליך תגובה לתקריות שבאמת עובד בשעה 3 בלילה

מאת צוות מדיה דיל · 02.08.2026 · DevOps · 7 דק׳

מדריך ארכיטקטוני לניהול תקריות: מבנה תפקידים, on-call rotations, אוטומציית זיהוי-תיוג-אסקלציה, וכתיבת פוסט-מורטם שבאמת מונע חזרה על אותה תקלה.

הבעיה: כשהמערכת נופלת, מי בכלל אחראי?

ב-3:14 לפנות בוקר יורד ה-checkout service. יש 6 מהנדסים אונליין בסלאק, כולם רואים את ההתרעה, ואף אחד לא יודע אם הוא "אמור" לטפל בזה או שמישהו אחר כבר על זה. עשר דקות עוברות רק על תיאום — לפני שמישהו בכלל פותח לוגים. זו לא בעיה של כישרון טכני, זו בעיה של ארכיטקטורת תגובה חסרה. Incident Management Architecture פותרת בדיוק את זה: היא מגדירה מראש מי עושה מה, באיזה סדר, ובאילו כלים — כך שברגע האמת אין אלתור.

הבלבול הנפוץ הוא לחשוב ש-incident management זה כלי (PagerDuty, Opsgenie) שמותקן ומריצים. בפועל, הכלי הוא רק ה-messenger. הארכיטקטורה האמיתית היא תהליך: זיהוי → תיוג חומרה → הקצאת תפקידים → תקשורת מובנית → פתרון → פוסט-מורטם, כאשר לכל שלב יש automation שתומכת בו.

מבנה התפקידים: Incident Commander ולא ועדה

הטעות הכי נפוצה בתקריות היא ניהול "בוועדה" — כל מי שנמצא באונליין מנסה לתקן במקביל, בלי ריכוז. המודל שעובד, שמקורו ב-Google וב-PagerDuty, מגדיר תפקידים נפרדים:

  • Incident Commander (IC) — לא בהכרח המומחה הטכני החזק ביותר, אלא מי שמנהל את התהליך: קובע עדיפויות, מונע bikeshedding, ומחליט מתי לאסקל.
  • Operations Lead / Tech Lead — מי שבפועל חוקר ומתקן, לרוב עם עוד 1-2 מהנדסים תחתיו לפי תחום.
  • Communications Lead — מעדכן סטטוס פייג', לקוחות פנימיים, ו-stakeholders, כדי שה-IC וה-Tech Lead לא יופרעו כל 5 דקות בשאלות "מה קורה".
  • Scribe — מתעד timeline בזמן אמת. זה קריטי לפוסט-מורטם — זיכרון אנושי אחרי אינסידנט לחוץ הוא לא אמין.

בארגון קטן אדם אחד יכול למלא כמה תפקידים, אבל ההגדרה חייבת להתקיים גם אם התפקידים "מתמזגים" — כלומר יש להחליט מפורשות מי ה-IC של האינסידנט הזה, לא להניח שזה מובן מאליו.

Severity Levels וכללי אסקלציה אוטומטיים

ארכיטקטורה טובה מגדירה מראש רמות חומרה עם קריטריונים אובייקטיביים, לא סובייקטיביים:

  • SEV1 — פגיעה מלאה בשירות core (checkout/login/API ראשי) או אובדן דאטה. Page מיידי ל-on-call + IC אוטומטי + עדכון סטטוס ציבורי.
  • SEV2 — פגיעה חלקית או degradation משמעותי (latency גבוה, פיצ'ר משני נופל). Page ל-on-call, בלי הכרזת IC ציבורית אם נפתר תוך 30 דק'.
  • SEV3 — bug שאינו משפיע ישירות על משתמשים, נכנס לתור רגיל.

האוטומציה הקריטית כאן היא הצמדת severity ל-alert מקורי: ה-alerting rule עצמו (ב-Prometheus/Datadog) כבר מתייג severity, כדי שהמערכת (PagerDuty/Opsgenie) תדע לבד אם לפייג' מיד או לפתוח טיקט. escalation policy עם multiple tiers — אם ה-on-call הראשי לא מגיב תוך 5 דקות, מסלים אוטומטית ל-secondary, ואחריו למנהל הצוות.

Runbooks כקוד, לא כמסמך Confluence מת

ה-ROI האמיתי של incident architecture מגיע מ-runbooks מוכנים מראש לתרחישים חוזרים: "DB connection pool exhausted", "queue backlog חורג", "certificate פג תוקף". runbook טוב הוא לא תיאור פרוזה — הוא רשימת פקודות מוכנות עם תנאי בדיקה:

## Runbook: Queue Backlog High
1. בדוק depth: `queue_depth_metric > threshold`
2. בדוק consumer lag: אם workers stuck -> restart pod group
3. אם backlog > 100k הודעות -> scale-out consumers x3 (auto-scale trigger)
4. אם עדיין גדל אחרי 5 דק' -> escalate ל-DB team (ייתכן bottleneck ב-write)

הרעיון הוא שגם מהנדס שמעולם לא נגע בשירות הספציפי הזה יכול לבצע את הצעדים הראשונים תחת לחץ, בלי לחכות שהמומחה היחיד יתעורר. ארגונים בוגרים שומרים runbooks כקוד (בתיקיית `/runbooks` ב-repo) עם CI שבודק שהפקודות בהם עדיין תקפות מול השירותים הקיימים.

Status Pages ותקשורת חיצונית

חלק שלרוב מתעלמים ממנו הוא ה-communication layer החיצוני. status page אוטומטי (Statuspage, Better Uptime, או פתרון פנימי) שמתעדכן מתוך אותו workflow של האינסידנט — לא ידנית על ידי מישהו שזוכר לעדכן. חיבור זה חשוב כי הוא מוריד עומס תמיכה בזמן אמת (לקוחות שרואים סטטוס לא פותחים 200 טיקטים), ובמקביל בונה אמון — שקיפות לגבי downtime, גם כשהוא כואב, נתפסת כמקצועית יותר משתיקה.

Trade-offs: פורמליות מול מהירות

יש מתח מובנה: תהליך מדי פורמלי (טפסים, אישורים) מאט תגובה בדיוק כשצריך מהירות. תהליך רופף מדי מוביל לבלגן שתיארנו בפתיחה. הפתרון המעשי הוא fast path ל-SEV1 — הרשאה מובנית ל-on-call לבצע שינויי production (rollback, scale, restart) בלי אישורים נוספים כשמוכרז אינסידנט חמור, לצד תהליך רגיל ומבוקר לכל השאר. הביטחון הזה חייב להיות כתוב ומוסכם מראש — לא מומצא תחת לחץ.

trade-off שני הוא כמות ה-on-call rotation. rotation קצר מדי (שבוע) שוחק אנשים; ארוך מדי (חודש) פוגע ב-freshness — אדם ששכח את ה-context של המערכת מגיב לאט יותר. הממוצע התעשייתי הוא שבוע-שבועיים, עם compensation ברור (bonus/יום off) ו-secondary rotation שמונע מצב שבו אדם יחיד נושא את כל העומס.

פוסט-מורטם: התוצר האמיתי של האינסידנט

אינסידנט בלי פוסט-מורטם הוא תקלה שתחזור. פוסט-מורטם טוב הוא blameless — מתמקד במערכת ובתהליך, לא ב"מי לחץ Enter". המבנה הסטנדרטי: timeline מדויק (מתועד על ידי ה-Scribe בזמן אמת, לא משוחזר), root cause אמיתי (לא "השרת נפל" אלא "connection pool הגיע ל-max כי retry storm ללא backoff יצר עומס x10"), ורשימת action items עם owner ותאריך יעד — לא "נשפר monitoring" באוויר.

ה-action items האלה חייבים להיכנס ל-backlog אמיתי עם מעקב, אחרת הפוסט-מורטם הופך לטקס ריק. ארגונים שעושים את זה נכון סוגרים לפחות 80% מה-action items תוך רבעון, ומודדים את זה כ-KPI של תרבות התקריות עצמה.

כלים: PagerDuty, Opsgenie, ומה שביניהם

מבחינה טכנית, שכבת ה-tooling שמממשת את כל הארכיטקטורה הזו בפועל בנויה משכבות: alerting layer (Prometheus Alertmanager, Datadog Monitors) שמייצר את ההתרעה הגולמית; on-call management (PagerDuty, Opsgenie, incident.io) שמנהל rotations, escalation policies, ופייג'ינג בפועל (SMS, שיחת טלפון, push notification) כשההתרעה חייבת תשומת לב אנושית; ו-incident coordination (לרוב ערוץ Slack/Teams ייעודי שנפתח אוטומטית לכל אינסידנט, עם bot שמתעד timeline ומעדכן סטטוס).

שילוב חשוב שרבים מפספסים: חיבור ישיר בין ה-alerting וה-incident tool כך שכשהתרעה מגיעה, נוצר אוטומטית incident record עם channel ייעודי, ולא שאדם צריך "לזכור" לפתוח את זה ידנית. האוטומציה הזו חוסכת בדיוק את דקות התיאום הראשוניות שתיארנו בפתיחת המאמר — ברגע שה-alert יורה, כל התשתית התיאומית כבר קיימת ומחכה, לא נבנית תוך כדי תנועה.

טעויות נפוצות

  • ה-IC גם מתקן וגם מנהל — מוביל לטונל ויז'ן. תפקידים חייבים להיות נפרדים גם כשאותו אדם ממלא שניים בפועל.
  • אין single source of truth לתקשורת — עדכונים מפוזרים בין סלאק, מייל וWhatsApp יוצרים גרסאות סותרות.
  • runbooks לא מתוחזקים — פקודה שמפנה לשירות שכבר לא קיים גורמת לבזבוז זמן קריטי.
  • אין תרגול — התהליך נבדק לראשונה באינסידנט אמיתי, במקום ב-game day מתוכנן (ראו chaos engineering).

תרבות Blameless: למה זה קשה יותר ממה שנשמע

הצהרה על "תרבות blameless" קלה; יישום שלה בפועל קשה משמעותית. הנטייה האנושית הטבעית, במיוחד תחת לחץ ארגוני, היא לחפש "מי אשם" — וברגע שפוסט-מורטם הופך (גם בעקיפין, גם בטון) לחיפוש אשמים, מהנדסים מפסיקים לדווח על טעויות בכנות, ומסתירים מידע קריטי לניתוח שורש הבעיה. הסימנים לתרבות blameless שלא ממש קיימת: פוסט-מורטמים שמזכירים שמות אנשים ספציפיים בהקשר שלילי, שאלות כמו "למה לא בדקת את זה" (במקום "למה התהליך אפשר לזה לקרות"), או תוצאות משמעתיות (אפילו לא רשמיות) שקשורות לתקרית.

המדד הכי אמין לבדוק אם התרבות אכן blameless: האם מהנדסים מדווחים על near-misses (דברים שכמעט נכשלו אבל לא) בלי לחכות שמישהו יגלה? ארגון עם תרבות blameless אמיתית רואה עלייה בדיווח עצמי על טעויות קטנות, כי אין עונש על שקיפות — וזה בדיוק מה שמאפשר לתפוס בעיות לפני שהן הופכות לאינסידנט אמיתי.

מתי כן ומתי לא

לצוותי startup קטנים (עד 10 מהנדסים) לא צריך את כל המנגנון — מספיק on-call rotation בסיסי ו-runbook לתרחישים הכי נפוצים. מעל 20-30 מהנדסים, עם מספר שירותים ותלויות בין-צוותיות, ההשקעה בתפקידים מוגדרים ו-escalation policies אוטומטיות משתלמת מהר מאוד — בדרך כלל אחרי האינסידנט הראשון שנמשך שעתיים בגלל בלבול תיאום.

מדדים שבאמת אומרים משהו: MTTA, MTTD, MTTR

ארגון שרוצה לשפר את תהליך התקריות שלו לאורך זמן חייב למדוד אותו, לא רק להריץ אותו. שלושה מדדים מרכזיים: MTTD (Mean Time To Detect) — כמה זמן עובר מרגע שהתקלה קרתה בפועל ועד שהמערכת (או אדם) מזהה אותה; מדד זה חושף פערי monitoring — אם MTTD גבוה, סימן שחסרות alerting rules על תרחישים אמיתיים. MTTA (Mean Time To Acknowledge) — כמה זמן עובר מרגע ההתרעה ועד שמישהו בפועל מגיב לה; מדד זה בעיקר משקף את איכות ה-escalation policy ואת עומס ה-on-call. MTTR (Mean Time To Resolve) — הזמן הכולל עד לפתרון, המדד הכי "מפורסם" אבל גם הכי פחות אינפורמטיבי לבד, כי הוא מערבב שלושה שלבים שונים לגמרי (זיהוי, תגובה, תיקון) שכל אחד דורש שיפור אחר.

הטעות הנפוצה היא להתמקד רק ב-MTTR הכולל בלי לפרק אותו. צוות עם MTTD גבוה (מגלים תקלות באיחור) צריך להשקיע ב-monitoring, לא ב-runbooks. צוות עם MTTA גבוה (מגלים מהר אבל לא מגיבים) צריך לבדוק את ה-escalation policy או את עומס ה-on-call rotation. פירוק המדד למרכיביו הוא מה שמכוון את ההשקעה הנכונה בפועל.

סיכום

Incident Management Architecture טובה נמדדת לא בכמה תקריות יש, אלא ב-MTTR (Mean Time To Resolve) ובכמה תקריות חוזרות על עצמן. ההשקעה האמיתית היא בהגדרת תפקידים מראש, runbooks שמתעדכנים, ותרבות פוסט-מורטם שבאמת סוגרת פערים — לא רק בקניית כלי alerting.

תגיות: Incident Management · Incident Commander · On-Call · Postmortem · SRE · Escalation Policy · Runbook

← חזרה לבלוג · צור קשר