אחד הלקוחות תאר בפני תהליך של העברת האתר הראשי שלו מאתר אחד לאתר שני. מדובר על פעילות מורכבת שבה במהלך תקופה מסויימת מעבירים את כל הציוד ממבנה אחד למבנה שני. שני המבנים קרובים יחסית אחד לשני ויש LAN מאוחד כלומר ניתן לעבוד במקביל. עם זאת בכל פעם שמעבירים מארז אחסון – יש להעביר איתו את כל המערכות שיושבות עליו. מדובר על פעילות שנחשבת לא פשוטה שגוזלת זמן רב ושעלולה לגרום להשבתה. מקובל שארגוני IT משתמשים בקבלן אשר מבצע את הפעילות תחת SLA מדוקדק. באופן טבעי שאלתי את הלקוח "מי מבצע את פעילות המעבר עבורך?" אבל להפתעתי הלקוח ענה שהוא מבצע את הפעילות למעט שימוש בשירותי הובלה (אחוז קטן מהעלות). מדובר על לקוח מוסדי אשר בהחלט יכול לגייס תקציב לצורך משימה כזו ולכן הבעתי תמיהה על כך שלא היה שימוש באינטגרטור חיצוני וכאן קיבלתי תשובה מאלפת. הלקוח שאל אותי – "נכון שמדובר בפעולה מורכבת שעיקרה ידיעה עמוקה לפני ולפנים של מבנה המערכות והתשתיות עליהן הן מסתמכות?" ברור שכן. ואז המשיך – "ואם הייתי משתמש באינטגרטור, מי היה מלמד את האינטגרטור כל זאת- העובדים שלי!". כלומר מבחינת הלקוח גם אם הוא מבצע את העבודה וגם אם אינטגרטור חיצוני מבצע את העבודה – העובדים שלו צריכים להשקיע פחות או יותר את אותו הזמן בתהליך. ולכן לדעתו של הלקוח כל מי שמשתמש באינטגרטור לפעולה כזו עושה זאת בעיקר לצורך כסת"ח! זאת אמירה נחרצת שלא זוכה להסכמה כללית בשוק אבל בהחלט מעוררת מחשבה. עד כמה השימוש באינטגרטורים לביצוע עבודות מוגדרות הוא בגלל העומס האוביקטיבי או הצורך של לימוד תחום שאינו מוכר לארגון – או עד כמה כמה המרכיב של "משהו חיצוני לוקח אחריות" הנו דומיננטי?!
הצגת רשומות עם תוויות drp bcm. הצג את כל הרשומות
הצגת רשומות עם תוויות drp bcm. הצג את כל הרשומות
דגשים לתחום ה- 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. תפעול שוטף. השלב הבעייתי ביותר בפרוייקט.
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. תפעול שוטף. השלב הבעייתי ביותר בפרוייקט.
שפעת החזירים ו- BCM\DRP
אנחנו בישראל עדיין לא מרגישים בצורה משמעותית לשימחתנו את השפעותיה של שפעת החזירים. אולם בעולם במקומות שבהם ישנה תחלואה גדולה יותר רואים כבר ספקים בתחום שמציעים קורסים מזורזים לבחינת ההשפעות של מגפה על ארגוני ה- IT תוך הצעה של דרכים להתמודדות.
שימו לב לדוגמה ל-
Professionals in the Business Continuity and Disaster Recovery fields won’t want to miss this critical webinar. Based on current events surrounding H1N1, or the “Swine Flu,” the session will clarify the difference between DHS guidelines for Public and Private sectors and demystify the overlap between the Continuity of Operations Essential (COP-E) guidelines as proscribed by DHS and your existing contingency plans.
נקווה שהמחלה תודבר במהרה ושכל זה יראה כ"הגזמה פראית" עוד כמה חודשים.
תוויות:
continuity,
drp bcm
הירשם ל-
רשומות (Atom)