רעידת אדמה באיטליה – מחשבות על DRP

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

שלוש המלצות מסוג "אל תעשה" לגבי טיול בחבל ארץ יפה זה:

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

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

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

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

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

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

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

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

להלן רשימה של שאלות לדוגמא שיש לספק עבורן מענה על מנת לייצר באופן נכון את רמות ה SLA בארגון:

1. האם הארגון מסוגל לסבול השבתה חלקית של מערכות המידע? מה הנזק הכספי שיגרם לארגון מהשבתה שכזו?
2. האם הארגון מסוגל לסבול השבתה מלאה של מערכות המידע? מה הנזק הכספי שיגרם לארגון מהשבתה שכזו?
3. האם קיימת אפליקציה קריטית שבלעדיה רוב הפעילות העסקית בארגון אינה יכולה להתקיים? מה הנזק הכספי שיגרם לארגון מהשבתה שכזו?
4. האם הארגון מסוגל לסבול השבתה חלקית של אפליקציה קריטית? מה הנזק הכספי שיגרם לארגון מהשבתה שכזו?
5. מה משך ההשבתה המקסימלי שהארגון מסוגל לספוג מבלי להיפגע מבחינה עסקית? מה הנזק הכספי שיגרם לארגון בחריגה מפרק הזמן המוגדר?
6. האם קיימת אפליקציה בארגון שבלעדיה יגרם נזק תדמיתי לארגון מצד הלקוחות? הספקים? בעלי המניות? הרגולטורים הרלוונטיים?

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

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

שלכם,

ניר מליק