Cuối tháng 12/2025, Cloudflare đăng một bài mang tựa đề Code Orange: Fail Small. Nội dung là kế hoạch chấn chỉnh nội bộ sau hai sự cố lớn liên tiếp, ngày 18/11 và ngày 5/12 cùng năm.
Trong quy ước của hãng, tuyên bố Code Orange nghĩa là công việc này được ưu tiên trên mọi thứ khác. Hiếm khi một nhà cung cấp công khai cả kế hoạch sửa mình.
Hai sự cố có nguyên nhân kỹ thuật khác nhau nhưng hình dạng giống hệt. Lần đầu là tệp cấu hình của hệ thống nhận diện bot phình quá giới hạn cho phép, làm tiến trình proxy sập. Lần sau phát sinh trong lúc hãng đang xử lý một lỗ hổng của React Server Components. Họ tắt một công cụ kiểm thử nội bộ. Thay đổi đó đi qua hệ thống cấu hình toàn cục, vốn lan ra toàn bộ máy chủ chỉ trong vài giây.
Điểm chung: cấu hình không được triển khai theo đợt
Cloudflare thừa nhận thẳng rằng cả hai lần đều do thay đổi cấu hình đẩy đi toàn cầu tức thì.
Phần mềm của họ đã có quy trình phát hành theo giai đoạn từ lâu, có kiểm chứng sức khoẻ và tự động quay lui. Nhưng cấu hình thì không đi qua quy trình ấy. Lỗ hổng nằm ở quy trình, không ở kỹ thuật.
Tên gọi Fail Small nói lên ý đồ: mục tiêu không phải là không bao giờ hỏng, mà là mỗi lần hỏng thì chỉ hỏng một phần nhỏ.
Sáu tháng sau: họ làm được những gì
Tháng 5/2026, Cloudflare công bố kế hoạch đã hoàn tất. Hơn hai quý dồn sức, và bản tổng kết liệt kê những thứ cụ thể hơn hẳn một lời hứa.
Họ dựng một hệ thống mới đặt tên Snapstone, cho phép thả cấu hình theo từng đợt kèm theo dõi sức khoẻ ngay lúc thả. Cấu hình rủi ro cao không còn đi thẳng ra cả mạng lưới nữa, mà lan dần qua các đợt lớn dần.
Họ cũng đổi cách hệ thống ứng xử khi gặp dữ liệu sai. Thay vì sập, dịch vụ giữ lại cấu hình tốt gần nhất và chạy tiếp. Chi tiết ấy trả lời thẳng cho lỗi tháng 11, khi một dòng mã không xử lý lỗi mà bung thẳng ra làm sập cả tiến trình.
Đáng chú ý nhất với người viết phần mềm là "Engineering Codex". Một bộ quy tắc nội bộ, áp bằng công cụ soát mã tự động trên toàn bộ mã nguồn. Hai quy tắc được nêu làm ví dụ. Cấm dùng hàm bung lỗi ngoài phạm vi kiểm thử. Và dịch vụ bắt buộc phải kiểm tra dữ liệu nhận từ thành phần khác.
Quy tắc thứ nhất chính là dòng mã đã làm sập mạng lưới hôm 18/11. Họ không chỉ sửa dòng đó — họ cấm cả loại dòng đó, trên toàn bộ mã nguồn, bằng máy.
Còn vài phần khác. Đường truy cập khẩn cấp dự phòng cho mười tám dịch vụ then chốt, để đội trực vẫn vào được hệ thống khi cả mạng lưới đang hỏng. Tách dịch vụ theo nhóm khách hàng, để một nhóm gãy không kéo nhóm khác. Và một đội truyền thông riêng chạy song song với đội xử lý sự cố, cập nhật theo nhịp cố định.
Ngày 7/4/2026, hơn 200 người tham gia một buổi diễn tập toàn công ty. Kết quả đo được: nền tảng chạy mã của họ nhận hơn năm mươi lượt triển khai trong bảy ngày, có theo dõi sức khoẻ và tự quay lui.
Cách hãng công khai chi tiết cả nguyên nhân lẫn kế hoạch sửa là điều đáng ghi nhận. Rất ít nhà cung cấp làm được; phần lớn chỉ ra thông cáo chung chung rồi thôi.
Fail Small không riêng cho nhà cung cấp lớn
Ý tưởng Fail Small không dành riêng cho nhà cung cấp quy mô toàn cầu. Bất kỳ công ty nào có nhiều máy chủ đều đối mặt cùng câu hỏi.
Khi bạn đổi một tham số cấu hình, nó áp lên bao nhiêu máy cùng lúc? Và bạn mất bao lâu để quay lại trạng thái cũ nếu đổi sai? Hai câu đó nên có câu trả lời trước khi đổi.
Trong thực tế vận hành ở Việt Nam, cấu hình thường được sửa bằng tay hoặc bằng công cụ đẩy đồng loạt. Không ai nghĩ tới việc chia đợt vì hệ thống nhỏ. Nhưng đúng ở hệ thống nhỏ thì việc quay lui lại càng khó, vì thường không có bản lưu cấu hình trước đó. Sửa xong rồi mới nhớ ra là mình không biết nó vốn thế nào.
Một kế hoạch tốt là kế hoạch giả định mình sẽ sai chứ không giả định mình sẽ đúng. Nếu quy trình thay đổi cấu hình của công ty đang dựa vào trí nhớ của một người, đó là điều nên bàn.
