לקראת הדיון שמתקיים היום בכנסת להלן מספר דגשים לתחום ה- 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. תפעול שוטף. השלב הבעייתי ביותר בפרוייקט.
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. תפעול שוטף. השלב הבעייתי ביותר בפרוייקט.
2 תגובות:
הי פיני, קצר ולעינין. כרגיל אשמח להגיב אחד על אחד ויש על מה.
הי פיני,
האם הנקודות הראשונות שהעלית בנושא המעקב ועידכון התוכנית אינן נוגעות בנקודה חלשה אחרת ב-IT הישראלי אשר נקראת Change Managment?
הוסף רשומת תגובה