במסמך הזה, Google Cloud Well-Architected Framework: Financial services (FS) perspective, מופיעה סקירה כללית של עקרונות והמלצות לאופטימיזציה של הביצועים של עומסי העבודה של שירותים פיננסיים ב- Google Cloud. ההמלצות במסמך הזה תואמות לעקרון האופטימיזציה של הביצועים ב-Well-Architected Framework.
אופטימיזציה של הביצועים היא דבר מקובל כבר הרבה זמן בתחום השירותים הפיננסיים. הוא עזר לארגונים בתחום השירותים הפיננסיים להתגבר על אתגרים טכניים, וכמעט תמיד היה גורם מאפשר או מאיץ ליצירת מודלים עסקיים חדשים. לדוגמה, כספומטים (שהושקו בשנת 1967) הפכו את תהליך חלוקת המזומנים לאוטומטי, ועזרו לבנקים להקטין את העלויות של פעילות הליבה שלהם. טכניקות כמו עקיפת ליבת מערכת ההפעלה והצמדת שרשורי אפליקציות לליבות מחשוב עזרו להשיג קביעות וזמן אחזור נמוך באפליקציות מסחר. הקיצור בזמני האחזור הוביל לנזילות גבוהה יותר ויציבה יותר בשווקים הפיננסיים, עם מרווחים קטנים יותר.
הענן יוצר הזדמנויות חדשות לאופטימיזציה של הביצועים. היא גם מאתגרת חלק מדפוסי האופטימיזציה שהיו מקובלים בעבר. באופן ספציפי, היתרונות והחסרונות הבאים שקופים יותר וניתנים לשליטה יותר ב-Cloud:
- זמן יציאה לשוק לעומת עלות.
- ביצועים מקצה לקצה ברמת המערכת לעומת ביצועים ברמת הצומת.
- זמינות של כישרונות לעומת גמישות בקבלת החלטות שקשורות לטכנולוגיה.
לדוגמה, התאמת חומרה ומשאבי IT לדרישות מיומנות ספציפיות היא משימה פשוטה בענן. כדי לתמוך בתכנות GPU, אפשר ליצור מכונות וירטואליות מבוססות GPU. אתם יכולים להגדיל את הקיבולת בענן כדי לעמוד בביקוש הגובר, בלי להקצות יותר מדי משאבים. היכולת הזו עוזרת לוודא שעומסי העבודה יכולים להתמודד עם עומסים מקסימליים, למשל בימים של שכר שאינו חקלאי וכשנפחי המסחר גדולים משמעותית מהרמות ההיסטוריות. במקום להשקיע בכתיבת קוד שעבר אופטימיזציה גבוהה ברמת השרתים האישיים (כמו קוד שעבר כוונון עדין בשפת C) או בכתיבת קוד לסביבות מחשוב קונבנציונליות עם ביצועים גבוהים (HPC), אתם יכולים להרחיב את המערכת בצורה אופטימלית באמצעות מערכת מבוזרת מבוססת-Kubernetes עם ארכיטקטורה טובה.
ההמלצות לשיפור הביצועים במסמך הזה מבוססות על העקרונות הבאים:
- התאמה של מדדי הביצועים של הטכנולוגיה למדדים עסקיים מרכזיים
- מתעדפים את האבטחה בלי לפגוע בביצועים בגלל סיכונים לא מוכחים
- שינוי הארכיטקטורה כדי להתאים להזדמנויות ולדרישות חדשות
- התאמת הטכנולוגיה לצרכים העסקיים הנוכחיים והעתידיים
התאמה בין מדדי ביצועים של הטכנולוגיה לבין מדדים עסקיים מרכזיים
יש כמה דרכים למפות את האופטימיזציה של הביצועים לתוצאות של ערך עסקי. לדוגמה, במחלקת מחקר של צד הקנייה, יעד עסקי יכול להיות אופטימיזציה של התפוקה לכל שעת מחקר או מתן עדיפות לניסויים של צוותים עם היסטוריית ביצועים מוכחת, כמו יחסי שארפ גבוהים יותר. בצד המכירה, אפשר להשתמש בניתוח נתונים כדי לעקוב אחרי תחומי העניין של הלקוחות, וכך לתת עדיפות לתפוקה של מודלים של AI שתומכים במחקר הכי מעניין.
חשוב גם לקשר בין יעדי הביצועים לבין מדדי הביצועים המרכזיים (KPI) של העסק, כדי לממן שיפורים בביצועים. למיזמי חדשנות עסקית וטרנספורמציה (שנקראים לפעמים מאמצי שינוי הבנק) יש תקציבים שונים, ויכול להיות שיש להם רמות גישה שונות למשאבים בהשוואה לפעולות רגילות (BAU) או לפעולות הפעלת הבנק. לדוגמה, Google Cloud עזרנו לצוותים לניהול סיכונים ולצוותי הטכנולוגיה של G-SIFI לשתף פעולה עם אנליסטים כמותיים במחלקות שפונות ישירות ללקוחות כדי למצוא פתרון לביצוע חישובים של ניתוח סיכונים (כמו XVA) תוך דקות במקום שעות או ימים. הפתרון הזה עזר לארגון לעמוד בדרישות התאימות הרלוונטיות. בנוסף, המערכת אפשרה לסוחרים לנהל שיחות איכותיות יותר עם הלקוחות שלהם, ויכולה להציע מרווחים קטנים יותר, נזילות גבוהה יותר וגידור משתלם יותר.
כשמתאימים את מדדי הביצועים למדדים עסקיים, כדאי לפעול לפי ההמלצות הבאות:
- כדאי לקשר כל יוזמה טכנולוגית ליעדים העסקיים ולתוצאות המרכזיות (OKR) הרלוונטיים, כמו הגדלת ההכנסות או הרווחים, צמצום העלויות והפחתת הסיכון בצורה יעילה או הוליסטית יותר.
- מתמקדים באופטימיזציה של הביצועים ברמת המערכת. כדאי להסתכל מעבר להפרדה המקובלת בין שינוי הבנק לבין ניהול הבנק, ולמחסומים בין המשרד הקדמי למשרד האחורי.
מתעדפים את האבטחה בלי לפגוע בביצועים בגלל סיכונים לא מוכחים
האבטחה והעמידה בתקנות בארגונים בתחום השירותים הפיננסיים חייבות להיות ברמה גבוהה ללא עוררין. שמירה על סטנדרט גבוה חיונית כדי למנוע אובדן של לקוחות ונזק בלתי הפיך למותג של הארגון. לרוב, הערך הגבוה ביותר מתקבל באמצעות חידושים טכנולוגיים כמו AI גנרטיבי ושירותים מנוהלים ייחודיים כמו Spanner. אל תפסלו אוטומטית אפשרויות טכנולוגיות כאלה בגלל תפיסה מוטעית כללית לגבי סיכון תפעולי גבוה או סטטוס העמידה בהוראות הדין שאינו מספק.
Google Cloud עבדה בשיתוף פעולה הדוק עם G-SIFIs כדי לוודא שאפשר להשתמש בגישה מבוססת-AI למניעת הלבנת הון (AML) בכל תחומי השיפוט שבהם המוסדות מספקים שירותים ללקוחות. לדוגמה, HSBC שיפרה באופן משמעותי את הביצועים של היחידה שלה לפשעים פיננסיים (Fincrime) עם התוצאות הבאות:
- כמעט פי שניים עד פי ארבע יותר פעילות חשודה מאומתת.
- עלויות תפעול נמוכות יותר כי יותר מ-60% מהתוצאות החיוביות הכוזבות בוטלו, והזמן שמוקדש לחקירה מתמקד רק בהתראות בסיכון גבוה שדורשות פעולה.
- פלט שניתן לביקורת וכולל הסברים, כדי לתמוך בעמידה בתקנות.
כדאי לשקול את ההמלצות הבאות:
- מוודאים שהמוצרים שבהם אתם מתכוונים להשתמש יכולים לעזור לכם לעמוד בדרישות האבטחה, העמידות והתאימות של תחומי השיפוט שבהם אתם פועלים. כדי להשיג את המטרה הזו, צריך לעבוד עם Google Cloud צוותי ניהול חשבונות, צוותי ניהול סיכונים וצוותי מוצרים.
- ליצור מודלים חזקים יותר ולספק שקיפות ללקוחות באמצעות הסברים מבוססי-AI (לדוגמה, שיוך ערך Shapley). טכניקות כמו שיוך ערך Shapley יכולות לשייך החלטות של מודלים לתכונות מסוימות ברמת הקלט.
כדי להשיג שקיפות לגבי עומסי עבודה של AI גנרטיבי, אפשר להשתמש בטכניקות כמו ציטוט מקורות, הארקה ו-RAG.
אם ההסבר לא מספיק, כדאי להפריד את שלבי קבלת ההחלטות בזרמי הערך ולהשתמש ב-AI כדי לבצע אוטומציה רק של השלבים שלא קשורים לקבלת החלטות. במקרים מסוימים, יכול להיות ש-AI שניתן להסבר לא יספיק או שתהליך מסוים ידרוש התערבות אנושית בגלל בעיות רגולטוריות (לדוגמה, GDPR, סעיף 22). במקרים כאלה, צריך להציג את כל המידע שהנציג האנושי צריך כדי לקבל החלטות בחלונית בקרה אחת, אבל להפוך לאוטומטיות את המשימות של איסוף הנתונים, ההטמעה, העיבוד והסיכום.
שינוי הארכיטקטורה כדי להתאים להזדמנויות ולדרישות חדשות
הרחבת הארכיטקטורות הנוכחיות באמצעות יכולות מבוססות-ענן יכולה לספק ערך משמעותי. כדי להשיג תוצאות משמעותיות יותר, צריך לחשוב מחדש על הארכיטקטורה שלכם מעת לעת באמצעות גישת עדיפות לענן.
כדאי לעיין בהמלצות הבאות כדי לשפר את הביצועים עוד יותר, ולחשוב מחדש על הארכיטקטורה של עומסי העבודה שלכם מדי פעם.
שימוש בחלופות מבוססות-ענן למערכות ולמתזמנים של HPC מקומיים
כדי ליהנות מגמישות גבוהה יותר, מאבטחה משופרת ומניטור נרחב ויכולות ניהול, אתם יכולים להריץ עומסי עבודה של HPC בענן או להעביר עומסי עבודה מקומיים לענן. עם זאת, במקרים מסוימים של שימוש במודלים מספריים, כמו סימולציה של אסטרטגיות השקעה או מודלים של XVA, שילוב של Kubernetes עם Kueue עשוי להציע פתרון יעיל יותר.
מעבר לתכנות מבוסס-גרפים לסימולציות
סימולציות מונטה קרלו עשויות להיות יעילות הרבה יותר במערכת הפעלה מבוססת-גרף כמו Dataflow. לדוגמה, HSBC משתמשת ב-Dataflow כדי להריץ חישובי סיכון במהירות גבוהה פי 16 בהשוואה לגישה הקודמת שלה.
הפעלת פלטפורמות מסחר ובורסות מבוססות-ענן
משיחות עם לקוחות עולה שעקרון 80/20 של פרטו חל על דרישות הביצועים של שווקים ואפליקציות מסחר. Google Cloud
- יותר מ-80% מהאפליקציות למסחר לא צריכות חביון נמוך במיוחד. עם זאת, הם נהנים מיתרונות משמעותיים בזכות יכולות העמידות, האבטחה והגמישות של הענן. לדוגמה, BidFX, פלטפורמה רב-עסקית למטבע חוץ, משתמשת בענן כדי להשיק מוצרים חדשים במהירות ולהגדיל באופן משמעותי את הזמינות והנוכחות שלה בלי להגדיל את המשאבים.
- לשאר האפליקציות (פחות מ-20%) נדרשת השהיה נמוכה (פחות ממילישנייה), דטרמיניזם והוגנות במסירת ההודעות. בדרך כלל, המערכות האלה פועלות במתקנים קשיחים ויקרים שמוקצים ללקוחות שונים. יותר ויותר אפליקציות מהקטגוריה הזו עוברות פלטפורמה לענן, או כקצה או כאפליקציות בעדיפות לענן.
התאמת הטכנולוגיה לצרכים העסקיים בהווה ובעתיד
בעבר, ארגונים רבים בתחום השירותים הפיננסיים פיתחו טכנולוגיות קנייניות כדי להשיג יתרון תחרותי. לדוגמה, בתחילת שנות ה-2000, לבנקים להשקעות ולחברות מסחר מצליחות היו הטמעות משלהן של טכנולוגיות בסיסיות כמו מערכות pub-sub וברוקרים של הודעות. עם התפתחות טכנולוגיות הקוד הפתוח והענן, טכנולוגיות כאלה הפכו למוצרים ולא מציעות ערך עסקי מצטבר.
כדי להכין את הטכנולוגיה שלכם לעתיד, כדאי לפעול לפי ההמלצות הבאות.
אימוץ גישה של נתונים כשירות (DaaS) כדי לקצר את זמן היציאה לשוק ולשפר את שקיפות העלויות
ארגונים בתחום השירותים הפיננסיים מתפתחים בדרך כלל באמצעות שילוב של צמיחה אורגנית ומיזוגים ורכישות (M&A). כתוצאה מכך, הארגונים צריכים לשלב טכנולוגיות שונות. הם צריכים גם לנהל משאבים כפולים, כמו ספקי נתונים, רישיונות לנתונים ונקודות שילוב. Google Cloud מספקת הזדמנויות ליצירת ערך מובחן בשילובים לאחר מיזוג.
לדוגמה, אפשר להשתמש בשירותים כמו BigQuery sharing כדי לבנות פלטפורמת נתונים כשירות (DaaS) שמוכנה לניתוח. הפלטפורמה יכולה לספק נתוני שוק וגם נתונים ממקורות חלופיים. הגישה הזו מבטלת את הצורך ליצור צינורות נתונים מיותרים, ומאפשרת לכם להתמקד ביוזמות חשובות יותר. בנוסף, החברות הממוזגות או הנרכשות יכולות לייעל במהירות וביעילות את רישוי הנתונים והתשתית שלהן אחרי המיזוג. במקום להשקיע מאמץ בהתאמה ובמיזוג של נתונים ומערכות מדור קודם, העסק המאוחד יכול להתמקד בהזדמנויות עסקיות חדשות.
לבנות שכבת הפשטה כדי לבודד מערכות קיימות ולטפל במודלים עסקיים חדשים
יתרון תחרותי של בנקים כבר לא נובע ממערכת הליבה הבנקאית, אלא משכבת חוויית הלקוח. עם זאת, מערכות בנקאות מדור קודם משתמשות לרוב באפליקציות מונוליטיות שפותחו בשפות כמו Cobol, והן משולבות בכל שרשרת הערך של הבנקאות. השילוב הזה הקשה על הפרדת השכבות של שרשרת הערך, ולכן כמעט בלתי אפשרי לשדרג ולעדכן מערכות כאלה.
אחד הפתרונות להתמודדות עם האתגר הזה הוא שימוש בשכבת בידוד, כמו מערכת לניהול API או שכבת ביניים כמו Spanner, שמשכפלת את ספר הרשומות ומאפשרת מודרניזציה של שירותים באמצעות ניתוח מתקדם ו-AI. לדוגמה, Deutsche Bank השתמשו ב-Spanner כדי לבודד את מערכת הליבה הקיימת שלהם ולהתחיל את תהליך החדשנות שלהם.