Chaos Engineering (วิศวกรรมความโกลาหล)
นับตั้งแต่ฉบับพิมพ์ครั้งแรกของหนังสือเล่มนี้ อีกเทคนิคหนึ่งที่ได้รับความสนใจมากขึ้นคือ chaos engineering ตั้งชื่อตามแนวทางที่ใช้ที่ Netflix มันสามารถเป็นแนวทางที่มีประโยชน์เพื่อช่วยพัฒนา resiliency ของคุณ—ไม่ว่าจะเป็นในแง่การมั่นใจว่าระบบของคุณ robust เท่าที่คุณคิด หรือในฐานะส่วนหนึ่งของแนวทางสู่ sustained adaptability ของระบบของคุณ
เดิมทีได้รับแรงบันดาลใจจากงานที่ Netflix ทำภายในองค์กร คำว่า chaos engineering ประสบปัญหาบ้างเพราะคำอธิบายที่สับสนว่ามันหมายถึงอะไร สำหรับหลายคน มันหมายถึง "รันเครื่องมือบนซอฟต์แวร์ของผมแล้วดูว่ามันบอกอะไร" ซึ่งอาจไม่ได้ช่วยอะไรจากความจริงที่ว่าผู้สนับสนุน chaos engineering ที่ออกมาพูดเสียงดังที่สุดหลายคนก็มักจะขายเครื่องมือให้รันบนซอฟต์แวร์ของคุณเพื่อทำ chaos engineering เช่นกัน
การได้นิยามที่ชัดเจนว่า chaos engineering หมายถึงอะไรสำหรับผู้ปฏิบัติงานเป็นเรื่องยาก นิยามที่ดีที่สุด (อย่างน้อยในความคิดของผม) ที่ผมเคยเจอคือ:
Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system's capability to withstand turbulent conditions in production.
ทีนี้ คำว่า system ตรงนี้มีความหมายมาก บางคนอาจมองแคบๆ ว่าเป็นแค่ส่วนประกอบซอฟต์แวร์และฮาร์ดแวร์ แต่ในบริบทของ resilience engineering สิ่งสำคัญคือเราต้องมองว่า system คือทั้งหมดของผู้คน กระบวนการ วัฒนธรรม และแน่นอน ซอฟต์แวร์และ infrastructure ที่ประกอบกันเป็นผลิตภัณฑ์ของเรา นี่หมายความว่าเราควรมอง chaos engineering ในภาพกว้างกว่าแค่ "มาปิดเครื่องบางเครื่องแล้วดูว่าจะเกิดอะไรขึ้น"
Game Days (วัน Game Day)
ก่อนที่ chaos engineering จะมีชื่อเรียก ผู้คนก็เคยจัดกิจกรรม Game Day เพื่อทดสอบความพร้อมของคนสำหรับเหตุการณ์บางอย่าง วางแผนล่วงหน้าแต่ในอุดมคติแล้วเปิดตัวแบบไม่ทันตั้งตัว (สำหรับผู้เข้าร่วม) สิ่งนี้ให้โอกาสคุณทดสอบทีมงานและกระบวนการของคุณในสถานการณ์ที่สมจริงแต่สมมติขึ้น ในช่วงที่ผมทำงานที่ Google นี่เป็นเรื่องปกติมากสำหรับระบบต่างๆ และผมคิดจริงๆ ว่าหลายองค์กรจะได้ประโยชน์จากการจัดกิจกรรมแบบนี้เป็นประจำ Google ไปไกลกว่าการทดสอบง่ายๆ เพื่อจำลองความล้มเหลวของเซิร์ฟเวอร์ และในฐานะส่วนหนึ่งของกิจกรรม DiRT (Disaster Recovery Test) ก็เคยจำลองภัยพิบัติขนาดใหญ่อย่างแผ่นดินไหว 6
Game Day สามารถใช้เพื่อสำรวจจุดอ่อนที่ต้องสงสัยในระบบได้ ในหนังสือของเขา Learning Chaos Engineering , 7 Russ Miles แชร์ตัวอย่างของ Game Day ที่เขาจัดขึ้น ซึ่งถูกออกแบบมาเพื่อตรวจสอบ ส่วนหนึ่งคือการพึ่งพาพนักงานคนเดียวมากเกินไป ที่ชื่อ Bob สำหรับ Game Day นี้ Bob ถูกกักตัวอยู่ในห้องและไม่สามารถช่วยทีมระหว่างการจำลอง outage ได้ แต่ Bob ก็เฝ้าสังเกตอยู่ และในที่สุดก็ต้องเข้ามาแทรกแซง เมื่อทีมงานพยายามแก้ปัญหากับระบบ "ปลอม" กลับดัน login เข้าไปที่ production โดยไม่ตั้งใจ และกำลังทำลายข้อมูล production อยู่ เราคงสรุปได้ว่ามีบทเรียนมากมายที่ได้เรียนรู้หลังจากกิจกรรมนั้น
Production Experiments (การทดลองบน Production)
ขนาดที่ Netflix ดำเนินงานอยู่นั้นเป็นที่รู้จักกันดี เช่นเดียวกับความจริงที่ว่า Netflix ตั้งอยู่บน infrastructure ของ AWS ทั้งหมด ปัจจัยสองอย่างนี้หมายความว่ามันต้องยอมรับความล้มเหลวได้ดี Netflix ตระหนักว่าการวางแผนรับมือความล้มเหลวและการ รู้ จริงๆ ว่าซอฟต์แวร์ของคุณจะรับมือกับความล้มเหลวนั้นเมื่อมันเกิดขึ้นเป็นสองเรื่องที่แตกต่างกัน เพื่อให้บรรลุสิ่งนั้น Netflix กระตุ้น (incites) ให้เกิดความล้มเหลวจริงๆ เพื่อให้แน่ใจว่าระบบของตนทนต่อความล้มเหลวได้ ด้วยการรันเครื่องมือบนระบบของตน
เครื่องมือที่มีชื่อเสียงที่สุดในกลุ่มนี้คือ Chaos Monkey ซึ่งในช่วงเวลาบางช่วงของวันจะปิดเครื่องแบบสุ่มบน production การรู้ว่าสิ่งนี้สามารถและจะเกิดขึ้นบน production หมายความว่านักพัฒนาที่สร้างระบบเหล่านี้ต้องพร้อมรับมือมันจริงๆ Chaos Monkey เป็นแค่ส่วนหนึ่งของ Simian Army บอทความล้มเหลวของ Netflix Chaos Gorilla ถูกใช้เพื่อ take out ทั้ง availability zone (เทียบเท่า data center ของ AWS) ในขณะที่ Latency Monkey จำลองการเชื่อมต่อเครือข่ายที่ช้าระหว่างเครื่อง สำหรับหลายคน บททดสอบสูงสุดว่าระบบของคุณทนทานจริงหรือไม่ อาจเป็นการปล่อย Simian Army ของคุณเองบน production infrastructure ของคุณ
From Robustness to Beyond (จาก Robustness สู่สิ่งที่ไกลกว่า)
เมื่อใช้ในรูปแบบที่แคบที่สุด chaos engineering อาจเป็นกิจกรรมที่มีประโยชน์ในแง่การพัฒนา robustness ของแอปพลิเคชันของเรา จำไว้ว่า robustness ในบริบทของ resilience engineering หมายถึงระดับที่ระบบของเราสามารถรับมือกับปัญหาที่คาดการณ์ได้ Netflix รู้ว่ามันพึ่งพา virtual machine ตัวใดตัวหนึ่งให้พร้อมใช้งานใน production environment ของตนไม่ได้ จึงสร้าง Chaos Monkey เพื่อให้แน่ใจว่าระบบของตนสามารถรอดจากปัญหาที่ คาดการณ์ได้ นี้
ถ้าคุณใช้เครื่องมือ chaos engineering เป็นส่วนหนึ่งของแนวทางในการตั้งคำถามอย่างต่อเนื่องเกี่ยวกับ resilience ของระบบคุณ มันสามารถมีประโยชน์กว้างขวางกว่ามาก การใช้เครื่องมือในพื้นที่นี้เพื่อช่วยตอบคำถาม "จะเกิดอะไรขึ้นถ้า" ที่คุณอาจมี ตั้งคำถามอย่างต่อเนื่องกับความเข้าใจของคุณ สามารถส่งผลกระทบใหญ่กว่ามาก Chaos Toolkit เป็นโปรเจกต์โอเพนซอร์สเพื่อช่วยให้คุณรันการทดลองบนระบบของคุณ และมันได้รับความนิยมมาก Reliably บริษัทที่ก่อตั้งโดยผู้สร้าง Chaos Toolkit เสนอเครื่องมือที่หลากหลายกว่าเพื่อช่วยด้าน chaos engineering โดยทั่วไป แม้ว่าอาจจะ vendor ที่รู้จักกันดีที่สุดในพื้นที่นี้คือ Gremlin
จำไว้ว่า การรันเครื่องมือ chaos engineering ไม่ได้ทำให้คุณ resilient