אילו לקחים יש להפיק מתקלת המחשוב החמורה בבריטיש איירווייז?

קריסת מערכות מחשוב כללית היא סיוט לילה "פופולרי" בקרב מנהלי מערכות מידע ומומחי טכנולוגיה. סיוט זה היה למציאות במקרה של חברת התעופה בריטיש איירווייז (British Airways) במהלך סוף שבוע של חופשת הבנקים האביבית.

הקריסה גרמה לביטול מוחלט של כל טיסות החברה משדות התעופה הית'רו (Heathrow) ולונדון גטוויק (London Gatwick), לפגיעה בתוכניות הטיסה והחופשה של מעל ל-75 אלף נוסעים ובלאגן מוחלט בטיפול במזוודות, לצניחה של מאות מיליוני ליש"ט בשווי החברה ולתחזית פיצויים עתידיים בסכום שמוערכת ב-150 מיליון ליש"ט, כך לפי הגרדיאן (Guardian).

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

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

כך או אחרת, השאלה הנשאלת היא האם יש לקחים מיידים שכל עסק או ארגון IT חייב להפיק מהתקרית של חברת התעופה? לדעתי יש שלושה כאלה:

● פשטו את ארכיטקטורת מערכות המידע

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

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

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

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

ההשקעה של ה-IT בתוכנית התאוששות מאסון (DRP) צמחה מהותית לאורך השנים בשל רגולציה ויוזמות לניהול סיכונים עסקיים.

הקריסה של בריטיש איירווייז היא הזדמנות טובה להרהר על היעילות של ה-DRP. אם ברגע האמת ה-DRP שלכם לא עובד, האם עליכם להטיל ספק בכל השקעה בפתרון DR?

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

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

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

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

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

● ניהול המשבר בתקשורת

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

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

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

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

הכותב הינו אסטרטג פתרונות עסקיים ראשי ב-VMware ישראל.