KPI תשתיתיתName

למה אתה צריך את זה?

קיי-פי-איי תשתית הופכים ”רגשות” על יציבות ליעדים מדידים, ניהול סיכונים ומיקוד עבודה. ה-Metrics הנכון מקשר בין SLIS הטכני לתוצאות עסקיות (המרה, זמן לארנק, LTV) ומאפשר לך לתכנן פיתוח, עומס ושיתוף של חדשנות נגד אמינות.

מושגים בסיסיים: SLI, SLO, SLA ותקציב שגיאה

(SLI (Service Level Indicator - אינדיקטור איכות נמדד: הפרופורציה של בקשות מוצלחות, p95 latency, uptime לכל מרווח.
SLO (Service Level Objective) - מטרה SLI (לדוגמה, הצלחה 99. 9% ב-30 יום".
הבטחה חיצונית עם קנסות/נקודות זכות. תמיד מופק מ, אבל לא שווה ל, SLO.
תקצוב שגיאה = ”1 -SLO”. זהו קצב הכשל המרבי המותר לכל חלון מדידה. נהג לקבל החלטות על שחרור מסוכן וניסויים.

דוגמה:

זמינות SLO 99. 95% ב 30 יום תקצוב שגיאה 0. 05% ≈ 21. 6 דקות של ”כישלון” בחודש קלנדרי.

ארבעה אותות זהב ועוד

1. Latency (p50/p90/p95/p99, הזנב חשוב מהממוצע).
2. שגיאות (5xx/timeout/business שגיאות).
3. תנועה/דרך (RPS/QPS, MBps).
4. רוויה (CPU/RAM/IO/FD/חיבורים/GC/מכסות).
נוסף: התחלה קרה, תורים/גיבוי, זמן פריסה, ציות SLO.

מודל SLI עבור סוגים שונים של שירותים

HTTP/API

זמינות: ”(מוצלח 2xx/3xx שגיאות לוגיות )/( כל הבקשות)”

Latency: 'p95' לשאילתות מוצלחות; מטרה במסלולים חמים.
איכות: יחס הבקשות עם ”קהל/היקף” נכון (ללא שגיאות authZ).

תורים/אסינכרוני

זמן עיבוד מסרים: p95 מקצה לקצה. N שניות

צבר: חציוני <x, tail p99 <Y.
שגיאת משלוח: Z. ppm.

DB/Cache

מבצע Latency: p95 get/לשים/להתחייב.
רוויה: שימוש בבריכה, יחס להיט מטמון.
שגיאות: פסקי זמן, מבוי סתום, סופות פינוי.

CDN/Static

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

תשלומים (עסקים SLI)

זמן לארנק p95, הפקדה/הצלחת פלט%, שיעור אי ספיקת PSP.

חישוב של זמינות והעלאה

זמינות שירות = ”בקשות מוצלחות/כל הבקשות” (רצוי לא ”זמן דקות”).
חלופה לצומתי תשתית היא ”זמן ירוק/זמן חלון”.
חלון לוח שנה: 28-31 ימים, חלון הזזה: להימשך 30/90 ימים.
שעות עבודה/חלונות קריטיים: עבור משרדים אחוריים ניתן לשקול uptime בהתאם ללוח הזמנים (לדוגמה, 08: 00-22: 00 שעון מקומי).

קומפוזיציה של תלויות (מפושטות): אם שירות A תלוי ב-B וב-C, עבור כשלים עצמאיים:

'זמינות (A) OV (B) × Av (C) × Av (A' B, C) - חשוב להניח SLOS על הגבולות.

דוגמה ערכת SLO (מדגם)

שער API: IM 99 זמין. 95 %/30d; p95 latency name 120 ms; שגיאה ברישום 0. 2%.
קופה/תשלומים: הפקדת הצלחה 98. 5 %/30d; זמן לארנק p95 יומן 90 ב; פסקי זמן פסו "פ על 0. 3%.
מסד נתונים: p95 קרא 10 ms; p95 כתוב 25ms; העתק lag p95 על 150.
מטמון: יחס פגיעה ב-85%; סופות פינוי = 0/30.
תשלום: p95 עיבוד סימון 5 דקות; הונאה-נופל-חיובי-0. 3%.

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

אם תקציב השגיאה מותש ב-50% + לפני אמצע החלון, הוצג ”הקפאה” של תכונות/שחרור, הפוקוס הוא על ייצוב.
אם התקציב מושקע לאט, אתה יכול להאיץ ניסויים/קנריות.
חיבור צריכת תקציב לשחרור/תקריות ספציפיות באמצעות "שחרור _ id'.

התראה: איך לא ”להתקשר בלילה” לשווא

התראות רק להשפלת SLO וסימפטומים חיוניים, לא לכל מטרי.
חלון רב-חלונות, קצב רב-צריבה: חלון קצר (5-15 דקות) + חלון ארוך (1-6 ח ').
דוגמה: ”שרף קצב 14 × 5 דקות ו-6 × 1 שעה”.
שעות שקטות לאותות non-P1; ניתוב בעלות.

לוחות מחוונים ומנהגי הדמיה

פנל SLO: ציות שירות, שנותר תקציב, מפות תלות.
לוח אחסון: p50/p90/p95/p99, פירוק על ידי מסלולים/דיירים/מדינות/ASN.
לוח שגיאה: קודים/סיבות, מתאם עם דגלים משוחררים/מאפיינים.
קיבולת-פאנל: מעבד/RAM/IO/רשת/FD/חיבורים, מגמות ותחזיות.
לוח עסקים: המרה, זמן לארנק, הפקדות/משיכות, השפעה על פרוטוקולים (WAF/Anti-Bots).

תקריות, MTTR ופוסט-mortems

תגובה KPI:

MTTD (גילוי), MTTA (קבלת), MTTR/MTTC (התאוששות/בלימה),% תקריות ללא RCA בזמן.
ספרי שעשועים: מי מחריף, איך להדליק דגלי תכונה/בלוקים, איך לגלגל בחזרה את השחרור, תקשורת עם העסק.
עובדות, ציר זמן, סיבות שורשיות (אלה/תהליכים), פעולות: בדיקות רגרסיה מיידית/ארוך טווח, השפעה על SLO.

ביצועים, רוויה והשפלה

חדר הראש: חדר הראש של משאב המטרה (למשל. מעבד <70% p95, RAM <75% p95).
נתיבים חמים: פרופיל מסלולים קריטיים; 'p99' הוא יותר חשוב מהממוצע.
מצבי הידרדרות: מטמון בלבד, קריאה בלבד, טחינת ירידה של בקשות לא חשובות, ”הגבלת קצב ”/מכסה.

נוסחאות ודוגמאות של חישובים

1) זמינות לפי דרישה


availability = (total_requests - error_requests) / total_requests

היכן ש 'בקשות' = 5xx + פסקי זמן + שגיאות עסקיות (מוגדרות).

2) תקציב שגיאה (דקות)


error_budget_minutes = window_minutes (1 - SLO)

דוגמה: 30 יום (43,200 דקות), SLO 99. 95% → 21. 6 דקות.

3) קצב צריבה


burn_rate = observed_error_ratio / (1 - SLO)

אם SLO 99. 9% (תקציב 0. 1%) וטעות 1% # burn_rate = 10 ×.

4) זמינות תרכובת


A_total ≈ A_gw × A_auth × A_db × A_psp

נפילות קטנות מכפילות את ה-A.

מדידה ומדיניות חריגה

חלונות לא מתוכננים (תקריות) נלקחו בחשבון.
חלונות תחזוקה מתוכננים - נלקחים בחשבון רק אם ה ־ SLA כל כך רשום; עבור SLOs לעתים קרובות אינם מחוסרים (או מסומנים בנפרד כ ”מתוכנן _ השבתה”).
סינתטיים נגד משתמשים אמיתיים: שימושי להחזיק בשני הערוצים (RUM + checks).

דוגמאות של חפצים

KQL/PromQL (רעיונות)

שגיאת SLI (5xx + פסק זמן) תוך 5 דקות:

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

מסלול latency p95:

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

שיעור צריבה 5m/1h:

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (תשלומים עסקי SLI)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

לנהל תלות וקסקדות

חוזים בין הקבוצות: gateway↔auth↔wallet↔PSP.
מדיניות השפלה: כאשר התלות יורדת, השירות נכנס למצב ”פשוט”.
דגלים מאפיינים: ביטול פונקציות לא ביקורתיות, שחרור אפור כדי להפחית זנבות.

קיבולת תכנון ותחזיות

שומס. תחזית RPS/MBps על ידי מגמות ואירועים (טורנירים, גפרורים, קידום מכירות).
בדיקת טעינה על ידי ”שבילי זהב”, בדיקות נפרדות עבור PSP/payouts.
המניה בשיא: גורם מטרה 1. 3 × 2. 0 כפול העומס הצפוי.

SLO/KPI רשימת מימושים

1. תזהה נתיבי משתמש קריטיים ותנהל משא ומתן ”מנקודת המבט של הלקוח”.
2. בחר מטרות SLO וחלון (30/90 ימים); לחשב את תקציב הטעות.
3. לבנות אוסף מטרי לתוך שערים/שירותים, לנרמל קודים/סיבות.
4. הגדרת התראות קצב צריבה (חלון קצר + ארוך), ניתוב וכוננות.
5. דמיינו ציות ל ־ SLO, מקושרים עם דגלים משוחררים/מאפיינים.
6. ליצור תקציב נגד מדיניות שינוי ותהליך הקפאה.
7. רטרוספקטיבות ו-RCAs על כל עודף, בדיקות רגרסיה.
8. סקירה רבעונית על שימוש בתקציב ומטרות עסקיות.

טעויות נפוצות

מדידה ”uptime by ping”, התעלמות משגיאות יישום.
SLOs ערוכים ”במילואים” (99. 999%), אבל בלתי ניתן להשגה ולפתור דבר.
התראות על מדדים ברמה נמוכה במקום תסמינים של משתמש.
אין מפת תלות. לא ברור היכן היא בוערת.
אין קשר בין SLO ל-professions = לא ברור מי ”אכל” את התקציב.
התעלם ממשתמשי UX VIP ממוצעים טובים אך רעים.

iGaming/fintech ספציפי

פסגות מתוכננות: התאמות/אירועים/קידום - הגדלת קיבולת מראש, חימום מטמון/CDN, כולל פרופילי הגבלה מיוחדים.
Business SLI: Time-to-Wallet, Preduct/treasure p95; בשורש לוחות המחוונים.
PSP/שותפים: לוחות SLO/Dashboard על ידי ספק, החלפת מסלול אוטומטית.
אנטיוט/אנטי-הונאה: לא צריך להיות תקציב לשגיאות - להפריד ”בלוקים לגיטימיים” מ ”טעויות טכניות”.
רגולציה: אחסון רישומים, רבייה של חישובי SLO/SLA, דו "חות תקרית.

FAQ

האם אני צריך להחסיר עבודה מתוכננת מה-SLO?
בדרך כלל לא: SLO משקף את החוויה שחווה המשתמש. באפשרותך לציין יוצאים מן הכלל עבור SLA.

למה פי-95, לא ממוצע?
האמצעי מסווה את הזנבות; UX מגדיר זנבות (p95/p99).

אפשר לקבל סלו אחד לכל המוצר?
אתה צריך עץ SLO: צבירה של מוצר וילדים על ידי מסלולים/רכיבים קריטיים.

סך הכל

מערכת KPI תשתית חזקה היא SLIs מותאמת אישית, SLOS ריאליסטי, תקציב שגיאות כמנוף בקרת שינוי, כוננות חכמה ומשמעת תקרית, ו-RCAs. חיבור אינדיקטורים טכניים עם מדדים עסקיים, איסוף אוטומטי והדמיה - והתשתית תהפוך צפויה, והעלאה תהיה מבוקרת אפילו בתרחישי שיא.