איך מודדים את איכות המוצרים במרכז השליטה של תפקוד האפליקציה ב-Google Home

1. לפני שמתחילים

ה-Codelab הזה מיועד לשותפים ולמפתחים של Google Home עם שילובי Cloud, כדי לשפר את איכות הסביבה העסקית ואת חוויית המשתמש.

מה תלמדו

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

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

הדרישות

• יש לכם שילוב עם הענן של Google Home

הגדרה

כדי להגיע ללוח הבקרה של Google Home Vitals:

1. פתיחה של Google Cloud Platform
2. מעקב > מרכז שליטה
3. לוחצים על לוח הבקרה Google Home Vitals (Cloud)

2. הסבר על מרכז הבקרה

חישוב ציון האיכות – סטנדרט 'טוב' לעומת 'גרוע'

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

1. שיעור ההצלחה הכולל: שיעור ההצלחה הכולל של השיחות בין השותף ל-Google צריך להיות ‎99.5%‎ ומעלה.
   הערה: אם שיעור ההצלחה הכולל נמוך מ-‎99.5%‎, הפרויקט כולו יקבל באופן אוטומטי את הדירוג POOR, ללא קשר לביצועים של כל מכשיר בנפרד.
2. מהימנות הפקודות: שיעורי ההצלחה של פקודות QUERY ו-EXECUTE צריכים להיות ‎99.5% או יותר לכל סוג מכשיר.
3. זמן אחזור מהיר: זמן האחזור באחוזון ה-90 עבור שאילתות וביצועים צריך להיות ‎ <=1000ms לכל סוג מכשיר.
4. שלמות המדינה: מידת הדיוק של המדינה צריכה להיות 99.5% ומעלה.

למה המדדים האלה חשובים

1. שיעור ההצלחה הגלובלי: מדד שבודק את תקינות הקריאות מהענן שלכם אל Google ברמת השילוב. שיעור הצלחה של ‎99.5% ‎ ומעלה מבטיח ש-Google Home ישתמש בסטטוסים הנכונים של המכשירים. לדוגמה, לוודא שהמכשירים מתווספים ומוסרים, שהאוטומציות מופעלות ושאירועי ההיסטוריה מופיעים בכרטיסייה 'פעילות' באפליקציית Google Home.
2. אמינות הפקודות: שיעורי ההצלחה של QUERY ו-EXECUTE נמדדים ברמת סוג המכשיר.שיעור הצלחה של ‎99.5% ‎ ומעלה מבטיח שהפקודות של המשתמש יבוצעו בצורה נכונה (כלומר, נמנעות תשובות של Assistant כמו "אין לי גישה למכשיר" או אישור שגוי של פקודה שלא בוצעה).
3. זמן האחזור של התגובה: זמני האחזור של QUERY ו-EXECUTE נמדדים גם ברמת סוג המכשיר. זמן אחזור של ‎<=1000ms לכל סוג מכשיר מבטיח שהמשתמש לא יצטרך לחכות יותר מדי זמן עד שיגיע לפעולה הרצויה (למשל, לחכות כמה שניות עד שהאור ייכבה).
4. ‫State Integrity: מדד שבודק את הדיוק של המצב שמאוחסן במערכות של Google ומשמש כדי להחזיר תשובות לשאילתות של משתמשים. אם המספרים האלה נמוכים, יכול להיות שהמשתמשים יראו תוצאות שגויות לגבי המכשירים שלכם כשהם יסתכלו על המצב של המכשיר או ישתמשו בתכונות מבוססות-AI כמו Ask Home. יכול להיות שהאוטומציות לא יופעלו והערכים בהיסטוריה לא יופיעו בכרטיסיית הפעילות בזמן הנכון.

הסבר על מרכז הבקרה

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

בקטע 'ציון מדדי האיכות' בחלק העליון של לוח הבקרה Google Home Vitals מוצגים המדדים שמשמשים לחישוב ציון האיכות של השילוב.

מקרא

• ירוק (טוב): המדד עומד בסף האיכות.
• אדום (נמוך): המדד לא עומד בסף האיכות.

דוגמה

בדוגמה שלמטה אפשר לראות שסוג המכשיר AC_UNIT עומד בקריטריונים של האיכות בשיעור ההצלחה של שאילתות וביצועים, וגם בקטע 'זמן האחזור של שאילתות', אבל לא עומד בדרישות של סרגל זמן האחזור של הביצוע (אדום). המשמעות היא שהפקודות מצליחות בשיעור שעובר, אבל זמן האחזור של EXECUTE איטי מדי ב-36ms. בקטע System Health (תקינות המערכת) מוצג שיעור של 98.92% של שיטות מצטברות שנכשלו באינטגרציה, מה שאומר שיש מקום לשיפור כדי להבטיח את הדיוק של מצבי המכשירים של המשתמשים ב-Google Home. המשמעות היא ש-1.08% מהשיחות (DeleteAgentUser, ‏ Query, ‏ ReportStateAndNotification, ‏ RequestSyncDevices או Sync) מחזירות קודי תגובה שלא שווים ל-2xx או ל-5xx (למשל, שגיאות 404). המדד האחרון שמשמש למדידת איכות של מעבר או כשל עבור סוג המכשיר AC_UNIT הוא דיוק המצב. בדוגמה הזו, שיעור ההצלחה הוא 77.43%, כלומר סביר שהמשתמשים יראו תוצאות לא מדויקות לגבי המכשירים. שלושת המדדים האלה מצביעים על כך שהציון הכולל של AC_UNIT הוא POOR (נמוך) ומתחת לסף האיכות.

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

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

כדי לנפות באגים בשיעורי ההצלחה של שיחות מ-Partner אל Google, עוברים אל 'שלב 2: אימות שיחות אל Google'.

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

3. שלב 1 בניפוי באגים: אימות של שיחות בענן

שלב 1: סקירה כללית

החלק הזה מתמקד בשיחות בענן – המדדים שבודקים את תקינות התקשורת מ-Google אל הבק אנד בענן (נקראים גם מדדים של Google אל השותף). זה כולל פקודות כמו Query ו-Execute.

אנחנו עוקבים אחרי שיעורי ההצלחה וההשהיות של QUERY ו-EXECUTE (שמשפיעים על ציוני האיכות של סוג המכשיר).

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

בשלבים 1א ו-1ב מוצג מגמת מספר בקשות הביצוע, מספר השגיאות לאורך זמן וסטטוסים ספציפיים של שגיאות.

שלב 1א: בדיקת שגיאות בשאילתות

שלב 1ב: בדיקת שגיאות ההפעלה

בשלבים 1c ו-1d מוצג פירוט של האחוזון ה-90 והאחוזון ה-50 של המדדים האלה, גם ברמת השילוב וגם ברמת סוג המכשיר.

שלב 1ג': בדיקת זמן האחזור של השאילתה

שלב 1ד: בדיקת זמן האחזור של ההפעלה

4. ניפוי באגים שלב 2: אימות שיחות אל Google

שלב 2: סקירה כללית

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

שלב 2א: ניפוי באגים בבעיות שקשורות למכסת נפח

‫Google Home מגבילה את הקצאת המשאבים והשימוש בהם, ומחילת מכסות מתאימות על בסיס כל פרויקט. ‫Google מחילה את מגבלת ברירת המחדל של 6,000 בקשות לכל 60 שניות על הצבירה של השאילתות, המחיקות, מצב הדוח והקריאות ל-API של בקשה לא סנכרונית, על בסיס כל שילוב בין ענן לענן.

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

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

5. ניפוי באגים שלב 3: שיפור הדיוק של המצב

שלב 3: סקירה כללית

אחרי שמבצעים את שלבי הניפוי 1 ו-2, בשלב 3 בודקים את הדיוק של Report State – מצבי המכשיר שמאוחסנים במערכות של Google, שמשמשים כדי להחזיר תשובות לשאילתות של משתמשים. בהמשך מוצגים פירוטים לפי מאפיין וסוג מכשיר. בשלבים 3א ו-3ב מוסבר על שתי שגיאות נפוצות בדוח המצב: שגיאות של שדה חסר ושגיאות של נתונים לא מדויקים.

שלב 3א: שגיאות מסוג 'שדה חסר'

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

שלב 3ב: שגיאות מסוג 'לא מדויק'

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

6. מסמכים ומשאבים אחרים

• כדי לשלוח משוב או לדווח על בעיות בלוח הבקרה הזה, אפשר לדווח על בעיה בIssue Tracker.
• כדי להגיש בקשת ערעור, צריך למלא את הטופס לערעור על מדדי איכות.
• כדי להתעדכן באופן קבוע באיכות השילוב, אפשר להגדיר התראות ב-Google Cloud Platform כדי לקבל הודעות כשהמדדים יורדים מתחת לסף קביל. כך תוכלו להיות הראשונים לדעת על בעיה שמתעוררת.
• למידע נוסף, אפשר לעיין במסמכי התיעוד של המפתח בכתובת https://developers.home.google.com/tools/analytics/home-vitals.