במאמר הזה ב-Google Cloud Well-Architected Framework: Financial services (FS) perspective מופיע סקירה כללית של עקרונות והמלצות לאופטימיזציה של העלויות של עומסי העבודה של שירותים פיננסיים ב- Google Cloud. ההמלצות במסמך הזה תואמות לעקרון אופטימיזציית העלויות של Well-Architected Framework.
כדי לבצע אופטימיזציה חזקה של העלויות של עומסי עבודה בתחום השירותים הפיננסיים, צריך להשתמש ברכיבים הבסיסיים הבאים:
- היכולת לזהות שימוש במשאבים שאינו יעיל לעומת שימוש במשאבים שמניב ערך.
- תרבות מוטמעת של אחריותיות פיננסית.
כדי לבצע אופטימיזציה של העלויות, צריך להבין באופן מקיף את הגורמים שמשפיעים על העלויות ואת צורכי המשאבים בארגון. בארגונים גדולים מסוימים, במיוחד בארגונים שנמצאים בשלב מוקדם של המעבר לענן, צוות אחד אחראי בדרך כלל לאופטימיזציה של ההוצאות במספר גדול של דומיינים. הגישה הזו מבוססת על ההנחה שצוות מרכזי הוא הגורם המתאים ביותר לזיהוי הזדמנויות בעלות ערך גבוה לשיפור היעילות.
הגישה הריכוזית עשויה להניב הצלחה מסוימת בשלבים הראשוניים של אימוץ הענן או עבור עומסי עבודה לא קריטיים. עם זאת, צוות אחד לא יכול לבצע אופטימיזציה של העלויות בכל הארגון. כששימוש המשאבים או רמת הבדיקה הרגולטורית עולים, הגישה המרכזית לא בת קיימא. צוותים מרכזיים מתמודדים עם אתגרי מדרגיות, במיוחד כשמדובר במספר גדול של מוצרים ושירותים פיננסיים. יכול להיות שצוותי הפרויקט שבבעלותם המוצרים והשירותים יתנגדו לשינויים שבוצעו על ידי צוות חיצוני.
כדי לבצע אופטימיזציה של העלויות בצורה יעילה, נתונים שקשורים להוצאות צריכים להיות גלויים מאוד, ומהנדסים ומשתמשי ענן אחרים שקרובים לעומסי העבודה צריכים להיות בעלי מוטיבציה לפעול כדי לבצע אופטימיזציה של העלויות. מבחינה ארגונית, האתגר באופטימיזציה של העלויות הוא לזהות את התחומים שצריך לבצע בהם אופטימיזציה, לזהות את המהנדסים שאחראים לתחומים האלה ולשכנע אותם לבצע את פעולת האופטימיזציה הנדרשת. במסמך הזה מפורטות המלצות להתמודדות עם האתגר הזה.
ההמלצות לאופטימיזציה של העלויות במסמך הזה ממופות לעקרונות הליבה הבאים:
- זיהוי בזבוז באמצעות Google Cloud כלים
- זיהוי ערך באמצעות ניתוח והעשרה של נתוני ההוצאות
- הקצאת הוצאות כדי לשפר את האחריותיות
- שיפור האחריותיות ועידוד מהנדסים לפעולה
- מתמקדים בערך ובסך העלות הכוללת במקום בעלות
זיהוי בזבוז באמצעות Google Cloud כלים
Google Cloud מספקת כמה מוצרים, כלים ותכונות שיעזרו לכם לזהות בזבוז. כדאי לעיין בהמלצות הבאות.
שימוש באוטומציה וב-AI כדי לזהות באופן שיטתי את מה שצריך לבצע בו אופטימיזציה
Active Assist מספק המלצות חכמות לגבי שירותים כמו Cloud Run למיקרו-שירותים, BigQuery לניתוח נתונים, Compute Engine לאפליקציות ליבה ו-Cloud SQL למסדי נתונים רלציוניים. ההמלצות של Active Assist ניתנות ללא עלות וללא צורך בהגדרה מצדכם. ההמלצות עוזרות לכם לזהות משאבים לא פעילים והתחייבויות שלא מנוצלות מספיק.
ריכוז המעקב והשליטה ב-FinOps באמצעות ממשק מאוחד
דוחות החיוב ב-Cloud ומרכז FinOps מאפשרים לכם להטמיע מעקב מקיף אחרי העלויות. התצוגה המקיפה הזו חיונית לצוותי ביקורת פיננסית ולצוותי כספים פנימיים כדי לעקוב אחרי ההוצאות על הענן, להעריך את המצב הפיננסי, לבדוק את רמת הבשלות של FinOps ביחידות עסקיות שונות או במרכזי עלויות, ולספק נרטיב פיננסי עקבי.
זיהוי ערך באמצעות ניתוח והעשרה של נתוני הוצאות
הכלי Active Assist יעיל בזיהוי בזבוז ברור. עם זאת, יכול להיות שיהיה קשה יותר לזהות את הערך, במיוחד אם עומסי העבודה נמצאים במוצרים לא מתאימים או אם אין התאמה ברורה בין עומסי העבודה לבין הערך העסקי. בעומסי עבודה של FS, הערך העסקי הוא לא רק הפחתת עלויות. הערך כולל צמצום סיכונים, עמידה בדרישות הרגולטוריות ויתרונות תחרותיים.
כדי להבין את ההוצאות בענן ואת הערך שלו באופן הוליסטי, צריך להבין את הנושא באופן מלא בכמה רמות: מאיפה מגיעות ההוצאות, איזו פונקציה עסקית ההוצאות מקדמות והאם אפשר מבחינה טכנית לבצע ארגון הקוד מחדש (Refactoring) או אופטימיזציה של עומס העבודה הרלוונטי.
בתרשים הבא מוצגות דרכים להשתמש בפירמידת הנתונים, המידע, הידע והתובנות (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. כדי להפיק תובנות פרקטיות ולקבל החלטות, צריך לבנות את הנתונים האלה ולהוסיף להם הקשר עסקי.
הצגת הנתונים באמצעות כלים זמינים
אפשר להוסיף לדשבורדים המובנים Google Cloud דוחות בהתאמה אישית באמצעות כלים כמו Looker Studio על בסיס נתונים שיוצאו מ-BigQuery. צוותי הכספים יכולים ליצור לוחות בקרה מותאמים אישית שנותנים הקשר להוצאות על הענן בהשוואה למדדים פיננסיים, לדרישות רגולטוריות לדיווח ולרווחיות של היחידה העסקית. לאחר מכן, הם יכולים לספק תיאור ברור של המצב הפיננסי לצורך ניתוח וקבלת החלטות על ידי בעלי עניין בכירים.
הקצאת הוצאות כדי לשפר את האחריותיות
אחרי שמבינים מה גורם להוצאות ב-Cloud, צריך לזהות מי מוציא כסף ולמה. כדי להגיע לרמת ההבנה הזו, צריך להקפיד על שיטת הקצאת עלויות אמינה, שכוללת צירוף מטא-נתונים שרלוונטיים לעסק למשאבי הענן. לדוגמה, אם צוות Banking-AppDev משתמש במשאב מסוים, אפשר לצרף למשאב תג כמו team=banking_appdev כדי לעקוב אחרי העלות שהצוות מוציא על המשאב הזה. מומלץ להקצות 100% מהעלויות ב-Cloud למקור ההוצאות. בפועל, יכול להיות שתתחילו עם יעד נמוך יותר כי בניית מבנה מטא-נתונים לתמיכה בהקצאת עלויות של 100% היא משימה מורכבת.
כדאי להיעזר בהמלצות הבאות כדי לפתח אסטרטגיה למטא-נתונים שתתמוך בהקצאת עלויות:
- תוקף: מוודאים שהתגים עוזרים לזהות מדדי ביצועים מרכזיים (KPI) שקשורים לעסק ודרישות רגולטוריות. השיוך הזה חשוב מאוד לחיובים פנימיים, לדיווחים רגולטוריים ולתיאום ההוצאות ב-Cloud עם היעדים של היחידה העסקית. לדוגמה, התגים הבאים מזהים בבירור את צוות ההוצאות, האזור והמוצר שעליו הם עובדים:
team=banking_appdev,region=emea,product=frontend. - אוטומציה: כדי להשיג רמה גבוהה של תאימות לתיוג, כדאי לאכוף את התיוג באמצעות אוטומציה. תיוג ידני עלול לגרום לשגיאות ולחוסר עקביות, וזה לא מקובל בסביבות FS שבהן חשובים במיוחד יכולת הביקורת ודיוק נתונים פיננסיים. תיוג אוטומטי מוודא שהמשאבים מסווגים בצורה נכונה כשהם נוצרים.
- פשטות: מדידת גורמים פשוטים ולא קשורים. סביבות FS הן מורכבות. כדי להבטיח שכללי הקצאת העלויות בסביבה כזו יהיו קלים להבנה וליישום, הכללים צריכים להיות פשוטים ככל האפשר. כדאי להימנע מהגדרת כללים מורכבים מדי למקרים ספציפיים מאוד (מקרים קיצוניים). כללים מורכבים עלולים לגרום לבלבול ולהתנגדות מצד צוותי התפעול.
אחרי שמגדירים אסטרטגיית הקצאה באמצעות תגים, צריך להחליט באיזו רמת פירוט להטמיע את האסטרטגיה. רמת הפירוט הנדרשת תלויה בצרכים העסקיים שלכם. לדוגמה, יכול להיות שחלק מהארגונים יצטרכו לעקוב אחרי העלויות ברמת המוצר, חלק יצטרכו נתוני עלויות לכל מרכז עלויות וחלק יצטרכו נתוני עלויות לכל סביבה (פיתוח, הכנה לייצור וייצור).
כדי להשיג את רמת הגרנולריות המתאימה להקצאת עלויות בארגון, אפשר להשתמש בגישות הבאות:
- אפשר להשתמש בהיררכיית הפרויקטים ב- Google Cloud כנקודת התחלה טבעית להקצאת עלויות. פרויקטים מייצגים נקודות לאכיפת מדיניות ב- Google Cloud. כברירת מחדל, הרשאות IAM, מדיניות אבטחה ועלויות משויכות לפרויקטים ולתיקיות. כשבודקים נתוני עלויות שמיוצאים מחיוב ב-Cloud, אפשר לראות את היררכיית התיקיות ואת הפרויקטים שמשויכים לנתוני העלויות. אם היררכיית המשאבים שלכם ב-Google Cloud משקפת את מבנה האחריות של הארגון שלכם להוצאות, זו הדרך הפשוטה ביותר להטמיע הקצאת עלויות.
- כדי להשיג רמת פירוט נוספת, אפשר להשתמש בתגים ובתוויות. הם מספקים דרכים גמישות לסיווג משאבים בייצוא של נתוני החיוב. תגים ותוויות מאפשרים לפרט את העלויות לפי אפליקציה וסביבה.
לרוב, כדי להקצות עלויות בצורה יעילה, צריך להשתמש בהיררכיית הפרויקטים בשילוב עם תיוג ותיוג באמצעות תוויות. לא משנה באיזו גישה לבחירת הקצאת עלויות תבחרו, חשוב לפעול לפי ההמלצות שתיארנו קודם לפיתוח אסטרטגיית מטא-נתונים חזקה: אימות, אוטומציה ופשטות.
הגברת האחריות ועידוד מהנדסים לפעולה
הצוות לניהול פרויקטים של FinOps בענן אחראי לוודא שהארגון מודע לעלויות ולערך. צוותי המוצר וצוותי ההנדסה צריכים לבצע את הפעולות הנדרשות לאופטימיזציה של העלויות. הצוותים האלה אחראים גם להתנהגות העלויות של עומסי העבודה של השירותים הפיננסיים, ולוודא שעומסי העבודה מספקים את הערך העסקי הנדרש.
כדי לעודד את הצוותים לקחת אחריות ולבצע אופטימיזציה של העלויות, כדאי ליישם את ההמלצות הבאות.
הקמת צוות FinOps מרכזי לצורך ניהול
נוהלי Cloud FinOps לא מתפתחים באופן אורגני. צוות ייעודי ל-FinOps צריך להגדיר ולבסס שיטות עבודה של FinOps על ידי ביצוע הפעולות הבאות:
- ליצור את התהליכים, הכלים וההנחיות הנדרשים.
- יוצרים את המדיניות הנדרשת, כמו תיוג חובה, בדיקות תקציב ותהליכי אופטימיזציה, מעבירים אותה לכל העובדים ומוודאים שהם פועלים לפיה.
- מעודדים את צוותי ההנדסה לקחת אחריות על העלויות.
- להתערב כשצוותי ההנדסה לא לוקחים אחריות על העלויות.
קבלת חסות והסכמה של מנהלים בכירים
ההנהלה הבכירה, כולל סמנכ"ל הטכנולוגיות, סמנכ"ל הכספים וסמנכ"ל המידע, צריכה לתמוך באופן פעיל במעבר לתרבות FinOps בכל הארגון. התמיכה שלהם חיונית כדי לתת עדיפות לאחריותיות בנוגע לעלויות, להקצות משאבים לתוכנית FinOps, להבטיח השתתפות חוצת-תפקידים ולעודד עמידה בדרישות של FinOps.
תמריצים לצוותים לאופטימיזציה של העלויות
יכול להיות שמהנדסים וצוותי הנדסה לא ירצו להתמקד באופטימיזציה של העלויות. חשוב להתאים את היעדים של הצוות והיעדים האישיים ליעילות העלויות באמצעות הטמעה של תמריצים כמו:
- כדאי להשקיע מחדש חלק מהחיסכון שהושג מאופטימיזציה של עלויות בצוותים שהשיגו את האופטימיזציה.
- לפרסם את המאמצים וההצלחות של אופטימיזציה של עלויות.
- משתמשים בטכניקות של מישחוּק (gamification) כדי לתגמל צוותים שמבצעים אופטימיזציה של העלויות בצורה יעילה.
- שילוב מדדי יעילות ביעדי ביצועים.
יישום של טכניקות showback ו-chargeback
חשוב לוודא שלצוותים יש גישה ברורה למשאבי הענן ולעלויות שלהם. להקצות אחריות פיננסית לאנשים המתאימים בצוותים. להשתמש במנגנונים רשמיים כדי לאכוף תיוג קפדני ולהטמיע כללים שקופים להקצאת עלויות משותפות.
התמקדות בערך ובסך העלות של הבעלות (TCO) במקום בעלות
כשמעריכים פתרונות ענן, חשוב לקחת בחשבון את עלות הבעלות הכוללת (TCO) לטווח הארוך. לדוגמה, יכול להיות שאירוח עצמי של מסד נתונים לאפליקציה ייראה זול יותר משימוש בשירות מנוהל של מסד נתונים כמו Cloud SQL. עם זאת, כדי להעריך את הערך לטווח ארוך ואת העלות הכוללת של הבעלות, צריך לקחת בחשבון את העלויות הסמויות שקשורות למסדי נתונים באירוח עצמי. העלויות האלה כוללות את המאמץ ההנדסי הייעודי לתיקון פרצות אבטחה, להרחבה, להקשחת אבטחה ולתוכנית התאוששות מאסון (DR), שהן דרישות קריטיות לעומסי עבודה של FS. שירותים מנוהלים מספקים ערך גבוה משמעותית לטווח הארוך, שמקזז את עלויות התשתית. שירותים מנוהלים מספקים יכולות חזקות של תאימות, כוללים תכונות אמינות מובנות ויכולים לעזור לכם לצמצם את התקורה התפעולית.
כדאי לקחת בחשבון את ההמלצות הבאות כדי להתמקד בערך ובסך עלות הבעלות.
שימוש בטכניקות ובכלים ספציפיים למוצרים לאופטימיזציה של משאבים
כדאי להשתמש בתכונות ובכלים לאופטימיזציה של עלויות שזמינים במוצרים של Google Cloud, כמו:
- Compute Engine: Autoscaling, custom machine types, and Spot VMs
- GKE: Cluster autoscaler and הקצאת צמתים אוטומטית (NAP)
- Cloud Storage: ניהול מחזור חיים של אובייקטים וסיווג אוטומטי
- BigQuery: תמחור לפי קיבולת וטכניקות לייעול עלויות
- Google Cloud VMware Engine: הנחות תמורת התחייבות לשימוש (CUD), אופטימיזציה של נפח אחסון ואסטרטגיות נוספות לאופטימיזציה של עלויות
ליהנות מהנחות
כדי לוודא ששיעור החיוב על המשאבים ב-Cloud יהיה נמוך ככל האפשר, כדאי להשתמש בהנחות ש-Google מציעה. בדרך כלל צוותי המוצר וההנדסה הנפרדים מנהלים את אופטימיזציית המשאבים. הצוות המרכזי של FinOps אחראי לאופטימיזציה של תעריפי החיוב, כי יש לו גישה לנתונים על דרישות המשאבים בכל הארגון. לכן, הם יכולים לצבור את הדרישות ולמקסם את ההנחות שמבוססות על התחייבות.
אפשר ליהנות מההנחות הבאות על משאביGoogle Cloud :
- הנחות לארגונים הן הנחות שנקבעות במשא ומתן על סמך התחייבות הארגון להוצאה מינימלית כוללת על Google Cloud בתעריף חיוב מופחת.
- הנחות CUD לשימוש במשאבים ניתנות בתמורה להתחייבות להשתמש בכמות מינימלית של משאבי Compute Engine במשך שנה או שלוש שנים. הנחות תמורת התחייבות לשימוש במשאבים חלות על משאבים שנמצאים בפרויקט ובאזור ספציפיים. כדי לשתף הנחות CUD בין כמה פרויקטים, אפשר להפעיל את שיתוף ההנחות.
- הנחות תמורת התחייבות להוצאה ניתנות בתמורה להתחייבות להוציא סכום מינימלי על מוצר מסוים במשך שנה או שלוש שנים. הנחות על סמך הוצאות חלות ברמת החשבון לחיוב. ההנחות חלות באופן אזורי או גלובלי, בהתאם למוצר.
אתם יכולים לחסוך משמעותית בעלויות באמצעות הנחות תמורת התחייבות לשימוש (CUD) בנוסף להנחות לארגונים.
בנוסף ל-CUD, אפשר להשתמש בגישות הבאות כדי להפחית את תעריפי החיוב:
- כדאי להשתמש ב-Spot VMs לעומסי עבודה (workloads) עמידים בכשלים וגמישים. העלות של מכונות Spot VM נמוכה ביותר מ-80% מזו של מכונות רגילות.
- ב-BigQuery יש כמה מודלים לתמחור, כולל תמחור לפי דרישה ותמחור לפי מהדורה שמבוסס על התחייבויות ודרישות של התאמה אוטומטית לעומס. אם אתם משתמשים בכמות גדולה של משאבי BigQuery, כדאי לבחור במהדורה מתאימה כדי להקטין את העלות לכל משבצת זמן של עומסי עבודה של ניתוח נתונים.
- חשוב לבדוק בקפידה את האזורים הזמינים לשירותים שבהם אתם רוצים להשתמש. Google Cloud בוחרים אזורים שתואמים ליעדי העלות ולגורמים כמו זמן אחזור ודרישות תאימות. כדי להבין את האיזון בין עלות, קיימות וזמן אחזור, אפשר להשתמש בGoogle Cloud Region Picker.