Google Home Vitals (Cloud)

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

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

1. ‫Google to Partner Metrics – מדד שבודק את תקינות הקריאות מ-Google אל הבק אנד בענן.

2. System Health - Partner to Google Metrics – מדד שבודק את תקינות הקריאות מהמערכת שלכם אל Google.

3. ‫Device Health - State Accuracy – מדד שבודק את הדיוק של המצבים שמאוחסנים במערכות של Google, שמשמשים כדי להחזיר תשובות לשאילתות של משתמשים.

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

אם הלחיצה על הלחצן הבא לא מעבירה אתכם ישירות ללוח הבקרה, אתם יכולים להגיע אליו על ידי בחירה בדף סקירה כללית, בחירה באפשרות לוחות בקרה ואז בחירה באפשרות לוח הבקרה של Google Home Vitals (Cloud) מתוך הרשימה לוחות הבקרה שלי.

כניסה לדף Dashboard

מדדי Google לשותף

המדד Query/Execute Success Rate >= 99.5%‎ מודד את התדירות שבה הפקודות של המשתמשים מבוצעות בצורה נכונה. המדד הזה עוזר להימנע מתשובות של Assistant כמו "אין לי גישה למכשיר" או מאישור שגוי של פקודה שלא בוצעה.

מהי ההגדרה של 'הצלחה'?

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

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

מהי הגדרת הסטטוס 'כשל'?

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

חריגות שקשורות לכשלים
aboveMaximumLightEffectsDuration	armLevelNeeded	inOffMode
alreadyArmed	bagFull	lockedToRange
alreadyAtMax	belowMinimumLightEffectsDuration	lowBattery
alreadyAtMin	binFull	maxSpeedReached
alreadyClosed	cancelArmingRestricted	minSpeedReached
alreadyDisarmed	deadBattery	notSupported
alreadyDocked	degreesOutOfRange	לא מקוון
alreadyInState	deviceJammingDetected	percentOutOfRange
alreadyLocked	deviceNotMounted	rangeTooClose
alreadyOff	deviceNotReady	remoteSetDisabled
alreadyOn	deviceOffline	safetyShutOff
alreadyOpen	deviceTurnedOff	targetAlreadyReached
alreadyPaused	discreteOnlyOpenClose	tooManyFailedAttempts
alreadyStarted	functionNotSupported	valueOutOfRange
alreadyStopped	inAutoMode
alreadyUnlocked	inEcoMode

המדד ‎Query/Execute Latency (p90) <= 1000ms מודד את זמן ההמתנה של פעולה שבוקשה ועוזר לוודא שהמשתמשים לא צריכים לחכות יותר מדי זמן, למשל, לחכות כמה שניות עד שהאור ייכבה.

מדדי זמן האחזור

זמן האחזור הוא אינדיקטור קריטי לרמת הרספונסיביות של השילוב עבור משתמש הקצה. בלוח הבקרה מוצג נתון השהייה באחוזון ה-90 (P90), שמייצג את החוויה של המשתמשים ה "איטיים" ביותר (לדוגמה, P90 של 800ms פירושו ש-90% מהבקשות מאושרות תוך 800ms או פחות).

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

1. זמן האחזור של השאילתה (שאילתה)

המדד הזה מודד את זמן הלוך ושוב של Cloud-to-cloud כש-Google מבקשת את המצב הנוכחי של מכשיר.

• התחלה: Google שולחת בקשת action.devices.QUERY לכתובת ה-URL של מרכז הבקשות.
• חלון המדידה: הזמן שנדרש לענן לקבל, לעבד ולשלוח את תגובת ה-HTTP המלאה בחזרה אל Google.
• סיום: Google מקבלת את מטען הנתונים של התגובה הסופית מהשירות שלכם ומאשרת את קבלתו.

2. זמן האחזור של הפעולה EXECUTE (הפעלה)

המדד הזה מודד את הזמן שחולף מרגע ש-Google שולחת בקשת שליטה למכשיר ועד לקבלת אישור על הפקודה.

• התחלה: Google שולחת בקשת action.devices.EXECUTE לכתובת ה-URL של מרכז הבקשות.
• חלון המדידה: הזמן שחלף מרגע שליחת הפקודה לענן ועד לקבלת תשובת אישור.
• סיום: Google מקבלת את תגובת הסטטוס SUCCESS, PENDING או OFFLINE.
• היקף טכני: המדד הזה מודד את הזמן שחלף בין קבלת אישור התגובה בענן של Google לבין קבלת אישור התגובה בענן שלכם. המדד לא מודד את הזמן שנדרש לחומרה הפיזית (לדוגמה, נורת LED) כדי להשלים את השינוי במצב הפיזי, כי בדרך כלל יש השהיה ברשת אריג מקומית שאינה חלק מהנתיב בין הענן לענן.

אפשרויות להפחתת זמן הטעינה

המלצות לארכיטקטורה של ניתוב גיאוגרפי

אם הטמעה של כתובת IP מסוג Anycast לא אפשרית, מומלץ להשתמש בחלופות הבאות שחוסכות עלויות כדי לוודא שהמשתמשים מקבלים שירות ממרכז הנתונים האזורי הקרוב ביותר.

1. איזון עומסים גלובלי (GLB)

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

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

   • היתרון: כך אפשר ליהנות מהביצועים של Anycast עם מורכבות ועלות הגדרה נמוכות משמעותית.

2. מערכת DNS שמודעת למיקום גיאוגרפי (GeoDNS)

   • איך זה עובד: מגדירים את ספק ה-DNS כך שיפענח את כתובת ה-URL של מרכז הלוגיסטיקה לכתובות IP שונות על סמך המיקום הגיאוגרפי של שאילתת ה-DNS.

   • הטמעה: צריך לוודא שספק ה-DNS שלכם מותאם לנקודות היציאה של Google. כששירותי ההשלמה האזוריים של Google (למשל בארה"ב, באיחוד האירופי או באסיה) פותרים את הדומיין שלכם, הם מקבלים את כתובת ה-IP של מרכז הנתונים באזור הספציפי הזה.

אסטרטגיות אופטימיזציה בשכבת האפליקציה

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

1. שיטת ה-Proxy ‏Trampoline

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

   1. מערכת Google ניגשת לכתובת ה-URL הגלובלית.

   2. בקשה מתקבלת על ידי שרת proxy אזורי (לדוגמה, פונקציית Nginx או Lambda קלה).

   3. ה-proxy מעביר את מטען הנתונים דרך עמוד השדרה הפנימי והמהיר שלכם אל מסד הנתונים הראשי.

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

2. רמזים לגבי אזור של טוקן גישה

   במהלך תהליך קישור החשבון (OAuth), המערכת שלכם יכולה לזהות את האזור הביתי של המשתמש.

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

תקינות המערכת – מדדי שותף ל-Google

שמירה על שיעור הצלחה של ‎99.5%‎ ומעלה עוזרת לוודא שהסטטוסים של המכשירים נכונים ב-Google Home, שהמכשירים מתווספים ומוסרים, שהאוטומציות מופעלות ושאירועי ההיסטוריה מופיעים בכרטיסייה "פעילות" של Google Home app (GHA).

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

מהי ההגדרה של 'הצלחה'?

• ‫2xx (הצלחה): עדכון המצב התקבל ועובד בהצלחה על ידי Home Graph.

מהי הגדרת הסטטוס 'כשל'?

• ‫4xx (שגיאת שותף): השגיאות האלה מייצגות כשלים ומעידות על בעיה בבקשה שנשלחה מהענן שלכם. דוגמאות לקודים נפוצים:
  • ‫400 בקשה שגויה: השרת לא הצליח לעבד את הבקשה בגלל תחביר לא תקין. הסיבות הנפוצות כוללות JSON לא תקין או שימוש בערך null במקום ב-"" עבור ערך מחרוזת.
  • 404 לא נמצא: המשאב המבוקש לא נמצא. בדרך כלל, המשמעות היא ש-Google לא יכולה למצוא את המכשיר המבוקש. יכול להיות גם שחשבון המשתמש לא מקושר או שקיבלנו agentUserId לא תקין. חשוב לוודא שהערך של agentUserId זהה לערך שמופיע בתגובת הסנכרון, ושהטיפול בכוונות DISCONNECT מתבצע בצורה תקינה.
  • ‫429 Resource Exhausted (המשאב מוצה): השילוב חרג מהמכסה שהוקצתה לו. הוראות לניהול נפח האחסון מופיעות בקטע 'שלב 1' בחלק העליון של מרכז הבקרה.

תקינות המכשיר – דיוק המצב

אם רמת הדיוק של המצב היא 99.5% ומעלה, המשתמשים יראו תוצאות נכונות כשהם יסתכלו על המצבים של המכשיר או ישתמשו בתכונות מבוססות-AI כמו "שאלת הבית". אם רמת הדיוק של המצב נמוכה, יכול להיות שהאוטומציות לא יופעלו והערכים בהיסטוריה לא יופיעו בכרטיסיית הפעילות של GHA בזמן הנכון. מידע נוסף מופיע במאמר בנושא דיווח של המצב.

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

1. רכיבי הדיוק

המדד מחושב על סמך 'דגימות' שבהן Google יכולה לאמת את המצב המדווח מול תוצאה ידועה של כוונת המשתמש.

2. מדדים בלוח הבקרה (חישוב שעתי)

החישוב של רמת הדיוק בלוח הבקרה מתבסס על מרווח של שעה אחת. אם בשעה מסוימת יש פחות מ-100 דגימות כוללות (S_Total < 100), הדיוק של השעה הזו מוגדר כ-N/A.

תצוגה 1: דיוק כולל (ממוצע גלובלי)

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

• חישוב: סך הדיוק של המצב בכל המכשירים חלקי סך המצב הכולל בכל המכשירים.

תצוגה 2: השילוב הנמוך ביותר של סוג/מאפיין

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

• חישוב: המינימום של דיוק המצב חלקי סך המצב לכל השילובים של מאפיין/מכשיר.