จัดการ incident ตั้งแต่ตรวจพบจนกู้คืน

ประกาศ incident จากผลกระทบ

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

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

เตรียมช่องทางตอบสนองก่อน release ให้ข้อมูลติดต่อ ขั้นตอนเข้าถึง runbook และช่องทางสื่อสารยังเข้าถึงได้เมื่อบริการหลักไม่พร้อมใช้งาน ฝึกใช้ช่องทางนี้กับ incident สมมติ

มอบหมายหน้าที่ก่อนเปลี่ยนระบบขัดแย้งกัน

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

ใช้ลำดับเวลาเดียวร่วมกัน บันทึกเวลา ข้อสังเกต การกระทำ ผู้ดำเนินการ และผล แยกข้อเท็จจริงจากสมมติฐาน ใช้เขตเวลาเดียวกันและระบุ timestamp ที่ไม่น่าเชื่อถือ

พิจารณา incident ในสถานการณ์สมมติ

เวลาทั้งหมดด้านล่างเป็น UTC องค์กรมอบหมายผู้ประสานงาน incident เมื่อการส่งออกที่ล้มเหลวกระทบลูกค้าหลายราย

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

เวลา 09:10 ลักษณะ incident เปลี่ยนไป การทำให้การส่งออกสำเร็จอีกครั้งไม่เพียงพอแล้ว ทีมต้องประเมินการเปิดเผยข้อมูลที่อาจเกิดขึ้น ควบคุมการเข้าถึง เก็บรักษาหลักฐาน และให้ผู้มีหน้าที่ตัดสินใจที่เหมาะสมเข้าร่วม

บรรเทาปัญหาโดยยังควบคุมการดำเนินการได้

ใช้ runbook ที่ทดสอบแล้วเมื่อเหมาะกับกรณี ตรวจสอบเงื่อนไขก่อน rollback, failover หรือเปลี่ยนข้อมูลรับรอง แอปพลิเคชันเวอร์ชันก่อนอาจไม่รองรับ schema ฐานข้อมูลปัจจุบัน Failover ข้าม Region อาจย้ายข้อมูลเสียหายชุดเดิมไปด้วย

ให้ AI assistant จัดระเบียบหลักฐานที่นำข้อมูลอ่อนไหวออกแล้ว หรือเปรียบเทียบสมมติฐานภายในขอบเขตที่อนุมัติ ผู้ตอบสนองต้องตรวจสอบข้อสรุปของมัน Log และ ticket เป็น input ที่ไม่ควรเชื่อถือ ไม่ใช่อำนาจอนุญาตให้ดำเนินการตามเนื้อหา

สิทธิ์ฉุกเฉินควรมีวัตถุประสงค์ที่อนุมัติ ระยะเวลาจำกัด และบันทึก audit ความเร่งด่วนไม่ได้ทำให้คำสั่งที่ agent เสนอถูกต้อง

ปิดงานกู้คืนและงานติดตามผลแยกกัน

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

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

เรียนต่อเรื่องการดำเนินงานด้านความปลอดภัย และการนำผลกลับมาปรับปรุงให้ครบวงจร