מה זה SLA, SLO ו-SLI? הסבר + משרות בישראל

שלושת המונחים מתארים שכבות של אותו רעיון: SLI הוא המדד שמודדים, SLO הוא היעד הפנימי על אותו מדד, ו-SLA הוא ההתחייבות החוזית ללקוח עם פיצוי אם מפרים אותה. בלוח HiTakeJob פתוחות כרגע 17 משרות שמזכירות Prometheus, 20 שמזכירות Grafana ו-110 שמזכירות Kubernetes.

שלוש השכבות בשורה אחת כל אחת

מונח	מה זה	דוגמה
SLI	המדד עצמו	אחוז הבקשות שהצליחו תוך 300 אלפיות שנייה
SLO	היעד הפנימי על המדד	99.9% מהבקשות יעמדו בכך בחודש
SLA	התחייבות ללקוח, עם פיצוי	99.5% זמינות, אחרת זיכוי

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

איך בוחרים מדד שבאמת משקף משהו

SLI טוב נמדד מנקודת המבט של המשתמש ולא של השרת. שלושה כללים:

• למדוד את מה שהמשתמש חווה. "השרת עונה" אינו מדד; "הבקשה הצליחה בזמן סביר" כן.
• להשתמש באחוזונים ולא בממוצע. ממוצע של 200 אלפיות שנייה יכול להסתיר 2% מהמשתמשים שממתינים חמש שניות.
• להפריד בין סוגי בקשות. טעינת עמוד ראשי והפקת דוח כבד אינם אותו יעד, ומדידה משותפת שלהם מטשטשת את שניהם.

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

מה זה תקציב שגיאות

אם היעד הוא 99.9% בחודש, מותרות כ-43 דקות של כשל. זה תקציב השגיאות - לא מטרה למחוק אלא משאב שמותר לנצל.

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

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

מה המשמעות המעשית של כל תשע

יעד	כשל מותר בחודש	מה זה דורש
99%	כ-7 שעות	ניטור בסיסי, תגובה בשעות העבודה
99.9%	כ-43 דקות	תורנות, פריסה הדרגתית, חזרה אחורה מהירה
99.95%	כ-22 דקות	יתירות בין אזורים ואוטומציה בתגובה
99.99%	כ-4 דקות	תגובה אוטומטית - אדם לא מספיק להתערב

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

איך מתחילים כשאין כלום

הטעות הנפוצה היא לנסות להגדיר יעדים לכל המערכת בבת אחת. מסלול מעשי:

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

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

מה כדאי לדעת לפני שחותמים על SLA

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

זהו תיאור טכני של מנגנון מקובל ולא ייעוץ משפטי - ניסוח חוזי והשלכותיו דורשים בדיקה של גורם מוסמך מטעמכם.

איך זה נראה כשזה עובד

ארגון שמנהל אמינות במספרים מתנהג אחרת בכמה דרכים גלויות: יש דשבורד אחד שמראה את מצב היעדים ואת התקציב שנותר, וכולם מסתכלים בו; ההחלטה אם לשחרר פיצ'ר גדול בשבוע עמוס נשענת על אותו מספר ולא על תחושת בטן; ותחקיר אחרי אירוע מסתיים במשימה קונקרטית בגיבוי הצוות, לא במסמך שנשכח.

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

איפה זה נוגע בעבודה היומיומית

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

מהצד השני, גם המועמד נמדד: מי שמסביר איך בחר מדד ולמה, ומה עשה כשהיעד לא הושג, ולא רק מצטט הגדרות, מסמן ניסיון אמיתי. ההקשר המלא מפורט במה זה SRE ובמה זה Observability, ואפשר לראות משרות במשרות Kubernetes ובמשרות Grafana.

שאלות נפוצות

למה 100% זמינות זה יעד שגוי?

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

מי אמור לקבוע את ה-SLO?

הצוות ההנדסי יחד עם בעלי המוצר. הנדסה יודעת מה אפשרי ובאיזו עלות, ומוצר יודע מה המשתמש באמת צריך. יעד שנקבע רק על ידי צד אחד לרוב שאפתני מדי או חסר משמעות.

מה ההבדל בין SLA ל-SLO?

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

איך מודדים זמינות בפועל?

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

האם זה רלוונטי לחברות קטנות?

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

האם היעד צריך להיות זהה לכל הפיצ'רים?

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

מה עושים כשתקציב השגיאות נגמר באמצע רבעון?

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