Khi AWS hứng chịu một sự cố ngừng hoạt động nghiêm trọng vào tháng 10 năm 2023, báo cáo phân tích sự cố chi tiết của họ đã tiết lộ một điều kiện tranh chấp tinh vi trong hệ thống quản lý DNS của họ. Dù các kỹ sư AWS có thành tích đáng nể về độ tin cậy, sự cố này cho thấy ngay cả những hệ thống tinh vi nhất cũng có thể trở thành nạn nhân của lỗi đồng thời. Cộng đồng kỹ thuật đã sôi sục với các phân tích về nguyên nhân và liệu các phương pháp xác minh hình thức có thể ngăn chặn được thất bại này hay không.
Các Thành Phần Chính Trong Sự Cố DNS Của AWS:
- DNS Planner: Tạo các kế hoạch DNS
- DNS Enactor: Áp dụng các kế hoạch lên Route 53 (3 phiên bản trên các vùng khả dụng)
- Route 53 Service: Dịch vụ web DNS của Amazon
- Race Condition: Enactor nhanh hơn áp dụng kế hoạch mới hơn và dọn dẹp các kế hoạch cũ hơn trong khi enactor chậm hơn vẫn đang sử dụng kế hoạch cũ
Thành Kiến Biết Trước Trong Thiết Kế Hệ Thống
Nhiều người bình luận nhận định rằng điều kiện tranh chấp cụ thể - khi một tiến trình xóa một kế hoạch DNS đang hoạt động mà một tiến trình khác vẫn đang sử dụng - có vẻ rõ ràng khi nhìn lại. Một bình luận viên đã diễn tả hoàn hảo tâm trạng này: Bất biến thì rõ ràng trong hồi tưởng, nhưng nó khó mà là hiển nhiên. Điều này làm nổi bật một thách thức cơ bản trong thiết kế hệ thống phân tán: những lỗi hỏng có vẻ đơn giản sau khi chúng xảy ra có thể cực kỳ khó lường trước trong quá trình phát triển. Vấn đề phân định, như một bình luận viên đã đề cập, nhắc nhở chúng ta rằng chúng ta không thể xác định trước tất cả các chế độ lỗi tiềm ẩn, bất kể phân tích của chúng ta có kỹ lưỡng đến đâu.
Giới Hạn Thực Tế Của Phương Pháp Hình Thức
Cuộc thảo luận đã cho thấy sự chia rẽ sâu sắc về giá trị của các công cụ xác minh hình thức như TLA+ và các trình kiểm tra mô hình. Một số cho rằng những công cụ này tạo ra một bài tập mang tính học thuật tách rời với lập trình thực tế, đòi hỏi phải dịch thủ công giữa các mô hình và mã code thực tế. Những người khác phản bác rằng Amazon đã sử dụng thành công các phương pháp hình thức nhẹ nhàng trong sản xuất nhiều năm, có khả năng đã ngăn chặn nhiều lỗi hỏng mà chúng ta không bao giờ thấy. Cuộc tranh luận cốt lõi xoay quanh việc liệu lợi ích của việc phát hiện các lỗi tinh vi có lớn hơn chi phí duy trì các mô hình hệ thống riêng biệt hay không.
Vấn đề với TLA+ là nó là một công cụ hoàn toàn tách biệt với việc lập trình thực tế, và ngay cả khi mọi thứ được thực hiện đúng đắn, nó cũng không ngăn được những thay đổi mã code sau này phá vỡ mô hình.
Các Công cụ Xác minh Hình thức được Đề cập:
- Trình kiểm tra mô hình Spin với ngôn ngữ Promela
- TLA+
- Alloy (alloytools.org)
- Lean, F*, Dafny (các công cụ xác minh tạo mã nguồn)
 |
|---|
| Một bài viết blog cung cấp thông tin về việc tái tạo các điều kiện tranh chấp gây ra sự cố ngừng hoạt động AWS thông qua các công cụ kiểm tra mô hình |
Các Giả Định Dựa Trên Thời Gian Và Sự Thất Bại Tất Yếu Của Chúng
Một số kỹ sư kỳ cựu chỉ ra một vấn đề sâu xa hơn: những hệ thống dựa vào các giả định về thời gian chắc chắn sẽ thất bại vào lúc nào đó. Cho dù là giả định một tiến trình sẽ hoàn thành trong một khung thời gian nhất định hay cho rằng các thao tác dọn dẹp sẽ không can thiệp vào các hoạt động đang diễn ra, những sự phụ thuộc thời gian này tạo ra các hệ thống mong manh. Một bình luận viên lưu ý họ đã nhiều lần gặp phải lỗi do các thời gian chờ không cần thiết gây ra, và kết luận rằng sự tồn tại của một thời gian chờ, về bản chất, là một lỗi, không phải một tính năng. Quan điểm này thách thức các thực hành kỹ thuật cơ bản mà nhiều người cho là đương nhiên.
Các Mẫu Hình Lỗi Thường Gặp Được Thảo Luận:
- Time-of-Check to Time-of-Use (TOCTOU)
- Phụ thuộc vào thời gian chờ
- Các quy trình dọn dẹp can thiệp vào hoạt động đang chạy
- Phân mảnh mạng gây ra độ trễ không mong muốn
Động Lực Tổ Chức Của Kỹ Thuật Độ Tin Cậy
Bên ngoài cuộc thảo luận kỹ thuật, các bình luận viên làm nổi bật các yếu tố con người và tổ chức. Những kỹ sư xây dựng các hệ thống mạnh mẽ không bao giờ hỏng thường nhận được ít sự công nhận hơn những người sửa chữa ngoạn mục các thất bại gây chú ý. Điều này tạo ra những động cé trái ngược khiến công việc đảm bảo độ tin cậy có thể bị đánh giá thấp. Như một bình luận viên đã nhận xét, những lính cứu hỏa code nhận được tất cả sự chú ý, nhưng chính họ cũng là những người đã tưới xăng lên cấu trúc trước đó. Điều này gợi ý rằng những thay đổi văn hóa có thể quan trọng không kém các cải tiến kỹ thuật để xây dựng các hệ thống đáng tin cậy.
Việc phân tích sự cố ngừng hoạt động AWS bằng trình kiểm tra mô hình đại diện cho nhiều hơn một bài tập phân tích sự cố - nó chứng minh cách các phương pháp hình thức có thể giúp các kỹ sư lập luận về các hệ thống phức tạp ngay cả khi không có đầy đủ kiến thức nội bộ. Trong khi cộng đồng tranh luận về giá trị thực tiễn của những công cụ này, sự cố này đóng vai trò như một lời nhắc nhở rằng các hệ thống phân tán đòi hỏi nhiều lớp phòng thủ: thiết kế cẩn thận, kiểm tra toàn diện, giám sát thời gian chạy, và vâng, đôi khi là cả xác minh hình thức. Khi các hệ thống ngày càng phức tạp, các công cụ chúng ta sử dụng để hiểu chúng cũng phải phát triển tương ứng.
Tham khảo: Reproducing The AWS Outage Race Condition With A Model Checker
 |
|---|
| Mô phỏng tình trạng race condition của AWS DNS thể hiện tương tác giữa các tiến trình trong hệ thống phân tán |