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

1) מדוע תקציב SLO וטעות

(SLO (Service Level Objective - רמת איכות המטרה נתפסת על ידי המשתמש; מדד SLI; תקצוב שגיאה - סבלנות לסטיות בכל חלון (בדרך כלל 30/90 ימים).
תקציב השגיאה הופך מהימנות מ ”הפשטה” למשאב מנוהל: כאשר התקציב נשרף במהירות, אנו מקפיאים תכונות וצ 'ינים; כאשר התקציב בריא - אתה יכול להאיץ את שחרור.

2 מה שנחשב כ ”טוב”

קריטריון: ”מוצלח מנקודת המבט של המשתמש”.

2. סלים קלאסי 1

זמינות היא אחוז הבקשות המוצלחות (למעט אלה שבוטלו על ידי הלקוח).
הצלחה = http_status 2xx, 3xx, 404 'ושום פסק זמן' (404 יכול להיחשב כהצלחת API אם הוא צפוי סמנטיקה).
Latency: יחס הבקשות מהיר יותר מהסף (לדוגמה, p95 300 ms).
'good _ latency = duration_ms stalled 300'.
רעננות/סטלינס: ”נתונים לא ישנים מ-X דקות” (מטמון, ספריות, מקדמים).
איכות: תקינות התוצאה (העברת מאשרים עסקיים/אינווריאנטים אחוריים).

2. 2 גבולות ומקטעים

יש לספור פרוסות חשובות: ”מסלול”, ”דייר/מותג”, ”אזור/תחום שיפוט”, ”תשלום _ ספק”. אז אתה לא ”להכפיש” את הכישלון של ידית קריטית אחת בכל המערכת.

3) נוסחאות ותקציב

3. 1 מבוסס בקשה (מועדף על API)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 זמן מבוסס (לשירותי רקע/זרימה)

SLO_uptime = good_minutes / total_minutes

3. 3 דוגמה ליעדים

כללי API: 99. 9% זמינות תוך 30 יום = 0. 1%.
עטי תשלום קריטיים: 99. 95%; קטלוגים/חיפוש: 99. 5%.
Latency: p95 בלום 300 ms ב- '/v1/תשלומים ', p99 ms 800.

4) מכשירים SLI

4. 1 עקרונות

Logs/trails = RED (Rate/Errons/Duration) metrics עם דליים מפורשים.
אל תשכח לשים ”דייר”, ”אזור”, ”מסלול _ מחלקה” (ללא PII).
ספור שני מדדים: ”הצלחה” ו ”סך הכל”, ובשביל איחור, ”מהיר” ו ”בסך הכל”.

4. 2 דוגמא של פרומתאוס (קצב ל ־ 5 מטר)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) התראות על ידי קצב צריבה (רב-חלון, רב-צריבה)

5. רעיון 1

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

5. 2 פרופילי סף (עבור SLO 99. 9%)

קריאה: שרפה בקצב 14. 4 × (10% מהתקציב לשעה 1 ו-5% לשעות 6).
כרטיס: קצב צריבה (6 × (2% ב-6 שעות ו-1% ב-24 שעות).

5. 3 כללי דוגמה (פרומתאוס, פסאודו)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

באופן דומה לכרטיס 6h/24h.

6) משרד התקציב: תהליכים

6. 1 שערי שחרור

אם יתרת התקציב היא <25% והמגמה שלילית - ”הקפאת קוד” על תכונות, העדיפות היא SRE/יציבות.
שחרור הקנריים חייב להיות פרוסת SLO נפרדת ('פריסה. סביבה =” קנרית”).

6. 2 עדיפות לצבר

הפץ יכולת פקודה בפרופורציה לשיעור בעירה ופגיעה בהכנסות.
להצדיק חוב טכני עם מדדים: ”תיקון X יפחית את שיעור השרפה ב Y%”.

6. 3 לאחר התקרית

כל תקרית - RCA ו ”תיקון שלא ניתן לגלגל חזרה” (ניתן לתפעול), השליטה ”חזרה ל ־ SLO”.

7) SLO כקוד

7. 1 SLO מציג דוגמה (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. דור חוק 2

השתמש במחוללים (slo-generator, pyrra, seloth) כדי ליצור אוטומטית כללים, לוחות מחוונים ודיווחים.

8) השפלה והגנה

טעינה: לתת תשובות מהירות ללא תלויות ”יקרות” בשיא.
מטמון & שפל: ”מעופש בזמן-חידוש” Teache 'sa backed read.
גבולות קצב/קונקורנסי: מגן על אחוריים; מסלולים חשובים - עדיפות.
מעגל/זמן: פסקי זמן מהירים וענפי ”נפילה”.
דגלי תכונה: ביטול תכונות כבדות עם כפתור אחד.

9) יכולת תצפית עבור SLO

לוחות מחוונים: SLO בפועל נגד מטרה, איזון תקציב, שיעור צריבה, תרומה על ידי מסלולים/ספקים.
קורלציה: מ ”חור” של SLO _ to examplar _ a עקבות מסויימות של לוגים/פרופילים.
דיווחים: מגמות שבועיות, צריכת תקציב, סיבות מובילות להשפלה.

10) תרופות אנטי ־ פטריות

אחד ”גלובלי” SLO עבור כל המסכות. קטע.
«99. 99% על כל דבר" לא כולל עלות ומציאות. בחר מטרות מניסיון המשתמש.
התראות מעבד/ערימה במקום קצב צריבה/SLO.
מתעלם מ-4xx/הפניות ארוכות שמקלקלות את UX.
חלון אטום (מתגלגל נגד לוח שנה) - השוואות של ”תפוחים עם תפוזים”.

11) פרטים של iGaming/Finance

נתיבי כסף (פיקדונות/משיכות): SLOS אישי מעל הרמה הכללית (למשל. 99. זמינות של 95%; p95 בלום 250 ms).
ספקי PSP/KYC: SLO לכל ספק + מתריע על תרומתם לשריפה; החלפת מסלול אוטומטית (ניתוב חכם).
תחום שיפוט/דיירים: SLOs ותקציבים על ידי 'אזור/תחום שיפוט/מותג' כך שבעיה מקומית לא ”מציפה” את המטרי הגלובלי.
משחק אחראי: SLO לתקופת היישום של הגבלות/הרחקה עצמית (תאימות-נוסחאות).
ביקורת/רגולטורית: לשמור SLO ודוחות אירוע; שקיפות לביקורת פנימית.

12) רשימת מוכנות למומחים

[ ] SLIS (זמינות/latency/איכות/רעננות) וקטעים (מסלול/דייר/אזור) מוגדרים.

[ מטרות ] (SLOs) מציאותיות, קשורות לעסקים; יש חלונות מתגלגלים 30/90 ימים.

[ ] התראות לפי קצב צריבה עם חלונות מרובים (paging/ticket).

[ ] SLO כקוד (כלל/מחולל לוח מחוונים); דוחות תקציב.

[ שערי שחרור ] קשורים לשאר התקציב; קטעים קנריים.

[ ] מנגנוני הידרדרות (shedder, pache spale, circle, limits) מיושמים ונבדקים.

[ ] Metrics ↔ שבילים קורלציה, ריצות ברורות.

[ ] נתיבים פיננסיים/שיפוטיים - התראות SLOs/נפרדות; PSP/KYC אינם משובצים.

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

13) TL; DR

הגדרת SLIs לפי ערך המשתמש, הגדרת SLOs מציאותית, וניהול באמצעות תקציב שגיאה וקצב צריבה עם חלונות מרובים. אפשר SLO-as-code, לשחרר שערים ולהשפיל כמתוכנן. קטע אחר מסלול/דייר/אזור; עבור נתיבי כסף לשמור על מטרות הדוקות יותר והתראות נפרדות.