במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מופיעה סקירה כללית של עקרונות והמלצות לאופטימיזציה של הביצועים של עומסי העבודה של שירותים פיננסיים ב- Google Cloud. ההמלצות במסמך הזה תואמות לעקרון האופטימיזציה של הביצועים ב-Well-Architected Framework.
אופטימיזציה של הביצועים היא תהליך שקיים כבר הרבה זמן בתחום השירותים הפיננסיים. הוא עזר לארגונים בתחום השירותים הפיננסיים להתגבר על אתגרים טכניים, וכמעט תמיד הוא היה גורם מאפשר או מאיץ ליצירת מודלים עסקיים חדשים. לדוגמה, כספומטים (שהושקו בשנת 1967) הפכו את תהליך חלוקת המזומנים לאוטומטי, ועזרו לבנקים להקטין את העלויות של פעילות הליבה שלהם. טכניקות כמו עקיפת ליבת מערכת ההפעלה והצמדת שרשורים של אפליקציות לליבות מחשוב עזרו להשיג דטרמיניזם וחביון נמוך באפליקציות מסחר. הקיצור של זמני האחזור הוביל לנזילות גבוהה יותר ויציבה יותר בשווקים הפיננסיים, עם מרווחים קטנים יותר.
הענן יוצר הזדמנויות חדשות לאופטימיזציה של הביצועים. הוא גם מאתגר חלק מהדפוסים המקובלים היסטורית של אופטימיזציה. באופן ספציפי, היתרונות והחסרונות הבאים שקשורים לשימוש בענן הם שקופים יותר וניתנים לשליטה רבה יותר ב-Google Cloud:
- זמן יציאה לשוק לעומת עלות.
- ביצועים מקצה לקצה ברמת המערכת לעומת ביצועים ברמת הצומת.
- זמינות הכישרונות לעומת הגמישות של קבלת החלטות שקשורות לטכנולוגיה.
לדוגמה, התאמת חומרה ומשאבי IT לדרישות ספציפיות של מיומנויות היא משימה פשוטה בענן. כדי לתמוך בתכנות GPU, אפשר ליצור מכונות וירטואליות (VM) מבוססות-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 בהשוואה לשיטה הקודמת שלה.
הפעלת פלטפורמות מסחר ובורסות מבוססות-ענן
משיחות עם Google Cloud לקוחות עולה שעקרון פארטו 80/20 רלוונטי לדרישות הביצועים של אפליקציות לשווקים ולמסחר.
- יותר מ-80% מהאפליקציות למסחר לא צריכות חביון נמוך במיוחד. עם זאת, הם נהנים מיתרונות משמעותיים של יכולות החוסן, האבטחה והגמישות של הענן. לדוגמה, BidFX, פלטפורמה רב-עסקית למטבע חוץ, משתמשת בענן כדי להשיק מוצרים חדשים במהירות ולהגדיל באופן משמעותי את הזמינות והנוכחות שלה בלי להגדיל את המשאבים.
- לשאר האפליקציות (פחות מ-20%) נדרשת השהיה נמוכה (פחות ממילישנייה), דטרמיניזם והוגנות במסירת ההודעות. בדרך כלל, המערכות האלה פועלות במתקנים קשיחים ויקרים שמוקצים ללקוחות שונים. יותר ויותר אפליקציות מהקטגוריה הזו עוברות פלטפורמה לענן, או כאפליקציות קצה או כאפליקציות שמתאימות לענן.
הכנת הטכנולוגיה לעתיד כדי לענות על הצרכים העסקיים בהווה ובעתיד
בעבר, ארגונים רבים בתחום השירותים הפיננסיים פיתחו טכנולוגיות קנייניות כדי להשיג יתרון תחרותי. לדוגמה, בתחילת שנות ה-2000, לבנקים להשקעות ולחברות מסחר מצליחות היו הטמעות משלהן של טכנולוגיות בסיסיות כמו מערכות pub-sub וברוקרים של הודעות. עם התפתחות הטכנולוגיות של קוד פתוח והענן, טכנולוגיות כאלה הפכו למוצרים ולא מציעות ערך עסקי מצטבר.
כדי להכין את הטכנולוגיה שלכם לעתיד, כדאי לפעול לפי ההמלצות הבאות.
אימוץ גישה של נתונים כשירות (DaaS) כדי לקצר את זמן היציאה לשוק ולשפר את שקיפות העלויות
ארגונים בתחום השירותים הפיננסיים מתפתחים בדרך כלל באמצעות שילוב של צמיחה אורגנית ומיזוגים ורכישות (M&A). כתוצאה מכך, הארגונים צריכים לשלב טכנולוגיות שונות. הם גם צריכים לנהל משאבים כפולים, כמו ספקי נתונים, רישיונות לנתונים ונקודות שילוב. Google Cloud מספקת הזדמנויות ליצירת ערך מובחן בשילובים לאחר מיזוג.
לדוגמה, אפשר להשתמש בשירותים כמו שיתוף ב-BigQuery כדי לבנות פלטפורמת נתונים כשירות (DaaS) שמוכנה לניתוח. הפלטפורמה יכולה לספק נתוני שוק וגם נתונים ממקורות חלופיים. הגישה הזו מבטלת את הצורך ליצור צינורות נתונים מיותרים, ומאפשרת לכם להתמקד ביוזמות חשובות יותר. בנוסף, החברות הממוזגות או הנרכשות יכולות לייעל במהירות וביעילות את רישוי הנתונים והתשתית שלהן אחרי המיזוג. במקום להשקיע מאמץ בהתאמה ובמיזוג של נתונים ומערכות מדור קודם, העסק המאוחד יכול להתמקד בהזדמנויות עסקיות חדשות.
לבנות שכבת הפשטה כדי לבודד מערכות קיימות ולטפל במודלים עסקיים חדשים
יתרון תחרותי של בנקים כבר לא מתבסס על מערכת הליבה הבנקאית, אלא על שכבת חוויית הלקוח. עם זאת, מערכות בנקאות מדור קודם משתמשות לרוב באפליקציות מונוליטיות שפותחו בשפות כמו Cobol, והן משולבות בכל שרשרת הערך של הבנקאות. השילוב הזה הקשה על הפרדת השכבות של שרשרת הערך, ולכן היה כמעט בלתי אפשרי לשדרג ולעדכן מערכות כאלה.
אחד הפתרונות להתמודדות עם האתגר הזה הוא שימוש בשכבת בידוד, כמו מערכת לניהול API או שכבת ביניים כמו Spanner, שמשכפלת את ספר הרשומות ומאפשרת מודרניזציה של שירותים באמצעות ניתוח מתקדם ו-AI. לדוגמה, Deutsche Bank השתמשו ב-Spanner כדי לבודד את מערכת הליבה של הבנק ולהתחיל את תהליך החדשנות שלהם.