# สร้างการตรวจสอบที่นำไปสู่การตอบสนองต่อเหตุการณ์ที่มีประโยชน์ | SwissOctet Insights

https://swissoctet.com/th/insights/monitoring-incident-response-playbook/

SwissOctet / ข้อมูลเชิงลึก / การดำเนินงานวันที่สอง การดำเนินงานวันที่สอง ประยุกต์ · อ่าน 4 นาที

สร้างการตรวจสอบที่นำไปสู่การตอบสนองเหตุการณ์ที่มีประโยชน์

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

โดย SwissOctet Editorial บันทึกคู่มือ คัดลอกลิงก์

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

01 เริ่มจากฟังก์ชันที่สำคัญ

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

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

02 เลือกสัญญาณที่มีคุณค่าต่อการวินิจฉัย

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

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

03 ให้ทุกการแจ้งเตือนมีการดำเนินการและผู้รับผิดชอบ

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

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

สภาวะที่สังเกตได้ การตอบสนองที่มีประโยชน์ บริบทที่ควรรวมไว้

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

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

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

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

04 เตรียมโครงสร้างการจัดการเหตุการณ์ขนาดเล็ก

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

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

05 ทดลองสถานการณ์ความเสื่อมประสิทธิภาพที่เป็นรูปธรรม

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

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

06 ปกป้องหลักฐานและตรวจสอบการกู้คืน

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

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

07 เปลี่ยนเหตุการณ์ให้เป็นการปรับปรุงที่วัดผลได้

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

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

เปลี่ยนเป็น行動 รายการตรวจสอบปฏิบัติของคุณ

✓ ตรวจสอบเส้นทางผู้ใช้ที่เป็นตัวแทนและไม่ก่อผลข้างเคียง

✓ เลือกสัญญาณที่อธิบายพฤติกรรมของแอปพลิเคชัน

✓ ให้การแจ้งเตือนมีการดำเนินการ ผู้รับผิดชอบ และเงื่อนไขการกู้คืน

✓ ตกลงการประสานงานและการยกระดับก่อนเกิดเหตุการณ์

✓ ปกป้องหลักฐานและตรวจสอบการกู้คืนที่สมบูรณ์

✓ มอบหมายการปรับปรุงที่ทดสอบได้หลังการทบทวน

ดาวน์โหลดรายการตรวจสอบ

คำถามที่พบบ่อย รายละเอียดที่สำคัญ

การตรวจสอบ uptime ของเซิร์ฟเวอร์เพียงพอหรือไม่ +

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

ทุกเกณฑ์เมตริกควรแจ้งเตือนใครสักคนทันทีหรือไม่ +

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

เหตุการณ์จะถือว่าสิ้นสุดเมื่อใด +

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

แหล่งอ้างอิงหลัก ไปที่ต้นทาง

แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน

Google SRE: การตรวจสอบระบบแบบกระจาย sre.google

Google SRE Workbook: การตอบสนองต่อเหตุการณ์ sre.google

NIST SP 800-61 Rev. 3: การตอบสนองต่อเหตุการณ์ csrc.nist.gov

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

เชื่อมโยงความรู้ โครงสร้างพื้นฐานที่เกี่ยวข้อง

Vector VPS สวิตเซอร์แลนด์ Metal Atlas สวิตเซอร์แลนด์ Transit 40 สวิตเซอร์แลนด์

รักษาสายไว้ บันทึกภาคสนามถัดไปของคุณ

สำรวจทุกคู่มือ

บันทึกภาคสนาม / 01

+

การดำเนินงานวันที่สอง ประยุกต์

สร้างการสำรองข้อมูลที่คุณกู้คืนได้จริง

เลือกเป้าหมายการกู้คืน ปกป้องสำเนาอิสระ และฝึกการกู้คืนก่อนที่เหตุการณ์จะบังคับให้ต้องทำ

อ่าน 4 นาที อ่านคู่มือ

บันทึกภาคสนาม / 02

+

การดำเนินงานวันที่สอง ประยุกต์

แบบจำลองภัยคุกคามเชิงปฏิบัติสำหรับโครงการโฮสติ้งของคุณ

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

อ่าน 6 นาที อ่านคู่มือ

บันทึกภาคสนาม / 03

+

การดำเนินงานวันที่สอง ประยุกต์

การดูแลระบบ Windows RDP อย่างปลอดภัยโดยไม่สูญเสียการเข้าถึง

แยกการเข้าถึงเครือข่าย การพิสูจน์ตัวตน และสิทธิ์ออกจากกัน จากนั้นยืนยันเส้นทางกู้คืนก่อนจำกัดการเข้าถึงระยะไกล

อ่าน 6 นาที อ่านคู่มือ