Chaos Engineering
มีคำกล่าวว่า “If it hurts, do it more often” คำกล่าวนี้ดูเหมือนจะจริงในโลก IT ซึ่ง concept นี้มันไปตรงกับ practice ต่างๆ มากมาย เช่น agile (development ยิ่งรอบสั้น cost of change ก็จะยิ่งน้อยลง), CI/CD (ยิ่ง deliver บ่อย, ต้นทุนการเตรียมการก็ยิ่งลดลง, และแก้ปัญหาได้เร็วขึ้น), lean (เอาของที่เป็น MVP ให้ลูกค้าใช้ก่อน เพื่อลองตลาด และปรับรูปแบบได้เร็วขึ้น)
การทำบ่อยๆ เป็นการกระจายความผิดพลาด (ลดผลกระทบต่อธุรกิจ) เพิ่ม feedback loop (ทำให้แก้ปัญหาได้เร็วขึ้น) และทำให้เกิดความ efficient เนื่องจากเราต้องทำบ่อยๆ ก็หาทาง automate มันซะ, เนื่องจากต้องตัดสินใจบ่อยๆ เลยต้องมี monitor เยอะๆ, และเนื่องจากต้องแก้ปัญหาบ่อยๆ ก็ต้องมี tool พร้อม
Chaos เป็น concept ของ Netflix สำหรับการแก้ปัญหา หรือลดผลกระทบจากปัญหา ประเด็นคือ ปัญหามักจะเกิดจากเหตุไม่คาดฝัน แล้วเราจะทำมันบ่อยๆ ได้อย่างไร?
คำตอบก็คือ ก็ทำให้ปัญหามันเกิดขึ้นไปเลยครับ
ขั้นตอนการทำ Chaos Engineering มี 4 ขั้นตอนง่ายๆ ดังนี้
- กำหนดตัวชี้วัด
ตัวชี้วัดที่ดีต้องวัดผลในแง่ธุรกิจ อย่างกรณีของ Netflix คือ Streams per second
2. ออกแบบเพื่อรองรับสิ่งเลวร้าย
คิดถึง incident ที่ทำให้ ตัวชี้วัดเราไปไม่ถึงเป้า ตัวอย่างเช่น
- services ตาย, ช้า, หรือ return errors
- cache หรือ db ตาย
- มี spike requests
โดย pattern ปกติเพื่อแก้ปัญหาข้างต้น คือ timeout, retry, แล้วก็ fallback ซึ่งทำให้ Netflix มี library สำหรับ handle เรื่องนี้โดยเฉพาะ เรียกว่า Hystrix
ตอนออกแบบ ให้คิดถึงการป้องกัน Cascading Failure ด้วย เช่น ถ้า cache ตาย ระบบไม่ควรให้ load ทั้งหมดมาที่ db เพราะจะทำให้ db ตายไปด้วย
3. ทดสอบ
ขั้นตอนที่สนุกที่สุดก็คืออันนี้แหละครับ ทำลาย services เล่นๆ มั่วๆ และก็อาจมี feature switch เพื่อทำให้ app ช้า หรือ return error ด้วยก็ได้ เหตุผลที่ต้อง random เพราะจะดูว่า เมื่อเกิดเหตุการณ์จริง เราจะมี log หรือ metric ที่รองรับสถานการณ์ได้หรือเปล่า
และเมื่อทดสอบจนมั่นใจแล้ว ด่านสุดท้ายคือ production environment เป็นอะไรที่ random ที่สุด behavior ของ user มักจะหลากหลาย และเล่นอะไรที่เราคาดไม่ถึง จำนวน load บน production ก็สมจริงที่สุด ทดลองบน production แล้วเตรียมพร้อมที่จะแก้ไข ดีกว่าเกิดเหตุผิดพลาดแล้วเรารับมือไม่ได้
Netflix คิดว่าการทดสอบเพื่อทำลาย services นี้เป็นอะไรที่ควรทำเป็นประจำ ถึงขนาดมีเครื่องมือสำหรับทำลาย services แบบ random เรียกว่า ChaosMonkey
แต่ละธุรกิจมีข้อจำกัดที่ต่างกัน การสร้าง fail บน production อาจสร้างปัญหาให้ลูกค้าโดยไม่จำเป็น การทดสอบบน production เป็นวิจารณญาณส่วนบุคคลนะครับ และทุกครั้งที่ test บน production อย่าลืมเตรียม rollback plan ด้วยทุกครั้ง เผื่อกรณีเกิดเหตุผิดพลาดจริงๆ
4. วัดผล
ตัวชี้วัดที่เรากำหนดในข้อ 1 หลังจากทดสอบแล้วดูผลลัพธ์ว่าผลที่ได้ตามเป้าหรือไม่ ยิ่งตัวเลขใกล้เป้าหมาย ยิ่งหมายถึงความน่าเชื่อถือที่ดีของระบบของคุณ