העיקרון הזה ב-Google Cloud Well-Architected Framework כולל המלצות לאופטימיזציה של ביצועי עומסי עבודה ב-Google Cloud.
המסמך הזה מיועד לארכיטקטים, למפתחים ולאדמינים שמתכננים, מעצבים, פורסים ומנהלים עומסי עבודה ב- Google Cloud.
ההמלצות בקטגוריה הזו יכולות לעזור לארגון שלכם לפעול ביעילות, לשפר את שביעות רצון הלקוחות, להגדיל את ההכנסות ולהפחית את העלויות. לדוגמה, כשזמן העיבוד של אפליקציה בשרת העורפי מתקצר, המשתמשים נהנים מזמני תגובה מהירים יותר, מה שיכול להוביל לשיעור גבוה יותר של שימור משתמשים ולהגדלת ההכנסות.
תהליך האופטימיזציה של הביצועים יכול לכלול פשרה בין ביצועים לעלות. עם זאת, אופטימיזציה של הביצועים יכולה לעזור לכם לפעמים להפחית את העלויות. לדוגמה, כשהעומס גדל, התאמה אוטומטית לעומס יכולה לעזור לספק ביצועים צפויים על ידי הבטחה שלא יהיה עומס יתר על משאבי המערכת. התאמה אוטומטית לעומס גם עוזרת לכם לצמצם עלויות על ידי הסרת משאבים לא בשימוש בתקופות של עומס נמוך.
אופטימיזציה של הביצועים היא תהליך מתמשך, ולא פעילות חד-פעמית. בתרשים הבא מוצגים השלבים בתהליך האופטימיזציה של הביצועים:
תהליך האופטימיזציה של הביצועים הוא מחזור מתמשך שכולל את השלבים הבאים:
- הגדרת דרישות: לפני שמתכננים ומפתחים את האפליקציות, מגדירים דרישות ביצועים מפורטות לכל שכבה במערך האפליקציות. כדי לתכנן את הקצאת המשאבים, כדאי לקחת בחשבון את המאפיינים העיקריים של עומס העבודה ואת ציפיות הביצועים.
- תכנון ופריסה: שימוש בדפוסי עיצוב גמישים וניתנים להרחבה שיכולים לעזור לכם לעמוד בדרישות הביצועים.
- מעקב וניתוח: מעקב רציף אחרי הביצועים באמצעות יומנים, מעקב, מדדים והתראות.
אופטימיזציה: כדאי לשקול עיצובים מחדש ככל שהאפליקציות מתפתחות. התאמת משאבי הענן לצרכים ושימוש בתכונות חדשות כדי לעמוד בדרישות משתנות של ביצועים.
כפי שמוצג בתרשים הקודם, ממשיכים במחזור של מעקב, הערכה מחדש של הדרישות והתאמה של משאבי הענן.
עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ולמידת מכונה מפורטים במאמר AI and ML perspective: Performance optimization ב-Well-Architected Framework.
עקרונות ליבה
ההמלצות בעמודה 'אופטימיזציה של הביצועים' ב-Well-Architected Framework ממופות לעקרונות הליבה הבאים:
שותפים ביצירת התוכן
מחברים:
- Daniel Lees | Cloud Security Architect
- גארי הרמסון (Gary Harmson) | אדריכל ראשי
- Luis Urena | Developer Relations Engineer
- Zach Seils | מומחה לרשתות
תורמי תוכן אחרים:
- Filipe Gracio, PhD | Customer Engineer, AI/ML Specialist
- חוזה אנדרדה | Customer Engineer, SRE Specialist
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Marwan Al Shawi | Partner Customer Engineer
- ניקולס פינטו (Nicolas Pintaux) | Customer Engineer, Application Modernization Specialist
- ריאן קוקס (Ryan Cox) | אדריכל ראשי
- ראדיקה קאנאקאם | מובילת תוכנית, Google Cloud Well-Architected Framework
- Samantha He | Technical Writer
- Wade Holmes | Global Solutions Director
תכנון הקצאת משאבים
העיקרון הזה הוא חלק מההמלצות לשיפור הביצועים ב-Google Cloud Well-Architected Framework, והוא מספק המלצות שיעזרו לכם לתכנן את המשאבים של עומסי העבודה ב-Google Cloud. הוא מדגיש את החשיבות של הגדרת דרישות מפורטות לפני שתתכננו ותפתחו אפליקציות לפריסה או להעברה בענן.
סקירה כללית של העקרונות
כדי לעמוד בדרישות העסקיות שלכם, חשוב להגדיר את דרישות הביצועים של האפליקציות לפני העיצוב והפיתוח. הגדירו את הדרישות האלה בצורה מפורטת ככל האפשר עבור האפליקציה כולה ועבור כל שכבה במערך האפליקציה. לדוגמה, בשכבת האחסון, צריך לקחת בחשבון את קצב העברת הנתונים ואת פעולות הקלט/פלט לשנייה (IOPS) שהאפליקציות צריכות.
כבר מההתחלה, חשוב לתכנן את עיצוב האפליקציה תוך התחשבות בביצועים ובמדרגיות. כדאי להביא בחשבון גורמים כמו מספר המשתמשים, נפח הנתונים ופוטנציאל הצמיחה לאורך זמן.
דרישות הביצועים משתנות בהתאם לעומס העבודה ולסוג עומס העבודה. כל עומס עבודה יכול להכיל שילוב של מערכות ורכיבים שונים עם מאפייני ביצועים ייחודיים. לדוגמה, מערכת שאחראית לעיבוד ברצף (batch processing) תקופתי של קבוצות נתונים גדולות, שונה מדרישות הביצועים של פתרון מחשב וירטואלי אינטראקטיבי. שיטות האופטימיזציה צריכות להתייחס לצרכים הספציפיים של כל עומס עבודה.
בוחרים שירותים ותכונות שתואמים ליעדי הביצועים של כל עומס עבודה. אין פתרון אחד שמתאים לכולם כשמדובר באופטימיזציה של הביצועים. כשמבצעים אופטימיזציה של כל עומס עבודה, המערכת כולה יכולה להשיג ביצועים ויעילות אופטימליים.
כדאי להביא בחשבון את המאפיינים הבאים של עומס העבודה, שיכולים להשפיע על דרישות הביצועים:
- ארכיטיפ פריסה: ארכיטיפ הפריסה שבחרתם לאפליקציה יכול להשפיע על הבחירה שלכם במוצרים ובתכונות, ובהמשך על הביצועים שאתם יכולים לצפות מהאפליקציה.
- מיקום המשאבים: כשבוחרים Google Cloud אזור למשאבי האפליקציה, מומלץ לתת עדיפות לזמן אחזור נמוך עבור משתמשי הקצה, לפעול בהתאם לתקנות בנושא מיקום הנתונים ולוודא שהמוצרים והשירותים הנדרשים זמינים. Google Cloud
- קישוריות לרשת: בוחרים שירותי רשת שמבצעים אופטימיזציה של הגישה לנתונים ושל העברת התוכן. כדאי לנצל את הרשת הגלובלית של Google Cloud, את רשתות הליבה המהירות, את מיקומי הקישוריות ואת שירותי שמירת הנתונים במטמון.
- אפשרויות לאירוח אפליקציות: כשבוחרים פלטפורמת אירוח, צריך להעריך את היתרונות והחסרונות של כל אפשרות מבחינת הביצועים. לדוגמה, נניח שיש פלטפורמות bare metal, מכונות וירטואליות, קונטיינרים ופלטפורמות ללא שרת (serverless).
- אסטרטגיית אחסון: חשוב לבחור אסטרטגיית אחסון אופטימלית על סמך דרישות הביצועים.
- הגדרות משאבים: סוג המכונה, IOPS וקצב העברת הנתונים יכולים להשפיע באופן משמעותי על הביצועים. בנוסף, בשלב מוקדם בתהליך התכנון, צריך לקחת בחשבון את יכולות האבטחה המתאימות ואת ההשפעה שלהן על המשאבים. כשמתכננים תכונות אבטחה, חשוב להיות מוכנים להתפשר על הביצועים כדי להימנע מהשלכות בלתי צפויות.
המלצות
כדי להקצות משאבים בצורה אופטימלית, כדאי לעיין בהמלצות שבקטעים הבאים.
הגדרה וניהול של מכסות
חשוב לוודא שהאפליקציה משתמשת רק במשאבים הדרושים, כמו זיכרון, אחסון וכוח עיבוד. הקצאת יתר עלולה להוביל להוצאות מיותרות, והקצאת חסר עלולה לגרום לירידה בביצועים.
כדי לאפשר שינוי גודל דינמי ולהבטיח שיש מספיק משאבים, חשוב לעקוב באופן קבוע אחרי הקיבולת של המכסות. בנוסף, כדאי לעקוב אחרי השימוש במכסת נפח האחסון כדי לזהות מגבלות פוטנציאליות על ההרחבה או בעיות בהקצאת יתר, ואז לקבל החלטות מושכלות לגבי הקצאת משאבים.
ללמד ולהגביר את המודעות
כדאי ליידע את המשתמשים לגבי דרישות הביצועים ולספק להם מקורות מידע לימודיים על טכניקות יעילות לניהול ביצועים.
כדי להעריך את ההתקדמות ולזהות תחומים לשיפור, כדאי לתעד באופן קבוע את ביצועי היעד ואת הביצועים בפועל. מבצעים בדיקת עומס באפליקציה כדי למצוא נקודות עצירה פוטנציאליות ולהבין איך אפשר להרחיב את האפליקציה.
מעקב אחר מדדי ביצועים
אתם יכולים להשתמש ב-Cloud Monitoring כדי לנתח מגמות במדדי הביצועים, לנתח את ההשפעות של ניסויים, להגדיר התראות למדדים קריטיים ולבצע ניתוחים רטרוספקטיביים.
Active Assist הוא קבוצה של כלים שיכולים לספק תובנות והמלצות שיעזרו לכם לייעל את השימוש במשאבים. ההמלצות האלה יכולות לעזור לכם להתאים את הקצאת המשאבים ולשפר את הביצועים.
ניצול הגמישות
העיקרון הזה הוא חלק מעמודת האופטימיזציה של הביצועים ב-Google Cloud Well-Architected Framework. הוא כולל המלצות שיעזרו לכם לשלב גמישות, כלומר היכולת להתאים את המשאבים באופן דינמי על סמך שינויים בדרישות של עומס העבודה.
גמישות מאפשרת לרכיבים שונים במערכת להתרחב באופן עצמאי. התאמת המשאבים לצרכים הספציפיים יכולה לעזור לשפר את הביצועים ולחסוך בעלויות, כי המערכת מקצה משאבים בדיוק במקומות שבהם הם נדרשים, בלי להקצות יותר מדי משאבים או פחות מדי משאבים.
סקירה כללית של העקרונות
דרישות הביצועים של מערכת משפיעות ישירות על מתי ואיך המערכת תבצע קנה מידה אנכי או קנה מידה אופקי. צריך להעריך את הקיבולת של המערכת ולקבוע את העומס שהמערכת צפויה לטפל בו כבסיס. לאחר מכן, צריך להגדיר איך המערכת תגיב לעלייה או לירידה בעומס.
כשהעומס גדל, המערכת צריכה להרחיב את הקיבולת שלה באופן אופקי, להגדיל את הקיבולת שלה באופן אנכי או לבצע את שתי הפעולות. כדי לבצע הרחבה אופקית, מוסיפים צמתים משוכפלים כדי לוודא שלמערכת יש מספיק קיבולת כוללת כדי לעמוד בביקוש המוגבר. במקרה של הרחבה אנכית, מחליפים את הרכיבים הקיימים באפליקציה ברכיבים עם קיבולת גדולה יותר, יותר זיכרון ויותר נפח אחסון.
כשהעומס יורד, המערכת צריכה להקטין את קנה המידה (אופקית, אנכית או גם וגם).
מגדירים את הנסיבות שבהן המערכת תבצע הגדלה או הקטנה של הקיבולת. תכננו להגדיל את הקיבולת של המערכות באופן ידני בתקופות ידועות של עומס תנועה גבוה. אפשר להשתמש בכלים כמו התאמה אוטומטית לעומס (automatic scaling), שמגיב לעלייה או לירידה בעומס.
המלצות
כדי לנצל את הגמישות, כדאי לעיין בהמלצות שבקטעים הבאים.
תכנון לתקופות של עומס שיא
צריך לתכנן נתיב יעיל להרחבת הקיבולת לאירועים ידועים, כמו תקופות צפויות של עלייה בביקוש מצד הלקוחות.
כדאי לשקול להגדיל את הקיבולת של המערכת לקראת תקופות ידועות של עומס גבוה. לדוגמה, אם אתם ארגון קמעונאי, אתם מצפים שהביקוש יעלה במהלך מבצעים עונתיים. מומלץ להרחיב אנכית או אופקית את המערכות באופן ידני לפני המכירות האלה, כדי לוודא שהמערכת תוכל להתמודד באופן מיידי עם העומס המוגבר או להתאים באופן מיידי את המגבלות הקיימות. אחרת, יכול להיות שיחלפו כמה דקות עד שהמערכת תוסיף משאבים בתגובה לשינויים בזמן אמת. יכול להיות שהקיבולת של האפליקציה לא תגדל מספיק מהר, ולכן חלק מהמשתמשים יחוו עיכובים.
במקרה של אירועים לא ידועים או לא צפויים, כמו עלייה פתאומית בביקוש או בתעבורה, אפשר להשתמש בתכונות של התאמה אוטומטית לעומס כדי להפעיל התאמה דינמית לעומס שמבוססת על מדדים. המדדים האלה יכולים לכלול את ניצול המעבד, קיבולת ההגשה של מאזן העומסים, זמן האחזור ואפילו מדדים מותאמים אישית שאתם מגדירים ב-Cloud Monitoring.
לדוגמה, נניח שיש אפליקציה שפועלת בקבוצת מופעי מכונה מנוהלים (MIG) של Compute Engine. האפליקציה הזו דורשת שכל מופע יפעל בצורה אופטימלית עד שהשימוש הממוצע במעבד יגיע ל-75%. בדוגמה הזו, אפשר להגדיר מדיניות של התאמה אוטומטית לעומס שיוצרת עוד מכונות כשניצול המעבד (CPU) מגיע לסף. המופעים החדשים שנוצרו עוזרים לספוג את העומס, וכך לוודא שהשימוש הממוצע במעבד יישאר בשיעור אופטימלי עד שיגיע למספר המקסימלי של מופעים שהגדרתם עבור ה-MIG. כשהביקוש יורד, מדיניות שינוי הגודל האוטומטי מסירה את המופעים שכבר לא נדרשים.
אפשר לתכנן מקומות שמורים של יחידות קיבולת ב-BigQuery או לשנות את המגבלות של הגדרות התאמה אוטומטית לעומס ב-Spanner באמצעות המידרוג האוטומטי המנוהל.
שימוש בהתאמת גודל חזויה
אם רכיבי המערכת שלכם כוללים Compute Engine, אתם צריכים להעריך אם שינוי גודל אוטומטי (autoscaling) מבוסס-תחזית מתאים לעומס העבודה שלכם. תכונת ההתאמה האוטומטית לעומס על סמך חיזוי חוזה את העומס העתידי על סמך המגמות ההיסטוריות של המדדים שלכם – למשל, ניצול המעבד. התחזיות מחושבות מחדש כל כמה דקות, כך שהתאמת הגודל האוטומטית מתאימה במהירות את התחזית שלה לשינויים האחרונים בעומס. בלי התאמה אוטומטית לעומס מבוססת-חיזוי, מידרוג אוטומטי יכול לשנות את הגודל של קבוצה רק באופן תגובתי, על סמך שינויים בזמן אמת בעומס. התכונה 'שינוי גודל אוטומטי מבוסס תחזיות' פועלת עם נתונים בזמן אמת ועם נתונים היסטוריים כדי לתת מענה לעומס הנוכחי ולעומס הצפוי.
הטמעה של ארכיטקטורות ללא שרת (serverless)
כדאי להטמיע ארכיטקטורה בלי שרת (serverless) עם שירותים בלי שרת (serverless) שהם גמישים מטבעם, כמו השירותים הבאים:
בניגוד לשינוי גודל אוטומטי בשירותים אחרים שדורשים כוונון עדין של כללים (לדוגמה, Compute Engine), שינוי הגודל האוטומטי ב-serverless הוא מיידי, ויכול להקטין את מספר המשאבים לאפס.
שימוש במצב Autopilot ב-Kubernetes
לאפליקציות מורכבות שדורשות שליטה רבה יותר ב-Kubernetes, כדאי לשקול מצב Autopilot ב-Google Kubernetes Engine (GKE). מצב אוטומטי מספק אוטומציה וגמישות כברירת מחדל. GKE משנה את גודל הצמתים והמשאבים באופן אוטומטי על סמך התנועה. מערכת GKE מנהלת את הצמתים, יוצרת צמתים חדשים לאפליקציות שלכם ומגדירה שדרוגים ותיקונים אוטומטיים.
קידום עיצוב מודולרי
העיקרון הזה, שמופיע ב-Google Cloud Well-Architected Framework (מסגרת ארכיטקטורה מתוכננת היטב) בקטע בנושא אופטימיזציה של הביצועים, כולל המלצות שיעזרו לכם לקדם עיצוב מודולרי. רכיבים מודולריים וממשקים ברורים יכולים לאפשר שינוי גודל גמיש, עדכונים עצמאיים והפרדה עתידית של רכיבים.
סקירה כללית של העקרונות
להבין את יחסי התלות בין רכיבי האפליקציה לרכיבי המערכת כדי לעצב מערכת ניתנת להרחבה.
עיצוב מודולרי מאפשר גמישות וחוסן (resilience), בלי קשר לארכיטקטורה המונוליטית או למיקרו-שירותים (microservice) שנפרסו בהתחלה. פירוק המערכת למודולים עצמאיים ומוגדרים היטב עם ממשקים ברורים מאפשר לכם לשנות את גודל הרכיבים בהתאם לצרכים הספציפיים.
התאמת קנה המידה לטירגוט יכולה לעזור לכם לבצע אופטימיזציה של ניצול המשאבים ולהפחית את העלויות בדרכים הבאות:
- הוא מקצה רק את המשאבים הדרושים לכל רכיב, ומקצה פחות משאבים לרכיבים שדורשים פחות.
- המערכת מוסיפה עוד משאבים בתקופות של תנועה גבוהה כדי לשמור על חוויית המשתמש.
- הכלי מסיר משאבים שלא מנוצלים מספיק בלי לפגוע בביצועים.
המודולריות גם משפרת את יכולת התחזוקה. יחידות קטנות ועצמאיות קלות יותר להבנה, לניפוי באגים ולעדכון, מה שיכול להוביל למחזורי פיתוח מהירים יותר ולסיכון מופחת.
למודולריות יש יתרונות משמעותיים, אבל חשוב להעריך את הפשרות הפוטנציאליות בביצועים. התקשורת המוגברת בין המודולים עלולה לגרום לזמן אחזור ולתקורה. חשוב לשאוף לאיזון בין מודולריות לבין ביצועים. יכול להיות שעיצוב מודולרי מאוד לא יתאים לכל המקרים. אם הביצועים הם קריטיים, יכול להיות שגישה עם צימוד הדוק יותר תתאים יותר. עיצוב מערכת הוא תהליך איטרטיבי שבו בודקים ומשפרים באופן רציף את העיצוב המודולרי.
המלצות
כדי לקדם עיצובים מודולריים, כדאי לעיין בהמלצות שבקטעים הבאים.
תכנון לצימוד חלש
תכנון של ארכיטקטורה בצימוד חלש. רכיבים עצמאיים עם תלות מינימלית יכולים לעזור לכם לבנות אפליקציות גמישות ועמידות. כשמתכננים את הגבולות של השירותים, צריך לקחת בחשבון את דרישות הזמינות והמדרגיות. לדוגמה, אם לרכיב אחד יש דרישות שונות מהרכיבים האחרים, אפשר לעצב את הרכיב כשירות עצמאי. צריך להטמיע תוכנית לטיפול בבעיות שמתרחשות בתהליכי משנה או בשירותים פחות חשובים שלא משפיעים על זמן התגובה של השירותים העיקריים.
תכנון של פעולות בו-זמניות ומקבילות
תכננו את האפליקציה כך שתתמוך בכמה משימות במקביל, כמו עיבוד של כמה בקשות משתמשים או הפעלה של משימות ברקע בזמן שהמשתמשים יוצרים אינטראקציה עם המערכת. לחלק משימות גדולות לחלקים קטנים יותר שאפשר לעבד בו-זמנית בכמה מופעים של שירות. התכונה 'מקביליות משימות' מאפשרת להשתמש בתכונות כמו שינוי גודל אוטומטי כדי להגדיל את הקצאת המשאבים במוצרים כמו:
איזון המודולריות להקצאת משאבים גמישה
במידת האפשר, צריך לוודא שכל רכיב משתמש רק במשאבים הדרושים (כמו זיכרון, אחסון וכוח עיבוד) לפעולות ספציפיות. הקצאת יתר של משאבים עלולה לגרום לעלויות מיותרות, והקצאת חסר של משאבים עלולה לפגוע בביצועים.
שימוש בממשקים מוגדרים היטב
חשוב לוודא שהרכיבים המודולריים מתקשרים ביעילות באמצעות ממשקים ברורים וסטנדרטיים (כמו ממשקי API ותורי הודעות) כדי להפחית את התקורה משכבות התרגום או מתנועה חיצונית.
שימוש במודלים חסרי מצב
מודל חסר מצב יכול לעזור לכם לוודא שתוכלו לטפל בכל בקשה או אינטראקציה עם השירות באופן עצמאי, ללא תלות בבקשות קודמות. המודל הזה מאפשר הרחבה ושחזור, כי אפשר להגדיל או להקטין את השירות או להפעיל אותו מחדש בלי לאבד את הנתונים שנדרשים לבקשות או לתהליכים שנמצאים בעיבוד.
בחירת טכנולוגיות משלימות
בחרו טכנולוגיות שמשלימות את העיצוב המודולרי. להעריך שפות תכנות, מסגרות ונתונים כדי לבדוק אם הם תומכים במודולריות.
מידע נוסף זמין במקורות המידע הבאים:
מעקב רציף אחרי הביצועים ושיפור שלהם
העיקרון הזה הוא חלק מההמלצות לשיפור הביצועים בGoogle Cloud Well-Architected Framework, והוא מספק המלצות שיעזרו לכם לעקוב אחרי הביצועים ולשפר אותם באופן שוטף.
אחרי שפורסים אפליקציות, צריך לעקוב אחרי הביצועים שלהן באופן רציף באמצעות יומנים, מעקב, מדדים והתראות. ככל שהאפליקציות שלכם יגדלו ויתפתחו, תוכלו להשתמש במגמות בנקודות הנתונים האלה כדי להעריך מחדש את דרישות הביצועים שלכם. יכול להיות שבסופו של דבר תצטרכו לעצב מחדש חלקים מהאפליקציות כדי לשמור על הביצועים שלהן או לשפר אותם.
סקירה כללית של העקרונות
תהליך השיפור המתמשך של הביצועים מחייב שימוש בכלים ובאסטרטגיות חזקים לניטור. כלים למעקב אחרי נראות ב-Cloud יכולים לעזור לכם לאסוף מדדי ביצועים מרכזיים (KPI) כמו זמן אחזור, קצב העברת נתונים, שיעורי שגיאות וניצול משאבים. סביבות ענן מציעות מגוון שיטות לביצוע הערכות מפורטות של הביצועים ברמת האפליקציה, הרשת וחוויית המשתמש.
שיפור הביצועים הוא מאמץ מתמשך שדורש גישה רב-פנים. המנגנונים והתהליכים העיקריים הבאים יכולים לעזור לכם לשפר את הביצועים:
- כדי לספק כיוון ברור ולעקוב אחרי ההתקדמות, כדאי להגדיר יעדי ביצועים שתואמים ליעדים העסקיים שלכם. מומלץ להגדיר יעדים חכמים: ספציפיים, ניתנים למדידה, ניתנים להשגה, רלוונטיים ומוגבלים בזמן.
- כדי למדוד את הביצועים ולזהות תחומים לשיפור, כדאי לאסוף מדדים של KPI.
- כדי לעקוב באופן רציף אחרי המערכות שלכם ולזהות בעיות, אפשר להשתמש בתהליכי עבודה חזותיים בכלי מעקב. משתמשים בטכניקות למיפוי תהליכים של ארכיטקטורה כדי לזהות כפילויות וחוסר יעילות.
- כדי ליצור תרבות של שיפור מתמשך, כדאי לספק הדרכות ותוכניות שתומכות בצמיחה של העובדים.
- כדי לעודד שיפור יזום ומתמשך, כדאי לתת תמריצים לעובדים וללקוחות כדי שיספקו משוב שוטף על הביצועים של האפליקציה.
המלצות
כדי לקדם עיצובים מודולריים, כדאי לעיין בהמלצות שבקטעים הבאים.
הגדרת מדדים ויעדים ברורים לביצועים
הגדירו יעדי ביצועים ברורים שתואמים ליעדים העסקיים שלכם. כדי לעשות את זה, צריך להבין לעומק את ארכיטקטורת האפליקציה ואת דרישות הביצועים של כל רכיב באפליקציה.
כדאי לתת עדיפות לאופטימיזציה של הרכיבים החשובים ביותר שמשפיעים ישירות על הפונקציות העסקיות העיקריות ועל חוויית המשתמש. כדי לוודא שהרכיבים האלה ימשיכו לפעול ביעילות ויענו על הצרכים העסקיים שלכם, כדאי להגדיר יעדי ביצועים ספציפיים ומדידים. היעדים האלה יכולים לכלול זמני תגובה, שיעורי שגיאות וסף לניצול משאבים.
הגישה הפרואקטיבית הזו יכולה לעזור לכם לזהות צווארי בקבוק פוטנציאליים ולטפל בהם, לבצע אופטימיזציה של הקצאת המשאבים ובסופו של דבר לספק למשתמשים חוויה חלקה ואיכותית.
מעקב אחר הביצועים
חשוב לעקוב באופן רציף אחרי מערכות הענן כדי לזהות בעיות בביצועים ולהגדיר התראות לבעיות פוטנציאליות. מעקב והתראות יכולים לעזור לכם לזהות ולתקן בעיות לפני שהן משפיעות על המשתמשים. פרופיל האפליקציה יכול לעזור לזהות צווארי בקבוק ולשפר את השימוש במשאבים.
אתם יכולים להשתמש בכלים שמסייעים לפתור בעיות ביעילות ולבצע אופטימיזציה של הרשת. משתמשים ב-Google Cloud Observability כדי לזהות אזורים שבהם יש צריכה גבוהה של CPU, זיכרון או רוחב פס. היכולות האלה יכולות לעזור למפתחים לשפר את היעילות, להפחית עלויות ולשפר את חוויית המשתמש. Network Intelligence Center מציג תרשימים של טופולוגיית תשתית הרשת, ויכול לעזור לכם לזהות נתיבים עם זמן אחזור גבוה.
תמריצים לשיפור מתמיד
צריך ליצור תרבות של שיפור מתמיד שיכולה להועיל גם לאפליקציה וגם לחוויית המשתמש.
תספקו לעובדים הזדמנויות להדרכה ולפיתוח שישפרו את הכישורים והידע שלהם בטכניקות לשיפור הביצועים בשירותי ענן. להקים קהילת למידה (CoP) ולהציע תוכניות ליווי ואימון כדי לתמוך בצמיחה של העובדים.
כדי למנוע ניהול ביצועים ריאקטיבי ולעודד ניהול ביצועים פרואקטיבי, כדאי לעודד קבלת משוב מתמשך מהעובדים, מהלקוחות ומהגורמים הרלוונטיים. אפשר להפוך את התהליך למשחק על ידי מעקב אחרי מדדי ביצועים מרכזיים (KPI) והצגת המדדים האלה לצוותים בתדירות גבוהה בצורה של טבלת ליגה.
כדי להבין את הביצועים ואת שביעות הרצון של המשתמשים לאורך זמן, מומלץ למדוד את המשוב של המשתמשים באופן כמותי ואיכותי. המסגרת HEART יכולה לעזור לכם לקבל משוב מהמשתמשים בחמש קטגוריות:
- שמחה
- מעורבות
- הטמעה
- שמירה
- הצלחת המשימה
שימוש במסגרת כזו מאפשר לתת למהנדסים תמריצים באמצעות משוב מבוסס-נתונים, מדדים שמתמקדים במשתמשים, תובנות פרקטיות והבנה ברורה של היעדים.