วิธีวัดคุณภาพผลิตภัณฑ์ในแดชบอร์ด Google Home Vitals

1. ก่อนเริ่มต้น

Codelab นี้ออกแบบมาสำหรับพาร์ทเนอร์และนักพัฒนาแอปของ Google Home ที่มีการผสานรวมระบบคลาวด์เพื่อปรับปรุงคุณภาพของระบบนิเวศและประสบการณ์ของผู้ใช้

สิ่งที่คุณจะได้เรียนรู้

แดชบอร์ด Google Home Vitals เป็นแหล่งข้อมูลที่ถูกต้องเพียงแหล่งเดียวสำหรับนักพัฒนาแอปและพาร์ทเนอร์ในการตรวจสอบความสมบูรณ์ของการผสานรวม Google Home ในระบบนิเวศที่ประสบการณ์ของผู้ใช้ขึ้นอยู่กับเวลาในการตอบสนองและความน่าเชื่อถือ Google Home Vitals คือพอร์ทัลแบบบริการตนเองที่มีข้อมูลวิเคราะห์เชิงลึกทั้งหมดที่จำเป็นต่อการเปลี่ยนจากการแก้ปัญหาแบบรีแอ็กทีฟเป็นการจัดการคุณภาพเชิงรุก

• วิธีคำนวณคะแนนการผสานรวมคุณภาพ
• วิธีอ่านและใช้แดชบอร์ด
• วิธีแก้ไขข้อบกพร่องของเมตริกคุณภาพต่ำ

สิ่งที่คุณต้องมี

• มีการผสานรวมระบบคลาวด์ของ Google Home

ตั้งค่า

วิธีไปที่แดชบอร์ด Google Home Vitals

1. เปิด Google Cloud Platform
2. การตรวจสอบ > แดชบอร์ด
3. คลิกแดชบอร์ด "Google Home Vitals (Cloud)"

2. วิธีอ่านแดชบอร์ด

การคำนวณคะแนนคุณภาพ - มาตรฐาน "ดี" เทียบกับ "ไม่ดี"

แดชบอร์ดจะอธิบายรายละเอียดการให้คะแนนคุณภาพ ระบบจะกำหนดคะแนนคุณภาพตามความละเอียดของประเภทอุปกรณ์ การผสานรวมประเภทอุปกรณ์จะถือว่าดีได้ก็ต่อเมื่อมีคุณสมบัติตรงตามเกณฑ์ 4 ข้อพร้อมกัน

1. อัตราความสำเร็จทั่วโลก: อัตราความสำเร็จของการโทรจากพาร์ทเนอร์ไปยัง Google โดยรวมต้องมากกว่าหรือเท่ากับ 99.5%
   หมายเหตุ: หากไม่เป็นไปตามอัตราความสำเร็จทั่วโลก (มากกว่าหรือเท่ากับ 99.5%) จะส่งผลให้มีการจัดประเภทไม่ดีโดยอัตโนมัติในทั้งโปรเจ็กต์ ไม่ว่าประสิทธิภาพของอุปกรณ์แต่ละเครื่องจะเป็นอย่างไร
2. ความน่าเชื่อถือของคำสั่ง: อัตราความสำเร็จของ QUERY และ EXECUTE ต้องมากกว่าหรือเท่ากับ 99.5% สำหรับอุปกรณ์ทุกประเภท
3. เวลาในการตอบสนอง: เปอร์เซ็นไทล์ที่ 90 ของเวลาในการตอบสนองสำหรับ QUERY และ EXECUTE ต้องไม่เกิน 1,000 มิลลิวินาทีสำหรับอุปกรณ์ทุกประเภท
4. ความสมบูรณ์ของสถานะ: ความแม่นยำของสถานะต้องมากกว่าหรือเท่ากับ 99.5%

ความสำคัญของเมตริกเหล่านี้

1. อัตราความสำเร็จทั่วโลก: การโทรจากพาร์ทเนอร์ไปยัง Google ในระดับการผสานรวมจะวัดความสมบูรณ์ของการโทรจากระบบคลาวด์ของคุณไปยัง Google อัตราความสำเร็จที่ >= 99.5% ช่วยให้มั่นใจได้ว่า Google Home จะใช้สถานะอุปกรณ์ที่ถูกต้อง ตัวอย่างเช่น ตรวจสอบว่าได้เพิ่มและนำอุปกรณ์ออกแล้ว การทำงานอัตโนมัติทริกเกอร์ และเหตุการณ์ในประวัติปรากฏในแท็บกิจกรรมของแอป Google Home
2. ความน่าเชื่อถือของคำสั่ง: ระบบจะวัดอัตราความสำเร็จของ QUERY และ EXECUTE ที่ระดับประเภทอุปกรณ์ อัตราความสำเร็จที่ >=99.5% จะช่วยให้มั่นใจได้ว่าระบบจะดำเนินการตามคำสั่งของผู้ใช้ได้อย่างถูกต้อง (เช่น หลีกเลี่ยงการตอบกลับของ Assistant เช่น "ฉันเข้าถึงอุปกรณ์ไม่ได้" หรือการยืนยันคำสั่งที่ไม่ถูกต้องซึ่งไม่ได้ดำเนินการ)
3. เวลาในการตอบสนอง: ระบบจะวัดเวลาในการตอบสนองของ QUERY และ EXECUTE ที่ระดับประเภทอุปกรณ์ด้วย เวลาในการตอบสนอง <=1000 มิลลิวินาทีต่อประเภทอุปกรณ์ช่วยให้ผู้ใช้ไม่ต้องรอนานเกินไปเพื่อดำเนินการที่ต้องการ (เช่น รอ 2-3 วินาทีเพื่อให้ไฟดับ)
4. ความสมบูรณ์ของสถานะ: วัดความแม่นยำของสถานะที่จัดเก็บไว้ในระบบของ Google และใช้เพื่อแสดงผลการค้นหาของผู้ใช้ หากตัวเลขเหล่านี้ต่ำ ผู้ใช้อาจเห็นผลลัพธ์ที่ไม่ถูกต้องสำหรับอุปกรณ์เมื่อดูสถานะของอุปกรณ์หรือใช้ฟีเจอร์ AI เช่น ถาม Google Home การทำงานอัตโนมัติอาจไม่เริ่มทำงานและรายการประวัติอาจไม่ปรากฏในกิจกรรมในเวลาที่เหมาะสม

วิธีอ่านแดชบอร์ด

เริ่มต้นในส่วนเมตริกคะแนนคุณภาพ ซึ่งทำหน้าที่เป็นตัวบ่งชี้ประสิทธิภาพหลักสำหรับการผสานรวม คะแนนระดับอุปกรณ์ที่ดีขึ้นอยู่กับเมตริกทั้งหมดในส่วนนี้ที่ตรงตามเกณฑ์ความสำเร็จสีเขียว ดูข้อกำหนดทางเทคนิคโดยละเอียดและคำจำกัดความของเมตริกได้ในเอกสารประกอบของศูนย์นักพัฒนาแอป

ส่วน "คะแนนเมตริกคุณภาพ" ที่ด้านบนของแดชบอร์ด Google Home Vitals จะแสดงเมตริกที่ใช้ในการคำนวณคะแนนคุณภาพของการผสานรวม

คำอธิบาย

• สีเขียว (ดี): เมตริกเป็นไปตามเกณฑ์คุณภาพ
• สีแดง (ไม่ดี): เมตริกไม่เป็นไปตามเกณฑ์คุณภาพ

ตัวอย่าง

ในตัวอย่างด้านล่าง คุณจะเห็นว่าประเภทอุปกรณ์ AC_UNIT เป็นไปตามเกณฑ์ด้านคุณภาพในอัตราความสำเร็จของ QUERY และ EXECUTE รวมถึงส่วนเวลาในการตอบสนองของ QUERY แต่ไม่ผ่านแถบเวลาในการตอบสนองของ EXECUTE (สีแดง) ซึ่งหมายความว่าคำสั่งทำงานสำเร็จตามอัตราการส่งผ่าน แต่เวลาในการตอบสนองของ EXECUTE ช้าเกินไป 36 มิลลิวินาที ส่วนสถานะของระบบแสดงอัตราความล้มเหลว 98.92% สำหรับวิธีการรวมทั้งหมดในการผสานรวม ซึ่งหมายความว่ายังสามารถปรับปรุงเพื่อให้มั่นใจในความถูกต้องของสถานะอุปกรณ์ของผู้ใช้ใน Google Home ได้ ซึ่งหมายความว่าการเรียกใช้ 1.08% (DeleteAgentUser, Query, ReportStateAndNotification, RequestSyncDevices หรือ Sync) จะแสดงรหัสการตอบกลับที่ไม่เท่ากับ 2xx หรือ 5xx (เช่น ข้อผิดพลาด 404) เมตริกสุดท้ายที่ใช้ในการวัดคุณภาพผ่าน/ไม่ผ่านสำหรับอุปกรณ์ประเภท AC_UNIT คือความถูกต้องของสถานะ ในตัวอย่างนี้ เราเห็นอัตราความสำเร็จ 77.43% ซึ่งหมายความว่าผู้ใช้อาจเห็นผลลัพธ์ที่ไม่ถูกต้องสำหรับอุปกรณ์ เมื่อใช้เมตริกทั้ง 3 รายการนี้ คะแนนโดยรวมสำหรับ AC_UNIT จะเป็น "ไม่ดี" และต่ำกว่าเกณฑ์คุณภาพ

การคำนวณคุณภาพแต่ละรายการเหล่านี้สอดคล้องกับส่วนการแก้ไขข้อบกพร่องด้านล่าง เปิดขั้นตอนที่ยุบไว้เพื่อแก้ไขข้อบกพร่องเพิ่มเติม

หากต้องการแก้ไขข้อบกพร่องของอัตราความสำเร็จและเวลาในการตอบสนองของ QUERY/EXECUTE ให้ไปที่ "ขั้นตอนที่ 1: ตรวจสอบการเรียกใช้ Cloud"

หากต้องการแก้ไขข้อบกพร่องของอัตราความสำเร็จของพาร์ทเนอร์ต่อ Google ให้ไปที่ "ขั้นตอนที่ 2: ตรวจสอบความถูกต้องของการโทรไปยัง Google"

หากต้องการแก้ไขข้อบกพร่องความแม่นยำของสถานะสำหรับอุปกรณ์แต่ละประเภท ให้ไปที่ "ขั้นตอนที่ 3: ปรับปรุงความแม่นยำของสถานะ"

3. ขั้นตอนการแก้ไขข้อบกพร่องที่ 1: ตรวจสอบการเรียกใช้ Cloud

ขั้นตอนที่ 1: ภาพรวม

ส่วนนี้มุ่งเน้นที่การเรียกใช้ในระบบคลาวด์ ซึ่งเป็นเมตริกที่วัดสถานะของการสื่อสารจาก Google ไปยังแบ็กเอนด์ระบบคลาวด์ของคุณ (หรือที่เรียกว่าเมตริกจาก Google ถึงพาร์ทเนอร์) ซึ่งรวมถึงคำสั่งต่างๆ เช่น Query, Execute

เราติดตามอัตราความสำเร็จและเวลาในการตอบสนองสำหรับ QUERY และ EXECUTE (ซึ่งเป็นปัจจัยที่ส่งผลต่อคะแนนคุณภาพประเภทอุปกรณ์)

ภาพรวมด้านล่างแสดงอัตราความสำเร็จและข้อผิดพลาดของ QUERY และ EXECUTE โดยรวมที่ระดับการผสานรวม ขั้นตอนที่ 1ก-1ง แสดงรายละเอียดของเมตริกเหล่านี้ในระดับประเภท/ลักษณะของอุปกรณ์

ขั้นตอนที่ 1a และ 1b แสดงแนวโน้มของจำนวนคำขอการดำเนินการ จำนวนข้อผิดพลาดในช่วงระยะเวลาหนึ่ง และสถานะข้อผิดพลาดที่เฉพาะเจาะจง

ขั้นตอนที่ 1ก: ตรวจสอบข้อผิดพลาดของคำค้นหา

ขั้นตอนที่ 1ข: ตรวจสอบข้อผิดพลาดในการดำเนินการ

ขั้นตอนที่ 1c และ 1d แสดงรายละเอียดเปอร์เซ็นไทล์ที่ 90 และ 50 สำหรับเมตริกเหล่านี้ที่ระดับการผสานรวมและระดับประเภทอุปกรณ์ด้วย

ขั้นตอนที่ 1ค: ตรวจสอบเวลาในการตอบสนองของคำค้นหา

ขั้นตอนที่ 1ง: ตรวจสอบเวลาในการตอบสนองของการดำเนินการ

4. การแก้ไขข้อบกพร่อง ขั้นตอนที่ 2: ตรวจสอบการเรียกไปยัง Google

ขั้นตอนที่ 2: ภาพรวม

หลังจากแก้ไขข้อบกพร่องของการโทรจาก Google ไปยังพาร์ทเนอร์แล้ว ขั้นตอนที่ 2 นี้จะครอบคลุมการแก้ไขข้อบกพร่องของการโทรจากระบบคลาวด์ของพาร์ทเนอร์ไปยัง Google ส่วนนี้ครอบคลุมเมตริกระดับการผสานรวมพาร์ทเนอร์ ไม่ใช่ระดับประเภทอุปกรณ์ ซึ่งรวมถึงรหัสการตอบกลับ เช่น 400 Bad Request, 404 Not Found และ 429 Resource Exhausted

ขั้นตอนที่ 2ก: แก้ข้อบกพร่องเกี่ยวกับปัญหาโควต้า

Google Home จำกัดการจัดสรรและการใช้ทรัพยากร รวมถึงบังคับใช้โควต้าที่เหมาะสมแบบต่อโปรเจ็กต์ Google ใช้ขีดจํากัดเริ่มต้นที่ 6,000 คําขอต่อ 60 วินาทีกับคําขอรวมของการเรียก API แบบค้นหา ลบ สถานะรายงาน และการซิงค์คําขอที่โหลดแบบอะซิงโครนัส โดยอิงตามการผสานรวมแบบคลาวด์ต่อคลาวด์

ปัญหาเกี่ยวกับโควต้าอาจส่งผลเสียต่อความถูกต้องของสถานะรายงาน เนื่องจากหากอัปเดตสถานะไม่สำเร็จอาจทำให้เกิดความไม่ตรงกัน ด้านล่างนี้คือแผนภูมิที่มีรายละเอียดซึ่งแสดงสถานะรายงานและข้อผิดพลาดในการซิงค์คำขอ รายละเอียดเมธอด API ของจำนวนและข้อผิดพลาด รวมถึงเปอร์เซ็นต์การใช้โควต้าโดยเฉพาะ หากแผนภูมิเหล่านี้แสดงการเข้าชมที่เพิ่มขึ้นอย่างไม่คาดคิด ให้ตรวจสอบการผสานรวมเพื่อดูว่าการเปลี่ยนแปลงใดที่ทำให้มีการส่งการเข้าชมไปยัง Home Graph API มากขึ้น

ในบางสถานการณ์ เช่น การเติบโตของการเข้าชมตามธรรมชาติเมื่อเวลาผ่านไป (เช่น การเติบโตสอดคล้องกับการเพิ่มขึ้นของจำนวนอุปกรณ์ การเปิดตัวอุปกรณ์ประเภทใหม่ หรือการเปิดตัวอื่นๆ ที่คาดไว้) การเพิ่มโควต้าสำหรับการผสานรวมอาจเหมาะสม หากต้องการขอเพิ่มโควต้า โปรดทำตามขั้นตอนในเอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์

5. การแก้ไขข้อบกพร่อง ขั้นตอนที่ 3: ปรับปรุงความแม่นยำของสถานะ

ขั้นตอนที่ 3: ภาพรวม

เมื่อแก้ไขข้อบกพร่องทั้งขั้นตอนที่ 1 และขั้นตอนที่ 2 แล้ว ขั้นตอนที่ 3 จะครอบคลุมความถูกต้องของสถานะรายงาน ซึ่งเป็นสถานะอุปกรณ์ที่จัดเก็บไว้ในระบบของ Google ซึ่งใช้เพื่อตอบคำค้นหาของผู้ใช้ รายละเอียดตามลักษณะและประเภทอุปกรณ์แสดงอยู่ด้านล่าง ขั้นตอนที่ 3a และ 3b ครอบคลุมข้อผิดพลาดที่พบบ่อย 2 อย่างสำหรับสถานะรายงาน ได้แก่ ข้อผิดพลาดเกี่ยวกับฟิลด์ที่ขาดหายไปและข้อผิดพลาดที่ไม่ถูกต้อง

ขั้นตอนที่ 3ก: ข้อผิดพลาด "ไม่มีฟิลด์"

ข้อผิดพลาด "ไม่มีฟิลด์" เกิดขึ้นเมื่อชุดฟิลด์เพย์โหลดแตกต่างกันระหว่างการตอบกลับ QUERY กับคำขอสถานะที่รายงานสำหรับอุปกรณ์ที่กำหนด ชุดฟิลด์ภายในเพย์โหลดของแต่ละอุปกรณ์ต้องเหมือนกัน ปัญหานี้อาจเกิดขึ้นหากตรรกะในการคำนวณเพย์โหลดแตกต่างกันระหว่างการตอบกลับสถานะ QUERY และรายงาน ใช้แผนภูมิด้านล่างเพื่อติดตามประเภทอุปกรณ์และลักษณะที่ตอบกลับสถานะ QUERY และรายงานไม่ตรงกัน

ขั้นตอนที่ 3ข: ข้อผิดพลาด "ไม่ถูกต้อง"

ข้อผิดพลาดที่ไม่ถูกต้องเกิดขึ้นเมื่อชุดฟิลด์เพย์โหลดเหมือนกันระหว่างการตอบกลับ QUERY กับคำขอสถานะที่รายงานสำหรับอุปกรณ์หนึ่งๆ แต่ค่าสถานะแตกต่างกัน ซึ่งอาจเกิดขึ้นหากไม่มีรายงานระดับรัฐ หรือหากตรรกะในการคํานวณรัฐแตกต่างกันระหว่าง QUERY กับรายงานระดับรัฐ ใช้แผนภูมิด้านล่างเพื่อติดตามประเภทอุปกรณ์และลักษณะที่ตอบกลับสถานะ QUERY และรายงานไม่ตรงกัน

6. เอกสารและแหล่งข้อมูลอื่นๆ

• หากต้องการส่งความคิดเห็นหรือรายงานปัญหาเกี่ยวกับแดชบอร์ดนี้ โปรดรายงานปัญหาในIssue Trackerสาธารณะของเรา
• หากต้องการยื่นคำขออุทธรณ์ โปรดยื่นปัญหาโดยใช้แบบฟอร์มอุทธรณ์เมตริกคุณภาพ
• หากต้องการทราบคุณภาพการผสานรวมอยู่เสมอ ให้กำหนดค่าการแจ้งเตือนของ Google Cloud Platform เพื่อรับการแจ้งเตือนเมื่อเมตริกต่ำกว่าเกณฑ์ที่ยอมรับได้ ซึ่งจะช่วยให้คุณเป็นคนแรกที่ทราบเมื่อเกิดปัญหา
• สำหรับข้อมูลอื่นๆ ทั้งหมด โปรดดูข้อมูลเพิ่มเติมในเอกสารประกอบของนักพัฒนาซอฟต์แวร์ที่ https://developers.home.google.com/tools/analytics/home-vitals