Drp Rt May08 V9

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫סיכום מפגש שולחן‪-‬עגול‬ ‫מדיניות וטכנולוגיות ‪BCM\DRP‬‬ ‫‪ 6‬למאי ‪2008‬‬ ‫מנחה פיני כהן‬

‫‪Page 1 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫‪30.6.2008‬‬

‫לקוחות נכבדים שלום‪,‬‬ ‫תודה על השתתפותכם במפגש שולחן עגול‬

‫‪ Round Table‬בנושא מדיניות וטכנולוגיות‬

‫‪.DRP\BCM‬‬ ‫מצ"ב סיכום עקרי הדברים שעלו במהלך המפגש‪ .‬במפגש עלו נושאים מהותיים שתומצתו‬ ‫בסיכום כפי שעלו‪ .‬אין בסיכום זה המלצה גורפת ללקוחות אלא מתן פרספרטיבה והצגה של‬ ‫ההתלבטויות שעלו במפגש כלומר "מהשטח"‪ .‬בנוסף לסיכום אני מצרף טבלה לדוגמה של‬ ‫רמות ‪ DRP‬שונות כולל התייחסות לעלויות של רמות אלו‪ .‬כמו כן ברצוני להזכיר כמה‬ ‫מגמות טכנולוגיות רלוונטיות‪:‬‬ ‫‪‬‬

‫‪ – Cloud Computing‬לאחרונה מדברים על מגמה חדשנית של שימוש בשרתים וירטואלים‬ ‫אשר נמצאים אצל ספק שירות‪ .‬לדוגמה‪ AMAZON ,‬מציעה היום שרת בסיסי וירטואלי עם‬ ‫יכולות ‪ WEB‬בעלות המתחילה ב‪-‬‬

‫‪ 0.1$‬לחודש ‪http://www.amazon.com/EC2-AWS-‬‬

‫‪ – Service-Pricing/b?ie=UTF8&node=201590011‬טכנולוגיה זו אשר אינו בשלה כעת‬ ‫ללקוחות מוסדיים עשויה‪ ,‬במידה ותתפוס עוד מספר שנים‪ ,‬לשנות בצורה מהותית את‬ ‫ההתייחסות ל‪ datacenter -‬באופן כללי וספציפית ל‪.DRP -‬‬ ‫‪‬‬

‫‪ – Run Book Automation‬טכנולוגית ‪ workflow‬עם ‪ adaptors‬ייעודיים לתשתיות ותפעול‪.‬‬ ‫טכנולוגיה זו מאפשרת לבצע פעולות אוטומטיות ובכך להקל ולשפר את העבודה של‬ ‫המפעילים‪ .‬לדוגמה‪ ,‬ניתן לצור ‪ workflow‬אשר במידה ויש זיהוי של איטיות של משתמשים‬ ‫מסוימים‪ ,‬המערכת בודקת ב‪ active directory -‬מי מחובר‪ ,‬בודקת ב‪ unicenter -‬איזה שרת‬ ‫תקוע‪ ,‬ומבצעת ‪ boot‬בתנאים מסוימים לשרת ‪ windows‬או ‪ Unix‬או לחלופין מוסיפה שרת‬ ‫ל‪ pool -‬של ה‪ application server -‬על ידי נתינה פקודות לסביבת ה‪.VMWARE -‬‬

‫המפגש הבא בנושא זה יתקיים בתאריך ‪ 21‬ליולי‪ ,‬יום ב' בשעה ‪ .0930‬סדר יום למפגש הוא‪:‬‬ ‫‪ .1‬התייחסות לנושא בדיקות ‪ :‬איזה בדיקות מבצעים‪ ,‬באיזה תדירות‪ ,‬מה קורה במהלך‬ ‫הבדיקה‪-‬האם המערכת הייצור מושבת‪ ,‬האם נבדק נושא של‬

‫‪ consistency‬של ‪ data‬בין‬

‫מערכות וכד'‪.‬‬ ‫‪ .2‬סבב של המשתתפים בהם הם יתארו את הטכנולוגיה והמתודולוגיה של‬

‫‪ DRP‬שבשימוש‬

‫באחת מהמערכות אצלהם‪ ,‬רצוי דואר אלקטרוני בכדי שנקבל מכנה משותף ופרספקטיבה‬

‫‪Page 2 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫אחידה‪ :‬איזה טכנולוגיה לריפלוק מידע ובאיזה תדירות‪ ,‬האם מבצעים גיבוי לקלטות או גיבוי‬ ‫על דיסק‪ ,‬כיצד מטופלים ‪ patches‬או שינויים באפליקציה‪ ,‬איזה קווי תקשורת ‪ ,‬וכד'‪.‬‬

‫אנא הודיעו לנו בטלפון או במייל חוזר על כוונתכם להשתתף במפגש בכדי שנוכל להיערך‬ ‫לוגיסטית‪ .‬כמו כן‪ ,‬ההשתתפות במפגש הנה אפשרית לשני נציגים מכל ארגון‪.‬‬

‫בברכה‪,‬‬ ‫פיני כהן‬

‫תוכן‬ ‫קבלת החלטות ‪3............... ................................ ................................ ................................‬‬ ‫אתרים ‪6......................... ................................ ................................ ................................‬‬ ‫טיפול במערכות חדשות ‪6................................... ................................ ................................‬‬ ‫תרגול ונהלים ‪7................. ................................ ................................ ................................‬‬ ‫טכנולוגיות ‪8..................... ................................ ................................ ................................‬‬ ‫אחר ‪9............................. ................................ ................................ ................................‬‬ ‫טבלה של רמות ‪ DRP‬שונות כולל התייחסות לעלות ‪10............................. ................................‬‬ ‫תגובות של ספקים ‪11........................................ ................................ ................................‬‬ ‫מטריקס ‪11.................. ................................ ................................ ................................‬‬ ‫בינת ‪12....................... ................................ ................................ ................................‬‬

‫קבלת החלטות‬ ‫להלן תאור הנאמר על ידי הארגונים לגבי אופן קבלת ההחלטות בנושאי ה‪:BCM , DRP -‬‬ ‫‪‬‬

‫אחד הארגונים קיבל בזמנו החלטה על ידי תהליך מסודר של הנהלת הארגון (בשיתוף ה‪)IT -‬‬ ‫לעבור ל‪ .Med1 -‬כאשר במקביל התקבלה החלטה לא לפתח מערך‬

‫‪ .DRP‬באתר ‪Med1‬‬

‫ישנה כפילות ו‪ HA -‬אבל אין ‪ DRP‬החוצה‪ .‬הארגון גם החליט שמערך המחשוב לא חיוני‬ ‫למערך השירות העיקרי של החברה‪.‬‬ ‫‪‬‬

‫אחד הארגונים דיבר על כך שלאחרונה‪ ,‬בעקבות מלחמת לבנון השנייה‪ ,‬גם גוף‬ ‫בארגון‪ ,‬תחת ה‪ . IT -‬כמו כן הוחלט בארגון לבנות מקלט אטומי ובמקביל לעבוד‬

‫‪ BCP‬כללי‬ ‫‪active‬‬

‫‪Page 3 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫‪ active‬עד כמה שאפשר‪ .‬תוצאה נוספת היא שימוש נרחב עד כמה שאפשר בוירטואליזציה‬ ‫ובמימד נוסף ב‪.geo-cluster -‬‬ ‫‪‬‬

‫אצל ארגון אחר ישנה ועדה ראשית שאחראית על כל נושא ה‪BCM – business continuity -‬‬ ‫‪ management‬כאשר הועדה היא תחת תחום "השירותים הארגוניים"‪ ,‬תחום שמדווח‬ ‫למנכ"ל ואחראי גם ל‪-‬‬

‫‪ IT‬וגם לנושאי תמיכה נוספים בארגון כגון נסיעות‪ ,‬בנינים ועוד‪.‬‬

‫מתחת לוועדה שמתכנסת פעם ברבעון‪ ,‬יש גוף ‪ BCP‬קבוע וגם פורום ‪ BCP‬נרחב שמתכנס‬ ‫לפי הצורך‪.‬‬ ‫‪‬‬

‫לגבי קביעה של ‪ RPO‬ו‪ .RTO -‬ההתרשמות בדיון הייתה שרוב החברות קובעות את מדדים‬ ‫אלו בצורה עצמאית (חלק מהחברות על ידי ה‪ IT -‬בלבד) אבל אחת החברות ציינה שחברת‬ ‫ייעוץ חיצונית עשתה בדיקה בישראל ובחול בתחום של ‪ .business impact analyses‬ועל פי‬ ‫תוצאות סקר זה קיבלו המלצות של‬

‫‪ .RTO RPO‬כלומר על פי תוצאות הסקר עושים את‬

‫תוכנית ה‪.DRP -‬‬ ‫‪‬‬

‫אחד הלקוחות טען שרגולציה של‬

‫‪ SOX‬מחייבת שכל המידע הפננסי מרופלק למרכז‬

‫בארה"ב‪.‬‬ ‫‪‬‬

‫אחד הלקוחות נכנס כעת לפרוייקט אחסון כאשר ההחלטה העקרונית היא לרפלק נתונים‬ ‫לכל הנתונים הייצוריים כלומר ‪ DR‬רק לרמה של ‪ .DATA‬יש לארגון רשימה של מערכות‬ ‫קריטיות אבל הארגון מתלבט כעת מתלבטים לגבי ההחלטה של‬

‫‪ RPO RTO‬למערכות‬

‫השונות‪.‬‬ ‫‪‬‬

‫בארגון אחר ה‪ IT -‬קובע לגבי ‪ .DRP BCP‬כיום ישנו נסיון לשכנע את המנכ"ל שתהייה ועדה‪.‬‬

‫‪‬‬

‫ארגון פיננסי ציין שיש פוררום ‪ – BCP‬מנהל מערכות מידע‪ ,‬איש או"ש (של תחום ה‪ )IT -‬שגם‬ ‫יועץ למנכ"ל ומכיר את כל הארגון‪ ,‬וגם פורום לוגיסטיקה‪ .‬הפורום מתכנס בפורום בתדירות‬ ‫של פעם בשבועיים (לא תמיד מתקיים)‪ .‬החלטה על התהליך של הערכות לחירום התקבלה‬ ‫בזמנו דרך הדירקטוריון! כלומר ברמה הגבוהה ביותר‪.‬‬

‫‪‬‬

‫מנהל ה‪ IT -‬בארגון קובע את רמת הקריטיות של המערכות‪.‬‬

‫‪‬‬

‫לקוח מתחום התקשורת (אין בעיה של קווי תקשורת‪ )...‬ציין שההחלטה על ‪ DR‬התקבלה עוד‬ ‫בזמנו לאחר שנפל סקאד במלחמת המפרץ הראשונה‪ .‬כאשר ‪ RPO‬נקבע ל‪ .0 -‬ו‪ RTO -‬זה ‪4‬‬ ‫שעות‪.‬‬

‫‪‬‬

‫המחשוב ביקש ‪ DRP‬מההנהלה‪ .‬קיבלו תקציב‪ .‬הוקם אתר שנמצא בבעלות הארגון במרחק‬ ‫של ‪ KM5‬בקו אווירי מהאתר הראשי‪.‬‬

‫‪‬‬

‫אצל אחד הלקוחות המחשוב בקש מההנהלה ואז פנו לאו"ש וללקוחות – ואז ה‪ IT -‬החליט ‪.‬‬ ‫כלומר ה‪ IT -‬מציע ואז ה‪ business -‬מאשר‪ .‬לא הגדירו קטגוריות ל‪ .DRP -‬החליטו שרצוי‬ ‫שמתקן ה‪ DRP -‬יהי פעיל כל הזמן‪ .‬וייתן גם שירות כל הזמן (מצב אופטימלי)‪.‬‬

‫‪‬‬

‫אצל אחד מהארגונים מתחום הבריאות החל מ‪ IT – 2000 -‬לא מקבל החלטות – הנהלה או‬ ‫‪ .board‬ה‪ IT -‬רק מבצע‪ .‬בזמנו ההנהלה החליטה שתהליכי העבודה הבסיסיים ביותר צריכים‬

‫‪Page 4 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫להתבצע גם אם אין חשמל כלומר ללא מחשוב‪ .‬כלומר יש תהליכים ידניים כגיבוי‪ .‬יש ועדת‬ ‫היגוי למערכות מידע‪ VP .‬רפואה‪ , VP FINANCE ,‬מנכ"ל ו‪ .CIO -‬הם מחליטים על ה‪RPO -‬‬ ‫‪ RTO‬כאשר ‪ KPMG‬מלווים אותם בתהליך‪ .‬ואז ההחלטות עוברות לתוכניות עבודה‪ .‬יש להם‬ ‫תהליך שלם של ‪ –BCM‬בגלל מל"ח וכד'‪ .‬תהליך או"ש חוצה ארגון‪ .‬יש ספר פיזי‪.‬משוכפל ב‪-‬‬ ‫‪ 4‬מקומות‪( .‬כולל קודים של אזעקה‪ ,‬מפתחות ‪ SPARE‬וכד')‪ .‬לפעמים אצל אנשים בבית‪.‬‬ ‫‪‬‬

‫אצל ארגון אחר ה‪ IT -‬ממליץ ובנה ‪ DRP‬באתר גיבוי למערכות קריטיות –גם ‪– exchange‬‬ ‫מאוד מאוד חשוב (יש ארגונם שציינו שאצלהם ה‪-‬‬

‫‪ exchange‬לא נמצא ברמת החשיבות‬

‫הגבוהה ביותר)‪ .‬המטרה הכללית היא ‪ RTO‬של ‪ 4‬שעות עם ‪ .capacity 60%‬כל זה נקבע‬ ‫על ידי ה‪ .IT -‬ה‪ IT -‬בצע סיווג של המערכות ומקבל עת ההחלטה על פי דרישות הלקוח‪ .‬כבר‬ ‫חצי שנה‪ -‬חבר הנהלה הבחירה שקיבל תפקיד אחריות על ‪ .BCM‬יש מערכות כמו שירות‬ ‫לקוחות חשוב שיעבוד בזמן חירום – ב‪ 5 -‬אתרים‪ .‬ומערכות המענה ‪ CTI‬מפוזר ולכן אין בעיה‬ ‫אם נופלים ממשיכים לקוח אחר דיבר על חברת ייעוץ בינלאומית שמבצעת כעת סקר בנושא‬ ‫של ניהול סיכונים‪ .‬מסקנה עד עכשיו שניתן להשבית את ה‪-‬‬

‫‪ ERP‬לתקופה של ‪ 3‬ימים‪.‬‬

‫מערכות של ייצור ניתן להשבית לפחות זמן‪.‬‬ ‫‪‬‬

‫לקוח תאר מצב שבו ‪ DRP‬תמיד היה קשור ל‪ .IT -‬ה‪ –BCP -‬לא תמיד טופל בצורה רחבה‪.‬‬ ‫אבל עכשיו יש צוות – ‪, IT‬הנדסה‪ ,‬שירות לקוחות וכד'‪ .‬כפופים ל‪ .SOX -‬מבצעים ביקורות‬ ‫פעמיים בשנה‪.‬‬

‫‪ – STKI‬מהמשתתפים במפגש אצל כ‪-‬‬

‫‪ 66%‬מהארגונים ההחלטות הקשורות ל‪-‬‬

‫‪DRP‬‬

‫נקבעות (או מובלות) על ידי ה‪ IT -‬ולא על ידי ה‪ .business -‬לדעתנו זה מספר די מייצג (אולי‬ ‫במציאות אפילו יותר גבוה)‪ .‬כמובן שעדיף שה‪ business -‬יהיה אחראי על ה‪DRP\BCM -‬‬ ‫ולא ה‪( IT -‬כלומר ה‪ IT -‬רק יבצע את מדיניות ההנהלה) אולם לצורך כך צריך תשומת לב‬ ‫שלא תמיד קיימת אצל המנהלים העסקיים‪ .‬אנו צופים שבעתיד‪ ,‬ככל שרגולציה תכנס יותר‬ ‫ויותר‪ ,‬אחוז הארגונים בהם ה‪ BCM\DRP -‬נקבע על ידי ה‪ business -‬יגדל‪.‬‬

‫‪Page 5 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫אתרים‬ ‫להלן סיכום בצורה סטטסטית של צורת הגיבוי המקובלת אצל הארגונים שהשתתפו‪.‬‬ ‫להערכתנו אין מדובר בסטטיסטיקה "אמיתית" וזאת מכיוון שהסיכוי שארגונים שנמצאים‬ ‫בתהליך של בניית ‪ DRP‬או שיפורו יגיעו למפגש יותר משיגיעו ארגונים שאינם נמצאים‬ ‫בתהליך של בנייה או שיפור ה‪.DRP -‬‬ ‫לרובם המכריע של המשתתפים ‪ ,‬מעל ‪ ,50%‬כבר כיום מדיניות ‪ DRP‬הכוללת מתקן גיבוי‬ ‫ומתקן ייצור באתר נוסף (של הארגון – לא אצל ספק שירות)‪.‬‬ ‫לכ‪ 20%-‬מהלקוחות אין תוכנית‬

‫‪ DRP‬כוללת‪ ,‬כאשר ארגונים אלו נמצאים כעת במהלך‬

‫לבניית תוכנית כזו‪.‬‬ ‫ל‪ 10%-‬יש מתקן ייצור ומתקן ‪ DRP‬אצל נותן שירות‪ ,‬ועוד ‪ 10%‬נמצאים ב‪ hosting -‬אצל‬ ‫נותן שירות (ללא מתקן גיבוי)‪ .‬ל‪ 10% -‬יש מתקן ‪ DRP‬סמוך לאתר הראשי (באותו האתר –‬ ‫מאפשר עבודה סינכרונית) ומתקן ‪ DRP‬נוסף רחוק יותר (לא סינכרוני)‪.‬‬ ‫כ‪ 40% -‬מהלקוחות שהשתתפו נמצאים בתהליך של בנייה\שדרוג\שיפור סביבת ה‪-‬‬

‫‪DRP‬‬

‫הנוכחית שלהם‪.‬‬

‫טיפול במערכות חדשות‬ ‫להלן התייחסות של ארגונים לסוגיה של סטנדרטים בתחום ומה מקובל כאשר מכניסים‬ ‫מערכת חדשה לייצור‪:‬‬ ‫‪‬‬

‫אצל אחד הארגונים הסטנדרט היום הוא שלא מכניסים לייצור ללא ‪ DRP‬כלומר ה‪default -‬‬ ‫הוא שרתים זהים ושכפול מידע!‬

‫‪‬‬

‫אצל אחד הארגונים שבו תחום ה‪ IT -‬הוא התשתית לכל הפעולות‪ ,‬הסטנדרט הוא ששרתים‬ ‫תמיד קונים ב‪-‬שלשות! כל שרת רוכשים שנים באתר הייצור לצרכי ‪ high availability‬ושרת‬ ‫נוסף ל‪.DRP -‬‬

‫‪‬‬

‫לקוח ציין שמערכות שקשורות ללקוח הסופי נבנות מראש בשתי אתרים‬

‫– עם ‪ DR‬כלומר‬

‫רוכשים תמיד ‪ 2‬שרתים וקיים מעבר ‪ DR‬בין שני אתרים‪.‬‬ ‫‪‬‬

‫אצל לקוח נוסף‪ ,‬מערכת חדשה – כל המערכות החדשות מקבלות ריפולוק של אחסון‪.‬‬

‫‪‬‬

‫אצל אחד הארגונים הגדירו תקן ב‪ .DC -‬איך נראה שרת‪ ,‬תקשורת וכד'‪ .‬ולכן תפעול קל יותר‪.‬‬ ‫וגם ‪ DR‬קל יותר‪.‬‬

‫‪Page 6 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫‪‬‬

‫הגדירו קטגוריות של רמות שירות ‪ 4‬קטגוריות של ‪ – SLA‬פלטינה – ארד‪ . ..‬לכל קטגוריה‬ ‫מספרים‪ ,‬כולל התייחסות לתקלות לוגיות (יש כאלה שלא מטפלים בתקלות לוגיות‪ ,)..‬בסוף‬ ‫הגיע למצב של תת קטגוריות‪ .‬כסף – רק ‪( .HA‬וגם ריפלוק של לונים) זהב‪ -‬אוטומטי ‪HA DR‬‬ ‫מלא‪ .‬וכד'‪ .‬וגם הסיווג מראה כמה פעמים מתרגלים בשנה‪ .‬וגם הגיבוי מדיה נתיקה – הכל‬ ‫מוגדר בקטגוריה‪ .‬הלקוח בנה שאלון ל‪ – DRP -‬ואז הלקוח עונה לשאלות ועל פי זה בוחרים‬ ‫את ה‪.SLA -‬‬

‫‪ – STKI‬מספר הארגונים אשר ציינו שה‪ default -‬לכניסה של מערכות חדשות לייצור כולל‬ ‫‪ DRP‬או ריפלוק הוא גבוה יחסית‪ .‬ברור שאצל לקוחות שמבוססים על שירותי מחשוב כמו‬ ‫לדוגמה לקוחות מהשוק הפיננסי‪ ,‬הדבר מתבקש‪ .‬אצל לקוחות שאינם מבוססים על מחשוב‬ ‫לנתינת השירות \ייצור המוצר הבסיסי‪ ,‬כמו לדוגמא בתחום הבריאות‪ default ,‬של ‪ DRP‬לכל‬ ‫מערכת פחות מתבקש‪.‬‬ ‫הערה נוספת – ככל שהקשרים בין המערכות יגברו ( ‪ SOA‬ומגמות נוספות‪ )..‬הצורך ל‪DRP -‬‬ ‫של כל המערכות יגבר בגלל הצורך ב‪ consistency -‬של המידע בין המערכות השונות‪.‬‬

‫תרגול ונהלים‬ ‫להלן התייחסויות של ארגונים לנושא של תרגול ונהלים‪:‬‬ ‫‪‬‬

‫מתרגלים פעמיים בשנה תהליך מלא של הקמת מערכות קריטיות בלבד‪.‬‬

‫‪‬‬

‫במערכות החשובות ביותר דברים לא יכולים לעלות אוטומטיות כאשר מבחינה של‬ ‫‪ – consistency‬לא עשו בדיקה מלאה‪ .‬בשביל לעשות בדיקה – משביתים ובודקים‪ .‬עושים‬ ‫סנכרון חד כיווני‪ .‬ואז בזמן הבדיקה ‪ ,‬המערכת המקבילה מושבתת‪.‬‬

‫‪‬‬

‫לקוח ציין שלמרות שיש תכנון מראש חלק מהדברים מגלים רק בתרגילים‪.‬‬

‫‪‬‬

‫לקוח ציין יש להם תרגילים מתודים – עם מנהלי אגפים‪" .‬נפל הבניין" ‪ -‬מה מנהל אגף‬

‫‪X‬‬

‫עושה‪( .‬פעם תרגיל עם מנהלי האגף פעם בנפרד עם הסגנים שלהם)‪ .‬יש להם ספר‬

‫–‬

‫מעדכנים אותו פעם בשנה‪.‬‬ ‫‪‬‬

‫לקוח דיבר על כך שלפעמים משחזרים מערכת שלמה‪ .‬שומרים קלטות ב‪ .databank -‬עושים‬ ‫ביקורת על מערכת קריטית פעם בשנה‪.‬‬

‫‪‬‬

‫לקוח דיבר על כך שעל פי הניסיון שלו‪ ,‬תקלה קריטית שמשביתה לקוחות רבים‪ ,‬מתרחשת‬ ‫פעם ב‪ 5 -‬שנים קורה משהו‪.‬‬

‫‪Page 7 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫טכנולוגיות‬ ‫להלן התייחסויות נוספות של לקוחות לטכנולוגיות שבשימוש ‪:‬‬ ‫‪‬‬

‫גיבוי של נתונים – מעבירים בין המתקנים השונים‪ .‬מרפליקים נתונים רפליציה סינכרונית‬ ‫‪ SRDF‬וגם ‪ .standby DBMS‬הסיבה שמשתמשים בשתי טכנולוגיות אלו הוא שהיה היה להם‬ ‫מקרה של ‪ BUG‬אפליקטיבי שפגע בנתונים ותשתית הריפלוק באחסון העבירה את התקלה‬ ‫בין אתר ראשי למשני דבר שגרם להשבתה של מספר ימים‪ .‬ולכן החליטו להשתמש גם ב‪-‬‬ ‫ל‪.standby DBMS -‬‬

‫‪‬‬

‫טכנולוגיה שבה משתדלים להשתמש באופן כללי וגם ספציפית ל‪ Windows -‬זה ‪boot from‬‬ ‫‪ .SAN‬כל מחשבי הפיתוח נמצאים בגיבוי‪ .‬מבחינת כוח חישוב בין‬

‫‪ 70%‬ל‪ .100% -‬ישנה‬

‫בדיקה של ‪ - geo-cluster‬פתרון זה אינו זול‪ ...‬כמו כן עובדים עם ‪ – srdf/c‬עם ‪geo-cluster‬‬ ‫שרוכב על ‪ cluster‬בין מיקרוסופט‪.‬‬ ‫‪‬‬

‫אחד הלקוחות משתמש ב‪-‬‬

‫‪ - continuity software‬עושה בקרה בהתחלה על דברים‬

‫קריטיים שלא קונפגו‪ .‬ש‪ redo log -‬ו‪ DBMS -‬על אותו דיסק (שתקלה תדפוק את שניהם‪.)...‬‬ ‫אבל לא מטפל באפליקציות‪ .‬מטפל במסד נתונים ואחסון‪ .‬אבל באפליקציות לדוגמה לא‬ ‫מטפל אם ‪ TIBCO‬לא יודע לטפל‪ .‬מטפל ב‪ RAIDS -‬וכד'‪.‬‬ ‫‪‬‬

‫לקוח דיבר על תצורת אפליקציה שמתבססת על ‪ Citrix‬סה"כ ‪ 80‬שרתי ‪ .CITRIX‬כאשר ‪40‬‬ ‫באתר המקור ו‪ 40 -‬ב‪ DR -‬ולכן עובדים כל הזמן וה‪ DRP-‬מובנה בשימוש הרגיל‪.‬‬

‫‪‬‬

‫לקוח דיבר על כך שה‪ LAN -‬משותף לייצור ול‪ DRP -‬וכך יודעים לדלג מערכות לאתר ה‪DR -‬‬ ‫כששאר המערכות נשארות בייצור – כי אותו לשרת בגיבוי אותו שם ומספר ‪.IP‬‬

‫‪‬‬

‫לקוח הזכיר שאצלהם ב‪ UNIX -‬יש דיסק סיסטם באתר הגיבוי שמתעדכן כל הזמן מדיסק‬ ‫‪ DR‬עם דיסק‬

‫הסיסטם בייצור‪ .‬שאר הדיסקים עובדים רגיל‪ .‬במקרה נפילה עולים ב‪-‬‬ ‫הסיסטם‪.‬‬ ‫‪‬‬

‫הפתרון שאחד הלקוחות מגבש לגבי ‪ -exchange‬יהיה ‪ exchange‬ב‪ DR -‬שיוכל לעלות אבל‬ ‫ללא הנתונים ואז ישחזרו את הנתונים לתוך ה‪ EXCHANGE -‬השני‪.‬‬

‫‪‬‬

‫תהליכי לקוחות רבים משתמשים ב‪ SRDF -‬בתחום ‪ .DMX‬כאשר בתחום ה‪-‬‬

‫‪midrange‬‬

‫הוזכרה טכנולוגיית ה‪ – Mirrorview -‬ב‪.Clarion -‬‬ ‫‪‬‬

‫את כל המערכות ב‪ DMX -‬מרפלקים‪ .‬ב‪– clarion -‬יש "הנחות"‪ .‬כל מה שקשור למערכות‬ ‫קריטיות – יש דגש‪.‬‬

‫‪‬‬

‫אצל אחד הלקוחות שאצלו אתר ה‪ DRP -‬נמצא בבניין ליד‪ ,‬ה‪ – RPO -‬הוא ‪( 0‬או קרוב) כי‬ ‫מגלגלים לוגים שמסונכרנים‪ .‬ה‪ – RTO -‬בין שני מתקנים זה ‪ cluster‬כלומר כ‪ 10 -‬דקות‪.‬‬ ‫באתר הגיבוי המרוחק – אין שרתים‪ .‬יש רק דיסקים עם נתונים כלומר אין התחייבות‪.‬‬

‫‪Page 8 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫אחר‬ ‫להלן התייחסויות של לקוחות לנושאים נוספים‪:‬‬ ‫‪‬‬

‫אחד הלקוחות מתעניין בסטנדרט ל‪-‬‬

‫‪ – BCM‬סטנדרט ‪ BS25999‬האנגלי‪ ,‬אשר מחזיק‬

‫מערכת של הסמכות (כלומר יש ‪ certification‬לתקן)‪.‬‬ ‫‪‬‬

‫לקוח ציין שהם עושים ‪ SRDF‬סינכרוני – ‪ KM130‬קווי (כאשר אווירית מדובר על מרחק קטן‬ ‫הרבה יותר) והפתרון עובד טוב כלומר לא מאט את המערכות!‬

‫‪‬‬

‫אחד הארגונים ציין שביצוע הדילוג ממתקן הייצור למתקן ה‪-‬‬

‫‪ DR‬מתבצע על ידי אנשי‬

‫ההפעלה (לא אנשי ‪ . )system‬כלומר הטכנולוגיה מספיק פשוטה ואוטומטית ומתאימה‬ ‫למפעילים‪ .‬המפעילים לא מחליטים על הדילוג זאת החלטה ניהולית‪ .‬כלומר הנהלים בנויים‬ ‫לסביבה של מפעילים‪.‬‬ ‫‪‬‬

‫קשרים בין מערכות – הרבה יותר ממה שחשבו‪.‬‬

‫‪‬‬

‫לגבי עלויות תוכנה‪ ,‬הוזכר שישנם ספקים אשר לא דורשים תשלום לסביבות כמו‬

‫‪ DRP‬או‬

‫‪( TEST‬לדוגמה מיקרוסופט במקרים מסויימים)‪.‬‬ ‫‪‬‬

‫אחד הלקוחות תאר מצב שבו משנעים קלטות עם‬

‫‪ BRINX‬לאתר גיבוי‪ .‬ספציפית לאחר‬

‫שכותבים את הקלטת מייד מוציאים את הקלטות‪.‬‬ ‫‪‬‬

‫אחד הלקוחות ציין שהם תחת רגולציה – אבל הרגולציה ניתנת לפירוש בצורה שונה‪ .‬מספיק‬ ‫להציג שיש תוכנית‪ .‬הרגולציה בתוקף רק מ‪ -‬יולי ‪.2007‬‬

‫‪Page 9 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫טבלה של רמות ‪ DRP‬שונות כולל התייחסות לעלות‬ ‫ניתן לפנות אלי בכדי לקבל את הטבלה בפורמט נוח\קריא יותר ( ‪.)PPT‬‬

‫‪Page 10 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫תגובות של ספקים‬ ‫מטריקס‬ ‫התייחסות לנושא ה ‪ DR‬והדרישות שהועלו על ידי הלקוחות‪:‬‬ ‫פתרון תוכנה שאינו תלוי ביצרן האחסון מבטיח את היכולת לשלב תשתית אחסון שונה וזולה‬ ‫יחסית באתר ‪( DR‬יצרן שונה או פתרון אחסון שונה) ובכך להבטיח חיסכון כספי ניכר‬ ‫בבחירת פתרון המשלב הגנת נתונים ורפלקציה בתוכנה ומבטיח גמישות בבחירת תשתית‬ ‫האחסון באתר ‪DR‬‬ ‫פתרון רפלקציה סלקטיבית (‪ )Selective Replication‬מבטיח שליטה על המידע העסקי‪,‬‬ ‫קריטי שיועבר לאתר ‪ DR‬בצורה מאובטחת ודחוסה‪ .‬בצורה זאת מובטח ניצול יעיל של רוחב‬ ‫הפס ושטחי האחסון המנוצלים בפועל עפ"י זמינות רוחב הפס וקריטיות האפליקציה‪.‬‬ ‫מעבר לכך ‪ -‬במקרי תקלת תשתית ברמת ‪ WAN‬לא נדרשת חזרה על תהליך הרפלקציה‬ ‫מההתחלה‪ .‬למעשה‪ ,‬עם תיקון תקלת התשתית ברמת‬

‫‪ WAN‬ימשיך תהליך הרפלקציה‬

‫החל מנקודת הכשל וללא צורך בחזרה על כל תהליך השכפול מההתחלה (‬

‫‪Self Healing‬‬

‫‪.)Replication‬‬ ‫שימוש בפתרון תוכנה המבוסס על קשר הדוק עם מיקרוסופט ‪-‬‬

‫‪Gold Certified Partner‬‬

‫‪ Microsoft‬ברמת המפתח מבטיח תאימות מלאה עם מגוון מערכות הפעלה מבוססות‬ ‫‪ Windows‬ואינטגרציה מלאה עם טכנולוגיות דוגמת‬

‫‪VSS - ((Volume Shadow Copy‬‬

‫‪. Services‬‬ ‫בצורה זאת מתבצע גיבוי חם ויעיל ברמת האפליקציה תוך זיהוי אוטומטי של אפליקציות כגון‬ ‫‪ Oracle, SQL, Exchange‬ומבטיח גיבוי קונסיסטנטי של מסדי נתונים לצורך שיחזור מהיר‬ ‫בעת אסון‪.‬‬ ‫במקרה של השבתת האתר הראשי מתבצע תהליך העברת שליטה לאתר‬ ‫ששרתי יישום חליפיים נכנסים לפעולה כשרתי ייצור בהסתמך על טכנולוגיית‬

‫‪ DR‬החליפי כך‬ ‫‪ BMR‬ו ‪-‬‬

‫‪ Instant Restore‬ובכך מאפשרים גישה למידע המאוחסן במאגר המידע באתר ‪.DR‬‬ ‫פריצת הדרך בטכנולוגית גיבוי בתוכנה ‪ Block level Incremental Forever -‬מבטיחה‬ ‫הקטנה משמעותית של שטחי האחסון הנדרשים תוך עמידה ביעדי זמן מתקצרים של חלון‬ ‫זמן הגיבוי‪ .‬טכנולוגיית ( ‪ – )CDP on Demand- Continuous Data Protection‬מבטיחה‬ ‫מענה מלא לכל דרישות הגנת הנתונים הנגזרות מהפעילות העסקית‪ .‬הגדלת תדירות הגיבוי‬ ‫באופן דרמטי‪ ,‬עד לרמת טרנזקציה בודדת‪ ,‬מבטיחה יכולת שחזור נתונים לטרנזקציה‬ ‫שקרתה בשנייה מסוימת!! תדירות הגיבוי הגבוהה גם מבטיחה הקטנת הסיכון לאבדן מידע‬ ‫עסקי מינימאלי ע"י שיפור מרכיב ‪ RPO: (Recovery Point Objective) =.RPO‬נוסף‬

‫‪Page 11 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫לכך – היכולת לבצע גיבוי חם ויעיל ברמת האפליקציה תוך זיהוי אוטומטי של אפליקציות כגון‬ ‫‪ Oracle, SQL, Exchange‬מבטיחה גיבוי קונסיסטנטי של מסדי נתונים לצורך שיחזור מהיר‬ ‫בעת אסון‪.‬‬ ‫תוספת לסעיף הטכנולוגיות ‪:‬‬ ‫מספר לקוחות התעניינו בטכנולוגיה נוספת שתופסת תאוצה בשוק היא טכנולוגיית ה‪-‬‬

‫‪On‬‬

‫‪ ,line compression‬הטכנולוגיה מסייעת ללקוחות בשיפור היעילות של מערך האחסון ע"י‬ ‫אספקת פתרון שקוף לחלוטין ופשוט להטמעה‪ ,‬המטפל גם בבעיות של גידול מואץ של‬ ‫המידע‪ ,‬רפלקציה של מידע בין אתרי ‪ ,DR‬יכולת לשיפור יכולות ה‪ ,DR -‬הקטנת חלון הגיבוי‬ ‫והשחזור‪ ,‬ביצועי המערכות ועוד‪ .‬כמובן יש לבחון לעומק את יכולת דחיסת המידע בכל ארגון‬ ‫וארגון ע"מ לבחון בשלב הראשון את כדאיות יישום הפתרון וכמו כן חשוב לציין כי הפתרון‬ ‫הקיים כיום בשוק תומך בתצורות אחסון ‪ NAS‬בלבד‪ .‬הפתרון של חברת ‪ Storwize‬הוטמע‬ ‫כבר במספר רב של ארגונים בארץ ובעולם‪.‬‬

‫בינת‬ ‫שולחן עגול ‪DR -‬‬ ‫למרות שנושא ההמשכיות העסקית מקבל יותר תשומת לב מבעבר העניין בו עדיין מושפע‬ ‫מאירועי אסון‪ ,‬שמהווים תזכורת מפחידה‪ ,‬ולא מניהול שוטף של התכניות להמשכיות עסקית‪.‬‬ ‫מאכזב לגלות שוב שנושאי הלפיד הם עדיין מנהלי ה‪ IT -‬שמודעים לקלות היחסית שבה‬ ‫ארגון יכול להיות מושבת ולקושי לאושש את פעילותו בזמן סביר‪ .‬החוסר במודעות בדרגי‬ ‫ההנהלה ובמחלקות העסקיות מקשה על הקצאת תקציבים ועל שיתוף פעולה פנים ארגוני –‬ ‫גורמים קריטיים להצלחת תכנית ‪.BC‬‬ ‫אחת הסיבות לחוסר המודעות והשיתוף ברמות הנהלה בכירות היא חוסר היכולת של‬ ‫ארגונים ליישם תכנית ‪ BC‬בקצב סביר תוך שיתוף גורמים עסקיים‪ .‬בשוק קיימים יועצים‬ ‫לשלב העסקי (‪ ,)BIA‬חברות מנתחי תהליכים‪ ,‬חברות יישום לתשתיות תקשורת‪ ,‬לתשתיות‬ ‫מחשוב‪ ,‬חברות ‪ Hosting‬וכו‪ .‬ריבוי הספקים גורם ליישום ארוך‪ ,‬מסורבל ויקר‪.‬‬ ‫להבדיל מתחומים אחרים בהם ברור שלפני יישום יש אפיון מצד הלקוח‪ ,‬ה"בעלות" הכפויה‬ ‫של המנמר"ים על הנושא והצורך לשלב ‪ 4-5‬ספקים ליישום מלא גורמת להם להתמקד בצד‬ ‫התשתיתי ולנסות לזרזו‪ .‬התוצאה היא יישומים לא זולים שאינם מונחים עסקית אלא מהווים‬ ‫שכפול מצומצם של מערך ה‪ IT-‬הקיים‪.‬‬ ‫בבינת אנו פותרים את הבעייתיות בריבוי ספקים ע"י שילוב מספר חברות בקבוצה ויישום‬ ‫פרוייקטי המשכיות עסקית מקצה לקצה‪ .‬גוף אחד‪ ,‬מובל ע"י מנהל פרוייקט אחד‪ ,‬מבצע את‬ ‫האפיון העסקי והתהליכי מול גורמים עסקיים‪ ,‬מציג ומאשר אותו בהנהלה‪ ,‬מאפיין פתרונות‬

‫‪Page 12 of 13‬‬

‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫טכנולוגיים ולוגיסטיים ומיישם אותם‪ ,‬כולל הקמת אתר ‪ DR‬או שילוב פתרון ‪.Hosting‬‬ ‫היכולת ליישם את כל שלבי הפרוייקט תחת קורת גג אחת חוסכת זמן וכסף ומצמצמת את‬ ‫הטעויות שנגרמות עקב מעבר מידע לא מיטבי בין חברות שונות‪.‬‬

‫מייק תלם‪ ,‬מנהל פיתוח עסקי‬

‫‪Page 13 of 13‬‬