זה עתה סבלתי מתקלה של XFONE, בה חיבור האינטרנט שלי נעלם למשך שעה בערך. לא היה אפשרי להתחבר, לא היה אפשר בכלל לדעת שיש תקלה.
- אם השרת רץ על VM, תבצעו לו רפליקציה כ-Virtual Machine נוסף, כאשר המקור ממשיך לעבוד.
- אם השרת מחובר ל-DB כלשהו, שכפלו את ה-DB ושנו את ההגדרות בשרת החדש שיצרתם עתה מהשכפול.
- אם אין אפשרות לשנות כתובות IP, הפקידו את השרת + השרת העתק של ה-DB ל-VLAN נפרד או שתבצעו במתג Forward אוטומטי לזוג כתובות אחרות, כל חברה והתשית/נהלים שלה.
- בצעו את העדכון ותנסו לבצע מספר סימולציות של חיבורי משתמשים/תוכנות שאמורות לקבל שרות. לא להסתפק ב-Client שמותקן לכם על הלאפטופ (חוקי מרפי אומרים שיש לכם Client מעודכן וחצי מהמשרד – לא)
- "הקפיאו" את מכונת הפרודקשן ותנו לגירסה ששכפלתם לקבל Clients חדשים וישנים (אם הם זקוקים לחיבור חדש). לחלופין, אם אתם עובדים ב-Cluster, עדכנו שרת שני, ולאחר עדכון ובדיקה מוצלחת, הורידו את הראשון כך שה-LB יזרוק את הפניות לשרת המעודכן.
- רק לאחר שהכל עובד, עדכנו את השרת פרודקשן הראשי, לא לפני כן.
תזכרו: תמיד תשמרו בצד Snapshot של השרת, Snapshot של ה-DB (אין מקום? תרימו שרת ZFS עם ערימות דיסקים SATA + דיסק אחד קטן SSD) עוד לפני שאתם מעדכנים את התוכנה בשרת פרודקשן חי ורץ. לצערי יצרני תוכנה רבים לא עושים מספיק טסטים (ראיתי כבר מספר מקרים עם אורקל ישראל כדי לחוות פאקים, לדוגמא) לפני שהם מתלבשים על השרתי פרודקשן לעדכן.
בהצלחה
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.
אם הייתי צריך לעשות את התהליך הזה כל פעם שאני מתקין עדכון, הייתי צריך לשלש את מחלקת הIT שלי
אפשר לבנות מערכת במעבדה שתבחן עדכונים לפני שהם מופצים הלאה. נכון שזה לא בדיקה של 100% אבל תהליך כמו שתיארת מתאים רק למקרים קריטיים שבקריטיים
למיטב ידיעתי לסביבת Exchange אין סיבולת לגיבויי Snapshot… אחת כמה וכמה להחזרה של שרת שעודכן לעותק שלא עודכן… שלא נדבר על AD…