Năm 2012, Knight Capital một công ty trading hàng đầu nước Mỹ mất gần 10.000 tỷ VND (440 triệu USD quy đổi sang VNĐ năm 2012) chỉ trong 45 phút. Do không còn khả năng tự đứng vững sau cú sốc tài chính và uy tín, vào tháng 12 cùng năm, Knight Capital đã buộc phải đồng ý để đối thủ cạnh tranh là Getco LLC thâu tóm. Nguyên nhân của sự sụp đổ này không phải vì bị hacker tấn công cũng không phải vì lỗi thuật toán. Mà nó đến từ 1 chuỗi các sự kiện nhỏ tưởng như vô hại:

• Một feature flag cũ được tái sử dụng
• Một server không deploy thành công
• Một đoạn code zombie

Và cho đến bây giờ, đây vẫn là một trong những bài học đắt nhất lịch sử software engineering về deployment, feature flag và rollback strategy.

I. Feature Flag là gì?

Feature flag là một kỹ thuật cho phép bật hoặc tắt một phần logic của hệ thống mà không cần deploy lại code.

Use case thường thấy của feature flag là:

• Deploy first, enable later: cho phép anh em tách biệt deployment và release
• Kill switch khi production gặp sự cố: rollback nhanh và giảm tối đa blast radius

II. Cách implement feature flag cơ bản

Ở mức đơn giản nhất, feature flag chỉ là một config

features:
  new-flow: true

Application dựa vào config của feature flag để lựa chọn đi flow nào

if (featureFlagManager.isEnabled("new-flow")) {
    runNewFlow();
} else {
    runOldFlow();
}

Ở các hệ thống lớn, feature flag thường được quản lý bởi một service riêng như LaunchDarkly hoặc các service tương tự, cho phép anh em có thể bật/tắt ngay trong runtime và rollback ngay mà không cần redeploy lại toàn bộ service.

III. Khi nào nên dùng Feature Flag

Feature flag đặc biệt hữu ích khi

• Rollout một thay đổi lớn
• Migration giữa hai hay nhiều system
• Hoặc cần rollback thật nhanh khi xảy ra sự cố

IV. Failure Case Study - Knight Capital

1. Code zombie - Khởi nguồn của sự sụp đổ

2003

Knight Capital ngừng sử dụng một hệ thống trading nội bộ tên là Power Peg. Nhưng anh em dev tiếc rẻ và quyết định không xóa code của feature đó, nó vẫn nằm trong production suốt nhiều năm sau đó.

2005

Knight Capital sửa một phần khác của hệ thống là SMARS. Thay đổi này vô tình làm logic xử lý của Power Peg bị lỗi nếu một ngày nào đó nó bị kích hoạt lại. Nhưng không một ai quan tâm vì Power Peg đã bị tắt rồi mà.

2. Feature flag Incident

From 2012-07-27 to 2012-07-31

Knight Capital chuẩn bị cho chương trình Retail Liquidity Program (RLP) của NYSE bằng cách triển khai phần mềm mới trên tổng cộng 8 con server. Tuy nhiên, một trong số đó đã không nhận được bản cập nhật đầy đủ, tức là tại thời điểm này có 7 server chạy bản build latest và server còn lại đang chạy bản build cũ.

Trớ trêu thay, feature flag được sử dụng cho feature trong bản build mới lại trùng với feature flag để kích hoạt Power Peg trên bản build cũ.

2012-08-01 08:01

Trước khi thị trường mở cửa, hệ thống giám sát nội bộ đã tạo ra nhiều thông báo cảnh báo và lỗi, nhưng không được báo cáo hoặc xử lý kịp thời

2012-08-01 09:30

Thị trường mở cửa, hệ thống gửi tín hiệu bật RLP đến toàn bộ servers. 7 servers hoạt động bình thường nhưng server thứ 8 bắt đầu trigger Power Peg.

Và vì Power Peg đã bị broken từ 2005, nó liên tục gửi lệnh mua bán sai, spam thị trường với tốc độ cực lớn và không nhận ra các orders đã được xử lý. Trong vòng 45 phút, hơn 4 triệu orders được gửi đi, Knight Capital giao dịch khoảng 397 triệu cổ phiếu, tích lũy hàng tỷ USD vị thế không mong muốn.

2012-08-01 10:15

Hệ thống mới được tắt hoàn toàn, sau 45 phút.

2012-12

Khoảng 4 tháng sau đó, Knight Capital rơi vào tay đối thủ là Getco LLC.

V. Bài học từ Knight Capital

Knight Capital downfall đã thay đổi cách các kỹ sư phát triển và vận hành hệ thống

1. Feature Flag Lifecycle Management

Các công ty bắt đầu các quy định rõ hơn về feature flag, nghiêm túc hơn với flag debt

• Set flag owner: không có owner thì flag trở thành tài sản vô chủ - không ai dám flip, không ai nhận alert, không ai cleanup
• Expiry date: giải quyết vấn đề flag bao giờ thì được owner cleanup
• Cleanup policy: trả lời câu hỏi clean up như thế nào. Ví dụ xoá flag trên LD và đồng thời xoá zombie code block trong source code

2. Không reuse flag cũ

Một trong những bài học lớn nhất, không reuse feature flag cũ cho logic mới. Trong distributed systems, version cũ và version mới có thể cùng chạy đồng thời, deployment có thể không đồng nhất và cùng một config có thể bị hiểu theo nhiều cách khác nhau.

3. Deployment Verification

Knight Capital deploy lên 8 servers nhưng bỏ sót một server. Sau những incident kiểu này, deployment pipeline hiện đại bắt đầu nghiêm túc hơn với:

• Deployment verification
• Artifact checksum
• Fleet consistency
• Version tracking
• Health checks
• Automated rollout validation

Anh em có thể tham khảo thêm cách AWS Code pipeline cover từng point phía trên nha

4. Deployment standard

Knight Capital mất 45 phút để dừng incident. Nếu thời điểm đó có một cơ chế để ngăn chặn incident sớm, trước hoặc ngay tại thời điểm thị trường mở cửa, Knight Capital đã không phải nhận cái kết đắng. Hiện nay, chúng ta có những standard như

• Canary Deployment
• Blue/Green Deployment
• Progressive delivery
• Automatic rollback

VI. Kết bài

Feature flag là một trong những design pattern đơn giản và hữu ích nhất trong modern systems. Nó giúp anh em rollout nhanh hơn, an toàn hơn, và giảm blast radius khi xảy ra sự cố.

Nhưng Knight Capital cũng nhắc ngành phần mềm một điều rất quan trọng, luôn chuẩn bị cho tình huống xấu nhất vì production thường chết bởi những cú tặc lưỡi

"Để đó lỡ đâu sau này dùng, chắc không sao đâu"

Nó có thể là một feature flag cũ, một human mistake trong lúc deployment hoặc một đoạn code zombie vô chủ. Đó cũng là lý do ngày nay, có rất nhiều best practice mà anh em có thể xem đó là "obvious" nhưng thực ra nó đã được viết bằng máu và nước mắt của những người đi trước.

---

Nếu anh em cảm thấy bài viết hữu ích đừng ngần ngại click upvote cho bài viết, hoặc phát hiện ý nào chưa hợp lý hoặc cần giải thích thêm hãy comment cho tôi biết để cùng trao đổi nhé. Anh em có thể tham khảo các bài viết khác của tôi tại Blog cái nhân hoặc kết nối với tôi qua Linkedin