On-call & Incident Response

בישראל, on-call לא מגיע עם מדריך. בסטארטאפ של 12 מהנדסים, שלושה אנשים מחלקים ביניהם תורנות שבועית עם PagerDuty ו-OpsGenie כבר מגיוס שלישי. בחברות גדולות כמו Wix, Monday.com ו-IronSource, ה-on-call מובנה לתוך squad structure — לכל squad יש primary ו-secondary משלו. אבל בשני המצבים, הכלים הם זהים: PagerDuty לניהול escalation ו-OpsGenie לניהול schedules, alert routing, ו-status pages.

המציאות שקורסים לא מלמדים: alert ב-2 בלילה על שגיאה שאתם לא מכירים, runbook שלא עודכן מאז 2023, ו-Slack של חברה שמחכה לעדכון. המיומנות כאן היא לא רק טכנית — זו יכולת להתנהל תחת לחץ, לתקשר מצב במהירות, ולקבל החלטות עם מידע חסר.

מינוחים שחייבים לדעת:
- **PagerDuty** — הפלטפורמה הנפוצה ביותר לניהול on-call. מקבל alerts מ-Prometheus/CloudWatch/Datadog ומפנה לאדם הנכון.
- **OpsGenie** (Atlassian) — אלטרנטיבה נפוצה, אינטגרציה טובה עם Jira.
- **Incident.io** — פלטפורמה מודרנית לניהול incident workflow ישירות מ-Slack.
- **MTTD** (Mean Time to Detect) — זמן ממוצע מרגע שהבעיה מתרחשת עד שנוצר alert.
- **MTTR** (Mean Time to Resolve) — זמן ממוצע מ-alert עד שהשירות חזר לנורמלי.

הדבר הראשון שעושים כשמגיע alert הוא לסווג אותו. סיווג שגוי גורם לאחד משני כשלים: over-react (מעירים את ה-CEO על בעיה שניתן לתקן מחר בבוקר) או under-react (מחכים עם SEV3 לשירות שכבר נפל ל-30% מהמשתמשים). הסיווג קובע מי מעורב, באיזה מהירות, ומה נמדד לאחר מכן.

**SEV1 — קריטי. שירות ראשי לא זמין לכלל המשתמשים.**
- קריטריונים: 0% availability, data loss בפועל, חדירת אבטחה פעילה, revenue loss בקצב של >$1K/דקה.
- דוגמאות: אתר ראשי ב-503 לכולם, DB לא נגיש, API payment לא מגיב.
- SLA תגובה: האדם on-call מתחיל לטפל בתוך **5 דקות**. Incident Commander מתמנה מיד.
- ערוצי תקשורת: status page מתעדכן, Slack #incidents, לקוחות מקבלים email.

**SEV2 — גבוה. פונקציונליות קריטית פגועה, חלק מהמשתמשים מושפעים.**
- קריטריונים: degraded performance (latency p99 > 5x נורמלי), feature ראשי לא עובד ל->20% מהמשתמשים, error rate > 5% בAPI קריטי.
- דוגמאות: checkout flow איטי, תשלומים נכשלים לחלק מהמשתמשים, dashboard לא נטען.
- SLA תגובה: התחלת טיפול בתוך **15 דקות**.

**SEV3 — בינוני. פגיעה שאינה קריטית, workaround קיים.**
- קריטריונים: feature משני לא עובד, error rate < 1% ב-non-critical path, dashboard warning ללא impact על משתמשים.
- דוגמאות: export ל-CSV לא עובד, email notifications מאחרים, search איטי.
- SLA תגובה: תיקון תוך **שעתיים** בשעות עבודה.

**SEV4 — נמוך. בעיה ידועה, אין impact מיידי.**
- קריטריונים: אזהרה בלבד, technical debt שמגיע ל-threshold, bug ממתין לתיקון.
- SLA תגובה: ticket ב-backlog, תיקון בתוך sprint.

**כלל אצבע לסיווג מהיר:**
- שאל "כמה משתמשים מושפעים ועד כמה?"
- שאל "האם revenue או data בסכנה?"
- ספק בין SEV → תמיד בחר SEV גבוה יותר. הורדת severity קל יותר מהעלאה.

Escalation הוא תהליך מובנה, לא כשלון. מהנדס שלא מצליח לפתור SEV1 תוך 15 דקות חייב להסלים — זה חלק מהעבודה, לא חולשה.

**מבנה escalation טיפוסי:**

Primary On-call
    ↓ (15 דקות ללא פתרון, או SEV1 מיידי)
Secondary On-call
    ↓ (30 דקות ללא פתרון, או SEV1 חמור)
Engineering Manager / Tech Lead
    ↓ (45 דקות ללא פתרון, או data loss)
VP Engineering / CTO
    ↓ (customer-facing SEV1 > 1 שעה)
CEO / Board

**RACI matrix לאירוע SEV1:**

| תפקיד | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Primary On-call | פותר את הבעיה | - | - | - |
| Incident Commander | מנהל את ה-incident | מחליט על escalation | כולם | - |
| Engineering Manager | - | תוצאה עסקית | Primary | VP Eng |
| Support Lead | - | תקשורת לקוחות | Incident Commander | - |
| VP Engineering | - | - | - | עדכון כל 30 דקות |

**Incident Commander (IC)** — תפקיד קריטי שמרבית הקורסים לא מזכירים. ב-SEV1, IC הוא אדם אחד שאחראי על תיאום — לא בהכרח הפותר הטכני. תפקידו:
1. לפתוח Slack thread ייעודי לאירוע
2. לנהל זמן — לעקוב שכל update נאמר כל 10 דקות
3. להחליט מתי להסלים
4. להכריז על resolution

**PagerDuty escalation policy בפועל:**

# escalation_policy.yaml (conceptual)
name: production-on-call
steps:
  - notify: primary-on-call
    timeout_minutes: 5
  - notify: secondary-on-call
    timeout_minutes: 10
  - notify: engineering-manager
    timeout_minutes: 15

**טעויות escalation נפוצות:**
- לחכות "עוד דקה" — escalation מאוחר מאריך את ה-MTTR
- להסלים ולהפסיק לעבוד — primary ממשיך לטפל בזמן שה-secondary מתעדכן
- לא לרשום מה ניסית — IC צריך לדעת מה כבר נבדק

Runbook הוא מסמך תפעולי שמצמצם את הזמן בין alert לפעולה. runbook טוב מאפשר למהנדס שמעולם לא ראה את השירות הזה לטפל באירוע ב-80% מהמקרים.

**מבנה runbook תקני (5 סעיפים חובה):**

# Runbook: High Memory Usage — api-service

## Trigger
- Alert name: MemoryUsageHigh
- Condition: container memory > 85% for > 5 minutes
- Severity: SEV2
- Link to Grafana dashboard: https://grafana.internal/d/api-memory

## Immediate Actions
1. ACK the alert in PagerDuty within 5 minutes
2. Post in #incidents: "Investigating high memory on api-service"
3. Check if memory is still rising: `kubectl top pod -n production | grep api`
4. If memory > 95% and rising: restart the pod immediately (see Rollback section)

## Diagnostic Steps
1. Check recent deployments: `kubectl rollout history deployment/api -n production`
2. Check for memory leak patterns: look for steadily rising graph with no drops
3. Check pod logs for OOMKilled events: `kubectl logs -n production deployment/api --previous | tail -50`
4. Check if the issue is isolated to one pod or all replicas
5. Check if a new feature flag was enabled recently

## Rollback
If caused by a recent deployment:

bash
kubectl rollout undo deployment/api -n production
kubectl rollout status deployment/api -n production

If caused by a memory leak without recent deploy:

bash
# Restart pods one at a time to avoid downtime
kubectl rollout restart deployment/api -n production

## Contacts
- Primary owner: @backend-squad Slack
- Escalate to: @sarah (Backend Lead)
- DB issues: @david (DBA)
- Last updated: 2026-03-15 by @matan

**כל alert חייב לקשר ל-runbook שלו.** ב-Prometheus:

groups:
  - name: api.alerts
    rules:
      - alert: MemoryUsageHigh
        expr: container_memory_usage_bytes / container_spec_memory_limit_bytes > 0.85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High memory usage on {{ $labels.pod }}"
          runbook_url: "https://wiki.internal/runbooks/api-memory"
          dashboard_url: "https://grafana.internal/d/api-memory"

ב-PagerDuty, כל service מקושר ל-runbook URL שמופיע ישירות ב-notification.

Runbook שלא עודכן מ-2022 הוא runbook שיוביל אותך לפעולות שגויות. המשמעת בתחזוקת runbooks היא מה שמבדיל בין צוות mature לצוות שלומד מחדש בכל אירוע.

**3 טריגרים לעדכון runbook — חובה:**

1. **לאחר כל incident** — הוסף ל-runbook כל דיאגנוסטיקה שמצאת שלא הייתה שם. אם בילית 20 דקות לגלות את הדבר הזה, חסוך אותן מ-on-call הבא.
2. **לאחר כל שינוי בארכיטקטורה** — שינית מ-Docker Compose ל-Kubernetes? עדכן את כל פקודות ה-kubectl ב-runbooks.
3. **בדיקת ריבעון (quarterly review)** — לבדוק שכל הלינקים עובדים, שהפקודות עדיין נכונות, ושאנשי הקשר עדיין רלוונטיים.

**Runbook testing — אסטרטגיית GameDay:**

# Game Day: פעם ברבעון, מחדירים fault מכוון וסוקרים את ה-runbook
# דוגמה: מחדירים memory pressure ומנהלים את ה-runbook step by step
stress-ng --vm 1 --vm-bytes 80% --timeout 120s &
# עוברים על כל שלב ב-runbook ומוודאים שהוא עובד

**Runbook quality checklist:**

# בדיקה אוטומטית: האם ה-runbook מכיל את הסעיפים הנדרשים?
RUNBOOK_FILE="/path/to/runbook.md"
for section in "## Trigger" "## Immediate Actions" "## Diagnostic" "## Rollback" "## Contacts"; do
  grep -q "$section" "$RUNBOOK_FILE" \
    && echo "PASS: $section" \
    || echo "FAIL: missing $section"
done

**Runbook stale detection — CI/CD integration:**
ניתן להוסיף check ב-CI שמזהיר כאשר runbook לא עודכן יותר מ-90 יום:

LAST_MODIFIED=$(git log -1 --format="%at" -- runbooks/api-memory.md)
NOW=$(date +%s)
DAYS_AGO=$(( (NOW - LAST_MODIFIED) / 86400 ))
[ "$DAYS_AGO" -gt 90 ] && echo "WARNING: runbook not updated in $DAYS_AGO days"

Postmortem הוא הכלי שמונע מאירועים להתחזר. המילה "blameless" היא לא ניסוח מנומס — היא עיקרון הנדסי: **מערכות נכשלות, לא אנשים**. המטרה היא להבין **כיצד** המערכת אפשרה לאירוע לקרות, לא **מי** לחץ על הכפתור הלא נכון.

**מבנה postmortem תקני (Google SRE model):**

# Postmortem: API Outage — 2026-03-20

## Summary
- Duration: 47 minutes (14:23 – 15:10 UTC)
- Severity: SEV1
- Impact: 100% of users could not complete checkout
- Root cause: Deployment of v2.4.1 introduced a DB migration that held
  a table lock for 40+ minutes, blocking all write transactions.

## Timeline
| Time (UTC) | Event |
|---|---|
| 14:15 | v2.4.1 deployed to production via CI/CD pipeline |
| 14:23 | Error rate spike detected by Prometheus (threshold: 5%) |
| 14:24 | PagerDuty alert triggered, on-call acknowledged |
| 14:28 | On-call opened #incident-2026-03-20 Slack channel |
| 14:35 | Identified DB lock as root cause via pg_stat_activity |
| 14:40 | Decision made to rollback — `kubectl rollout undo` initiated |
| 14:52 | Rollback complete, error rate back to 0.1% |
| 15:10 | Confirmed stable, incident closed |

## Contributing Factors (לא אשמות — גורמים מערכתיים)
1. Migration script was not tested against production-scale data (table had 40M rows, test DB had 5K)
2. No DB lock monitoring alert existed
3. Deployment checklist did not include "does this migration acquire locks?"
4. No staging environment with production-scale data

## What Went Well
- Alert fired within 1 minute of first errors
- Rollback procedure was documented and executed quickly
- Communication in #incidents was clear and frequent

## Action Items
| Action | Owner | Due |
|---|---|---|
| Add DB lock duration alert (> 30s) | @david | 2026-03-27 |
| Add "DB migration risk" to deployment checklist | @matan | 2026-03-25 |
| Create staging DB snapshot from production weekly | @infra-squad | 2026-04-03 |
| Add migration dry-run step to CI pipeline | @backend-squad | 2026-04-10 |

**5 Whys — הטכניקה לחפירה עד לשורש:**

השגיאה הנפוצה היא לעצור ב-"Why" הראשון:
- Why 1: למה ה-API נפל? כי ה-DB לא הגיב
- Why 2: למה ה-DB לא הגיב? כי migration החזיק table lock
- Why 3: למה migration החזיק lock? כי לא נבדק על data בסדר גודל production
- Why 4: למה לא נבדק? כי אין staging עם production-scale data
- Why 5: למה אין staging עם production data? כי אין תהליך לreplicate production data ל-staging

ה-Root Cause האמיתי: **חסר תהליך לוולידציה של migrations על production-scale data**. זה מה שה-action items צריכים לפתור.

**Root cause vs Contributing factors:**
הבחנה קריטית שנכשלים בה ב-postmortems:
- **Contributing factor**: "Developer X pushed v2.4.1 without testing" — זה נכון אבל לא מועיל. מה ימנע את זה בפעם הבאה?
- **Root cause**: "אין automated check שמזהה migrations שיכולים לגרום ל-table lock" — זה מה שאפשר לתקן.

Action items שלא מיושמים הופכים postmortem לטקס ריק. בחברות mature, כל action item עוקב אחרי SMART criteria ויש follow-up mechanism.

**SMART criteria לaction items:**
- **Specific**: "הוסף Prometheus alert על DB lock > 30s" — לא "שפר ניטור"
- **Measurable**: "Alert יופעל אם pg_locks wait time > 30s" — ניתן לאמת
- **Achievable**: האם יש לאדם זמן ומשאבים בתוך ה-sprint?
- **Relevant**: קושר ישירות ל-contributing factor שזוהה
- **Time-bound**: Due date מוגדרת — לא "בקרוב"

**דוגמת action item מלא לעומת חסר:**

חסר:

- שפר את תהליך ה-deployment

מלא:

- הוסף שלב "migration dry-run" ל-CI pipeline שמריץ EXPLAIN על כל migration
  ומכשיל את ה-build אם הוא מזהה sequential scan על טבלה > 1M rows
  Owner: @backend-squad
  Due: 2026-04-10
  Ticket: ENG-1847

**Follow-up cadence:**

ב-Google SRE model:
- **1 שבוע**: בדיקת התקדמות quick items (< 2 ימים)
- **1 חודש**: review של כל action items ב-team meeting
- **Postmortem closed** רק כאשר כל action items: done, או explicitly deferred עם justification

**Postmortem meeting בפועל:**

משתתפים: אנשים שהיו מעורבים באירוע + OM
משך: 45-60 דקות
סדר יום:
  1. קריאת timeline (5 דקות)
  2. Contributing factors — כל אחד מזכיר מה ראה (15 דקות)
  3. Action items — הגדרה קולקטיבית (20 דקות)
  4. What went well — חשוב לא לדלג! (10 דקות)
חוקים:
  - אין להזכיר שמות בהקשר שלילי
  - כל בעיה שמוזכרת צריכה לגרור action item
  - Facilitator לא יכול להיות ה-IC שניהל את האירוע

Rotation טוב מחלק את העול באופן הוגן ומבטיח שיש תמיד מישהו שיודע מה קרה השבוע האחרון.

**דפוסי rotation נפוצים:**

**1. Weekly rotation (הנפוץ ביותר):**

שבוע 1: Alice (primary) + Bob (secondary)
שבוע 2: Bob (primary) + Carol (secondary)
שבוע 3: Carol (primary) + Alice (secondary)

יתרון: continuity טוב, פחות handoffs.
חיסרון: שבוע שלם on-call יכול להיות מתיש.

**2. Follow-the-sun (לצוות מרובה אזורי זמן):**

08:00–16:00 UTC: Tel Aviv team
16:00–00:00 UTC: London team  
00:00–08:00 UTC: Austin team

יתרון: אף אחד לא on-call בשעות השינה שלו.
חיסרון: דורש 3 צוותים ו-handoff protocol חזק.

**3. Hybrid: ימי עבודה weekly + לילות/סופי שבוע rotating:**
נפוץ בסטארטאפים ישראלים עם צוות קטן.

**Handoff checklist (עוברים עליו כל שינוי תורנות):**

## On-call Handoff — 2026-04-14 → 2026-04-21

### Open Incidents
- [ ] INC-2341: intermittent 504 on /checkout — not yet root-caused

### Active Alerts (non-critical)
- [ ] DiskUsage warning on worker-3 (65%, threshold 80%) — ETA: monitor

### Recent Deployments
- v3.1.2 deployed Thursday 12:00 — stable
- DB index added Friday 09:00 — monitoring for slow queries

### Known Issues / Watch Items
- Redis memory has been climbing since Tuesday — no action yet but watch
- Traffic expected to spike Monday (marketing campaign)

### Contacts
- Database questions: @david (available all week)
- Infra questions: @infra-squad (Sarah on PTO Mon–Wed, contact @mike)

### Links
- Grafana main dashboard: https://grafana.internal/d/overview
- Recent alerts: https://pagerduty.com/services/api-production

**Shadow shifts — onboarding חדשים:**
לפני שמהנדס נכנס ל-rotation עצמאי, הוא עובר 2–3 shadow shifts:
1. Shadow shift 1: צופה, לא מתערב. מכיר את הכלים.
2. Shadow shift 2: מנהל ה-incident, ה-senior על הקו לשאלות.
3. Shadow shift 3: עצמאי, עם secondary מנוסה.

אין להכניס מהנדס לrotation לפני שהוא עבר את כל השלבים — זה לא קיצור דרך אלא הגנה על שניהם.

On-call burnout הוא לא חולשה אישית — הוא כשל של המערכת. כאשר on-call מקבל יותר מ-3–4 alerts ב-shift לילי אחד, כאשר יותר מ-50% מה-alerts הם false positives, או כאשר מהנדסים מבקשים לעזוב בגלל on-call — יש בעיית מערכת.

**Toil tracking — מדידת העול:**

Toil הוא עבודה שהיא:
- מנואלית (לא automated)
- חוזרת (running the same playbook every week)
- לא מייצרת ערך מתמשך (לאחר שעשיתה, המצב חוזר לנקודת ההתחלה)

# דוגמה לtoil tracking בפייתון — סיכום alerts לפי סוג מה-on-call log
import json
from collections import Counter

# reading from simulated on-call log
alerts = [
    {"name": "DiskFull", "auto_resolved": False, "action_taken": "manual"},
    {"name": "DiskFull", "auto_resolved": False, "action_taken": "manual"},
    {"name": "HighMemory", "auto_resolved": True, "action_taken": "none"},
    {"name": "DiskFull", "auto_resolved": False, "action_taken": "manual"},
    {"name": "ServiceDown", "auto_resolved": False, "action_taken": "rollback"},
]

toil_count = Counter(
    a["name"] for a in alerts 
    if not a["auto_resolved"] and a["action_taken"] == "manual"
)
print("Top toil candidates (automate these first):")
for name, count in toil_count.most_common():
    print(f"  {name}: {count} manual interventions")

**כלל ה-50% של Google SRE:**
אם מהנדס מבלה יותר מ-50% מזמנו ב-toil, זה trigger לפתיחת engineering project לאוטומציה.

**Alert fatigue reduction — 5 טכניקות:**

1. **Alert grouping**: קבץ 10 alerts קשורים ל-notification אחד ב-PagerDuty/Alertmanager
2. **Inhibition rules**: אם DB down, דכא את כל ה-alerts על שגיאות application (הן סימפטום, לא סיבה)

   # Alertmanager inhibition rule
   inhibit_rules:
     - source_match:
         alertname: DatabaseDown
       target_match_re:
         alertname: '.*Error.*'
       equal: ['environment']
   

3. **Alert ownership**: כל alert יש לו owner — אם alert מגיע לצוות שגוי חצי הפעמים, תתקנו את ה-routing
4. **Alert audit**: פעם בחודש, סקור את 10 ה-alerts הנפוצים ביותר. כמה מהם צריכים פעולה? כמה מהם noise?
5. **Auto-remediation**: alerts שדורשים אותה פעולה בכל פעם — אוטומטו אותם

**Automation threshold:**
- 3+ פעמים: כתוב runbook
- 5+ פעמים בחצי שנה: אוטומטו עם script
- weekly: אוטומטו עם cron/Lambda trigger

**מדדי בריאות on-call שצריך לעקוב:**

# שאלות שצוות צריך לדון בהן ב-monthly review:
# כמה alerts לפי שבוע?
echo "Alerts last 4 weeks: $(cat on_call_log.json | jq '[.[] | select(.week >= "2026-03-17")] | length')"
# כמה incidents מחוץ לשעות עבודה?
echo "Off-hours incidents: $(cat on_call_log.json | jq '[.[] | select(.hour < 8 or .hour > 22)] | length')"

**On-call compensation ו-culture בישראל:**
בחברות ישראליות רבות, on-call מגיע עם:
- תשלום נוסף per week on-call (לרוב 10–15% מהמשכורת השבועית)
- recovery time: שעה לכל alert לילי שהוציא ממיטה
- explicit policy שאפשר לדחות sprint commitments כשאתה on-call

הפלואו השכיח ביותר בפרויקטים ישראלים עם AWS:

CloudWatch Alarm
    → SNS Topic
        → PagerDuty webhook
            → on-call phone call/SMS
                → Slack #incidents

**שלב 1: CloudWatch Alarm**

# יצירת CloudWatch alarm שמתריע על שגיאות 5xx מעל סף
aws cloudwatch put-metric-alarm \
  --alarm-name "API-5xx-High" \
  --alarm-description "API error rate above threshold" \
  --metric-name 5XXError \
  --namespace AWS/ApiGateway \
  --statistic Sum \
  --period 60 \
  --threshold 10 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-east-1:123456789:pagerduty-alerts \
  --ok-actions arn:aws:sns:us-east-1:123456789:pagerduty-alerts

**שלב 2: SNS Topic + PagerDuty subscription**

# יצירת SNS topic
aws sns create-topic --name pagerduty-alerts

# הוספת PagerDuty HTTPS subscription
# ה-endpoint מגיע מ-PagerDuty integration settings
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789:pagerduty-alerts \
  --protocol https \
  --notification-endpoint https://events.pagerduty.com/integration/<INTEGRATION_KEY>/enqueue

**שלב 3: PagerDuty → Slack integration**
ב-PagerDuty UI:
1. Extensions → Slack V2 → link workspace
2. בחר service → הגדר notification rules
3. כל SEV1/SEV2 → post ב-#incidents ועם @here

**Prometheus + Alertmanager → PagerDuty (חלופה ל-CloudWatch):**

# alertmanager.yml
receivers:
  - name: pagerduty-critical
    pagerduty_configs:
      - service_key: <PAGERDUTY_INTEGRATION_KEY>
        description: '{{ .CommonAnnotations.summary }}'
        details:
          runbook: '{{ .CommonAnnotations.runbook_url }}'
          dashboard: '{{ .CommonAnnotations.dashboard_url }}'
          firing: '{{ .CommonLabels.alertname }}'

route:
  receiver: pagerduty-critical
  routes:
    - match:
        severity: critical
      receiver: pagerduty-critical
    - match:
        severity: warning
      receiver: slack-warnings

**MTTD ו-MTTR monitoring ב-PagerDuty Analytics:**
PagerDuty מספק metrics מובנים:
- Incident Volume: כמה incidents לפי שבוע/חודש
- MTTD: זמן מ-alert נוצר עד acknowledged
- MTTR: זמן מ-alert נוצר עד resolved
- Interruptions: כמה פעמים on-call הוצא מהשינה

אלה המדדים שצוות mature מייצא ל-Grafana ועוקב אחריהם כ-SLO.