במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מופיע סקירה כללית של עקרונות והמלצות לאופטימיזציה של העלות של עומסי העבודה של שירותים פיננסיים ב- Google Cloud. ההמלצות במסמך הזה תואמות לעקרון אופטימיזציית העלויות של Well-Architected Framework.
כדי לבצע אופטימיזציה חזקה של העלויות של עומסי עבודה בתחום השירותים הפיננסיים, צריך להשתמש ברכיבים הבסיסיים הבאים:
- היכולת לזהות שימוש במשאבים שמוביל לבזבוז לעומת שימוש במשאבים שמניב ערך.
- תרבות מוטמעת של אחריותיות פיננסית.
כדי לבצע אופטימיזציה של העלויות, צריך להבין באופן מקיף את הגורמים שמשפיעים על העלויות ואת צורכי המשאבים בארגון. בארגונים גדולים מסוימים, במיוחד בארגונים שנמצאים בשלב מוקדם של המעבר לענן, צוות אחד אחראי בדרך כלל לאופטימיזציה של ההוצאות במספר גדול של דומיינים. הגישה הזו מבוססת על ההנחה שצוות מרכזי הוא הגורם המתאים ביותר לזיהוי הזדמנויות בעלות ערך גבוה לשיפור היעילות.
הגישה הריכוזית עשויה להניב הצלחה מסוימת בשלבים הראשוניים של אימוץ הענן או עבור עומסי עבודה לא קריטיים. עם זאת, צוות אחד לא יכול להניע אופטימיזציה של עלויות בכל הארגון. כשיש עלייה בשימוש במשאבים או ברמת הבדיקה הרגולטורית, הגישה הריכוזית לא בת קיימא. צוותים ריכוזיים מתמודדים עם אתגרי מדרגיות, במיוחד כשמדובר במספר גדול של מוצרים ושירותים פיננסיים. צוותי הפרויקט שהם הבעלים של המוצרים והשירותים עשויים להתנגד לשינויים שנעשים על ידי צוות חיצוני.
כדי לבצע אופטימיזציה של העלויות בצורה יעילה, נתונים שקשורים להוצאות צריכים להיות גלויים מאוד, ומהנדסים ומשתמשי ענן אחרים שקרובים לעומסי העבודה צריכים להיות בעלי מוטיבציה לפעול כדי לבצע אופטימיזציה של העלויות. מבחינת הארגון, האתגר באופטימיזציה של העלויות הוא לזהות את התחומים שצריך לבצע בהם אופטימיזציה, לזהות את המהנדסים שאחראים לתחומים האלה ולשכנע אותם לבצע את פעולת האופטימיזציה הנדרשת. במסמך הזה מפורטות המלצות להתמודדות עם האתגר הזה.
ההמלצות לאופטימיזציה של העלויות במסמך הזה ממופות לעקרונות הליבה הבאים:
- זיהוי בזבוז באמצעות Google Cloud כלים
- זיהוי ערך באמצעות ניתוח והעשרה של נתוני ההוצאות
- הקצאת הוצאות כדי לשפר את האחריותיות
- שיפור האחריותיות ועידוד מהנדסים לפעולה
- מתמקדים בערך ובסך העלות של הבעלות (TCO) ולא בעלות
זיהוי בזבוז באמצעות Google Cloud כלים
Google Cloud מספקת כמה מוצרים, כלים ותכונות שיעזרו לכם לזהות בזבוז. כדאי לעיין בהמלצות הבאות.
שימוש באוטומציה וב-AI כדי לזהות באופן שיטתי את מה שצריך לבצע בו אופטימיזציה
Active Assist מספק המלצות חכמות לגבי שירותים כמו Cloud Run למיקרו-שירותים, BigQuery לניתוח נתונים, Compute Engine לאפליקציות ליבה ו-Cloud SQL למסדי נתונים רלציוניים. ההמלצות של Active Assist ניתנות ללא עלות וללא צורך בהגדרה מצדכם. ההמלצות עוזרות לכם לזהות משאבים לא פעילים והתחייבויות שלא מנוצלות מספיק.
ריכוז המעקב והשליטה ב-FinOps באמצעות ממשק מאוחד
דוחות החיוב ב-Cloud ומרכז FinOps מאפשרים לכם לעקוב אחרי העלויות בצורה מקיפה. התצוגה המקיפה הזו חיונית למבקרים פיננסיים ולצוותי פיננסים פנימיים כדי לעקוב אחרי ההוצאות על Cloud, להעריך את המצב הפיננסי, להעריך את רמת הבשלות של FinOps ביחידות עסקיות שונות או במרכזי עלויות, ולספק נרטיב פיננסי עקבי.
זיהוי ערך באמצעות ניתוח והעשרה של נתוני הוצאות
הכלי Active Assist יעיל בזיהוי בזבוז ברור. עם זאת, יכול להיות שיהיה קשה יותר לזהות את הערך, במיוחד אם עומסי העבודה נמצאים במוצרים לא מתאימים או אם אין התאמה ברורה בין עומסי העבודה לבין הערך העסקי. בעומסי עבודה של FS, הערך העסקי הוא לא רק הפחתת עלויות. הערך כולל צמצום סיכונים, עמידה בדרישות הרגולטוריות ויתרונות תחרותיים.
כדי להבין את ההוצאות בענן ואת הערך שלו באופן הוליסטי, צריך להבין את הנתונים באופן מלא בכמה רמות: מאיפה מגיעות ההוצאות, איזו פונקציה עסקית ההוצאות מקדמות והאם אפשר מבחינה טכנית לבצע רפקטורינג או אופטימיזציה של עומס העבודה הרלוונטי.
בתרשים הבא מוצגות דרכים להשתמש בפירמידת הנתונים, המידע, הידע והתבונה (DIKW) ובכלים של Google Cloud כדי לקבל תמונה מלאה של העלויות והערך של הענן.
בתרשים שלמעלה מוצג אופן השימוש בגישת DIKW כדי לזקק נתוני הוצאות גולמיים בענן לתובנות ולנתונים מעשיים שיעזרו לכם לקבל החלטות שיגדילו את הערך העסקי.
- נתונים: בשכבה הזו נאספים נתונים גולמיים ולא מעובדים של שימוש ועלויות של משאבי הענן. צוות FinOps המרכזי משתמש בכלים כמו חשבוניות של חיוב ב-Cloud, ייצוא נתוני חיוב ו-Cloud Monitoring כדי לקבל נתונים מפורטים וגרנולריים. לדוגמה, נקודת נתונים יכולה להיות מכונה וירטואלית בשם
app1-test-vmAשפעלה במשך 730 שעות באזורus-central1ועלתה 70 דולר ארה"ב. - מידע: בשכבה הזו, צוות FinOps מרכזי משתמש בכלים כמו דוחות חיוב ב-Cloud ו-FinOps Hub כדי לבנות את הנתונים הגולמיים בצורה שתעזור לענות על שאלות כמו "על אילו קטגוריות של משאבים אנשים מוציאים כסף?" לדוגמה, יכול להיות שתגלו שהוצאתם סכום כולל של 1,050$ על מכונות וירטואליות מסוג n4-standard-2 בשני אזורים בארה"ב.
- ידע: בשלב הזה, צוות FinOps המרכזי מעשיר את המידע בהקשר עסקי מתאים לגבי מי הוציא כסף ולשם מה. משתמשים במנגנונים כמו תיוג, הוספת תוויות, היררכיית משאבים, חשבונות לחיוב ולוחות בקרה מותאמים אישית ב-Looker. לדוגמה, יכול להיות שתגלו שצוות הבדיקות
app1בארה"ב הוציא 650 דולר ארה"ב במהלך השבוע השני של יולי כחלק מתרגיל בדיקת עומס. - תובנות: בשלב הזה, צוותי המוצר והאפליקציה משתמשים בידע שנוצר בהקשר כדי להעריך את הערך העסקי של ההוצאות על הענן ולקבל החלטות אסטרטגיות מושכלות. הצוותים שלכם יכולים לענות על שאלות כמו:
- האם ההוצאה של 5,000 דולר על צינור ניתוח נתונים מניבה ערך עסקי?
- האם אפשר לשנות את הארכיטקטורה של צינור הנתונים כדי שהוא יהיה יעיל יותר בלי לפגוע בביצועים?
כדאי לקחת בחשבון את ההמלצות הבאות לניתוח נתוני ההוצאות על Cloud.
ניתוח נתוני ההוצאות שסופקו על ידי Google Cloud
מתחילים עם נתוני חיוב מפורטים ב-Cloud שיוצאו ל-BigQuery ועם נתונים שזמינים ביומני Monitoring. כדי להפיק תובנות פרקטיות ולקבל החלטות, צריך לבנות את הנתונים האלה ולהוסיף להם הקשר עסקי.
המחשה ויזואלית של נתונים באמצעות כלים זמינים
אפשר להשתמש בכלים כמו Data Studio כדי להוסיף לדשבורדים המובנים דוחות בהתאמה אישית על בסיס נתונים שיוצאו מ-BigQuery. Google Cloud צוותי הכספים יכולים ליצור לוחות בקרה מותאמים אישית שנותנים הקשר להוצאות על שירותי ענן בהשוואה למדדים פיננסיים, לדרישות של דיווח רגולטורי ולרווחיות של היחידה העסקית. לאחר מכן, הם יכולים לספק תיאור פיננסי ברור לצורך ניתוח וקבלת החלטות על ידי בעלי עניין בכירים.
הקצאת הוצאות כדי לשפר את האחריותיות
אחרי שמבינים מה גורם להוצאות ב-Cloud, צריך לזהות מי מוציא כסף ולמה. כדי להגיע לרמת הבנה כזו, צריך להקצות עלויות בצורה יעילה, כלומר לצרף מטא-נתונים שרלוונטיים לעסק למשאבי הענן. לדוגמה, אם משאב מסוים נמצא בשימוש של צוות Banking-AppDev, אפשר לצרף למשאב תג כמו team=banking_appdev כדי לעקוב אחרי העלות שהצוות מוציא על המשאב הזה. במצב אידיאלי, צריך להקצות 100% מהעלויות בענן למקור ההוצאות. בפועל, יכול להיות שתתחילו עם יעד נמוך יותר כי בניית מבנה מטא-נתונים לתמיכה בהקצאת עלויות של 100% היא משימה מורכבת.
כדאי להיעזר בהמלצות הבאות כדי לפתח אסטרטגיה למטא-נתונים שתתמוך בהקצאת עלויות:
- תוקף: חשוב לוודא שהתגים עוזרים לזהות מדדי ביצועים מרכזיים (KPI) שקשורים לעסק ודרישות רגולטוריות. השיוך הזה חיוני לחיובים פנימיים, לדיווח רגולטורי ולתיאום בין ההוצאות ב-Cloud לבין היעדים של היחידה העסקית. לדוגמה, התגים הבאים מזהים בבירור את צוות ההוצאות, האזור והמוצר שעליו הם עובדים:
team=banking_appdev,region=emea,product=frontend. - אוטומציה: כדי להשיג רמה גבוהה של תאימות לתיוג, צריך לאכוף את התיוג באמצעות אוטומציה. תיוג ידני עלול להוביל לשגיאות ולחוסר עקביות, וזה לא מקובל בסביבות של שירותים פיננסיים שבהן היכולת לבצע ביקורת ודיוק פיננסי הם בעלי חשיבות עליונה. תיוג אוטומטי מבטיח שהמשאבים יסווגו בצורה נכונה כשהם נוצרים.
- פשטות: מודדים גורמים פשוטים ולא קשורים. סביבות FS הן מורכבות. כדי להבטיח שכללי הקצאת העלויות בסביבה כזו יהיו קלים להבנה ולאכיפה, הכללים צריכים להיות פשוטים ככל האפשר. כדאי להימנע מהגדרת כללים מורכבים מדי למקרים ספציפיים מאוד (מקרים קיצוניים). כללים מורכבים עלולים לגרום לבלבול ולהתנגדות מצד צוותי התפעול.
אחרי שמגדירים אסטרטגיית הקצאה באמצעות תגים, צריך להחליט על רמת הפירוט שבה האסטרטגיה תיושם. רמת הפירוט הנדרשת תלויה בצרכים העסקיים שלכם. לדוגמה, יכול להיות שחלק מהארגונים יצטרכו לעקוב אחרי העלויות ברמת המוצר, חלק יצטרכו נתוני עלויות לכל מרכז עלויות וחלק יצטרכו נתוני עלויות לכל סביבה (פיתוח, הכנה לייצור וייצור).
כדי להשיג את רמת הגרנולריות המתאימה להקצאת עלויות בארגון, אפשר להשתמש בגישות הבאות:
- השימוש בהיררכיית הפרויקטים ב- Google Cloud הוא נקודת התחלה טובה להקצאת עלויות. הפרויקטים מייצגים נקודות לאכיפת מדיניות ב- Google Cloud. כברירת מחדל, הרשאות IAM, מדיניות אבטחה ועלויות משויכות לפרויקטים ולתיקיות. כשבודקים נתוני עלויות שמיוצאים מחיוב ב-Cloud, אפשר לראות את היררכיית התיקיות ואת הפרויקטים שמשויכים לנתוני העלויות. אם היררכיית המשאבים ב-Google Cloud משקפת את מבנה האחריות של הארגון בנוגע להוצאות, זו הדרך הפשוטה ביותר להקצאת עלויות.
- כדי לקבל פירוט נוסף, אפשר להשתמש בתגים ובתוויות. הם מאפשרים לכם לסווג את המשאבים בייצוא נתוני החיוב בדרכים גמישות. התגים והתוויות עוזרים לכם לקבל פירוט עלויות לפי אפליקציה וסביבה.
לרוב, כדי להקצות עלויות בצורה יעילה, צריך להשתמש בהיררכיית הפרויקטים בשילוב עם תיוג ותיוג באמצעות תוויות. לא משנה באיזו גישה לבחירת עלויות תבחרו, חשוב לפעול לפי ההמלצות שתיארנו קודם כדי לפתח אסטרטגיית מטא-נתונים חזקה: אימות, אוטומציה ופשטות.
שיפור האחריות האישית ועידוד מהנדסים לפעולה
הצוות לניהול פרויקטים של FinOps בענן אחראי לוודא שהארגון מודע לעלויות ולערך. צוותי המוצר וצוותי ההנדסה צריכים לבצע את הפעולות הנדרשות לאופטימיזציה של העלויות. הצוותים האלה אחראים גם להתנהגות העלויות של עומסי העבודה של השירותים הפיננסיים, ולוודא שעומסי העבודה מספקים את הערך העסקי הנדרש.
כדאי לקחת בחשבון את ההמלצות הבאות כדי לעודד אחריות ולהניע צוותים לבצע אופטימיזציה של העלויות.
הקמת צוות FinOps מרכזי לצורך ניהול
נוהלי Cloud FinOps לא מתפתחים באופן אורגני. צוות ייעודי ל-FinOps צריך להגדיר ולבסס שיטות עבודה של FinOps באמצעות הפעולות הבאות:
- בניית התהליכים, הכלים וההנחיות הנדרשים.
- ליצור את המדיניות הנדרשת, כמו תיוג חובה, בדיקות תקציב ותהליכי אופטימיזציה, להעביר אותה לכל העובדים ולאכוף אותה.
- מעודדים את צוותי ההנדסה לקחת אחריות על העלויות.
- להתערב כשצוותי ההנדסה לא לוקחים אחריות על העלויות.
קבלת חסות והסכמה של מנהלים בכירים
ההנהלה הבכירה, כולל סמנכ"ל הטכנולוגיות, סמנכ"ל הכספים וסמנכ"ל המידע, צריכה לתמוך באופן פעיל במעבר של הארגון לתרבות FinOps. התמיכה שלהם חיונית כדי לתת עדיפות לאחריותיות בנוגע לעלויות, להקצות משאבים לתוכנית FinOps, להבטיח השתתפות חוצת-תפקידים ולעודד עמידה בדרישות של FinOps.
תמריצים לצוותים לאופטימיזציה של העלויות
יכול להיות שהמהנדסים וצוותי ההנדסה לא ירצו להתמקד באופטימיזציה של העלויות. חשוב להתאים את היעדים של הצוות והיעדים האישיים ליעילות העלויות באמצעות הטמעה של תמריצים כמו:
- כדאי להשקיע מחדש חלק מהחיסכון שהושג מאופטימיזציה של עלויות בצוותים שהשיגו את האופטימיזציה.
- להכיר בפומבי במאמצים ובהצלחות של אופטימיזציה של עלויות ולחגוג אותם.
- משתמשים בטכניקות של גיימיפיקציה כדי לתגמל צוותים שמבצעים אופטימיזציה יעילה של העלויות.
- שילוב מדדי יעילות ביעדי ביצועים.
יישום טכניקות של showback ו-chargeback
חשוב לוודא שלצוותים יש תצוגה ברורה של משאבי הענן והעלויות שלהם. להקצות אחריות פיננסית לאנשים המתאימים בצוותים. להשתמש במנגנונים רשמיים כדי לאכוף תיוג קפדני ולהטמיע כללים שקופים להקצאת עלויות משותפות.
התמקדות בערך ובסך העלות של הבעלות (TCO) במקום בעלות
כשמעריכים פתרונות בענן, חשוב לקחת בחשבון את עלות הבעלות הכוללת (TCO) בטווח הארוך. לדוגמה, אירוח עצמי של מסד נתונים לאפליקציה עשוי להיראות זול יותר משימוש בשירות מסד נתונים מנוהל כמו Cloud SQL. עם זאת, כדי להעריך את הערך ואת עלות הבעלות הכוללת בטווח הארוך, צריך לקחת בחשבון את העלויות הנסתרות שמשויכות למסדי נתונים באירוח עצמי. עלויות כאלה כוללות את המאמץ ההנדסי הייעודי לתיקון, להרחבה, לחיזוק האבטחה ולתוכנית התאוששות מאסון (DR), שהם דרישות קריטיות לעומסי עבודה של שירותים פיננסיים. שירותים מנוהלים מספקים ערך גבוה משמעותית בטווח הארוך, שמקזז את עלויות התשתית. שירותים מנוהלים מספקים יכולות תאימות חזקות, כוללים תכונות אמינות מובנות ויכולים לעזור לכם להפחית את התקורה התפעולית.
כדאי לקחת בחשבון את ההמלצות הבאות כדי להתמקד בערך ובסך עלות הבעלות.
שימוש בטכניקות ובכלים ספציפיים למוצרים לאופטימיזציה של משאבים
כדאי להשתמש בתכונות ובכלים לאופטימיזציה של עלויות שזמינים במוצרים של Google Cloud, כמו:
- Compute Engine: Autoscaling, custom machine types, and Spot VMs
- GKE: מידרוג אוטומטי של אשכולות ו-הקצאת צמתים אוטומטית (NAP)
- Cloud Storage: ניהול מחזור חיים של אובייקטים וסיווג אוטומטי
- BigQuery: תמחור לפי קיבולת וטכניקות לייעול העלויות
- Google Cloud VMware Engine: הנחות תמורת התחייבות לשימוש (CUD), אופטימיזציה של נפח אחסון ואסטרטגיות נוספות לאופטימיזציה של עלויות
ליהנות מהנחות
כדי לוודא ששיעור החיוב על משאבי הענן שלכם נמוך ככל האפשר, כדאי להשתמש בהנחות ש-Google מציעה. בדרך כלל צוותי המוצר וההנדסה הנפרדים מנהלים את אופטימיזציית המשאבים. הצוות המרכזי של FinOps אחראי לאופטימיזציה של תעריפי החיוב, כי יש לו גישה לנתונים על דרישות המשאבים בכל הארגון. לכן, הם יכולים לצבור את הדרישות ולמקסם את ההנחות על התחייבות לשימוש.
אפשר ליהנות מההנחות הבאות על משאבים ב-Google Cloud :
- הנחות לארגונים הן הנחות שנקבעות במשא ומתן על סמך ההתחייבות של הארגון להוציא סכום מינימלי כולל על Google Cloud בתעריף חיוב מופחת.
- הנחות תמורת התחייבות לשימוש במשאבים ניתנות בתמורה להתחייבות להשתמש בכמות מינימלית של משאבי Compute Engine במשך שנה או שלוש שנים. הנחות תמורת התחייבות לשימוש במשאבים חלות על משאבים שנמצאים בפרויקט ובאזור ספציפיים. כדי לחלק את ההנחות תמורת התחייבות לשימוש בין כמה פרויקטים, אתם יכולים להפעיל את חלוקת ה-CUD.
- הנחות תמורת התחייבות להוצאה ניתנות בתמורה להתחייבות להוציא סכום מינימלי על מוצר מסוים במשך שנה או שלוש שנים. הנחות על סמך הוצאות חלות ברמת החשבון לחיוב. ההנחות חלות באופן אזורי או גלובלי, בהתאם למוצר.
אתם יכולים לחסוך משמעותית בעלויות באמצעות הנחות תמורת התחייבות לשימוש (CUD) בנוסף להנחות לארגונים.
בנוסף להנחות תמורת התחייבות לשימוש (CUD), אפשר להשתמש בגישות הבאות כדי להפחית את תעריפי החיוב:
- כדאי להשתמש ב-Spot VMs לעומסי עבודה גמישים ועמידים בפני תקלות. העלות של Spot VMs נמוכה ביותר מ-80% מזו של מכונות וירטואליות רגילות.
- ב-BigQuery יש כמה מודלים לתמחור, כולל תמחור לפי דרישה ותמחור לפי מהדורה שמבוסס על התחייבויות לשימוש ודרישות של התאמה אוטומטית לעומס. אם אתם משתמשים בכמות גדולה של משאבי BigQuery, כדאי לבחור במהדורה מתאימה כדי להקטין את העלות לכל משבצת זמן של עומסי עבודה של ניתוח נתונים.
- חשוב לבדוק בקפידה את Google Cloud האזורים שבהם השירותים שאתם צריכים זמינים. מומלץ לבחור אזורים שתואמים ליעדי העלות שלכם ולגורמים כמו זמן אחזור ודרישות תאימות. כדי להבין את ההבדלים בין עלות, קיימות וזמן אחזור, אפשר להשתמש בGoogle Cloud כלי לבחירת אזור.