מעקב מעלה

1) מדוע לנטר את הזמן

זמן פנוי - פרק הזמן שבו השירות זמין למשתמש. זוהי השורה הראשונה של יכולת התצפית: שימו לב מיידית לאי-נגישות, הידרדרות ברשת, כשל DNS/TLS, ניתוב או בעיות CDN. עבור מערכות בעלות עומס גבוה ומווסתות (fintech, iGaming), העלאה בזמן משפיעה ישירות על הכנסות, ביצועי SLA וסיכוני עונשין.

2) מונחים ונוסחאות

זמינות: 'sli' = (צ 'קים מוצלחים/כל הצ' קים) × 100%.
זמינות המטרה לחלון (בדרך כלל 28-30 יום), לדוגמה 99. 9%.
SLA: חובה חיצונית; תמיד יש סלו פנימי.
MTBF/MTTR: זמן ממוצע בין כשלים/זמן החלמה ממוצע.

99. 0% ~ 432 דקות לא זמינות

99. 9% ~ 43 דקות ~

99. 99% → ~4. 3 מין

99. 999% * 26 שניות

3) אילו בדיקות דרושות (קופסה שחורה)

הושק מנקודות חיצוניות (אזורים/ספקים שונים) כדי לראות את השירות ”דרך עיניו של הלקוח”.

1. (ICMP (פינג - זמינות רשת/צומת בסיסית. מהיר, אבל לא משקף הצלחה עסקית.
2. חיבור TCP - הקשבה שמאלה? שימושי עבור ברוקרים/DB/SMTP.
3. HTTTP/HTTPS - קוד מצב, כותרות, גודל, הפניות, זמן לבייט ראשון.
4. TLS/תעודות - תקופת תוקף, שרשרת, אלגוריתמים, SNI, פרוטוקולים.
5. DNS - A/AAAA/CNAME, NS-Health, הפצה, DNSSEC.
6. GRPC - מצב שיחה, מועד אחרון, metadata.
7. שקע אינטרנט/SSE - לחיצת יד, תחזוקת חיבור, הודעת אקו.
8. פרוקסי/ניתוב/CDN - פופ שונה, חשיש מטמון, גיאו-וריאנטים.
9. תרחישים סינתטיים טרנסצנדנטיים (קליקים/טפסים): ”Login lough search # deposit (ארגז חול)”.
10. ניטור לב/קרון - השירות חייב ”דופק” (הוק פעם ב-N דקות); אין אות אזעקה.

טיפים

קבע פסקי זמן קרובים יותר ל-UX האמיתי (לדוגמה, TTFB 300 ms, סך הכל 2 S).
בדוק את נכס התוכן (שדה מילת מפתח/JSON) כך ש- ”200 OK” עם שגיאה לא נחשב להצלחה.
בדיקות כפולות באמצעות ספקים ורשתות עצמאיות (רב-הופ, ASNs שונים).

4) ארגז לבן ושירות בריאות

בדיקות לביאה/מוכנות לתזמור (תהליכים הם בחיים? מוכן לקבל תנועה?).
בריאות תלות: DB, מטמון, ברוקר אירועים, API חיצוני (תשלומים/KYC/AML).
דגלים/השפלה: במקרה של בעיות, בטל בעדינות מסלולים שאינם קריטיים.

דגימות לבנות אינן מחליפות בדיקות חיצוניות: השירות עשוי להיות ”בריא מבפנים”, אך לא זמין למשתמש בשל DNS/TLS/rate.

5) גאוגרפיה וריבוי אזורי

הפעל סינתטיים מאזורי תעבורת מפתח וכמעט ספקי תלות קריטית.
קוורום (Quorum): אירוע מתועד אם כשל באזורי ה-Window N (לדוגמה, 2 מתוך 3) כדי לחתוך חריגות מקומיות.
סף אחר קוהורטה: SLI/SLO נפרד עבור מקטעים חשובים (מדינות, אח "מים, נושאות מטוסים).

6) מדיניות התראה (רעש מינימלי)

Multi-region + multi-grave: זימונית רק במקרה של כשל עקבי (לדוגמה, HTTP ו-TLS בו זמנית, 2 אזורים).
כישלונות רצופים או 2-3 דקות לפני הזימון.

• L1: בכוננות (שירותי הפקה).
• רשת L2/פלטפורמה/אבטחה המבוססת על חתימת כישלון.
• קרוב אוטומטית: לאחר צ 'קים מוצלחים יציבים.
• שעות שקט/זיכיונות: עבור שירותים פנימיים שאינם קריטיים - רק כרטיסים, אין איתורית.

7) עמוד סטטוס ותקשורת

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

8) התחשבות בתלויות חיצוניות

עבור כל ספק (תשלומים, KYC, דואר, CDN, עננים) - המחאות משלהם ממספר אזורים.
נתיבי כשל: החלפה אוטומטית לספק חלופי באמצעות אות סינתטי.
SLOs נפרדים ברמת הספק e2e-SLO משולב.
מסכים על SLA עם ספקים (סטטוס הוקס, עדיפות תמיכה).

9) לוחות מחוונים ווידג 'טים

מפה עולמית עם מצב המחאות (לפי סוג: HTTP, DNS, TLS).
ציר זמן של תקריות עם הערות שחרור/דגל.
P50/P95/P99 TFB/TTL/latency by area.
זמינות על ידי קוהורטה (מדינה/ספק/התקן).
MTTR/MTBF, ”דקות סרק” ומגמות ”לשרוף” של תקציב הזמינות לחודש.
סיבות עליונות לכישלונות (TLS-expearing, DNS-פתרון, 5xx, timeouts).

10) תהליך תקרית (תרחיש ארעי)

1. אזהרה רב-תחומית מופעלת.
2. הקצין התורן מאשר, מדליק את הקפאת השחרור, מודיע לבעלים.
3. אבחון מהיר: מצב DNS/TLS/CDN, שחרור עדכני, לוח זמנים לשגיאות.
4. מעקף: שינוי מסלול, תוכן עממי/ספק, המאפשר מצב הידרדרות.
5. התאוששות: ודא שהתנועה הסינתטית/אמיתית ירוקה.
6. תקשורת בדף המצב; סגירת התקרית.
7. RCA ופריטי פעולה: תיקונים, בדיקות, התראות, ספרי משחק.

11) דיווח SLA/SLO

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

12) תבניות בדיקה (דוגמה)

• שיטה: ”גט/בריא/ציבורי” (אין סודות).
• פסק זמן: 2 אס, ניסיון חוזר: 1.
• הצלחה: '2xx', כותרת 'X-App-Version' הווה, JSON field 'סטטוס: ”ok”.

• מונח> 14 ימים, שרשרת תקפה, פרוטוקולים 'TLS 1. 2 +, נכון SNI.

• זמן התגובה נקבע על 100 ms, רשומות A/AAAA הן כמתוכנן, אין SERVFAIL/SURFAIL.

• Webhook '/beat/{ service 'כל 5 דקות; היעדר 2 אותות ברצף - התראת L2 (משימות רקע/ETL).

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

[ ] בדיקות חיצוניות רב-אזוריות [HTTP/TCP/DNS/TLS/תסריטים עמוקים].

[ ] דגימות מוכנות/לביאה לבנה לתזמור.

[ ] הפרדה של נתיבים ביקורתיים/לא ביקורתיים, דגלי השפלה.

[ ] קוורום וחובות בהתראות, הסלמה וסגירה אוטומטית.

[ ] עמודי סטטוס ציבוריים ופנימיים, תבניות מסרים.

[ ] בדיקות נפרדות ו-SLO לספקים חיצוניים + כשל אוטומטי.

[ ] לוחות מחוונים: מפה, ציר זמן, אחוזים, דקות סרק, MTTR/MTBF.

[ ] דוחות SLA/SLO רגילים ו-RCAs לאחר התקרית.

14) שגיאות תכופות

רק פינג/פורט ללא תוכן HTTP הוא ירוק כאשר אינו זמין בפועל.
נקודת ניטור אחת - מסקנות חיוביות/שליליות שגויות.
אין בקרת TLS/DNS - הפסקות פתאומיות עקב עיכוב/פיגורציה מוטעית.
רעש נוסף: התראות על כשלים בודדים מאותו אזור/סוג של צ 'ק.
אין קשר לשינויים - אין הערות של שחרורים ודגלים בלוחות מחוונים.
חסרים תלויות - ספק התשלום נפל, והמעמד הכולל הוא ”ירוק”.

15) השורה התחתונה

מעקב למעלה הוא לא רק על "כתובות שיא. "זוהי מערכת של בדיקות סינתטיות מאזורים אמיתיים, התראות סבירות ללא רעש, תקשורת שקופה דרך דפי מצב, חשבון לתלות חיצונית ודיווח קפדני. ניטור זמן שנבנה כהלכה מפחית את MTTR, מגן על SLAs, ומשמר את יכולת החיזוי של חווית המשתמש.