Well-Architected Framework: נקודת מבט על שירותים פיננסיים (FS)

Last reviewed 2025-07-28 UTC

במסמך הזה ב-Google Cloud Well-Architected Framework מפורטים עקרונות והמלצות שיעזרו לכם לתכנן, לבנות ולנהל אפליקציות של שירותים פיננסיים (FS) ב- Google Cloud , שיעמדו ביעדים התפעוליים, הביטחוניים, האמינותיים, העלותיים והביצועיים שלכם.

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

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

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

בדפים הבאים מתוארים עקרונות והמלצות שספציפיים לעומסי עבודה של FS לכל אחד מהעקרונות של Well-Architected Framework:

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים:

נקודת מבט של שירותים פיננסיים: מצוינות תפעולית

במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מפורטת סקירה כללית של העקרונות וההמלצות לבנייה, לפריסה ולהפעלה של עומסי עבודה חזקים של שירותים פיננסיים ב- Google Cloud. ההמלצות האלה עוזרות לכם להגדיר רכיבים בסיסיים כמו יכולת צפייה, אוטומציה ומדרגיות. ההמלצות במסמך הזה תואמות לעקרון המצוינות התפעולית של Well-Architected Framework.

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

מצוינות תפעולית מספקת את היתרונות הבאים לעומסי עבודה של FS:

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

  • עמידה בדרישות מחמירות של תאימות לתקנות: שירותים פיננסיים כפופים לתקנות רבות ומורכבות, כמו:

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

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

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

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

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

ההמלצות לשיפור התפעול במסמך הזה ממופות לעקרונות הליבה הבאים:

הגדרת הסכמי רמת שירות (SLA) ומדדי SLO ו-SLI תואמים

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

הסכמי רמת שירות (SLA) צריכים להתבסס על מסגרת של מדדים שמייצגים את התנהגות המערכת מנקודת המבט של שביעות רצון המשתמשים. שיטות Site reliability engineering (SRE) מאפשרות להשיג את רמת האמינות הרצויה של המערכת. יצירת מסגרת של מדדים כוללת הגדרה ומעקב של אינדיקטורים מספריים מרכזיים כדי להבין את תקינות המערכת מנקודת המבט של המשתמש. לדוגמה, מדדים כמו זמן האחזור ושיעורי השגיאות מאפשרים לכמת את רמת הביצועים של שירות מסוים. המדדים האלה נקראים מדדי רמת שירות (SLI). פיתוח של מדדי SLI יעילים הוא קריטי, כי הם מספקים את הנתונים הגולמיים שדרושים להערכה אובייקטיבית של מהימנות.

כדי להגדיר הסכמי SLA,‏ SLI ו-SLO משמעותיים, מומלץ לפעול לפי ההמלצות הבאות:

  • פיתוח והגדרה של SLI לכל שירות קריטי. הגדרת ערכי יעד שמגדירים את רמות הביצועים הקבילות.
  • לפתח ולהגדיר את היעדים למדידת רמת השירות (SLO) שמתאימים לאינדיקטורים ברמת השרת (SLI). לדוגמה, יכול להיות ש-SLO יקבע ש-99.9% מהבקשות צריכות להיות עם זמן אחזור של פחות מ-200 אלפיות השנייה.
  • מזהים את פעולות התיקון הפנימיות שצריך לבצע אם שירות לא עומד ביעדי ה-SLO. לדוגמה, כדי לשפר את העמידות של הפלטפורמה, יכול להיות שתצטרכו להקצות משאבי פיתוח לתיקון בעיות.
  • צריך לאמת את הדרישה להסכם רמת שירות (SLA) לכל שירות, ולהכיר בהסכם רמת השירות כחוזה הרשמי עם משתמשי השירות.

דוגמאות לרמות שירות

בטבלה הבאה מופיעות דוגמאות ל-SLI, ל-SLO ול-SLA של פלטפורמת תשלומים:

מדד עסקי SLI SLO הסכם רמת שירות (SLA)
התשלום בוצע בהצלחה

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

דוגמה: (מספר העסקאות המוצלחות חלקי המספר הכולל של העסקאות התקינות) כפול 100, נמדד בחלון של 5 דקות.

יעד פנימי לשמירה על אחוז גבוה של עסקאות תשלום מוצלחות במהלך תקופה מסוימת.

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

התחייבות חוזית לשיעור ההצלחה ולמהירות של עיבוד עסקאות התשלום.

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

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

דוגמה: זמן התגובה הממוצע באלפיות השנייה לאישור עסקה, שנמדד בחלון נע של 5 דקות.

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

דוגמה: חשוב לוודא ש-99.5% מעסקאות התשלום יעובדו בתוך 400 אלפיות השנייה במהלך חלון מתגלגל של 30 יום.

התחייבות חוזית לפתרון בעיות קריטיות בעיבוד תשלומים בתוך פרק זמן מוגדר.

דוגמה: לבעיות קריטיות בעיבוד תשלומים (מוגדרות כהפסקת שירות שמשפיעה על יותר מ-1% מהעסקאות), ספק השירות מתחייב לזמן פתרון של עד שעתיים מהרגע שבו הבעיה דווחה או זוהתה.
זמינות בפלטפורמות השונות

אחוז הזמן שבו ה-API העיקרי לעיבוד תשלומים וממשק המשתמש פועלים ונגישים ללקוחות.

דוגמה: (זמן הפעולה הכולל − זמן ההשבתה) ÷ זמן הפעולה הכולל × 100, נמדד בכל דקה.

יעד פנימי לזמן הפעולה של פלטפורמת התשלומים המרכזית.

דוגמה: השגת זמינות של 99.995% בפלטפורמה בכל חודש קלנדרי, לא כולל חלונות זמן מתוזמנים לתחזוקה.

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

דוגמה: הפלטפורמה תשמור על זמינות של 99.9% לפחות בכל חודש קלנדרי, לא כולל חלונות תחזוקה מתוזמנים. אם הזמינות יורדת מתחת לרמה המינימלית, הלקוח יקבל זיכוי על שירות בשיעור של 5% מעמלת השירות החודשית על כל ירידה של 0.1%.

שימוש בנתוני SLI כדי לעקוב אחרי המערכות ולוודא שהן עומדות ב-SLO שהוגדר, וכדי לוודא שהן עומדות בדרישות של הסכמי רמת השירות (SLA). באמצעות קבוצה של SLI מוגדרים היטב, מהנדסים ומפתחים יכולים לעקוב אחרי אפליקציות FS ברמות הבאות:

  • ישירות בשירות שבו האפליקציות נפרסות, כמו GKE או Cloud Run.
  • באמצעות יומנים שמסופקים על ידי רכיבי תשתית, כמו מאזן העומסים.

‫OpenTelemetry מספקת תקן קוד פתוח וקבוצה של טכנולוגיות ללכידת כל סוגי הטלמטריה, כולל מדדים, עקבות ויומנים. השירות המנוהל של Google Cloud ל-Prometheus מספק קצה עורפי מנוהל לחלוטין וניתן להתאמה לעומסים, למדדים ולהפעלה של Prometheus בקנה מידה גדול.

מידע נוסף על SLI,‏ SLO ותקציבי שגיאות זמין במדריך SRE.

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

הגדרת תהליכים לניהול אירועים ובדיקתם

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

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

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

כדי להגדיר ולבדוק את תהליכי ניהול האירועים, כדאי לפעול לפי ההמלצות הבאות.

הגדרת נהלי תגובה ברורים לאירועים

קבוצה מבוססת של נהלים לתגובה לאירועים כוללת את הרכיבים הבאים:

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

הטמעה של בדיקות עומס וביצועים באופן קבוע

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

ביצוע אוטומציה של בדיקות בצינורות עיבוד נתונים של CI/CD

שילוב של בדיקות אוטומטיות בצינורות CI/CD עוזר להבטיח את האיכות והמהימנות של אפליקציות בענן על ידי אימות השינויים לפני הפריסה. הגישה הזו מצמצמת באופן משמעותי את הסיכון לשגיאות ולנסיגות, ועוזרת לכם לבנות מערכת תוכנה יציבה ואמינה יותר. אפשר לשלב סוגים שונים של בדיקות בצינורות CI/CD, כולל בדיקות יחידה, בדיקות שילוב ובדיקות מקצה לקצה. אפשר להשתמש במוצרים כמו Cloud Build ו-Cloud Deploy כדי ליצור ולנהל את צינורות עיבוד הנתונים של CI/CD.

שיפור וחדשנות מתמשכים

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

  • האצת חדשנות: אתם יכולים לנצל טכנולוגיות חדשות כמו AI כדי לשפר את השירותים שלכם.
  • הפחתת עלויות: ביטול חוסר יעילות ואופטימיזציה של השימוש במשאבים.
  • שיפור הגמישות: התאמה מהירה לשינויים בשוק ולשינויים רגולטוריים.
  • שיפור תהליך קבלת ההחלטות: שימוש במוצרים לניתוח נתונים כמו BigQuery ו-Looker כדי לקבל החלטות מושכלות.

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

עורכים מפגשי רטרוספקטיבה באופן קבוע

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

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

טיפוח תרבות של למידה

תרבות של למידה מאפשרת לחקור בבטחה טכנולוגיות חדשות ב-Google Cloud, כמו יכולות AI ו-ML לשיפור שירותים כמו זיהוי תרמיות וייעוץ פיננסי מותאם אישית. כדי לקדם תרבות של למידה, צריך:

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

התעדכנות בטכנולוגיות ענן

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

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

נקודת מבט של שירותים פיננסיים: אבטחה, פרטיות ותאימות

במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מופיע סקירה כללית של העקרונות וההמלצות לטיפול בדרישות האבטחה, הפרטיות והתאימות של עומסי עבודה של שירותים פיננסיים (FS) ב- Google Cloud. ההמלצות עוזרות לכם לבנות תשתית עמידה ותואמת, להגן על מידע אישי רגיש, לשמור על אמון הלקוחות, להתמודד עם הדרישות הרגולטוריות המורכבות ולנהל ביעילות איומי סייבר. ההמלצות במסמך הזה תואמות לעקרון האבטחה של Well-Architected Framework.

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

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

ההמלצות בנושא אבטחה במסמך הזה ממופות לעקרונות הליבה הבאים:

הטמעה של אבטחה משלב התכנון

תקנות פיננסיות כמו תקן אבטחת הנתונים המקובל בתעשיית כרטיסי תשלום (PCI DSS),‏ Gramm-Leach-Bliley Act (חוק GLBA) בארצות הברית וחוקים שונים להגנה על נתונים פיננסיים ברמה הלאומית מחייבים לשלב אבטחה במערכות כבר מההתחלה. העיקרון של אבטחה מובנית מדגיש את השילוב של אבטחה לאורך מחזור החיים של הפיתוח, כדי למזער את נקודות החולשה כבר מההתחלה.

כדי ליישם את עקרון האבטחה לפי עיצוב בעומסי העבודה של FS ב-Google Cloud, כדאי לפעול לפי ההמלצות הבאות:

  • כדי לוודא שמוענקות רק ההרשאות הנדרשות, כדאי להחיל את העיקרון של הרשאות מינימליות באמצעות בקרת גישה מפורטת מבוססת-תפקידים (RBAC) בניהול זהויות והרשאות גישה (IAM). שימוש ב-RBAC הוא דרישה מרכזית בהרבה תקנות פיננסיות.
  • אפשר להשתמש ב-VPC Service Controls כדי לאכוף אזורי אבטחה מסביב לשירותים ולנתונים הרגישים שלכם ב- Google Cloud . גבולות הגזרה האלה עוזרים לפלח ולהגן על מידע אישי רגיש ומשאבים, ולמנוע זליגת נתונים וגישה לא מורשית, כפי שנדרש בתקנות.
  • להגדיר את הגדרות האבטחה כקוד באמצעות כלים של תשתית כקוד (IaC) כמו Terraform. הגישה הזו משלבת אמצעי אבטחה כבר בשלב הפריסה הראשוני, וכך עוזרת להבטיח עקביות ויכולת ביקורת.
  • סורקים את קוד האפליקציה על ידי שילוב של בדיקת אבטחה סטטית של אפליקציות (SAST) בצינור ה-CI/CD באמצעות Cloud Build. הגדרת שערים אוטומטיים לאבטחה כדי למנוע פריסה של קוד שלא עומד בדרישות.
  • שימוש ב-Security Command Center כדי לספק ממשק מאוחד לתובנות בנושא אבטחה. השימוש ב-Security Command Center מאפשר מעקב רציף וזיהוי מוקדם של טעויות בהגדרות או איומים שעלולים להוביל להפרות של תקנות. כדי לעמוד בדרישות של תקנים כמו ISO 27001 ו-NIST 800-53, אפשר להשתמש בתבניות של ניהול מצב האבטחה.
  • מעקב אחרי הפחתה במספר נקודות החולשה שמזוהות בפריסות בסביבת הייצור, ואחרי אחוז הפריסות של IaC שעומדות בשיטות המומלצות לאבטחה. אתם יכולים לזהות ולראות פגיעויות ומידע על תאימות לתקני אבטחה באמצעות Security Command Center. מידע נוסף זמין במאמר בנושא ממצאים של פגיעויות.

הטמעה של מודל אבטחה של אפס אמון

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

כדי להטמיע גישת אפס אמון, כדאי לפעול לפי ההמלצות הבאות:

  • הפעלה של בקרת גישה מבוססת-הקשר על סמך זהות המשתמש, אבטחת המכשיר, המיקום וגורמים אחרים, באמצעות שילוב של אמצעי בקרה של IAM עם Chrome Enterprise Premium. הגישה הזו מבטיחה אימות רציף לפני שניתנת גישה לנתונים ולמערכות פיננסיות.
  • כדי לספק ניהול מאובטח וניתן להרחבה של זהויות וגישה, צריך להגדיר את Identity Platform (או את ספק הזהויות החיצוני אם משתמשים באיחוד שירותי אימות הזהות של כוח העבודה). הגדרת אימות רב-שלבי (MFA) ואמצעי בקרה אחרים שחשובים להטמעה של Zero Trust ולעמידה בדרישות הרגולטוריות.
  • הטמעת MFA בכל חשבונות המשתמשים, במיוחד בחשבונות עם גישה למידע אישי רגיש או למערכות.
  • תמיכה בביקורות ובחקירות שקשורות לתאימות לתקנות על ידי הקמת רישום מקיף ומעקב אחר גישת משתמשים ופעילות ברשת.
  • אפשר להשתמש ב-Private Service Connect כדי לאפשר תקשורת פרטית ומאובטחת בין שירותים בסביבותGoogle Cloud ובסביבות מקומיות, בלי לחשוף את התנועה לאינטרנט הציבורי.
  • כדי להטמיע אמצעי בקרה פרטניים של זהויות ולאשר גישה ברמת האפליקציה, אפשר להשתמש בשרת proxy לאימות זהויות (IAP) במקום להסתמך על מנגנוני אבטחה שמבוססים על רשתות, כמו מנהרות VPN. הגישה הזו עוזרת לצמצם את התנועה הרוחבית בסביבה.

הטמעה של אבטחה מוקדמת

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

כדי ליישם את הגישה של shift-left security, כדאי לפעול לפי ההמלצות הבאות:

  • כדי להבטיח בדיקות אבטחה אוטומטיות בשלב מוקדם בתהליך הפיתוח, אפשר לשלב כלי סריקה לאבטחה, כמו סריקת נקודות חולשה במאגרי נתונים וניתוח קוד סטטי, בצינור CI/CD באמצעות Cloud Build.

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

  • אפשר לסרוק באופן אוטומטי אפליקציות אינטרנט כדי למצוא נקודות חולשה נפוצות באמצעות שילוב של Web Security Scanner, שהוא חלק מ-Security Command Center, בצינורות הפיתוח.

  • כדי להטמיע בדיקות אבטחה לקוד המקור, לתהליך build ולמקור הקוד, אפשר להשתמש במסגרת Supply-chain Levels for Software Artifacts‏ (SLSA). אפשר לאכוף את המקור של עומסי העבודה שפועלים בסביבות שלכם באמצעות פתרונות כמו Binary Authorization. כדי לוודא שעומסי העבודה שלכם משתמשים רק בספריות מאומתות של תוכנה בקוד פתוח, אתם יכולים להשתמש ב-Assured Open Source.

  • אפשר לעקוב אחרי מספר נקודות החולשה שזוהו ותוקנו במחזור החיים של הפיתוח, אחוז פריסות הקוד שעברו סריקות אבטחה והפחתה במספר אירועי האבטחה שנגרמו על ידי נקודות חולשה בתוכנה. Google Cloud מספקת כלים שיעזרו לכם לעקוב אחרי נתונים כאלה לסוגים שונים של עומסי עבודה. לדוגמה, לעומסי עבודה מבוססי-קונטיינר, אפשר להשתמש בתכונת סריקת הקונטיינרים של Artifact Registry.

הטמעה של הגנת סייבר מונעת

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

כדאי לשקול את ההמלצות הבאות:

  • זיהוי יזום של איומים פוטנציאליים וצמצום הסיכון שלהם באמצעות שירותי מודיעין איומי סייבר, תגובה לאירוע ואימות אבטחה של Mandiant.
  • הגנה על אפליקציות אינטרנט וממשקי API מפני ניצול לרעה של האינטרנט ומתקפות DDoS בקצה הרשת באמצעות Google Cloud Armor.
  • אפשר לצבור ולתעדף ממצאים והמלצות בנושא אבטחה באמצעות Security Command Center, וכך לאפשר לצוותי האבטחה לטפל באופן יזום בסיכונים פוטנציאליים.
  • כדי לוודא שאמצעי ההגנה המקדימים ותוכניות התגובה לאירועים יעילים, מומלץ לבצע סימולציות אבטחה ובדיקות חדירה באופן קבוע.
  • למדוד את הזמן שנדרש לזיהוי אירועי אבטחה ולתגובה להם, את היעילות של מאמצי המיתון של מתקפות DDoS ואת מספר מתקפות הסייבר שנמנעו. אפשר לקבל את המדדים והנתונים הנדרשים מלוחות הבקרה של Google Security Operations SOAR ו-SIEM.

שימוש מאובטח ואחראי ב-AI, ושימוש ב-AI למטרות אבטחה

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

  • פיתוח ופריסה של מודלים של למידת מכונה בסביבה מאובטחת ומנוהלת באמצעות Gemini Enterprise Agent Platform. תכונות כמו הסבר על המודל ומדדי הוגנות יכולות לעזור לטפל בבעיות שקשורות ל-AI אחראי.
  • להשתמש ביכולות ניתוח ותפעול של נתוני אבטחה ב-Google Security Operations, שמבוססות על AI ועל למידת מכונה (ML) כדי לנתח כמויות גדולות של נתוני אבטחה, לזהות חריגות ולהפוך את התגובה לאיומים לאוטומטית. היכולות האלה עוזרות לשפר את אמצעי האבטחה הכוללים ולעקוב אחרי התאימות.
  • הגדרת מדיניות ברורה לניהול פיתוח ופריסה של AI ולמידת מכונה, כולל שיקולים שקשורים לאבטחה ולאתיקה.
  • התאמה לרכיבים של Secure AI Framework‏ (SAIF), שמספק גישה מעשית לטיפול בבעיות אבטחה ובסיכונים של מערכות AI.
  • מעקב אחרי הדיוק והיעילות של מערכות לזיהוי הונאות מבוססות-AI, אחרי הירידה בתוצאות חיוביות שגויות בהתראות אבטחה ואחרי שיפור היעילות בעקבות אוטומציה של אבטחה מבוססת-AI.

עמידה בדרישות רגולטוריות, בדרישות תאימות ובדרישות פרטיות

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

  • כדי להגדיר גבולות נתונים ב- Google Cloud לעומסי עבודה (workloads) שמכילים מידע רגיש ומידע שחל עליו רגולציה, צריך להשתמש ב-Assured Workloads. כך תוכלו לעמוד בדרישות התאימות של הממשלה ושל הענף הספציפי, כמו FedRAMP ו-CJIS.
  • מזהים ומסווגים מידע רגיש, כולל מידע פיננסי, ומגנים עליו באמצעות הטמעה של מניעת אובדן נתונים בענן (Cloud DLP). כך תוכלו לעמוד בדרישות של תקנות בנושא פרטיות נתונים כמו GDPR ו-CCPA.
  • כדי לעקוב אחרי פרטים של פעילויות אדמין וגישה למשאבים, אפשר להשתמש ביומני ביקורת של Cloud. היומנים האלה חיוניים כדי לעמוד בדרישות הביקורת שנקבעו בהרבה תקנות פיננסיות.
  • כשבוחרים Google Cloud אזורים לעומסי העבודה ולנתונים, חשוב לקחת בחשבון תקנות מקומיות שקשורות למיקום אחסון הנתונים. Google Cloud התשתית הגלובלית מאפשרת לכם לבחור אזורים שיעזרו לכם לעמוד בדרישות בנוגע למיקום אחסון הנתונים.
  • ניהול המפתחות שמשמשים להצפנה של נתונים פיננסיים רגישים במנוחה ובמעבר באמצעות Cloud Key Management Service. הצפנה כזו היא דרישה בסיסית של תקנות רבות בנושא אבטחה ופרטיות.
  • מטמיעים את אמצעי הבקרה שנדרשים כדי לעמוד בדרישות הרגולטוריות. מוודאים שהאמצעים פועלים כצפוי. לקבל אימות חוזר של אמצעי הבקרה על ידי מבקר חיצוני כדי להוכיח לרשות הרגולטורית שעומסים דינמיים תואמים לתקנות.

הגדרת סדר עדיפויות ליוזמות אבטחה

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

  1. יוצרים בסיס אבטחה חזק: מתמקדים בתחומי הליבה של האבטחה, כולל ניהול זהויות וגישה, אבטחת רשת והגנה על נתונים. המיקוד הזה עוזר לבנות אסטרטגיית אבטחה חזקה ומבטיח הגנה מקיפה מפני איומים מתפתחים.
  2. התייחסות לתקנות קריטיות: חשוב לתת עדיפות לעמידה בתקנות חשובות כמו PCI DSS,‏ GDPR וחוקים לאומיים רלוונטיים. כך תוכלו להבטיח את הגנה על נתונים, לצמצם את הסיכונים המשפטיים ולבנות אמון עם הלקוחות.
  3. הטמעת אבטחה מתקדמת: הטמעה הדרגתית של שיטות אבטחה מתקדמות כמו אפס אמון, פתרונות אבטחה מבוססי-AI וחיפוש פרואקטיבי של איומים.

נקודת מבט על שירותים פיננסיים: אמינות

במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מפורטת סקירה כללית של העקרונות וההמלצות לתכנון, לפריסה ולהפעלה של עומסי עבודה מהימנים של שירותים פיננסיים ב- Google Cloud. במסמך הזה מוסבר איך לשלב שיטות מתקדמות של אמינות וניטור בתרשימי הארכיטקטורה שלכם. ההמלצות במסמך הזה תואמות לעקרון המהימנות של Well-Architected Framework.

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

אבני הבניין העיקריות של מהימנות ב- Google Cloud הן אזורים, תחומים (zones) והיקפי המיקום השונים של משאבי הענן: תחום, אזור, מספר אזורים וגלובלי. כדי לשפר את הזמינות, אפשר להשתמש בשירותים מנוהלים, להפיץ משאבים, להטמיע דפוסי זמינות גבוהה ולבצע אוטומציה של תהליכים.

דרישות רגולטוריות

ארגונים פיננסיים פועלים תחת דרישות מחמירות של מהימנות מצד סוכנויות רגולטוריות כמו Federal Reserve System בארה"ב, European Banking Authority באיחוד האירופי ו-Prudential Regulation Authority בבריטניה. ברחבי העולם, הרגולטורים מדגישים את החשיבות של חוסן תפעולי, שהוא חיוני ליציבות פיננסית ולהגנה על הצרכנים. חוסן תפעולי הוא היכולת לעמוד בפני שיבושים, להתאושש מהם ביעילות ולשמור על שירותים קריטיים. לכן נדרשת גישה מתואמת לניהול סיכונים טכנולוגיים ותלות בצדדים שלישיים.

הדרישות הרגולטוריות ברוב תחומי השיפוט כוללות את הנושאים המשותפים הבאים:

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

ההמלצות בנושא מהימנות במסמך הזה ממופות לעקרונות הליבה הבאים:

העדיפו פריסות במספר אזורים ובמספר אזורים

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

כדי לשפר את החוסן (resilience) בפני הפסקות חשמל באזורים ובתחומי זמינות, כדאי לפעול לפי ההמלצות הבאות:

  • מומלץ להשתמש במשאבים עם היקף מיקום רחב יותר. כשאפשר, כדאי להשתמש במשאבים אזוריים במקום במשאבים של תחום מוגדר, ובמשאבים גלובליים או שמנוהלים במספר אזורים במקום במשאבים אזוריים. הגישה הזו עוזרת להימנע מהצורך לשחזר פעולות באמצעות גיבויים.
  • בכל אזור, כדאי להשתמש בשלושה תחומים ולא בשניים. כדי לטפל במעבר לגיבוי, כדאי להקצות שליש יותר קיבולת מההערכה.
  • כדי לצמצם את השלבים של שחזור ידני, כדאי להטמיע פריסות פעילות-פעילות, כמו בדוגמאות הבאות:
    • מסדי נתונים מבוזרים כמו Spanner מספקים יתירות מובנית וסנכרון בין אזורים.
    • תכונת הזמינות הגבוהה של Cloud SQL מספקת טופולוגיה שהיא כמעט פעילה-פעילה, עם רפליקות לקריאה באזורים שונים. הוא מספק יעד להתאוששות מאסון (RPO) בין אזורים שקרוב ל-0.
  • כדי לחלק את תעבורת הנתונים של המשתמשים בין אזורים, משתמשים ב-Cloud DNS ומפריסים מאזן עומסים אזורי בכל אזור. מאזן עומסים גלובלי הוא עוד אפשרות שכדאי לשקול בהתאם לדרישות ולחשיבות שלכם. מידע נוסף זמין במאמר היתרונות והסיכונים של איזון עומסים גלובלי לפריסות במספר אזורים.
  • כדי לאחסן נתונים, משתמשים בשירותים מרובי-אזורים כמו Spanner ו-Cloud Storage.

ביטול נקודות כשל בודדות

כדאי לפזר את המשאבים במיקומים שונים ולהשתמש במשאבים מיותרים כדי למנוע מצב שבו נקודת כשל יחידה (SPOF) תשפיע על כל מחסנית האפליקציה.

כדי להימנע מנקודות כשל יחידות, כדאי לפעול לפי ההמלצות הבאות:

מידע נוסף זמין במאמר בנושא תכנון תשתית מהימנה לעומסי עבודה ב- Google Cloud.

הסבר על זמינות מצטברת וניהול שלה

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

  • כדי לחשב את הזמינות הכוללת של מחסנית מרובת רמות, משתמשים בנוסחה tier1_availability × tier2_availability × tierN_availability.

    התרשים הבא מציג את החישוב של זמינות מצטברת למערכת רב-שכבתית שמורכבת מארבעה שירותים:

    נוסחת הזמינות המצטברת לשירות רב-שכבתי עם ארבעה שירותים.

    בתרשים שלמעלה, רמת הזמינות של השירות בכל שכבה היא 99.9%, אבל רמת הזמינות הכוללת של המערכת נמוכה יותר ועומדת על 99.6% (0.999 × 0.999 × 0.999 × 0.999). באופן כללי, הזמינות המצטברת של מחסנית מרובת-שכבות נמוכה מהזמינות של השכבה שמספקת את הזמינות הכי נמוכה.

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

    הדיאגרמה הבאה מציגה שני שירותים, A ו-B, שנפרסים באמצעות הגישות של שרשור והקבלה:

    הנוסחאות לחישוב הזמינות הכוללת של שירותים בשרשרת לעומת שירותים מקבילים.

    בדוגמאות הקודמות, לשני השירותים יש הסכם SLA של 99%, ולכן רמת הזמינות הכוללת תהיה תלויה בגישת ההטמעה:

    • שירותים בשרשרת מניבים זמינות מצטברת של 98% בלבד (0.99 × 0 .99).
    • שירותים מקבילים מניבים זמינות מצטברת גבוהה יותר של 99.99% כי כל שירות פועל באופן עצמאי, והזמינות של שירותים בודדים לא מושפעת מהזמינות של השירותים האחרים. הנוסחה לשירותים מצטברים מקבילים היא 1 − (1 − A) × (1 − B).

  • כדאי לבחור Google Cloud שירותים עם הסכמי רמת שירות (SLA) לזמן פעולה תקינה, שיעזרו לכם לעמוד ברמת הזמינות הכוללת הנדרשת עבור חבילת האפליקציות שלכם.

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

    לדוגמה, זמינות של 99.9% (שלוש תשיעיות) פירושה זמן השבתה פוטנציאלי של 86 שניות ביום של 24 שעות. לעומת זאת, 99% (שני תשיעיות) פירושו זמן השבתה של 864 שניות באותו פרק זמן, שהוא פי 10 יותר מזמן ההשבתה עם זמינות של 99.9%.

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

יישום אסטרטגיה חזקה להתאוששות מאסון

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

DR וזמינות גבוהה (HA) הם מושגים שונים. בפריסות בענן, התאוששות מאסון (DR) חלה בדרך כלל על פריסות במספר אזורים, וזמינות גבוהה (HA) חלה על פריסות אזוריות. ארכיטיפים של פריסה תומכים במנגנוני שכפול שונים.

  • HA: שירותים מנוהלים רבים מספקים שכפול סינכרוני בין אזורים בתוך אזור יחיד כברירת מחדל. שירותים כאלה תומכים ביעד להתאוששות מאסון (RPO) וביעד משך ההתאוששות (RTO) של אפס או קרוב לאפס. התמיכה הזו מאפשרת ליצור טופולוגיית פריסה פעילה-פעילה ללא נקודת כשל יחידה (SPOF).
  • DR: לעומסי עבודה שנפרסים בשני אזורים או יותר, אם לא משתמשים בשירותים גלובליים או בשירותים במספר אזורים, צריך להגדיר אסטרטגיית שכפול. אסטרטגיית השכפול היא בדרך כלל אסינכרונית. חשוב להעריך בקפידה איך השכפול הזה משפיע על זמן ההתאוששות (RTO) ועל נקודת ההתאוששות (RPO) של אפליקציות קריטיות. זיהוי הפעולות הידניות או החצי-אוטומטיות שנדרשות למעבר לגיבוי בעת כשל.

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

כדאי לשקול את ההמלצות הבאות:

  • להשתמש בשירותי אחסון מנוהלים במספר אזורים בשביל הנתונים.
  • יוצרים תמונות מצב של נתונים בדיסקים לאחסון מתמיד (persistent disks) ומאחסנים את תמונות המצב במיקומים רב-אזוריים.
  • כשמשתמשים במשאבים אזוריים או של תחום מוגדר, צריך להגדיר רפליקציה של נתונים לאזורים אחרים.
  • כדי לוודא שתוכניות ה-DR שלכם יעילות, חשוב לבדוק את התוכנית באופן קבוע.
  • חשוב להכיר את ה-RTO ואת ה-RPO ואת הקשר שלהם לסבילות להשפעה שנקבעה בתקנות הפיננסיות בתחום השיפוט שלכם.

מידע נוסף מופיע במאמר תכנון התאוששות מאסון (DR) להפסקות בשירותי תשתית ענן.

שימוש בשירותים מנוהלים

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

  • שימוש בשירותים מנוהלים ב- Google Cloud. הם מספקים זמינות גבוהה שמגובה בהסכמי רמת שירות (SLA). הם כוללים גם מנגנוני גיבוי מובנים ותכונות עמידות.
  • לניהול נתונים, כדאי להשתמש בשירותים כמו Cloud SQL,‏ Cloud Storage ו-Spanner.
  • למחשוב ולאירוח אפליקציות, כדאי לשקול קבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine ואשכולות Google Kubernetes Engine‏ (GKE). קבוצות אזוריות של מכונות וירטואליות ואשכולות אזוריים של GKE עמידים בפני הפסקות זמניות בשירות באזור מסוים.
  • כדי לשפר את החוסן (resilience) מפני הפסקות חשמל באזור, כדאי להשתמש בשירותים מנוהלים במספר אזורים.
  • לזהות את הצורך בתוכניות יציאה לשירותים עם מאפיינים ייחודיים ולהגדיר את התוכניות הנדרשות. רגולטורים פיננסיים כמו FCA,‏ PRA ו-EBA דורשים מחברות להגדיר אסטרטגיות ותוכניות מגירה לשחזור נתונים ולהמשכיות תפעולית במקרה של סיום הקשר עם ספק שירותי ענן. חברות צריכות להעריך את היתכנות היציאה לפני שהן חותמות על חוזים עם ספקי ענן, והן צריכות לשמור על היכולת לשנות ספקים בלי שיבושים תפעוליים.
  • מוודאים שהשירותים שבוחרים תומכים בייצוא נתונים לפורמט פתוח כמו CSV,‏ Parquet ו-Avro. בודקים אם השירותים מבוססים על טכנולוגיות פתוחות, כמו תמיכה ב-GKE בפורמט Open Container Initiative‏ (OCI) או Managed Service for Apache Airflow שמבוסס על Apache Airflow.

אוטומציה של תהליכי הקצאת התשתית והשחזור

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

  • מצמצמים את הטעויות האנושיות באמצעות כלים של תשתית כקוד (IaC) כמו Terraform.
  • צמצום ההתערבות הידנית באמצעות אוטומציה של תהליכי מעבר לגיבוי. תשובות אוטומטיות יכולות גם לעזור לצמצם את ההשפעה של כשלים. לדוגמה, אפשר להשתמש ב-Eventarc או ב-Workflows כדי להפעיל אוטומטית פעולות לתיקון בעיות שנצפו באמצעות יומני ביקורת.
  • כדי להגדיל את הקיבולת של משאבי הענן במהלך מעבר לגיבוי, אפשר להשתמש בהתאמת קנה מידה אוטומטית.
  • הטמעה של הנדסת פלטפורמה מאפשרת להחיל באופן אוטומטי מדיניות ואמצעי הגנה על דרישות רגולטוריות בטופולוגיית הענן במהלך פריסת השירות.

נקודת מבט של שירותים פיננסיים: אופטימיזציה של עלויות

במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מופיע סקירה כללית של עקרונות והמלצות לאופטימיזציה של העלות של עומסי העבודה של שירותים פיננסיים ב- Google Cloud. ההמלצות במסמך הזה תואמות לעקרון אופטימיזציית העלויות של Well-Architected Framework.

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

  • היכולת לזהות שימוש במשאבים שמוביל לבזבוז לעומת שימוש במשאבים שמניב ערך.
  • תרבות מוטמעת של אחריותיות פיננסית.

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

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

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

ההמלצות לאופטימיזציה של העלויות במסמך הזה ממופות לעקרונות הליבה הבאים:

זיהוי בזבוז באמצעות Google Cloud כלים

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

שימוש באוטומציה וב-AI כדי לזהות באופן שיטתי את מה שצריך לבצע בו אופטימיזציה

‫Active Assist מספק המלצות חכמות לגבי שירותים כמו Cloud Run למיקרו-שירותים, BigQuery לניתוח נתונים, Compute Engine לאפליקציות ליבה ו-Cloud SQL למסדי נתונים רלציוניים. ההמלצות של Active Assist ניתנות ללא עלות וללא צורך בהגדרה מצדכם. ההמלצות עוזרות לכם לזהות משאבים לא פעילים והתחייבויות שלא מנוצלות מספיק.

ריכוז המעקב והשליטה ב-FinOps באמצעות ממשק מאוחד

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

זיהוי ערך באמצעות ניתוח והעשרה של נתוני הוצאות

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

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

בתרשים הבא מוצגות דרכים להשתמש בפירמידת הנתונים, המידע, הידע והתבונה (DIKW) ובכלים של Google Cloud כדי לקבל תמונה מלאה של העלויות והערך של הענן.

פירמידת הנתונים-מידע-ידע-תבונה (DIKW) מראה איך להשתמש בנתוני ההוצאות ב-Cloud כדי לקבל החלטות מושכלות.

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

  • נתונים: בשכבה הזו אתם אוספים נתונים גולמיים ולא מעובדים של שימוש ונתוני עלות של משאבי הענן. צוות FinOps מרכזי משתמש בכלים כמו חשבוניות של חיוב ב-Cloud, ייצוא נתוני חיוב ו-Cloud Monitoring כדי לקבל נתונים מפורטים וגרנולריים. לדוגמה, נקודת נתונים יכולה להיות שמכונה וירטואלית בשם app1-test-vmA פעלה במשך 730 שעות באזור us-central1 והעלות שלה הייתה 70 דולר ארה"ב.
  • מידע: בשכבה הזו, צוות FinOps המרכזי משתמש בכלים כמו דוחות חיוב ב-Cloud ו-FinOps Hub כדי לבנות את הנתונים הגולמיים בצורה שתעזור לענות על שאלות כמו "על אילו קטגוריות של משאבים אנשים מוציאים כסף?" לדוגמה, יכול להיות שתגלו שהוצאתם סכום כולל של 1,050$ על מכונות וירטואליות מסוג n4-standard-2 בשני אזורים בארה"ב.
  • ידע: בשכבה הזו, צוות ה-FinOps המרכזי מעשיר את המידע בהקשר העסקי המתאים לגבי מי הוציא כסף ולשם מה. אתם משתמשים במנגנונים כמו תיוג, תוויות, היררכיית משאבים, חשבונות לחיוב ולוחות בקרה מותאמים אישית ב-Looker. לדוגמה, יכול להיות שתגלו שapp1 צוות הבדיקות בארה"ב הוציא 650 דולר ארה"ב במהלך השבוע השני של יולי כחלק מתרגיל לבדיקת עומסים.
  • תובנות: בשלב הזה, צוותי המוצר והאפליקציה משתמשים בידע שנוצר בהקשר כדי להעריך את הערך העסקי של ההוצאות על הענן ולקבל החלטות אסטרטגיות מושכלות. הצוותים שלכם יכולים לענות על שאלות כמו:
    • האם ההוצאה של 5,000 דולר על צינור ניתוח נתונים מניבה ערך עסקי?
    • האם אפשר לשנות את הארכיטקטורה של צינור הנתונים כדי שהוא יהיה יעיל יותר בלי לפגוע בביצועים?

כדאי לקחת בחשבון את ההמלצות הבאות לניתוח נתוני ההוצאות על Cloud.

ניתוח נתוני ההוצאות שסופקו על ידי Google Cloud

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

המחשה ויזואלית של נתונים באמצעות כלים זמינים

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

הקצאת הוצאות כדי לשפר את האחריותיות

אחרי שמבינים מה גורם להוצאות ב-Cloud, צריך לזהות מי מוציא כסף ולמה. כדי להגיע לרמת ההבנה הזו, צריך להקפיד על הקצאת עלויות, שכוללת צירוף מטא-נתונים שרלוונטיים לעסק למשאבי ענן. לדוגמה, אם משאב מסוים נמצא בשימוש של צוות Banking-AppDev, אפשר לצרף למשאב תג כמו team=banking_appdev כדי לעקוב אחרי העלות שהצוות מוציא על המשאב הזה. מומלץ להקצות 100% מהעלויות בענן למקור ההוצאות. בפועל, יכול להיות שתתחילו עם יעד נמוך יותר כי בניית מבנה מטא-נתונים לתמיכה בהקצאת עלויות של 100% היא משימה מורכבת.

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

  • תוקף: חשוב לוודא שהתגים עוזרים לזהות מדדי ביצועים מרכזיים (KPI) שקשורים לעסק ודרישות רגולטוריות. השיוך הזה חשוב מאוד לחיובים פנימיים, לדיווח רגולטורי ולתיאום בין ההוצאות ב-Cloud לבין היעדים של היחידה העסקית. לדוגמה, התגים הבאים מזהים בבירור את צוות ההוצאות, האזור והמוצר שבו הם עובדים: team=banking_appdev, region=emea, product=frontend.
  • אוטומציה: כדי להשיג רמה גבוהה של תאימות לתיוג, כדאי לאכוף את התיוג באמצעות אוטומציה. תיוג ידני עלול להוביל לשגיאות ולחוסר עקביות, וזה לא מקובל בסביבות של שירותים פיננסיים שבהן חשובים במיוחד יכולת הביקורת והדיוק הפיננסי. תיוג אוטומטי מוודא שהמשאבים מסווגים בצורה נכונה כשהם נוצרים.
  • פשטות: מדידת גורמים פשוטים ולא קשורים. סביבות FS הן מורכבות. כדי להבטיח שכללי הקצאת העלויות בסביבה כזו יהיו קלים להבנה וליישום, הכללים צריכים להיות פשוטים ככל האפשר. לא כדאי להגזים בתכנון הכללים למקרים ספציפיים מאוד (מקרים קיצוניים). כללים מורכבים עלולים לגרום לבלבול ולהתנגדות מצד צוותי התפעול.

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

כדי להשיג את רמת הגרנולריות המתאימה להקצאת עלויות בארגון, אפשר להשתמש בגישות הבאות:

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

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

שיפור האחריות האישית ועידוד מהנדסים לפעולה

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

כדאי ליישם את ההמלצות הבאות כדי לעודד אחריות ולהניע את הצוותים לייעל את העלויות.

הקמת צוות FinOps מרכזי לצורך ניהול

נוהלי Cloud FinOps לא מתפתחים באופן אורגני. צוות ייעודי ל-FinOps צריך להגדיר וליישם שיטות עבודה מומלצות ל-FinOps. לשם כך, הוא צריך:

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

קבלת חסות והסכמה של מנהלים בכירים

ההנהלה הבכירה, כולל מנהל הטכנולוגיות הראשי (CTO), מנהל הכספים הראשי (CFO) ומנהל המידע הראשי (CIO), צריכה לתמוך באופן פעיל במעבר של הארגון לתרבות FinOps. התמיכה שלהם חיונית כדי לתת עדיפות לאחריותיות בנוגע לעלויות, להקצות משאבים לתוכנית FinOps, להבטיח השתתפות חוצת-תפקידים ולעודד עמידה בדרישות של FinOps.

תמריצים לצוותים לאופטימיזציה של העלויות

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

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

יישום טכניקות של showback ו-chargeback

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

התמקדות בערך ובסך העלות של הבעלות (TCO) במקום בעלות

כשמעריכים פתרונות ענן, חשוב לקחת בחשבון את עלות הבעלות הכוללת (TCO) לטווח הארוך. לדוגמה, יכול להיות שאירוח עצמי של מסד נתונים לאפליקציה ייראה זול יותר משימוש בשירות מנוהל של מסד נתונים כמו Cloud SQL. עם זאת, כדי להעריך את הערך לטווח ארוך ואת העלות הכוללת של הבעלות, צריך לקחת בחשבון את העלויות הסמויות שקשורות למסדי נתונים באירוח עצמי. העלויות האלה כוללות את המאמץ ההנדסי הייעודי לתיקון פרצות אבטחה, להרחבה, להקשחת אבטחה ולהתאוששות מאסון, שהן דרישות קריטיות לעומסי עבודה של FS. שירותים מנוהלים מספקים ערך גבוה יותר לטווח ארוך, שמקזז את עלויות התשתית. שירותים מנוהלים מספקים יכולות חזקות של תאימות, כוללים תכונות אמינות מובנות ויכולים לעזור לכם לצמצם את ההוצאות התפעוליות.

כדאי לקחת בחשבון את ההמלצות הבאות כדי להתמקד בערך ובסך עלות הבעלות.

שימוש בטכניקות ובכלים ספציפיים למוצרים לאופטימיזציה של משאבים

כדאי להשתמש בתכונות ובכלים לאופטימיזציה של עלויות שזמינים במוצרים של Google Cloud, כמו:

ליהנות מהנחות

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

אפשר ליהנות מההנחות הבאות על משאבים ב-Google Cloud :

  • הנחות לארגונים הן הנחות שנקבעות במשא ומתן על סמך ההתחייבות של הארגון להוציא סכום מינימלי כולל על Google Cloud בתעריף חיוב מופחת.
  • הנחות תמורת התחייבות לשימוש במשאבים ניתנות בתמורה להתחייבות להשתמש בכמות מינימלית של משאבי Compute Engine במשך שנה או שלוש שנים. הנחות תמורת התחייבות לשימוש במשאבים חלות על משאבים שנמצאים באזור ספציפי. ברוב החשבונות לחיוב ב-Cloud, Google Cloud ההגדרה הזו מפעילה חלוקת הנחות תמורת התחייבות לשימוש (CUD) שמבוססות על משאבים, וההנחות מתחלקות בין כל הפרויקטים שמשויכים לחשבון הזה.
  • הנחות תמורת התחייבות להוצאה ניתנות בתמורה להתחייבות להוציא סכום מינימלי על מוצר מסוים במשך שנה או שלוש שנים. הנחות על סמך הוצאות חלות ברמת החשבון לחיוב. ההנחות חלות באופן אזורי או גלובלי, בהתאם למוצר.

אתם יכולים לחסוך משמעותית בעלויות באמצעות הנחות תמורת התחייבות לשימוש (CUD) בנוסף להנחות לארגונים.

בנוסף להנחות תמורת התחייבות לשימוש (CUD), אפשר להשתמש בגישות הבאות כדי להפחית את תעריפי החיוב:

  • כדאי להשתמש ב-Spot VMs לעומסי עבודה (workloads) עמידים בכשלים וגמישים. העלות של מכונות Spot VM נמוכה ביותר מ-80% מזו של מכונות רגילות.
  • ב-BigQuery יש כמה מודלים לתמחור, כולל תמחור לפי דרישה ותמחור לפי מהדורה שמבוסס על התחייבויות ודרישות של שינוי גודל אוטומטי. אם אתם משתמשים בכמות גדולה של משאבי BigQuery, כדאי לבחור במהדורה מתאימה כדי להקטין את העלות לכל משבצת זמן של עומסי עבודה של ניתוח נתונים.
  • חשוב לבדוק בקפידה את האזורים הזמינים לשירותים שבהם אתם רוצים להשתמש. Google Cloud בוחרים אזורים שתואמים ליעדי העלות ולגורמים כמו זמן אחזור ודרישות תאימות. כדי להבין את האיזון בין עלות, קיימות וזמן אחזור, אפשר להשתמש בGoogle Cloud כלי לבחירת אזור.

נקודת מבט של שירותים פיננסיים: אופטימיזציה של הביצועים

במסמך הזה, שמופיע ב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 כדי לבודד את מערכת הליבה של הבנק ולהתחיל את תהליך החדשנות שלהם.