במאמר הזה, שהוא חלק מהסדרה Google Cloud Well-Architected Framework: נקודת המבט של שירותים פיננסיים (FS), נסביר על העקרונות וההמלצות לאופטימיזציה של עלויות עומסי העבודה של FS ב- 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 Hub מאפשרים לכם להטמיע מעקב מקיף אחרי העלויות. התצוגה המקיפה הזו חיונית למבקרי כספים ולמחלקה פיננסית פנימית כדי לעקוב אחרי ההוצאות בענן, להעריך את המצב הפיננסי, להעריך את הבשלות של FinOps ביחידות עסקיות שונות או במרכזי עלויות, ולספק נרטיב פיננסי עקבי.
זיהוי ערך על ידי ניתוח והעשרה של נתוני ההוצאות
Active Assist יעיל בזיהוי בזבוז ברור. עם זאת, קשה יותר להצביע על הערך, במיוחד כשעומסי העבודה הם על מוצרים לא מתאימים או כשעומסי העבודה לא תואמים באופן ברור לערך העסקי. בעומסי עבודה של שירותים פיננסיים, הערך העסקי הוא לא רק הפחתת עלויות. הערך כולל צמצום סיכונים, עמידה בדרישות הרגולציה ויתרונות תחרותיים.
כדי להבין את ההוצאות והערך של הענן באופן הוליסטי, צריך להבין באופן מלא כמה רמות: מה מקור ההוצאה, איזו פונקציה עסקית ההוצאה מניעה, וההיתכנות הטכנית של ארגון מחדש או אופטימיזציה של עומס העבודה הרלוונטי.
בתרשים הבא מוצג איך אפשר להשתמש בפירמידת הנתונים-מידע-ידע-חוכמה (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 דולר ארה"ב שהוצאו על צינור עיבוד נתונים של ניתוח נתונים מייצרים ערך עסקי?
- האם אפשר לשנות את הארכיטקטורה של צינור עיבוד הנתונים כדי שיהיה יעיל יותר בלי לפגוע בביצועים?
כדאי להביא בחשבון את ההמלצות הבאות לניתוח נתוני ההוצאות בענן.
ניתוח נתוני ההוצאות שסופקו על ידי 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. - אוטומציה: כדי להשיג רמה גבוהה של תאימות לתיוג, צריך לאכוף את התיוג באמצעות אוטומציה. תיוג ידני נוטה לשגיאות ולחוסר עקביות, וזה לא מקובל בסביבות של שירותים פיננסיים שבהן יכולת הביקורת והדיוק הפיננסי הם בעלי חשיבות עליונה. תיוג אוטומטי מבטיח שהמשאבים ישויכו לקטגוריה הנכונה כשהם נוצרים.
- פשטות: מודדים גורמים פשוטים שלא קשורים זה לזה. סביבות FS הן מורכבות. כדי לוודא שקל להבין ולאכוף את הכללים להקצאת עלויות בסביבה כזו, הכללים צריכים להיות פשוטים ככל האפשר. אל תגדירו כללים מורכבים מדי למקרים ספציפיים מאוד (מקרי קצה). כללים מורכבים עלולים לגרום לבלבול ולהתנגדות מצד צוותי התפעול.
אחרי שמגדירים אסטרטגיית הקצאה באמצעות תגים, צריך להחליט על רמת הפירוט שבה האסטרטגיה תיושם. רמת הפירוט הנדרשת תלויה בצרכים העסקיים שלכם. לדוגמה, יכול להיות שארגונים מסוימים צריכים לעקוב אחרי העלויות ברמת המוצר, אחרים צריכים נתוני עלות לכל מרכז עלות, ויש כאלה שצריכים נתוני עלות לכל סביבה (פיתוח, 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מספקים, כמו:
- Compute Engine: התאמה אוטומטית לעומס, סוגי מכונות בהתאמה אישית וVM במודל Spot
- Google Kubernetes Engine: מידרוג אוטומטי של אשכול והקצאת צמתים אוטומטית (NAP)
- Cloud Storage: ניהול מחזור חיים של אובייקטים וסיווג אוטומטי
- BigQuery: תמחור מבוסס-קיבולת ושיטות לאופטימיזציה של עלויות
- Google Cloud VMware Engine: הנחות תמורת התחייבות לשימוש (CUD), אופטימיזציה של האחסון ואסטרטגיות אחרות לאופטימיזציה של עלויות
ליהנות מהנחות
כדי לוודא ששיעור החיוב על משאבי הענן נמוך ככל האפשר, כדאי להשתמש בהנחות ש-Google מציעה. בדרך כלל, צוותי המוצר וההנדסה הם אלה שמנהלים את אופטימיזציית המשאבים. צוות ה-FinOps המרכזי אחראי על אופטימיזציה של שיעורי החיוב, כי יש לו גישה לדרישות המשאבים בכל הארגון. לכן, הם יכולים לצבור את הדרישות ולמקסם את ההנחות תמורת התחייבות.
אתם יכולים לנצל את סוגי ההנחות הבאים על משאבים ב-Google Cloud :
- הנחות לארגונים הן הנחות שנקבעות במשא ומתן על סמך ההתחייבות של הארגון להוצאה כוללת מינימלית על Google Cloud בתעריף חיוב מופחת.
- הנחות תמורת התחייבות לשימוש במשאבים ניתנות בתמורה להתחייבות להשתמש בכמות מינימלית של משאבי Compute Engine במשך שנה או שלוש שנים. הנחות תמורת התחייבות לשימוש במשאבים חלות על המשאבים שנמצאים באזור ספציפי. ברוב החשבונות לחיוב ב-Cloud, ההגדרה Google Cloud מפעילה את חלוקת ההנחות תמורת התחייבות לשימוש במשאבים, ומחלקת את ההנחות בין כל הפרויקטים שמשויכים לאותו חשבון.
- הנחות תמורת התחייבות להוצאה ניתנות בתמורה להתחייבות להוציא סכום כסף מינימלי על מוצר מסוים, בפרק זמן של שנה או שלוש שנים. הנחות שמבוססות על הוצאות חלות ברמת החשבון לחיוב. ההנחות חלות באופן אזורי או גלובלי, בהתאם למוצר.
אתם יכולים לחסוך הרבה כסף אם תשתמשו בהנחות תמורת התחייבות לשימוש בנוסף להנחות לארגונים.
בנוסף ל-CUD, אתם יכולים להשתמש בשיטות הבאות כדי להפחית את שיעורי החיוב:
- להשתמש ב-VM במודל Spot לעומסי עבודה (workloads) גמישים ועמידים בכשלים. המחיר של מכונות וירטואליות במודל Spot זול ביותר מ-80% מהמחיר של מכונות וירטואליות רגילות.
- ב-BigQuery יש כמה מודלים של תמחור, כולל תמחור על פי דרישה ותמחור מבוסס-מהדורה שמבוסס על התחייבויות ודרישות של התאמה לעומס (scaling) אוטומטית. אם אתם משתמשים בכמות גדולה של משאבים ב-BigQuery, כדאי לבחור מהדורה מתאימה כדי להוזיל את העלות לכל חריץ של עומסי עבודה שקשורים לניתוח נתונים.
- חשוב לבדוק בקפידה את Google Cloud האזורים הזמינים לשירותים שבהם אתם צריכים להשתמש. בחרו אזורים שמתאימים ליעדי העלות שלכם ולגורמים כמו דרישות זמן אחזור ותאימות. כדי להבין את הפשרות בין עלות, קיימות וזמן אחזור, השתמשו ב-Google Cloud Region Picker.