Knightmare: เรื่องเตือนใจของ DevOps (2014)

• บทความที่เล่าเรื่องเตือนใจของ Knight Capital Group บริษัทบริการทางการเงินรายใหญ่ระดับโลกในปี 2012 ซึ่งล้มละลายในเวลาเพียง 45 นาทีจากการปรับใช้ซอฟต์แวร์ที่ล้มเหลว
• ในปี 2012 Knight Capital Group เป็นผู้ซื้อขายหุ้นรายใหญ่ที่สุดของสหรัฐฯ โดยมีปริมาณการซื้อขายเฉลี่ยต่อวันมากกว่า 3.3 พันล้านรายการ และมีมูลค่าการซื้อขายมากกว่า 2.1 หมื่นล้านดอลลาร์ต่อวัน
• บริษัทได้อัปเดต SMARS ซึ่งเป็นเราเตอร์อัลกอริทึมความเร็วสูงแบบอัตโนมัติ ระหว่างการเตรียมเปิดตัว Retail Liquidity Program ใหม่ของ NYSE
• การอัปเดตนี้มีเป้าหมายเพื่อแทนที่โค้ดเก่าที่ไม่ได้ใช้งานชื่อว่า "Power Peg" ซึ่ง Knight ไม่ได้ใช้มาเป็นเวลา 8 ปี
• โค้ดใหม่ถูกปรับใช้ด้วยมือไปยังเซิร์ฟเวอร์ 8 เครื่อง แต่เนื่องจากความผิดพลาดของช่างเทคนิค ทำให้มีเซิร์ฟเวอร์ 1 เครื่องที่ไม่ได้คัดลอกโค้ดใหม่ ส่งผลให้โค้ด Power Peg เก่าถูกเปิดใช้งาน
• ฟังก์ชัน Power Peg เริ่มทำการ route เพื่อดำเนินการ child order โดยไม่ติดตามจำนวนหุ้นของ parent order ส่งผลให้เกิดลูปคำสั่งแบบไม่สิ้นสุด
• เมื่อเปิดตลาด ระบบของ Knight ได้ถล่มตลาดด้วยคำสั่งซื้อขาย ทำให้หุ้นบางตัวพุ่งขึ้นเกิน 10% ของมูลค่า และบางตัวลดลงเพื่อตอบสนองต่อธุรกรรมที่ผิดพลาด
• ระบบของ Knight ส่งอีเมลอัตโนมัติ 97 ฉบับที่อ้างอิงถึง SMARS และระบุข้อผิดพลาดว่า "Power Peg disabled" แต่สิ่งเหล่านี้ไม่ได้ถูกออกแบบมาเป็นการแจ้งเตือนระบบ จึงไม่มีการตรวจสอบในทันที
• ในช่วง 45 นาทีแรกของการซื้อขาย โค้ด Power Peg ได้ประมวลผล parent order 212 รายการ และประมวลผลธุรกรรม 4 ล้านครั้งสำหรับหุ้น 154 ตัว คิดเป็นหุ้นมากกว่า 397 ล้านหุ้น
• Knight Capital Group ขาดทุน 460 ล้านดอลลาร์ภายในเวลา 45 นาที จนล้มละลาย พวกเขาระดมทุนที่จำเป็นเพื่อชดเชยความสูญเสียได้ผ่านเงินลงทุน 400 ล้านดอลลาร์จากนักลงทุน 6 ราย
• บทความเน้นย้ำถึงความสำคัญของการทำให้การปรับใช้เป็นอัตโนมัติทั้งหมดและทำซ้ำได้ เพื่อหลีกเลี่ยงความล้มเหลวขนาดใหญ่ลักษณะนี้ ซึ่งเป็นส่วนหนึ่งของแผน DevOps/Continuous Delivery
• ผู้เขียนเสนอว่าการออกซอฟต์แวร์ควรเป็นกระบวนการที่ทำซ้ำได้และเชื่อถือได้ และควรทำให้เป็นอัตโนมัติมากที่สุดเพื่อลดความเสี่ยงจากความผิดพลาดของมนุษย์

[GN⁺]

ความคิดเห็นจาก Hacker News

• การดีพลอยแบบอัตโนมัติอาจไม่ได้ป้องกันปัญหา และอาจยิ่งขยายปัญหาเพราะโค้ดที่เข้ากันไม่ได้
• ระบบเทรดอัตโนมัติควรมี kill switch ในตัว และควรทดสอบเป็นประจำเพื่อให้มั่นใจว่ามันทำงานได้ตามต้องการ
• ระบบ continuous deployment อาจไม่ได้บล็อกบั๊กนี้ ซึ่งเป็นข้อผิดพลาดเชิงตรรกะที่นำไปสู่ความล้มเหลวระดับวิกฤต
• คำว่า "ดึงแบบ Knight Capital" เป็นสำนวนที่รู้จักกันในแวดวงการเงินเชิงปริมาณ สำหรับการตัดมุมในระบบสำคัญแล้วต้องเผชิญผลลัพธ์ตามมา
• การเทรดความถี่สูงเป็นตัวอย่างสุดโต่งของสิ่งที่สามารถผิดพลาดได้อย่างรวดเร็ว
• สำหรับระบบที่รองรับปริมาณการขายขนาดใหญ่ การมีขั้นตอนแบบแมนนวล ขั้นตอน rollback และ feature flag เป็นสิ่งสำคัญในการลดความเสี่ยง
• เหตุการณ์ Knight Capital เป็นผลจากการเพิกเฉยต่อระบบ SCRAM อัตโนมัติที่ควรหยุดการซื้อขายทั้งหมดหรือแจ้งเตือนให้มีการแทรกแซงด้วยมนุษย์
• การมี dead code อยู่ในโค้ดเบสยาวนานถึง 8 ปีสะท้อนถึงความเสี่ยง และบ่งชี้ถึงการขาดงานบำรุงรักษาเชิงรุก
• หากมีการ rollout การตั้งค่าและไบนารีไปพร้อมกัน ก็น่าจะป้องกันปัญหาประเภทนี้ได้
• การนำแฟล็กเก่ากลับมาใช้ซ้ำเป็นความผิดพลาดสำคัญ และตอกย้ำความสำคัญของแนวปฏิบัติที่เหมาะสมในการดีพลอย