בחלק הזה של Google Cloud Well-Architected Framework מפורטות המלצות לאופטימיזציה של הביצועים של עומסי העבודה ב-Google Cloud.
המסמך הזה מיועד לאדריכלים, למפתחים ולאדמינים שמתכננים, מעצבים, פורסים ומנהלים עומסי עבודה ב- Google Cloud.
ההמלצות בעמוד התווך הזה יכולות לעזור לארגון לפעול ביעילות, לשפר את שביעות רצון הלקוחות, להגדיל את ההכנסות ולהפחית את העלויות. לדוגמה, כשזמן העיבוד של אפליקציה בקצה העורפי מתקצר, המשתמשים נהנים מזמני תגובה מהירים יותר, מה שיכול להוביל לשיעור גבוה יותר של שימור משתמשים ולהגדלת ההכנסות.
תהליך האופטימיזציה של הביצועים יכול לכלול פשרה בין ביצועים לעלות. עם זאת, אופטימיזציה של הביצועים יכולה לפעמים לעזור לכם להפחית את העלויות. לדוגמה, כשהעומס גדל, התאמה אוטומטית לעומס (automatic scaling) יכולה לעזור לספק ביצועים צפויים על ידי כך שהיא מבטיחה שמשאבי המערכת לא יהיו עמוסים מדי. התאמה לעומס (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
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Marwan Al Shawi | Partner Customer Engineer
- ניקולס פינטו | מהנדס לקוחות, מומחה למודרניזציה של אפליקציות
- ריאן קוקס | אדריכל ראשי
- Radhika Kanakam | מובילת תוכנית, 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 ואת שירותי המטמון.
- אפשרויות לאירוח אפליקציות: כשבוחרים פלטפורמת אירוח, צריך להעריך את היתרונות והחסרונות של כל אפשרות מבחינת הביצועים. לדוגמה, שקלו להשתמש ב-Bare Metal, במכונות וירטואליות, בקונטיינרים ובפלטפורמות ללא שרת (serverless).
- אסטרטגיית אחסון: בוחרים אסטרטגיית אחסון אופטימלית בהתאם לדרישות הביצועים.
- הגדרות המשאבים: לסוג המכונה, ל-IOPS ולקצב העברת הנתונים יכולה להיות השפעה משמעותית על הביצועים. בנוסף, בשלב מוקדם של התכנון, צריך לשקול את יכולות האבטחה המתאימות ואת ההשפעה שלהן על המשאבים. כשמתכננים אמצעי אבטחה, צריך להיות מוכנים להתפשר על הביצועים כדי להימנע מהשפעות בלתי צפויות.
המלצות
כדי להבטיח הקצאת משאבים אופטימלית, כדאי לפעול לפי ההמלצות שבקטעים הבאים.
הגדרה וניהול של מכסות
חשוב לוודא שהאפליקציה משתמשת רק במשאבים הנחוצים, כמו זיכרון, אחסון וכוח עיבוד. הקצאת יתר עלולה להוביל להוצאות מיותרות, והקצאת חסר עלולה לפגוע בביצועים.
כדי להתאים את עצמכם לשינויים בגודל המשאבים ולוודא שיש לכם מספיק משאבים, כדאי לעקוב באופן קבוע אחרי הקיבולת של המכסות. בנוסף, כדאי לעקוב אחרי השימוש במכסות כדי לזהות אילוצים פוטנציאליים בהתאמה לעומס או בעיות של הקצאת יתר, ואז לקבל החלטות מושכלות לגבי הקצאת המשאבים.
ללמד ולקדם מודעות
ליידע את המשתמשים לגבי דרישות הביצועים ולספק מקורות מידע על שיטות יעילות לניהול ביצועים.
כדי להעריך את ההתקדמות ולזהות תחומים לשיפור, תעדו באופן קבוע את הביצועים בפועל לעומת הביצועים הרצויים. כדאי לבצע בדיקת עומסים באפליקציה כדי למצוא נקודות עצירה פוטנציאליות ולהבין איך אפשר לשנות את קנה המידה של האפליקציה.
מעקב אחרי מדדי ביצועים
אפשר להשתמש ב-Cloud Monitoring כדי לנתח מגמות במדדי הביצועים, לנתח את ההשפעות של ניסויים, להגדיר התראות למדדים קריטיים ולבצע ניתוחים רטרוספקטיביים.
Active Assist הוא חבילת כלים שמספקת תובנות והמלצות שיעזרו לכם לייעל את השימוש במשאבים. ההמלצות האלה יכולות לעזור לכם לשנות את הקצאת המשאבים ולשפר את הביצועים.
מנצלים את הגמישות
העיקרון הזה, שמופיע בעמוד התווך של אופטימיזציית הביצועים ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לשלב גמישות – היכולת להתאים את המשאבים באופן דינמי על סמך שינויים בדרישות של עומס העבודה.
גמישות מאפשרת לרכיבים שונים של מערכת לשנות את קנה המידה באופן עצמאי. התאמה ממוקדת כזו יכולה לשפר את הביצועים ואת היעילות מבחינת עלות, כי היא מקצה משאבים בדיוק איפה שצריך, בלי הקצאת יתר או הקצאת חסר של המשאבים.
סקירה כללית של העקרונות
דרישות הביצועים של המערכת משפיעות באופן ישיר על המועד והאופן שבו המערכת משתנה אנכית או אופקית. צריך להעריך את קיבולת המערכת ולקבוע את העומס שהמערכת צפויה להתמודד איתו בבסיס ההשוואה. לאחר מכן, צריך לקבוע איך המערכת תגיב לעליות ולירידות בעומס.
כשהעומס גדל, המערכת צריכה להתרחב אופקית (scale out), להתרחב אנכית (scale up) או גם וגם. כדי להרחיב את המערכת בצורה אופקית, מוסיפים צומתי רפליקה כדי לוודא שיש למערכת מספיק קיבולת כוללת כדי לעמוד בביקוש המוגבר. כדי להגדיל את קנה המידה בצורה אנכית, מחליפים את הרכיבים הקיימים של האפליקציה ברכיבים שמכילים יותר קיבולת, יותר זיכרון ויותר נפח אחסון.
כשהעומס פוחת, המערכת צריכה לצמצם את המשאבים (אופקית, אנכית או גם וגם).
מגדירים את הנסיבות שבהן המערכת תרחיב או תצמצם את המשאבים. תכננו להרחיב ידנית את המערכות בתקופות ידועות של תנועה גבוהה. השתמשו בכלים כמו התאמה אוטומטית לעומס (autoscaling), שמגיבה לעליות או לירידות בעומס.
המלצות
כדי לנצל את הגמישות, כדאי להשתמש בהמלצות שבקטעים הבאים.
תכנון לתקופות של עומס שיא
אתם צריכים לתכנן נתיב התאמה יעיל לאירועים ידועים, כמו תקופות צפויות של עלייה בביקוש מצד הלקוחות.
כדאי להרחיב את המערכת לפני תקופות ידועות של תנועה גבוהה. לדוגמה, אם אתם ארגון קמעונאי, אתם מצפים שהביקוש יעלה במהלך מבצעים עונתיים. מומלץ להרחיב את המערכות באופן ידני (אנכית או אופקית) לפני המכירות האלה, כדי לוודא שהמערכת תוכל להתמודד מיד עם העומס המוגבר, או להתאים מיד את המגבלות הקיימות. אחרת, יכול להיות שיעברו כמה דקות עד שהמערכת תוסיף משאבים בתגובה לשינויים בזמן אמת. יכול להיות שהקיבולת של האפליקציה לא תגדל מספיק מהר, וזה יגרום לעיכובים אצל חלק מהמשתמשים.
באירועים לא ידועים או לא צפויים, כמו עלייה פתאומית בביקוש או בתנועה, אתם יכולים להשתמש בתכונות של התאמה אוטומטית לעומס כדי להפעיל התאמה גמישה לעומס שמבוססת על מדדים. המדדים האלה יכולים לכלול ניצול מעבד (CPU), קיבולת השירות של מאזן העומסים, זמן אחזור ואפילו מדדים מותאמים אישית שאתם מגדירים ב-Cloud Monitoring.
לדוגמה, נניח שיש אפליקציה שפועלת בקבוצת מופעי מכונה מנוהלים (MIG) ב-Compute Engine. באפליקציה הזו יש דרישה שכל מכונה תפעל בצורה אופטימלית עד שהניצול הממוצע של המעבד יגיע ל-75%. בדוגמה הזו, אפשר להגדיר מדיניות התאמה לעומס (autoscaling) שיוצרת עוד מכונות כשניצול ה-CPU מגיע לסף. המכונות החדשות שנוצרו עוזרות להתמודד עם העומס, וכך לוודא ששיעור הניצול הממוצע של המעבד נשאר אופטימלי עד שמגיעים למספר המכונות המקסימלי שהגדרתם לקבוצת ה-MIG. כשהביקוש יורד, מדיניות ההתאמה האוטומטית לעומס מסירה את המכונות שאין בהן יותר צורך.
תכננו הזמנות של יחידות קיבולת (Slot) ב-BigQuery או התאימו את המגבלות של הגדרות ההתאמה האוטומטית לעומס ב-Spanner באמצעות מידרוג אוטומטי.
שימוש בהתאמה חזויה לעומס (predictive scaling)
אם רכיבי המערכת שלכם כוללים את Compute Engine, אתם צריכים לבדוק אם התאמה אוטומטית חזויה לעומס מתאימה לעומס העבודה שלכם. התכונה "חיזוי להתאמה אוטומטית לעומס" חוזה את העומס העתידי על סמך מגמות היסטוריות של המדדים, למשל ניצול ה-CPU. התחזיות מחושבות מחדש כל כמה דקות, כך שהמידרוג האוטומטי מתאים במהירות את התחזית לשינויים האחרונים בעומס. בלי התאמה חזויה לעומס, המערכת יכולה להתאים את קבוצת המכונות לעומס רק באופן תגובתי, על סמך שינויים בעומס שנצפו בזמן אמת. התאמה אוטומטית לעומס חיזוי פועלת גם עם נתונים בזמן אמת וגם עם נתונים היסטוריים, כדי להגיב לעומס הנוכחי ולעומס החזוי.
הטמעת ארכיטקטורות ללא שרת (serverless)
כדאי להטמיע ארכיטקטורה ללא שרת (serverless) עם שירותים ללא שרת שהם גמישים מטבעם, כמו:
בניגוד להתאמה לעומס בשירותים אחרים שדורשים כללים לכוונון עדין (לדוגמה, Compute Engine), התאמה לעומס ללא שרת היא מיידית ויכולה לצמצם את המשאבים לאפס.
שימוש במצב Autopilot ב-Kubernetes
לאפליקציות מורכבות שדורשות שליטה רבה יותר ב-Kubernetes, כדאי להשתמש במצב Autopilot ב-Google Kubernetes Engine (GKE). מצב אוטומטי מספק אוטומציה ומדרגיות כברירת מחדל. GKE מתאים באופן אוטומטי את הצמתים והמשאבים לעומס (automatic scaling) על סמך התנועה. 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 יכול לעזור לכם לאסוף משוב ממשתמשים בחמש קטגוריות:
- אושר
- מעורבות
- הטמעה
- שמירה
- המשימה הושלמה
שימוש במסגרת כזו מאפשר לתמרץ מהנדסים באמצעות משוב מבוסס-נתונים, מדדים שמתמקדים במשתמשים, תובנות פרקטיות והבנה ברורה של היעדים.