שעה 02:30 בלילה, ו-45 דקות של אאוטג' שעלו 180,000 שח
ה-on-call קם. 15 alerts ירדו בבת-אחת. ה-dashboard מלא גרפים, CPU, memory, network, disk. שום גרף לא אמר מה הבעיה האמיתית. 45 דקות מאוחר יותר גילו: ה-Redis connection pool התמלא. startup ישראלי עם 10 מיליון בקשות ביום שילם על זה בעסקאות שנפלו, לקוחות שעזבו, ו-SLA penalty.
הבעיה לא היתה חוסר monitoring. הבעיה היתה monitoring לא נכון. 50 alerts שמדדו את התשתית, אפס alerts שמדדו את חוויית המשתמש. לפי דוח PagerDuty 2025, ממוצע ה-on-call מקבל 50 alerts בשבוע, אבל רק 2-5% מהם דורשים התערבות אנושית. 70% מה-SREs דיווחו שעומס ה-on-call גורם ל-burnout ועזיבה (Catchpoint 2025).
Claude שינה את המשוואה. הוא לא רק כותב PromQL, הוא חושב על monitoring כמו SRE מנוסה: alert על סימפטומים שמשתמשים מרגישים, לא על תשתית שרצה.
ארבעת האותות הזהובים, הבסיס של כל monitoring טוב
Google SRE הגדירה ב-2016 את ה-Four Golden Signals: ארבעת המדדים שמכסים כמעט כל בעיה בשירות פרודקשן. Claude מכיר אותם ויגדיר אותם נכון לכל stack.
| אות | מה הוא מודד | דוגמת PromQL |
|---|---|---|
| Latency | כמה זמן לוקח לשרת בקשה | histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) |
| Traffic | כמה בקשות מגיעות | sum(rate(http_requests_total[5m])) |
| Errors | כמה בקשות נכשלות | sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) |
| Saturation | כמה קרובים אנחנו לגבול | db_connections_active / db_connections_max |
הפרומפט הנכון ל-Claude: תמיד ציינו את שם השירות ואת שמות ה-metrics המדויקים בסביבה שלכם. Claude יודע PromQL מצוין, אבל הוא לא יכול לדעת שה-metric שלכם נקרא app_http_requests_total ולא http_requests_total.
SLO-based Alerting, לעזוב את ה-CPU ולסמן את מה שחשוב
SLO (Service Level Objective) הוא ההתחייבות לזמינות: "99.9% מהבקשות יסתיימו בהצלחה". ה-error budget הוא ה-0.1% שמותר להיכשל, בתרגום: 43.8 דקות בחודש. כשה-budget מתאזל, עוצרים features ומתמקדים ב-reliability.
Multi-window burn rate alerting הוא הסטנדרט של Google SRE: שני חלונות זמן (למשל 1h ו-5m) חייבים שניהם לחרוג מהסף כדי שה-alert יפעל. כך נמנעים false positives מ-spikes קצרים. בקשו מ-Claude:
כתוב Prometheus alerting rule שמזהה SLO burn rate מהיר:
- SLO target: 99.9%
- Fast burn: 14.4x rate ב-5 דקות ו-1 שעה
- Slow burn: 3x rate ב-30 דקות ו-6 שעות
- severity: page (fast) ו-ticket (slow)
- הוסף annotation עם error budget remaining
- metric: http_requests_total עם labels job, status_code
- job name: "api-service"Grafana Dashboard בפרומפט אחד, כולל import מוכן
עד 2025, בניית Grafana dashboard לקחה שעות: PromQL ידני, panel-by-panel, JSON editing. היום Claude + Grafana MCP Server (הוציאו אותו ב-2026) מאפשרים ליצור dashboard מלא בשיחה אחת. אפילו בלי MCP, Claude מייצר Grafana JSON שניתן לimport ישירות.
טיפ קריטי: תמיד ציינו את ה-datasource UID. ברירת המחדל של Claude היא placeholder, ואז ה-import נכשל. אמרו: datasource uid: "prometheus", type: prometheus.
כתוב Grafana dashboard JSON ל-Node.js API service:
- datasource uid: "prometheus", type: prometheus
- Row 1 (Overview): stat panel, RPS, error rate %, p95 latency. time series, traffic בשעה האחרונה
- Row 2 (SLO): gauge, availability %, error budget remaining (בדקות). time series, burn rate
- Row 3 (Resources): gauge, CPU %, memory %. stat, pod count
- Row 4 (Database): time series, connection pool usage %, slow queries
- Variables: $interval (auto), time picker. Refresh: 30s. Theme: dark.
כל panel עם threshold צבעוני: ירוק / צהוב / אדום.Claude כ-SRE Agent אוטונומי, Anthropic Cookbook 2026
ב-2026 פרסמה Anthropic cookbook רשמי לבניית on-call agent עם Claude Managed Agents. ה-pattern:
- PagerDuty alert מגיע → Claude מתחיל חקירה
- Claude קורא logs, runbooks, ו-Prometheus metrics
- Claude מוצא root cause ופותח PR עם תיקון
- Agent מחכה לאישור אנושי ב-Slack (human-in-the-loop)
- רק אחרי אישור, merge ו-deploy
דוגמה אמיתית מה-cookbook: שירות checkout קרס מ-OOMKilled. Claude זיהה שה-memory limit (128Mi) קטן מדי ל-pricing cache של 14,000 רשומות. הוא העלה את ה-limit ל-256Mi/512Mi, פתח PR, וחיכה לאישור. ה-on-call אישר, בלי לכתוב שורת קוד.
עיצוב הכלים חשוב מהפרומפט: "Tool descriptions drive agent behavior more effectively than elaborate instructions" (Anthropic, 2026). תארו כל כלי בדיוק מה הוא עושה ומתי להשתמש בו.
טעויות נפוצות, ואיך להימנע מהן
- Alert על CPU ולא על error rate: CPU > 80% לא אומר שמשתמשים מרגישים בעיה. Error rate > 1% כן. תמיד שאלו: "האם משתמש מרגיש את זה?" לפני שאתם מגדירים alert.
- for: clause של דקה:
for: 1mמוביל לflapping, כל spike קצר שולח alert. השתמשו ב-for: 3mל-warning ו-for: 5mל-critical. חסכו את ה-burnout. - Alert בלי runbook URL: on-call בשעה 02:30 לא יודע מה לעשות בלי הוראות. כל alert חייב
runbook_urlב-annotations. Claude מצוין בכתיבת runbooks, בקשו ממנו לכתוב runbook לכל alert שאתם מגדירים. - 50+ alerts = 0 alerts אפקטיביים: כשהכל דחוף, שום דבר לא דחוף. בחרו 5-7 alerts קריטיים שמייצגים בעיות משתמשים אמיתיות.
סיכום, מה לקחת מהשיעור הזה
- Alert על סימפטומים, לא תשתית. ארבעת האותות הזהובים, Latency, Traffic, Errors, Saturation, מכסים כמעט הכל.
- SLO + error budget הם הכלי שמאזן בין מהירות פיתוח לstability. בלי error budget, כולם רוצים velocity ואף אחד לא אחראי ל-reliability.
- Claude כותב PromQL מדויק, אבל תמיד ספקו לו שמות metrics ו-labels מהסביבה שלכם. הוא לא יכול לנחש את שמות ה-metric הספציפיים ב-stack שלכם.
- כל alert = runbook. בלי runbook, ה-alert הוא רעש. Claude מצוין בכתיבת runbooks, אחד לכל alert.
- Claude כ-SRE agent עובד, Anthropic פרסמו cookbook רשמי בתחילת 2026 עם pattern מלא לon-call automation עם human-in-the-loop.