המשמעות של ניהול SLA עבור ספקי SaaS

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

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

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

ההצלחה של כל SLA ובפרט של שירות SaaS תלוי ביכולות:

1. להגדיר את שירותי המפתח הניתנים מנקודת מבט של הלקוחות
2. ניטור הזמינות והביצועים של השירותים שניתנים מנקודת מבט של הלקוחות
3. דיווח מהימן של תוצאות מדדי ה-SLA באופן שיהיה תואם להתחייבויות ה-SLA

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

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

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

נושא נוסף הוא ניהול סיכונים. בכדי ליצור SLA מוצלח צריך לבצע ניהול סיכונים באמצעות ניתוח עלות/תועלת. למרבה הצער, ספקי SaaS לעיתים קרובות אינם יכולים לחשב את הסיכון באופן יעיל כי אין להם מידע מספיק מדוייק ביחס לעלויות הנדרשות בכדי לשיג יעדי SLA מדויקים. כלל האצבע הישן הוא שכל 9 נוסף של זמינות (כמו 99.9% לעומת 99.99% לעומת 99.999%) עולה פי 10 יותר מאשר הקודם. במציאות, ישנם הרבה גורמים הקשורים ל-SLA שמשפיעים על עלות הזמינות, הביצועים ואבטחת המידע. גורמים אלו כוללים: מבנה היישום, מאפייני שימוש, בגרות של תהליכי ניהול שירות של ספק ה-SaaS והיכולות של הפלטפורמה הטכנולוגית עליו נשען היישום.

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

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

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

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

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