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