SLA, SLO ו-KPI אמינות

1) תנאים והבדלים

(SLI (Service Level Indicator - אינדיקטור מדיד לאיכות (לדוגמה, הפרופורציה של בקשות מוצלחות, p95 latency).
(SLO (Service Level Objective - ערך מטרה SLI לכל חלון זמן (לדוגמה, "הצלחה בין 99. 9% ב-28 ימים".
תקצוב שגיאה - שיעור אי ספיקת ה ־ SLO המותר הוא '1 -SLO'.
SLA (הסכם רמת שירות) - התחייבויות חוזיות עם קנסות/קרדיטים (חיצוניים).
MTTD/MTTR/MTBF).

2) כיצד לבחור ב ־ SLI (המבוסס על אותות הזהב) ‏

1. Latency - p95/p99 עבור נקודות קצה מפתח.
2. תנועה - זרימת RPS/RPM/הודעה.
3. שגיאות - הנתח של שגיאות 5xx/business (לדוגמה, לא כולל תשלום "ירידה עקב אשמת PSP).
4. רוויה - רווית משאבים (CPU/RAM/IO/lag).

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

3) נוסחאות ודוגמאות

3. זמינות 1

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

דוגמה: SLO 99. 9% תוך 30 יום תקצוב שגיאה = 0. 1%, שהוא שווה ערך ל 43 min 12 שנייה של זמינות.

3. 2 latency

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 תשלומים (רמה עסקית)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) תקציב פגום ושיעור צריבה

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

• ערוץ מהיר (גילוי ב ~ 1 h),
• ערוץ איטי (מגמה על ~ 6-12 h/24 h).

• אם לשרוף קצב> 14. 4 בשעה 1 - SEV-1 (נאכל את התקציב היומי ב ~ 100 דקות).
• אם לשרוף קצב> 6 תוך 6 שעות - SEV-2 (הידרדרות מהירה).

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

אינדיקטור שגיאה: פרופורציה של הפרות 5xx או latency.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) דוגמאות SLI/SLO מאת Domain

6. 1 API שער/Edge

שגיאות SLI: שיעור תגובה 5xx <0. 1% (28d).
SLI-Latency: p95 nothered 250 ms (היום).
זמינות ב-99. 95% (רבעון).

6. 2 תשלומים

SLI-Success: תשלום עבור כשלים מוצלחים (למעט כשלי לקוח) IM 99. 8% (28d).
SLI-Latency: אישור 2 שניות עבור 99% (היום).
זמן לארנק p95 3 יומי 3 (24h).

6. 3 מסדי נתונים (PostGreSQL)

LI-Lag: שכפול lag p95 לשיא של 1 שניות (יום).
שגיאות SLI: שגיאת שאילתה שיעור 0. 05% (28d).
זמינות אשכול SLO-99. 95%.

6. 4 תורים/הזרמה (קפקא)

SLI-Lag: הודעות N (שעה).
עמידות SLI - לאשר כניסה 99. 99% (28d).
זמינות של ברוקרים ו-99. 9%.

7) תהליך אמינות KPI

MTTD (זמן אכזרי לזהות)

MTTA (... להכיר)

MTTR (... כדי לשחזר)

MTBF (... בין כשלונות)

% מהתקריות עם הפחתה אוטומטית

כיסוי SLO/התראה של נתיבי תנועה עליונים (יעד 95%)

שיתוף של שחרורים עם שלב הקנרית

צריכת תקציב שגוי על ידי צוותים/תכונות

8) כיצד לשים את SLO מציאותי

1. מדידת אמינות קו הבסיס הנוכחי (3-4 שבועות).
2. הגדר נתיבי משתמש ”רגישים” (התחברות, הפקדה, משחק).
3. תן דעתך למחיר של כל סטייה (זמן, כסף, מוניטין).
4. בחר מטרה שאפתנית אך ברת השגה (שיפור של 10-30% בקו הבסיס).
5. סקירה רבעונית.

• מיד ”חמש תשיעיות” ללא הצדקה.
• SLO על ידי מדדים שאינם נראים למשתמש (לדוגמה, מעבד ללא תקשורת עם UX).
• יותר מדי ספריי מיקוד.

9) SLO ודיווח תקציב

• השלמה לפי SLO: למעשה נגד מטרה, מגמות, ביטחון עצמי.
• סיכום של צריכת שגיאות: כמה תקציב ”נשרף” מאשר על ידי מי (שחרור/תקרית).
• חמשת הגורמים הראשונים להשפלה, תוכנית CAPA ומצב משימה.
• השפעה עסקית: המרה, ND, שימור, LTV.

10) תקשורת עם מדיניות שחרור

שגיאה בתקציב <50% + שחרור חופשי.
50-80% ”מצב זהיר”: רק חישובים בסיכון נמוך/קנרית.

11) SLA (חוזה) - תבניות פריטים

חובת זמינות: למשל, 99. 9 %/חודש.
כוח מג 'ור: DDOS מעבר לשליטה סבירה, ספקי צד שלישי.
חלון מדידה ואזור אחריות: מקורות מדדים, שיטת חישוב.
קרדיטים/פנדלים: טבלה של רמות (לדוגמה, חוסר זמינות של 60-120 דקות = X אשראי).
הליכי הסלמה והודעה: מועדים, ערוצים.
נתונים ופרטיות: מיסוך, אחסון, אחיזה משפטית.
תוכנית מניעת חזרה (CAPA) במקרה של הפרה.

12) כלי מדידה

מדדים פסיביים: פרומתאוס/מימיר/תאנוס, יצואנים.
יומנים: Loky/ELK לספור הצלחות/שגיאות ברמה העסקית.
סינתטיים: דוגמאות פעילות (התחברות/הפקדה/משחק) על ידי cron.
איתור: Tempo/Jaeger עבור p99 צווארי בקבוק.
תשלום/מימון: מקורות אמת קרקעיים לתשלום SLI.

13) שאילתות דוגמאות (תבניות)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

מפתח> מסנני זיקוק לשלילה ”ירידה על ידי לקוח”.

14) פינוקים ואמינות

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

15) SLO/התראה איכות - רשימה

[ ] SLI מתאם עם UX ומדדים עסקיים.

[ חלון ] וצבירה עקביים (מתגלגלים 28d/רבע).

[ ] התראות רב-חלונות, לא התנפלות, ניתוב מבוסס תפקידים.

[ תיעוד ]: בעלים, נוסחה, מקורות, מדפים.

[ ] דמו SLO עם תקציב שגוי ואינדיקטורים לשרוף.

[ ] סקור מטרות באופן קבוע (רבעון). ‏

[ ] בדיקות סינתטיות על תרחישי מפתח.

16) תוכנית יישום (4 איטרציות)

1. שבוע 1: רשימת מלאי של נתיבי משתמש, טיוטות SLI, לוחות מחוונים בסיסיים.
2. שבוע 2: עיצוב SLO, תקצוב, התראות (צריבה מהירה/איטית).
3. שבוע 3: אינטגרציה עם תהליך התקרית/שחרור, הקפאת כללים.

4. שבוע 4 +: SLA חוזית, ביקורות רבעוניות, ”עלות לכל 9” מודל פינופס

17) מיני ־ FAQ

אני צריך סלו אחד לכל שירות?
עדיף 2-3 מפתחות (הצלחה + latency) במקום עשרות משניים.

מה אם התקציב מותש?
הקפאת שחרור, התמקדות בייצוב ו CAPA, הסרת תכונות ניסיוניות.

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

תוצאות

אמינות אינה מבוקרת על ידי מערכת מדדים מוזרה, אלא על ידי המערכת: SLI # SLO _ Group Access ac Burn ac Act Act Act Act Access Act Access Act Accest Ac.CAPA. הגדרות סטנדרטיות, מקורות מידע ודיווח, מטרות קישור לחוויית משתמש וכלכלה, וסקירה קבועה של תשיעיות המבוססות על ROI בעולם האמיתי.