SRE (Site Reliability Engineering) เป็นแนวทางในการตรวจสอบความพร้อมใช้งานของโครงการเว็บ ถือเป็นกรอบการทำงานสำหรับ DevOps และพูดถึงวิธีที่จะประสบความสำเร็จในการนำแนวปฏิบัติ DevOps ไปประยุกต์ใช้ คำแปลในบทความนี้ บทที่ 6 การตรวจสอบระบบแบบกระจาย книги วิศวกรรมความน่าเชื่อถือของไซต์ จาก Google ฉันเตรียมการแปลนี้ด้วยตัวเองและอาศัยประสบการณ์ของตัวเองในการทำความเข้าใจกระบวนการติดตาม ในช่องโทรเลข @monitorim_it и บล็อกบนสื่อ ฉันยังเผยแพร่ลิงก์ไปยังการแปลบทที่ 4 ของหนังสือเล่มเดียวกันเกี่ยวกับเป้าหมายระดับการบริการด้วย

แปลโดยแมว. สนุกกับการอ่าน!

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

กำหนด

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

การตรวจสอบ

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

การตรวจสอบกล่องขาว

การตรวจสอบตามตัววัดที่แสดงโดยส่วนประกอบของระบบภายใน รวมถึงบันทึก ตัววัดการทำโปรไฟล์ Java Virtual Machine หรือตัวจัดการ HTTP ที่สร้างสถิติภายใน

การตรวจสอบกล่องดำ

การทดสอบพฤติกรรมแอปพลิเคชันจากมุมมองของผู้ใช้

แผงควบคุม

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

การแจ้งเตือน (การแจ้งเตือน)

การแจ้งเตือนที่มีเจตนาให้บุคคลได้รับทางอีเมลหรือวิธีการอื่น ซึ่งอาจเกิดจากข้อผิดพลาดหรือคิวคำขอเพิ่มขึ้น การแจ้งเตือนแบ่งออกเป็น: ตั๋ว อีเมลแจ้งเตือน และข้อความโต้ตอบแบบทันที

สาเหตุที่แท้จริง

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

โหนดและเครื่อง (โหนดและเครื่อง)

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

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

ผลัก

การเปลี่ยนแปลงการกำหนดค่าซอฟต์แวร์

เหตุใดจึงต้องมีการตรวจสอบ?

มีสาเหตุหลายประการที่ต้องตรวจสอบแอปพลิเคชัน:

การวิเคราะห์แนวโน้มระยะยาว

ฐานข้อมูลมีขนาดใหญ่แค่ไหนและเติบโตเร็วแค่ไหน? จำนวนผู้ใช้รายวันเปลี่ยนแปลงอย่างไร?

การเปรียบเทียบประสิทธิภาพ

คำขอเร็วขึ้นบน Acme Bucket of Bytes 2.72 เมื่อเปรียบเทียบกับ Ajax DB 3.14 หรือไม่ คำขอถูกแคชไว้ดีกว่ามากเพียงใดหลังจากการปรากฏของโหนดเพิ่มเติม ไซต์ทำงานช้าลงเมื่อเทียบกับสัปดาห์ที่แล้วหรือไม่?

การแจ้งเตือน (การแจ้งเตือน)

มีบางอย่างเสียหายและมีคนจำเป็นต้องแก้ไข หรือบางอย่างจะพังในไม่ช้าและต้องมีคนตรวจสอบในไม่ช้า

การสร้างแดชบอร์ด

แดชบอร์ดควรตอบคำถามพื้นฐานและรวมบางอย่างจาก “4 สัญญาณทอง” — ความล่าช้า (เวลาแฝง) การรับส่งข้อมูล (การรับส่งข้อมูล) ข้อผิดพลาด (ข้อผิดพลาด) และขนาดโหลด (ความอิ่มตัว)

การดำเนินการวิเคราะห์ย้อนหลัง (การดีบัก)

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

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

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

การกำหนดความคาดหวังที่สมเหตุสมผลสำหรับระบบการติดตาม

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

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

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

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

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

อาการกับสาเหตุ

ระบบการตรวจสอบของคุณควรตอบคำถามสองข้อ: “อะไรพัง” และ “ทำไมมันพัง”
“อะไรพัง” พูดถึงอาการ และ “ทำไมมันพัง” พูดถึงสาเหตุ ตารางด้านล่างแสดงตัวอย่างการเชื่อมต่อดังกล่าว

อาการ
ก่อให้เกิด

รับข้อผิดพลาด HTTP 500 หรือ 404
เซิร์ฟเวอร์ฐานข้อมูลปฏิเสธการเชื่อมต่อ

การตอบสนองของเซิร์ฟเวอร์ช้า
การใช้งาน CPU สูงหรือสายเคเบิลอีเธอร์เน็ตเสียหาย

ผู้ใช้ในทวีปแอนตาร์กติกาจะไม่ได้รับ cat GIF
CDN ของคุณเกลียดนักวิทยาศาสตร์และแมว ดังนั้นที่อยู่ IP บางส่วนจึงถูกขึ้นบัญชีดำ

เนื้อหาส่วนตัวมีให้ใช้งานจากทุกที่
การเปิดตัวซอฟต์แวร์ใหม่ทำให้ไฟร์วอลล์ลืม ACL ทั้งหมดและอนุญาตให้ทุกคนเข้าไปได้

“อะไร” และ “ทำไม” เป็นส่วนสำคัญที่สุดในการสร้างระบบตรวจสอบที่ดีโดยมีสัญญาณสูงสุดและสัญญาณรบกวนน้อยที่สุด

กล่องดำ VS กล่องขาว

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

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

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

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

สี่สัญญาณสีทอง

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

ความล่าช้า

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

การจราจร

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

ข้อผิดพลาด

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

ความอิ่มตัว

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

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

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

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

หมดกังวลเรื่อง “หาง” (หรือเครื่องมือวัดและประสิทธิภาพ)

เมื่อสร้างระบบการตรวจสอบตั้งแต่เริ่มต้น มีสิ่งล่อใจให้พัฒนาระบบตามค่าเฉลี่ย: เวลาแฝงเฉลี่ย การใช้งาน CPU โดยเฉลี่ยของโหนด หรือความสมบูรณ์ของฐานข้อมูลโดยเฉลี่ย อันตรายจากสองตัวอย่างสุดท้ายนั้นชัดเจน: ตัวประมวลผลและฐานข้อมูลถูกกำจัดด้วยวิธีที่ไม่อาจคาดเดาได้ เช่นเดียวกับความล่าช้า หากคุณใช้บริการเว็บด้วยเวลาแฝงเฉลี่ย 100ms โดยมีคำขอ 1000 รายการต่อวินาที คำขอ 1% อาจใช้เวลา 5 วินาที หากผู้ใช้พึ่งพาบริการเว็บดังกล่าวหลายรายการ เปอร์เซ็นไทล์ที่ 99 ของหนึ่งแบ็กเอนด์สามารถกลายเป็นเวลาตอบสนองมัธยฐานของฟรอนต์เอนด์ได้อย่างง่ายดาย

วิธีที่ง่ายที่สุดในการแยกความแตกต่างระหว่างค่าเฉลี่ยที่ช้าและส่วนท้ายที่ช้ามากของคำขอคือการรวบรวมการวัดของคำขอที่แสดงเป็นสถิติ (เครื่องมือที่ดีในการแสดงคือฮิสโตแกรม) แทนที่จะเป็นเวลาแฝงจริง: จำนวนคำขอที่บริการให้บริการซึ่งใช้เวลาระหว่าง 0 มิลลิวินาที และ 10 มิลลิวินาที ระหว่าง 10 มิลลิวินาที ถึง 30 มิลลิวินาที ระหว่าง 30 มิลลิวินาที ถึง 100 มิลลิวินาที ระหว่าง 100 มิลลิวินาที ถึง 300 มิลลิวินาที เป็นต้น การขยายขอบเขตฮิสโตแกรมโดยประมาณแบบเอ็กซ์โปเนนเชียล (ด้วยปัจจัยประมาณ 3) มักเป็นวิธีง่ายๆ ในการแสดงภาพการกระจายตัว ของการร้องขอ

การเลือกระดับรายละเอียดที่เหมาะสมสำหรับการวัด

องค์ประกอบต่างๆ ของระบบจะต้องวัดในระดับรายละเอียดที่ต่างกัน ตัวอย่างเช่น:

• การตรวจสอบการใช้งาน CPU ในช่วงเวลาหนึ่งจะไม่แสดงการเพิ่มขึ้นอย่างรวดเร็วในระยะยาวซึ่งนำไปสู่เวลาแฝงที่สูง
• ในทางกลับกัน สำหรับบริการเว็บที่กำหนดเป้าหมายการหยุดทำงานไม่เกิน 9 ชั่วโมงต่อปี (เวลาทำงานต่อปี 99,9%) การตรวจสอบการตอบสนอง HTTP 200 มากกว่าหนึ่งครั้งหรือสองครั้งต่อนาทีมีแนวโน้มว่าจะเกิดขึ้นบ่อยครั้งโดยไม่จำเป็น
• ในทำนองเดียวกัน การตรวจสอบพื้นที่ฮาร์ดไดรฟ์เพื่อความพร้อมใช้งาน 99,9% มากกว่าหนึ่งครั้งทุกๆ 1-2 นาทีอาจไม่จำเป็น

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

1. วัดโหลด CPU ทุกวินาที
2. ลดรายละเอียดเหลือ 5%
3. รวบรวมตัวชี้วัดทุกนาที

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

ง่ายที่สุดเท่าที่จะทำได้ แต่ไม่ง่ายกว่า

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

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

แหล่งที่มาของภาวะแทรกซ้อนที่อาจเกิดขึ้นไม่มีที่สิ้นสุด เช่นเดียวกับระบบซอฟต์แวร์อื่นๆ การตรวจสอบอาจซับซ้อนมากจนเปราะบางและยากต่อการเปลี่ยนแปลงและบำรุงรักษา

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

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

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

การเชื่อมโยงหลักการเข้าด้วยกัน

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

เมื่อสร้างกฎการติดตามและการแจ้งเตือน การถามคำถามต่อไปนี้สามารถช่วยคุณหลีกเลี่ยงผลบวกลวงและการแจ้งเตือนที่ไม่จำเป็น:

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

คำถามเหล่านี้สะท้อนถึงปรัชญาพื้นฐานเกี่ยวกับการแจ้งเตือนและระบบเตือนภัย:

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

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

การติดตามผลในระยะยาว

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

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

Bigtable SRE: เรื่องราวของการแจ้งเตือนมากเกินไป

โดยทั่วไปโครงสร้างพื้นฐานภายในของ Google จะได้รับการจัดเตรียมและวัดผลโดยเทียบกับระดับบริการ (SLO) เมื่อหลายปีก่อน บริการ SLO ของ Bigtable ขึ้นอยู่กับประสิทธิภาพโดยเฉลี่ยของธุรกรรมสังเคราะห์ที่จำลองไคลเอนต์ที่ใช้งานจริง เนื่องจากปัญหาใน Bigtable และสแต็กพื้นที่เก็บข้อมูลในระดับที่ต่ำกว่า ประสิทธิภาพโดยเฉลี่ยจึงได้รับแรงหนุนจากส่วนท้ายที่ "ใหญ่": ข้อความค้นหา 5% ที่แย่ที่สุดมักจะช้ากว่าข้อความที่เหลืออย่างมาก

การแจ้งเตือนทางอีเมลถูกส่งเมื่อเข้าใกล้เกณฑ์ SLO และระบบส่งการแจ้งเตือน Messenger เมื่อเกิน SLO การแจ้งเตือนทั้งสองประเภทถูกส่งค่อนข้างบ่อย โดยกินเวลาทางวิศวกรรมในปริมาณที่ยอมรับไม่ได้: ทีมงานใช้เวลาจำนวนมากในการจัดเรียงการแจ้งเตือนเพื่อค้นหาส่วนที่เกี่ยวข้องจริงๆ เรามักจะพลาดปัญหาที่ส่งผลกระทบต่อผู้ใช้จริง ๆ เนื่องจากมีการแจ้งเตือนเพียงบางส่วนเท่านั้นสำหรับปัญหาเฉพาะนั้น การแจ้งเตือนจำนวนมากไม่ใช่เรื่องเร่งด่วนเนื่องจากปัญหาที่เข้าใจได้ในโครงสร้างพื้นฐานและได้รับการประมวลผลในวิธีมาตรฐานหรือไม่ได้รับการประมวลผลเลย

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

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

Gmail: การตอบสนองของมนุษย์แบบอัลกอริทึมที่คาดเดาได้

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

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

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

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

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

ระยะยาว

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

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

ข้อสรุป

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

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

ขอบคุณที่อ่านคำแปลจนจบ สมัครสมาชิกช่องโทรเลขของฉันเกี่ยวกับการตรวจสอบ @monitorim_it и บล็อกบนสื่อ.

ที่มา: will.com