Khi Amazon Web Services gặp sự cố nghiêm trọng tại khu vực Bắc Virginia vào ngày 19-20 tháng 10 năm 2025, nguyên nhân ban đầu có vẻ rõ ràng: một điều kiện tranh chấp trong hệ thống quản lý DNS của DynamoDB. Nhưng khi cộng đồng kỹ thuật nghiên cứu kỹ báo cáo phân tích sự cố chi tiết của Amazon, một câu chuyện phức tạp hơn đã lộ ra về những thách thức vốn có trong việc quản lý các hệ thống phân tán cực kỳ phức tạp và liệu các phương pháp tiếp cận truyền thống cho độ tin cậy có còn đủ ở quy mô điện toán đám mây hay không.
Điều kiện tranh chấp DNS khởi nguồn mọi chuyện
Sự cố bắt đầu với một vấn đề cổ điển trong hệ thống phân tán - nhiều Trình thực thi DNS hoạt động độc lập trên các Vùng sẵn sàng khác nhau trở nên mất đồng bộ. Một trình thực thi gặp phải độ trễ bất thường khi xử lý các bản cập nhật, trong khi một trình khác chạy nhanh hơn với các kế hoạch mới hơn. Thời điểm này tạo ra một cơn bão hoàn hảo khi một kế hoạch DNS đã lỗi thời ghi đè lên kế hoạch hiện tại, sau đó quy trình dọn dẹp xóa luôn cả kế hoạch đang hoạt động. Điều này khiến điểm cuối khu vực của DynamoDB không có địa chỉ IP nào, khiến dịch vụ trên thực tế không thể truy cập được.
Điều khiến các kỹ sư đặc biệt lo ngại là sự thiếu vắng rõ ràng của các biện pháp bảo vệ cơ bản cho hệ thống phân tán. Như một bình luận viên nhận xét, Nghe có vẻ như đây là trường hợp 'tự triển khai thuật toán hệ thống phân tán' mà không có sự đầu tư ban đầu để thực hiện một hệ thống phân tán thực sự mạnh mẽ. Hệ thống này thiếu các thao tác so sánh-và-hoán đổi hoặc kiểm tra phiên bản phù hợp vốn có thể ngăn kế hoạch cũ ghi đè lên dữ liệu mới hơn.
Các Hệ thống Nội bộ Chính của AWS Được Đề cập
- DNS Planner: Giám sát tình trạng hoạt động của load balancer và tạo các kế hoạch DNS
- DNS Enactor: Áp dụng các thay đổi DNS vào Route53 (chạy trên 3 AZ)
- DWFM (Droplet Workflow Manager): Quản lý các máy chủ vật lý cho EC2
- Network Manager: Xử lý việc truyền bá cấu hình mạng
- NLB Health Check Subsystem: Giám sát tình trạng hoạt động của các node load balancer
Lỗi dây chuyền phơi bày các vấn đề kiến trúc sâu hơn
Mặc dù vấn đề DNS đã được giải quyết trong vòng vài giờ, thiệt hại thực sự đến từ các lỗi dây chuyền xuyên suốt cơ sở hạ tầng của AWS. Trình quản lý quy trình công việc Droplet (DWFM), quản lý các máy chủ vật lý cho các phiên bản EC2, đã rơi vào tình trạng mà các kỹ sư gọi là sụp đổ do tắc nghẽn. Khi DWFM cố gắng thiết lập lại các hợp đồng thuê với các droplet trên toàn bộ đội EC2, khối lượng công việc khổng lồ đã tạo ra một vòng lặp phản hồi nơi các lần thử hết thời gian và xếp thêm nhiều công việc thử lại vào hàng đợi, ngăn cản mọi tiến triển.
Vì tình huống này không có quy trình khôi phục vận hành được thiết lập sẵn, các kỹ sư đã rất thận trọng trong việc cố gắng giải quyết vấn đề với DWFM mà không gây ra thêm sự cố.
Lời thừa nhận này trong báo cáo của Amazon đã khiến cộng đồng kỹ thuật đặc biệt báo động. Việc một thành phần cốt lõi như vậy của cơ sở hạ tầng EC2 lại thiếu các quy trình khôi phục được thiết lập cho chế độ lỗi này cho thấy những vấn đề sâu hơn về sự sẵn sàng trong vận hành. Giải pháp cuối cùng - giới hạn luồng công việc đến và khởi động lại có chọn lọc các máy chủ DWFM - về cơ bản là một ca phẫu thuật khẩn cấp trên một hệ thống đang hoạt động.
Cuộc tranh luận về Hệ thống Phức hợp
Sự cố này đã châm ngòi cho một cuộc tranh luận sôi nổi về cách chúng ta nghĩ về các lỗi hỏng trong các hệ thống phức hợp. Nhiều kỹ sư chỉ ra rằng bài tiểu luận How Complex Systems Fail (Các Hệ thống Phức hợp Thất bại như thế nào) của Richard Cook đã cung cấp bối cảnh quan trọng. Cook lập luận rằng trong các hệ thống thực sự phức hợp, khái niệm về một nguyên nhân gốc duy nhất là gây hiểu lầm - các lỗi hỏng nảy sinh từ sự kết hợp của các điều kiện tiềm ẩn mà riêng lẻ có thể vô hại.
Góc nhìn này thách thức các phương pháp tiếp cận phản ứng sự cố truyền thống. Như một bình luận viên giải thích, Với nguồn lực hữu hạn, bạn nên phản ứng với sự cố này bằng cách kiểm tra các hệ thống quản lý DNS của mình để tìm điều kiện tranh chấp? Hay thay vào đó, bạn nên tìm cách giúp Trình quản lý Droplet tồn tại sau khi bị ngắt kết nối khỏi DynamoDB mà không rơi vào tình trạng sụp đổ do tắc nghẽn? Câu trả lời có thể liên quan đến cả hai, nhưng việc ưu tiên những cải tiến nào mang lại nhiều lợi ích về độ tin cậy nhất ngày càng trở nên khó khăn khi các hệ thống trở nên phức tạp hơn.
Thực tế vận hành so với sự hoàn hảo lý thuyết
Cuộc thảo luận đã làm lộ rõ sự căng thẳng giữa các phương pháp hay nhất về lý thuyết cho hệ thống phân tán và thực tế vận hành khi chạy các dịch vụ ở quy mô AWS. Một số bình luận viên có kinh nghiệm tại các công ty công nghệ lớn đã mô tả những thách thức của việc trực ca và sự tích lũy dần dần nợ kỹ thuật khiến các hệ thống trở nên mong manh hơn theo thời gian.
Một nhà thầu chia sẻ: Tôi chưa bao giờ làm việc trong một công ty mà coi việc trực ca là một việc rất nghiêm túc. Trên giấy tờ, họ đều nói nó nghiêm túc và tất cả các thỏa thuận cấp độ dịch vụ (SLA) đều được thiết lập, nhưng trong thực tế thì không có đủ sự hỗ trợ. Điều này gợi ý rằng ngay cả tại các nhà cung cấp dịch vụ đám mây lớn, các yếu tố con người và tổ chức có thể quan trọng không kém các yếu tố kỹ thuật trong việc duy trì độ tin cậy.
Sự cố này cũng làm nổi bật thách thức về sự phụ thuộc liên vùng. Mặc dù mô hình vùng của AWS được quảng cáo là hoàn toàn độc lập, sự cố đã tiết lộ rằng một số dịch vụ toàn cầu vẫn phụ thuộc vào us-east-1, tạo ra một điểm hỏng duy nhất ảnh hưởng đến khách hàng trên toàn thế giới. Đây không phải là lần đầu tiên điều này xảy ra, cho thấy rằng việc loại bỏ những sự phụ thuộc này khó khăn hơn vẻ ngoài của nó.
Các Dịch vụ AWS Bị Ảnh Hưởng
- Cốt lõi: DynamoDB, EC2, Network Load Balancer
- Điện toán: Lambda, ECS, EKS, Fargate
- Định danh: IAM, AWS Management Console, Security Token Service
- Phân tích: Redshift
- Kinh doanh: Amazon Connect
- Hỗ trợ: Managed Workflows for Apache Airflow, Outposts, Support Center
Hướng tới tương lai
Amazon đã hành động ngay lập tức bằng cách vô hiệu hóa tự động hóa DNS có vấn đề trên toàn cầu. Các bản sửa lỗi theo kế hoạch của họ bao gồm giải quyết điều kiện tranh chấp, thêm các điều khiển tốc độ cho quá trình chuyển đổi dự phòng kiểm tra sức khỏe NLB, và xây dựng các bài kiểm tra tốt hơn cho quy trình công việc khôi phục DWFM. Nhưng câu hỏi rộng hơn vẫn còn đó: liệu có tổ chức nào thực sự có thể dự đoán và ngăn chặn tất cả các chế độ lỗi trong các hệ thống phức tạp như vậy không?
Cuộc thảo luận của cộng đồng kỹ thuật cho thấy rằng khi các hệ thống ngày càng phức tạp, cách tiếp cận của chúng ta về độ tin cậy phải phát triển vượt ra ngoài việc tìm và sửa các nguyên nhân gốc, hướng tới việc thiết kế các hệ thống có thể suy giảm một cách duyên dáng và phục hồi nhanh chóng. Sự cố AWS phục vụ như một lời nhắc nhở rằng trong các hệ thống phân tán, lỗi hỏng là không thể tránh khỏi - nhưng các lỗi hỏng thảm khốc thì không cần phải xảy ra.
Cuộc trò chuyện vẫn tiếp tục về việc liệu các hệ thống AI hiện tại có thể giúp ích cho các kịch bản xử lý sự cố phức tạp như vậy hay không, với các ý kiến chia rẽ về việc liệu chỉ riêng nhận dạng mẫu có thể giải quyết được các vấn đề đòi hỏi sự hiểu biết sâu sắc về tương tác hệ thống hay không. Điều rõ ràng là khi cơ sở hạ tầng đám mây trở nên thiết yếu hơn đối với kinh doanh toàn cầu, mức độ quan trọng của việc xử lý đúng vấn đề này chỉ ngày càng tăng lên.
Tham khảo: Tóm tắt Sự gián đoạn Dịch vụ Amazon DynamoDB trong Khu vực Bắc Virginia (US-EAST-1)