בעקבות התקלה שהיתה בשבוע החולף באחד הבנקים הגדולים, רציתי להתייחס לנושא ה- DRP* , אך מזוית שנוטים להתעלם ממנה – היבט DRP בסביבות הפיתוח.
חוסר ב- DRP בסביבת הפיתוח יכול לגרום להשבתת עבודת הפיתוח, לאיחור בשחרורי גירסאות ובמסירת המוצר ללקוחות.
כבר יצא לי להתקל בכמה חברות בהן נושא ה-DRP תוכנן לעילא ולעילא עבור סביבות הייצור (Production), אך עם התייחסות מינורית לסביבות הפיתוח.
בדומה ל- DRP בסביבות יצור, פתרון כזה יכול להיות החל מהעתקת (גיבוי) המידע אל דיסק אחר, עובר בהחזקת שרת זהה כגיבוי, ועד לאתר גיבוי מלא הכולל העתק מלא של כל הסביבה (חומרה ותוכנה), וכן סנכרון אוטומטי אל סביבת הגיבוי.
נקודות דמיון נוספות: תחזוקה מונעת; תיעוד הקשרים למערכות מידע אחרות ; הגדרת נהלים ברורים לאופן הפעולה במקרה של אסון. חשוב להגדיר סדר פעולות ותחומי אחריות של הגורמים בארגון.
בסופו של דבר זהו ענין כספי: המשמעות הכספית של המידע שעלול להעלם והאובדן הכרוך בכך, והתקציב העומד לרשות הארגון לצורך מניעת האסון.
בשונה מ- DRP לסביבות יצור, בסביבות הפיתוח יש לתת התייחסות לכלי העזר בפיתוח התוכנה – כוונתי לאותם כלים ומערכות המשמשים את אנשי הפיתוח. התייחסות נכונה לכלים אלה תאפשר זמן התאוששות קצר, וחזרה מהירה לעבודה.
בנוסף – יש להגדיר נוהל ברור לכל עובדי הארגון הקשורים לסביבות הפיתוח, ובו סדר פעולות הנוהגות במקרה זה.
דוגמא ליישום חלקי של DRP בסביבות פיתוח, הדורש שיפורים:
רבים מהארגונים מסתפקים בגיבוי פשוט אחת (בד"כ כל לילה), אך לא תמיד זהו פתרון מספק. מה בנוגע לדלתאות, דהיינו זמני ההפרש בין הגיבוי האחרון לבין זמן האסון? מה בנוגע לקשרים וסנכרון למערכות מידע משיקות? מה בנוגע לסביבות העבודה הפרטיות של משתמשי הקצה?
באחד מהפוסטים הבאים כוונתי להתייחס לתכנון התאוששות מאסון בהיבט ספציפי למוצרי ניהול תצורה ושינויים: IBM Rational ClearCase ClearQuest , Subversion ו- Bugzilla .
גילוי נאות: החברה בה אני עובד, נותנת שירותי DRP עבור מערכות המידע של IBM Rational.
=======================================
*DRP – Disaster Recovery Plan – דהיינו: תוכנית תכנון להתאוששות מאסון ולהמשכיות עסקית במקרה של אובדן מידע ומשאבים.
תמיר גפן על ניהול תצורה ומחזור חיי תוכנה 