הגדרת ניטור סינתטי: איתור בעיות נסתרות באתר

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

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

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

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

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

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

מה נותנת סימולציה של פעולות משתמש לפי לוח זמנים

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

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

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

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

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

מצבי ניטור סינתטי: זמינות, נקודת כניסה, דפדפן

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

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

תדירות ההרצות והגיאוגרפיה של הבדיקות

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

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

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

איך אנחנו בונים בדיקות: מאינבנטריזציה עד מסירה

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

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

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

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

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

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

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

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

מה נשאר בפרויקט לאחר הגדרת הבדיקות

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

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

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

מקרה בוחן: תקלות תשלום נסתרות באתר קטלוג

תקלה שלא הופיעה במדדי השרת

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

עם זאת, התמיכה קיבלה מדי שבוע פניות «התשלום עבר, אין הזמנה», וכל אחת מהן צפה לאחר 4–11 שעות מתחילת התקלה — כשכבר נפגעו עשרות קונים.

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

מה הגדרנו ומה השתנה

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

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

מדדים לפני ואחרי: זמן עד גילוי תקלות — מ-4–11 שעות ל-2 דקות, שיעור התשלומים האבודים בשעות שיא — מ-3–5% ל-0.2%, שיעור התרחישים שמגיעים עד הסוף — 99.8%. התורן מקבל התראה עם מספר השלב הכושל, צילום מסך ומעקב בקשות, לכן שחזור התרחיש דורש ניתוח אחד, ולא חיפוש סיבה בעיוורון. אותו תרחיש מורץ לאחר כל שחרור — רגרסיה בשלב התשלום נראית לפני שק�ונים כותבים עליה.

במה בדיקות סינתטיות נבדלות מנתוני מבקרים אמיתיים?

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

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

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

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

ספקות טכניים לפני הפעלת בדיקות

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

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

איך בודקים אזורים סגורים שבהם נדרש אימות?

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

לאן מגיעות ההתראות ומי מטפל בהן?

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

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

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

בתגובה נשלח תוכנית שלפיה נמשיך:

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

תארו את המשימה — נחזור עם הערכה ותוכנית בדיקות.