หลังจากอ่านเรื่อง Incident response ใน SRE Book
พบว่าเป็นสิ่งที่สำคัญมาก ๆ
เมื่อเกิดปัญหาต่าง ๆ ขึ้นมาบน production server แล้ว
เช่น ทำงานผิดพลาดหรือพัง ระบบ network มีปัญหา และ data หลุด เป็นต้น
เราจะจัดการมันอย่างไร
เนื่องจากยิ่งแก้ได้ช้า ผลกระทบก็ยิ่งมาก
ส่งผลต่อทั้งระบบ การบริการ ลูกค้า และ องค์กร
โดยการจัดการกับ Incident นั้น สามารถแบ่งออกเป็นขั้นตอนดังนี้
- Detect
- Response
- Resolution and Recovery
- Postmortems
ขั้นตอนที่ 1 Detect
เป็นการหาหรือตรวจพบปัญหา ว่าปัญหาเกิดขึ้นตรงไหน
ตรวจหาอย่างไรกัน
ระบบ monitoring/observability ทำการแจ้งมา หรือ ให้ผู้ใช้งานแจ้งมา
เจอแล้วแจ้งอย่างไร ต้องส่ง email หรือ โทร !!
ข้อมูลที่แจ้งมา ควรชัดเจนว่า ต้นเหตุคือที่ไหน
อีกอย่าง ในฐานะคนสร้างและดูแลระบบ
ควรจะรู้ปัญหาตอนที่เกิดขึ้นแล้ว หรือ ควรแจ้งก่อนที่ปัญหาจะเกิดขึ้น กันแน่ ?
ตรงนี้น่าคิดมาก ๆ
ถ้าเราหา หรือ รับรู้ปัญหา ได้ช้า และ ไม่ชัดเจน
การแก้ไขก็ยิ่งช้า
ขั้นตอนที่ 2 Response
ในขั้นตอนนี้ คือ การวิเคราะห์ปัญหาที่เกิดขึ้น พร้อมหาวิธีการแก้ไขปัญหา
ทั้งแก้ไขแบบ short term และ long term
ขั้นตอนนี้ทำงานกันอย่างไร ?
ต้องเรียกคนที่เกี่ยวข้องมาจัดการไหม
ถ้ามีงานในมืออยู่ก็ทิ้งซะ แล้วมาแก้ไข
ตั้ง War room ขึ้นมา เพื่อมาทำการแก้ไขกัน
หรือว่า ทำการวิเคราะห์จากข้อมูลที่มีก่อน
ทั้ง metric, log ต่าง ๆ ว่าเป็นอย่างไร
ปัญหาน่าจะมาจากสาเหตุอะไรบ้าง
จากนั้นค่อยหาวิธีการแก้ไข และ ลงมือทำ
รวมทั้งการทำงานร่วมกัน สำหรับคนที่ใช่จริง ๆ
ขั้นตอนที่ 3 Resolution and Recovery
เมื่อทำการวิเคราะห์ และ หาต้นเหตุของปัญหาเรียบร้อยแล้ว
ก็ต้องทำการแก้ไข เพื่อให้ระบบกลับมาทำงานได้อย่างปกติ
แน่นอนว่า ต้อการการทำงานร่วมกันในหลายส่วน
ทั้ง การออกแบบ วิเคราะห์ พัฒนา ทดสอบ infra network และ deploy
เพื่อทำให้การทำงาน flow หรือ ไหลลื่นมากที่สุด
ยิ่งมีการทำงานแบบ automation เข้ามาช่วย จะยิ่งดี
ที่สำคัญเลือกคน ให้เหมาะกับปัญหาด้วยละ
และต้องคอยดูด้วยว่า ปัญหาเดิมจะไม่กลับมาอีก
และแนวทางในการป้องกันด้วย
ไม่ใช่ผิดซ้ำ ๆ ที่เกิดอยู๋อย่างเสมอ แบบนี้ไม่น่าดีนะ
ขั้นตอนที่ 4 Postmortems
เมื่อปัญหาต่าง ๆ ถูกแก้ไขแล้ว สิ่งที่ควรทำคือ การเรียนรู้ หรือ lesson learn จากปัญหา
เพื่อไม่ให้ปัญหาเหล่านี้เกิดขึ้นมาอีก
ด้วยการเขียนบันทึกปัญหา วิธีการแก้ไข วิธีการที่ควรต้องทำออกมา
นัดประชุมเพื่อสรุป กับหน่วยงานต่าง ๆ ที่เกี่ยวข้องทั้งหมด
รวมทั้งแจ้งปัญหาที่แท้จริง ออกไปให้กับผู้ใช้งาน หรือ ทาง business ด้วย
สิ่งที่ได้จากขั้นตอนนี้ สามารถนำไปใช้ในการ training ภายในของบริษัทได้อีกด้วย
จะได้ไม่ผิดซ้ำ ๆ ที่เดิม โดยในเอกสารประกอบไปด้วย
- การวิเคราะห์ปัญหาที่ผ่านมา
- รูปแบบของปัญหาที่เกิดขึ้น หรือ การหารูปแบบของปัญหาที่อาจจะเกิดขึ้นได้
- แนวทางปฏิบัติ เพื่อป้องกันปัญหาไม่ให้เกิดขึ้น
ไม่ใช่แก้ไขปัญหาด้วยการหาคนมา audit ในสิ่งที่ทำ
โดยไม่แก้ไขปัญหาที่ต้นเหตุ แบบนี้ไม่น่าจะใช่ทางที่ดีไหมนะ !!
ลองมาดูที่ระบบของเราก็บ้าง
เมื่อเกิด incident ขึ้นมา เราจัดการอย่างไรบ้าง ?
Reference Websites
