במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מופיעה סקירה כללית של עקרונות והמלצות לאופטימיזציה של הביצועים של עומסי העבודה של שירותים פיננסיים ב- Google Cloud. ההמלצות במסמך הזה תואמות לעקרון האופטימיזציה של הביצועים ב-Well-Architected Framework.
אופטימיזציה של הביצועים היא תחום עם היסטוריה ארוכה בשירותים פיננסיים. היא עזרה לארגונים בתחום השירותים הפיננסיים להתגבר על אתגרים טכניים, וכמעט תמיד הייתה גורם מאפשר או מאיץ ליצירת מודלים עסקיים חדשים. לדוגמה, כספומטים (שהושקו בשנת 1967) הפכו את תהליך חלוקת המזומנים לאוטומטי, ועזרו לבנקים להפחית את העלויות של העסק הליבתי שלהם. טכניקות כמו עקיפת ליבת מערכת ההפעלה והצמדת שרשורי אפליקציות לליבות מחשוב עזרו להשיג קביעות וחביון נמוך באפליקציות מסחר. ההפחתה בחביון תרמה לנזילות גבוהה יותר ויציבה יותר עם מרווחים קטנים יותר בשווקים הפיננסיים.
הענן יוצר הזדמנויות חדשות לאופטימיזציה של הביצועים. הוא גם מאתגר חלק מהדפוסים המקובלים היסטורית של אופטימיזציה. באופן ספציפי, היתרונות והחסרונות הבאים שקופים יותר וניתנים לשליטה יותר בענן:
- זמן יציאה לשוק לעומת עלות.
- השוואה בין הביצועים מקצה לקצה ברמת המערכת לבין הביצועים ברמת הצומת.
- זמינות של כישרונות לעומת גמישות בקבלת החלטות שקשורות לטכנולוגיה.
לדוגמה, התאמת חומרה ומשאבי IT לדרישות מיומנות ספציפיות היא משימה פשוטה בענן. כדי לתמוך בתכנות GPU, אפשר ליצור מכונות וירטואליות (VM) מבוססות-GPU. אתם יכולים להגדיל את הקיבולת בענן כדי לעמוד בביקוש הגובר, בלי להקצות יותר מדי משאבים. היכולת הזו עוזרת לוודא שעומסי העבודה יכולים להתמודד עם עומסים מקסימליים, למשל בימים של שכר שאינו חקלאי וכשנפחי המסחר גדולים משמעותית מהרמות ההיסטוריות. במקום להשקיע בכתיבת קוד שעבר אופטימיזציה גבוהה ברמה של שרתים בודדים (כמו קוד שעבר כוונון עדין בשפת C) או בכתיבת קוד לסביבות מחשוב עתיר ביצועים (HPC) רגילות, אתם יכולים להרחיב את המערכת בצורה אופטימלית באמצעות מערכת מבוזרת מבוססת-Kubernetes עם ארכיטקטורה טובה.
ההמלצות לשיפור הביצועים במסמך הזה מבוססות על העקרונות הבאים:
- התאמה בין מדדי הביצועים של הטכנולוגיה לבין מדדים עסקיים מרכזיים
- מתעדפים את האבטחה בלי לפגוע בביצועים בגלל סיכונים לא מוכחים
- שינוי הארכיטקטורה כדי להתאים להזדמנויות ולדרישות חדשות
- הכנת הטכנולוגיה לעתיד כדי לענות על הצרכים העסקיים בהווה ובעתיד
התאמה בין מדדי ביצועים של הטכנולוגיה לבין מדדים עסקיים מרכזיים
יש כמה דרכים למפות את האופטימיזציה של הביצועים לתוצאות של ערך עסקי. לדוגמה, במחלקת מחקר בצד הקנייה, יעד עסקי יכול להיות אופטימיזציה של התפוקה לכל שעת מחקר או מתן עדיפות לניסויים של צוותים עם רקורד מוכח, כמו יחסי שארפ גבוהים יותר. בצד המכירה, אפשר להשתמש בניתוח נתונים כדי לעקוב אחרי תחומי העניין של הלקוחות, וכך לתת עדיפות לתפוקה של מודלים של AI שתומכים במחקרים הכי מעניינים.
חשוב גם לקשר בין יעדי הביצועים לבין מדדי הביצועים המרכזיים (KPI) של העסק כדי לממן שיפורים בביצועים. למיזמי חדשנות עסקית וטרנספורמציה (לפעמים נקראים מאמצי שינוי הבנק) יש תקציבים שונים, ויכול להיות שיש להם רמות גישה שונות למשאבים בהשוואה לפעולות רגילות (BAU) או לפעולות הפעלת הבנק. לדוגמה, Google Cloud עזרנו לצוותי ניהול הסיכונים והטכנולוגיה של G-SIFI לשתף פעולה עם אנליסטים כמותיים במשרד הקדמי כדי למצוא פתרון לביצוע חישובים של ניתוח סיכונים (כמו XVA) תוך דקות במקום שעות או ימים. הפתרון הזה עזר לארגון לעמוד בדרישות התאימות הרלוונטיות. בנוסף, היא אפשרה לסוחרים לנהל שיחות באיכות גבוהה יותר עם הלקוחות שלהם, ויכולה להציע מרווחים קטנים יותר, נזילות גבוהה יותר וגידור חסכוני יותר.
כשמתאימים את מדדי הביצועים למדדים עסקיים, כדאי לפעול לפי ההמלצות הבאות:
- כדאי לקשר כל יוזמה טכנולוגית ליעדים העסקיים ולתוצאות המרכזיות (OKR) הרלוונטיים, כמו הגדלת ההכנסות או הרווח, צמצום העלויות והפחתת הסיכון בצורה יעילה או הוליסטית יותר.
- מתמקדים באופטימיזציה של הביצועים ברמת המערכת. כדאי להסתכל מעבר להפרדה המקובלת בין שינוי הבנק לבין ניהול הבנק, ולמחסומים בין המשרד הקדמי למשרד האחורי.
מתעדפים את האבטחה בלי לפגוע בביצועים בגלל סיכונים לא מוכחים
האבטחה והעמידה בתקנות בארגונים בתחום השירותים הפיננסיים חייבות להיות ברמה גבוהה ללא עוררין. שמירה על סטנדרט גבוה חיונית כדי למנוע אובדן של לקוחות ולמנוע נזק בלתי הפיך למותג של הארגון. לרוב, הערך הגבוה ביותר מתקבל באמצעות חידושים טכנולוגיים כמו AI גנרטיבי ושירותים מנוהלים ייחודיים כמו Spanner. אל תפסלו אוטומטית אפשרויות טכנולוגיות כאלה בגלל תפיסה מוטעית כללית לגבי סיכון תפעולי גבוה או סטטוס העמידה בהוראות הדין שאינו מספק.
Google Cloud עבד בשיתוף פעולה הדוק עם G-SIFI כדי לוודא שאפשר להשתמש בגישה מבוססת-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 כדי לבודד את מערכת הליבה הבנקאית מדור קודם ולהתחיל את תהליך החדשנות שלה.