...וגם בלתי אפשרי לשחזר. למשל במהלך בדיקות עומסים שבסה"כ חוזרות על עצמן והבעיה אינה פונקציונלית.
אני מתכוון למערכות מורכבות בעלות שרתים רבים כאשר נניח שרת אחד נופל או אפליקציה או קומפוננטה בו נופלות ולא ברור למה, ומן הסתם זה קורה במהלך בדיקות של גרסה גדולה חדשה. הרבה פעמים מצאתי שאנשים טובים ומקצועיים פשוט מסתכלים אחד על השני בחוסר אונים... אז הנה כמה פעולות גנריות שכדאי לבצע, לפי סדר שעושה לכם שכל:
1. כניסה לדיבאג מוד לאפליקציות / קומפוננטות "החשודות". כלומר האפליקציה מכניסה לקובץ הערות רלונטיות במהלך פעילותה. אם היא נופלת אז פותחים את הקובץ ומתחילים לחקור.
יתרונות: במקרה הטוב מיד ניתן לעלות על הבעיה.
חסרונות: שימוש במשאבים לצורך הכנת הדיבאג, אח"כ מתברר שאין את כל הפרטים הרלוונטיים, שוב משאבים ושוב הרצות וכיוצא באלה. לפעמים הבעיה אינה עקבית וצריך לחכות כמה ימים. ולבסוף, מניסיון - ותסלחו לי שאני עובר לתחום המיסטי - תמיד זה יעבוד טוב עם הדיבאגר. אולי כי הוא מעט את התהליך או גורם לשינוי זה או אחר בקוד או בהרצה שלו.
2. הכנת דאמפ. בעת קריסת האפליקציה, המחשב מכניס לקובץ את המידע שיש לו בזיכרון השייך לאפליקציה http://en.wikipedia.org/wiki/Core_dump.
יתרונות: במקרה הטוב מיד ניתן לעלות על הבעיה.
חסרונות: לפעמים המחשב קורס ללא הדאמפ, לפעמים הוא ענק ולא ניתן למצוא בו ידיים ורגליים, ולפעמים הבעיה אינה עקבית וצריך לחכות כמה ימים.
3. חזרה אחורה בגרסאות של האפליקציה / קומפוננטה החשודה.
יתרון: ייתן להבין שהבעיה בדלתה שבין הגרסאות.
חסרון: עדיין לא יבהיר מהי הבעיה.
4. אם אכן זה קורה בעומס - הוצאת תסריט אחר תסריט מתוכנית ההרצה עד שיהיה ניתן להבין איזה תסריט אחראי לבעיה.
זה בעייתי מאוד כי זה דורש הרבה זמן עד למציאת הבעיה אם בכלל. ייתכן שהבעיה תפסיק לא כי תסריט X הוצא ממנה אלא כי העומס הכללי ירד.
כשמשהו לא הולךכשמשהו לא הולך
5. ישיבת "סיעור מוחות" עם המומחים הטובים ביותר של החברה, TIER 4 של התמיכה והמפתחים עם רשימה מלאה של שינויים שנעשו הגרסה, כולל שידרוגי מערכות הפעלה, שינויים ברשת וכד'.
6. הרבה פעמים הפיתוח מאשים את אנשי הרשת ולהיפך או את אנשי הסיסטם. לשלול בעיות רשת וחומרה הייתי מבצע אודיט מקיף למערכת (בכלל חשוב לפני כל גרסה גדולה).
7. האם אפשר למצוא מכנה משותף לבעיות, למשל שעה מסוימת שבה התקלה מתרחשת (ואז: האם יש אפליקציות שרצות על מערכת ההפעלה או על המערכת שלך בשעה זו).
8. לנסות להרחיב את המקורות העלולים לגרום לתקלה: אולי יש פגם בהארד דיסק או איזה קונטרולר סורר, שדרוג למערכת ההפעלה וכד'.
9. מעבר על כל פרט שנכנס לגרסה - פיתוח, באגים.
אם הגעתם לכאן אז המצב קשה. נסו להתקין במעבדה אחרת, עשו קוד רוויו...
אני מתכוון למערכות מורכבות בעלות שרתים רבים כאשר נניח שרת אחד נופל או אפליקציה או קומפוננטה בו נופלות ולא ברור למה, ומן הסתם זה קורה במהלך בדיקות של גרסה גדולה חדשה. הרבה פעמים מצאתי שאנשים טובים ומקצועיים פשוט מסתכלים אחד על השני בחוסר אונים... אז הנה כמה פעולות גנריות שכדאי לבצע, לפי סדר שעושה לכם שכל:
1. כניסה לדיבאג מוד לאפליקציות / קומפוננטות "החשודות". כלומר האפליקציה מכניסה לקובץ הערות רלונטיות במהלך פעילותה. אם היא נופלת אז פותחים את הקובץ ומתחילים לחקור.
יתרונות: במקרה הטוב מיד ניתן לעלות על הבעיה.
חסרונות: שימוש במשאבים לצורך הכנת הדיבאג, אח"כ מתברר שאין את כל הפרטים הרלוונטיים, שוב משאבים ושוב הרצות וכיוצא באלה. לפעמים הבעיה אינה עקבית וצריך לחכות כמה ימים. ולבסוף, מניסיון - ותסלחו לי שאני עובר לתחום המיסטי - תמיד זה יעבוד טוב עם הדיבאגר. אולי כי הוא מעט את התהליך או גורם לשינוי זה או אחר בקוד או בהרצה שלו.
2. הכנת דאמפ. בעת קריסת האפליקציה, המחשב מכניס לקובץ את המידע שיש לו בזיכרון השייך לאפליקציה http://en.wikipedia.org/wiki/Core_dump.
יתרונות: במקרה הטוב מיד ניתן לעלות על הבעיה.
חסרונות: לפעמים המחשב קורס ללא הדאמפ, לפעמים הוא ענק ולא ניתן למצוא בו ידיים ורגליים, ולפעמים הבעיה אינה עקבית וצריך לחכות כמה ימים.
3. חזרה אחורה בגרסאות של האפליקציה / קומפוננטה החשודה.
יתרון: ייתן להבין שהבעיה בדלתה שבין הגרסאות.
חסרון: עדיין לא יבהיר מהי הבעיה.
4. אם אכן זה קורה בעומס - הוצאת תסריט אחר תסריט מתוכנית ההרצה עד שיהיה ניתן להבין איזה תסריט אחראי לבעיה.
זה בעייתי מאוד כי זה דורש הרבה זמן עד למציאת הבעיה אם בכלל. ייתכן שהבעיה תפסיק לא כי תסריט X הוצא ממנה אלא כי העומס הכללי ירד.
כשמשהו לא הולךכשמשהו לא הולך
5. ישיבת "סיעור מוחות" עם המומחים הטובים ביותר של החברה, TIER 4 של התמיכה והמפתחים עם רשימה מלאה של שינויים שנעשו הגרסה, כולל שידרוגי מערכות הפעלה, שינויים ברשת וכד'.
6. הרבה פעמים הפיתוח מאשים את אנשי הרשת ולהיפך או את אנשי הסיסטם. לשלול בעיות רשת וחומרה הייתי מבצע אודיט מקיף למערכת (בכלל חשוב לפני כל גרסה גדולה).
7. האם אפשר למצוא מכנה משותף לבעיות, למשל שעה מסוימת שבה התקלה מתרחשת (ואז: האם יש אפליקציות שרצות על מערכת ההפעלה או על המערכת שלך בשעה זו).
8. לנסות להרחיב את המקורות העלולים לגרום לתקלה: אולי יש פגם בהארד דיסק או איזה קונטרולר סורר, שדרוג למערכת ההפעלה וכד'.
9. מעבר על כל פרט שנכנס לגרסה - פיתוח, באגים.
אם הגעתם לכאן אז המצב קשה. נסו להתקין במעבדה אחרת, עשו קוד רוויו...
