การสร้างแดชบอร์ดสำหรับการแสดงผลการปฏิบัติงาน

เราทุกคนเรียกใช้แอปพลิเคชันในแล็ปท็อป แท็บเล็ต และสมาร์ทโฟนของเรา เป็นเรื่องง่ายที่เราจะดูว่าอุปกรณ์เปิดอยู่หรือไม่และการเชื่อมต่อเครือข่าย Wi-Fi ออนไลน์อยู่หรือไม่ เราทราบดีว่าหน้าจอของเราจะแสดงการแจ้งเตือนที่สำคัญ เช่น คำเตือนพื้นที่ว่างในดิสก์เหลือน้อย อันที่จริง ความเร็วและการตอบสนองโดยรวมของอินเทอร์เฟซผู้ใช้ (UI) สามารถเป็นตัวบ่งชี้ที่ดีว่าอุปกรณ์นั้นมีทรัพยากร เช่น หน่วยความจำ หรือ CPU เพียงพอสำหรับเรียกใช้แอปพลิเคชันของเราหรือไม่

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

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

Amazon ดูการทำงานของบริการระบบคลาวด์ทั้งหมดที่ทำงานใน Availability Zone หลายแห่งในหลายรีเจี้ยนทั่วโลกได้อย่างไร การตรวจสอบอัตโนมัติ เวิร์กโฟลว์การแก้ไขอัตโนมัติ (เช่น การเปลี่ยนปริมาณการใช้งาน) และระบบการติดตั้งใช้จริงอัตโนมัติ มีความสำคัญอย่างยิ่งต่อการตรวจสอบและแก้ไขปัญหาส่วนใหญ่ในระดับนี้ อย่างไรก็ตาม ด้วยเหตุผลหลายประการ เรายังคงต้องสามารถดูได้ว่าบริการ เวิร์กโฟลว์ และการติดตั้งใช้จริงเหล่านี้ ทำอะไรบ้างในช่วงเวลาใดเวลาหนึ่ง

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

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

แน่นอนว่า เราไม่ได้คาดหวังให้ผู้ปฏิบัติงานของเราตรวจสอบแดชบอร์ดตลอดเวลา ส่วนใหญ่ไม่มีใครเฝ้าดูแดชบอร์ดเหล่านี้ ในความเป็นจริง เราพบว่ากระบวนการปฏิบัติงานที่ต้องมีการตรวจสอบแดชบอร์ดด้วยตนเองจะล้มเหลวเนื่องจากความผิดพลาดของมนุษย์ ไม่ว่าจะมีการตรวจสอบแดชบอร์ดบ่อยเพียงใดก็ตาม เพื่อจัดการกับความเสี่ยงนี้ เราได้สร้างสัญญาณเตือนอัตโนมัติที่ประเมินข้อมูลการตรวจสอบที่สำคัญที่สุดที่ระบบของเราส่งออกมา โดยทั่วไปแล้ว ตัววัดเหล่านี้จะบ่งชี้ว่าระบบกำลังเข้าใกล้ขีดจำกัดบางอย่าง (การตรวจสอบเชิงรุก ก่อนเกิดผลกระทบ) หรือระบบมีความบกพร่องแล้วในลักษณะที่ไม่คาดคิด (การตรวจสอบเชิงรับ หลังเกิดผลกระทบ)

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

โดยทั่วไปแล้วเมื่อกิจกรรมกำลังดำเนินอยู่ Amazon จะว่าจ้างผู้ให้บริการโทรศัพท์หลายราย ผู้ปฏิบัติงานอาจใช้แดชบอร์ดที่แตกต่างกันในการดำเนินการตามลำดับของงาน โดยทั่วไปแล้วงานเหล่านี้จะรวมถึงการประเมินผลกระทบต่อลูกค้า การคัดแยก การติดตามในบริการต่างๆ เพื่อหาสาเหตุหลักของเหตุการณ์ การสังเกตเวิร์กโฟลว์การแก้ไขอัตโนมัติ รวมถึงดำเนินการและตรวจสอบความถูกต้องของขั้นตอนการลดผลกระทบในระบบรันบุ๊ก ในขณะเดียวกัน ทีมที่ร่วมงานและผู้มีส่วนได้ส่วนเสียทางธุรกิจยังใช้แดชบอร์ดเพื่อตรวจสอบผลกระทบที่เกิดขึ้นในระหว่างเหตุการณ์ด้วย ผู้เข้าร่วมต่างๆ เหล่านี้สื่อสารโดยใช้เครื่องมือจัดการเหตุการณ์ ห้องแชท (พร้อมบอทอย่าง AWS Chatbot) และการประชุมทางโทรศัพท์ ผู้มีส่วนได้ส่วนเสียแต่ละรายมีมุมมองที่แตกต่างกันเกี่ยวกับข้อมูลที่ตนเห็นในแดชบอร์ด

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

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

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

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

แผนผังต่อไปนี้แสดงให้เห็นว่าแดชบอร์ดแบบต่างๆ ให้มุมมองที่แตกต่างกันในระบบโดยรวมอย่างไรบ้าง

ที่ Amazon แดชบอร์ดที่สำคัญที่สุดและใช้กันอย่างแพร่หลายคือแดชบอร์ดประสบการณ์การใช้งานของลูกค้า แดชบอร์ดเหล่านี้ได้รับการออกแบบมาเพื่อใช้งานโดยกลุ่มผู้ใช้ในวงกว้างอันได้แก่ผู้ปฏิบัติงานบริการและผู้มีส่วนได้ส่วนเสียรายอื่นเป็นจำนวนมาก แดชบอร์ดเหล่านี้นำเสนอตัววัดเกี่ยวกับความสมบูรณ์ของบริการโดยรวมและการปฏิบัติตามเป้าหมายอย่างมีประสิทธิภาพ แดชบอร์ดเหล่านี้แสดงข้อมูลการตรวจสอบที่รวบรวมจากตัวบริการเองและจากเครื่องมือของไคลเอ็นต์ ผู้ทดสอบแบบต่อเนื่อง (เช่น คานารีต่างๆ ใน Amazon CloudWatch Synthetics) รวมถึงระบบแก้ไขอัตโนมัติ แดชบอร์ดเหล่านี้ยังมีข้อมูลที่ช่วยผู้ใช้ในการตอบคำถามเกี่ยวกับความลึกและความกว้างของผลกระทบอีกด้วย คำถามเหล่านี้บางข้อจะเป็นไปในทำนองว่า “ลูกค้าจำนวนเท่าใดที่ได้รับผลกระทบ” และ “ลูกค้ารายใดได้รับผลกระทบมากที่สุด”

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

• ข้อมูลการตรวจสอบที่เกี่ยวข้องกับอินพุต เช่น จำนวนคำขอที่ได้รับ หรืองานที่สำรวจจากคิว/สตรีม เปอร์เซ็นไทล์ขนาดไบต์ของคำขอ และจำนวนการยืนยันตัวตน/การอนุญาตที่ล้มเหลว
• ข้อมูลการตรวจสอบที่เกี่ยวข้องกับการประมวลผล เช่น เส้นทางตรรกะทางธุรกิจแบบหลายรูปแบบ/จำนวนการดำเนินการของสาขา, เปอร์เซ็นต์ไทล์ของจำนวน/ความล้มเหลว/เวลาแฝงสำหรับคำขอของไมโครเซอร์วิสสำหรับแบ็กเอนด์, เอาต์พุตบันทึกข้อบกพร่องและข้อผิดพลาด และข้อมูลการติดตามการร้องขอ
• ข้อมูลการตรวจสอบที่เกี่ยวข้องกับเอาต์พุต เช่น จำนวนประเภทการตอบสนอง (พร้อมรายละเอียดสำหรับการตอบสนองต่อข้อบกพร่อง/ข้อผิดพลาดโดยลูกค้า) ขนาดของการตอบสนอง และเปอร์เซ็นต์ไทล์สำหรับไบต์การตอบสนองครั้งแรกแบบเวลาในการเขียนและการตอบสนองแบบเวลาในการเขียน

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

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

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

สำหรับกรณีการใช้งานระยะยาว เรายังสร้างแดชบอร์ดสำหรับการวางแผนและการคาดการณ์กำลังการผลิตเพื่อช่วยให้เราเห็นภาพการเติบโตของบริการของเรา

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

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

บริการของเราทำงานในโครงสร้างพื้นฐาน AWS ที่มักจะปล่อยตัววัด ตังนั้นเราจึงมีแดชบอร์ดโครงสร้างพื้นฐานโดยเฉพาะ แดชบอร์ดเหล่านี้มุ่งเน้นไปที่ตัววัดที่ปล่อยออกมาจากทรัพยากรการประมวลผลที่ระบบของเราทำงานอยู่เป็นหลัก เช่น อินสแตนซ์ Amazon Elastic Compute Cloud (EC2), คอนเทนเนอร์ Amazon Elastic Container Service (ECS)/Amazon Elastic Kubernetes Service (EKS) และฟังก์ชัน AWS Lambda ตัววัด เช่น การใช้งาน CPU, การรับส่งข้อมูลทางเครือข่าย, ดิสก์ IO และการใช้พื้นที่มักใช้ในแดชบอร์ดเหล่านี้ พร้อมกับคลัสเตอร์, Auto Scaling และตัววัดโควต้าที่เกี่ยวข้องซึ่งเกี่ยวข้องกับทรัพยากรการคำนวณเหล่านี้

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

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

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

เราได้ปรับใช้แบบแผนการออกแบบที่จะสร้างมาตรฐานให้กับเค้าโครงข้อมูลในแดชบอร์ด แดชบอร์ดจะแสดงข้อมูลจากบนลงล่าง และผู้ใช้ก็มีแนวโน้มจะตีความกราฟที่แสดงในช่วงต้น (แสดงเมื่อโหลดแดชบอร์ด) ว่าเป็นข้อมูลที่สำคัญที่สุด ดังนั้น แบบแผนการออกแบบของเราจึงแนะนำให้วางข้อมูลที่สำคัญที่สุดไว้ด้านบนของแดชบอร์ด เรายังค้นพบอีกว่าโดยทั่วไปแล้ว กราฟสรุป/รวมความพร้อมใช้งานและกราฟเปอร์เซ็นเวลาแฝงตั้งแต่ต้นทางถึงปลายทาง คือแดชบอร์ดที่สำคัญที่สุดสำหรับบริการบนเว็บไซต์

นี่คือภาพหน้าจอด้านบนของแดชบอร์ด Foo Service จำลอง:

ถ้าเรามีตัววัดหลายตัวในกราฟเดียว เราจะตรวจสอบให้แน่ใจว่าคำอธิบายกราฟนั้นไม่ได้บีบข้อมูลกราฟที่แสดงในแนวตั้งหรือแนวนอน ถ้าเราใช้การสืบค้นในกราฟ เราจะตรวจสอบให้แน่ใจว่าได้อนุญาตให้สืบค้นได้มากกว่าชุดผลการวัดปกติ

ซึ่งจะช่วยป้องกันไม่ให้ผู้ใช้ต้องเลื่อนดูซ้าย-ขวา ผู้ปฏิบัติงานที่ทำงานหน้าแล็ปท็อปตอนตี 3 อาจไม่สังเกตเห็นแถบเลื่อนแนวนอน หากไม่มีสัญลักษณ์บ่งบอกที่ชัดเจนว่ามีกราฟอีกหลายกราฟในทางขวา

สำหรับแดชบอร์ดที่แสดงข้อมูลวันที่และเวลา เราจะตรวจสอบให้แน่ใจว่าเขตเวลาที่เกี่ยวข้องได้แสดงในแดชบอร์ด สำหรับแดชบอร์ดที่ผู้ปฏิบัติงานใช้งานพร้อมกันแต่คนละเขตเวลา เราจะตั้งค่าเริ่มต้นเป็นเขตเวลาเดียว (UTC) ที่ผู้ใช้ทุกคนสามารถอ้างอิงได้ ทำให้ผู้ใช้สามารถสื่อสารโดยใช้เขตเวลาเดียวกันได้ ซึ่งจะช่วยให้ไม่เสียเวลาและความพยายามในการแปลงเขตเวลาเองโดยไม่จำเป็น

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

และเรายังหลีกเลี่ยงไม่พล็อตจุดข้อมูลในกราฟมากเกินไป เพราะนั่นจะทำให้แดชบอร์ดต้องใช้เวลาโหลดนานขึ้น นอกจากนี้ เรายังสังเกตว่าการแสดงจุดข้อมูลต่อผู้ใช้ที่มากเกินไปจะทำให้การแสดงผลเกิดความผิดปกติ ตัวอย่างเช่น กราฟรอบเวลา 3 ชั่วโมงของจุดข้อมูลความละเอียด 1 นาที ที่มีเพียง 180 ค่าต่อตัววัด จะแสดงข้อมูลอย่างชัดเจนแม้ในวิดเจ็ตแดชบอร์ดขนาดเล็ก จุดข้อมูลจำนวนเท่านี้ยังให้บริบทแก่ผู้ปฏิบัติงานที่กำลังคัดกรองการปฏิบัติงานที่กำลังดำเนินการอย่างเพียงพอ

แดชบอร์ดของเรามีเครื่องมือควบคุมสำหรับปรับรอบเวลาและระยะเวลาของตัววัดสำหรับกราฟทั้งหมด อัตราส่วนรอบเวลา x ความละเอียดทั่วไปอื่นๆ ที่ใช้ในแดชบอร์ดของเราคือ:

• 1 ชั่วโมง x 1 นาที (จุดข้อมูล 60 จุด) – เหมาะสำหรับการซูมเข้าเพื่อดูกิจกรรมที่กำลังดำเนินการ
• 12 ชั่วโมง x 1 นาที (จุดข้อมูล 720 จุด)
• 1 วัน x 5 นาที (จุดข้อมูล 288 จุด) – เหมาะสำหรับการดูแนวโน้มรายวัน
• 3 วัน x 5 นาที (จุดข้อมูล 864 จุด)
• 1 สัปดาห์ x 1 ชั่วโมง (จุดข้อมูล 168 จุด) – เหมาะสำหรับการดูแนวโน้มรายสัปดาห์
• 1 เดือน x 1 ชั่วโมง (จุดข้อมูล 744 จุด)
• 3 เดือน x 1 วัน (จุดข้อมูล 90 จุด) – เหมาะสำหรับการดูแนวโน้มรายไตรมาส
• 9 เดือน x 1 วัน (จุดข้อมูล 270 จุด)
• 15 เดือน x 1 วัน (จุดข้อมูล 450 จุด) – เหมาะสำหรับการตรวจสอบความจุในระยะยาว
  

เมื่อเราสร้างกราฟตัววัดที่มีการแจ้งเตือนอัตโนมัติที่เกี่ยวข้อง ถ้าเกณฑ์การแจ้งเตือนเป็นแบบคงที่ เราจะอธิบายกราฟด้วยเส้นแนวนอน แต่ถ้าเกณฑ์การแจ้งเตือนเป็นแบบไดนามิกที่สร้างจากการพยากรณ์หรือการคาดการณ์โดยใช้ปัญญาประดิษฐ์ (AI) หรือแมชชีนเลิร์นนิ่ง (ML) เราจะแสดงทั้งตัววัดจริงและตัววัดแบบเกณฑ์ในกราฟเดียวกัน ถ้ากราฟแสดงตัววัดด้านการบริการที่มีขีดจำกัด (เช่น ขีดจำกัด “การทดสอบสูงสุด” หรือขีดจำกัดด้านข้อมูลถาวร) เราจะอธิบายกราฟด้วยเส้นแนวนอน เพื่อบอกตำแหน่งของขีดจำกัดการทดสอบหรือขีดจำกัดที่รู้จัก สำหรับตัววัดที่มีเป้าหมาย เราจะเพิ่มเส้นแนวนอนเพื่อให้ผู้ใช้เห็นเป้าหมายเหล่านั้นในทันที

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

เราหลีกเลี่ยงสถานการณ์นี้เพราะข้อมูลที่มากเกินไปจะทำให้การมองเห็นตัววัดเกิดความแปรปรวนอย่างน้อยหนึ่งตัว ตัวอย่างของสถานการณ์นี้คือ เมื่อเราพล็อตเวลาแฝง p0 (ขั้นต่ำ) และ p100 (ขั้นสูง) ในกราฟเดียวกัน ซึ่งเป็นกราฟที่ค่าของจุดข้อมูล p100 อาจใหญ่กว่าจุดข้อมูล p0 หลายเท่า

การกวาดตามองกราฟที่มีช่วงข้อมูลแกน y ที่จำกัดกับค่าของจุดข้อมูล อาจทำให้ตัววัดดูแปรปรวนมากกว่าความเป็นจริง

เราต้องการตรวจสอบให้แน่ใจว่าเราไม่ได้แสดงตัววัดทางสถิติที่มากเกินไปหรือแสดงตัววัดที่ไม่เกี่ยวข้องในกราฟเดียว ตัวอย่างเช่น เมื่อเพิ่มกราฟสำหรับกระบวนการส่งคำขอ เรามักจะสร้างกราฟใกล้เคียงแยกต่างหากในแดชบอร์ดสำหรับข้อมูลต่อไปนี้:

• ความพร้อมใช้งาน % (ผิดพลาด/คำขอ * 100)
• เวลาแฝง p10 เฉลี่ย p90
• เวลาแฝง p99.9 และสูงสุด (p100)
  

เรานำแนวคิดนี้ไปใช้เพื่อปรับปรุงตัววัดบางตัว เราต้องการมอบบริบทที่เพียงพอในข้อความของแดชบอร์ด ตัวอย่างเช่น มีข้อความอธิบายด้านข้างหรือด้านล่างของแต่ละกราฟ ผู้ปฏิบัติงานสามารถอ่านข้อความนี้เพื่อทำความเข้าใจความหมายของตัววัดได้ จากนั้น ผู้ปฏิบัติงานจะสามารถวิเคราะห์ได้ว่าข้อมูล “ปกติ” ควรเป็นอย่างไร และจะเกิดจะอะไรขึ้นถ้ากราฟนั้น “ไม่ปกติ” ในข้อความนี้เรามีลิงก์ที่เชื่อมโยงไปยังแหล่งข้อมูลที่เกี่ยวข้องที่ผู้ปฏิบัติสามารถใช้กำหนดสาเหตุหลักของความผิดปกติได้ นี่คือตัวอย่างเล็กๆ น้อยๆ เกี่ยวกับประเภทของลิงก์ที่เรามีให้:

• ไปยังรันบุ๊ค แดชบอร์ดสามารถเป็นรันบุ๊คสำหรับผู้เชี่ยวชาญในเรื่องต่างๆ ได้
• ไปยังแดชบอร์ด “เจาะลึก” ที่เกี่ยวข้อง
• ไปยังแดชบอร์ดใกล้เคียงสำหรับกลุ่มตัวอย่างหรือพาร์ติชันอื่น
• ไปยังไปป์ไลน์การปรับใช้
• ไปยังข้อมูลติดต่อที่เกี่ยวข้อง
  

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

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

เราดำเนินการเช่นนี้เมื่อเราแสดงกราฟสำหรับตัววัดที่รวมลักษณะการทำงานหลายโมเดลในระบบของเรา ซึ่งเราอาจเพิ่มกราฟในบางสถานการณ์ เช่น

• ถ้าบริการนั้นรองรับคำขอในขนาดต่างๆ เราอาจสร้างกราฟสำหรับเวลาแฝงรวมของคำขอนั้น รวมถึงเราอาจสร้างกราฟที่แสดงตัววัดสำหรับคำขนาดเล็ก กลาง และใหญ่
• ถ้าบริการดำเนินการคำขอหลากหลายวิธี โดยอิงจากค่า (หรือค่ารวม) ของพารามิเตอร์ที่ป้อน เราอาจจะเพิ่มกราฟสำหรับตัววัดที่ครอบคลุมโหมดการดำเนินการแต่ละโหมด