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

המלצות

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

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

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

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

  • כדי להריץ מסדי נתונים של שרתים מסוג PostgreSQL,‏ MySQL או Microsoft SQL Server, משתמשים ב-Cloud SQL במקום לפרוס את מסדי הנתונים האלה במכונות וירטואליות.
  • כדי להריץ ולנהל אשכולות Kubernetes, מומלץ להשתמש ב-Google Kubernetes Engine (GKE) Autopilot במקום לפרוס קונטיינרים במכונות וירטואליות.
  • כדי לענות על צורכי העיבוד של Apache Hadoop או Apache Spark, אפשר להשתמש ב-Dataproc וב-Dataproc Serverless. חיוב לפי שנייה יכול לעזור להשיג עלות כוללת נמוכה יותר באופן משמעותי בהשוואה לאגמי נתונים מקומיים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המלצות

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

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

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

  • סטנדרטיזציה של חישוב העלויות והתקצוב: חשוב להשתמש בשיטה עקבית כדי לקבוע את העלויות המלאות של משאבי הענן, אחרי שמביאים בחשבון הנחות ועלויות משותפות. צריך ליצור תהליכי תקצוב ברורים וסטנדרטיים שתואמים ליעדים של הארגון ומאפשרים ניהול עלויות פרואקטיבי.
  • שימוש בכלים סטנדרטיים לניהול עלויות ולשקיפות: שימוש בכלים מתאימים שמספקים תובנות בזמן אמת לגבי ההוצאות ב-Cloud ומפיקים תמונות מצב של התקדמות העלויות באופן קבוע (לדוגמה, שבועי). הכלים האלה מאפשרים לכם לתכנן את התקציב, ליצור תחזיות ולזהות הזדמנויות לאופטימיזציה באופן יזום. הכלים יכולים להיות כלים של ספק שירותי ענן (כמו לוח הבקרה לחיוב ב-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 Google מסוימים כמו Compute Engine ו-GKE, אפשר לקבל קרדיטים של הנחות אוטומטיות אחרי שימוש רציף במשאבים מעבר לסף משך זמן ספציפי.
  • מכונות וירטואליות מסוג 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. אפשר להשתמש בכלי להצגה חזותית כמו Looker Studio כדי להתחבר למסד הנתונים של הניתוח, ליצור דוחות אינטראקטיביים ולאפשר בקרת גישה מפורטת באמצעות הרשאות מבוססות-תפקידים.
  • דוחות עלויות של מרובה עננים: עבור פריסות מרובות עננים, אתם צריכים תצוגה מאוחדת של העלויות בכל ספקי שירותי הענן כדי להבטיח Analysis מקיף, תקצוב ואופטימיזציה. אפשר להשתמש בכלים כמו BigQuery כדי לרכז ולנתח נתוני עלויות מכמה ספקי ענן, ולהשתמש ב-Looker Studio כדי ליצור דוחות אינטראקטיביים ספציפיים לצוות.

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

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

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

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

המלצות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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