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

Last reviewed 2025-07-28 UTC

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

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

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

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

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

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

מחברים:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בארגונים רבים בתחום השירותים הפיננסיים, הזמינות של אפליקציות מסווגת בדרך כלל על סמך מדדים של יעד להתאוששות מאסון (RPO) ויעד משך ההתאוששות (RTO). יכול להיות שיוגדר גם הסכם רמת שירות (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 כדי לקבל החלטות מושכלות.

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

עורכים רטרוספקטיבות באופן קבוע

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

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

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

תרבות של למידה מאפשרת לחקור בבטחה טכנולוגיות חדשות ב-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) ואמצעי בקרה אחרים שחשובים להטמעה של מודל אבטחה של אפס אמון ולעמידה בתקנות.
  • הטמעת אימות רב-שלבי (MFA) בכל חשבונות המשתמשים, במיוחד בחשבונות עם גישה לנתונים או למערכות רגישים.
  • תמיכה בביקורות ובחקירות שקשורות לתאימות לתקנות באמצעות יצירת רישום מקיף ומעקב אחרי גישת משתמשים ופעילות ברשת.
  • אפשר להפעיל תקשורת פרטית ומאובטחת בין שירותים בתוך סביבותGoogle Cloud ובסביבות מקומיות בלי לחשוף את התנועה לאינטרנט הציבורי באמצעות Private Service Connect.
  • כדי להטמיע אמצעי בקרה פרטניים לזהויות ולאשר גישה ברמת האפליקציה, מומלץ להשתמש בשרת proxy לאימות זהויות (IAP) במקום להסתמך על מנגנוני אבטחה שמבוססים על רשת, כמו מנהרות VPN. הגישה הזו עוזרת לצמצם את התנועה הרוחבית בסביבה.

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

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

כדי ליישם אבטחה מסוג Shift-Left, כדאי לפעול לפי ההמלצות הבאות:

  • כדי להבטיח בדיקות אבטחה אוטומטיות בשלב מוקדם בתהליך הפיתוח, אפשר לשלב כלי סריקה לאבטחה, כמו סריקת נקודות חולשה במאגרי נתונים וניתוח קוד סטטי, בצינור 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:

  • פיתוח ופריסה של מודלים של ML בסביבה מאובטחת ומפוקחת באמצעות Vertex AI. תכונות כמו הסבר על המודל ומדדי הוגנות יכולות לעזור לטפל בבעיות שקשורות ל-AI אחראי.
  • אפשר להשתמש ביכולות ניתוח ותפעול של נתוני אבטחה ב-Google Security Operations, שמתבסס על AI ולמידת מכונה כדי לנתח כמויות גדולות של נתוני אבטחה, לזהות חריגות ולהפוך את התגובה לאיומים לאוטומטית. היכולות האלה עוזרות לשפר את אמצעי האבטחה הכוללים ולעקוב אחרי התאימות.
  • הגדרת מדיניות ברורה לניהול פיתוח ופריסה של 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. יצירת בסיס אבטחה חזק: התמקדות בתחומי הליבה של האבטחה, כולל ניהול זהויות והרשאות גישה (IAM), אבטחת רשת והגנה על נתונים. ההתמקדות הזו עוזרת לבנות אסטרטגיית אבטחה חזקה ומבטיחה הגנה מקיפה מפני איומים מתפתחים.
  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, שנפרסים באמצעות הגישות של שרשור והקבלה:

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

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

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

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

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

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

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

יישום אסטרטגיית DR חזקה

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

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

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

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

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

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

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

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

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

  • שימוש בשירותים מנוהלים ב- Google Cloud. הם מספקים זמינות גבוהה שמגובה בהסכמי רמת שירות (SLA). הם כוללים גם מנגנוני גיבוי מובנים ותכונות עמידות.
  • לניהול נתונים, כדאי להשתמש בשירותים כמו Cloud SQL,‏ Cloud Storage ו-Spanner.
  • למחשוב ולאירוח אפליקציות, כדאי לשקול קבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine ואשכולות של Google Kubernetes Engine ‏ (GKE). קבוצות אזוריות של מכונות וירטואליות (MIG) ואשכולות אזוריים של GKE עמידים בפני הפסקות זמניות בשירות באזור מסוים.
  • כדי לשפר את החוסן (resilience) מפני הפסקות זמניות בשירות באזור מסוים, כדאי להשתמש בשירותים מנוהלים במספר אזורים.
  • לזהות את הצורך בתוכניות יציאה לשירותים עם מאפיינים ייחודיים ולהגדיר את התוכניות הנדרשות. רגולטורים פיננסיים כמו FCA,‏ PRA ו-EBA דורשים מחברות להגדיר אסטרטגיות ותוכניות מגירה לשחזור נתונים ולהמשכיות תפעולית במקרה של סיום הקשר עם ספק שירותי ענן. חברות צריכות להעריך את היתכנות היציאה לפני שהן חותמות על חוזים עם ספקי ענן, והן צריכות לשמור על היכולת לשנות ספקים בלי שיבושים תפעוליים.
  • מוודאים שהשירותים שבוחרים תומכים בייצוא נתונים לפורמט פתוח כמו CSV,‏ Parquet ו-Avro. בודקים אם השירותים מבוססים על טכנולוגיות פתוחות, כמו תמיכה ב-GKE בפורמט Open Container Initiative‏ (OCI) או Cloud Composer שמבוסס על 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 מאפשרים לכם להטמיע מעקב מקיף אחרי העלויות. התצוגה המקיפה הזו חיונית לצוותי ביקורת פיננסית ולצוותי כספים פנימיים כדי לעקוב אחרי ההוצאות על הענן, להעריך את המצב הפיננסי, לבדוק את רמת הבשלות של FinOps ביחידות עסקיות שונות או במרכזי עלויות, ולספק נרטיב פיננסי עקבי.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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