בלוגיקה

על כישוף טוב ומאגיה רעה

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

בעולם תקשורת הנתונים והטלפוניה, בדיוק כמו בעולם המחשבים, קיימת תופעה שאני (ולא רק אני, אני לא מתיימר למקוריות כאן) מכנה "וודו". וודו הן שורה של פעולות לפתרון או מניעת תקלות, שלכאורה לא אמורות לפתור את התקלה כלל ועיקר, כי אין ביניהן לבין התקלה כל קשר - ובכל זאת, לפעמים הן עובדות. לפעמים לוודו יש מקור בעבר - הדוגמה הבולטת היא המנהג לפרוק סוללה של מחשב נישא אחת לכמה זמן (שנובע מזה שבעבר לסוללות ליתיום היה "זיכרון" שפריקה של הסוללה איפסה). לפעמים יש לו נימוק הגיוני ותקף, אבל רק במקרים מסוימים מאד - דוגמה טובה מתחום הטלפוניה היא פעולת הניתוק של כבל טלפון לכמה דקות כדי לפתור תקלה של טלפון שלא מקבל קו. אחד מהמקרים (די נדירים בשימוש ביתי, קורים לא אחת עם קופסאות קוד אודיו ו/או כרטיסי דיאלוג'יק) הוא כאשר שיחה לא נותקה כמו שצריך וממשיכה לחסום את הקו - במקרה כזה ניתוק של הטלפון מהקו למשך חמש דקות פותר את התקלה, מסיבות שלא נכנס אליהן כאן.
בגלל שהוודו הוא לעתים קרובות פעולה קלה לביצוע, פעמים רבות מכניסים אותו בשלב הראשון של פתרון תקלות, מתוך מחשבה שאם זה עובד - חסכנו עבודה, ואם לא - לא בזבזנו זמן רב ומאמץ. דוגמה להליך פתרון תקלות "מכושף" כזה אפשר למצוא אם מתקשרים ל"סלקום" (ואולי גם למפעילים האחרים, אינני יודע) עם תקלה טכנית בטלפון הסלולרי. במסגרת הפעולות הראשונות שלהם תהיה גם הוצאת הסוללה והחזרתה. אין לזה (כמעט) שום אפקט, אבל בכל זאת - זה לא דורש מאמץ.
ובמצבים האלה, אין בוודו שום דבר רע. כשלא מועיל (ובדרך כלל, לא מועיל) הוא לא מזיק, מחד, ומנגד, במקרה של תקלה נדירה - הוא יכול לספק פתרון מהיר למקרה שלא היה נפתר אחרת. (לפריקה מלאה של סוללת ליתיום דווקא יש נזק, כי מתווסף לה מחזור טעינה, אבל זה נזק לא גדול). הוודו הופך למאגיה רעה כשאנשים מתחילים לייחס תכונות אנושיות או מאגיות לתוכנות ומכשירים, והליך קבלת ההחלטות שלהם בפתרון תקלות מושפע מזה.
פתרון תקלות בכל תחום, ובייחוד כשמדובר במערכות מורכבות, צריך להיעשות בצורה מושכלת, שיטתית ומסודרת. לכל תקלה יש הסבר, גורם ופתרון, או לכל הפחות workaround, שבנוי מנטרול או עקיפת גורם התקלה. לתקלות שתוצאתן זהה (כלומר, הן מתבטאות באותה הצורה עבור המשתמש) יכולים להיות גורמים שונים (ולכן הן לא אותה תקלה), ולכן הליך פתרון תקלות נכון לוקח בחשבון כמה דברים - כמה נפוצה כל סוג של תקלה, כמה זמן לוקחת כל בדיקה ואילו פעולות ניתן לעשות כדי לקבל מידע נוסף על אופי התקלה.
הנה דוגמה לתקלה והליך של פתרון: אחת מאפליקציות הטלפוניה שאנחנו עושים בה שימוש במוקדים טלפוניים מקפיצה מסך עם הפרטים של איש הקשר אצל הטלפן שעושה את השיחה ברגע שהחייגן מצליח להקים שיחה. על המסך הזה הטלפן יכול לעדכן את פרטי איש הקשר (במידה והם השתנו) ולעדכן את תוצאת השיחה - האם היא הסתיימה במכירה, האם איש הקשר אינו מעוניין, או קביעה של שיחה נוספת במועד אחר. נניח שעבור פרוייקט מסוים, חדש, המסך לא עולה. יכולות להיות לכך מספר סיבות - ייתכן שמי שהקים את הפרוייקט לא העלה את המסכים לסביבת העבודה, ייתכן שלא התבצע חיבור בין הפרוייקט לבסיס הנתונים, ייתכן שלפרוייקט לא הוגדר מהיכן לשלוף את המסכים וייתכן שיש תקלה בסביבת העבודה, למשל, שאחד משרתי האפליקציה נפל. האפשרות האחרונה היא הקלה והמיידית ביותר לבדיקה - אם האפליקציה עובדת בפרוייקטים אחרים, סביר שאין תקלה בסביבת העבודה. שתי הפעולות המהירות ביותר לביצוע (וכיוון שטלפנים יושבים ולא יכולים לעשות שיחות, זמן הוא בהחלט חשוב) הן בדיקה של הגדרות הפרוייקט, ולכן שני הדברים הבאים שאבדוק יהיו חיבור בין הפרוייקט לבסיס הנתונים ושלפרוייקט הוגדר המיקום הנכון לשלוף ממנו את המסכים. במידה ושתי הפעולות האלה צלחו, אנסה להעלות מחדש (או לא) את המסכים לסביבת העבודה, פשוט כי זה הליך ארוך יותר. במקרה של האפליקציה שאנחנו משתמשים בה בעבודה יש גם וודו - עצירה והפעלה מחדש של הפרוייקט - שלא אמור לפתור את התקלה, למעט מקרה אחד, חריג מאד (תקלה בשליפה ראשונית של הנתונים, כתוצאה מכשל זמני בבסיס הנתונים. אני ראיתי את זה קורה רק פעם אחת). כיוון שזו פעולה פשוטה, היא תכנס באיזשהו שלב של התהליך, במקביל לפעולה אחרת.
מה שאני לא אעשה זה מה שעשה חבר חדש בצוות שלי לפני אי אלו חודשים - הקמה מחדש במערכת של כל אחד מהטלפנים (כ-30). זו פעולה שמתנוססים מעליה שלושה דגלים אדומים. הראשון והחשוב ביותר הוא שאין שום קשר בין ההגדרות של הטלפן (שנמצאות על אפליקציה אחרת) לבין האפליקציה שמקפיצה את המסכים. הפעולה הזו מעידה על חוסר הבנה של האופן בו המערכת בנויה. השני, חשוב אף הוא, הוא שההסתברות שההגדרות של שלושים טלפנים אקראיים שבמקרה עובדים על אותו פרוייקט, ורק שלהם, השתבשו הוא אפסי. השלישי נוגע לשיטתיות של פתרון תקלות - הקמת שלושים טלפנים חדשים במערכת היא פעולה שגוזלת זמן רב, ולכן, גם אם לא היו קיימים הדגלים האדומים האחרים, עדיין אין טעם לנסות אותה כמוצא ראשון.
הנימוק של אותו עמית היה "חשבתי שהמערכת השתגעה, ומשהו השתבש בהגדרות שלהם". זה ניסוח מאגי לחלוטין - מערכות לא משתגעות, בני אדם משתגעים. למערכות יש באגים ותקלות. גם הנימוק של "משהו" השתבש הוא בעייתי - חשוב מאד להגדיר מהו השיבוש שאנחנו מחפשים לפני שמתחילים לחפש אותו.
איך נמנעים מחשיבה וודואית? אין לי תשובה. הדבר החשוב ביותר הוא היכרות טובה עם המערכת שעובדים אתה. היכרות כזו תשלול על הסף "פתרונות" שאין בהם טעם. הדבר השני, לדעתי, הוא קבלת החלטות שקולה ושיטתית בפתרון תקלות - כזו שמגדירה, קודם כל, מהם הגורמים האפשריים לבעיה ואז יוצאת ובודקת אם הם באמת מתקיימים. אשמח לשמוע, בתגובות, רעיונות נוספים למניעת חשיבה של רופאי אליל.