אם מישהו היה אומר לי לפני שבועיים שייתכן מצב שבו בנק פועלים סובל מתקלה שמנטרלת את מערך המחשוב שלו ליומיים שלמים, הייתי חושב שהוא מקשקש.
כשמפעילים מערכת קריטית – ובנק הוא מערכת קריטית, חשוב לבנות את המערכת עם מנגנוני יתירות (redundancy) ככה שגם כשמשהו קורס (ומשהו יקרוס בשלב מסויים, זה ברור), המערכת כולה לא תקרוס כי משהו יתפוס את מקומו בצורה שקופה.
דוגמאות לזה אפשר לראות בהרבה מקומות, למשל:
- שרתי DNS תמיד מוגדרים לפחות בזוגות, ככה שאם הראשון נופל השני תופס את מקומו והמשתמשים אפילו לא יודעים שמשהו קרה.
- ברוב תצורות הRAID, אם נופל כונן קשיח המערכת ממשיכה לעבוד כרגיל, ואפשר להחליף אותו בלי לאבד נתונים.
- אפשר ורצוי להגדיר את הDNS בצורה כזו שאם שרת דואר נופל, שרת דואר חלופי יקבל את ההודעות בצורה שקופה למי ששולח את הדואר.
- יש לנו שתי ריאות, שני כבדים, שתי כליות, שתי עיניים, שתי אוזניים.. 🙂
הנקודה היא שמי שלוקח את עצמו ברצינות, ידאג שלא תהיה לו נקודת כשל יחידה.
לפני כמה ימים המחשב המרכזי של בנק הפועלים קרס "עקב תקלה נדירה במערכת ההפעלה", ובנק פועלים היה מושבת ליומיים, בהם הבורסה טולטלה, ולקוחות בנק הפועלים לא יכלו להגיב.
בתור מערכת קריטית, בנק הפועלים אמור היה להיות חסין לקריסה כזו, ובכל זאת "תקלה נדירה" הצליחה להפיל אותו.
במערכת עם יתירות, יש הסתברות מסויימת לכך שתהיה קריסה של כל אחד מהרכיבים, נניח שהמערכת היא שרת עם מערך RAID, ונניח שהכוננים הקשיחים הם ממש דפוקים והסתברות לקריסה של אחד מהם בכל רגע נתון הוא 1%.
נניח גם שהמערכת מסוגלת להתמודד עם כונן אחד שקרס בלי לאבד מידע, אבל לא עם שניים.
עכשיו – מה הסיכוי ששני כוננים קשיחים יקרסו באותו רגע?
ההסתברות במקרה הזה היא מכפלת ההסתברויות להסתברות לארוע בודד, כלומר 0.01% (זאת כמובן בהנחה שהמאורעות בלתי תלויים, דוגמא למאורעות תלויים היא הפסקת חשמל שגרמה לקצר שדפק שני כוננים).
בצורה דומה ההסתברות לקריסה של שלושה כוננים היא כבר 0.0001% וכן הלאה.
אפשר לראות שככל שהיתירות שלנו גדלה בכל נקודה קריטית, הסיכוי לארוע שיפיל את המערכת קטנה בצורה מאוד מהירה, אבל היא עדיין קיימת. הנקודה היא שאם מבינים את המערכת בצורה טובה, אפשר לשלוט בהסתברות לארוע קטסטרופלי ולהקטין אותו עד לרמה נמוכה מספיק (למשל רמה כזו שההסתברות לרעידת אדמה שתמחק את ישראל היא הרבה יותר גבוהה).
כמובן שבעולם האמיתי דברים מסתבכים, כי בדרך כלל יש תלות בין רכיבים והרבה פעמים קריסה של רכיב אחד גורמת תגובה שרשרת שיכולה להפיל רכיב אחר לגמרי.
כל זה עדיין לא מצדיק את הקריסה של המחשב של בנק הפועלים, שלדעתי עלתה להם מליונים רבים ועוד תעלה להם מליונים רבים עוד יותר כשיפגע בהם גל התביעות.
מה לדעתכם קרה שם?
שני כבדים? ידעתי שדפקו אותי 🙂
קצת מוזר שזה קורה בדיוק בזמן של משבר שמערער את הבנקים בישראל. קצת נוח מדי.
"כל זה עדיין לא מצדיק את הקריסה של המחשב של בנק הפועלים, שלדעתי עלתה להם מליונים רבים ועוד תעלה להם מליונים רבים עוד יותר כשיפגע בהם גל התביעות."
אני לא אוהב להיות קונספירטור, אבל אני משער שבלי ה"קריסה" הזאת הם היו מפסידים הרבה יותר.
או זה או שהתוכי של שרי אריסון (זה שהשלום מתחיל ממנו) עף מוטרף לחלוטין דרך החלון וזרע הרס במאגר המידע שלהם תוך כדי קריאות "לא עופר! לא עופר! לא לעשות כואב!"
משה, אבל יצאת קונספירטור.
תסביר לי איך בדיוק הבנק חסך לעצמו הפסדים בזה שיזם "קריסה" של יומיים.
אין לי ספק שלבנק הפועלים יש מערכות גיבוי ויתירות. הם לא אידיוטים. כרגיל במקרים של תקלות IT קטסטרופליות, יש פה כנראה שרשרת כשלים – מישהו עשה טעות, מישהו אחר לא שם לב, מערכת הגיבוי במקרה לא פעלה וכו'.
לאור ההשפעה האדירה של התקלה הזו, אני יכול לשער שהתקלה היא במיינפריים של הבנק (רמז: ב-YNET היה כתוב שמומחי IBM מטפלים בבעיה). להחזיק מיינפריים נוסף למקרה קריסה זה דבר די יקר.
אגב, לתקלה כזו, פרט לנזקים הישירים ולחשיפה לתביעות, יש גם סכנה נוספת – אם גופי דירוג בינלאומיים יחליטו שהבנק לא מספיק אמין, הוא ייפגע בצורה מאוד קשה. אני חושב שאפשר לשלול את תאוריית הקונספירציה של משה שרף.
למה יומיים?
עוד היה להם בלאגאן רציני אתמול יום ד' ארבעה ימים אחרי תחילת התקלה.
לפי מה שהבנתי זה היה "שדרוג שהתפקשש". מצחיק שאנשים עוד לא קלטו ששדרוגים לא עושים ישירות על גרסת הלקוח, אלא על גרסה בצד קודם כל בשביל בדיקות. לא יאומן כמה אנשים אני מכיר שלא מבינים את הקונספט הקטן הזה וכל שינוי עושים אמנם בחרדת קודש, אבל ישירות על המערכת שב-production.
לעמרי (ורואה שחורות). אני לא באמת חושב שזו קונספירציה. חשבתי שעניין התוכי מבהיר את זה, מסתבר שלא,מצטער על אי ההבנה.
אם המשבר היה מקומי (משהו כמו "השפל הגדול") ואנשים היו מנסים למשוך את כל חסכונותיהם היה בכך הגיון מסוים.
אני עצמי מסכים עם קישון שכתב פעם שאין שום סודות גדולים ומניעים נסתרים מאחרי פעולות תמוהות של גופים גדולים, רק טימטום עממי ופשוט לחלוטין.
(ההצעה של הבנק לפטור לקוחות מעמלות על תקופה בה לא היה ניתן לבצע פעולות הינה דוגמה מעולה לטימטום שכזה).
על פי "אנשים ומחשבים", אכן מדובר במיינפריים – תקלה בבסיס הנתונים DB2 שהוחרפה ע"י טעות אנוש בהפעלת מערכת ההתאוששות (DRP)
http://www.pc.co.il/Index.asp?ArticleID=23255&CategoryID=72
עומר, הנקודה עם שדרוגים היא שמתישהו צריך לגעת במערכת הפרודקשן, ואז דברים יכולים להידפק גם אם בדקת את זה 100 פעם קודם במערכת בדיקות.
משה, איש צודק היה קישון.
דור, תודה.
הבעיה עם תרחישי שרידות היא התמודדות עם כשלים לוגיים. כולם ערוכים לנפילת טילים, אבל מה קורה אם יש לך מערכת יתירות בזמן אמת (אתר חם המגבה אתר ייצורי); שדרגת את האתר הייצורי ועלית לאוויר. אם אתה מאפשר יתירות בזמן אמת ויש לך תקלה לוגית במערכת הייצורית היא תשוכפל גם למערכת המשנית. אם אתה עולה בלי יתירות אז זה לא יקרה, אך גם לא יהיה לך גיבוי. זו לא סוגיה טריוויאלית ואני לא בטוח כמה ארגונים יודעים איך להתמודד עם מצב כזה. צריך גם לזכור שגם סביבת בדיקות לרוב אינה מדמה במלואה סביבה ייצורית. תתכן תקלה נדירה בסביבת הייצור שלא תופיע בסביבת הבדיקות. במצב כזה ייתכן ששני האתרים יקרסו והמערכת תצטרך לבצע rollback לגרסה קודמת. אך עם נתונים בנקאיים עולה השאלה – כמה אחורה ניתן לחזור ושזה יהיה רלוונטי? זה לא שרת web וגם לא DNS.
בקיצור, זה לא טריוויאלי. אני מניח שהתקלה לא הייתה ספק כוח שנשרף. אני מקווה שיהיו ממצאים שיתפרסמו כדי שניתן יהיה להפיק לקחים לטובת הכלל.
עומר, ברור שזו לא סוגיה טריוויאלית, ועצם העובדה שבנק הפועלים הצליח להתאושש בתוך כמה ימים בלבד היא נקודה לזכותם.
ועדיין, מישהו פישל.
גם אני הייתי רוצה לשמוע הסבר טכני על מה קרה שם, ורוב הסיכויים שהסבר כזה יודלף על ידי IBM או על ידי בנק הפועלים ברגע שהתמונה תתבהר (תלוי מי אשם)
כן, מאחר ויש איזו מלחמת האשמות בין הבנק ובין IBM, סביר להניח שהצד שאינו אשם ידליף את הסיבה. אבל יכול גם להיות שהצד שכן אשם ידליף גרסה שקרית…
מה עם פריימריז הנופלים?
קצת פחות מקורי אבל עדיין
פשוט מבייש מה שקורה בארץ בתחום המערכות מידע
עמרי, מסכים שבנקודות מסוימות, סביבת ה-Production יכולה להיפגע גם כן, ללא קשר לבדיקות מקדימות (שאף פעם לא יוכלו לכסות 100% מהמקרים). אם המערכת מבוססת על מערך RAID מספיק מורכב, ניתן לגבות את המידע בצורה יעילה ולבצע שחזור של המידע במהירות יחסית. למרות זאת, יש כאן בעייתיות מסוימת ואני מסכים עם דעתך.