ניפוי שגיאות בתנאי שטח ובסביבת הייצור

24 באוגוסט 2016

אין תגובות

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

Application has encountered a problem

סביבת הלקוח, או כפי שאני קורא לה סביבת הייצור, אינה סביבה ידידותית למפתח. על מחשבי הלקוח לא מותקן Visual Studio ואתה לא יכול להתחבר לתכנה עם Debugger ולעשות Break ו Single Step כדי לבדוק ערכי משתנים או את ה Call Stack. מה שיותר גרוע (לפחות בעיני המפתח) זה שסביבת הייצור מנוהלת על ידי אנשי IT ו Help Desk שאין להם מושג ירוק בשפת תכנות “נורמאלית”, תכנות זה בכלל לא מה שמעניין אותם והדבר האחרון שהם יתנו למפתח זה להתקרב ל Console ולתת פקודות שיכולות להשפיע על המערכת.

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

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

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

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

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

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

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

כתיבת תגובה

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