וופל בלגי אמיתי

כך תבטיחו המשכיות עסקית ורציפות מבצעית ותפעולית

באחד מטוריו בידיעות אחרונות, סיפר יאיר לפיד על התלאות שהוא ואימו עברו מול מוקד שירות הלקוחות של אחת מחברות הסלולר, בעניין חשבון על שם אביו, יוסף (טומי) לפיד ז"ל. בשלב מסוים ביקש נציג השירות, ניב, מהגברת לפיד שתשלח לו משהו בפקס – משהו שהיא כבר שלחה בעבר. על זה כתב לפיד: "היא אמרה ששלחה כבר, אבל ניב לא ראה את זה במחשב. הם אף פעם לא רואים את זה במחשב. לדעתי אין להם מחשב, יש רק פתק שעליו כתוב בגדול 'אני מצטער גברת, זה לא מופיע אצלי במחשב'".

התפקעתי מצחוק, עד שבא לי לבכות! למה צחקתי? כי זה היה מצחיק, כמו שאומרים הגששים. למה בא לי לבכות? כי זה סיפור עצוב שמציג את המיחשוב באור לא מחמיא. למה זה קורה? איך זה שעם כל ההתקדמות הטכנולוגית ויישום מערכות משוכללות שמושקע בהן הון תועפות, עדיין דברים בסיסיים לא עובדים? איך זה שעדיין, למעלה מחמישים שנה אחרי שהחל עידן המיחשוב המסחרי, נציגי שרות נאלצים לא פעם להגיד ללקוח משפטים דוגמת "רגע, נתקע לי המחשב", "אני לא רואה את זה במחשב, שלח לי שוב", "אי אפשר לשלם עכשיו באשראי כי אין תקשורת" וכיוצא באלו האשמות כלפי "המחשב"?

סיפור נוסף: מכריי מודעים לחיבתי למתוק, בפרט שוקולד וגלידות. אני מכור. בחופשה שבילינו בבלגיה, חגגתי על פרלינים ומנות של וופל בלגי. אתם יודעים: וופל רך, נוטלה, גלידה וקצפת, רוטב שוקולד חם (מצטער אם עשיתי לכם חשק). עד שלא אוכלים בבלגיה וופל בלגי, לא יודעים באמת מה זה וופל בלגי. מה שנותנים בארץ כ-וופל בלגי גובל בהונאת הציבור…

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

נכון לנקוט בעניין זה בשלושה צעדים: הראשון הוא בסיסי ומוכר – בניית מערך גיבוי ושרידות, תוך התייחסות לרמת הרכיב הבודד, המערכת הבודדת וברמת האתר (DRP).

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

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

תכנית התרגול צריכה לכלול הרבה תרגילים קטנים, שבודקים גיבוי ושרידות של רכיבים ומערכים, ותרגיל מלא לפחות פעם בשנה. תרגיל מלא – וזה הדגש העיקרי בתוך הדגש העיקרי – משמעו מעבר כל הפעילות לאתר ה-DR, תוך ניתוק התקשורת לאתר הראשי (הוא לא קיים) ועבודה של יום עסקים שלם משם. רק כך אפשר להבטיח שהכל יעבוד כמו שצריך. עשינו כך בבזק, ובזכות תרגיל מלא כזה, איתרנו נקודת כשל שהשביתה מערכת (חיפשה כתובת IP פיזית באתר הראשי) ותיקון פשוט (Virtual IP) פתר את הבעיה.

כמה שהחיים יכולים להיות מתוקים אם רק עושים נכון את הדברים הנכונים!

אלי פרנק, מנכ"ל חברת הייעוץ FrankIT, שימש כסמנכ"ל טכנולוגיות המידע של בזק בין 2006 ל-2012

תגובות

(0)

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

אין לשלוח תגובות הכוללות דברי הסתה, דיבה, וסגנון החורג מהטעם הטוב

אירועים קרובים