SLO / SLA / SLI: המדריך המלא להבדלים ולאיך קובעים יעדי אמינות נכונים

מאת צוות מדיה דיל · 08.08.2026 · DevOps · 9 דק׳

ההבדל המדויק בין SLI, SLO ו-SLA, איך קובעים יעד אמינות ריאלי, ולמה SLA חייב להיות נמוך מה-SLO הפנימי - מדריך מעמיק עם דוגמאות מפרודקשן.

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

הבעיה: "המערכת עובדת טוב" הוא משפט לא מדיד

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

SLI: המדד הגולמי שהכל נבנה עליו

Service Level Indicator הוא מדד כמותי של היבט מסוים בביצועי השירות - לא "המערכת מהירה" אלא "אחוז הבקשות שהוחזרו תוך פחות מ-300 מילישניות". SLI טוב חייב לעמוד בשלושה תנאים: מדיד באופן אוטומטי ועקבי לאורך זמן (לא הערכה סובייקטיבית של מישהו), רלוונטי לחוויית המשתמש בפועל (לא רק נוח למדידה מבחינה טכנית), ו-בעל הגדרה חד-משמעית וברורה של מה בדיוק נחשב "טוב" ומה נחשב "רע" בכל בקשה בודדת. ה-SLI-ים הנפוצים ביותר הם Availability (אחוז הזמן שהשירות זמין ומגיב), Latency (זמן תגובה, לרוב נמדד ב-percentiles כמו p50/p95/p99), Error Rate (אחוז הבקשות שנכשלו), ו-Throughput (כמות הבקשות שהמערכת מסוגלת לעבד בזמן נתון). בחירת ה-SLI-ים הנכונים לכל שירות היא צעד ראשון קריטי - SLI שלא משקף את מה שבאמת חשוב למשתמש (למשל, מדידת זמינות שרת בלי לבדוק אם התשובה שהוא מחזיר בכלל נכונה) נותן תחושת ביטחון כוזבת.

SLO: היעד הפנימי שמנחה החלטות יומיומיות

Service Level Objective הוא היעד המספרי שנקבע ל-SLI, לרוב עם חלון זמן מוגדר - "99.9% מהבקשות מוצלחות בחלון נע של 30 יום". חשוב להבין ש-SLO אינו צריך להיות 100%: יעד מושלם הוא לא רק בלתי מציאותי (אין מערכת מבוזרת אמיתית שמשיגה 100% זמינות לאורך זמן), הוא גם לא רצוי - השגת "תשע-תשיעיות" (99.9999999%) עולה משאבי הנדסה עצומים שברוב המקרים לא מצדיקים את עצמם ביחס לתועלת השולית. הבחירה הנכונה של SLO מתחילה בשאלה: מה רמת האמינות שבאמת משנה למשתמש? אם ההבדל בין 99.9% ל-99.99% זמינות (בערך פי 10 פחות דקות downtime בחודש) לא מורגש בכלל בחוויית המשתמש או בהכנסות, אין סיבה לשלם את המחיר ההנדסי הגבוה של השגתו.

SLA: ההתחייבות החוזית והשלכותיה

Service Level Agreement הוא לא מדד טכני - הוא מסמך משפטי-עסקי שמתחייב על רמת שירות מסוימת ללקוח, לרוב עם פיצוי כספי (credit או החזר) אם ההתחייבות לא מתקיימת. הכלל החשוב ביותר בקביעת SLA: הוא חייב להיות נמוך יותר מה-SLO הפנימי, ולא זהה לו. אם ה-SLO הפנימי הוא 99.9% אבל ה-SLA שהובטח ללקוח הוא גם 99.9%, כל סטייה קלה מהיעד הפנימי כבר מהווה הפרת חוזה - אין שום מרווח ביטחון. SLA טיפוסי נקבע נמוך יותר, למשל 99.5%, כך שהצוות ההנדסי יכול לשאוף ל-99.9% פנימית ועדיין "לספוג" תנודות בלי לחצות את הרף החוזי. הפער בין השניים הוא בעצם מרווח הביטחון הארגוני.

// דוגמה למבנה SLO כקוד - ניתן לבדיקה אוטומטית
const slo = {
  name: 'checkout-api-availability',
  sli: 'successful_requests / total_requests',
  target: 0.999,       // SLO פנימי: 99.9%
  window: '30d',
  sla_target: 0.995     // SLA חוזי ללקוח: 99.5% - מרווח ביטחון
};

Error Budget: הגשר בין SLO להחלטות שחרור בפועל

ברגע שיש SLO מוגדר, נגזר ממנו באופן טבעי Error Budget - הכמות המותרת של "כישלון" בחלון הזמן שנבחר. תקציב זה הוא הכלי המעשי ביותר לניהול יומיומי: כשיש תקציב פנוי, הצוות יכול לשחרר פיצ'רים חדשים בביטחון ואף לקחת סיכונים מחושבים; כשהתקציב מתקרב לאפס, המדיניות הטבעית היא להקפיא שחרורים לא קריטיים ולהתמקד ביציבות עד שהמצב מתאושש. המנגנון הזה, שמפורט בהרחבה במאמר על SRE Architecture, הופך את השאלה "האם בטוח לשחרר עכשיו" משאלה אינטואיטיבית לשאלה עם תשובה מספרית ברורה.

איך בוחרים חלון זמן ל-SLO: 7 ימים, 28 ימים או 90 יום

בחירת חלון הזמן (measurement window) ל-SLO משפיעה באופן ישיר על ההתנהגות המעשית של המערכת. חלון קצר (7 ימים) מגיב מהר לשינויים - תקלה שקרתה יוצאת מהחישוב מהר יחסית, אבל זה גם אומר שהתקציב "מתאפס" תדיר יותר, מה שעלול לתת תחושת ביטחון כוזבת אחרי תקלה חמורה. חלון ארוך (90 יום) נותן תמונה יציבה יותר לטווח ארוך, מתאים במיוחד ל-SLA רבעוניים, אבל תקלה חמורה שקרתה בתחילת החלון תמשיך "לרדוף" את התקציב חודשים ארוכים אחרי שהיא כבר נפתרה בפועל. גישת ביניים נפוצה היא חלון נע (rolling window) של 28 או 30 יום, שמאזן בין רגישות לתנודות קצרות טווח ליציבות מספקת לקבלת החלטות ניהוליות סבירות.

Multi-Window, Multi-Burn-Rate Alerting

לא כל חריגה מה-SLO דורשת את אותה רמת דחיפות. אם המערכת "שורפת" תקציב שגיאות בקצב שיביא לחריגה מה-SLO תוך שעה, זו התראה חמורה שדורשת תגובה מיידית; אם היא שורפת אותו בקצב שיביא לחריגה רק בעוד שבועיים, יש זמן להגיב בצורה מסודרת יותר בשעות העבודה. גוגל פיתחה עבור זה טכניקת Multi-Window, Multi-Burn-Rate Alerting - הגדרת כמה כללי התראה במקביל, כל אחד עם חלון זמן וסף רגישות (burn rate) שונה: התראה "חמה" עם חלון קצר (5 דקות) וסף רגישות גבוה לתגובה מיידית של on-call, לצד התראה "רגועה" עם חלון ארוך יותר (6 שעות) לתקלות איטיות ומתמשכות יותר שדורשות תשומת לב אך לא הערה מיידית באמצע הלילה. הגישה הזו מפחיתה משמעותית alert fatigue בלי לפגוע ביכולת לתפוס תקלות אמיתיות וחמורות מוקדם.

Trade-offs: כמה SLI-ים באמת צריך לעקוב אחריהם

יש פיתוי טבעי להגדיר עשרות SLI-ים לכל שירות "כדי להיות בטוחים שלא מפספסים כלום" - אבל ריבוי מדדים יוצר בעיה משלו: קשה לתעדף, קשה להבין מה באמת קריטי, וקל להיסחף לתחושת "הכל אדום" שמובילה לשיתוק ולא לפעולה. הגישה המומלצת (וזו שגוגל עצמה ממליצה עליה) היא להתחיל במעט מאוד SLI-ים לכל שירות - בדרך כלל שניים עד ארבעה, שמכסים יחד את מה שבאמת חשוב למשתמש (זמינות, latency, error rate) - ורק להוסיף מדדים נוספים כשמתגלה פער אמיתי וממוקד שהמדדים הקיימים לא מכסים. פחות SLO-ים, אבל כאלה שבאמת נאכפים ומשפיעים על החלטות, שווים הרבה יותר מרשימה ארוכה שאיש לא עוקב אחריה בפועל.

SLO ברמת User Journey מול SLO לכל שירות בנפרד

גישה נפוצה, אך מוגבלת, היא להגדיר SLO נפרד לכל מיקרו-שירות בנפרד - שירות האימות עומד ב-99.9%, שירות המלאי ב-99.9%, שירות התשלומים ב-99.9%. הבעיה: אם משתמש צריך שכל שלושת השירותים יעבדו בהצלחה כדי להשלים הזמנה אחת, ההסתברות המצטברת להצלחה של כל השרשרת נמוכה משמעותית מ-99.9% של כל שירות בנפרד (בקירוב, מכפלת ההסתברויות). הפתרון המדויק יותר הוא להגדיר SLO ברמת User Journey שלם - "אחוז ההזמנות שהושלמו בהצלחה מקצה לקצה", לא רק אחוז הצלחה של כל שירות בנפרד. זה דורש מדידה שחוצה שירותים (ולכן נשען על distributed tracing, כפי שמפורט במאמר על Distributed Tracing), אך נותן תמונה הרבה יותר קרובה לחוויית המשתמש בפועל, ולא רק תמונה טכנית מפורקת שנראית טוב על הנייר אך לא משקפת נכון את מה שהמשתמש חווה בסוף התהליך.

תקשורת SLO כלפי מחזיקי עניין לא-טכניים

אחד האתגרים המעשיים הגדולים ביותר בהטמעת SLO הוא לא הטכני - הוא התקשורתי. מנהלי מוצר ומנהלים בכירים לא תמיד מבינים מדוע 99.9% זמינות "לא מספיק טוב" או מדוע השגת עוד "תשיעית" עולה כל כך הרבה משאבי הנדסה. הכלי המעשי ביותר לתרגם את זה הוא המרה לזמן אנושי מוחשי: 99% זמינות שווה בערך 3.65 ימי downtime בשנה; 99.9% שווה כ-8.76 שעות; 99.99% שווה כ-52 דקות בלבד. הצגת הפער הזה במונחים של "שעות" ולא "אחוזים" הופכת את השיחה על תעדוף השקעה באמינות לשיחה עסקית ברורה במקום דיון אבסטרקטי - במיוחד כשמנגידים אותה מול עלות ההנדסה הנדרשת להשגת כל רמת אמינות נוספת.

טעויות נפוצות בהגדרת SLI/SLO/SLA

• מדידה מנקודת מבט השרת, לא המשתמש: SLI שנמדד מבפנים (uptime של התהליך) בלי לבדוק שהתשובה בפועל מגיעה נכון וללא עיכוב חריג ללקוח האמיתי.
• SLO ו-SLA זהים: כפי שהוסבר, זה מבטל את מרווח הביטחון ומגדיל את הסיכון להפרת חוזה בכל תנודה קלה.
• אכיפה תיאורטית בלבד: תקציב שגיאות שקיים במסמך אך לא נבדק בפועל לפני כל דפלוי - מאבד את כל הערך המעשי שלו.
• יעד שנקבע שרירותית: קביעת 99.99% "כי זה נשמע מקצועי", בלי לבדוק מה רמת האמינות ההיסטורית הנוכחית בפועל ומה באמת נדרש מבחינה עסקית - מוביל כמעט תמיד ליעד בלתי מושג שמדכא מורל צוות ומאבד את כל האמון בתהליך המדידה כולו.
• SLO ברמת שירות בודד בלבד: התעלמות מכך שהמשתמש חווה שרשרת שירותים שלמה, לא כל שירות בנפרד - כפי שהוסבר בהרחבה בסעיף על User Journey לעיל.

מתי כדאי ומתי לא, וסיכום

הגדרת SLI/SLO פורמלית משתלמת כמעט לכל שירות production עם משתמשים אמיתיים - גם בגרסה מינימלית, זה נותן שפה משותפת ומספר לעקוב אחריו. SLA חוזי כלפי לקוחות רלוונטי בעיקר במוצרי B2B או תשתית שבהם ללקוחות יש ציפייה עסקית ברורה, ולא תמיד נחוץ למוצרי B2C צרכניים שבהם הציפייה גמישה יותר. הכלל המעשי: מתחילים תמיד ב-SLI פשוט ומדיד, קובעים SLO ריאלי מבוסס נתונים היסטוריים בפועל ולא שאיפה תיאורטית, ורק כאשר יש בשלות תפעולית מוכחת ומספקת לעמוד ביעד באופן עקבי לאורך זמן ממושך, ולא רק בחודש בודד של מזל - שוקלים להפוך אותו ל-SLA חוזי כלפי לקוחות, עם מרווח הביטחון המתאים שהוסבר קודם. בפרויקטים שאנחנו בונים במדיה דיל, אנחנו תמיד ממליצים ללקוחות לחיות עם ה-SLO הפנימי במשך כמה חודשים לפני שהם מתחייבים עליו כ-SLA חוזי כלפי הלקוחות שלהם - כי רק ניסיון מעשי מצטבר לאורך זמן מגלה את כל התרחישים החריגים והבלתי צפויים שהיעד התיאורטי, בישיבת תכנון בודדת, פשוט לא היה יכול לחזות מראש.

תגיות: SLO · SLA · SLI · Error Budget · Reliability · SRE · Availability

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