איך הבנק נכשל?

העברת תשתית IT כושלת הביאה לשחיתות של 1,3 מיליארד רשומות של לקוחות בנק. כל זה נבע מבדיקות לא מספקות ויחס קל דעת כלפי מערכות IT מורכבות. Cloud4Y מספר איך זה קרה.

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

מעטים האנשים שאוהבים לשלם כסף לאקסים שלהם, אז ב-22 באפריל 2018 בשעה 18:00 החל TSB את השלב האחרון של תוכנית של 18 חודשים שאמורה הייתה לשנות הכל. תוכנן להעביר מיליארדי רישומי לקוחות למערכת ה-IT של חברת Banco Sabadell הספרדית, שרכשה את TSB ב-2,2 מיליארד דולר עוד ב-2015.

מנכ"ל Banco Sabadell, José Olu, דיבר על האירוע הקרוב שבועיים לפני חג המולד 2 במהלך פגישת צוות חגיגית באולם כנסים יוקרתי בברצלונה. כלי ההגירה החשוב ביותר היה להיות גרסה חדשה של המערכת שפותחה על ידי Banco Sabadell: Proteo. שמו אפילו שונה ל-Proteo2017UK במיוחד עבור פרויקט ההגירה של TSB.

בהצגת Proteo4UK, מנכ"ל Banco Sabadell, ג'יימה גווארדיולה רומוג'רו, התגאה בכך שהמערכת החדשה היא פרויקט רחב היקף שאין לו אנלוגים באירופה, עליו עבדו למעלה מ-1000 מומחים. ושהיישום שלו יספק דחיפה משמעותית לצמיחת Banco Sabadell בבריטניה.

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

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

התברר שהמהנדסים היו עצבניים מסיבה טובה.

בדל באתר שלקוחות ראו יותר מדי זמן

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

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

בשעה 21:00, נציגי TSB הודיעו לרגולטור הפיננסי המקומי (הרשות להתנהלות פיננסית בבריטניה, FCA) שהבנק בבעיה. אבל ה-FCA כבר שם לב: TSB באמת פישל קשות, והלקוחות הפכו לטיפשים. וכמובן, הם התחילו להתלונן רשתות חברתיות (וכיום, להוריד כמה שורות בטוויטר או בפייסבוק זה לא קשה במיוחד). בשעה 23:30 פנה ל-FCA רגולטור פיננסי אחר, הרשות לתקנות זהירות (PRA), שגם הוא חש שמשהו לא בסדר.

כבר הרבה אחרי חצות הם הצליחו לעבור לאחד מנציגי הבנק. ותשאל אותם את השאלה היחידה: "מה לעזאזל קורה?"

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

כך נראה הבנק המקוון של לקוחות TSB

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

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

קצת היסטוריה

הכספומט הראשון נפתח ב-27 ביוני 1967 ליד ברקליס באנפילד

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

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

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

כספומטים היו רק ההתחלה. עד מהרה אנשים הצליחו להתחמק מהתור בקופה על ידי התקשרות טלפונית לבנק. לשם כך נדרשו כרטיסים מיוחדים שהוכנסו לקורא המסוגלים לפענח את האותות הרב-תדרים בגוונים כפולים (DTMF) המשודרים כאשר המשתמש לחץ על מקש "1" (משיכת כסף) או "2" (הפקדת כספים).

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

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

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

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

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

ללא מבחנים - היכונו לבעיות

מנכ"ל בנקו דה סבאדל, חיימה גווארדיולה (משמאל) היה בטוח שהכל יעבור חלק. לא הסתדר.

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

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

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

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

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

בנקים בריטיים (וגם אחרים) שואפים להגיע לרמת זמינות של ארבע-תשע, כלומר 99,99%. בפועל, המשמעות היא שמערכת ה-IT חייבת להיות זמינה בכל עת, עם השבתה של עד 52 דקות בשנה. שיטת "שלוש התשע", 99,9%, במבט ראשון אינה שונה בהרבה. אבל במציאות זה אומר שזמן ההשבתה מגיע ל-8 שעות בשנה. עבור הבנק, "ארבע תשע" זה טוב, אבל "שלוש תשע" לא.

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

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

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

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

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

תוצאות של

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

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

קמצנות עם IT כרוכה בסופו של דבר במחיר. TSB דיווחה על הפסד של 134 מיליון דולר ב-2018, לעומת רווח של 206 מיליון דולר ב-2017. עלויות לאחר ההגירה, לרבות פיצויי לקוחות, תיקון עסקאות הונאה (שעלו בחדות במהלך הכאוס הבנקאי), וסיוע צד שלישי, הסתכמו ב-419 מיליון דולר. גם ספקית ה-IT של הבנק חויבה ב-194 מיליון דולר על תפקידה במשבר.

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

מה עוד אפשר לקרוא בבלוג? Cloud4Y

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

הירשם למנוי שלנו מברק-ערוץ כדי לא לפספס את המאמר הבא! אנו כותבים לא יותר מפעמיים בשבוע ורק לעסקים.

מקור: www.habr.com