SLA בשירותים מנוהלים: מה באמת נמדד ומה נשאר מחוץ להסכם?

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

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

זמן תגובה או זמן תיקון?

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

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

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

ממתי מתחיל השעון?

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

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

קשור לזה גם מי מסווג את החומרה. כשהספק הוא שקובע אם אירוע הוא P1 או P2, ההתחייבות המחמירה חלה רק כשהוא מחליט שהיא חלה.

מה נכלל בחישוב הזמינות ומה מוחרג ממנו?

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

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

מה קורה כשההתחייבות לא מתקיימת?

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

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

מדדים שכדאי לבקש מעבר לזמינות

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

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

מי אחראי על מה בסביבה היברידית

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

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

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

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

ארגון שמקבל תשובות ברורות לחמש האלה יודע מה הוא קונה. מי שמקבל טבלה עם אחוזים בלבד יגלה את ההגדרות ביום הראשון שבו הוא באמת זקוק להן.