Knightmare: Câu chuyện cảnh tỉnh về DevOps (2014)

• Bài viết nói về câu chuyện cảnh tỉnh của Knight Capital Group, một công ty dịch vụ tài chính lớn toàn cầu, đã phá sản chỉ trong 45 phút do một lần triển khai phần mềm thất bại.
• Năm 2012, Knight Capital Group là nhà giao dịch cổ phiếu lớn nhất tại Mỹ, với khối lượng giao dịch trung bình hằng ngày hơn 3,3 tỷ lệnh và giao dịch hơn 21 tỷ USD mỗi ngày.
• Công ty đã cập nhật SMARS, bộ định tuyến thuật toán tốc độ cao tự động, trong lúc chuẩn bị cho việc NYSE ra mắt Retail Liquidity Program mới.
• Bản cập nhật này nhằm thay thế đoạn mã cũ không còn được dùng có tên "Power Peg", thứ mà Knight đã không sử dụng suốt 8 năm.
• Mã mới được triển khai thủ công lên 8 máy chủ, nhưng do lỗi của kỹ thuật viên, một máy chủ không được sao chép mã mới nên đoạn mã Power Peg cũ đã được kích hoạt.
• Chức năng Power Peg bắt đầu định tuyến để thực thi các lệnh con mà không theo dõi số lượng cổ phiếu của lệnh cha, tạo ra một vòng lặp lệnh vô hạn.
• Khi thị trường mở cửa, hệ thống của Knight làm ngập thị trường bằng các lệnh, khiến một số cổ phiếu tăng hơn 10% giá trị, trong khi các cổ phiếu khác giảm do phản ứng với các giao dịch sai.
• Hệ thống của Knight đã gửi 97 email tự động có tham chiếu đến SMARS và xác định lỗi là "Power Peg vô hiệu hóa", nhưng chúng không được thiết kế như cảnh báo hệ thống và đã không được kiểm tra ngay lập tức.
• Trong 45 phút đầu tiên của phiên giao dịch, mã Power Peg đã xử lý 212 lệnh cha và 4 triệu giao dịch trên 154 mã cổ phiếu, tổng cộng hơn 397 triệu cổ phiếu.
• Knight Capital Group chịu khoản lỗ 460 triệu USD chỉ trong 45 phút, dẫn đến phá sản. Họ đã huy động đủ vốn để bù đắp thiệt hại thông qua khoản đầu tư 400 triệu USD từ nửa tá nhà đầu tư.
• Bài viết nhấn mạnh tầm quan trọng của việc tự động hóa hoàn toàn và làm cho quy trình triển khai có thể lặp lại để tránh những thất bại lớn như vậy, như một phần của kế hoạch DevOps/Continuous Delivery.
• Tác giả cho rằng việc phát hành phần mềm phải là một quy trình có thể lặp lại và đáng tin cậy, đồng thời nên được tự động hóa tối đa để giảm rủi ro do lỗi con người.

[GN⁺]

Ý kiến trên Hacker News

• Việc triển khai tự động có thể đã không ngăn được sự cố, thậm chí còn có thể làm trầm trọng thêm do mã không tương thích.
• Hệ thống giao dịch tự động nên có công tắc ngắt tích hợp, và cơ chế này cần được kiểm thử định kỳ để bảo đảm hoạt động đúng.
• Hệ thống triển khai liên tục có thể cũng đã không chặn được lỗi này, một lỗi logic dẫn tới thất bại nghiêm trọng.
• Cụm từ "bị Knight Capital hóa" được biết đến trong giới tài chính định lượng để chỉ việc cắt góc ở các hệ thống quan trọng rồi phải đối mặt với hậu quả.
• Giao dịch tần suất cao là một ví dụ cực đoan về việc mọi thứ có thể nhanh chóng đi sai như thế nào.
• Với các hệ thống xử lý khối lượng bán ra lớn, điều quan trọng là phải có quy trình thủ công, các bước rollback và feature flag để giảm thiểu rủi ro.
• Sự cố Knight Capital là kết quả của việc bỏ qua một hệ thống SCRAM tự động có nhiệm vụ dừng mọi giao dịch hoặc cảnh báo để can thiệp thủ công.
• Việc mã chết tồn tại trong codebase suốt 8 năm là dấu hiệu của rủi ro, cho thấy thiếu nỗ lực bảo trì chủ động.
• Nếu cấu hình và binary được rollout cùng lúc, có lẽ đã có thể ngăn được kiểu sự cố này.
• Việc tái sử dụng một cờ cũ là một sai lầm nghiêm trọng, nhấn mạnh tầm quan trọng của các thực hành đúng đắn trong triển khai.