העיקרון הזה ב-Google Cloud Well-Architected Framework מספק המלצות לאופטימיזציה של ביצועי עומסי העבודה ב-Google Cloud.
המסמך הזה מיועד לאדריכלים, למפתחים ולאדמינים שמתכננים, מעצבים, פורסים ומנהלים עומסי עבודה ב- Google Cloud.
ההמלצות בעמוד התווך הזה יכולות לעזור לארגון לפעול ביעילות, לשפר את שביעות רצון הלקוחות, להגדיל את ההכנסות ולהפחית את העלויות. לדוגמה, כשזמן העיבוד של אפליקציה בקצה העורפי מתקצר, המשתמשים נהנים מזמני תגובה מהירים יותר, מה שיכול להוביל לשיעור גבוה יותר של שימור משתמשים ולהגדלת ההכנסות.
תהליך האופטימיזציה של הביצועים יכול לכלול פשרה בין ביצועים לעלות. עם זאת, אופטימיזציה של הביצועים יכולה לפעמים לעזור לכם להפחית את העלויות. לדוגמה, כשהעומס גדל, התאמה אוטומטית לעומס יכולה לעזור לספק ביצועים צפויים על ידי הבטחה שמשאבי המערכת לא עמוסים מדי. התאמה לעומס (autoscaling) גם עוזרת לצמצם את העלויות על ידי הסרת משאבים שלא בשימוש בתקופות של עומס נמוך.
אופטימיזציה של הביצועים היא תהליך מתמשך, לא פעילות חד-פעמית. בתרשים הבא מוצגים השלבים בתהליך האופטימיזציה של הביצועים:
תהליך האופטימיזציה של הביצועים הוא מחזור מתמשך שכולל את השלבים הבאים:
- הגדרת דרישות: הגדירו דרישות ביצועים מפורטות לכל שכבה במחסנית האפליקציה לפני שאתם מתכננים ומפתחים את האפליקציות. כדי לתכנן את הקצאת המשאבים, כדאי להביא בחשבון את המאפיינים העיקריים של עומס העבודה ואת הציפיות לגבי הביצועים.
- תכנון ופריסה: שימוש בתבניות עיצוב גמישות וניתנות להתאמה, שיכולות לעזור לכם לעמוד בדרישות הביצועים.
- מעקב וניתוח: עוקבים אחרי הביצועים באופן קבוע באמצעות יומנים, מעקב, מדדים והתראות.
אופטימיזציה: כדאי לשקול עיצובים חדשים ככל שהאפליקציות מתפתחות. להתאים את משאבי הענן ולהשתמש בתכונות חדשות כדי לעמוד בדרישות הביצועים המשתנות.
כפי שמוצג בתרשים הקודם, ממשיכים במחזור של מעקב, הערכה מחדש של הדרישות והתאמת משאבי הענן.
במאמר נקודת מבט על AI ו-ML: אופטימיזציה של ביצועים ב-Well-Architected Framework, תוכלו לקרוא על עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ו-ML.
הערכת עומסי עבודה באמצעות מיומנות של סוכן
כדי לאפשר לסוכני AI להעריך את עומסי העבודה בענן בהתאם לעקרונות ולהמלצות שבעמוד התווך הזה, אתם יכולים להשתמש במיומנות google-cloud-waf-performance-optimization שזמינה במאגר Google Agent Skills ב-GitHub.
כדי להתקין את המיומנות, מריצים את הפקודה הבאה בטרמינל או בלקוח של הנציג:
npx skills add google/skills --skill google-cloud-waf-performance-optimization
כשמוצגת בקשה, מציינים את סוכני ה-AI שרוצים להתקין בהם את המיומנות ומגדירים את היקף ההתקנה (פרויקט או גלובלי).
אם כבר התקנתם את המיומנות, אתם יכולים לעדכן אותה לגרסה העדכנית באמצעות הפקודה הבאה:
npx skills update
עקרונות הליבה
ההמלצות בעקרון אופטימיזציית הביצועים של Well-Architected Framework ממופות לעקרונות הליבה הבאים:
שותפים ביצירת התוכן
מחברים:
- דניאל ליס | ארכיטקט אבטחה בענן
- גארי הרמסון | אדריכל ראשי
- לואיס אורנה | מהנדס קשרי מפתחים
- זאק סיילס | מומחה רשתות
תורמים אחרים:
- Filipe Gracio, PhD | Customer Engineer, AI/ML Specialist
- חוזה אנדרדה | מהנדס לקוחות, מומחה SRE
- קומאר דהנגופאל | מפתח פתרונות למוצרים שונים
- מרוואן אל שאווי | מהנדס לקוחות של שותפים
- ניקולס פינטו | מהנדס לקוחות, מומחה למודרניזציה של אפליקציות
- ריאן קוקס | אדריכל ראשי
- רדהיקה קנקאם | מנהלת תוכנית, Google Cloud Well-Architected Framework
- סמנתה הי | כותבת טכנית
- Wade Holmes | Global Solutions Director
תכנון הקצאת המשאבים
העיקרון הזה, שמופיע בעמוד התווך של אופטימיזציית הביצועים ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לתכנן את המשאבים לעומסי העבודה ב-Google Cloud. הוא מדגיש את החשיבות של הגדרת דרישות מפורטות לפני שמתכננים ומפתחים אפליקציות לפריסה או להעברה לענן.
סקירה כללית של העקרונות
כדי לעמוד בדרישות העסקיות, חשוב להגדיר את דרישות הביצועים של האפליקציות לפני התכנון והפיתוח. הגדירו את הדרישות האלה בצורה הכי מפורטת שאפשר, גם לאפליקציה כולה וגם לכל שכבה במחסנית האפליקציה. לדוגמה, בשכבת האחסון צריך להביא בחשבון את קצב הנתונים ואת פעולות הקלט/פלט לשנייה (IOPS) שהאפליקציות צריכות.
מההתחלה, תכננו את עיצובי האפליקציות תוך התחשבות בביצועים ובמדרגיות. כדאי להביא בחשבון גורמים כמו מספר המשתמשים, נפח הנתונים והצמיחה הפוטנציאלית לאורך זמן.
דרישות הביצועים של כל עומס עבודה משתנות בהתאם לסוג עומס העבודה. כל עומס עבודה יכול להכיל שילוב של מערכות ושירותים של רכיבים, עם מאפייני ביצועים ייחודיים. לדוגמה, למערכת שאחראית על עיבוד תקופתי של קבוצות נתונים גדולות ברצף (batch processing) יש דרישות ביצועים שונות מאלה של פתרון אינטראקטיבי לשולחן עבודה וירטואלי. שיטות האופטימיזציה צריכות להתייחס לצרכים הספציפיים של כל עומס עבודה.
בחרו שירותים ותכונות שמתאימים ליעדי הביצועים של כל עומס עבודה. אין פתרון אחד שמתאים לכולם לאופטימיזציה של הביצועים. כשמבצעים אופטימיזציה לכל עומס עבודה, המערכת כולה יכולה להגיע לביצועים וליעילות אופטימליים.
כדאי להביא בחשבון את המאפיינים הבאים של עומס העבודה, שיכולים להשפיע על דרישות הביצועים:
- ארכיטיפ פריסה: ארכיטיפ הפריסה שתבחרו לאפליקציה יכול להשפיע על בחירת המוצרים והתכונות, שיקבעו את הביצועים הצפויים מהאפליקציה.
- מיקום המשאבים: כשבוחרים Google Cloudאזור למשאבי האפליקציה, מומלץ לתת עדיפות לזמן אחזור נמוך למשתמשי הקצה, לפעול בהתאם לתקנות בנושא אחסון ועיבוד נתונים באופן מקומי ולוודא ש Google Cloud המוצרים והשירותים הנדרשים זמינים.
- קישוריות לרשת: בחירת שירותי רשת שמבצעים אופטימיזציה של הגישה לנתונים ושל העברת התוכן. אתם יכולים לנצל את הרשת הגלובלית של Google Cloud, את רשתות ה-backbone המהירות, את מיקומי ה-interconnect ואת שירותי המטמון.
- אפשרויות לאירוח אפליקציות: כשבוחרים פלטפורמת אירוח, צריך להעריך את היתרונות והחסרונות של כל אפשרות מבחינת הביצועים. לדוגמה, שקלו להשתמש בשרתים פיזיים, במכונות וירטואליות, בקונטיינרים ובפלטפורמות ללא שרת (serverless).
- אסטרטגיית אחסון: בחרו אסטרטגיית אחסון אופטימלית שמבוססת על דרישות הביצועים שלכם.
- הגדרות המשאבים: סוג המכונה, ה-IOPS וקצב הנתונים יכולים להשפיע באופן משמעותי על הביצועים. בנוסף, בשלב מוקדם של התכנון, צריך לשקול את יכולות האבטחה המתאימות ואת ההשפעה שלהן על המשאבים. כשמתכננים את אמצעי האבטחה, צריך להתכונן לפשרות הנדרשות בביצועים כדי למנוע השפעות בלתי צפויות.
המלצות
כדי להבטיח הקצאת משאבים אופטימלית, כדאי לפעול לפי ההמלצות שבקטעים הבאים.
הגדרה וניהול של מכסות
חשוב לוודא שהאפליקציה משתמשת רק במשאבים הנחוצים, כמו זיכרון, אחסון וכוח עיבוד. הקצאת יתר עלולה להוביל להוצאות מיותרות, והקצאת חסר עלולה לפגוע בביצועים.
כדי להתאים את עצמכם לשינויים בגודל, ולוודא שיש לכם מספיק משאבים, חשוב לעקוב באופן קבוע אחרי הקיבולת של המכסות. בנוסף, כדאי לעקוב אחרי השימוש במכסות כדי לזהות אילוצים פוטנציאליים בהתאמה לעומס או בעיות של הקצאת יתר, ואז לקבל החלטות מושכלות לגבי הקצאת המשאבים.
ללמד ולקדם מודעות
ליידע את המשתמשים לגבי דרישות הביצועים ולספק מקורות מידע על שיטות יעילות לניהול ביצועים.
כדי להעריך את ההתקדמות ולזהות תחומים לשיפור, תעדו באופן קבוע את הביצועים בפועל לעומת הביצועים הרצויים. כדאי לבצע בדיקת עומסים באפליקציה כדי למצוא נקודות שבירה פוטנציאליות ולהבין איך אפשר לשנות את קנה המידה של האפליקציה.
מעקב אחרי מדדי ביצועים
אפשר להשתמש ב-Cloud Monitoring כדי לנתח מגמות במדדי הביצועים, לנתח את ההשפעות של ניסויים, להגדיר התראות למדדים קריטיים ולבצע ניתוחים רטרוספקטיביים.
Active Assist הוא אוסף של כלים שמספקים תובנות והמלצות שיעזרו לכם לייעל את השימוש במשאבים. ההמלצות האלה יכולות לעזור לכם לשנות את הקצאת המשאבים ולשפר את הביצועים.
מנצלים את הגמישות
העיקרון הזה, שמופיע בעמוד התווך של אופטימיזציית הביצועים ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לשלב גמישות – היכולת להתאים את המשאבים באופן דינמי על סמך שינויים בדרישות של עומס העבודה.
גמישות מאפשרת לרכיבים שונים של מערכת להתאים את קנה המידה שלהם באופן עצמאי. התאמה ממוקדת כזו יכולה לשפר את הביצועים ואת היעילות מבחינת עלות, כי היא מקצה משאבים בדיוק איפה שצריך, בלי להקצות יותר מדי או פחות מדי משאבים.
סקירה כללית של העקרונות
דרישות הביצועים של המערכת משפיעות באופן ישיר על המועד והאופן שבו המערכת משתנה אנכית או אופקית. צריך להעריך את קיבולת המערכת ולקבוע את העומס שהמערכת צפויה להתמודד איתו בבסיס. לאחר מכן, צריך לקבוע איך המערכת תגיב לעליות ולירידות בעומס.
כשהעומס גדל, המערכת צריכה להתרחב אופקית (scale out), להתרחב אנכית (scale up) או גם וגם. כדי להרחיב את המערכת בצורה אופקית, מוסיפים צומתי רפליקה כדי לוודא שיש למערכת מספיק קיבולת כוללת כדי לעמוד בביקוש המוגבר. כדי להגדיל את קנה המידה בצורה אנכית, מחליפים את הרכיבים הקיימים של האפליקציה ברכיבים עם קיבולת, זיכרון ונפח אחסון גדולים יותר.
כשהעומס פוחת, המערכת צריכה לצמצם את המשאבים (אופקית, אנכית או גם וגם).
מגדירים את הנסיבות שבהן המערכת תגדיל או תצמצם את המשאבים. תכננו להגדיל את המערכות באופן ידני בתקופות ידועות של תנועה גבוהה. השתמשו בכלים כמו התאמה אוטומטית לעומס (autoscaling), שמגיבה לעליות או לירידות בעומס.
המלצות
כדי לנצל את הגמישות, כדאי להשתמש בהמלצות שבקטעים הבאים.
תכנון לתקופות של עומס שיא
אתם צריכים לתכנן נתיב התאמה יעיל לאירועים ידועים, כמו תקופות צפויות של ביקוש מוגבר מצד הלקוחות.
כדאי להגדיל את המערכת לפני תקופות ידועות של תנועה רבה. לדוגמה, אם אתם ארגון קמעונאי, אתם מצפים שהביקוש יעלה במהלך מבצעים עונתיים. מומלץ להרחיב את המערכות אנכית או אופקית בהתאם לעומס (scale up או scale out) באופן ידני לפני המכירות האלה, כדי לוודא שהמערכת תוכל לטפל מיד בעומס המוגבר או להתאים מיד את המגבלות הקיימות. אחרת, יכול להיות שיעברו כמה דקות עד שהמערכת תוסיף משאבים בתגובה לשינויים בזמן אמת. יכול להיות שהקיבולת של האפליקציה לא תגדל מספיק מהר, וחלק מהמשתמשים יחוו עיכובים.
באירועים לא ידועים או לא צפויים, כמו עלייה פתאומית בביקוש או בתנועה, אתם יכולים להשתמש בתכונות של התאמה אוטומטית לעומס כדי להפעיל התאמה גמישה לעומס שמבוססת על מדדים. המדדים האלה יכולים לכלול ניצול מעבד (CPU), קיבולת הצגת המודעות של מאזן העומסים, זמן אחזור ואפילו מדדים מותאמים אישית שאתם מגדירים ב-Cloud Monitoring.
לדוגמה, נניח שיש אפליקציה שפועלת בקבוצת מופעי מכונה מנוהלים (MIG) ב-Compute Engine. באפליקציה הזו יש דרישה שכל מכונה תפעל בצורה אופטימלית עד שהניצול הממוצע של המעבד יגיע ל-75%. בדוגמה הזו, אפשר להגדיר מדיניות התאמה אוטומטית לעומס שיוצרת עוד מכונות כשניצול המעבד מגיע לסף. המכונות החדשות שנוצרו עוזרות לספוג את העומס, וכך לוודא ששיעור הניצול הממוצע של המעבד נשאר אופטימלי עד שמגיעים למספר המכונות המקסימלי שהגדרתם לקבוצת ה-MIG. כשהביקוש יורד, מדיניות ההתאמה האוטומטית לעומס מסירה את המכונות שאין בהן יותר צורך.
תכננו הזמנות של משבצות משאבים ב-BigQuery או התאימו את המגבלות של הגדרות ההתאמה האוטומטית לעומס ב-Spanner באמצעות התאמה אוטומטית מנוהלת לעומס.
שימוש בהתאמה חזויה לעומס (predictive scaling)
אם רכיבי המערכת שלכם כוללים את Compute Engine, אתם צריכים לבדוק אם התאמה אוטומטית חזויה לעומס (autoscaling) מתאימה לעומס העבודה שלכם. התכונה "חיזוי להתאמה אוטומטית לעומס" חוזה את העומס העתידי על סמך מגמות היסטוריות של המדדים, למשל ניצול ה-CPU. התחזיות מחושבות מחדש כל כמה דקות, כך שהמידרוג האוטומטי מתאים במהירות את התחזית לשינויים האחרונים בעומס. בלי התאמה אוטומטית לעומס (scaling) חזויה, מידרוג אוטומטי יכול להתאים את הקבוצה לעומס רק באופן תגובתי, על סמך שינויים בעומס שנצפו בזמן אמת. התאמה אוטומטית לעומס (scaling) חזויה פועלת גם עם נתונים בזמן אמת וגם עם נתונים היסטוריים, כדי להגיב לעומס הנוכחי ולעומס החזוי.
הטמעת ארכיטקטורות ללא שרת (serverless)
כדאי להטמיע ארכיטקטורה ללא שרת (serverless) עם שירותים ללא שרת שהם גמישים מטבעם, כמו:
בניגוד להתאמה לעומס בשירותים אחרים שדורשים כללים לכוונון עדין (לדוגמה, Compute Engine), התאמה לעומס ללא שרת היא מיידית ויכולה לצמצם את המשאבים לאפס.
שימוש במצב Autopilot ב-Kubernetes
לאפליקציות מורכבות שדורשות שליטה רבה יותר ב-Kubernetes, כדאי להשתמש במצב Autopilot ב-Google Kubernetes Engine (GKE). מצב אוטומטי מספק אוטומציה ומדרגיות כברירת מחדל. GKE מבצע התאמה אוטומטית לעומס של הצמתים והמשאבים בהתאם לתעבורת הנתונים. GKE מנהל את הצמתים, יוצר צמתים חדשים לאפליקציות ומגדיר שדרוגים ותיקונים אוטומטיים.
קידום עיצוב מודולרי
העיקרון הזה, שמופיע בעמוד התווך של אופטימיזציית הביצועים ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לקדם עיצוב מודולרי. רכיבים מודולריים וממשקים ברורים יכולים לאפשר התאמה גמישה לעומס, עדכונים עצמאיים והפרדה עתידית של רכיבים.
סקירה כללית של העקרונות
להבין את יחסי התלות בין רכיבי האפליקציה לרכיבי המערכת כדי לתכנן מערכת שניתנת להתאמה לעומס.
עיצוב מודולרי מאפשר גמישות ועמידות, גם אם בהתחלה נפרסה ארכיטקטורה מונוליתית או ארכיטקטורה של מיקרו-שירותים. אם תפרקו את המערכת למודולים מוגדרים היטב ועצמאיים עם ממשקים ברורים, תוכלו לשנות את קנה המידה של רכיבים ספציפיים כדי לעמוד בדרישות מסוימות.
התאמה ממוקדת של קנה המידה יכולה לעזור לכם לייעל את השימוש במשאבים ולהוזיל את העלויות בדרכים הבאות:
- מקצה רק את המשאבים הדרושים לכל רכיב, ומקצה פחות משאבים לרכיבים פחות תובעניים.
- הוספת משאבים בתקופות של תנועה גבוהה כדי לשמור על חוויית המשתמש.
- הסרת משאבים שלא מנוצלים מספיק בלי לפגוע בביצועים.
מודולריות גם משפרת את יכולת התחזוקה. יחידות קטנות יותר, שפועלות באופן עצמאי, קלות יותר להבנה, לניפוי באגים ולעדכון, מה שיכול להוביל למחזורי פיתוח מהירים יותר ולהפחתת הסיכון.
למרות שלמודולריות יש יתרונות משמעותיים, חשוב להעריך את הפשרות האפשריות בביצועים. התקשורת המוגברת בין המודולים עלולה לגרום לזמן אחזור ולתקורה. נסו למצוא את האיזון בין מודולריות לביצועים. עיצוב מודולרי מאוד לא בהכרח מתאים לכל המקרים. כשהביצועים קריטיים, יכול להיות שגישה של צימוד חזק יותר תתאים. תכנון המערכת הוא תהליך איטרטיבי, שבו בודקים ומשפרים כל הזמן את התכנון המודולרי.
המלצות
כדי לקדם עיצובים מודולריים, כדאי להביא בחשבון את ההמלצות בסעיפים הבאים.
תכנון לצימוד חלש
תכנון ארכיטקטורה בצימוד חלש. רכיבים עצמאיים עם מינימום תלויות יכולים לעזור לכם לבנות אפליקציות ניתנות להתאמה וגמישות. כשאתם מתכננים את הגבולות של השירותים, אתם צריכים להביא בחשבון את דרישות הזמינות והמדרגיות. לדוגמה, אם לרכיב אחד יש דרישות שונות משאר הרכיבים, אתם יכולים לעצב את הרכיב כשירות עצמאי. הטמיעו תוכנית לטיפול בכשלים בתהליכי משנה או בשירותים פחות חשובים, שלא משפיעים על זמן התגובה של השירותים העיקריים.
תכנון של בו-זמניות ומקביליות
תכננו את האפליקציה כך שתתמוך בכמה משימות בו-זמנית, כמו עיבוד של כמה בקשות משתמשים או הפעלת משימות ברקע בזמן שהמשתמשים יוצרים אינטראקציה עם המערכת. לפצל משימות גדולות לחלקים קטנים יותר, שאפשר לעבד בו-זמנית בכמה מכונות של שירותים. התכונה "משימות בו-זמניות" מאפשרת להשתמש בתכונות כמו התאמה אוטומטית לעומס (autoscaling) כדי להגדיל את הקצאת המשאבים במוצרים כמו:
מודולריות מאוזנת להקצאת משאבים גמישה
במידת האפשר, ודאו שכל רכיב משתמש רק במשאבים הדרושים (כמו זיכרון, אחסון וכוח עיבוד) לפעולות ספציפיות. הקצאת יתר של משאבים עלולה לגרום לעלויות מיותרות, והקצאת חסר של משאבים עלולה לפגוע בביצועים.
שימוש בממשקים מוגדרים היטב
חשוב לוודא שרכיבים מודולריים מתקשרים ביעילות באמצעות ממשקים ברורים וסטנדרטיים (כמו ממשקי API ותורי הודעות) כדי להפחית את התקורה משכבות תרגום או מתנועה מיותרת.
שימוש במודלים ללא שמירת מצב (stateless)
מודל בלי שמירת מצב יכול לעזור לכם לוודא שאתם יכולים לטפל בכל בקשה או אינטראקציה עם השירות, בלי קשר לבקשות קודמות. המודל הזה מאפשר יכולת התאמה לעומס (scalability) ויכולת שחזור, כי אפשר להגדיל, להקטין או להפעיל מחדש את השירות בלי לאבד את הנתונים שנדרשים לבקשות או לתהליכים שמתבצעים.
בחירת טכנולוגיות משלימות
בחרו טכנולוגיות שמשלימות את העיצוב המודולרי. העריכו שפות תכנות, מסגרות ומסדי נתונים כדי לבדוק את התמיכה שלהם במודולריות.
מידע נוסף זמין במקורות המידע הבאים:
מעקב רציף אחרי הביצועים ושיפור שלהם
העיקרון הזה, שמופיע בעמוד התווך של אופטימיזציית הביצועים ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לעקוב אחרי הביצועים ולשפר אותם באופן קבוע.
אחרי שפורסים אפליקציות, צריך לעקוב באופן קבוע אחרי הביצועים שלהן באמצעות יומנים, מעקב, מדדים והתראות. ככל שהאפליקציות גדלות ומתפתחות, אפשר להשתמש במגמות בנקודות על הגרף האלה כדי להעריך מחדש את דרישות הביצועים. יכול להיות שתצטרכו לתכנן מחדש חלקים מהאפליקציות כדי לשמור על הביצועים שלהן או לשפר אותם.
סקירה כללית של העקרונות
כדי לשפר את הביצועים באופן קבוע, צריך להשתמש בכלים ובאסטרטגיות יעילים למעקב. כלי ניראות בענן יכולים לעזור לכם לאסוף מדדי ביצועים מרכזיים (KPI) כמו זמן אחזור, תפוקה, שיעורי שגיאות וניצול משאבים. בסביבות ענן יש מגוון שיטות לביצוע הערכות ביצועים פרטניות באפליקציה, ברשת ובחוויית משתמש הקצה.
שיפור הביצועים הוא מאמץ מתמשך שדורש גישה רב-כיוונית. המנגנונים והתהליכים העיקריים הבאים יכולים לעזור לכם לשפר את הביצועים:
- כדי לספק כיוון ברור ולעזור במעקב אחרי ההתקדמות, הגדירו יעדי ביצועים שתואמים ליעדים העסקיים שלכם. הגדירו מטרות עסקיות חכמות: ספציפיות, מדידות, ברי השגה, רלוונטיות ומוגבלות בזמן.
- כדי למדוד את הביצועים ולזהות תחומים לשיפור, צריך לאסוף מדדי KPI.
- כדי לעקוב באופן רציף אחרי בעיות במערכות, השתמשו בתהליכי עבודה חזותיים בכלי המעקב. להשתמש בטכניקות של מיפוי תהליכים בארכיטקטורה כדי לזהות כפילויות וחוסר יעילות.
- כדי ליצור תרבות של שיפור מתמשך, כדאי לספק הדרכות ותוכניות שתומכות בצמיחה של העובדים.
- כדי לעודד שיפור יזום ומתמשך, תנו תמריצים לעובדים וללקוחות שלכם לספק משוב שוטף על ביצועי האפליקציה.
המלצות
כדי לעקוב אחרי הביצועים ולשפר אותם באופן קבוע, כדאי לפעול לפי ההמלצות שבקטעים הבאים.
הגדירו יעדי ביצועים ומדדים ברורים
הגדירו יעדי ביצועים ברורים שתואמים ליעדים העסקיים שלכם. לשם כך, אתם צריכים להבין לעומק את הארכיטקטורה של האפליקציה ואת דרישות הביצועים של כל רכיב באפליקציה.
קודם כל, בצעו אופטימיזציה של הרכיבים הכי קריטיים שמשפיעים ישירות על הפונקציות העסקיות העיקריות ועל חוויית המשתמש. כדי לוודא שהרכיבים האלה ימשיכו לפעול ביעילות ולענות על הצרכים העסקיים, הגדירו יעדי ביצועים ספציפיים וניתנים למדידה. היעדים האלה יכולים לכלול זמני תגובה, שיעורי שגיאות וספי ניצול משאבים.
הגישה הפרואקטיבית הזו יכולה לעזור לכם לזהות צווארי בקבוק פוטנציאליים ולטפל בהם, לבצע אופטימיזציה של הקצאת המשאבים, ובסופו של דבר לספק למשתמשים חוויה חלקה וביצועים גבוהים.
מעקב אחר הביצועים
עוקבים באופן קבוע אחרי מערכות הענן כדי לזהות בעיות בביצועים, ומגדירים התראות על בעיות פוטנציאליות. מעקב והתראות יכולים לעזור לכם לזהות בעיות ולתקן אותן לפני שהן משפיעות על המשתמשים. יצירת פרופיל של אפליקציה יכולה לעזור לזהות צווארי בקבוק ולשפר את השימוש במשאבים.
אתם יכולים להשתמש בכלים שמאפשרים לפתור בעיות ביעילות ולבצע אופטימיזציה של הרשת. משתמשים ב-Google Cloud Observability כדי לזהות אזורים עם צריכה גבוהה של מעבד (CPU), זיכרון או רשת. היכולות האלה יכולות לעזור למפתחים לשפר את היעילות, להפחית את העלויות ולשפר את חוויית המשתמש. ב-Network Intelligence Center מוצגת המחשה חזותית של הטופולוגיה של תשתית הרשת, שיכולה לעזור לכם לזהות נתיבים עם זמן אחזור ארוך.
תמריצים לשיפור מתמיד
כדאי ליצור תרבות של שיפור מתמשך, שיכולה להועיל גם לאפליקציה וגם לחוויית המשתמש.
לספק לעובדים הזדמנויות להכשרה ולפיתוח, כדי לשפר את המיומנויות והידע שלהם בשיטות לשיפור הביצועים בשירותי הענן. הקימו קהילת פרקטיקה (CoP) והציעו תוכניות חונכות ואימון כדי לתמוך בצמיחת העובדים.
כדי למנוע ניהול ביצועים תגובתי ולעודד ניהול ביצועים פרואקטיבי, כדאי לעודד משוב מתמשך מהעובדים, מהלקוחות ומבעלי העניין. אפשר להפוך את התהליך למשחק על ידי מעקב אחרי מדדי KPI של ביצועים והצגת המדדים האלה לצוותים לעיתים קרובות בצורה של טבלת ליגה.
כדי להבין את הביצועים ואת שביעות הרצון של המשתמשים לאורך זמן, מומלץ למדוד את המשוב מהמשתמשים באופן כמותי ואיכותי. מודל HEART יכול לעזור לכם לאסוף משוב ממשתמשים בחמש קטגוריות:
- שביעות רצון
- מעורבות
- הטמעה
- שמירה
- המשימה הושלמה
שימוש במסגרת כזו מאפשר לתמרץ מהנדסים באמצעות משוב מבוסס-נתונים, מדדים שמתמקדים במשתמשים, תובנות פרקטיות והבנה ברורה של היעדים.