אנו מפתחים תיעוד תגובה לאירועים (Incident Response) במפתח מוכן: החל מניתוח האירועים הקודמים שלכם ועד לספרי פעולות (playbooks) מוכנים, תבניות תקשורת ושילוב עם כלי העבודה שלכם. נבצע הערכה של הפרויקט שלכם תוך 1–2 ימים — פשוט צרו קשר.
אירוע הוא לא רק תקלה, אלא מצב מלחיץ שבו אנשים פותרים בעיות בלילה עם מידע חלקי. ללא תהליך, כל אירוע נראה אחרת: מישהו מציק לכולם, מישהו שותק, התקשורת כאוטית, וציר הזמן לא מתועד. תיעוד תגובה לאירועים אינו בירוקרטיה — הוא כלי לעבודה תחת לחץ. ראינו: צוותים עם ספרי פעולות מפחיתים את MTTR ב-40–60% בהשוואה לתגובה אד-הוק. כל דקת השבתה עולה לחברה בממוצע 5,000 דולר, ואוטומציה של התהליך משתלמת כבר מהאירוע הקריטי הראשון. עבור חברת קמעונאות גדולה, הפחתנו את העלות הממוצעת של אירוע מ-12,000 דולר ל-4,500 דולר.
סיווג חומרת אירועים
ללא מערכת עדיפויות ברורה, מהנדסים מבזבזים זמן בוויכוחים. אנו מגדירים סולם אחיד:
| חומרה | תיאור | דוגמה | SLA לתגובה |
|---|---|---|---|
| P1 | חוסר זמינות מוחלט של הייצור, אובדן נתונים, פרצת אבטחה | מסד נתונים מושבת, כל המשתמשים מושפעים | 5 דקות |
| P2 | השפלה של פונקציונליות מפתח, חלק מהמשתמשים לא יכולים לעבוד | API מחזיר שגיאות עבור 50% מהבקשות | 15 דקות |
| P3 | השפלה קלה, קיים פתרון עוקף | יצירת דוחות איטית | 30 דקות |
| P4 | בעיות קוסמטיות, ללא השפעה עסקית | שגיאת ממשק משתמש בעמוד ההגדרות | יום העסקים הבא |
סיווג זה מסיר ויכוחים: כולם מבינים את העדיפות. העסק יודע למה בעיה אחת זוכה לתגובה של 5 דקות ואחרת לשעתיים. עבור צוות DevOps, זה הבסיס לSLO ולדיווח.
תפקידים ואחריות במהלך אירוע
בכל אירוע, יש להקצות תפקידים בצורה ברורה. אפילו בצוות קטן, אנו מגדירים מי עושה מה:
| תפקיד | אחריות | פעולות אופייניות |
|---|---|---|
| מפקד האירוע | מוביל את התהליך, לא עוסק בפרטים טכניים | תקשורת, ניהול זמן, קבלת החלטות |
| מוביל טכני | אבחון ופתרון | ניתוח לוגים, יישום תיקון או rollback |
| אחראי תקשורת | תקשורת עם העסק והמשתמשים | כתיבת עדכוני סטטוס, עדכון דף הסטטוס |
| רשם | תיעוד ציר הזמן | רישום אירועי מפתח לצורך post-mortem |
שימו לב: כאשר תפקידים מוקצים, נמנעים מהמצב שבו "כולם מתקנים, אף אחד לא כותב עדכוני סטטוס." אנו מגדירים יצירה אוטומטית של ערוץ Slack בעת הכרזת אירוע — זה מאיץ את התהליך פי 2-3 בהשוואה לגישה לא מובנית. ספרי פעולות יעילים פי 2 מרשימות בדיקה כי הם מכילים פקודות וקישורים מוכנים.
מה כלול בספר פעולות ל-P1?
ספר פעולות הוא מדריך שלב-אחר-שלב לתרחישים הקריטיים ביותר. הנה מבנה מפרויקט אמיתי:
## P1 Incident Response Playbook
### Триггер
Алерт ServiceDown или SLO breach > 1% error rate за 5 минут
### Шаг 1: Объявление инцидента (0-5 минут)
- Создать канал: #inc-YYYY-MM-DD-краткое-описание
- Назначить Incident Commander (IC)
- Оповестить: @oncall-backend, @oncall-infra
### Шаг 2: Первичная диагностика (5-15 минут)
- IC координирует, не занимается техническими деталями
- Ссылки на dashboards: [Production Overview], [Error Rates], [Dependency Map]
- Первый статус в #status-page и #incidents: "Investigating"
### Шаг 3: Митигация (15-60 минут)
- Если причина найдена — применить fix или rollback
- Каждые 15 минут: обновление статуса от IC
- Критерий rollback: если fix не готов за 30 минут
### Шаг 4: Разрешение
- SLO восстановлен, ошибки на baseline уровне
- Финальный статус во все каналы
- Создать post-mortem задачу: Due в течение 48 часовספר פעולות כזה חוסך עשרות דקות ברגע קריטי: אין צורך לזכור מה לעשות. אנו מוסיפים קישורים לדשבורדים ספציפיים ופקודות לאבחון מהיר.
תבניות תקשורת
מהנדסים לא צריכים לחשוב מה לומר לעסק. אנו מכינים ניסוחים לכל סטטוס:
- הודעה ראשונית: "אנו חוקרים בעיה עם [שירות]. [X] משתמשים מושפעים. עדכון הבא בעוד 30 דקות."
- עדכון: "זיהינו את שורש הבעיה ואנו עובדים על תיקון. התאוששות צפויה עד [שעה]."
- פתרון: "הבעיה נפתרה. כל השירותים פעילים. דו"ח post-mortem יפורסם תוך 48 שעות."
תבניות אלו משולבות בפקודות Slack או בדף סטטוס, כך שניתן לפרסם סטטוסים בלחיצת כפתור אחת.
מה כלול בפיתוח התיעוד
- ניתוח היסטוריית אירועים: הפקת תרחישים אמיתיים כדי לשמור על ספרי פעולות מבוססים.
- יצירת מטריצת חומרה והגדרת "מוכן" לכל רמה.
- פיתוח 3–5 ספרי פעולות לתרחישים אופייניים (כשל מסד נתונים, השבתת Kubernetes, DDoS וכו').
- תבניות תקשורת ל-Slack, דוא"ל ודף סטטוס.
- שילוב עם כלים: יצירת ערוצים אוטומטית, התראות on-call, תיעוד ציר זמן.
- הכשרת צוות: סדנה לשימוש בתיעוד.
- תבנית post-mortem עם רשימת בדיקה משולבת.
שלבי העבודה
- ניתוח (יום אחד): ראיונות עם הצוות, סקירת אירועים קודמים, זיהוי בעיות נפוצות.
- עיצוב (יום אחד): פיתוח מטריצת חומרה, דיאגרמות הסלמה, טיוטות ספרי פעולות.
- יישום (1–2 ימים): כתיבת תיעוד, הגדרת אינטגרציות.
- בדיקה (0.5 יום): הרצת אירוע מדומה, ביצוע התאמות.
- מסירה (0.5 יום): העברה דרך Git/wiki, הכשרת צוות.
לוח זמנים ואחריות
זמן פיתוח: 2 עד 5 ימים בהתאם להיקף. השלמנו מעל 50 פרויקטים של תגובה לאירועים עבור צוותים של 5 עד 100 אנשים. אנו מבטיחים: התיעוד ישמש באירועים אמיתיים, ולא יצבור אבק ב-wiki. אנו מספקים חודש תמיכה חינם לאחר המסירה: אנו מתאימים את ספרי הפעולות בהתאם לאירועים הראשונים. הזמינו פיתוח תיעוד — קבלו ספרי פעולות מוכנים, אינטגרציות והכשרת צוות. צרו קשר להערכת פרויקט. קבלו ייעוץ — נראה כיצד התיעוד יפחית את העלויות שלכם.
רשימת בדיקה להערכת בשלות תגובה לאירועים נוכחית
- מטריצת חומרה מוגדרת
- תפקידים מוקצים במהלך אירועים
- ערוץ נפרד לכל אירוע
- התראת on-call אוטומטית מוגדרת
- מבוצעים post-mortems
- קיימות תבניות תקשורת לעסק
מטרת תגובה לאירועים היא להחזיר את המערכת לפעילות תקינה במהירות האפשרית — מתוך פרקטיקת SRE.







