จากบทความเรื่อง How We Improved Application’s Resiliency by Uncovering Our Hidden Issues Using Chaos Testing
ทำการอธิบายเกี่ยวกับ Chaos Testing ว่าเป็นอย่างไร มีที่มาอย่างไร
มีข้อดีข้อเสียอะไรบ้าง
เหตุใดถึงต้องทำด้วย
ไม่ใช่ความรู้ใหม่ แต่ทำไม่เยอะเท่านั้นเอง
Chaos Testing เกิดจากระบบที่มีความซับซ้อน
ต้องทำงานร่วมกันหลาย ๆ ส่วนงาน (integration system)
ยิ่งแยก service ออกมาจำนวนมาก
หรือมี server จำนวนมากขึ้น
ก็ต้องทำให้มั่นใจว่าระบบจะสามารถทำงานได้
และสิ่งที่ต้องคิดไว้เสมอคือ เรื่องของ resiliency
เพื่อเพิ่มความเชื่อมั่นให้กับระบบ
ว่าเมื่อเกิดปัญหาขึ้นมาแล้วระบบยังคงทำงานได้ปกติ
หรือสามารถ recovery กลับมาได้เอง
เป็นการทดสอบแบบ proactive นั่นหมายความว่า
เราต้องทำการระบุเป้าหมายว่าต้องการอะไร
ทำการสร้าง scenario ขึ้นมา
เตรียม environment ขึ้นมา
จากนั้นจำลองสถานการณ์ขึ้นมา เพื่อหาจุดที่เกิดปัญหาตามที่ต้องการ
หรือบางครั้งก็ทำการ random event ต่าง ๆ ที่จะทำให้ระบบพังขึ้นมาได้
บ่อยครั้งการทดสอบประเภทนี้ จะพบเจอได้บน production เท่านั้น
เพราะว่ามีการใช้งานที่หลายหลายกว่า และตรงกว่า
ดังนั้นจึงต้องระมัดระวัง และต้องมีระบบ monitoring และ observability ที่ดีด้วย
อีกอย่างที่มักจะพบปัญหาของการทดสอบหลาย ๆ ที่
ชอบทดสอบเฉพาะส่วนที่สนใจ หรือ ที่ทำเท่านั้น
ส่วนระบบที่ไปเรียกใช้ กลับทำการจำลองทั้งหมด
ทำให้ทำงานได้ตามที่คาดหวัง
แต่กลับไม่เชื่อมต่อจริง ๆ ซึ่งส่งผลให้เจอปัญหามากมาย และ ไม่คาดฝันตามมาอีกเพียบ
ในบทความสรุปเรื่อง Principles of chaos testing
ประกอบไปด้วย
- Identify a steady state
- Hypothesize that the system will hold its steady state
- Ensure minimal impact to your users ตรงนี้สำคัญมาก ๆ เป็นเป้าหมายหลักเลย
- Introduce chaos
- Monitor and repeat ขาดไม่ได้ !! ถ้าขาดทั้ง monitoring และ observability อย่าทำเด็ดขาด
ความยากของการทำ Chaos testing คือการทำความเข้าใจว่าทำไมต้องทำ !!
ดังนั้นจำเป็นต้องอธิบายให้เข้าใจ ว่าทำไม อะไร อย่างไร ต่อไป
หรือเราจำเป็นต้องทำไหม
กระทบต่อ business มากน้อยเพียงใด
Reference Websites
