Well-Architected Framework: עקרון הוזלת העלויות

Last reviewed 2025-02-14 UTC

בקטע בנושא הוזלת העלויות ב-Google Cloud Well-Architected Framework מפורטים עקרונות והמלצות לאופטימיזציה של עלויות עומסי העבודה ב- Google Cloud.

הקהל המיועד כולל את האנשים הבאים:

  • מנהלי טכנולוגיה (CTO), מנהלי מידע (CIO), מנהלי כספים (CFO) ומנהלים אחרים שאחראים על ניהול אסטרטגי של עלויות.
  • ארכיטקטים, מפתחים, אדמינים ואנשי תפעול שמקבלים החלטות שמשפיעות על העלויות בכל השלבים של המעבר של הארגון לענן.

יש הבדלים משמעותיים בין מודלים של עלויות עבור עומסי עבודה מקומיים ועומסי עבודה בענן. עלויות ה-IT המקומיות כוללות הוצאות הוניות (CapEx) והוצאות תפעוליות (OpEx). נכסי חומרה ותוכנה מקומיים נרכשים, ועלויות הרכישה מפוחתות במהלך חיי התפעול של הנכסים. בענן, העלויות של רוב משאבי הענן נחשבות כהוצאות תפעוליות, והן מצטברות כשמשתמשים במשאבי הענן. ההבדל הבסיסי הזה מדגיש את החשיבות של העקרונות הבסיסיים הבאים לאופטימיזציה של העלויות.

עקרונות והמלצות לאופטימיזציה של עלויות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Cost optimization ב-Well-Architected Framework.

עקרונות ליבה

ההמלצות בעמודה של הוזלת העלויות ב-Well-Architected Framework ממופות לעקרונות הליבה הבאים:

  • התאמת ההוצאות בענן לערך העסקי: כדי לוודא שהמשאבים בענן מספקים ערך עסקי מדיד, צריך להתאים את ההוצאות על IT ליעדים העסקיים.
  • טיפוח תרבות של מודעות לעלויות: חשוב לוודא שאנשים בארגון לוקחים בחשבון את ההשפעה של ההחלטות והפעילויות שלהם על העלויות, ושיש להם גישה למידע על העלויות שנדרש להם כדי לקבל החלטות מושכלות.
  • אופטימיזציה של השימוש במשאבים: הקצאת משאבים רק לפי הצורך, ותשלום רק על המשאבים שצורכים.
  • אופטימיזציה מתמשכת: מעקב מתמשך אחרי השימוש במשאבי הענן והעלויות, וביצוע שינויים באופן יזום לפי הצורך כדי לייעל את ההוצאות. הגישה הזו כוללת זיהוי של חוסר יעילות פוטנציאלי בעלויות וטיפול בו לפני שהוא הופך לבעיה משמעותית.

העקרונות האלה תואמים מאוד לעקרונות הבסיסיים של FinOps בענן. השיטה הזו רלוונטית לכל ארגון, בלי קשר לגודל שלו או לרמת הבשלות שלו בשימוש בענן. אם תאמצו את העקרונות האלה ותפעלו לפי ההמלצות שקשורות אליהם, תוכלו לשלוט בעלויות ולבצע אופטימיזציה שלהן לאורך כל הדרך בענן.

שותפים ביצירת התוכן

מחבר: Nicolas Pintaux | Customer Engineer, Application Modernization Specialist

תורמי תוכן אחרים:

התאמה בין ההוצאות בענן לבין הערך העסקי

העיקרון הזה, שמופיע בקטגוריה 'אופטימיזציה של עלויות' בGoogle Cloud מסגרת Well-Architected Framework, מספק המלצות להתאמת השימוש במשאבי Google Cloud למטרות העסקיות של הארגון.

סקירה כללית של העקרונות

כדי לנהל את עלויות הענן בצורה יעילה, צריך למקסם את הערך העסקי שמשאבי הענן מספקים ולמזער את העלות הכוללת של הבעלות (TCO). כשבודקים את אפשרויות המשאבים לעומסי העבודה בענן, צריך לקחת בחשבון לא רק את העלות של הקצאת המשאבים והשימוש בהם, אלא גם את העלות של ניהול המשאבים. לדוגמה, מכונות וירטואליות (VM) ב-Compute Engine יכולות להיות אפשרות חסכונית לאירוח אפליקציות. עם זאת, כשמביאים בחשבון את התקורה של תחזוקה, תיקון והרחבה של המכונות הווירטואליות, העלות הכוללת של הבעלות יכולה לעלות. מצד שני, שירותים ללא שרתים כמו Cloud Run יכולים להציע ערך עסקי גבוה יותר. התקורה התפעולית הנמוכה מאפשרת לצוות להתמקד בפעילויות הליבה ועוזרת להגדיל את הגמישות.

כדי לוודא שהשימוש במשאבי הענן יניב את הערך האופטימלי, חשוב להעריך את הגורמים הבאים:

  • עלויות הקצאה ושימוש: ההוצאות שנוצרות כשרוכשים, מקצים או משתמשים במשאבים.
  • עלויות ניהול: ההוצאות החוזרות על הפעלה ותחזוקה של משאבים, כולל משימות כמו תיקון, מעקב ושינוי גודל.
  • עלויות עקיפות: העלויות שאתם עשויים לשלם כדי לנהל בעיות כמו זמן השבתה, אובדן נתונים או פרצות אבטחה.
  • השפעה על העסק: היתרונות הפוטנציאליים מהמשאבים, כמו הגדלת ההכנסות, שיפור שביעות רצון הלקוחות וקיצור זמן יציאה לשוק.

התאמה בין ההוצאות בענן לערך העסקי מאפשרת לכם ליהנות מהיתרונות הבאים:

  • החלטות שמבוססות על ערך: הצוותים שלכם מקבלים תמריץ לתעדף פתרונות שמניבים את הערך העסקי הגבוה ביותר, ולשקול את ההשלכות של העלויות בטווח הקצר ובטווח הארוך.
  • בחירת משאבים מושכלת: לצוותים שלכם יש את המידע והידע שהם צריכים כדי להעריך את הערך העסקי ואת העלות הכוללת של הבעלות (TCO) של אפשרויות פריסה שונות, וכך הם יכולים לבחור משאבים שמשתלמים מבחינת עלות.
  • התאמה בין צוותים: שיתוף פעולה חוצה-תפקידים בין צוותים עסקיים, פיננסיים וטכניים מבטיח שההחלטות לגבי הענן יתאימו ליעדים הכוללים של הארגון.

המלצות

כדי להתאים את ההוצאות על הענן ליעדים העסקיים, כדאי להביא בחשבון את ההמלצות הבאות.

מתן עדיפות למוצרים מנוהלים ולמוצרים ללא שרת

כדי לצמצם את התקורה התפעולית ואת עלויות התחזוקה, מומלץ לבחור בשירותים מנוהלים ובמוצרים ללא שרתים כשזה אפשרי. האפשרות הזו מאפשרת לצוותים שלכם להתמקד בפעילויות העסקיות העיקריות שלהם. הן יכולות להאיץ את ההשקה של תכונות ופונקציות חדשות, ולעזור לכם לקדם חדשנות וערך.

הנה כמה דוגמאות לאופן שבו אפשר ליישם את ההמלצה הזו:

איזון בין עלות-תועלת לבין גמישות עסקית

שליטה בעלויות ואופטימיזציה של ניצול המשאבים הם יעדים חשובים. עם זאת, צריך לאזן בין היעדים האלה לבין הצורך בתשתית גמישה שתאפשר לכם לחדש במהירות, להגיב במהירות לשינויים ולספק ערך מהר יותר. הנה כמה דוגמאות לאופן שבו אפשר להשיג את האיזון הזה:

  • שימוש במדדי DORA כדי לשפר את הביצועים של הכנת תוכנה להפצה. מדדים כמו שיעור הכשלים בשינויים (CFR), זמן הזיהוי (TTD) וזמן השחזור (TTR) יכולים לעזור לכם לזהות ולתקן צווארי בקבוק בתהליכי הפיתוח והפריסה. הפחתת זמן ההשבתה והאצת המסירה מאפשרות לכם להשיג יעילות תפעולית וגמישות עסקית.
  • כדי לשפר את האמינות התפעולית, כדאי לפעול לפי שיטות העבודה המומלצות של הנדסת אמינות אתרים (SRE). המיקוד של SRE באוטומציה, ביכולת התבוננות ובמענה לאירועים יכול להוביל לצמצום זמן ההשבתה, לקיצור זמן השחזור ולשיפור שביעות רצון הלקוחות. צמצום זמן ההשבתה ושיפור האמינות התפעולית יכולים למנוע אובדן הכנסות ולבטל את הצורך בהקצאת יתר של משאבים כרשת ביטחון לטיפול בהפסקות שירות.

הפעלת אופטימיזציה בשירות עצמי

כדי לעודד תרבות של ניסויים וחיפוש, כדאי לספק לצוותים שלכם כלים לאופטימיזציה של עלויות בשירות עצמי, כלים למעקב אחר נתונים ופלטפורמות לניהול משאבים. הם יכולים להקצות, לנהל ולייעל את משאבי הענן באופן אוטונומי. הגישה הזו עוזרת לטפח תחושת בעלות, להאיץ את החדשנות ולהבטיח שהצוותים יוכלו להגיב במהירות לצרכים משתנים תוך שמירה על יעילות מבחינת עלויות.

אימוץ והטמעה של FinOps

כדאי לאמץ את גישת ה-FinOps כדי ליצור סביבה שיתופית שבה כל אחד יכול לקבל החלטות מושכלות שמאזנות בין עלות לערך. ‫FinOps מעודד אחריות פיננסית ומקדם אופטימיזציה יעילה של עלויות בענן.

קידום חשיבה שמבוססת על ערך ועל עלות כוללת של בעלות (TCO)

חשוב לעודד את חברי הצוות לאמץ גישה הוליסטית להוצאות על ענן, עם דגש על עלות כוללת ולא רק על עלויות ראשוניות. אפשר להשתמש בטכניקות כמו מיפוי זרם ערך כדי להמחיש ולנתח את זרימת הערך בתהליך אספקת התוכנה, וכדי לזהות תחומים לשיפור. כדאי להטמיע תמחור ליחידה באפליקציות ובשירותים כדי להבין את הגורמים לעלויות ברמת פירוט גבוהה ולזהות הזדמנויות לאופטימיזציה של העלויות. מידע נוסף זמין במאמר הגדלת הערך העסקי באמצעות FinOps בענן.

טיפוח תרבות של מודעות לעלויות

העיקרון הזה הוא חלק מעמודת האופטימיזציה של העלויות ב-Google Cloud Well-Architected Framework. הוא כולל המלצות לקידום המודעות לעלויות בארגון, ולוודא שלחברי הצוות יש את נתוני העלויות שהם צריכים כדי לקבל החלטות מושכלות.

בדרך כלל, האחריות לניהול העלויות מרוכזת אצל כמה בעלי עניין נבחרים, והיא מתמקדת בעיקר בהחלטות לגבי הארכיטקטורה הראשונית של הפרויקט. עם זאת, חברי צוות בכל תפקידי המשתמש בענן (אנליסט, ארכיטקט, מפתח או אדמין) יכולים לעזור להפחית את עלות המשאבים ב-Google Cloud. שיתוף נתוני העלויות בצורה מתאימה מאפשר לחברי הצוות לקבל החלטות חסכוניות לאורך תהליכי הפיתוח והפריסה.

סקירה כללית של העקרונות

בעלי עניין בתפקידים שונים – בעלי מוצרים, מפתחים, מהנדסי פריסה, אדמינים ואנליסטים פיננסיים – צריכים לראות את נתוני העלויות הרלוונטיים ואת הקשר שלהם לערך העסקי. כשמקצים משאבים בענן ומנהלים אותם, צריך לספק את הנתונים הבאים:

  • ‫Projected resource costs: אומדני עלויות בזמן התכנון והפריסה.
  • עלויות שימוש במשאבים בזמן אמת: נתוני עלויות עדכניים שאפשר להשתמש בהם למעקב שוטף ולאימות התקציב.
  • עלויות שממופות למדדים עסקיים: תובנות לגבי ההשפעה של ההוצאות בענן על מדדי ביצועים מרכזיים (KPI), כדי לאפשר לצוותים לזהות אסטרטגיות חסכוניות.

לא כל אחד צריך גישה לנתוני עלות גולמיים. עם זאת, חשוב לקדם את המודעות לעלויות בכל התפקידים, כי החלטות של אנשים פרטיים יכולות להשפיע על העלויות.

קידום השקיפות בנוגע לעלויות והקפדה על בעלות ברורה על שיטות לניהול עלויות מבטיחים שכולם מודעים להשלכות הפיננסיות של הבחירות שלהם וכולם תורמים באופן פעיל ליעדים של הארגון בנוגע לאופטימיזציה של העלויות. בין אם באמצעות צוות FinOps מרכזי או מודל מבוזר, חשוב להגדיר אחריות כדי להשיג אופטימיזציה יעילה של העלויות.

המלצות

כדי להעלות את המודעות לעלויות ולוודא שחברי הצוות שלכם מקבלים את פרטי העלויות שהם צריכים כדי לקבל החלטות מושכלות, כדאי לפעול לפי ההמלצות הבאות.

הצגת נראות של העלויות ברמת הארגון

כדי לקבל תמונה מלאה של העלויות בארגון, הצוותים שאחראים על ניהול העלויות יכולים לבצע את הפעולות הבאות:

  • סטנדרטיזציה של חישוב העלויות והתקציב: חשוב להשתמש בשיטה עקבית כדי לקבוע את העלויות המלאות של משאבי הענן, אחרי שמביאים בחשבון הנחות ועלויות משותפות. כדאי ליצור תהליכי תקצוב ברורים וסטנדרטיים שתואמים ליעדים של הארגון ומאפשרים ניהול עלויות פרואקטיבי.
  • שימוש בכלים סטנדרטיים לניהול עלויות ולשקיפות: שימוש בכלים מתאימים שמספקים תובנות בזמן אמת לגבי ההוצאות ב-Cloud ומפיקים תמונות מצב של התקדמות העלויות באופן קבוע (לדוגמה, שבועי). הכלים האלה מאפשרים לכם לתכנן את התקציב, ליצור תחזיות ולזהות הזדמנויות לאופטימיזציה באופן יזום. הכלים יכולים להיות כלים של ספק שירותי ענן (כמו לוח הבקרה לחיוב ב-Cloud ב-Google Cloud), פתרונות של צד שלישי או פתרונות קוד פתוח כמו פתרון שיוך העלויות.
  • הטמעת מערכת להקצאת עלויות: הקצאת חלק מהתקציב הכולל ל-Cloud לכל צוות או פרויקט. הקצאה כזו נותנת לצוותים תחושת בעלות על ההוצאות ב-Cloud ומעודדת אותם לקבל החלטות חסכוניות במסגרת התקציב שהוקצה להם.
  • קידום שקיפות: כדאי לעודד את הצוותים לדון בהשלכות של העלויות במהלך תהליכי התכנון וקבלת ההחלטות. ליצור סביבה בטוחה ותומכת לשיתוף רעיונות וחששות שקשורים לאופטימיזציה של העלויות. חלק מהארגונים משתמשים במנגנוני חיזוק חיובי כמו טבלאות מובילים או תוכניות הכרה. אם בארגון שלכם יש הגבלות על שיתוף נתוני עלויות גולמיים בגלל שיקולים עסקיים, כדאי לבדוק גישות חלופיות לשיתוף מידע ותובנות לגבי עלויות. לדוגמה, כדאי לשתף מדדים מצטברים (כמו העלות הכוללת של סביבה או תכונה) או מדדים יחסיים (כמו העלות הממוצעת לכל עסקה או משתמש).

הסבר על החיוב של משאבי ענן

התמחור של Google Cloud המשאבים עשוי להשתנות בין אזורים. Google Cloud יש משאבים שמחויבים מדי חודש במחיר קבוע, ויש משאבים שמחויבים לפי השימוש. Google Cloud כדי להבין איך מחויבים המשאבים, אפשר להשתמש בGoogle Cloud מחשבון התמחור ובמידע על התמחור של מוצרים ספציפיים (לדוגמה, התמחור של Google Kubernetes Engine‏ (GKE)).

הסבר על אפשרויות לאופטימיזציה של עלויות לפי משאבים

לכל סוג של משאב בענן שאתם מתכננים להשתמש בו, כדאי לבדוק אסטרטגיות לאופטימיזציה של השימוש והיעילות. האסטרטגיות כוללות התאמת גודל, התאמה אוטומטית לעומס ואימוץ טכנולוגיות בלי שרת במקרים המתאימים. בהמשך מופיעות דוגמאות לאפשרויות של אופטימיזציה של עלויות עבור כמה Google Cloud מוצרים:

הסבר על אפשרויות לאופטימיזציה של עלויות שמבוססות על הנחות

מומלץ לעיין בתוכניות ההנחות ש- Google Cloud מציעה, כמו הדוגמאות הבאות:

  • הנחות תמורת התחייבות לשימוש (CUD): הנחות CUD מתאימות למשאבים עם שימוש צפוי ויציב. הנחות תמורת התחייבות לשימוש (CUD) מאפשרות לכם לקבל הנחות משמעותיות במחיר בתמורה להתחייבות לשימוש במשאבים ספציפיים במשך תקופה מסוימת (בדרך כלל שנה עד שלוש שנים). אפשר גם להשתמש בחידוש אוטומטי של הנחות על שימוש מתמשך כדי להימנע מרכישה ידנית של התחייבויות כשהן יפוגו.
  • ‫Sustained use discounts: במוצרים מסוימים של Google Cloud, כמו Compute Engine ו-GKE, אפשר לקבל קרדיטים של הנחות אוטומטיות אחרי שימוש רציף במשאבים מעבר לסף משך זמן ספציפי. Google Cloud
  • מכונות וירטואליות מסוג Spot: מכונות וירטואליות מסוג Spot יכולות לעזור לכם להפחית את העלויות של Compute Engine עבור עומסי עבודה גמישים ועמידים בפני תקלות. העלות של מכונות Spot VM נמוכה משמעותית מזו של מכונות וירטואליות רגילות. עם זאת, יכול להיות ש-Compute Engine יפסיק או ימחק מכונות וירטואליות מסוג Spot באופן יזום כדי לפנות קיבולת. מכונות וירטואליות מסוג Spot מתאימות למשימות באצווה שיכולות לעמוד בדרישות של קדימות (preemption) ואין להן דרישות זמינות גבוהות.
  • הנחות על אפשרויות מוצר ספציפיות: חלק מהשירותים המנוהלים, כמו BigQuery, מציעים הנחות כשרוכשים קיבולת ייעודית או קיבולת של עיבוד שאילתות עם שינוי גודל אוטומטי.

כדאי להעריך ולבחור את אפשרויות ההנחות שמתאימות למאפיינים של עומס העבודה ולדפוסי השימוש שלכם.

שילוב אומדני עלויות בתוכניות ארכיטקטורה

מומלץ לעודד צוותים לפתח תוכניות אדריכלות שכוללות הערכות עלויות לאפשרויות פריסה ותצורות שונות. השיטה הזו מאפשרת לצוותים להשוות עלויות באופן יזום ולקבל החלטות מושכלות שתואמות ליעדים הטכניים והפיננסיים.

שימוש בערכה עקבית וסטנדרטית של תוויות לכל המשאבים

אתם יכולים להשתמש בתוויות כדי לעקוב אחרי עלויות, לזהות משאבים ולסווג אותם. באופן ספציפי, אתם יכולים להשתמש בתוויות כדי להקצות עלויות לפרויקטים, למחלקות או למרכזי עלויות שונים. הגדרה של מדיניות רשמית לשימוש בתוויות שתואמת לצרכים של בעלי העניין העיקריים בארגון עוזרת להפוך את העלויות לגלויות יותר. אתם יכולים גם להשתמש בתוויות כדי לסנן את נתוני העלויות והשימוש במשאבים לפי קהל היעד.

משתמשים בכלי אוטומציה כמו Terraform כדי לאכוף את התיוג של כל משאב שנוצר. כדי לשפר עוד יותר את השקיפות של העלויות ואת הייחוס שלהן, אפשר להשתמש בכלים שמסופקים על ידי פתרון הייחוס של עלויות בקוד פתוח.

שיתוף דוחות עלויות עם חברי צוות

שיתוף דוחות עלויות עם חברי הצוות מאפשר להם לקחת אחריות על ההוצאות שלהם ב-Cloud. השיטה הזו מאפשרת לקבל החלטות חסכוניות, לבצע אופטימיזציה מתמשכת של העלויות ולשפר באופן שיטתי את מודל הקצאת העלויות.

יש כמה סוגים של דוחות עלויות, כולל:

  • דוחות עלויות תקופתיים: דוחות קבועים שמספקים לצוותים מידע על ההוצאות הנוכחיות שלהם בענן. בדרך כלל, הדוחות האלה הם גיליונות אלקטרוניים מיוצאים. שיטות יעילות יותר כוללות אימיילים אוטומטיים ולוחות בקרה ייעודיים. כדי להבטיח שדוחות העלויות יספקו מידע רלוונטי ופרקטי בלי להעמיס על הנמענים פרטים מיותרים, צריך להתאים את הדוחות לקהלי היעד. הגדרת דוחות מותאמים היא שלב בסיסי לקבלת נראות וניהול של עלויות בזמן אמת ובאופן אינטראקטיבי.
  • התראות אוטומטיות: אתם יכולים להגדיר דוחות עלויות כדי לשלוח התראות יזומות לבעלי עניין רלוונטיים (למשל, באימייל או בצ'אט) לגבי חריגות בעלויות, ערכי סף של תקציבים או הזדמנויות לאופטימיזציה של עלויות. ההתראות האוטומטיות מספקות מידע בזמן אמת ישירות לאנשים שיכולים לפעול בעקבותיו, ומעודדות אותם לפעול במהירות ולנקוט גישה יזומה לאופטימיזציה של עלויות.
  • Google Cloud לוחות בקרה: אתם יכולים להשתמש בלוחות הבקרה המובנים לחיוב ב- Google Cloud כדי לקבל תובנות לגבי פירוט העלויות ולזהות הזדמנויות לאופטימיזציה של העלויות. Google Cloud מספק גם את FinOps Hub, שעוזר לכם לעקוב אחרי החיסכון ולקבל המלצות לאופטימיזציה של העלויות. מנוע AI מפעיל את FinOps Hub כדי להמליץ על הזדמנויות לאופטימיזציה של העלויות של כל המשאבים שכרגע בפריסה. כדי לשלוט בגישה להמלצות האלה, אתם יכולים להטמיע בקרת גישה מבוססת-תפקידים (RBAC).
  • מרכזי בקרה בהתאמה אישית: אפשר ליצור מרכזי בקרה בהתאמה אישית על ידי ייצוא נתוני עלויות למסד נתונים של ניתוח נתונים, כמו BigQuery. אפשר להשתמש בכלי להמחשה כמו Data Studio כדי להתחבר למסד הנתונים של ניתוח הנתונים, ליצור דוחות אינטראקטיביים ולאפשר בקרת גישה מפורטת באמצעות הרשאות מבוססות-תפקידים.
  • דוחות עלויות של כמה עננים: אם אתם משתמשים בכמה עננים, אתם צריכים תצוגה מאוחדת של העלויות בכל ספקי הענן כדי לבצע ניתוח מקיף, להגדיר תקציב ולבצע אופטימיזציה. אתם יכולים להשתמש בכלים כמו BigQuery כדי לרכז ולנתח נתוני עלויות מכמה ספקי ענן, ולהשתמש ב-Data Studio כדי ליצור דוחות אינטראקטיביים ספציפיים לצוות.

אופטימיזציה של השימוש במשאבים

העיקרון הזה הוא חלק מעמודת האופטימיזציה של העלויות בGoogle Cloud Well-Architected Framework, והוא כולל המלצות שיעזרו לכם לתכנן ולספק משאבים בהתאם לדרישות ולדפוסי הצריכה של עומסי העבודה בענן.

סקירה כללית של העקרונות

כדי לבצע אופטימיזציה של עלות משאבי הענן, צריך להבין היטב את דרישות המשאבים של עומסי העבודה ואת דפוסי הטעינה. ההבנה הזו היא הבסיס למודל עלויות מוגדר היטב, שמאפשר לכם לחזות את עלות הבעלות הכוללת (TCO) ולזהות את הגורמים לשינוי בעלויות לאורך תהליך המעבר לענן. ניתוח וחיזוי יזומים של ההוצאות על הענן מאפשרים לכם לקבל החלטות מושכלות לגבי הקצאת משאבים, ניצול משאבים ואופטימיזציה של העלויות. הגישה הזו מאפשרת לכם לשלוט בהוצאות על הענן, להימנע מהקצאת יתר ולוודא שמשאבי הענן מותאמים לצרכים הדינמיים של עומסי העבודה והסביבות שלכם.

המלצות

כדי לבצע אופטימיזציה יעילה של השימוש במשאבי הענן, כדאי להביא בחשבון את ההמלצות הבאות.

בחירת משאבים ספציפיים לסביבה

לכל סביבת פריסה יש דרישות שונות לגבי זמינות, מהימנות ומדרגיות. לדוגמה, יכול להיות שמפתחים יעדיפו סביבה שמאפשרת להם לפרוס ולהפעיל במהירות אפליקציות לפרקי זמן קצרים, אבל לא יזדקקו לזמינות גבוהה. מצד שני, בסביבת ייצור נדרשת בדרך כלל זמינות גבוהה. כדי למקסם את השימוש במשאבים, צריך להגדיר דרישות ספציפיות לסביבה על סמך הצרכים העסקיים. בטבלה הבאה מפורטות דוגמאות לדרישות ספציפיות לסביבה.

סביבה דרישות
ייצור
  • זמינות גבוהה
  • ביצועים צפויים
  • יציבות תפעולית
  • אבטחה עם משאבים חזקים
פיתוח ובדיקה
  • עלות-תועלת
  • תשתית גמישה עם קיבולת משתנה
  • תשתית זמנית כשאין צורך בשימור נתונים
סביבות אחרות (כמו סביבת פיתוח וסביבת בדיקה)
  • הקצאת משאבים מותאמת אישית על סמך דרישות ספציפיות לסביבה

בחירת משאבים ספציפיים לעומס העבודה

יכול להיות שלכל אחד מעומסי העבודה בענן יהיו דרישות שונות לגבי זמינות, מדרגיות, אבטחה וביצועים. כדי לייעל את העלויות, צריך להתאים את בחירת המשאבים לדרישות הספציפיות של כל עומס עבודה. לדוגמה, יכול להיות שאפליקציה בלי שמירת מצב לא תדרוש את אותה רמה של זמינות או אמינות כמו קצה עורפי עם שמירת מצב. בטבלה הבאה מפורטות דוגמאות נוספות לדרישות ספציפיות לעומס עבודה.

סוג עומס העבודה דרישות לגבי עומסי עבודה אפשרויות משאבים
קריטי לפעילות העסקית זמינות רציפה, אבטחה חזקה וביצועים גבוהים משאבי פרימיום ושירותים מנוהלים כמו Spanner, לזמינות גבוהה ועקביות גלובלית של נתונים.
לא קריטיות תשתית חסכונית וניתנת להתאמה לעומס (autoscaling) משאבים עם תכונות בסיסיות ומשאבים זמניים כמו מכונות וירטואליות מסוג Spot.
מבוסס-אירועים התאמה דינמית של קנה המידה על סמך הביקוש הנוכחי לקיבולת ולביצועים שירותים בלי שרת (serverless) כמו Cloud Run ופונקציות Cloud Run.
עומסי עבודה ניסיוניים סביבה גמישה וזולה לפיתוח מהיר, חזרה על תהליך העבודה, בדיקות וחדשנות משאבים עם תכונות בסיסיות, משאבים זמניים כמו מכונות וירטואליות מסוג Spot וסביבות ארגז חול עם מגבלות הוצאות מוגדרות.

אחד היתרונות של הענן הוא האפשרות לנצל את כוח המחשוב המתאים ביותר לעומס עבודה נתון. חלק מעומסי העבודה מפותחים כדי לנצל את ערכות ההוראות של המעבד, וחלק אחר לא מתוכנן בצורה כזו. כדאי להשוות בין עומסי העבודה ולנתח אותם בהתאם. סיווג עומסי העבודה ובחירת משאבים ספציפיים לעומס העבודה (לדוגמה, בחירת משפחות מכונות מתאימות למכונות וירטואליות ב-Compute Engine). השיטה הזו עוזרת לייעל את העלויות, לאפשר חדשנות ולשמור על רמת הזמינות והביצועים שנדרשת לעומסי העבודה.

הנה כמה דוגמאות לאופן שבו אפשר ליישם את ההמלצה הזו:

  • לעומסי עבודה קריטיים שמשרתים משתמשים שמפוזרים ברחבי העולם, כדאי להשתמש ב-Spanner. ‏Spanner מבטל את הצורך בפריסות מסד נתונים מורכבות, כי הוא מבטיח את המהימנות והעקביות של הנתונים בכל האזורים.
  • עבור עומסי עבודה עם רמות עומס משתנות, כדאי להשתמש בהתאמת קנה מידה אוטומטית כדי שלא תצטרכו לשלם כשהעומס נמוך, ועדיין לשמור על קיבולת מספקת שתעמוד בעומס הנוכחי. אפשר להגדיר שינוי גודל אוטומטי עבור הרבהGoogle Cloud שירותים, כולל מכונות וירטואליות ב-Compute Engine, אשכולות Google Kubernetes Engine‏ (GKE) ו-Cloud Run. כשמגדירים התאמה אוטומטית לעומס, אפשר להגדיר מגבלות על התאמה לעומס כדי לוודא שהעלויות לא יחרגו מהתקציבים שצוינו.

בחירת אזורים על סמך דרישות העלות

כדי להבין את ההבדלים בין העלויות, הקיימות, זמני האחזור וגורמים אחרים, אפשר להשתמש בGoogle Cloud Region Picker. Google Cloud

שימוש באפשרויות מובנות לאופטימיזציה של עלויות

‫Google Cloud products מספקים תכונות מובנות שיעזרו לכם לייעל את השימוש במשאבים ולשלוט בעלויות. בטבלה הבאה מפורטות דוגמאות לתכונות של אופטימיזציה של עלויות שבהן תוכלו להשתמש בחלק ממוצרי Google Cloud :

Product התכונה 'אופטימיזציה של עלויות'
Compute Engine
  • הוספה אוטומטית של מכונות וירטואליות או הסרה שלהן בהתבסס על העומס הנוכחי באמצעות שינוי גודל אוטומטי.
  • כדי להימנע מהקצאת יתר של משאבים, כדאי ליצור סוגי מכונות בהתאמה אישית ולהשתמש בהם
    • שמתאימים לדרישות של עומס העבודה.
  • כדי להפחית את העלויות של עומסי עבודה לא קריטיים או עמידים בכשלים, כדאי להשתמש במכונות Spot.
  • בסביבות פיתוח, אפשר להפחית את העלויות על ידי הגבלת זמן הריצה של מכונות וירטואליות, או על ידי השהיה או הפסקה של מכונות וירטואליות כשלא צריך אותן.
GKE
  • אפשר להתאים אוטומטית את הגודל של אשכולות GKE בהתאם לעומס הנוכחי באמצעות Cluster Autoscaler.
  • כדי ליצור ולנהל מאגרי צמתים באופן אוטומטי על סמך דרישות עומס העבודה, וכדי להבטיח ניצול אופטימלי של המשאבים, אפשר להשתמש ב הקצאה אוטומטית של צמתים.
Cloud Storage
  • מעבר אוטומטי של נתונים לסוגי אחסון (storage class) בעלות נמוכה יותר על סמך גיל הנתונים או דפוסי הגישה באמצעות ניהול מחזור החיים של אובייקטים.
  • אפשר להשתמש בסיווג אוטומטי כדי להעביר נתונים באופן דינמי לסוג האחסון הכי חסכוני בהתבסס על דפוסי השימוש.
BigQuery
  • כדי לצמצם את עלויות העיבוד של שאילתות בעומסי עבודה במצב יציב, אפשר להשתמש בתמחור לפי קיבולת.
  • אפשר לשפר את ביצועי השאילתות ולהוזיל את העלויות באמצעות טכניקות של חלוקה למחיצות (partitioning) וקיבוץ לאשכולות (clustering).
Google Cloud VMware Engine
  • כדי לצמצם את העלויות של VMware, אפשר להשתמש בשיטות לאופטימיזציה של עלויות כמו הנחות תמורת התחייבות לשימוש (CUD), אופטימיזציה של צריכת נפח האחסון והתאמה של גודל אשכולות ESXi.

אופטימיזציה של שיתוף משאבים

כדי למקסם את השימוש במשאבי הענן, אפשר לפרוס כמה אפליקציות או שירותים באותה תשתית, ועדיין לעמוד בדרישות האבטחה ובדרישות אחרות של האפליקציות. לדוגמה, בסביבות פיתוח ובדיקה, אפשר להשתמש באותה תשתית ענן כדי לבדוק את כל הרכיבים של אפליקציה. בסביבת הייצור, אפשר לפרוס כל רכיב על קבוצה נפרדת של משאבים כדי להגביל את היקף ההשפעה במקרה של אירועים.

הנה כמה דוגמאות לאופן שבו אפשר ליישם את ההמלצה הזו:

  • שימוש במכונה אחת של Cloud SQL לכמה סביבות שהן לא סביבות ייצור.
  • אפשר להשתמש בתכונה ניהול צוותים ב-Fleet ב-GKE כדי לאפשר לכמה צוותי פיתוח לשתף אשכול GKE, עם אמצעי בקרה מתאימים לגישה.
  • כדאי להשתמש ב-GKE Autopilot כדי ליהנות מטכניקות לחיסכון בעלויות כמו bin packing והתאמה אוטומטית לעומס (autoscaling), שמוטמעות ב-GKE כברירת מחדל.
  • כדי לחסוך בעלויות של GPU בעומסי עבודה של AI ו-ML, אפשר להשתמש באסטרטגיות לשיתוף GPU כמו GPU מרובה-מופעים, GPU לשיתוף זמן ו-NVIDIA MPS.

פיתוח ותחזוקה של ארכיטקטורות לדוגמה

ליצור ולתחזק מאגר של ארכיטקטורות הפניה שמותאמות לדרישות של סביבות פריסה שונות ולסוגים שונים של עומסי עבודה. כדי לייעל את תהליך התכנון וההטמעה של פרויקטים ספציפיים, צוות כמו מרכז מצוינות בענן (CCoE) יכול לנהל את התוכניות באופן מרכזי. צוותי פרויקטים יכולים לבחור תוכניות מתאימות על סמך קריטריונים מוגדרים בבירור, כדי להבטיח עקביות ארכיטקטונית ואימוץ של שיטות מומלצות. אם יש דרישות ייחודיות לפרויקט, צוות הפרויקט וצוות הארכיטקטורה המרכזי צריכים לשתף פעולה כדי לתכנן ארכיטקטורות הפניה חדשות. אתם יכולים לשתף את הארכיטקטורות המומלצות עם כל הארגון כדי לעודד שיתוף ידע ולהרחיב את מאגר הפתרונות הזמינים. הגישה הזו מבטיחה עקביות, מאיצה את הפיתוח, מפשטת את קבלת ההחלטות ומקדמת ניצול יעיל של המשאבים.

קוראים את הדוגמאות לארכיטקטורות ש-Google מספקת לתרחישי שימוש ולטכנולוגיות שונות. הארכיטקטורות האלה כוללות שיטות מומלצות לבחירה, להגדרה ולפריסה של משאבים, וגם לקביעת הגודל שלהם. השימוש בארכיטקטורות ההפניה האלה מאפשר לכם להאיץ את תהליך הפיתוח ולחסוך בעלויות כבר מההתחלה.

אכיפת משמעת בהוצאות באמצעות מדיניות הארגון

כדאי להשתמש במדיניות הארגון כדי להגביל את המיקומים והמוצרים הזמינים ב- Google Cloud שחברי הצוות יכולים להשתמש בהם. המדיניות הזו עוזרת לוודא שהצוותים משתמשים בפתרונות חסכוניים ומקצים משאבים במיקומים שתואמים ליעדי האופטימיזציה של העלויות.

הערכת תקציבים ריאליים והגדרת גבולות פיננסיים

פיתוח תקציבים מפורטים לכל פרויקט, עומס עבודה וסביבת פריסה. חשוב לוודא שהתקציבים מכסים את כל ההיבטים של פעולות הענן, כולל עלויות התשתית, רישיונות התוכנה, כוח האדם והצמיחה הצפויה. כדי למנוע חריגה מהתקציב ולהבטיח התאמה ליעדים הפיננסיים שלכם, כדאי להגדיר מגבלות או ספי הוצאות ברורים לפרויקטים, לשירותים או למשאבים ספציפיים. כדאי לעקוב באופן קבוע אחרי ההוצאות בענן בהשוואה למגבלות האלה. אתם יכולים להשתמש בהתראות פרואקטיביות לגבי מכסות כדי לזהות מראש חריגות פוטנציאליות בעלויות ולנקוט פעולות מתקנות בזמן.

בנוסף להגדרת תקציבים, אפשר להשתמש במכסות ובמגבלות כדי לאכוף משמעת בהוצאות ולמנוע עליות פתאומיות לא צפויות בהוצאות. אפשר להגדיר מכסות ברמות שונות, כולל פרויקטים, שירותים ואפילו סוגים ספציפיים של משאבים, וכך לשלוט בצריכת המשאבים בצורה מפורטת.

הנה כמה דוגמאות לאופן שבו אפשר ליישם את ההמלצה הזו:

  • מכסות ברמת הפרויקט: הגדרת מגבלות הוצאה או מכסות משאבים ברמת הפרויקט כדי לקבוע גבולות פיננסיים כלליים ולשלוט בצריכת המשאבים בכל השירותים בפרויקט.
  • מכסות ספציפיות לשירות: אפשר להגדיר מכסות לשירותים ספציפיים Google Cloud, כמו Compute Engine או BigQuery, כדי להגביל את מספר המופעים, מעבדי ה-CPU או קיבולת האחסון שאפשר להקצות.
  • מכסות ספציפיות לסוגי משאבים: אפשר להגדיר מכסות לסוגים ספציפיים של משאבים, כמו מכונות וירטואליות של Compute Engine, קטגוריות של Cloud Storage, מכונות של Cloud Run או צמתים של GKE, כדי להגביל את השימוש בהם ולמנוע חריגות לא צפויות בעלויות.
  • התראות לגבי מכסות: קבלת התראות כששימוש במכסה (ברמת הפרויקט) מגיע לאחוז מסוים מהערך המקסימלי.

שימוש במכסות ובמגבלות בשילוב עם תקצוב ומעקב מאפשר ליצור גישה פרואקטיבית ורב-שכבתית לבקרת עלויות. הגישה הזו עוזרת להבטיח שההוצאות על הענן יישארו בגבולות מוגדרים ויתאימו ליעדים העסקיים שלכם. חשוב לזכור שאמצעי בקרת העלויות האלה הם לא קבועים או נוקשים. כדי לוודא שאמצעי בקרת העלויות ימשיכו להתאים לסטנדרטים הנוכחיים בתעשייה וישקפו את הצרכים העסקיים המשתנים שלכם, אתם צריכים לבדוק את אמצעי הבקרה באופן קבוע ולשנות אותם כך שיכללו טכנולוגיות חדשות ושיטות מומלצות.

אופטימיזציה מתמשכת

העיקרון הזה הוא חלק מעמודת האופטימיזציה של העלויות בGoogle Cloud מסגרת Well-Architected Framework. הוא מספק המלצות שיעזרו לכם לבצע אופטימיזציה של העלויות של פריסות הענן על סמך יעדים עסקיים שמשתנים ומתפתחים כל הזמן.

כשהעסק שלכם גדל ומתפתח, עומסי העבודה בענן צריכים להשתנות בהתאם לשינויים בדרישות המשאבים ובדפוסי השימוש. כדי להפיק את הערך המקסימלי מההוצאות על הענן, צריך לשמור על יעילות מבחינת עלויות תוך המשך תמיכה ביעדים העסקיים. לכן נדרש גישה פרואקטיבית וגמישה שמתמקדת בשיפור ובאופטימיזציה מתמשכים.

סקירה כללית של העקרונות

כדי לבצע אופטימיזציה של העלויות באופן שוטף, צריך לעקוב באופן יזום אחרי סביבת הענן ולנתח אותה, ולבצע התאמות מתאימות כדי לעמוד בדרישות הנוכחיות. כדאי להתמקד במדדי ביצועים מרכזיים (KPI) שמשפיעים ישירות על חוויית המשתמשים, תואמים ליעדים העסקיים שלכם ומספקים תובנות לשיפור מתמיד. הגישה הזו מאפשרת לכם לזהות חוסר יעילות ולטפל בו, להתאים את עצמכם לצרכים משתנים ולהתאים באופן רציף את ההוצאות על הענן ליעדים עסקיים אסטרטגיים. כדי לאזן בין יכולת תצפית מקיפה לבין יעילות מבחינת עלויות, חשוב להבין את העלויות והיתרונות של מעקב אחר השימוש במשאבים ולהשתמש באסטרטגיות מתאימות לשיפור התהליך ולאופטימיזציה.

המלצות

כדי לעקוב ביעילות אחרי הסביבה שלכם ב- Google Cloud ולבצע אופטימיזציה של העלויות באופן שוטף, כדאי לפעול לפי ההמלצות הבאות.

התמקדות במדדים שרלוונטיים לעסק

כדי לעקוב אחרי הביצועים בצורה יעילה, צריך קודם לזהות את המדדים שהכי חשובים לעסק וללקוחות שלכם. המדדים האלה כוללים:

  • מדדי חוויית משתמש: מדדי חביון, שיעורי שגיאות, קצב העברת נתונים ומדדי שביעות רצון לקוחות יכולים לעזור לכם להבין את חוויית משתמשי הקצה שלכם בזמן השימוש באפליקציות.
  • מדדים של תוצאות עסקיות: אפשר לקשר בין הכנסות, צמיחה במספר הלקוחות ומעורבות לבין השימוש במשאבים כדי לזהות הזדמנויות לאופטימיזציה של העלויות.
  • מדדי DevOps Research & Assessment‏ (DORA): מדדים כמו תדירות הפריסה, זמן הביצוע לשינויים, שיעור הכשלים בשינויים והזמן לשחזור מספקים תובנות לגבי היעילות והמהימנות של הכנת תוכנה להפצה. שיפור המדדים האלה יכול להגדיל את הפרודוקטיביות, לצמצם את זמן ההשבתה ולבצע אופטימיזציה של העלויות.
  • מדדים של Site Reliability Engineering‏ (SRE): תקציבי שגיאות עוזרים לצוותים לכמת ולנהל את רמת השיבוש המקובלת בשירות. באמצעות הגדרת ציפיות ברורות לגבי מהימנות, תקציבי שגיאות מאפשרים לצוותים לחדש ולפרוס שינויים בביטחון רב יותר, בידיעה שיש להם מרווח ביטחון. הגישה הפרואקטיבית הזו מקדמת איזון בין חדשנות ליציבות, ועוזרת למנוע עלויות תפעול מוגזמות שקשורות להפסקות שירות משמעותיות או להשבתה ממושכת.

שימוש ב-Observability לאופטימיזציה של משאבים

ההמלצות הבאות יעזרו לכם להשתמש ב-Observability כדי לזהות צווארי בקבוק במשאבים ומשאבים שלא מנוצלים מספיק בפריסות בענן:

  • מעקב אחרי ניצול משאבים: אפשר להשתמש במדדים של ניצול משאבים כדי לזהותGoogle Cloud משאבים שלא מנוצלים מספיק. לדוגמה, אפשר להשתמש במדדים כמו ניצול המעבד (CPU) והזיכרון כדי לזהות משאבי מכונות וירטואליות (VM) שלא נמצאים בשימוש. ב-Google Kubernetes Engine ‏ (GKE), אפשר לראות פירוט עלויות ומדדי אופטימיזציה שקשורים לעלויות. ב-Google Cloud VMware Engine, כדאי לבדוק את ניצול המשאבים כדי לבצע אופטימיזציה של הנחות תמורת התחייבות לשימוש (CUD), של צריכת נפח האחסון ושל התאמת הגודל של ESXi.
  • שימוש בהמלצות לענן: Active Assist הוא חבילה של כלים חכמים שעוזרים לכם לשפר את הפעולות בענן. הכלים האלה מספקים המלצות פרקטיות להפחתת עלויות, לשיפור הביצועים והאבטחה ואפילו לקבלת החלטות שמתמקדות בקיימות. לדוגמה, תובנות לגבי התאמת גודל מכונות וירטואליות לצרכים יכולות לעזור לכם לבצע אופטימיזציה של הקצאת משאבים ולהימנע מהוצאות מיותרות.
  • השוואה בין ניצול המשאבים לבין הביצועים: ניתוח הקשר בין ניצול המשאבים לבין ביצועי האפליקציה כדי לקבוע אם אפשר לשדרג למשאבים זולים יותר בלי לפגוע בחוויית המשתמש.

פתרון בעיות שקשורות ליתרה בעלות

נתוני תצפית מפורטים יכולים לעזור באבחון ובפתרון בעיות. עם זאת, אחסון של כמויות מוגזמות של נתוני יכולת צפייה או ייצוא של נתונים מיותרים לכלי ניטור חיצוניים עלולים להוביל לעלויות מיותרות. כדי לפתור בעיות ביעילות, כדאי לפעול לפי ההמלצות הבאות:

  • איסוף מספיק נתונים לפתרון בעיות: חשוב לוודא שפתרון המעקב שלכם מתעד מספיק נתונים כדי לאבחן ולפתור בעיות ביעילות כשהן מתעוררות. הנתונים האלה עשויים לכלול יומנים, עקבות ומדדים ברמות שונות של פירוט.
  • שימוש בדגימה ובצבירה: כדי לאזן בין הצורך בנתונים מפורטים לבין שיקולי עלות, אפשר להשתמש בטכניקות של דגימה וצבירה. הגישה הזו מאפשרת לכם לאסוף נתונים מייצגים בלי לשלם עלויות אחסון מוגזמות.
  • הבנת מודלי התמחור של כלי השירות והניטור: כדאי להעריך פתרונות ניטור שונים ולבחור באפשרויות שתואמות לצרכים הספציפיים של הפרויקט, לתקציב ולדפוסי השימוש. כשבוחרים, כדאי לקחת בחשבון גורמים כמו נפח הנתונים, דרישות שמירת הנתונים והתכונות הנדרשות.
  • בדיקה קבועה של הגדרות המעקב: כדי להימנע מאיסוף נתונים מוגזם, מומלץ להסיר מדדים או יומנים מיותרים.

התאמה אישית של איסוף הנתונים לתפקידים והגדרת מדיניות שמירה ספציפית לתפקידים

כדאי להתחשב בצרכים הספציפיים של נתונים שונים לתפקידים שונים. לדוגמה, מפתחים צריכים בעיקר גישה למעקב ולנתוני יומן ברמת האפליקציה, בעוד שאדמינים ב-IT מתמקדים ביומני מערכת ובמדדי תשתית. התאמה אישית של איסוף הנתונים מאפשרת לכם להפחית את עלויות האחסון המיותרות ולמנוע הצפה של משתמשים במידע לא רלוונטי.

בנוסף, אתם יכולים להגדיר מדיניות שמירה בהתאם לצרכים של כל תפקיד ולדרישות רגולטוריות. לדוגמה, יכול להיות שמפתחים יצטרכו גישה ליומנים מפורטים לתקופה קצרה יותר, בעוד שאנליסטים פיננסיים יצטרכו נתונים לטווח ארוך יותר.

כדאי לקחת בחשבון דרישות רגולטוריות ודרישות תאימות

בתעשיות מסוימות, דרישות רגולטוריות מחייבות שמירת נתונים. כדי להימנע מסיכונים משפטיים ופיננסיים, אתם צריכים לוודא שהשיטות שלכם לניטור ולשמירת נתונים עוזרות לכם לעמוד בדרישות של התקנות הרלוונטיות. במקביל, חשוב לשמור על יעילות מבחינת עלויות. כדאי לשקול את ההמלצות הבאות:

  • צריך לקבוע את הדרישות הספציפיות לשמירת נתונים בתעשייה או באזור שלכם, ולוודא שאסטרטגיית המעקב שלכם עומדת בדרישות האלה.
  • הטמעת מנגנונים מתאימים לארכוב נתונים ולאחזור שלהם כדי לעמוד בדרישות של ביקורת ותאימות, תוך מזעור עלויות האחסון.

הטמעה של התראות חכמות

התראות עוזרות לזהות ולפתור בעיות בזמן. עם זאת, חשוב לשמור על איזון בין גישה שמעדכנת אתכם לבין גישה שגורמת להצפה בהתראות. בעזרת מערכות חכמות להתראות, אפשר לתת עדיפות לבעיות קריטיות שיש להן השפעה גדולה יותר על העסק. כדאי לקחת בחשבון את ההמלצות הבאות:

  • נותנים עדיפות לבעיות שמשפיעות על הלקוחות: כדאי לעצב התראות שמופעלות במהירות במקרים של בעיות שמשפיעות ישירות על חוויית הלקוח, כמו הפסקות באתר, זמני תגובה איטיים או כשלים בעסקאות.
  • התאמה לבעיות זמניות: השתמשו בספים מתאימים ובמנגנוני השהיה כדי להימנע מהתראות מיותרות על בעיות זמניות או על בעיות במערכת שמתקנות את עצמן ולא משפיעות על הלקוחות.
  • התאמה אישית של רמת החומרה של ההתראות: כדי לוודא שהבעיות הדחופות ביותר יקבלו טיפול מיידי, אפשר להבחין בין התראות קריטיות לבין התראות לא קריטיות.
  • שימוש מושכל בערוצי התראות: בוחרים ערוצים מתאימים להתראות (אימייל, SMS או ביפר) בהתאם לרמת החומרה ולדחיפות של ההתראות.