אבחון תקלה טוב מתחיל בבידוד משתנים

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

מנסחים את הסימפטום בלי לפרש אותו

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

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

יוצרים קו בסיס שאפשר לחזור אליו

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

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

משנים דבר אחד בלבד

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

מהירות אינה מספר הפעולות שביצענו; מהירות היא כמה מהר צמצמנו את מרחב האפשרויות.

משתמשים ברכיב שידוע כתקין

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

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

מבדילים בין התאמה זמנית לבין תיקון

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

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

התיעוד צריך להיות קצר ושימושי

אין צורך בדוח ארוך. חמש שורות מסודרות מספיקות ברוב המקרים:

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

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

מתי עוצרים ומסלימים

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

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