במסמך הזה, שמופיע ב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 המרכזי משתמש בכלים כמו דוחות חיוב בענן ו-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. לשם כך, הוא צריך:
- בניית התהליכים, הכלים וההנחיות הנדרשים.
- ליצור את המדיניות הנדרשת, כמו תיוג חובה, בדיקות תקציב ותהליכי אופטימיזציה, להעביר אותה לכל העובדים ולאכוף אותה.
- מעודדים את צוותי ההנדסה לקחת אחריות על העלויות.
- להתערב כשצוותי ההנדסה לא לוקחים אחריות על העלויות.
קבלת חסות והסכמה של מנהלים בכירים
ההנהלה הבכירה, כולל מנהל הטכנולוגיות הראשי (CTO), מנהל הכספים הראשי (CFO) ומנהל המידע הראשי (CIO), צריכה לתמוך באופן פעיל במעבר של הארגון לתרבות FinOps. התמיכה שלהם חיונית כדי לתת עדיפות לאחריותיות בנוגע לעלויות, להקצות משאבים לתוכנית FinOps, להבטיח השתתפות חוצת-תפקידים ולעודד עמידה בדרישות של FinOps.
תמריצים לצוותים לאופטימיזציה של העלויות
יכול להיות שהמהנדסים וצוותי ההנדסה לא ירצו להתמקד באופטימיזציה של העלויות. חשוב להתאים את היעדים של הצוות והיעדים האישיים ליעילות העלויות באמצעות הטמעה של תמריצים כמו:
- כדאי להשקיע מחדש חלק מהחיסכון שהושג מאופטימיזציה של עלויות בצוותים שהשיגו את האופטימיזציה.
- להכיר בפומבי במאמצים ובהצלחות של אופטימיזציה של עלויות ולחגוג אותם.
- משתמשים בטכניקות של גיימיפיקציה כדי לתגמל צוותים שמבצעים אופטימיזציה יעילה של העלויות.
- שילוב מדדי יעילות ביעדי ביצועים.
יישום טכניקות של showback ו-chargeback
חשוב לוודא שלצוותים יש תצוגה ברורה של משאבי הענן והעלויות שהם אחראים להם. להקצות אחריות פיננסית לאנשים המתאימים בצוותים. כדאי להשתמש במנגנונים רשמיים כדי לאכוף תיוג קפדני ולהטמיע כללים שקופים להקצאת עלויות משותפות.
התמקדות בערך ובסך העלות של הבעלות (TCO) במקום בעלות
כשמעריכים פתרונות ענן, חשוב לקחת בחשבון את עלות הבעלות הכוללת (TCO) לטווח הארוך. לדוגמה, יכול להיות שאירוח עצמי של מסד נתונים לאפליקציה ייראה זול יותר משימוש בשירות מנוהל של מסד נתונים כמו Cloud SQL. עם זאת, כדי להעריך את הערך לטווח ארוך ואת העלות הכוללת של הבעלות, צריך לקחת בחשבון את העלויות הסמויות שקשורות למסדי נתונים באירוח עצמי. העלויות האלה כוללות את המאמץ ההנדסי הייעודי לתיקון באגים, להרחבה, להקשחת אבטחה ולשחזור אחרי אסון, שהן דרישות קריטיות לעומסי עבודה של FS. שירותים מנוהלים מספקים ערך גבוה יותר לטווח ארוך, שמקזז את עלויות התשתית. שירותים מנוהלים מספקים יכולות חזקות של תאימות, כוללים תכונות אמינות מובנות ויכולים לעזור לכם לצמצם את ההוצאות התפעוליות.
כדאי לקחת בחשבון את ההמלצות הבאות כדי להתמקד בערך ובסך עלות הבעלות.
שימוש בטכניקות ובכלים ספציפיים למוצרים לאופטימיזציה של משאבים
כדאי להשתמש בתכונות ובכלים לאופטימיזציה של עלויות שזמינים במוצרים של Google Cloud, כמו:
- Compute Engine: Autoscaling, custom machine types, and Spot VMs
- GKE: Cluster autoscaler and node auto-provisioning
- Cloud Storage: ניהול מחזור חיים של אובייקטים וסיווג אוטומטי
- BigQuery: תמחור לפי קיבולת וטכניקות לייעול העלויות
- Google Cloud VMware Engine: הנחות תמורת התחייבות לשימוש (CUD), אופטימיזציה של נפח אחסון ואסטרטגיות נוספות לאופטימיזציה של עלויות
ליהנות מהנחות
כדי לוודא ששיעור החיוב על משאבי הענן שלכם נמוך ככל האפשר, כדאי להשתמש בהנחות ש-Google מציעה. בדרך כלל צוותי המוצר וההנדסה הנפרדים מנהלים את אופטימיזציית המשאבים. הצוות המרכזי של FinOps אחראי לאופטימיזציה של תעריפי החיוב, כי יש לו גישה לנתונים על דרישות המשאבים בכל הארגון. לכן, הם יכולים לצבור את הדרישות ולמקסם את ההנחות שמבוססות על התחייבות.
אפשר ליהנות מההנחות הבאות על משאבים ב-Google Cloud :
- הנחות לארגונים הן הנחות שנקבעות במשא ומתן על סמך ההתחייבות של הארגון להוציא סכום מינימלי כולל על Google Cloud בתעריף חיוב מופחת.
- הנחות תמורת התחייבות לשימוש במשאבים ניתנות בתמורה להתחייבות להשתמש בכמות מינימלית של משאבי Compute Engine במשך שנה או שלוש שנים. הנחות תמורת התחייבות לשימוש במשאבים חלות על משאבים שנמצאים באזור ספציפי. ברוב החשבונות לחיוב ב-Cloud, Google Cloud ההגדרה הזו מפעילה חלוקת הנחות תמורת התחייבות לשימוש (CUD) שמבוססות על משאבים, וההנחות מתחלקות בין כל הפרויקטים שמשויכים לחשבון הזה.
- הנחות תמורת התחייבות להוצאה ניתנות בתמורה להתחייבות להוציא סכום מינימלי על מוצר מסוים במשך שנה או שלוש שנים. הנחות על סמך הוצאות חלות ברמת החשבון לחיוב. ההנחות חלות באופן אזורי או גלובלי, בהתאם למוצר.
אתם יכולים לחסוך משמעותית בעלויות באמצעות הנחות תמורת התחייבות לשימוש (CUD) בנוסף להנחות לארגונים.
בנוסף להנחות תמורת התחייבות לשימוש (CUD), אפשר להשתמש בגישות הבאות כדי להפחית את תעריפי החיוב:
- כדאי להשתמש ב-Spot VMs לעומסי עבודה (workloads) עמידים בכשלים וגמישים. העלות של מכונות Spot VM נמוכה ביותר מ-80% מזו של מכונות רגילות.
- ב-BigQuery יש כמה מודלים לתמחור, כולל תמחור לפי דרישה ותמחור לפי מהדורה שמבוסס על התחייבויות ודרישות של שינוי גודל אוטומטי. אם אתם משתמשים בכמות גדולה של משאבי BigQuery, כדאי לבחור במהדורה מתאימה כדי להקטין את העלות לכל משבצת זמן של עומסי עבודה של ניתוח נתונים.
- חשוב לבדוק בקפידה את האזורים הזמינים לשירותים שבהם אתם רוצים להשתמש. Google Cloud בוחרים אזורים שתואמים ליעדי העלות ולגורמים כמו זמן אחזור ודרישות תאימות. כדי להבין את האיזון בין עלות, קיימות וזמן אחזור, אפשר להשתמש בGoogle Cloud כלי לבחירת אזור.