ตรวจสอบฟังก์ชันที่ผู้ใช้มองเห็น เพิ่มหลักฐานด้านทรัพยากรและแอปพลิเคชันให้เพียงพอต่อการวินิจฉัย และแจ้งเตือนเฉพาะสภาวะที่ต้องมีการดำเนินการของมนุษย์อย่างทันท่วงที จับคู่การแจ้งเตือนแต่ละรายการกับผู้รับผิดชอบ ขั้นตอนแรก และการยกระดับ ในระหว่างเหตุการณ์ ให้ประสานการบรรเทาผลกระทบ ปกป้องหลักฐาน และตรวจสอบการกู้คืนผ่านเส้นทางผู้ใช้จริง
เริ่มจากฟังก์ชันที่สำคัญ
เซิร์ฟเวอร์ที่ตอบสนองต่อ ping ไม่ได้พิสูจน์ว่าแอปพลิเคชันทำงานได้ เลือกเส้นทางผู้ใช้ที่เป็นตัวแทนและไม่ก่อผลข้างเคียง เช่น การเรียกดูหน้าสาธารณะหรือการเข้าถึงปลายทางการทดสอบที่ควบคุมไว้ กำหนดว่าความสำเร็จมีลักษณะอย่างไร และหลีกเลี่ยงการตรวจสอบแบบสังเคราะห์ที่สร้างคำสั่งซื้อจริง เผยแพร่เนื้อหา หรือส่งการแจ้งเตือนลูกค้าในทุกครั้งที่ทำงาน
ตรวจสอบจากมุมมองภายนอกที่เหมาะสมเช่นเดียวกับจากภายในแอปพลิเคชัน การสังเกตจากภายนอกสามารถเปิดเผยปัญหาการเข้าถึงหรือการกำหนดเส้นทางที่เซิร์ฟเวอร์มองไม่เห็น การวัดภายในสามารถอธิบายได้ว่าเส้นทางผู้ใช้ล้มเหลวเพราะเหตุใด เชื่อมโยงมุมมองทั้งสองเข้ากับฟังก์ชัน แทนการรวบรวมแดชบอร์ดขนาดใหญ่เพียงเพราะมีเมตริกทุกตัวพร้อมใช้
เลือกสัญญาณที่มีคุณค่าต่อการวินิจฉัย
คำแนะนำ SRE ของ Google เน้นความหน่วง ทราฟฟิก ข้อผิดพลาด และความอิ่มตัวเป็นสัญญาณที่มีประโยชน์สำหรับระบบที่ผู้ใช้เข้าถึง ใช้สิ่งเหล่านี้เพื่ออธิบายพฤติกรรม: เวลาตอบสนอง ปริมาณคำขอ คำขอที่ไม่สำเร็จ และแรงกดดันต่อทรัพยากรที่มีจำกัด เลือกการวัดที่เหมาะสมกับแอปพลิเคชัน แทนการสันนิษฐานว่านิยามเมตริกเดียวใช้ได้กับเว็บไซต์ บริการถ่ายโอนข้อมูล และเวิร์กเกอร์เบื้องหลัง
แยกพฤติกรรมของคำขอที่สำเร็จและล้มเหลวในจุดที่สำคัญ และตรวจสอบผลลัพธ์ในส่วนท้ายที่ช้าแทนค่าเฉลี่ยเพียงอย่างเดียว เพิ่มแรงกดดันหน่วยความจำ พื้นที่ดิสก์ ความลึกของคิว หรือขีดจำกัดเฉพาะแอปพลิเคชันเมื่อสิ่งเหล่านั้นอธิบายบริการได้ ค่า CPU ที่สูงอาจเป็นเรื่องปกติระหว่างงานแบบกลุ่มที่มีประโยชน์ ผลกระทบที่ผู้ใช้มองเห็นเป็นตัวกำหนดว่าจำเป็นต้องดำเนินการทันทีหรือไม่
ให้ทุกการแจ้งเตือนมีการดำเนินการและผู้รับผิดชอบ
การแจ้งเตือนควรระบุฟังก์ชันที่ได้รับผลกระทบ สภาวะที่สังเกตได้ และการตรวจสอบเบื้องต้นที่มีประโยชน์ กำหนดผู้รับผิดชอบและเส้นทางการยกระดับก่อนนำไปใช้ แยกแยะสภาวะที่ต้องขัดจังหวะอย่างรวดเร็วออกจากรายการที่เหมาะกับการทบทวนตามกำหนด การแจ้งเตือนซ้ำ ๆ ที่มีคุณค่าต่ำจะฝึกให้ผู้ปฏิบัติงานเพิกเฉยต่อระบบและทำให้สัญญาณสำคัญจดจำได้ยากขึ้น
ใช้การทบทวนการแจ้งเตือนขนาดเล็กเพื่อขจัดความคลุมเครือ ตารางตัวอย่างนี้อธิบายการตัดสินใจด้านการตรวจสอบที่เป็นไปได้ ไม่ใช่ความครอบคลุมการสนับสนุนของ SwissOctet หรือคำมั่นเรื่องความพร้อมใช้งาน เกณฑ์ต่าง ๆ ต้องได้รับการทดสอบเทียบกับค่าพื้นฐานของแอปพลิเคชันจริง รวมเงื่อนไขการกู้คืนเพื่อให้ผู้ปฏิบัติงานรู้ว่าการแจ้งเตือน cleared เมื่อใดและยังต้องตรวจสอบอะไร
| สภาวะที่สังเกตได้ | การตอบสนองที่มีประโยชน์ | บริบทที่ควรรวมไว้ |
|---|---|---|
| เส้นทางผู้ใช้ที่เป็นตัวแทนล้มเหลว | ประเมินผลกระทบและบรรเทา | ปลายทางที่ได้รับผลกระทบ ระยะเวลา และการเปลี่ยนแปลงล่าสุด |
| ดิสก์ใกล้ถึงขีดจำกัดที่วางแผนไว้ | ทบทวนการเติบโตและการเก็บรักษา | ปริมาณ อัตราการเติบโต และพื้นที่ว่างที่ปลอดภัย |
| การตรวจสอบการสำรองข้อมูลล้มเหลว | ปกป้องเส้นทางการกู้คืน | งาน จุดที่ใช้งานได้ล่าสุด และข้อผิดพลาด |
| ความหน่วงเพิ่มขึ้นระหว่างการเผยแพร่ | ตรวจสอบหรือย้อนกลับการเปลี่ยนแปลง | ค่าพื้นฐาน เวลาที่เผยแพร่ และคำขอที่ได้รับผลกระทบ |
เตรียมโครงสร้างการจัดการเหตุการณ์ขนาดเล็ก
กระบวนการตอบสนองควรเข้าใจได้ภายใต้แรงกดดัน ระบุผู้ประสานงาน ผู้ที่ทำงานด้านเทคนิค และผู้รับผิดชอบการอัปเดต เมื่อเหตุการณ์ใหญ่พอที่จะต้องมีบทบาทแยกกัน โครงการขนาดเล็กอาจรวมบทบาท แต่ก็ยังได้ประโยชน์จากจุดตัดสินใจที่ชัดเจนหนึ่งจุด ตกลงช่องทางการสื่อสารก่อนที่บริการจะล้มเหลว
เอกสารการตอบสนองต่อเหตุการณ์ของ Google เน้นการประสานงานและแนวทางที่ให้ความสำคัญกับการบรรเทาผลกระทบก่อน นำสิ่งนั้นไปใช้ในระดับที่เหมาะกับโครงการ: กำหนดผลกระทบ เลือกการดำเนินการที่ปลอดภัย และหลีกเลี่ยงผู้ปฏิบัติงานหลายคนที่ทำให้เกิดการเปลี่ยนแปลงขัดแย้งกัน บันทึกไทม์ไลน์และการตัดสินใจ การค้นหาคำอธิบายที่สมบูรณ์แบบไม่ควรทำให้มาตรการที่ปลอดภัยซึ่งฟื้นฟูฟังก์ชันที่ได้รับผลกระทบล่าช้า
ทดลองสถานการณ์ความเสื่อมประสิทธิภาพที่เป็นรูปธรรม
ลองจินตนาการว่าไซต์เริ่มช้าลงหลังการเผยแพร่ การตรวจสอบภายนอกแสดงเวลาที่ใช้เสร็จสิ้นเพิ่มขึ้น ขณะที่การวัดภายในแสดงข้อผิดพลาดของแอปพลิเคชันและงานฐานข้อมูลที่เพิ่มขึ้น ผู้ประสานงานประกาศเหตุการณ์ที่มีขอบเขตชัดเจน ปกป้องหลักฐาน และมอบหมายให้คนหนึ่งเปรียบเทียบการเผยแพร่กับค่าพื้นฐาน อีกคนเตรียมเส้นทางการย้อนกลับที่ทดสอบแล้ว แทนการเปลี่ยนแปลงโครงสร้างพื้นฐานที่ไม่เกี่ยวข้อง
หากการย้อนกลับปลอดภัยต่อสถานะข้อมูลของแอปพลิเคชัน ให้ใช้และสังเกตผลลัพธ์ หากไม่ปลอดภัย ให้เลือกการบรรเทาผลกระทบที่แคบลงซึ่งได้รับการสนับสนุนจากแผนการดำเนินงาน บันทึกสิ่งที่เปลี่ยนแปลงและเมื่อใด VPS หรือพอร์ตที่ใหญ่ขึ้นอาจคุ้มค่าที่จะประเมินในภายหลัง แต่การตัดสินใจในทันทีควรตอบสนองต่อหลักฐาน แทนการสันนิษฐานว่าขนาดโครงสร้างพื้นฐานเป็นสาเหตุ
ปกป้องหลักฐานและตรวจสอบการกู้คืน
บันทึกการดำเนินงานและบันทึกเหตุการณ์อาจมีที่อยู่ ตัวระบุ และข้อมูลลูกค้า เก็บรวบรวมสิ่งที่การสอบสวนต้องการ จำกัดการเข้าถึง และเก็บข้อมูลรับรองหรือโทเค็นคำสั่งซื้อส่วนตัวออกจากรายงานที่แชร์ สำหรับเหตุการณ์ด้านความปลอดภัยที่ต้องสงสัย ให้เก็บรักษาหลักฐานที่เหมาะสมและปฏิบัติตามนโยบายการตอบสนองของโครงการ แทนการทำลายข้อมูลผ่านการล้างข้อมูลอย่างเร่งรีบ
คำแนะนำการตอบสนองต่อเหตุการณ์ของ NIST วางการตอบสนองไว้ในกรอบการจัดการความเสี่ยงด้านความปลอดภัยไซเบอร์ที่กว้างขึ้น การกู้คืนรวมถึงการตรวจสอบฟังก์ชันที่ต้องการและแก้ไขสภาวะที่ทำให้เกิดเหตุการณ์ ทดสอบเส้นทางผู้ใช้ ทบทวนพฤติกรรมทรัพยากร และตรวจสอบงานเบื้องหลังก่อนปิดการตอบสนอง การแจ้งเตือนที่ cleared หรือโปรเซสที่รีสตาร์ทเพียงอย่างเดียวอาจไม่แสดงให้เห็นถึงการกลับสู่บริการที่มีประโยชน์อย่างสมบูรณ์
เปลี่ยนเหตุการณ์ให้เป็นการปรับปรุงที่วัดผลได้
เขียนการทบทวนสั้น ๆ เกี่ยวกับผลกระทบ ไทม์ไลน์ สภาวะที่ contribut และการดำเนินการที่ทำไป เน้นการเปลี่ยนแปลงที่ตรวจสอบได้: ปรับปรุงการตรวจสอบ แก้ไขสิทธิ์ ซ้อมการย้อนกลับ หรือเพิ่ม dependency การกู้คืนที่ขาดหายไป กำหนดผู้รับผิดชอบและเกณฑ์ความสำเร็จ หลีกเลี่ยงรายการความตั้งใจที่คลุมเครือยาวเหยียดซึ่งไม่มีใครยืนยันได้ในภายหลังว่าได้ดำเนินการแล้ว
เมื่อปรับใช้บน SwissOctet ให้วางแผนการตรวจสอบและการตอบสนองเป็นส่วนหนึ่งของการดำเนินงานของแอปพลิเคชัน แยกจากฮาร์ดแวร์ที่เลือกและข้อตกลงการจัดการที่ยืนยันแล้ว แค็ตตาล็อกไม่ได้ยืนยันว่ามีทีมตอบสนองเหตุการณ์ที่มีเจ้าหน้าที่ประจำหรือชั่วโมงสนับสนุนต่อเนื่อง ตัดสินใจว่าใครได้รับการแจ้งเตือน ใครสามารถดำเนินการได้ และข้อกำหนดบริการจริงครอบคลุมอะไรบ้าง ก่อนพึ่งพาสภาพแวดล้อมโปรดักชัน
รายการตรวจสอบปฏิบัติของคุณ
- ตรวจสอบเส้นทางผู้ใช้ที่เป็นตัวแทนและไม่ก่อผลข้างเคียง
- เลือกสัญญาณที่อธิบายพฤติกรรมของแอปพลิเคชัน
- ให้การแจ้งเตือนมีการดำเนินการ ผู้รับผิดชอบ และเงื่อนไขการกู้คืน
- ตกลงการประสานงานและการยกระดับก่อนเกิดเหตุการณ์
- ปกป้องหลักฐานและตรวจสอบการกู้คืนที่สมบูรณ์
- มอบหมายการปรับปรุงที่ทดสอบได้หลังการทบทวน
รายละเอียดที่สำคัญ
การตรวจสอบ uptime ของเซิร์ฟเวอร์เพียงพอหรือไม่+
ไม่เพียงพอ เครื่องที่เข้าถึงได้อาจโฮสต์แอปพลิเคชันที่เสียหายได้ ตรวจสอบฟังก์ชันที่ผู้ใช้พึ่งพาและเพิ่มหลักฐานด้านทรัพยากรเพื่อวินิจฉัยความล้มเหลว
ทุกเกณฑ์เมตริกควรแจ้งเตือนใครสักคนทันทีหรือไม่+
ไม่ ควรสงวนการขัดจังหวะเร่งด่วนไว้สำหรับสภาวะที่ต้องดำเนินการและต้องการความสนใจอย่างทันท่วงที ส่งงานที่มีความสำคัญต่ำกว่าเข้าสู่กระบวนการทบทวนที่มีผู้รับผิดชอบชัดเจน
เหตุการณ์จะถือว่าสิ้นสุดเมื่อใด+
หลังจากตรวจสอบฟังก์ชันที่ได้รับผลกระทบและงานเบื้องหลังที่เกี่ยวข้องแล้ว ความเสี่ยงในทันทีได้รับการจัดการ และการดำเนินการติดตามผลถูกบันทึกไว้ การรีสตาร์ทโปรเซสเพียงอย่างเดียวไม่เพียงพอ
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- Google SRE: การตรวจสอบระบบแบบกระจาย sre.google
- Google SRE Workbook: การตอบสนองต่อเหตุการณ์ sre.google
- NIST SP 800-61 Rev. 3: การตอบสนองต่อเหตุการณ์ csrc.nist.gov
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก