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

Last reviewed 2026-10-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.

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

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

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

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

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

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

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

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

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

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

הגדרת הסכמי 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 של כל שירות, והתייחסו ל-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 ברמות הבאות:

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

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

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

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

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

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

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

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

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

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

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

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

מבצעים בדיקות ביצועים ועומס באופן קבוע

בדיקות ביצועים ועומסים קבועות עוזרות לוודא שהאפליקציות והתשתית מבוססות-ענן יכולות להתמודד עם עומסי שיא ולשמור על ביצועים אופטימליים. בדיקות עומס מדמות דפוסי תנועה מציאותיים. בדיקות עומס מפעילות את המערכת עד קצה גבול היכולת שלה כדי לזהות צווארי בקבוק פוטנציאליים ומגבלות בביצועים. אתם יכולים להשתמש במוצרים כמו 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: נקודת המבט של שירותים פיננסיים (FS). הוא מספק סקירה כללית של העקרונות וההמלצות לעמידה בדרישות האבטחה, הפרטיות והתאימות של עומסי עבודה של שירותים פיננסיים (FS) ב- Google Cloud. ההמלצות עוזרות לכם לבנות תשתית עמידה ותואמת, להגן על נתונים רגישים, לשמור על אמון הלקוחות, לנווט בנוף המורכב של הדרישות הרגולטוריות ולנהל ביעילות את איומי הסייבר. ההמלצות במסמך הזה תואמות לעקרון האבטחה של Well-Architected Framework.

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

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

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

הטמעת אבטחה משלב התכנון (security-by-design)

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

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

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

הטמעת אבטחה מוקדמת (shift-left)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • להגדיר גבולות נתונים ב- Google Cloud לעומסי עבודה רגישים ומפוקחים באמצעות Assured Workloads. כך תוכלו לעמוד בדרישות התאימות של הממשלה ושל התחום הספציפי, כמו FedRAMP ו-CJIS.
  • זיהוי, סיווג והגנה על מידע אישי רגיש, כולל מידע פיננסי, באמצעות הטמעה של Sensitive Data Protection. כך תוכלו לעמוד בתקנות בנושא פרטיות נתונים כמו 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 הן אזורים, תחומים והיקפי המיקום השונים של משאבי הענן: תחום, אזור, מספר אזורים וגלובלי. כדי לשפר את הזמינות, אתם יכולים להשתמש בשירותים מנוהלים, להפיץ משאבים, להטמיע דפוסי זמינות גבוהה ולהפוך תהליכים לאוטומטיים.

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

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

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

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

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

תעדוף של פריסות במספר אזורים ובמספר תחומים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הטמעה של אסטרטגיית התאוששות מאסון (DR) יעילה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אתם יכולים לנצל את סוגי ההנחות הבאים על משאבים ב-Google Cloud :

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

אתם יכולים לחסוך הרבה כסף אם תשתמשו בהנחות תמורת התחייבות לשימוש בנוסף להנחות לארגונים.

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

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

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

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

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

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

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

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

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

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

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

חשוב גם לקשר בין יעדי הביצועים לבין מדדי הביצועים המרכזיים (KPI) של העסק כדי לממן את שיפורי הביצועים. ליוזמות של חדשנות וטרנספורמציה עסקית (שנקראות לפעמים מאמצי change-the-bank) יש תקציבים שונים, וייתכן שיש להן רמות שונות של גישה למשאבים בהשוואה לפעולות של עסקים כרגיל (BAU) או run-the-bank. לדוגמה, Google Cloud עזר לצוותי ניהול הסיכונים והטכנולוגיה של G-SIFI לשתף פעולה עם האנליסטים הכמותיים של המשרד הראשי, כדי למצוא פתרון לביצוע חישובים של ניתוח סיכונים (כמו XVA) תוך דקות במקום שעות או ימים. הפתרון הזה עזר לארגון לעמוד בדרישות התאימות הרלוונטיות. הוא גם מאפשר לסוחרים לנהל שיחות איכותיות יותר עם הלקוחות שלהם, וכך להציע להם מרווחים קטנים יותר, נזילות יציבה יותר וגידור חסכוני יותר.

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

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

לתת עדיפות לאבטחה בלי לפגוע בביצועים בגלל סיכונים שלא הוכחו

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

‫Google Cloud עבדה בשיתוף פעולה הדוק עם G-SIFI כדי לוודא שאפשר להשתמש בגישה מבוססת-AI למניעת הלבנת הון (AML) בכל תחומי השיפוט שבהם המוסדות משרתים לקוחות. לדוגמה, בנק HSBC שיפר משמעותית את הביצועים של היחידה למאבק בפשעים פיננסיים (Fincrime) והשיג את התוצאות הבאות:

  • פי 2 עד 4 יותר פעילות חשודה מאומתת.
  • עלויות תפעול נמוכות יותר, כי המערכת מסננת יותר מ-60% מההתראות החיוביות השקריות, ומאפשרת להתמקד רק בהתראות שדורשות פעולה ומתייחסות לסיכון גבוה.
  • פלט שניתן לבדוק ולהסביר כדי לתמוך בעמידה בתקנות.

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

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

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

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

תכנון מחדש של הארכיטקטורה כדי להתאים אותה להזדמנויות ולדרישות חדשות

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

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

שימוש בחלופות מבוססות-ענן למערכות HPC ולמתזמנים מקומיים

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

מעבר לתכנות מבוסס-תרשים לסימולציות

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

להפעיל פלטפורמות מסחר ובורסות מבוססות-ענן

משיחות עם לקוחות של Google Cloud עולה שעיקרון פארטו (80/20) חל על דרישות הביצועים של שווקים ואפליקציות מסחר.

  • יותר מ-80% מאפליקציות המסחר לא צריכות זמן אחזור נמוך במיוחד. עם זאת, הם נהנים מהיתרונות המשמעותיים של יכולות העמידות, האבטחה והגמישות של הענן. לדוגמה, BidFX, פלטפורמה למסחר במט"ח עם מספר סוחרים, משתמשת בענן כדי להשיק מוצרים חדשים במהירות ולהגדיל באופן משמעותי את הזמינות ואת הנוכחות שלה בלי להגדיל את המשאבים.
  • שאר האפליקציות (פחות מ-20%) צריכות זמן אחזור קצר (פחות מאלפית השנייה), דטרמיניזם והוגנות בהעברת ההודעות. באופן מסורתי, המערכות האלה פועלות במתקנים קשיחים ויקרים לאחסון ואירוח שרתים (colocation). יותר ויותר אפליקציות מהקטגוריה הזו מועברות לפלטפורמה אחרת בענן, או בקצה או כאפליקציות בעדיפות לענן.

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

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

כדאי לעיין בהמלצות הבאות כדי להכין את הטכנולוגיה שלכם לעתיד.

אימוץ גישת "נתונים כשירות" (DaaS) כדי לקצר את זמן היציאה לשוק ולשפר את שקיפות העלויות

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

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

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

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

אחד הפתרונות לאתגר הזה הוא להשתמש בשכבת בידוד כמו מערכת לניהול ממשקי API או בשכבת ביניים כמו Spanner, שמשכפלת את מערכת הרישום ומאפשרת לשדרג את השירותים באמצעות ניתוח מתקדם ו-AI. לדוגמה, ב-Deutsche Bank השתמשו ב-Spanner כדי לבודד את מערכת הבנקאות הקיימת שלהם ולהתחיל בתהליך החדשנות.