בחלק הזה של Google Cloud Well-Architected Framework מפורטות המלצות לאופטימיזציה של הביצועים של עומסי העבודה ב-Google Cloud.
המסמך הזה מיועד לאדריכלים, למפתחים ולאדמינים שמתכננים, מעצבים, פורסים ומנהלים עומסי עבודה ב- Google Cloud.
ההמלצות בקטגוריה הזו יכולות לעזור לארגון שלכם לפעול ביעילות, לשפר את שביעות רצון הלקוחות, להגדיל את ההכנסות ולצמצם את העלויות. לדוגמה, כשזמן העיבוד של אפליקציה בשרת העורפי מתקצר, המשתמשים נהנים מזמני תגובה מהירים יותר, מה שיכול להוביל לשיעור שימור משתמשים גבוה יותר ולהגדלת ההכנסות.
תהליך האופטימיזציה של הביצועים יכול לכלול פשרה בין ביצועים לעלות. עם זאת, אופטימיזציה של הביצועים יכולה לעזור לכם לפעמים להפחית את העלויות. לדוגמה, כשהעומס גדל, התאמה אוטומטית לעומס (automatic scaling) יכולה לעזור לספק ביצועים צפויים על ידי כך שהיא מבטיחה שמשאבי המערכת לא יהיו עמוסים מדי. התאמה אוטומטית לעומס גם עוזרת לכם לצמצם את העלויות על ידי הסרת משאבים לא בשימוש בתקופות של עומס נמוך.
אופטימיזציה של הביצועים היא תהליך מתמשך, לא פעילות חד-פעמית. בתרשים הבא מוצגים השלבים בתהליך האופטימיזציה של הביצועים:
תהליך האופטימיזציה של הביצועים הוא מחזור מתמשך שכולל את השלבים הבאים:
- הגדרת דרישות: לפני שמתכננים ומפתחים את האפליקציות, מגדירים דרישות מפורטות לביצועים של כל שכבה במערך האפליקציות. כדי לתכנן את הקצאת המשאבים, כדאי לקחת בחשבון את המאפיינים העיקריים של עומס העבודה ואת ציפיות הביצועים.
- תכנון ופריסה: משתמשים בדפוסי תכנון גמישים וניתנים להרחבה שיכולים לעזור לכם לעמוד בדרישות הביצועים.
- מעקב וניתוח: מעקב רציף אחרי הביצועים באמצעות יומנים, מעקב, מדדים והתראות.
אופטימיזציה: כדאי לשקול עיצובים מחדש פוטנציאליים כשהאפליקציות מתפתחות. התאמת משאבי הענן ושימוש בתכונות חדשות כדי לעמוד בדרישות הביצועים המשתנות.
כפי שמוצג בתרשים הקודם, ממשיכים במחזור של מעקב, הערכה מחדש של הדרישות והתאמה של משאבי הענן.
במאמר נקודת מבט על AI ו-ML: אופטימיזציה של ביצועים ב-Well-Architected Framework, תוכלו לקרוא על עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ו-ML.
הערכת עומסי עבודה באמצעות סקיל אג'נטי
כדי לאפשר לסוכני AI להעריך את עומסי העבודה בענן בהתאם לעקרונות ולהמלצות שמופיעים בפרק הזה, אפשר להשתמש במיומנות google-cloud-waf-performance-optimization שזמינה במאגר המיומנויות של סוכני Google ב-GitHub.
כדי להתקין את המיומנות, מריצים את הפקודה הבאה בטרמינל או בלקוח של הנציג:
npx skills add google/skills --skill google-cloud-waf-performance-optimization
כשמוצגת בקשה, מציינים את סוכני ה-AI שרוצים להתקין בשבילם את המיומנות ומגדירים את היקף ההתקנה (פרויקט או גלובלי).
עקרונות מרכזיים
ההמלצות בנושא אופטימיזציה של ביצועים ב-Well-Architected Framework ממופות לעקרונות הליבה הבאים:
שותפים ביצירת התוכן
מחברים:
- דניאל ליס | ארכיטקט אבטחה בענן
- גארי הרמסון | אדריכל ראשי
- לואיס אורנה | מהנדס קשרי מפתחים
- זאק סיילס | מומחה רשתות
תורמי תוכן אחרים:
- Filipe Gracio, PhD | Customer Engineer, AI/ML Specialist
- חוסה אנדרדה | מהנדס לקוחות, מומחה SRE
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Marwan Al Shawi | Partner Customer Engineer
- ניקולס פינטו | מהנדס לקוחות, מומחה למודרניזציה של אפליקציות
- ריאן קוקס | אדריכל ראשי
- Radhika Kanakam | Program Lead, 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), שמגיבה לעליות או לירידות בעומס.
המלצות
כדי לנצל את הגמישות, כדאי להשתמש בהמלצות שבקטעים הבאים.
תכנון לתקופות של עומס שיא
צריך לתכנן דרך יעילה להרחבת הקיבולת לאירועים ידועים, כמו תקופות צפויות של עלייה בביקוש מצד הלקוחות.
כדאי להרחיב את המערכת לפני תקופות ידועות של תנועה גבוהה. לדוגמה, אם אתם ארגון קמעונאי, אתם מצפים לעלייה בביקוש במהלך מבצעים עונתיים. מומלץ להרחיב את המערכות באופן ידני (אנכית או אופקית) לפני המכירות האלה, כדי לוודא שהמערכת תוכל להתמודד מיד עם העומס המוגבר, או להתאים מיד את המגבלות הקיימות. אחרת, יכול להיות שיחלפו כמה דקות עד שהמערכת תוסיף משאבים בתגובה לשינויים בזמן אמת. יכול להיות שהקיבולת של האפליקציה לא תגדל מספיק מהר, וזה יגרום לעיכובים אצל חלק מהמשתמשים.
במקרה של אירועים לא ידועים או לא צפויים, כמו עלייה פתאומית בביקוש או בתעבורה, אפשר להשתמש בתכונות של התאמה אוטומטית לעומס כדי להפעיל התאמה גמישה לעומס שמבוססת על מדדים. המדדים האלה יכולים לכלול את ניצול המעבד, קיבולת ההגשה של מאזן העומסים, זמן האחזור ואפילו מדדים מותאמים אישית שאתם מגדירים ב-Cloud Monitoring.
לדוגמה, נניח שיש אפליקציה שפועלת בקבוצת מופעי מכונה מנוהלים (MIG) ב-Compute Engine. באפליקציה הזו יש דרישה שכל מכונה תפעל בצורה אופטימלית עד שהניצול הממוצע של המעבד יגיע ל-75%. בדוגמה הזו, אפשר להגדיר מדיניות התאמה לעומס (autoscaling) שיוצרת עוד מכונות כשניצול ה-CPU מגיע לסף. המופעים החדשים שנוצרו עוזרים לספוג את העומס, וכך לוודא ששיעור השימוש הממוצע במעבד יישאר אופטימלי עד שיגיע למספר המופעים המקסימלי שהגדרתם עבור ה-MIG. כשהביקוש יורד, מדיניות ההתאמה האוטומטית לעומס מסירה את המכונות שכבר לא נחוצות.
אפשר לתכנן מקומות שמורים של יחידות קיבולת (Slot) ב-BigQuery או לשנות את המגבלות של הגדרות התאמה אוטומטית לעומס (automatic scaling) ב-Spanner באמצעות מידרוג אוטומטי מנוהל.
שימוש בהתאמה חזויה לעומס (predictive scaling)
אם רכיבי המערכת שלכם כוללים את Compute Engine, אתם צריכים לבדוק אם התאמה אוטומטית חזויה לעומס מתאימה לעומס העבודה שלכם. תכונת ההתאמה האוטומטית לעומס החזויה חוזה את העומס העתידי על סמך המגמות ההיסטוריות של המדדים שלכם – למשל, ניצול המעבד. התחזיות מחושבות מחדש כל כמה דקות, כך שהמידרוג האוטומטי מתאים במהירות את התחזית שלו לשינויים האחרונים בעומס. בלי התאמה חזויה לעומס, המערכת יכולה להתאים את קבוצת המכונות לעומס רק באופן תגובתי, על סמך שינויים בעומס שנצפו בזמן אמת. התאמה אוטומטית לעומס חיזוי פועלת גם עם נתונים בזמן אמת וגם עם נתונים היסטוריים, כדי להגיב לעומס הנוכחי ולעומס החזוי.
הטמעת ארכיטקטורות ללא שרת (serverless)
כדאי להטמיע ארכיטקטורה ללא שרתים (serverless) עם שירותים ללא שרתים שהם גמישים מטבעם, כמו השירותים הבאים:
בניגוד לשינוי גודל אוטומטי בשירותים אחרים שדורשים כוונון עדין של כללים (לדוגמה, Compute Engine), שינוי גודל אוטומטי ב-serverless הוא מיידי, ויכול להקטין את מספר המשאבים לאפס.
שימוש במצב Autopilot ב-Kubernetes
לאפליקציות מורכבות שדורשות שליטה רבה יותר ב-Kubernetes, כדאי לשקול מצב Autopilot ב-Google Kubernetes Engine (GKE). מצב אוטומטי מספק אוטומציה ומדרגיות כברירת מחדל. GKE מתאים באופן אוטומטי את הצמתים והמשאבים לעומס (automatic scaling) על סמך התנועה. GKE מנהל את הצמתים, יוצר צמתים חדשים לאפליקציות שלכם ומגדיר שדרוגים ותיקונים אוטומטיים.
קידום עיצוב מודולרי
העיקרון הזה, שמופיע בעמוד התווך של אופטימיזציית הביצועים ב-Google Cloud Well-Architected Framework, מספק המלצות שיעזרו לכם לקדם עיצוב מודולרי. רכיבים מודולריים וממשקים ברורים יכולים לאפשר התאמה גמישה לעומס, עדכונים עצמאיים והפרדה עתידית של רכיבים.
סקירה כללית של העקרונות
להבין את יחסי התלות בין רכיבי האפליקציה לרכיבי המערכת כדי לעצב מערכת ניתנת להרחבה.
עיצוב מודולרי מאפשר גמישות ועמידות, בלי קשר לארכיטקטורה המונוליטית או למיקרו-שירותים שנפרסו בהתחלה. פירוק המערכת למודולים עצמאיים ומוגדרים היטב עם ממשקים ברורים מאפשר לכם להרחיב רכיבים ספציפיים כדי לעמוד בדרישות ספציפיות.
התאמה ממוקדת של קנה המידה יכולה לעזור לכם לייעל את השימוש במשאבים ולהוזיל את העלויות בדרכים הבאות:
- מקצה רק את המשאבים הדרושים לכל רכיב, ומקצה פחות משאבים לרכיבים פחות תובעניים.
- מוסיף עוד משאבים בתקופות של תנועה גבוהה כדי לשמור על חוויית המשתמש.
- הסרת משאבים שלא מנוצלים מספיק בלי לפגוע בביצועים.
מודולריות גם משפרת את יכולת התחזוקה. יחידות קטנות יותר, שפועלות באופן עצמאי, קל יותר להבין, לנפות באגים ולעדכן, מה שיכול להוביל למחזורי פיתוח מהירים יותר ולהפחתת הסיכון.
למרות שלמודולריות יש יתרונות משמעותיים, חשוב להעריך את הפשרות האפשריות בביצועים. התקשורת המוגברת בין המודולים עלולה לגרום לזמן אחזור ולתקורה. חשוב לשאוף לאיזון בין מודולריות לבין ביצועים. עיצוב מודולרי מאוד לא תמיד מתאים לכל המקרים. אם הביצועים הם קריטיים, יכול להיות שגישה עם צימוד הדוק יותר תתאים יותר. תכנון המערכת הוא תהליך איטרטיבי, שבו בודקים ומשפרים כל הזמן את התכנון המודולרי.
המלצות
כדי לקדם עיצובים מודולריים, כדאי לעיין בהמלצות שבקטעים הבאים.
תכנון לצימוד חלש
תכנון ארכיטקטורה בצימוד חלש. רכיבים עצמאיים עם תלות מינימלית יכולים לעזור לכם ליצור אפליקציות שניתנות להרחבה ועמידות. כשמתכננים את הגבולות של השירותים, צריך לקחת בחשבון את דרישות הזמינות והמדרגיות. לדוגמה, אם לרכיב אחד יש דרישות שונות מאלה של הרכיבים האחרים, אתם יכולים לתכנן את הרכיב כשירות עצמאי. הטמיעו תוכנית לטיפול בכשלים בתהליכי משנה או בשירותים פחות חשובים, שלא משפיעים על זמן התגובה של השירותים הראשיים.
תכנון לשימוש בו-זמני ולמקביליות
תכננו את האפליקציה כך שתתמוך בכמה משימות בו-זמנית, כמו עיבוד של כמה בקשות משתמשים או הפעלת משימות ברקע בזמן שהמשתמשים מבצעים פעולות במערכת. לפצל משימות גדולות לחלקים קטנים יותר, שאפשר לעבד בו-זמנית באמצעות כמה מכונות של שירותים. התכונה 'בו-זמניות משימות' מאפשרת להשתמש בתכונות כמו התאמה אוטומטית לעומס כדי להגדיל את הקצאת המשאבים במוצרים כמו:
איזון בין מודולריות להקצאת משאבים גמישה
ככל האפשר, צריך לוודא שכל רכיב משתמש רק במשאבים הדרושים (כמו זיכרון, אחסון וכוח עיבוד) לפעולות ספציפיות. הקצאת יתר של משאבים עלולה לגרום לעלויות מיותרות, ואילו הקצאת חסר של משאבים עלולה לפגוע בביצועים.
שימוש בממשקים מוגדרים היטב
חשוב לוודא שרכיבים מודולריים מתקשרים ביעילות באמצעות ממשקים ברורים וסטנדרטיים (כמו ממשקי API ותורי הודעות) כדי להפחית את התקורה משכבות תרגום או מתנועה מיותרת.
שימוש במודלים ללא שמירת מצב (stateless)
מודל חסר מצב יכול לעזור לכם לוודא שתוכלו לטפל בכל בקשה או אינטראקציה עם השירות בנפרד מהבקשות הקודמות. המודל הזה מאפשר מדרגיות ויכולת שחזור, כי אפשר להגדיל או להקטין את השירות או להפעיל אותו מחדש בלי לאבד את הנתונים שנדרשים לבקשות או לתהליכים שנמצאים בעיבוד.
בחירת טכנולוגיות משלימות
בחרו טכנולוגיות שמשלימות את העיצוב המודולרי. הערכה של שפות תכנות, מסגרות ונתונים מבחינת התמיכה שלהם במודולריות.
מידע נוסף זמין במקורות המידע הבאים:
מעקב שוטף אחרי הביצועים ושיפורם
העיקרון הזה הוא חלק מעמודת האופטימיזציה של הביצועים בGoogle Cloud Well-Architected Framework. הוא כולל המלצות שיעזרו לכם לעקוב אחרי הביצועים ולשפר אותם באופן שוטף.
אחרי שפורסים אפליקציות, צריך לעקוב אחרי הביצועים שלהן באופן קבוע באמצעות יומנים, מעקב, מדדים והתראות. ככל שהאפליקציות גדלות ומתפתחות, אפשר להשתמש במגמות בנקודות על הגרף האלה כדי להעריך מחדש את דרישות הביצועים. יכול להיות שתצטרכו לתכנן מחדש חלקים מהאפליקציות כדי לשמור על הביצועים שלהן או לשפר אותם.
סקירה כללית של העקרונות
כדי לשפר את הביצועים באופן קבוע, צריך להשתמש בכלים ובאסטרטגיות יעילים למעקב. כלים למעקב אחרי נראות ב-Cloud יכולים לעזור לכם לאסוף מדדי ביצועים מרכזיים (KPI) כמו זמן אחזור, קצב העברת נתונים, שיעורי שגיאות וניצול משאבים. סביבות ענן מציעות מגוון שיטות לביצוע הערכות מפורטות של הביצועים ברמת האפליקציה, הרשת וחוויית המשתמש.
שיפור הביצועים הוא מאמץ מתמשך שדורש גישה רב-פנים. המנגנונים והתהליכים העיקריים הבאים יכולים לעזור לכם לשפר את הביצועים:
- כדי לספק כיוון ברור ולעזור במעקב אחרי ההתקדמות, הגדירו יעדי ביצועים שתואמים ליעדים העסקיים שלכם. הגדירו מטרות עסקיות חכמות: ספציפיות, מדידות, ניתנות להשגה, רלוונטיות ומוגבלות בזמן.
- כדי למדוד את הביצועים ולזהות תחומים לשיפור, כדאי לאסוף מדדים של KPI.
- כדי לעקוב באופן רציף אחרי בעיות במערכות, השתמשו בתהליכי עבודה חזותיים בכלי המעקב. להשתמש בטכניקות של מיפוי תהליכי ארכיטקטורה כדי לזהות כפילויות וחוסר יעילות.
- כדי ליצור תרבות של שיפור מתמשך, צריך לספק הדרכות ותוכניות שתומכות בצמיחה של העובדים.
- כדי לעודד שיפור יזום ומתמשך, כדאי לתת תמריצים לעובדים וללקוחות כדי שיספקו משוב שוטף על הביצועים של האפליקציה.
המלצות
כדי לקדם עיצובים מודולריים, כדאי לעיין בהמלצות שבקטעים הבאים.
הגדירו יעדי ביצועים ומדדים ברורים
הגדירו יעדי ביצועים ברורים שתואמים ליעדים העסקיים שלכם. לשם כך, אתם צריכים להבין לעומק את הארכיטקטורה של האפליקציה ואת דרישות הביצועים של כל רכיב באפליקציה.
קודם כל, בצעו אופטימיזציה של הרכיבים הכי קריטיים שמשפיעים ישירות על הפונקציות העסקיות העיקריות ועל חוויית המשתמש. כדי לוודא שהרכיבים האלה ימשיכו לפעול ביעילות ויענו על הצרכים העסקיים שלכם, כדאי להגדיר יעדי ביצועים ספציפיים ומדידים. היעדים האלה יכולים לכלול זמני תגובה, שיעורי שגיאות וספי ניצול משאבים.
הגישה הפרואקטיבית הזו יכולה לעזור לכם לזהות צווארי בקבוק פוטנציאליים ולטפל בהם, לבצע אופטימיזציה של הקצאת המשאבים ובסופו של דבר לספק למשתמשים חוויה חלקה ואיכותית.
מעקב אחר הביצועים
עוקבים באופן רציף אחרי מערכות הענן כדי לזהות בעיות בביצועים ומגדירים התראות לבעיות פוטנציאליות. מעקב והתראות יכולים לעזור לכם לזהות בעיות ולתקן אותן לפני שהן משפיעות על המשתמשים. יצירת פרופיל של אפליקציה יכולה לעזור לזהות צווארי בקבוק ולשפר את השימוש במשאבים.
אתם יכולים להשתמש בכלים שמאפשרים לפתור בעיות ביעילות ולבצע אופטימיזציה של הרשת. משתמשים ב-Google Cloud Observability כדי לזהות אזורים שבהם יש צריכה גבוהה של CPU, זיכרון או רוחב פס. היכולות האלה יכולות לעזור למפתחים לשפר את היעילות, להפחית את העלויות ולשדרג את חוויית המשתמש. ב-Network Intelligence Center מוצגת המחשה חזותית של הטופולוגיה של תשתית הרשת, שיכולה לעזור לכם לזהות נתיבים עם זמן אחזור ארוך.
תמריצים לשיפור מתמיד
צריך ליצור תרבות של שיפור מתמיד שיכולה להועיל גם לאפליקציה וגם לחוויית המשתמש.
תספקו לעובדים שלכם הזדמנויות להדרכה ולפיתוח שישפרו את הכישורים והידע שלהם בטכניקות לשיפור הביצועים בשירותי ענן. הקימו קהילת פרקטיקה (CoP) והציעו תוכניות חונכות ואימון כדי לתמוך בצמיחת העובדים.
כדי למנוע ניהול ביצועים תגובתי ולעודד ניהול ביצועים פרואקטיבי, עודדו משוב מתמשך מהעובדים, מהלקוחות ומבעלי העניין שלכם. אפשר להפוך את התהליך למשחק: לעקוב אחרי מדדי KPI של ביצועים ולהציג את המדדים האלה לצוותים לעיתים קרובות בצורת טבלת ליגה.
כדי להבין את הביצועים שלכם ואת שביעות הרצון של המשתמשים לאורך זמן, מומלץ למדוד את המשוב של המשתמשים באופן כמותי ואיכותי. המסגרת HEART יכולה לעזור לכם לקבל משוב מהמשתמשים בחמש קטגוריות:
- שמחה
- מעורבות
- הטמעה
- שמירה
- הצלחת המשימה
שימוש במסגרת כזו מאפשר לתמרץ מהנדסים באמצעות משוב מבוסס-נתונים, מדדים שמתמקדים במשתמשים, תובנות פרקטיות והבנה ברורה של היעדים.