מה חייבים להוסיף ליישום בזמן הפיתוח כדי לאתר מהר יותר למה הוא מתעופף בשטח

19 בספטמבר 2016

אין תגובות

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

Card

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

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

לטפל בבעיה בשטח הרבה יותר קשה ומורכב מאשר בסביבת הפיתוח וה QA. בשטח אין Visual Studio, אין BreakPoint ואין Live Debugging. בשטח אי אפשר לעשות Restart כאשר יש לך כמה מאות לקוחות מחוברים לשרת ולספוג את כל הטלפונים הזועמים על זה שנמחקה להם כל העבודה שלא נשמרה עדיין. אבל על זה כבר דיברתי מספיק ברשומת רשת קודמת.

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

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

התשתיות האלה אינן תיאורטיות. הן פעילות כל הזמן ואוספות מידע שוטף על מערכת ההפעלה. הם פעילות בכל שרתי הישומים של מיקרוסופט כולל מערכות שלמות כמו IIS, Exchange ו SQL. הם פעילות בכל היישומים של מיקרוסופט כולל כל המרכיבים של  Office ובהרבה מוצרים אחרים כמו Media Player ו IE.

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

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

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

שילוב היישום שלך בתשתיות האיסוף המובנות של Windows מחייב בשלב הראשון ניתוח של הארכיטקטורה ואיתור המקומות הנכונים שבהן כדאי לשים נקודות בדיקה (Test Points). יש מתודולוגיה ברורה לתהליך הזה ואם יש לך תרשים ברור של הארכיטקטורה מאד קל להוציא ממנו את מיקום נקודות הבדיקה. לאחר איתור נקודות הבדיקה יש לאפיין את אופי זרימת המידע בנקודות האלה וזה תהליך פשוט. בהתאם לאופי זרימת המידע, תיבחר התשתית המתאימה להתחברות לאותה נקטודת בדיקה: ETW,  Perf Counters, Diagnostic event logger וכו’ (דרך אגב, Diagnostic Event Logger זה לא ה Event Log הרגיל שאתם מכירים).

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

למי שמעוניין להכיר יותר לעומק את הנושא, ואין לו זמן מיותר, אני מעביר ב 30/11/16 Crash Course על הנושא. זה יום אחד, פרקטי, מרוכז ודחוס, עם הרבה מתודולוגיה ותרגול מעשי. שבו אני מלמד, על בסיס תרחישים מהשטח, את הכלים והטכניקות שמאפשרים למפתחים, מנהלי פיתוח וראשי צוותי פיתוח, לשלב את היישום שלהם בתשתיות האיסוף המובנות של מיקרוסופט. כל הדוגמאות והתרגולים מבוססים על עבודת השטח שלי ויהיו גם המון טיפים וטריקים שימושיים.

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

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

כתיבת תגובה

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