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