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

קרה לכם? ברור. בואו נרשום לקחים:

1. לא להילחץ. המטרה הראשונה שלנו היא לגרום לבעיה להופיע גם על שרת הבדיקות, שם אפשר לשבור דברים ויש לנו יותר מקום למשחק.

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

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

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

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

6. לפעמים יש לנו תוספים או תוכנות שהתקנו בסביבה אחת ושכחנו מהם. אפשר להשתמש ב:

   apt list --installed
   

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

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

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