Operations and Assess Action Management by Syste

התראות קיבולת המערכת

1) למה אתה צריך את זה

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

מטרות:

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

2) מושגים בסיסיים

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

3) ארכיטקטורת אותות ומקורות נתונים

טלמטריה: מטריצות (Prometheus/Otel), יומנים (ELK/ClickHouse), עקבות (Otel/Yager).
גישה שכבתית: התראות על ידי שכבות (Edge # API Access Services = תורים/זרמים = מסדי נתונים/מטמונים = מאגרי קבצים/אובייקטים = ספקים חיצוניים).
הקשר: דגלים, פרסומות, קמפיינים שיווקיים, טורנירים, יישור גיאו.
צמיג תקרית: Alertmanager/Pagre Duty/Opsgenie/Slack; מחייב לרכיבה ומטריצת הסלמה.

4) מדדי מפתח לפי שכבה (מה לנטר ומדוע)

קצה/אל 7

RPS, 95/99-latency, שיעור שגיאה (5xx/4xx), חיבורים פתוחים.
דירוג גבולות/מכסות, מוריד את CDN/WAF/Firewall.

API-group/Backend-for-Frontend

רוויה על ידי עבודה/מאגר עבודה, תור בקשה, פסקי זמן למורד הנחלים.
שברי דלדול (פלבים, מפרי מעגל).

תורים/זרימה (קפקא/ארנב/פולסר)

השהייה של לאג/צרכן, קצב גדילה, תפריט (msg/s, MB/s).
חלוקה, איזון מחדש של churn, ISR (עבור קפקא), מגש/סבא-מאוחר יותר.

עובדים אסינכרונים

זמן משימה, אורך תור, אחוז משימות SLA שפג תוקפן.
מעבד רוויה/זיכרון/אף-די בבריכות.

caches (Redis/Memcashed)

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

TrackStrancture (PostgreSQL/MySQL/ClickHouse)

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

אחסון אובייקט/קובץ

PUT/GET latency, 4xx/5xx, egress, בקשות/שנייה, גבולות ספק.

ספקים חיצוניים (תשלומים/LCC/ספקי משחקים)

מגבלות TPS, חלונות QPS, קצב שגיאה/פסק זמן, תור מגש מחדש, ”עלות לכל קריאה”.

תשתית

מעבד/זיכרון/FD/IOPS/רווית רשת על צמתים/תרמילים/ASG.
אירועי HPA/VPA, תרמילים תלויים ועומדים, מיכל OOM/מצערת.

5) סוגי התראות קיבליות

1. סף סטטי

פשוט וישיר: 'db _ חיבורים> 80% מקסימום'. טוב כמו אות מגדלור.

2. סף הסתגלות (דינמי)

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

3. מכוון SLO (קצב צריבה)

הם מופעלים כאשר שיעור האכילה בתקציב השגיאה יסכן את ה-SLO באופק השעה X.

4. פרוגנוסטי (התראות תחזית)

”אחרי 20 דקות במגמה הנוכחית, התור יגיע ל-90%”. משתמשים בחיזוי לינארי/חזק/דמוי נביא על חלונות קצרים.

5. ריבוי אותות

הטריגר עם הצירוף: "תור _ lag grough" + "consumer _ cpu 85% +" autoscaling at max "#" נדרשת התערבות ידנית ".

6) מדיניות סף ואנטי-רעש

סימן מים גבוה/נמוך:

למעלה: אזהרה 70-75%, כרתים 85-90%. למטה: היסטרציה 5-10 pp על מנת לא ”ראה על הסף”.

חלונות זמן ותוספות:

לקריטריונים של 5 מטר, עבור 10-15 מטר עבור אזהרות. מצב לילה: מסלול לא קריטי לצ 'אט בלי לקרוא.

קיבוצי אירועים:

קבוצה אחר שירות/אשכול/גיאו כדי לא לייצר כרטיסי תקרית.

דיכוי תלות מודעת:

אם הספק של KYC לא נמצא, שגיאות API נובעות מקריאה לבעל האינטגרציה, לא כל הצרכנים.

חלונות זמן שיווק:

במהלך תקופת המלאי, להעלות את סף הרעש עבור ”צמיחה צפויה”, אבל להשאיר התראות SLO ללא פגע.

7) דוגמאות חוק (פסאודו-פרומתאוס)

חיבורי DB:


ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

קפקא לג + הגדלה אוטומטית על הגבול:


ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

Burn-קצב SLO (API Latency):


ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

זיכרון Redis ואיקשנס:


ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

ספק תשלומים - גבולות:


ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8) גישת SLO ועדיפות עסקית

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

9) הפעלה אוטומטית ו ”נכונה”

HPA/VPA: המטרה לא רק על ידי CPU/Memory, אלא גם על ידי מדדים עסקיים (RPS, תור lag, p99 latency).
זמן חימום: קחו בחשבון את מגבלות ההתחלה והספק הקר (ספין-אפ ASG, בוני מכולות, מטמונים לחימום).
מעקות בטיחות: תנאי עצירה בצמיחה דמוית מפולת של שגיאות; הגנה מפני ”בעיית קשקשים”.
קיבולת-משחק: איפה ואיך להוסיף שבר/צד/העתק, איך לחלק מחדש את התנועה באזור.

10) תהליך: מתכנון לתפעול

1. הגבלת מיפוי: הגבלת צוואר בקבוק ”אמיתי” לכל שכבה (מקסימום קונוס, IOPS, TPS, ספקי מכסות).
2. בחירת מדדי חיזוי: אילו אותות מצביעים על ”מנוחה תוך N דקות” קודם.
3. עיצוב סף: תרכובת גבוהה/נמוכה + SLO-Burn +.

4. רינון לכל כרתים: צעדים אבחוניים (”מה לפתוח”, ”מה מצווה”, ”איפה להסלים”), שלוש אפשרויות לפעולה:

5. בדיקות: סימולציות עומס (ימי כאוס/משחק), התחלות יבשות של התראות, בדיקת אנטי-רעש.

6. סקירה ואימוץ: בעל אות = בעל שירות. אין בעלים - אין דף.

7. נקודות מבט וכוונון: ניתוח שבועי של טעות/החמצה; מטרי ”MTTA (אק), MTTD, MTTR, יחס רעש/אות”.

11) אנטי דפוסים

מעבד> 90% פאניקה: ללא התאמה עם תורים/latency, זה יכול להיות נורמלי.
”סף אחד לכולם”: אזורים/אזורי זמן שונים - פרופילי תנועה שונים.
התראה ללא פנקס: עמוד ללא ניקוז פעולה ברור בכוננות.
עיוורון לספקים: מכסות חיצוניות/מגבלות הן בדרך כלל הראשונות ”לשבור” תסריטים (PSP, KYC, אנטי הונאה, ספקי משחקים).
אין היסטריה: ”ניסור” בגבול 80 %/79%.

12) מאפיינים של iGaming/פלטפורמות פיננסיות

פסגות לוח הזמנים: פריים טיים, גמר טורניר, משחקים גדולים; לקדם העתקים של המטרה ולמלא מטמונים מראש.
נחלים ואתרי אינטרנט חיים: התפרצויות של אירועי שידור * מגבלות על ברוקרים/אתרי אינטרנט.
תשלומים ו-KYC: חלונות מספקים, ניקוד נגד הונאה; שמור נתיבי חילוף ומרבצי ”גרייס-מוד”.
איזון גאו: כשלים מקומיים לספק - להסיט את התנועה לאזור השכן שבו יש חדר ראש.
אחריות: בסיכון להפסיד הימורים/הימורים - דף מיידי לצוות תחום + התראה עסקית.

13) לוחות מחוונים (סט מינימלי)

סקירת קיבולת: ראש אחר שכבה, אזורים מסוכנים 3 עליון, SLO-קצב צריבה.
זרם & תורים: פיגור, גידול בצריכה, רוויה צרכנית, מצב HPA.
DB & Cache: חיבורים, רפול-לג, p95/p99 latency, יחס פגיעה, פינוי.
ספקים: TPS/חלונות/מכסות, פסקי זמן/שגיאות, עלות שיחה.
תשחרר/תכונה הקשר: משחרר/פישפלג ליד עקומות.

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

[ רשימה ] של גבולות ובעלים ”אמיתיים”.

[ ] מפת מטרי חיזוי + אסוציאציות בין שכבות.

[ ] סטטי + היסטריה.

[ ] SLO-Burn-התראות בדרכים קריטיות (הפקדה, הימור, השקת משחק חי).

[ ] התראות חיזוי על תור/זרמים/קשרים.

[ ] דיכוי/תחזוקה של החלון; פוליטיקה נגד רעש.

[ ] Runbook 'ועם פקודות, גרפים, פילטרים השפלה.

[ ניתוח שבועי ] של חיוביות כוזבות וכוונון.

[ ] דין וחשבון על מסעות שיווק ולוח שנה לאירועים.

15) דוגמא לדפוס ריצות (מקוצר)

איתות: "MoveGATRISKfoss

מטרה: למנוע גידול לאג> 10 מיליון ו עיכוב טיפול> 5 דקות.

אבחנה (3-5 דקות):

1. בדוק 'hpa _ רצוי/max', מצערת/oom בבורות.

2. תצוגה 'rate (lag) ", מחיצה (skew).

3. בדוק ברוקר (ISR, לא משוכפל, רשת).

פעולות:

להגדיל את ההעתקים לצרכן ב + N, להעלות מקסימום בטיסה.
אפשר מאגר עדיפות על ”נושאים קריטיים”.
באופן זמני להפחית את התדירות של טיפולים משניים/העשרה.
אם ASG במקסימום - מבקש התרוממות זמנית מהענן; במקביל - אפשר הידרדרות של תפקודים כבדים.
חזרה לפרופיל תנועה רגיל אחרי 'לג <1 מיליון' 15 דקות.
בעל אשכול קפקא, ואז פלטפורמת SRE.

16) KPI ואיכות אות

כיסוי:% מהנתיבים הקריטיים נסגרים על ידי התראות קיבליות.
רעש/אות: לא יותר מ-1 עמוד בדוי לכל שבוע בכוננות.
MTTD/MTTR: תקריות קיבליות מזוהות 5 דק לפני שביתות SLO.
הצלות פרואקטיביות: מספר תקריות שנמנעו (לאחר המוות).

17) התחלה מהירה (ברירות מחדל שמרניות)

DB: אזהרה ל ־ 75% מחיבורים/IOPS/lat; כרתים 85%, היסטרציה 8-10 pp

מטמונים: "פגע <0. 9 'ו' פינוי> 0 '> 5 דק' - אזהרה; " השתמש _ mem> 85% '- כרתים.
תורים: 'lag' גובה> 3 סיגנל הממוצע עבור 30d + hpa at max '- כרתים.
API: 'p99> SLO1. 3 '10 דקות - אזהרה; " שרפת קצב> 4 '15 דקות - כרתים.
ספקים: ”דרך> 90% מכסה” - אזהרה; 'פסקי זמן> 5%' - כרתים.

18) FAQ

Q: מדוע לא רק ”מעבד> 80%”?
א ': ללא איחור/תור ההקשר, זה רעש. המעבד עצמו אינו שווה לסיכון.

קיו: האם אנו זקוקים לסף הסתגלות? ‏

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

קיו: כיצד לשקול שיווק/אירועים? ‏

A: Campaign langer # annotations on graps + temply anti-noise advancement, אך אל תיגע בהתראות SLO.