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 בענן. ‫FinOps רלוונטי לכל ארגון, ללא קשר לגודל שלו או לרמת הבשלות שלו ב-Cloud. אם תאמצו את העקרונות האלה ותפעלו לפי ההמלצות שקשורות אליהם, תוכלו לשלוט בעלויות ולבצע אופטימיזציה שלהן לאורך כל הדרך בענן.

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

מחבר: 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) יכולים לעזור לכם לזהות ולתקן צווארי בקבוק בתהליכי הפיתוח והפריסה. הפחתת זמן ההשבתה והאצת המסירה מאפשרות לכם להשיג יעילות תפעולית וגמישות עסקית.
  • כדאי לפעול לפי השיטות המומלצות של Site Reliability Engineering (SRE) כדי לשפר את המהימנות התפעולית. ההתמקדות של SRE באוטומציה, בכושר צפייה ובמענה לאירועים יכולה להוביל לצמצום זמן ההשבתה, לקיצור זמן השחזור ולשיפור שביעות רצון הלקוחות. צמצום זמן ההשבתה ושיפור האמינות התפעולית עוזרים למנוע אובדן הכנסות ולחסוך במשאבים שנדרשים לגיבוי במקרה של הפסקות שירות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המלצות

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

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

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

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

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

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

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

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

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

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

מומלץ לעיין בתוכניות ההנחות ש- 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.
מבוסס-אירועים התאמה דינמית של קנה המידה על סמך הביקוש הנוכחי לקיבולת ולביצועים שירותים ללא שרתים כמו Cloud Run ופונקציות Cloud Run.
עומסי עבודה ניסיוניים סביבה גמישה וזולה לפיתוח מהיר, חזרה על תהליך העבודה, בדיקות וחדשנות משאבים עם תכונות בסיסיות, משאבים זמניים כמו מכונות וירטואליות מסוג Spot וסביבות ארגז חול עם מגבלות הוצאות מוגדרות.

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

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

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

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

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

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

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

Product התכונה 'אופטימיזציה של עלויות'
Compute Engine
  • הוספה אוטומטית של מכונות וירטואליות או הסרה שלהן בהתבסס על העומס הנוכחי באמצעות שינוי גודל אוטומטי.
  • כדי להימנע מהקצאת יתר של משאבים, כדאי ליצור סוגי מכונות בהתאמה אישית ולהשתמש בהם
    • שמתאימים לדרישות של עומס העבודה.
  • כדי להפחית את העלויות של עומסי עבודה לא קריטיים או עמידים בפני תקלות, כדאי להשתמש ב-Spot VMs.
  • בסביבות פיתוח, אפשר להפחית את העלויות על ידי הגבלת זמן הריצה של מכונות וירטואליות, או על ידי השהיה או הפסקה של מכונות וירטואליות כשלא צריך אותן.
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 או ביפר) בהתאם לחומרה ולדחיפות של ההתראות.