ניטור SLA ו ־ SLO

1) מונחים ותפקידים

(SLA (Service Level Agreement - התחייבות חוזית חיצונית ללקוח (סעיפי עונשין, נקודות זכות).
(SLO (Service Level Objective - כוונו לרמת השירות הפנימי התומכת בביצוע SLA.
(SLI (Service Level Indicator - אינדיקטור מדוד, שעל בסיסו מוערכים SLO/SLA.
תקצוב שגיאה - האחוז המותר של ”שגיאות/לא זמינות” לתקופה: ”תקציב = 1 -SLO”.
היקף: נמדד על ידי עיני המשתמש (מקצה לקצה). במיקרו-רווחים, הן ברמת הרכיב והן ברמת המסלול מקצה לקצה.

2) בחירת SLI: מה בדיוק למדוד

הקריטריון הוא מתאם עם ניסיון משתמש וערך עסקי.

• זמינות: אחוז הבקשות המוצלחות. 'SLI = מוצלח/כל'.
• Latency: פרופורציית הבקשות מהירה יותר מהסף T. 'SLI = P (latency light T).
• איכות: פרופורציה של תשובות נכונות (ללא 5xx/פונקציות. שגיאות).
• נתונים עדכניים - איחור שכפול/ETL/X דקות.
• ביצועי תהליך עסקי: נתח של תשלומים/רישומים מוצלחים.

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

3) נוסחאות וחלונות תצפית

• זמינות = (OK_requests/ All_requests) × 100%.

• P95 Plight T. = = = ”SLI =% מהבקשות של T”.
• דוגמה: "99% משאלות החיפוש נמצאו 300 מ" מ ב-28 ימים ".
• חלון הזזה: 28 או 30 יום (איזון של רגישות ויציבות). לאירועים - חלונות נוספים: 1 h, 6 h, 24 h.

4) שגיאה בתקציב ושינוי קצב הבקרה

חישוב: ב-SLO = 99. 9% 'תקציב =' 0. 1% שגיאות/אי זמינות לתקופה.

מדיניות

תקציב> 50%: משחררים ומתכננים ניסויים.
תקציב 10-50%: רק שחרור בסיכון נמוך, הידוק קנריות.
תקציב <10%: הקפאת שחרור, סיבה שורשית, שיפורים אמינים.
חיבור עם שחרור פרוגרסיבי: canary/feature-flags ”לאכול” את התקציב במינונים, עם אוטומטי-rollback תחת השפלה.

5) התריע פוליטיקאים: מסף לקצב צריבה

למה לא ”דאופאל SLO - להעלות כוננות”: מאוחר מדי. צריך פרואקטיביות.

• ”Br = (נצפתה שגיאה בחלון קצר/איפשרה שגיאה בחלון זה)”.
• אם BR> 1 - התקציב נצרך מהר יותר מהרגיל.

• התראה מהירה (רעש הוא רגיש, תופס אסונות): חלון 5-10 דקות, סף BR 14-20 ×.
• התראה איטית (תופס זחילה הידרדרות): חלון 1-6 שעות, סף BR 2-4 ×.
• לשלב תנאים: מהר או איטי עבד - קריאה בכוננות.
• רמות: זימונית עבור SLOs המשתמש, כרטיסים/הודעות עבור השפלה אפורה של SLIs פנימיים.

6) יכולת התבוננות ומקורות אמת

יומנים - אבחנה של סיבות.
Metrics - numerical SLIs (הצלחה/שגיאה, אחוזי איחור, שברים, דלפקים).
שבילים - דרך נתיבים, מיקום מקטעים ”חמים”.
דגימות סינתטיות פעילות מהפריפריה (אזור מודע).
אירועים אמיתיים - טלמטריה רום/לקוח, מדדים עסקיים (המרה, תשלומים מוצלחים).

דרישות: תמונה בודדת בלוחות מחוונים של שחרורים ואירועים, הערות ”גרסה/כנרית/דגל”.

7) עיצוב SLO: תבנית צעד אחר צעד

1. תאר את המסלול הקריטי (לדוגמה, ”הפקדה בכרטיס”).
2. הגדר SLI: הצלחה/שגיאה, סף איחור, שלמות.
3. מסכים SLO: יעד של 28 ימים + יוצאים מן הכלל (חלונות מתוכננים).
4. קישור ל-SLA: חובה משפטית ≦ SLO בפועל.
5. להקצות בעל שירות, RACI וערוץ התראה.
6. הגדר מדיניות התראה (שני חלונות BR) וגלגולים אוטומטיים.
7. דיווח יישומי: ביקורות תקציב שבועיות, ביקורות לאחר תקרית.
8. Review SLOS רבעון (שינוי בארכיטקטורה/עומס).

8) דוגמאות SLO (תבניות)

• זמינות: 99. 95% (28d, לא כולל חלונות שהוכרזו 30 דקות בחודש).
• Latency: "'IM 99%' תגובות '400 mS'.
• הצלחה במבצעים עסקיים: 98. 5% 'אישור מוצלח (מסנני הונאה נלקחים בחשבון).

• Latency: ”IM 99% 'בקשות' name 300 ms”.
• רלוונטיות מטמון: '5 min' lag 99% מהזמן.

• משלוח: 99. 9% עבור '60' (מקצה לקצה, עם רטראס).
• הפסד: 0. 01% 'הודעות (idempotency/dauplication מופעל).

9) רב-אזורי ורב-דייר

SLO "על ידי קוהורט": מדינה, ספק תשלום, פלח אח "מים, מכשיר.
SLOS מקומי בקצה: מדדים מהנקודות הקרובות ביותר למשתמש (Edge/PoP).
צבירה: סה "כ SLO לא צריך להסתיר כשלונות על פני קבוצות חשובות.
נתיבי החלפה אוטומטיים ברמת השער של SLO.

10) לוחות מחוונים ודיווח

שחררו לוח מחוונים: גרסה, קנרית (% תנועה), SLI (הצלחה/latency), BR, אנוטציות דגל.
לוח מחוונים תפעולי: לשרוף-למטה תקציב ביום, תקריות צמרת, MTTR, קוהורטות בעיה.
דו "חות שבועיים: איזון תקציבי, מגמות יחסי ציבור, חוב טכני (צווארי בקבוק), תוכנית שיפור.

11) תהליכים: תקריות, פניות ושיפורים

ניהול אירוע: התראה = BR assession _ scale of canaries/flags # rollback/tyle.
RCA (גורם שורש): עובדות/צירי זמן/היפותזות/תיקונים/בדיקת אפקט על ידי SLI.
לקחים נלמדים: אי ענישה לאחר המוות, פריטי פעולה חובה עם בעלים ותאריכי יעד.
סגירת מעגל לולאה: שינויים בבדיקות, דגלי תכונה, גבולות, מגשים, מכסות.

12) ציות וביקורת חשבונות

SLO/SLI כחפצי בקרה (מדיניות-כקוד, יומנים בלתי ניתנים לשינוי).
קישור לדרישות (למשל, זמינות של עסקאות תשלום).
דקות התראה, דוחות תקציב, יומני שחרור/רולבק.

13) טעויות תכופות וכיצד להימנע מהן

“99. 99% או מוות". מטרות בלתי ניתנות להשגה. בחר בתפקידים מציאותיים.
ממוצעים גלובליים מסתירים טבילות מקומיות.
Metrics not e2e: high SLOS במהלך הידרדרות בפועל של הלקוח * הוסף RUM/סינתטי.
התראות על מפסק מספר אחד לקצב צריבה של שני חלונות.
אין קישור לשינויים * שחרורים אינם מובנים, אין אוטומטית-rollback.

14) מיני רשימת מימושים

[ ] מסלולים קריטיים ו-SLO שלהם מתוארים.

[ ] חלון ניטור והרחקה מוגדר.

[ ] התראות BR שתי חלונות (מהיר ואיטי) מוגדרות.

[ ] לוחות מחוונים של שחרורים ופעולות עם הערות של גרסאות/דגלים.

[ ] מדיניות תקציב השגיאות משפיעה על שחרור.

[ ] סקירות תקציב רגילות וסריקות לאחר התקרית.

[ ] תיעוד ובעלי כרטיסי ניקוד.

15) דוגמה לחישוב (פרטים)

זמינות API SLO: 99. 9% ב -28 ימים תקצוב = 0. 1%.
במשך 7 ימים הצטברו 0. 06% מהטעויות * השתמשו ב-60% מהתקציב השבועי.
בחלון קצר של 15 דקות, 2% מהשגיאות נצפות. תקף על חלון זה הוא '0. 1% × (15 דקות/40320 דקות) ו-0. 000037%`.
Burn Rate ≫ 1 (עשרות ×) = איתורית מהירה מופעלת, הקנרית מתגלגלת חזרה ל-1%, הדגל המשפיל-תשלומים-UX מופעל, RCA מתחיל.

16) השורה התחתונה

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