צוות שסיפק סביבת הרצה (runtime) של Python בגודל 5.5MB לדפדפנים גילה כי 69% מהשגיאות שנרשמו במהלך ספרינט (sprint) אחרון נכללו תחת כותרת אחת מטעה, ו-89% מהן היו למעשה פקיעת זמן תקשורת (network timeouts). הדיווח השגוי הוביל את המפתחים לנתיב ניפוי שגיאות (debugging) שגוי והותיר חלק ניכר מהמשתמשים עם כשלים שקטים בהורדה – בעיה שכל אפליקציית ווב (web-app) המאגדת נכסים (assets) גדולים עלולה לחזור עליה בקרוב.

לוח הבקרה הטעה

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

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

ה-API של חיבור הדפדפן סיפק ערך זמני (placeholder)

כדי להימנע מהאטת משתמשים איטיים במהלך הורדה של 5.5MB, המפתחים נעזרו ב-Network Information API של הדפדפן (navigator.connection). ה-API דיווח על רוחב פס קבוע של 1.7Mbps עבור כל מבקר חדש.

דפדפנים מחזירים ערך ברירת מחדל כאשר אין להם נתונים היסטוריים עבור משתמש חדש. ערך ברירת המחדל הזה הוא רק רמז, לא מהירות מוחלטת. כאשר אותו ערך זמני מופיע בכל סשן (session) חדש, זה מאותת שה-API טרם כויל (calibrated) עבור קהל זה.

לקח חשוב: התייחסו לכל אות רשת שאינו משתנה לעולם כאל ברירת מחדל (fallback), ולא כמדד מוחלט.

צילומי מצב חד-פעמיים אינם אמינים

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

לקח חשוב: אל תבססו פעולה קבועה על קריאה בודדת של יעד משתנה. עדיף להירשם לאירועי שינוי (subscribe to change events) במקום לבצע polling חד-פעמי.

תיקונים מעשיים שהצוות יישם

  • הרשמה לשינויים בחיבור. במקום לקרוא את navigator.connection פעם אחת, הקוד מאזין כעת לאירוע ה-change ומגיב אם רוחב הפס יורד או עולה במהלך ההורדה.
  • הוספת "כלב שמירה" (watchdog) למניעת חוסר התקדמות. טיימר מבטל כל בקשה שאינה מתקדמת לאחר מרווח זמן קצר, מה שמאפשר לדפדפן לנסות שוב או לעבור לשיטת גיבוי.
  • הפסקת החלפת CDNs באמצע הורדה. החלפת מקור של קובץ גדול בקישור איטי גורמת להתחלת ההעברה מחדש, מה שמבזבז בתים שכבר התקבלו. ההורדה נשארת מחוברת ל-CDN שנבחר בתחילה לאורך כל משך הפעולה.
  • דחיית עבודות מטמון (caching) כבדות. משימות שכותבות כמויות גדולות של נתונים למטמון נדחות עד לאחר סיום טעינת סביבת ההרצה, כדי לשמור על נתיב קריטי קצר.

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