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

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

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

מה מארחים כותבים לרוב בגרסה הפומבית של SLA שהם מראים לציבור? ובכן, השורה הראשונה היא המונח "אמינות" של המארח - אלו הם בדרך כלל מספרים מ-98 עד 99,999%. למעשה, המספרים הללו הם רק המצאה יפה של משווקים. פעם, כשהאירוח היה צעיר ויקר, והעננים היו רק חלום עבור מומחים (כמו גם גישה לפס רחב לכולם), מחוון זמן הפעילות של אירוח היה מאוד מאוד חשוב. כעת, כאשר כל הספקים משתמשים, פלוס או מינוס, באותו ציוד, יושבים על אותן רשתות עמוד שדרה ומציעים את אותן חבילות שירות, מחוון זמן הפעילות אינו ראוי לציון.

האם יש בכלל SLA "נכון"?

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

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

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

מה שכתוב באתר ומה שמחכה במציאות זה שני דברים שונים

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

אם ניקח מארחים מקומיים פופולריים, אז הצעה אחת טובה יותר מהשנייה: תמיכה 25/8, זמן פעילות שרת 99,9999999% מהזמן, חבורה של מרכזי נתונים משלהם לפחות ברוסיה. אנא זכרו את הנקודה לגבי מרכזי נתונים, נחזור אליו מעט מאוחר יותר. בינתיים, בואו נדבר על סטטיסטיקה אידיאלית של סובלנות תקלות ועל מה שעומד בפני אדם כאשר השרת שלו עדיין נופל לתוך "0,0000001% מהכשלים".

עם אינדיקטורים של 98% ומעלה, כל ירידה היא אירוע על סף שגיאה סטטיסטית. ציוד עבודה וחיבור או שיש או שהם לא. אתה יכול להשתמש במארח עם דירוג "אמינות" של 50% (לפי SLA משלו) במשך שנים ללא בעיה אחת, או שאתה יכול "להיכשל" פעם בחודש למשך כמה ימים עם החבר'ה שטוענים 99,99%.

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

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

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

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

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

"מרכזי נתונים רבים ברחבי העולם" הם סיבה לדאגה

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

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

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

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

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

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

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

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

והתוצאה הוא ש

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

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

ראשית, יש לקבוע האם מוכר השירות הוא הבעלים הישיר של המתקנים/מרכז הנתונים. משווקים רבים המשתמשים במודל White Label מנסים כמיטב יכולתם להסוות את מעמדם, ובמקרה זה אתה צריך לחפש כמה סימנים עקיפים. לדוגמה, אם ל-"DCs האירופים שלהם" יש כמה שמות וסמלי לוגו ספציפיים השונים מהשם של חברת הספק. או אם המילה "שותפים" מופיעה איפשהו. שותפים = White Label ב-95% מהמקרים.

לאחר מכן, עליך להכיר את מבנה החברה עצמה, או יותר טוב, להסתכל על הציוד באופן אישי. בין מרכזי נתונים, הנוהג של טיולים או לפחות מאמרי טיול באתר או בבלוג שלהם אינו חדש (כתבנו כאלה זמן и два), שם הם מדברים על מרכז הנתונים שלהם עם תמונות ותיאורים מפורטים.

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

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

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

מקור: www.habr.com