บทเรียน 20 ปีที่ได้รับจาก Site Reliability Engineering (SRE)
บทเรียนด้านวิศวกรรมความเชื่อถือได้ที่ได้จาก YouTube
-
การเลือกมาตรการลดความเสี่ยง
- เมื่อเกิดข้อผิดพลาดร้ายแรง ควรเลือกมาตรการลดความเสี่ยงให้เหมาะสมตามระดับความรุนแรงของข้อผิดพลาดนั้น
- มาตรการลดความเสี่ยงที่มากเกินไปอาจก่อให้เกิดผลข้างเคียง และควรทำเช่นนั้นก็ต่อเมื่อมีเหตุผลอันสมควรที่จะข้ามขั้นตอนมาตรฐานเท่านั้น
-
การทดสอบกลไกการกู้คืนเพื่อเตรียมพร้อมรับสถานการณ์ฉุกเฉิน
- ควรฝึกซ้อมและทดสอบกลไกการกู้คืนและมาตรการบรรเทาไว้ล่วงหน้าอย่างเพียงพอ เพื่อให้สามารถรับมือได้อย่างมีประสิทธิภาพแม้ในสถานการณ์วิกฤต
- การทดสอบช่วยลดความเสี่ยงในอนาคตและเพิ่มขีดความสามารถในการตอบสนอง
-
การค่อย ๆ นำการเปลี่ยนแปลงไปใช้ (ใช้การทดสอบ Canary)
- ก่อนปล่อยการเปลี่ยนแปลงออกใช้งานทั้งหมด ควรทยอยนำไปใช้เพื่อไม่ให้กระทบทั้งระบบหากเกิดปัญหา
- จากกรณีการเปลี่ยนแปลงการตั้งค่าแคชของ YouTube ทำให้ตระหนักว่าแม้เป็นการเปลี่ยนแปลงเล็กน้อย ก็ยังต้องมีการนำไปใช้อย่างเป็นระบบ
บทเรียนที่ได้จาก Google Calendar
-
ความสำคัญของฟังก์ชันหยุดฉุกเฉิน
- สำหรับการเปลี่ยนแปลงที่มีความเสี่ยงแฝง จำเป็นต้องมีฟังก์ชันอย่าง "ปุ่มแดงใหญ่" ที่ช่วยตอบสนองได้อย่างรวดเร็ว
- ควรเตรียมฟังก์ชันหยุดฉุกเฉินไว้เพื่อรับมือกับการพึ่งพาบริการต่าง ๆ
-
ความจำเป็นของการทดสอบแบบบูรณาการ
- แม้การทดสอบหน่วยจะมีประโยชน์ในขอบเขตจำกัด แต่ควรใช้การทดสอบแบบบูรณาการร่วมกับสภาพแวดล้อมจริงเพื่อตรวจสอบความเหมาะสมของระบบ
- จากกรณีข้อผิดพลาดของ Google Calendar ทำให้ตระหนักถึงความสำคัญของการทดสอบตามเส้นทางการใช้งานจริง
บทเรียนของ Google ในปี 2017
-
ความสำคัญของช่องทางสื่อสารสำหรับสถานการณ์ฉุกเฉิน
- จำเป็นต้องเตรียมช่องทางสื่อสารและช่องทางสำรองไว้
- เมื่อบริการหยุดชะงัก ควรมีวิธีการสื่อสารหลายรูปแบบที่ไม่พึ่งพากัน และต้องทดสอบประสิทธิภาพของวิธีเหล่านั้น
-
การคงไว้ซึ่งฟังก์ชันขั้นต่ำเมื่อประสิทธิภาพลดลง
- เพื่อไม่ให้บริการหยุดทำงานทั้งหมด ควรออกแบบให้ยังสามารถให้บริการฟังก์ชันพื้นฐานได้แม้ในภาวะที่ประสิทธิภาพลดลง
การทดสอบด้านความทนทานต่อภัยพิบัติ
- การทดสอบความทนทานและความสามารถในการฟื้นตัวจากภัยพิบัติ
- ควรทดสอบความสามารถในการฟื้นตัวของบริการหรือระบบ เพื่อให้มั่นใจว่ายังดำเนินต่อไปได้แม้เกิดสถานการณ์ภัยพิบัติ
- ควรตรวจสอบผ่านการทดสอบการกู้คืนว่าระบบสามารถกลับสู่สภาวะปกติได้หลังจากหยุดชะงัก
ความสำคัญของมาตรการบรรเทาแบบอัตโนมัติ
- การทำมาตรการบรรเทาให้เป็นอัตโนมัติ
- เมื่อเกิดความขัดข้องของเครือข่ายหลายจุด ควรใช้มาตรการบรรเทาแบบอัตโนมัติแทนการจัดการด้วยมือ เพื่อลดเวลาในการแก้ปัญหา
การลดช่วงเวลาระหว่างการปล่อยใช้งาน
-
การทำ rollout ให้บ่อยครั้ง
- ช่วงเวลาที่ห่างกันนานระหว่าง rollout เป็นปัจจัยในการประเมินความปลอดภัยของระบบ
-
ฮาร์ดแวร์เวอร์ชันเดียวทั่วโลกคือจุดล้มเหลวเพียงจุดเดียว
- การพึ่งพาเพียงโมเดลเฉพาะรุ่นเดียวอาจทำให้การปฏิบัติการง่ายขึ้น แต่หากรุ่นนั้นมีปัญหา ก็อาจทำให้การทำงานสำคัญหยุดชะงักได้
- การมี network backbone ที่หลากหลายช่วยป้องกันการหยุดชะงักทั้งระบบ และยังทำให้สามารถ route ทราฟฟิกที่มีลำดับความสำคัญสูงไปยังทางเลือกอื่นที่ยังทำงานอยู่ได้
ยังไม่มีความคิดเห็น