הקמת ניטור SLO/SLI: יעדים, מדדים והתראות

לעתים קרובות אנו נתקלים במצב שבו הניטור מראה ירוק, אך המשתמשים מתלוננים על האטות. SLO ללא SLI הוא רק מספר במסמך. SLI ללא SLO הוא מדד ללא משמעות. יחד, הם עונים על השאלה העסקית: "האם השירות עובד טוב מספיק?" הניסיון שלנו מראה שהפער בין לוח המחוונים לחוויית המשתמש הוא מקור לבעיות נסתרות. אנו מגדירים ניטור SLO/SLI כך שלכל התראה יש הצדקה עסקית ישירה. פעם היה לנו לקוח מסחר אלקטרוני: הניטור הראה זמינות של 99.9%, אך שיעור ההמרה ירד. התברר שההתראות לא התחשבו בזמן השהיה — דפים נטענו תוך 5 שניות. לאחר יישום SLI זמן השהיה ו-SLO של 95% מהבקשות <200ms, הבעיה נעלמה. אם יש לך מקרה דומה, אנו יכולים לעזור. למידע נוסף על הרעיון, ראה SLO (Service Level Objective).

SLI: מה אנו מודדים

SLI (Service Level Indicator) הוא מדד כמותי ספציפי המתאר את התנהגות השירות מנקודת מבטו של המשתמש. לא "עומס CPU" אלא "חלקם של בקשות מוצלחות." לא "זיכרון פנוי" אלא "זמן השהיה בתגובה."

SLIs סטנדרטיים לשירות HTTP: SLI זמינות — חלקם של בקשות מוצלחות (לא 5xx) מתוך כל הבקשות:

sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m])) 

SLI זמן השהיה — חלקם של בקשות שהושלמו מהר יותר מסף מסוים. "99% מהבקשות מהר יותר מ-300ms" הוא SLI. נוסחה:

sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) / sum(rate(http_request_duration_seconds_count[5m])) 

חשוב: SLI זמן השהיה באמצעות היסטוגרמה. אם המדדים מגיעים רק כ-gauge (ערך ממוצע), ה-SLI יהיה לא מדויק. sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m])) על מדדי היסטוגרמה מקוריים הוא הגישה הנכונה.

כיצד לבחור את ה-SLIs הנכונים לשירות שלך?

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

SLO: ערך יעד

SLO (Service Level Objective) הוא ערך היעד עבור SLI לאורך תקופה. דוגמאות טיפוסיות:

• זמינות: 99.9% מהבקשות מוצלחות במשך 30 יום
• זמן השהיה: 95% מהבקשות הושלמו תוך 200ms במשך 30 יום
• רעננות (עבור צינורות נתונים): 99% מהנתונים מופיעים בטבלה תוך 5 דקות מיצירתם

זמינות של 99.9% במשך 30 יום פירושה 43.8 דקות של זמן השבתה מותר בחודש. זהו תקציב השגיאות. הפרת SLO פירושה חריגה מהתקציב.

כללי רישום עבור SLO

SLO מחושב על פני תקופה ארוכה (30 יום). חישוב שאילתת PromQL על פני 30 יום בזמן אמת הוא יקר. הפתרון הוא כללי רישום שמצברים נתונים באופן מצטבר.

ב-sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) / sum(rate(http_request_duration_seconds_count[5m])) :

---
groups:
  - name: slo.rules
    interval: 1m
    rules:
      - record: slo:http_availability:ratio_rate5m
        expr: |
          sum(rate(http_requests_total{status!~"5..", service="checkout"}[5m])) / sum(rate(http_requests_total{service="checkout"}[5m]))
      - record: slo:http_availability:ratio_rate30d
        expr: |
          sum_over_time(slo:http_availability:ratio_rate5m[30d]) / count_over_time(slo:http_availability:ratio_rate5m[30d])
---

הכלל הראשון הוא חלון הזמן הנוכחי של 5 דקות (משתנה במהירות, עבור לוח מחוונים בזמן אמת). השני הוא חלון נע של 30 יום (משתנה לאט, מציג עמידה ב-SLO).

בלוח מחוונים של Grafana, פאנל סטטיסטי עם histogram_quantile יציג: 99.96% — ותראה מיד אם אתה בתוך ה-SLO של 99.9%.

מדוע Burn Rate היא הגישה הטובה ביותר להתראות?

התראה נאיבית "SLI ירד מתחת ל-SLO" מופעלת מאוחר מדי — כשהתקציב כבר מוצה. הגישה הנכונה היא התראות Multi-Window, Multi-Burn-Rate (סטנדרט Google SRE Book). Burn rate היא מהירות צריכת תקציב השגיאות. Burn rate = 1 פירושו הוצאה בדיוק כמתוכנן. Burn rate = 14.4 פירושו שבקצב הנוכחי, תקציב השגיאות ימוצה תוך שעתיים במקום 30 יום.

התראה על burn rate גבוה באופן קריטי (שריפה מהירה):

---
- alert: SLOHighBurnRate
  expr: |
    ( slo:http_availability:ratio_rate1h < (1 - 14.4 * (1 - 0.999)) )
    and
    ( slo:http_availability:ratio_rate5m < (1 - 14.4 * (1 - 0.999)) )
  for: 2m
  labels:
    severity: critical
    service: checkout
  annotations:
    summary: "High burn rate: error budget depletes in <2h"

ההתראה מופעלת רק כאשר שני החלונות (1 שעה ו-5 דקות) מראים burn rate גבוה — זה מונע חיובי שווא מקפיצות קצרות.

כלים עבור SLO

כתיבת כל כללי הרישום וההתראות ידנית היא גוזלת זמן. ישנם כלים:

Sloth — מחולל כללי SLO עבור Prometheus. תאר SLO ב-YAML, ו-Sloth ייצור כללי רישום וכללי התראות מרובי-חלונות:

version: "prometheus/v1"
service: "checkout-api"
labels:
  team: backend
slos:
  - name: requests-availability
    objective: 99.9
    sli:
      events:
        error_query: sum(rate(http_requests_total{status=~"5..", service="checkout"}[{{.window}}]))
        total_query: sum(rate(http_requests_total{service="checkout"}[{{.window}}]))

Pyrra — מסגרת SLO מקורית ל-Kubernetes עם ממשק משתמש משלה ויצירה אוטומטית של כללי Prometheus באמצעות CRD.

מה כלול בהגדרת SLO/SLI

המהנדסים שלנו עם ניסיון של 5+ שנים בתחום ה-observability ו-50+ פרויקטי ניטור מבטיחים:

• ביקורת מדדים נוכחיים (מקורות, שלמות, דיוק)
• הגדרת SLOs יחד עם בעלי השירות
• כתיבת כללי רישום והתראות מרובי-חלונות
• פיתוח לוח מחוונים עם תקציב שגיאות ו-burn rate
• תיעוד ב-runbook (פעולות כאשר התקציב נחצה, גורמים אחראיים)
• תמיכה לאחר היישום (שבועיים של ייעוץ)

העלות הממוצעת של זמן השבתה במסחר אלקטרוני יכולה להיות משמעותית. הגדרת ה-SLO שלנו מפחיתה את ה-MTTR ב-40%, ומונעת הפסדים משמעותיים בשנה על שירות בודד.

הגדרת SLO שלב אחר שלב

1. ביקורת מדדים: בדוק היסטוגרמה, תקינות מיפוי קודי תגובה.
2. הגדר SLIs: בחר מדדים המשקפים חוויית משתמש.
3. סכם על SLOs: עם בעל המוצר, הגדר אחוזי יעד ותקופות.
4. כתוב כללי רישום: צור כללי Prometheus עבור מצברים לטווח ארוך.
5. הגדר התראות מרובי-חלונות: יישם התראות המבוססות על burn rate.
6. לוח מחוונים ו-runbook: הצג תקציב שגיאות, תעד פעולות.

דוגמה ל-SLOs טיפוסיים עבור שירותים שונים

כיצד העבודה בנויה

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

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

תעד SLOs ב-runbook: מה לעשות כאשר burn rate גבוה, מי אחראי, לאן להסתכל הלאה.

מסגרת זמן: הגדרת SLO לשירות אחד עם לוח מחוונים והתראות — 2–3 ימים.

קבל שליטה שקופה על אמינות. צור קשר — נספר לך כיצד ליישם ניטור SLO על המחסנית שלך. או פשוט כתוב לנו — נבחר את הפתרון האופטימלי לתקציב שלך.