מה זה Production Time Debugging ואיפה לומדים את זה

10 בדצמבר 2014

אין תגובות

את המונח Production Time Debugging אני טבעתי לפני יותר מעשור בהרצאה באירוע ענק של מיקרוסופט שאני כבר לא זוכר איפה הוא התרחש ובשני Webcast – ים על הנושא ששודרו מאזור התחנה המרכזית הישנה מהבניין של חברת Interwise (היום חלק מ AT&T בקריית שדה התעופה) כאשר יוסי תאגורי הזכור לטוב (אז במיקרוסופט וכיום אי שם בעולם היזמות) מסייע לי בכל שלב (בעיקר בהזמנת הפיצה למי שענה נכון על השאלות).

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

אבל לא על זה רציתי לדבר ברשומת הרשת הזו, אלא על ההגדרה המדויקת של מה זה Production Time Debugging. ומה שיותר חשוב, מה זה לא (רמז, זה לא Advanced debugging ולא NET Internals). 

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

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

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

הבעיה היא שיש בעיות ותקלות שמופיעות אך ורק בסביבת הייצור ולא ניתן לשחזר אותם בסביבת הפיתוח או בסביבת ה QA. וזה בדיוק הרגע שבו Production Time Debugging נכנס לפעולה. הוא נותן פתרון לשאלות כמו איזה כלים ניתן להפעיל בסביבת הייצור מבלי להפריע לפעילות השוטפת ?  מה ההשפעה של כל כלי על המערכת ? איזה מידע ניתן לאסוף בטכניקות לא הרסניות ? איך מנתחים את המידע הזה (Offline כמובן) ומוציאים ממנו מה הבעיה ? ואיך מתרגמים את כל התובנות הללו לשפה שמובנת למפתחים כך שיוכלו לתקן את הבעיה ?.

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

אם כל הנושא הזה מעניין אותך אז ב 1-3/3/15 אני מעביר סדנה של שלושה ימים על Production Time Debugging שכוללת בתוכה כלים, טכניקות, ותרגול פרקטי המבוסס על הניסיון שלי בתחום. זה מכרה זהב של ידע לכל מי שרוצה לדעת איך להתמודד עם האילוצים של סביבת הייצור ואיך לשפר ולייעל באותה הזדמנות גם את סביבת ה QA בארגון שלו. פרטים נוספים ניתן למצוא בקישור הבא. כמו תמיד יש הנחות משמעותיות למקדימים (Early Bird), נצלו אותה.  

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *