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

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

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

מה תלמדו

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

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

הדרישות

• יש לכם שילוב עם Google Home Cloud

הגדרה

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

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

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

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

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

1. שיעור ההצלחה הגלובלי: שיעור ההצלחה הכולל של השיחות בין השותף ל-Google צריך להיות ‎99.5%‎ ומעלה.
   הערה: אם שיעור ההצלחה הגלובלי לא עומד בדרישה (‎99.5%‎ ומעלה), הפרויקט כולו יקבל באופן אוטומטי דירוג נמוך, בלי קשר לביצועים של כל מכשיר בנפרד.
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. זמן האחזור של התגובה: זמני האחזור של שאילתות וביצועים נמדדים גם ברמת סוג המכשיר. זמן אחזור של ‎<=1000ms לכל סוג מכשיר מבטיח שהמשתמש לא יצטרך לחכות יותר מדי זמן עד שיגיע לפעולה הרצויה (למשל, לחכות כמה שניות עד שהאור ייכבה).
4. תקינות מצב: מדד הדיוק של המצב שמאוחסן במערכות של Google ומשמש כדי להחזיר תשובות לשאילתות של משתמשים. אם המספרים האלה נמוכים, יכול להיות שהמשתמשים יראו תוצאות שגויות לגבי המכשירים שלכם כשהם יסתכלו על המצב של המכשיר או ישתמשו בתכונות מבוססות-AI כמו Ask Home. יכול להיות שהאוטומציות לא יופעלו והערכים בהיסטוריה לא יופיעו בכרטיסיית הפעילות בזמן הנכון.

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

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

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

מקרא

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

דוגמה

בדוגמה שלמטה אפשר לראות שסוג המכשיר 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 בניפוי באגים: אימות של Cloud Calls

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

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

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

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

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

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

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

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

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

שלב 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 לבין דוח סטטוס. אפשר להשתמש בתרשימים שלמטה כדי לעקוב אחרי סוגי המכשירים והמאפיינים שבהם יש אי התאמה בין התשובות של שאילתת QUERY לבין התשובות של דוח הסטטוס.

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

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