รายการตรวจสอบและคู่มือการตอบสนองต่อเหตุการณ์การหยุดทำงานของเว็บไซต์

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

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

ตอบ-สรุปข้อแรก

เวิร์กโฟลว์การตอบสนองต่อเหตุการณ์การหยุดทำงานของเว็บไซต์ที่มีประสิทธิภาพประกอบด้วยสี่ขั้นตอนสำคัญ: การระบุและคัดแยก (การตรวจสอบฉันทามติการสอบสวนหลายภูมิภาค), การแยกสาเหตุ (การตรวจสอบ DNS, TLS, Edge CDN และเลเยอร์ฐานข้อมูลแบ็กเอนด์), การบรรเทาเหตุการณ์ (การย้อนกลับการปรับใช้ล่าสุดหรือปรับขนาดทรัพยากรเซิร์ฟเวอร์) และการวิเคราะห์หลังการเสียชีวิต (การบันทึกสาเหตุที่แท้จริงและรายการการดำเนินการป้องกัน)การปฏิบัติตามรายการตรวจสอบที่เป็นมาตรฐานจะช่วยลด Mean Time to Recovery (MTTR) จากชั่วโมงเหลือเป็นนาที

ขั้นตอนการทำงานในการคัดแยกเหตุการณ์ทีละขั้นตอน

ระยะที่ 1: การระบุการหยุดทำงานและการคัดแยก (0 - 2 นาที)

1. ตรวจสอบขอบเขตการหยุดทำงาน: ตรวจสอบฉันทามติการสอบสวนหลายภูมิภาคใน SimpleOps เพื่อยืนยันว่าการหยุดทำงานส่งผลกระทบต่อผู้ใช้ทั่วโลกหรือภูมิภาคทางภูมิศาสตร์ที่เฉพาะเจาะจงหรือไม่
2. ตรวจสอบลำดับความสำคัญของการแจ้งเตือน: แยกความแตกต่างระหว่างความล้มเหลวของความพร้อมใช้งานโดยสมบูรณ์ (HTTP 5xx, การหมดเวลาการเชื่อมต่อ TCP) และประสิทธิภาพการทำงานที่ลดลงเฉพาะที่ (LCP > 4.0 วินาที)
3. แจ้งทีมงานที่พร้อมให้ความช่วยเหลือ: กำหนดเส้นทางการอัปเดตเหตุการณ์ไปยังช่องทางแชทของนักพัฒนาภายใน (Slack, Telegram) และมอบหมายผู้บัญชาการเหตุการณ์

ระยะที่ 2: การแยกสาเหตุ (2 - 5 นาที)

1. ตรวจสอบ DNS Resolution Layer: ตรวจสอบว่าเซิร์ฟเวอร์ชื่อโดเมนแก้ไขบันทึก A/AAAA ที่ถูกต้อง และตรวจสอบความล่าช้าในการเผยแพร่ DNS ทั่วโลกหรือข้อผิดพลาดในการล็อกผู้รับจดทะเบียน
2. ตรวจสอบความสมบูรณ์ของใบรับรอง SSL/TLS: ยืนยันวันหมดอายุของใบรับรอง ชื่อทางเลือกของหัวเรื่อง (SAN) และความสมบูรณ์ของห่วงโซ่ความน่าเชื่อถือของ CA
3. ตรวจสอบ Edge CDN และ Reverse Proxy: ตรวจสอบรหัสสถานะการตอบสนอง HTTP ของ Edge (เช่น 502 Bad Gateway, 504 Gateway Timeout, 500 Internal Error) และอัตราส่วนการเข้าถึงแคชของ Edge
4. ประเมินฐานข้อมูลแบ็กเอนด์และเซิร์ฟเวอร์แอปพลิเคชัน: ตรวจสอบการใช้งาน CPU, การใช้งานหน่วยความจำ, ความอิ่มตัวของพูลการเชื่อมต่อ และการล็อคฐานข้อมูล

ระยะที่ 3: การบรรเทาผลกระทบและการแก้ปัญหา (5 - 15 นาที)

1. ดำเนินการย้อนกลับฉุกเฉิน: หากการหยุดทำงานเกิดขึ้นพร้อมกับการปรับใช้โค้ดล่าสุดหรือการเปลี่ยนแปลงโครงสร้างพื้นฐาน ให้ดำเนินการย้อนกลับ CI/CD อัตโนมัติทันที
2. ล้มเหลวผ่านไปยังภูมิภาครอง: เปลี่ยนเส้นทางการรับส่งข้อมูลไปยังโหนดโครงสร้างพื้นฐานที่ซ้ำซ้อนหรือต้นทาง CDN รอง หากเกิดความล้มเหลวของฮาร์ดแวร์ในระดับภูมิภาค
3. ใช้การจำกัดอัตราหรือเซอร์กิตเบรกเกอร์: ปกป้องอินสแตนซ์ฐานข้อมูลระหว่างการรับส่งข้อมูลที่เพิ่มขึ้นอย่างรวดเร็วโดยเปิดใช้งานการจำกัดอัตราหรือปิดใช้งานงานพื้นหลังที่ไม่สำคัญชั่วคราว

ระยะที่ 4: การชันสูตรพลิกศพและการดำเนินการป้องกัน (หลังเหตุการณ์)

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

เมทริกซ์ความรุนแรงของเหตุการณ์

รูปแบบความล้มเหลวทั่วไปและการแก้ไขฉุกเฉิน

1. การหมดแรงของพูลการเชื่อมต่อฐานข้อมูล: รีเซ็ตการเชื่อมต่อที่ใช้งานอยู่หรือเพิ่มขีดจำกัดพูลสูงสุดในไฟล์การกำหนดค่า my.cnf / postgresql.conf
2. ใบรับรอง ACME SSL ที่หมดอายุ: เรียกใช้ Certbot ด้วยตนเองต่ออายุคำสั่งด้วย --force-renewal และตรวจสอบการกำหนดเส้นทางความท้าทาย HTTP-01 ผ่าน Nginx
3. เกตเวย์ Nginx Reverse Proxy 502 ที่ไม่ถูกต้อง: ตรวจสอบกระบวนการเซิร์ฟเวอร์แอปพลิเคชันอัปสตรีม (เช่น อินสแตนซ์ Node.js PM2 หรือไบนารี Go Gin) กำลังทำงานบนพอร์ต 8080 หรือ 4000
4. กระบวนการหน่วยความจำรั่วไหลขัดข้อง: รีสตาร์ทพูลเธรดของผู้ปฏิบัติงานหรืออินสแตนซ์ของแอปพลิเคชัน จากนั้นรวบรวมสแนปชอตหน่วยความจำฮีปดัมพ์สำหรับการทำโปรไฟล์การวินิจฉัย

การสื่อสารและความโปร่งใสของผู้มีส่วนได้ส่วนเสีย

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

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

แนวทางปฏิบัติที่ดีที่สุดในการบำรุงรักษา Playbook ของเหตุการณ์

• ตรวจสอบหลังจากการหยุดทำงานของ SEV-1 ทุกครั้ง: อัปเดตขั้นตอนของขั้นตอนทันทีหลังจากการชันสูตรพลิกศพย้อนหลัง เพื่อปรับปรุงขั้นตอนการคัดแยก
• ตรวจสอบ Hooks อัตโนมัติ: ตรวจสอบให้แน่ใจว่า SimpleOps Webhooks โพสต์การแจ้งเตือนไปยังช่อง Slack และ Telegram โดยอัตโนมัติ
• ขั้นตอนการตอบสนองการเจาะ: ดำเนินการฝึกซ้อมดับเพลิงจำลองทุกไตรมาสเพื่อฝึกอบรมสมาชิกทีมวิศวกรใหม่เกี่ยวกับระเบียบการของเหตุการณ์
• รักษาเส้นทางการยกระดับที่ชัดเจน: อัปเดตรายละเอียดการติดต่อที่สามารถติดต่อได้ระดับรองและระดับอุดมศึกษาในบัญชีรายชื่อการจัดการเหตุการณ์ของคุณ

การใช้ SimpleOps สำหรับการตอบสนองต่อเหตุการณ์อัตโนมัติ

SimpleOps ผสานรวมโดยตรงกับเวิร์กโฟลว์ DevOps ที่ทันสมัย ​​โดยส่งการแจ้งเตือนเหตุการณ์ทันทีผ่าน Slack, Telegram, อีเมล หรือ Webhooks แบบกำหนดเอง เพื่อเริ่มต้นรายการตรวจสอบของทีมของคุณโดยอัตโนมัติเมื่อความล้มเหลวที่ยืนยันครั้งแรก