הגדרת Synthetic Monitoring (בדיקות זמינות תקופתיות)

ניטור סינתטי: כשכשל נראה רק ללקוח

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

ניטור סינתטי סוגר בדיוק את סוג הכשלים הזה. תרחישים על Playwright מורצים לפי לוח זמנים מנקודות חיצוניות באזורים וברשתות שונים: לפתוח קטלוג, להוסיף מוצר לסל, להביא הזמנה עד אישור, לבדוק את תגובת אינטגרציית התשלומים. הנתיב הוא אותו נתיב של קונה חי — מחוץ למתאר, דרך כניסה ציבורית ורשת הפצת תוכן.

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

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

מה נותנת בדיקה סדירה של זמינות שירותים

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

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

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

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

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

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

מצבי ניטור סינתטי: השוואת גישות

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

תרחיש הזמנה רב-שלבי חוזר על נתיב הקונה — בחירה, סל, השלמה, אישור — ומשווה תגובות בכל שלב. הוא תופס נתק באינטגרציות שבקשה בודדת מפספסת: העמוד נפתח, אבל ההזמנה לא עוברת.

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

שלבי הטמעה: מניתוח נקודות כניסה ועד העברה לתמיכה

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

1. ביקורת נקודות כניסה. אוספים כתובות חיצוניות, API, טפסי התחברות, נקודות שותפים ותשלומים, ומסמנים בנפרד את אלה שהכשל שלהן לא נראה לניטור פנימי. עבור כל נקודה מתעדים בעלים והתנהגות צפויה.
2. תעדוף. מחלקים את הרשימה לתרחישים קריטיים ומשניים: עצימות הבדיקות ועוצמת ההתראות צריכות להתאים להשפעה האמיתית על התפעול והלקוחות.
3. סכמת בדיקות. לכל נקודה מתארים תרחיש: קוד תגובה, שרשרת הפניות, נוכחות מקטע מפתח בגוף התגובה, זמן תגובה, תוקף אישור. בודקים ממספר אזורים, כדי להבדיל בין כשל שירות לתקלת רשת במסלול.
4. ספי רגישות. מגדירים לא «שגיאה אחת — אזעקה», אלא סדרה של ניסיונות כושלים או שיעור כשלים בחלון; ספים נפרדים לאי-זמינות ולדעיכה בזמן תגובה.
5. ערוצי התראות. ניתוב לפי קריטיות: מהנדס תורן, צ'אט צוות, משימה במערכת ניהול. חובה איחוד חזרות ודיכוי כפילויות, אחרת תקלה אחת מייצרת עשרות הודעות והקשבה אליהן יורדת.
6. בדיקה להתראות שווא. מריצים בדיקות במצב צפייה, משווים לאירועים אמיתיים מהתקופה הקודמת, בודקים רעש בשעות לא-עבודה ובתחזוקה מתוכננת. פסקי זמן, חלונות וטקסטי הודעות מתקנים כאן, ולא אחרי האזעקה הלילית הראשונה.
7. העברה לתמיכה. מוסרים הוראות תורן: מה משמעות הפעלה, אילו שלבי אבחון, את מי לחבר. בנפרד מתעדים נוהל סקירת תרחישים בעת שחרורים ושינוי נקודות כניסה.

מה מעבירים יחד עם בדיקות מוגדרות

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

• סכמת כיסוי שירותים — אילו נקודות כניסה, תרחישי משתמש קריטיים ותלויות חיצוניות נבדקים, אילו קטעים הושארו בכוונה ללא בדיקות ומדוע.
• תצורות בדיקות — שלבי תרחיש, תדירות הרצה, נקודות הרצה מרשתות שונות, קודי תגובה צפויים וספים שאחריהם הבדיקה נחשבת לכושלת.
• הגדרות התראות — מסלולי התראות לפי תורנים, כללי קיבוץ הפעלות קשורות, דיכוי בזמן תחזוקה מתוכננת, שליחה חוזרת אם אף אחד לא אישר את האות.
• נוהל תגובה — מה נחשב לאירוע, מי מאשר את האות ובאיזה פרק זמן, באילו מקרים מנטרלים בדיקה זמנית כהתראת שווא ומי מקבל את ההחלטה.
• הוראות לתורן — פירוק שלב-אחר-שלב של הפעלה טיפוסית: מפתיחת דוח הבדיקה ועד הודעה לאחרים האחראים, הסלמה ורישום ביומן.
• תיעוד בדיקות — תיאור של כל תרחיש, הבעלים שלו, שיוך לשירות, סדר תיקון ספים והוספת בדיקות חדשות.
• העברת ידע לצוות — ניתוח על הפעלות אמיתיות, תשובות לשאלות על ספים שנויים במחלוקת, מתן הרשאות וחלוקת תפקידים.

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

מקרה בוחן: איך הסרנו התראות שווא והאצנו את התגובה

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

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

מה שינינו

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

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

מה השתנה

שיעור התראות השווא ירד מ-86% ל-7%, והרעש בהתראות הפסיק להיות רקע. זמן התגובה הממוצע לתקלה אמיתית הצטמצם מחצי שעה לשתיים-שלוש דקות: כעת מגיע אות אחד, המשויך לתרחיש משתמש מסוים, עם סדר פעולות מוכן לתורן. ניתוח האירוע אורך דקות במקום שעות — מהיסטוריית הבדיקות רואים מיד מה בדיוק נשבר ובאיזה שלב.

מה לעשות אם הבדיקות כבר מוגדרות אבל האותות חסרי תועלת?

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

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

כשל אמיתי מופרד מהרעש במעבר מבדיקות «התהליך מגיב» לתרחישי נתיב מקצה לקצה: כניסה, פעולה קריטית, החזרת תוצאה. התראות שווא נעלמות כשהתרחיש לא תלוי בשירות חיצוני אחד, יש לו מרווח בזמן ההמתנה והוא מורץ מכמה נקודות. את הרעש שנותר מטפלים באופן ממוקד — מתקנים סף או מסירים בדיקה, ולא משתיקים את הערוץ.

תורנויות והסלמה מוגדרות לפי שירותים: ההתראה מגיעה למי שיכול לתקן, עם חלונות שקט לתחזוקה מתוכננת וכלל «לא אישר — עבר גבוה יותר בשרשרת». אז אות לילי הופך לעילה לפעולה, ולא לרקע.

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

ספקות ומגבלות: מה חשוב לקחת בחשבון מראש

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

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

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

האם כדאי לבדוק תרחישים עם התחברות?

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

בדיקות פנימיות וחיצוניות — מה לבחור?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

• רשימת שירותים ונקודות כניסה שזמינותם חשובה, עם סימון קריטיות: מה יכול להיות מושבת שעה, ומה לא צריך ליפול בכלל;
• תרחישי משתמש שצריך לבדוק במלואם — כניסה, חיפוש, השלמת הזמנה, תשלום, תגובת ממשק חיצוני;
• כיצד נודע לכם על תקלה כעת — תלונות, תורן, מערכת נפרדת — וכמה זמן עובר עד לאות;
• היכן ממוקמים השירותים ומאילו רשתות צריכות לצאת הבדיקות, כדי לראות את התמונה מבחוץ, ולא רק מבפנים;
• דרישות להרשאות, אופן אישורים וחלונות עבודות תחזוקה, כדי שהבדיקות לא יעירו את התורן בתחזוקה מתוכננת;
• סדר פתיחה צפוי: פיילוט על מתאר קריטי אחד או מיד כל רשימת השירותים.

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