SLO/SLA ו ־ Metrics

SLO/SLA ומדדים

1) מונחים והיררכיה

(SLI (Service Level Indicator - מחוון מדיד ”כפי שהמשתמש רואה אותנו”: החלק של בקשות מוצלחות, p95 Latency, רעננות של נתונים, הנתח של חבורות מעובדות בהצלחה וכו '.

(SLO (Service Level Objective - ערך המטרה SLI במרווח התצפית (28/30/90 ימים. דוגמה: "99. 9% מהבקשות/תשלום בסוף 400 ms"

תקציב שגיאה - 1 -SLO. ב-SLO 99. 9% תקצוב שגיאה = 0. אחוז אחד של זמן/בקשות.
רמת שירות משמעותית מבחינה משפטית: כולל SLO, מדידות, חריגים, פיצויים/קנסות.

2) עקרונות עיצוב

תסמינים> מדדים פנימיים. SLIs צריכים לשקף את חוויית המשתמש בפועל.
מספר קטן של מפתחות. לשירות - 2-5 עיקרי: הצלחה, איחור, תפאורה/רעננות, תקינות.
כיסוי של מסלולים קריטיים. לכל תרחיש עסקי (checkout, login, webhook, ETL load) יש מערכת משלו של SLI/SLO.
סמנטיקה ”הצלחה” קפדנית. לא ”קוד 200”, אלא ”המשתמש קיבל תגובה בזמן והתוצאה תקפה”.
הפרדה של סל "ד חיצוני ופנימי. פנימי - מחמיר יותר; SLA חיצוני רישום 1-2 תשיעיות נמוך יותר.

3) קטלוג SLI (התייחסות)

3. 1 API/שירותים מקוונים

הצלחה: 'SLI _ הצלחה = 1 - (5xx + timeout + business_error )/ all_requests'

Latency: p95/p99 ”http _ server _ turation _ seconds” by route/method/terenant

רוחב פס: RPS/גבולות/מכסות

תקינות: פרופורציה של תגובות תקפות (חתימות, סכמות, אינווריאנטים)

3. 2 חוברות אינטרנט/משלוחים אסינכרונים

משלוח: פרופורציה של אירועים שאושרו בשניות ו-N מגשים

לקוחות: אחוז המנויים ללא עיכוב ארוך (לכל דייר)

3. 3 נתונים/ETL/DWH

רעננות: "עכשיו last_successful_ingest_ts'

שלמות: "בלע _ שורות/ expected_rows'

תקינות: הפרופורציה של רשומות שעברו בדיקות איכות

צינורות: חלק מהעבודות הושלמו לפני המועד האחרון

3. 4 SDKs נייד/לקוח

הצלחה לקוח: פרופורציה של פגישות ללא שגיאות קטלניות

הלוך חזור: p95 מהבקשה לבצע

להיטי מטמון: אחוז מוגש ממטמון (כסימפטום של ביצועים)

4) נוסחאות ודוגמאות למטרות

• ”SLI _ req _ avail = 1 - (failed_requests/ total_requests)”
• 'SLO _ req _ avail = 99. 95% עבור 30 יום תקצוב שגיאה = 0. 05% מהבקשות.

• Uptime = (obs_window והשבתה )/ obs_window'

• 'SLO _ latency = p95 (מסלול = ”/pay ”) 400 ms על פרוסות 7 ימים, לא כולל חימום מטמון (1%)

• 'SLO _ רעננות (dataset = ”פקודות”) 10 min' p99 ב- 24 שעות.

5) תקצוב שגיאות ושינוי ניהול

תקציב (B): ”B = 1 - SLO”.
צריבה - היחס בין שגיאות אמיתיות לשגיאות ניתנות להשגה.

• (Overspend (burn> 1). # הקפאת תכונה, התמקדות במהימנות.
• בקצב צריבה> x בחלון קצר - אירוע וכובע. אמצעים.
• תכנון: החלק המהימן של הספרינט תואם לכוויות בתקופה האחרונה.

6) התראה: קצב צריבה וכללים רב חלונות

הרעיון: אנחנו תופסים דליפות מהירות וסחף איטי.

• קריטי: ”2% תקציב בשעה 1” (אש מהירה).
• אזהרה: ”5% מהתקציב ב-6 שעות”.

• חלון זמן קצר לתקריות מהירות.
• חלון זמן ארוך (6-24 שעות) למגמות.
• Latency: התראה על ידי p99> סף 5 min, עם דיכוי של נפנוף ותקשורת עם עקבות מקרים.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) רב-דייר וקטע

SLI/SLO נספרים על פי דיירים/תוכניות/אזורים, אחרת החציוני ”יכסה” את הכישלונות.
מספר מינימלי של אירועים בעלי משמעות סטטיסטית (מעקות שמירה).
SLA יכול להשתנות בתעריפים (לדוגמה, Pro 99. 9%, חינם 99. 5%»).

8) התרועעות עם יכולת תצפית ועקבות

מ-SLMetrics - מ-histograms/conters עם מופת = = מעבר לשבילים ”רעים”.
יומנים הם המקור לסיבות: פסקי זמן, קודי שגיאה עסקיים, גבולות.
למידע - קישור לשושלת: ”איזו עבודה עיכבה את שיטת הטריות”.

9) חוזים ותאונות SLAName

• שיטת מדידה של SLI/הגדרות חלונות.
• יוצאים מן הכלל (עבודה מתוכננת, כוח עליון).
• נוהל תקרית ותקשורת (עמוד מצב, RFO/RCA).
• זיכוי שירות והזמנת בקשה.
• תחום שיפוט, תקופת תוקף, תנאי תיקון.

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

10) עלות ותעדוף

המחיר של תשיעיות לא גדל בצורה לינארית. «99. 9% → 99. 99%" = שיעור ארכיטקטורה שונה (N + 1, רב-אזורי, נכס לנכס).
שים SLOs על פעולות המשתמש היקרות ביותר.
בקרת עלויות הטלמטריה - ירידה במחירים, מכסות, העתק ואחסון לפי רמה.

11) נהלים ודיווח

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

12) תבניות (להתחלה מהירה)

12. 1 כרטיס SLO (דוגמה)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 שולחן בגרות SLO

13) דוגמאות של כללים (קטעים)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO עבור נתונים ו ML (תכונות)

SLOs נתונים מקצה לקצה: רעננות p99, שלמות p99, זמן ”התאוששות” לאחר ההתרסקות.
חוזי נתונים: תוכניות צפויות, כרכים, מועדים; תקרית הפרת נתונים.
ML: SLO עבור הסקת מסקנות, SLA עבור זמינות סטור תכונה, ניטור סחף (איכות מודל היא נושא נפרד, מחוץ ל-SLA).

15) שילוב עם ביטחון ופרטיות

לוגי SLI ללא PII/סודות; tochenization/masking.
הביקורת משתנה ל ־ SLO/SLAs ומדווחת על פרסומים ביומנים בלתי ניתנים לשינוי.
עבור מסלולים רגולטוריים (תשלומים/PII) - SLOs נפרדים, מתוחים יותר.

16) רשימות בדיקה

לפני תחילת השירות/תכונות

[ ] Latency/Laterput/Treeness SLIs.

[ ] SLO וחלונות מוגדרים; תקציב שגיאה מחושב.

[ ] הכינו התראות בקצב צריבה (קצר + ארוך).

[ ] Dashbards RED + exemplars = מסלולים; חשבונות תקריות.

[ ] מקטעים רב-שכירים וסף משמעות.

[ ] פיצ 'פריז ונוהל דיווח.

מבצע

[ ] דו "ח שבועי של SLO/Burn, תוכניות מתקשות.

[ ] להעריך מחדש את SLO כאשר הארכיטקטורה/טעינה משתנה.

[ תקופתית ] ”תקדימי תקדימי” ועדכוני ריצה.

[ עלויות טלמטריה מוניטור ] וספירת SLI.

17) Runbook 'edition

רנבוק: צמיחה מהירה p99/שלם

1. התראה p99> סף * פתח לוח מחוונים * עבור דרך מופת לאתר.
2. מצא מרווח צר של CLIENT/SERVER, השווה אזורים/גרסאות.
3. אפשר הידרדרות (cache/limit/falback), הודע על פקודת התלות.
4. לאחר הייצוב - RCA, משימות אופטימיזציה, עדכון מדידות SLO.

ספר הדרכות: הוצאה תקציבית> 50% לשבוע

1. הקפאת תכונות, להעלות עדיפות אמינות.
2. התקבצות של טעויות: על ידי מסלולים/דיירים/תלויות.
3. Roll החוצה תיקונים = לאשר התאוששות מגמה.
4. רטרוספקטיבה והתראה/התאמת סף.

18) FAQ

קיו: כמה סלו אתה צריך?
A: מינימום על תרחישי משתמש קריטיים: הצלחה + latency. כל השאר הוא מתוך הכרח.

קיו: איזו זמינות טובה יותר לפי זמן או לפי בקשה? ‏

א ": לפי דרישה - יותר מטרי משתמש. הזמן נוח לרכיבי רשת/אינפרה.

ש: למה פי-95, לא ממוצע?
א ': האמצעי מסתיר את הזנב; המשתמש מרגיש p95/p99.

קיו: איך לא ”להדק את הברגים” יותר מדי?
א. התחל עם מטרות מציאותיות (נתונים היסטוריים), אחר כך הידק ככל שאתה מתבגר.

• ”יכולת תצפית: יומנים, מדדים, עקבות”
• ‏ ”עקבות מבוזרות” ‏
• ”ביקורת ויומנים בלתי ניתנים לשינוי”
• ‏ ”ערובות למשלוחים” ‏
• ”בהצפנת מעבר/במנוחה”
• ”מקור נתונים (לינאז ')”