עוד על סביבות פיתוח ובדיקה Testing enviroments

ישנם מספר מופעים של כל סביבה (פיתוח למפתחים, סביבת פיתוח אינטגרטיבית למפתחים, סביבות בדיקה, סביבת pre-prod וסביבות ייצור) בייחוד למפתחים. נניח שבארגון מסויים המערכת שנמצאת בייצור היא בגרסה 200. המערכת שנמצאת בבדיקות היא בגרסה 201. המערכת עליה עובדים המפתחים היא כבר גרסה 202. אבל מובן שלמפתחים צריך שיהיו עותקים גם של 200 (למקרה של תקלות בייצור) וגם של 201 (למקרה של תקלות בגרסה שנמצאת ב- QA).
ל- QA שעובדים על גרסה 201 יש גם עותק של גרסה 200 וזאת בכדי שיוכלו לאשר תיקונים בייצור.

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



סוגי הפעולות של צוות סביבות
1. Setup – בניה של סביבה חדשה. מתבצע לפי Check list. דברים כגון שרתים, אחסון DBA, middleware. אבטחת מידע ופיתוח.
2. שדרוגים :
a. שדרוגים תשתיתיים על פי checklists או scripts ידועים של אוטומציה
b. שדרוגי תוכנה- כלים או ידנית
3. Data Refresh –
a. Full - דרך clone, ומיסוך (משכורות, סיסמאות)
b. SUBSET או שיש הפצה מרובת סביבות. בונים master (כלומר מייצרים מדגם) , מרעננים ומפיצים לכולם (העתקה ממש ולא SNAPS) .בד"כ מבצעים העתקות בפועל – לא משתמשים ב- SNAPS
c. Direct – לוקחים נתונים מייצור בפועל. בכדי לבדוק בעיה.

הכלים לביצוע משימות ה- Refresh הם: ETL, refresh scripts - ובכלים – כמו Optim (כיום של IBM ) או Brilix שמבצעים גזירות ו- SUBSET.

דגשים לתחום ה- DRP

לקראת הדיון שמתקיים היום בכנסת להלן מספר דגשים לתחום ה- DRP :

1. הדבר החשוב ביותר הוא להבין ש-DRP אינו פרוייקט תשתיתי\טכנולוגי אלה תפעולי! מדובר בנושא שמחייב התייחסות שינויים ועדכונים לכל אורך הדרך ולא רק בזמן הקמת הפרוייקט. ישנם ארגונים רבים שטועים בהבנת סוגייה בסיסית זו.
2. אחד הדברים הבעייתיים ב- DRP היא שמירה על עדכניות. מתקינים משהו בייצור- ואז חייבים להתקין אותו ב- DR. בפועל זה לא קורה ואז ביום הדין יש אי תאימות באפליקציה או בתשתית. וכמובן שהדיסק חסר...
3. Boot from san פותר בעיה זו אבל מביא גם בעיות אחריות. לדוגמה, מגיע טכנאי חומרה כחלק מהאחריות למוצר לתקן מאוור. על הדרך הוא מעדכן bios. זה לא מתבצע באתר ה- DR כי זה לא באחריות הטכנאי והוא גם לא מודיע את זה לאף אחד ואז המערכות לא עולות.... זה קרה בזמנו ב- WIN . בUnIX פחות בעייתי.
4. וירטואליזציה תופסת תאוצה גם בהקשר ל- DRP. מאפשר גם לחסוך שרתים באתר ה- DRP ועוד יותר חשוב מאפשרת להעביר מערכות ללא חשש לתאימות חומרה.
5. SRM של VMWARE מתקדם כל הזמן. עדיין לא בשל לגמרי כמו cluster אמיתי (הוא מזהה תקיעה של מערכת הפעלה אבל בד"כ לא יזהה תקיעה של אפליקציה כאשר מערכת ההפעלה עובדת כשורה).
6. לקוחות כותבים הרבה scripts . יש שימוש מסויים ב- geo cluster בעיקר של Veritas אבל לא בצורה אוטומטית לגמרי.
7. מבחינת רפליקציה, לאחרונה לקוחות מדברים על זה שעדיף לבצע רפליקציה ברמת ה- DBMS ולא באמצעות הדיסק (SRDF\Snapmirror ) כי הביצוע השכפול באמצעות סביבת האחסון מעביר גם שגיאות לצד השני.
8. מומלץ לתת תפקיד של אחראי DRP. כאשר אותו אחראי הוא חלק מהשרשרת שחותמת על העברה לייצור.
9. תוכנת continuity software שכיום נמכרת ב- OEM דרך Symantec מסייעת לאיתור פערים.
10. ישנה סוגיה ארכיטקטונית מעניינת לגבי רשת נפרדת מול רשת אחודה (dr ו- prod) . ארגונים רבים בוחרים ברשת אחודה למרות שהדבר מחייב בשינויים לא פשוטים (קינפוג מתאים של DNS ולעיתים גם שינויים בתוך האפליקציות).


השלבים השונים לפרוייקט DRP הנם:
1. התנעת הפרוייקט. שם גם מגדירים מה התוצרים מהפרוייקט ולמידת תמונת המצב בארגון כעת
2. BIA – business impact analysis - מסתכלים על התהליכים העסקיים (והמערכות שמיישמות אותם) ומצד שני על הסיכונים והתוצאה היא הגדרה של רמות שירות שונות (platinum gold וכד') כולל RPO RTO למערכות השונות.
3. הגדרת ארכיטקטורה למערכות השונות לפי הרמות שהוגדרו.
4. יישום הארכיטקטורה.
5. מבצוע הרמה הגבוהה ביותר – (platinum ולאחריה הרמה השניה- GOLD וכך הלאה)
6. בדיקות.
7. תפעול שוטף. השלב הבעייתי ביותר בפרוייקט.