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