SRE (הנדסת אמינות אתרים) היא גישה להנגשת פרויקטים באינטרנט. זה נחשב למסגרת עבור DevOps ומספר כיצד להצליח ביישום שיטות DevOps. מאמר זה מתרגם ספרים מגוגל. הכנתי את התרגום הזה בעצמי והסתמכתי על הניסיון שלי בהבנת תהליכי ניטור. בערוץ הטלגרם и פרסמתי גם תרגום של פרק 6 של אותו ספר על יעדי רמת השירות.
תרגום על ידי חתול. קריאה מהנה!
אי אפשר לנהל שירות אם אין הבנה של מה המדדים באמת חשובים וכיצד למדוד ולהעריך אותם. לשם כך, אנו מגדירים ומספקים רמת שירות מסוימת למשתמשים שלנו, ללא קשר אם הם משתמשים באחד מממשקי ה-API הפנימיים שלנו או במוצר ציבורי.
אנו משתמשים באינטואיציה, בניסיון ובהבנה שלנו לגבי רצונם של משתמשים להבין מדדי רמת שירות (SLIs), יעדי רמת שירות (SLOs) והסכמי רמת שירות (SLAs). מימדים אלו מתארים את המדדים העיקריים שאנו רוצים לפקח עליהם ועליהם נגיב אם לא נוכל לספק את איכות השירות המצופה. בסופו של דבר, בחירת המדדים הנכונים עוזרת להנחות את הפעולות הנכונות אם משהו משתבש, וגם מעניקה לצוות SRE אמון בבריאות השירות.
פרק זה מתאר את הגישה שבה אנו משתמשים כדי להילחם בבעיות של מודלים מטריים, בחירת מדדים וניתוח מטרי. רוב ההסבר יהיה ללא דוגמאות, לכן נשתמש בשירות שייקספיר המתואר בדוגמה ליישום שלו (חפש יצירות של שייקספיר) כדי להמחיש את עיקרי הדברים.
טרמינולוגיה של רמת השירות
קוראים רבים כנראה מכירים את המושג SLA, אך המונחים SLI ו-SLO ראויים להגדרה מדוקדקת מכיוון שבאופן כללי המונח SLA עמוס מדי ויש לו מספר משמעויות בהתאם להקשר. למען הבהירות, אנו רוצים להפריד בין ערכים אלה.
אינדיקטורים
ה-SLI הוא אינדיקטור של רמת השירות - מדד כמותי מוגדר בקפידה של היבט אחד של רמת השירות הניתן.
עבור רוב השירותים, SLI המפתח נחשב להשהיית בקשה - כמה זמן לוקח להחזיר תגובה לבקשה. SLIs נפוצים אחרים כוללים שיעור שגיאות, המתבטא לעתים קרובות כשבריר מכל הבקשות שהתקבלו, ותפוקת מערכת, הנמדדת בדרך כלל בבקשות לשנייה. לעתים קרובות מדידות מצטברות: נתונים גולמיים נאספים תחילה ולאחר מכן מומרים לקצב שינוי, ממוצע או אחוזון.
באופן אידיאלי, SLI מודד ישירות את רמת השירות של עניין, אבל לפעמים רק מדד קשור זמין למדידה מכיוון שקשה להשיג או לפרש את המקורי. לדוגמה, זמן חביון בצד הלקוח הוא לרוב מדד מתאים יותר, אך ישנם מקרים שבהם ניתן למדוד את השהייה רק בשרת.
סוג נוסף של SLI שחשוב ל-SREs הוא זמינות, או פרק הזמן שבמהלכו ניתן להשתמש בשירות. לרוב מוגדר כשיעור הבקשות המוצלחות, הנקרא לפעמים תשואה. (משך החיים - הסבירות שהנתונים יישמרו לפרק זמן ממושך - חשובה גם עבור מערכות אחסון נתונים.) למרות ש-100% זמינות אינה אפשרית, זמינות קרובה ל-100% היא לרוב ניתנת להשגה; ערכי זמינות מתבטאים כ מספר ה"תשע" » אחוז הזמינות. לדוגמה, 99% ו-99,999% זמינות עשויות להיות מתויגות כ-"2 תשע" ו-"5 תשע". יעד הזמינות המוצהר הנוכחי של Google Compute Engine הוא "שלוש וחצי תשע" או 99,95%.
מטרות
SLO הוא יעד רמת שירות: ערך יעד או טווח ערכים עבור רמת שירות הנמדדת על ידי ה-SLI. ערך נורמלי עבור SLO הוא "SLI ≤ Target" או "Lower Limit ≤ SLI ≤ Upper Limit". לדוגמה, אנו עשויים להחליט שנחזיר את תוצאות החיפוש של שייקספיר "מהיר" על ידי הגדרת ה-SLO לאחזור ממוצע של שאילתת חיפוש של פחות מ-100 אלפיות השנייה.
בחירת SLO נכון היא תהליך מורכב. ראשית, לא תמיד ניתן לבחור ערך ספציפי. עבור בקשות HTTP נכנסות חיצוניות לשירות שלך, מדד השאילתה לשנייה (QPS) נקבע בעיקר על פי רצונם של המשתמשים שלך לבקר בשירות שלך, ולא תוכל להגדיר SLO עבור זה.
מצד שני, אתה יכול לומר שאתה רוצה שהשהייה הממוצעת לכל בקשה תהיה פחות מ-100 מילישניות. הגדרת מטרה כזו עשויה לאלץ אותך לכתוב את ה-frontend שלך עם חביון נמוך או לקנות ציוד המספק חביון כזה. (100 אלפיות שניות זה כמובן מספר שרירותי, אבל עדיף שיהיו מספרי חביון נמוכים עוד יותר. יש עדויות שמצביעות על כך שמהירות מהירות עדיפה על מהירויות איטיות, ושאיחור בעיבוד בקשות משתמשים מעל ערכים מסוימים למעשה מאלץ אנשים להתרחק מהשירות שלך.)
שוב, זה יותר מעורפל ממה שזה נראה במבט ראשון: לא כדאי לכלול QPS לחלוטין מהחישוב. העובדה היא ש-QPS ו-Latency קשורים מאוד זה לזה: QPS גבוה יותר מוביל לרוב להשהיות גבוהות יותר, ושירותים בדרך כלל חווים ירידה חדה בביצועים כשהם מגיעים לסף עומס מסוים.
בחירה ופרסום של SLO מגדיר את ציפיות המשתמש לגבי אופן הפעולה של השירות. אסטרטגיה זו יכולה להפחית תלונות מופרכות נגד בעל השירות, כגון ביצועים איטיים. ללא SLO מפורש, משתמשים לרוב יוצרים ציפיות משלהם לגבי הביצועים הרצויים, שאולי אין להם שום קשר לדעותיהם של האנשים שמעצבים ומנהלים את השירות. מצב זה עלול להוביל לציפיות מנופחות מהשירות, כאשר משתמשים מאמינים בטעות שהשירות יהיה נגיש יותר ממה שהוא בפועל, ולגרום לחוסר אמון כאשר משתמשים מאמינים שהמערכת פחות אמינה ממה שהיא בפועל.
הסכם
הסכם רמת שירות הוא חוזה מפורש או מרומז עם המשתמשים שלך הכולל את ההשלכות של עמידה (או אי עמידה) ב-SLOs שהם מכילים. ההשלכות מזוהות בצורה הכי קלה כשהן כספיות - הנחה או קנס - אבל הן יכולות ללבוש צורות אחרות. דרך קלה לדבר על ההבדל בין SLOs ו-SLAs היא לשאול "מה קורה אם ה-SLOs לא מתקיימים?" אם אין השלכות ברורות, אתה מסתכל כמעט בוודאות על SLO.
ה-SRE בדרך כלל אינו מעורב ביצירת SLAs מכיוון ש-SLAs קשורים קשר הדוק להחלטות עסקיות ומוצר. ה-SRE, לעומת זאת, מעורב בסיוע למתן את ההשלכות של SLOs כושלים. הם יכולים גם לעזור לקבוע את ה-SLI: ברור שחייבת להיות דרך אובייקטיבית למדוד את ה-SLO בהסכם או שתהיה אי הסכמה.
חיפוש Google הוא דוגמה לשירות חשוב שאין לו SLA ציבורי: אנחנו רוצים שכולם ישתמשו בחיפוש בצורה יעילה ככל האפשר, אבל לא חתמנו על חוזה עם העולם. עם זאת, עדיין יש השלכות אם החיפוש אינו זמין - חוסר זמינות מביא לירידה במוניטין שלנו וכן לירידה בהכנסות מפרסום. לשירותים רבים אחרים של Google, כגון Google for Work, יש הסכמי רמת שירות מפורשים עם משתמשים. לא משנה אם לשירות מסוים יש SLA, חשוב להגדיר את ה-SLI וה-SLO ולהשתמש בהם כדי לנהל את השירות.
כל כך הרבה תיאוריה - עכשיו לחוות.
אינדיקטורים בפועל
בהתחשב בכך שהגענו למסקנה שחשוב לבחור מדדים מתאימים למדידת רמת השירות, איך יודעים כעת אילו מדדים חשובים לשירות או למערכת?
מה אכפת לך ולמשתמשים שלך?
אינך צריך להשתמש בכל מדד כ-SLI שאתה יכול לעקוב אחריו במערכת ניטור; הבנת מה המשתמשים רוצים ממערכת תעזור לך לבחור מספר מדדים. בחירת אינדיקטורים רבים מדי מקשה על התמקדות באינדיקטורים חשובים, בעוד שבחירה במספר קטן עלולה להשאיר חלקים גדולים מהמערכת ללא השגחה. בדרך כלל אנו משתמשים במספר אינדיקטורים מרכזיים כדי להעריך ולהבין את תקינותה של מערכת.
בדרך כלל ניתן לחלק את השירותים למספר חלקים במונחים של SLI הרלוונטיים עבורם:
- מערכות חזית מותאמות אישית, כמו ממשקי החיפוש עבור שירות שייקספיר מהדוגמה שלנו. הם חייבים להיות זמינים, ללא עיכובים ובעלי רוחב פס מספיק. בהתאם, ניתן לשאול שאלות: האם נוכל להיענות לבקשה? כמה זמן לקח להיענות לבקשה? כמה בקשות ניתן לטפל?
- מערכות אחסון. הם מעריכים זמן השהיית תגובה נמוכה, זמינות ועמידות. שאלות קשורות: כמה זמן לוקח לקרוא או לכתוב נתונים? האם נוכל לגשת לנתונים לפי בקשה? האם הנתונים זמינים כשאנחנו צריכים אותם? ראה פרק 26 שלמות נתונים: מה שאתה קורא זה מה שאתה כותב לדיון מפורט בנושאים אלה.
- מערכות ביג דאטה כגון צינורות עיבוד נתונים מסתמכות על תפוקה וזמן עיבוד שאילתות. שאלות קשורות: כמה נתונים מעובדים? כמה זמן לוקח לנתונים לעבור מרגע קבלת הבקשה ועד למתן תגובה? (חלקים מסוימים של המערכת עשויים להיות גם עיכובים בשלבים מסוימים.)
אוסף אינדיקטורים
אינדיקטורים רבים של רמת שירות נאספים באופן הטבעי ביותר בצד השרת, באמצעות מערכת ניטור כגון Borgmon (ראה להלן). ) או Prometheus, או פשוט ניתוח תקופתי של היומנים, זיהוי תגובות HTTP עם סטטוס 500. עם זאת, מערכות מסוימות צריכות להיות מצוידות באיסוף מדדים בצד הלקוח, שכן היעדר ניטור בצד הלקוח יכול להוביל להחמצה של מספר בעיות המשפיעות על משתמשים, אך אינם משפיעים על מדדי צד השרת. לדוגמה, התמקדות בהשהיית התגובה האחורית של אפליקציית בדיקת החיפוש של שייקספיר שלנו עשויה לגרום להשהיה בצד המשתמש עקב בעיות JavaScript: במקרה זה, מדידת כמה זמן לוקח לדפדפן לעבד את הדף היא מדד טוב יותר.
צבירה
למען הפשטות וקלות השימוש, לעתים קרובות אנו צוברים מדידות גולמיות. יש לעשות זאת בזהירות.
חלק מהמדדים נראים פשוטים, כמו בקשות לשנייה, אבל אפילו המדידה הפשוטה הזו, לכאורה, אוספת באופן מרומז נתונים לאורך זמן. האם המדידה מתקבלת באופן ספציפי פעם בשנייה או שממוצע המדידה על פני מספר הבקשות לדקה? האפשרות האחרונה יכולה להסתיר מספר מיידי גבוה בהרבה של בקשות שנמשכות רק כמה שניות. שקול מערכת שמשרתת 200 בקשות בשנייה עם מספרים זוגיים ו-0 בשאר הזמן. קבוע בצורת ערך ממוצע של 100 בקשות לשנייה ופעמיים מהעומס המיידי אינם אותו דבר. באופן דומה, ממוצע של זמן השהייה של שאילתות עשוי להיראות אטרקטיבי, אך הוא מסתיר פרט חשוב: ייתכן שרוב השאילתות יהיו מהירות, אך יהיו הרבה שאילתות איטיות.
רוב האינדיקטורים נתפסים טוב יותר כהפצות ולא ממוצעים. לדוגמה, עבור חביון SLI, חלק מהבקשות יעובדו במהירות, בעוד שחלקן תמיד ייקח יותר זמן, לפעמים הרבה יותר. ממוצע פשוט יכול להסתיר את העיכובים הארוכים האלה. האיור מציג דוגמה: למרות שבקשה טיפוסית לוקח בערך 50 אלפיות השנייה להגשת, 5% מהבקשות איטיות פי 20! ניטור והתראה על סמך זמן חביון ממוצע בלבד אינם מציגים שינויים בהתנהגות לאורך היום, כאשר למעשה ישנם שינויים בולטים בזמן העיבוד של חלק מהבקשות (השורה העליונה).
זמן אחזור של 50, 85, 95 ו-99 אחוזים במערכת. ציר ה-Y הוא בפורמט לוגריתמי.
שימוש באחוזונים לאינדיקטורים מאפשר לראות את צורת ההתפלגות ומאפייניה: רמת אחוזונים גבוהה, כמו 99 או 99,9, מציגה את הערך הגרוע ביותר, בעוד שאחוזון 50 (הידוע גם כחציון) מציג את המצב השכיח ביותר של המדד. ככל שפיזור זמן התגובה גדול יותר, כך בקשות ארוכות טווח ישפיעו על חווית המשתמש. האפקט מוגבר בעומס גבוה ובנוכחות של תורים. מחקר חווית משתמש הראה שאנשים מעדיפים בדרך כלל מערכת איטית יותר עם שונות זמן תגובה גבוהה, כך שחלק צוותי SRE מתמקדים רק בציוני אחוז גבוהים, על בסיס שאם ההתנהגות של מדד באחוזון 99,9 טובה, רוב המשתמשים לא יחוו בעיות .
הערה לגבי טעויות סטטיסטיות
בדרך כלל אנו מעדיפים לעבוד עם אחוזונים ולא עם הממוצע (ממוצע אריתמטי) של קבוצת ערכים. זה מאפשר לנו לשקול ערכים מפוזרים יותר, שלעתים קרובות יש להם מאפיינים שונים (ומעניינים יותר) באופן משמעותי מהממוצע. בשל האופי המלאכותי של מערכות מחשוב, ערכים מטריים מוטים לעתים קרובות, כך שאף בקשה לא יכולה לקבל תגובה בפחות מ-0 אלפיות השנייה, וזמן קצוב של 1000 מילישניות אומר שלא יכולות להיות תגובות מוצלחות עם ערכים גדולים מ- פסק הזמן. כתוצאה מכך, איננו יכולים לקבל שהממוצע והחציון יכולים להיות זהים או קרובים זה לזה!
ללא בדיקה מוקדמת, אלא אם כן מתקיימות הנחות סטנדרטיות וקרובים מסוימים, אנו נזהרים לא להסיק שהנתונים שלנו מופצים באופן נורמלי. אם ההפצה אינה כצפוי, תהליך האוטומציה שמתקן את הבעיה (לדוגמה, כאשר הוא רואה חריגים, הוא מפעיל מחדש את השרת עם זמן אחזור גבוה לעיבוד בקשות) עשוי לעשות זאת לעתים קרובות מדי או לא מספיק (שניהם לא טוב מאוד).
תקן אינדיקטורים
אנו ממליצים לתקן את המאפיינים הכלליים של SLI כך שלא תצטרכו להעלות השערות לגביהם בכל פעם. כל תכונה שעונה על דפוסים סטנדרטיים עשויה להיות חריגה מהמפרט של SLI בודד, למשל:
- מרווחי צבירה: "בממוצע מעל דקה אחת"
- אזורי צבירה: "כל המשימות באשכול"
- באיזו תדירות נלקחות מדידות: "כל 10 שניות"
- אילו בקשות כלולות: "HTTP GET מעבודות ניטור קופסה שחורה"
- איך מתקבלים הנתונים: "תודות לניטור שלנו שנמדד בשרת"
- זמן אחזור של גישה לנתונים: "זמן עד בית אחרון"
כדי לחסוך במאמץ, צור קבוצה של תבניות SLI הניתנות לשימוש חוזר עבור כל מדד משותף; הם גם מקלים על כולם להבין מה המשמעות של SLI מסוים.
מטרות בפועל
התחל במחשבה (או גלה!) מה אכפת למשתמשים שלך, לא מה אתה יכול למדוד. לעתים קרובות מה אכפת למשתמשים שלך קשה או בלתי אפשרי למדוד, אז בסופו של דבר אתה מתקרב לצרכים שלהם. עם זאת, אם רק תתחיל עם מה שקל למדוד, תגמור עם SLOs פחות שימושיים. כתוצאה מכך, גילינו לעיתים שזיהוי תחילה של יעדים רצויים ולאחר מכן עבודה עם מדדים ספציפיים עובד טוב יותר מאשר בחירת אינדיקטורים ולאחר מכן השגת היעדים.
הגדירו מטרות
לבהירות מירבית, יש להגדיר כיצד נמדדים SLOs והתנאים שבהם הם תקפים. לדוגמה, נוכל לומר את הדברים הבאים (השורה השנייה זהה לראשונה, אך משתמשת בברירות המחדל של SLI):
- 99% (בממוצע מעל דקה אחת) מקריאות Get RPC יסתיימו תוך פחות מ-1ms (נמדד בכל שרתי הקצה האחורי).
- 99% מהשיחות לקבל RPC יסתיימו תוך פחות מ-100 אלפיות השנייה.
אם צורת עקומות הביצועים חשובה, אתה יכול לציין מספר SLOs:
- 90% מהשיחות קבל RPC שהושלמו תוך פחות משנייה אחת.
- 99% מהשיחות קבל RPC שהושלמו תוך פחות משנייה אחת.
- 99.9% מהשיחות קבל RPC שהושלמו תוך פחות משנייה אחת.
אם המשתמשים שלך מייצרים עומסי עבודה הטרוגניים: עיבוד בתפזורת (שעבורו חשובה התפוקה) ועיבוד אינטראקטיבי (שעבורם חביון חשוב), ייתכן שכדאי להגדיר יעדים נפרדים עבור כל מחלקת עומס:
- 95% מבקשות הלקוחות דורשות תפוקה. הגדר את ספירת קריאות ה-RPC שבוצעו <1 שניות.
- ל-99% מהלקוחות אכפת מהשהייה. הגדר את ספירת שיחות ה-RPC עם תעבורה <1 KB ופועלת <10 אלפיות השנייה.
זה לא מציאותי ולא רצוי להתעקש ש-SLOs יתקיימו ב-100% מהזמן: זה יכול להפחית את קצב הצגת הפונקציונליות והפריסה החדשה, ולדרוש פתרונות יקרים. במקום זאת, עדיף לאפשר תקציב שגיאה - אחוז השבתת המערכת המותרת - ולנטר ערך זה מדי יום או שבועי. ההנהלה הבכירה עשויה לרצות הערכות חודשיות או רבעוניות. (תקציב השגיאה הוא פשוט SLO להשוואה עם SLO אחר.)
ניתן להשוות את אחוז הפרות SLO לתקציב השגיאה (ראה פרק 3 וסעיף ), כאשר ערך ההפרש משמש כקלט לתהליך שמחליט מתי לפרוס מהדורות חדשות.
בחירת ערכי יעד
בחירת ערכי תכנון (SLOs) אינה פעילות טכנית גרידא בגלל האינטרסים של המוצר והעסק שחייבים לבוא לידי ביטוי ב-SLIs, SLOs (ואולי SLAs). כמו כן, ייתכן שיהיה צורך להחליף מידע בנוגע לנושאים הקשורים לצוות עובדים, זמן הגעה לשוק, זמינות ציוד ומימון. SRE צריך להיות חלק מהשיחה הזו ולעזור להבין את הסיכונים והכדאיות של אפשרויות שונות. הבאנו כמה שאלות שעשויות לעזור להבטיח דיון פרודוקטיבי יותר:
אל תבחר יעד על סמך הביצועים הנוכחיים.
בעוד שהבנת החוזקות והגבולות של מערכת חשובה, התאמת מדדים ללא נימוקים יכולה לחסום אותך מלתחזק את המערכת: זה ידרוש מאמצים הרואיים כדי להשיג מטרות שלא ניתן להשיג ללא עיצוב מחדש משמעותי.
היה פשוט
חישובי SLI מורכבים יכולים להסתיר שינויים בביצועי המערכת ולהקשות על מציאת הגורם לבעיה.
הימנע ממוחלטים
למרות שזה מפתה להחזיק מערכת שיכולה להתמודד עם עומס גדל ללא הגבלת זמן מבלי להגדיל את השהיה, דרישה זו אינה מציאותית. מערכת שמתקרבת לאידיאלים כאלה כנראה תדרוש זמן רב לתכנון ובנייה, תהיה יקרה לתפעול ותהיה טובה מדי לציפיות של משתמשים שיעשו משהו פחות.
השתמש בכמה שפחות SLOs
בחר מספר מספיק של SLOs כדי להבטיח כיסוי טוב של תכונות המערכת. הגן על SLOs שאתה בוחר: אם לעולם לא תוכל לנצח ויכוח על סדרי עדיפויות על ידי ציון SLO ספציפי, כנראה שלא כדאי לשקול את ה-SLO הזה. עם זאת, לא כל תכונות המערכת ניתנות ל-SLOs: קשה לחשב את רמת ההנאה של המשתמש באמצעות SLOs.
אל תרדוף אחרי שלמות
אתה תמיד יכול לחדד את ההגדרות והיעדים של SLOs לאורך זמן ככל שאתה לומד יותר על התנהגות המערכת תחת עומס. עדיף להתחיל עם מטרה צפה שתחדד עם הזמן מאשר לבחור מטרה קפדנית מדי שיש להרגיע אותה כאשר אתה מוצא שהיא בלתי ניתנת להשגה.
SLOs יכולים וצריכים להיות מניע מרכזי בתעדוף עבודה עבור SREs ומפתחי מוצר מכיוון שהם משקפים דאגה למשתמשים. SLO טוב הוא כלי אכיפה שימושי עבור צוות פיתוח. אבל SLO מעוצב בצורה גרועה יכול להוביל לעבודה בזבזנית אם הצוות עושה מאמצים הרואיים להשיג SLO אגרסיבי מדי, או מוצר גרוע אם ה-SLO נמוך מדי. SLO הוא מנוף חזק, השתמש בו בחוכמה.
שליטה במידות שלך
SLI ו-SLO הם מרכיבי מפתח המשמשים לניהול מערכות:
- ניטור ומדידה של מערכות SLI.
- השווה SLI ל-SLO והחליט אם יש צורך בפעולה.
- אם נדרשת פעולה, הבינו מה צריך לקרות כדי להשיג את המטרה.
- השלם פעולה זו.
לדוגמה, אם שלב 2 מראה שהבקשה מתפוגגת ותפרק את ה-SLO תוך מספר שעות אם לא נעשה דבר, שלב 3 עשוי לכלול בדיקת ההשערה שהשרתים קשורים ל-CPU והוספת שרתים נוספים תפזר את העומס. ללא SLO, לא היית יודע אם (או מתי) לנקוט בפעולה.
הגדר SLO - אז יוגדרו ציפיות המשתמש
פרסום SLO מגדיר את ציפיות המשתמש להתנהגות המערכת. משתמשים (ומשתמשים פוטנציאליים) רוצים לרוב לדעת למה לצפות משירות כדי להבין אם הוא מתאים לשימוש. לדוגמה, אנשים המעוניינים להשתמש באתר שיתוף תמונות עשויים לרצות להימנע משימוש בשירות המבטיח אריכות ימים ועלות נמוכה בתמורה למעט פחות זמינות, למרות שאותו שירות עשוי להיות אידיאלי עבור מערכת ניהול רשומות ארכיון.
כדי להגדיר ציפיות ריאליות למשתמשים שלך, השתמש באחת מהטקטיקות הבאות או בשתיהן:
- שמור על מרווח בטיחות. השתמש ב-SLO פנימי מחמיר יותר ממה שמפורסם למשתמשים. זה ייתן לך הזדמנות להגיב לבעיות לפני שהן נראות לעין חיצונית. מאגר SLO גם מאפשר לך לקבל מרווח בטיחות בעת התקנת מהדורות המשפיעות על ביצועי המערכת ומבטיחות שקל לתחזק את המערכת מבלי שתצטרך לתסכל משתמשים בזמן השבתה.
- אל תחרוג מציפיות המשתמש. המשתמשים מבוססים על מה שאתה מציע, לא על מה שאתה אומר. אם הביצועים בפועל של השירות שלך טובים בהרבה מה-SLO המוצהר, המשתמשים יסתמכו על הביצועים הנוכחיים. אתה יכול למנוע תלות יתר על ידי כיבוי מכוון של המערכת או הגבלת ביצועים בעומסים קלים.
הבנה עד כמה מערכת עומדת בציפיות עוזרת להחליט אם להשקיע בהאצת המערכת והפיכתה לנגישה וגמישה יותר. לחלופין, אם שירות מתפקד טוב מדי, יש להקדיש זמן מהצוות לסדרי עדיפויות אחרים, כגון תשלום חובות טכניים, הוספת תכונות חדשות או הצגת מוצרים חדשים.
הסכמים בפועל
יצירת SLA מחייבת צוותים עסקיים ומשפטיים להגדיר את ההשלכות והעונשים על הפרתו. תפקיד ה-SRE הוא לעזור להם להבין את האתגרים הסבירים בעמידה ב-SLOs הכלולים ב-SLA. רוב ההמלצות ליצירת SLOs חלות גם על SLAs. זה חכם להיות שמרני במה שאתה מבטיח למשתמשים מכיוון שככל שיש לך יותר, כך קשה יותר לשנות או להסיר SLA שנראים לא הגיוניים או שקשה לעמוד בהם.
תודה שקראת את התרגום עד הסוף. הירשם לערוץ הטלגרם שלי בנושא ניטור и .
מקור: www.habr.com