המדריך המקוצר איך לא לדפוק את עצמך כאיש IT

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

תקלות כמובן יכולות לקרות, במיוחד שעדכונים שוברים לפעמים אפליקציות קריטיות או מערכות הפעלה שלמות (אהלן מיקרוסופט, ששברו עדכון ל-Exchange 2010 עם SP3 ובשבוע שעבר הצליחו לחסום עדכונים של כל צד ג' כולל עצמם ע"י שחרור טלאי דפוק), ולכן כדאי לעשות את הצעדים הבאים שכל איש IT שמכבד את עצמו אמור לדעת בעל פה. קחו זאת רק כתזכורת:

  • אם השרת רץ על VM, תבצעו לו רפליקציה כ-Virtual Machine נוסף, כאשר המקור ממשיך לעבוד.
  • אם השרת מחובר ל-DB כלשהו, שכפלו את ה-DB ושנו את ההגדרות בשרת החדש שיצרתם עתה מהשכפול.
  • אם אין אפשרות לשנות כתובות IP, הפקידו את השרת + השרת העתק של ה-DB ל-VLAN נפרד או שתבצעו במתג Forward אוטומטי לזוג כתובות אחרות, כל חברה והתשית/נהלים שלה.
  • בצעו את העדכון ותנסו לבצע מספר סימולציות של חיבורי משתמשים/תוכנות שאמורות לקבל שרות. לא להסתפק ב-Client שמותקן לכם על הלאפטופ (חוקי מרפי אומרים שיש לכם Client מעודכן וחצי מהמשרד – לא)
  • "הקפיאו" את מכונת הפרודקשן ותנו לגירסה ששכפלתם לקבל Clients חדשים וישנים (אם הם זקוקים לחיבור חדש). לחלופין, אם אתם עובדים ב-Cluster, עדכנו שרת שני, ולאחר עדכון ובדיקה מוצלחת, הורידו את הראשון כך שה-LB יזרוק את הפניות לשרת המעודכן.
  • רק לאחר שהכל עובד, עדכנו את השרת פרודקשן הראשי, לא לפני כן.

תזכרו: תמיד תשמרו בצד Snapshot של השרת, Snapshot של ה-DB (אין מקום? תרימו שרת ZFS עם ערימות דיסקים SATA + דיסק אחד קטן SSD) עוד לפני שאתם מעדכנים את התוכנה בשרת פרודקשן חי ורץ. לצערי יצרני תוכנה רבים לא עושים מספיק טסטים (ראיתי כבר מספר מקרים עם אורקל ישראל כדי לחוות פאקים, לדוגמא) לפני שהם מתלבשים על השרתי פרודקשן לעדכן.

בהצלחה

Print Friendly, PDF & Email

3 תגובות בנושא “המדריך המקוצר איך לא לדפוק את עצמך כאיש IT”

  1. There are so many other ways to avoid or minimise down time – e.g. build a proper build-deploy chain which tests things automatically before putting them in production. Test backups regularly. Test DR plan in general regularly. Do all deployment process using automatic tools (puppet and friends), etc.

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

  3. למיטב ידיעתי לסביבת Exchange אין סיבולת לגיבויי Snapshot… אחת כמה וכמה להחזרה של שרת שעודכן לעותק שלא עודכן… שלא נדבר על AD…

כתיבת תגובה

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

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