Tự động hóa các bài kiểm tra chuyển đổi dự phòng trong kỹ thuật hỗn loạn trên pipeline CI/CD của AWS

Một hướng dẫn kỹ thuật chi tiết được công bố vào ngày 2 tháng 11 năm 2026 trình bày cách nhúng các bài kiểm tra độ tin cậy tự động trực tiếp vào quy trình tích hợp và triển khai liên tục. Hướng dẫn này, do Gbenga Ogbonyenitan viết cho DEV Community, hướng dẫn các kỹ sư sử dụng AWS Fault Injection Service (FIS) để cố ý dừng các tác vụ container và xác minh rằng hệ thống phục hồi trong giới hạn thời gian chấp nhận được.

Chuyện gì đã xảy ra

Bài viết cung cấp một triển khai từng bước của mô hình kỹ thuật hỗn loạn, trong đó pipeline triển khai một dịch vụ, cố ý làm hỏng một trong các thành phần đang chạy của nó, sau đó xác thực rằng cơ sở hạ tầng tự chữa lành. Thiết lập này sử dụng Amazon ECS (Elastic Container Service) với Fargate, Application Load Balancer và AWS CodePipeline. Đổi mới cốt lõi là thêm giai đoạn "FailoverTest" chạy sau khi triển khai, đảm bảo rằng mỗi bản phát hành đều đi kèm với bằng chứng về khả năng chống chịu.

Quy trình bao gồm hai giai đoạn chính: xây dựng cơ sở hạ tầng dịch vụ nền tảng và cấu hình cơ chế tiêm lỗi. Đầu tiên, kỹ sư thiết lập các nhóm bảo mật, nhóm đích và load balancer để xử lý lưu lượng truy cập. Sau đó, họ cấu hình FIS để nhắm mục tiêu vào các tác vụ ECS cụ thể. Hướng dẫn nhấn mạnh rằng điều này không chỉ đơn thuần là phá vỡ mọi thứ, mà còn là đo lường thời gian phục hồi so với ngưỡng định trước, chẳng hạn như 300 giây. Nếu dịch vụ không trở lại trạng thái khỏe mạnh trong khoảng thời gian đó, pipeline sẽ thất bại, ngăn chặn việc coi các cấu hình có thể không ổn định là thành công.

Tác giả lưu ý rằng mặc dù demo sử dụng máy chủ web nginx đơn giản, nhưng mô hình này được thiết kế cho các ứng dụng thực tế. Bằng cách tự động hóa bài kiểm tra này, các nhóm chuyển từ việc giả định rằng thiết kế sẵn sàng cao của họ hoạt động sang việc chứng minh điều đó trong từng bản phát hành. Hướng dẫn bao gồm cả phương pháp thủ công dựa trên bảng điều khiển để học tập và phương pháp dựa trên CloudFormation cho cơ sở hạ tầng dưới dạng mã (infrastructure as code) sẵn sàng cho môi trường sản xuất.

Chi tiết chính

• Pipeline bao gồm ba giai đoạn: Source, Deploy và FailoverTest, với giai đoạn cuối cùng thực hiện thí nghiệm hỗn loạn.
• AWS Fault Injection Service được cấu hình để dừng chính xác một tác vụ trong dịch vụ ECS có hai tác vụ, đảm bảo tính khả dụng một phần trong suốt quá trình thử nghiệm.
• Một script tùy chỉnh chạy trong AWS CodeBuild kiểm tra các điều kiện tiền đề, khởi động thí nghiệm FIS, chờ hoàn tất và xác thực các số liệu phục hồi.
• Việc xác thực phục hồi yêu cầu cả số lượng tác vụ đang chạy của ECS và số lượng đích khỏe mạnh của load balancer phải khớp với trạng thái mong muốn.
• Thí nghiệm sử dụng cảnh báo CloudWatch làm điều kiện dừng để giám sát các máy chủ khỏe mạnh, mặc dù biện pháp kiểm soát an toàn chính là giới hạn lỗi ở mức một tác vụ.
• Các script dọn dẹp được cung cấp để xử lý các tài nguyên không được quản lý bởi các stack CloudFormation, chẳng hạn như nhóm log và phiên bản định nghĩa tác vụ.

Bối cảnh

Kỹ thuật hỗn loạn là kỷ luật thực hiện các thí nghiệm trên một hệ thống nhằm xây dựng sự tự tin vào khả năng của nó trong việc chịu đựng các điều kiện bất ổn trong môi trường sản xuất. Theo truyền thống, điều này có thể liên quan đến các ngày chơi game thủ công hoặc các môi trường thử nghiệm riêng biệt. Việc tích hợp nó vào CI/CD đưa các bài kiểm tra này gần hơn với những thay đổi mã, giúp phát hiện sớm các suy giảm trong logic chống chịu. AWS Fault Injection Service là một dịch vụ được quản lý giúp thực hiện các thí nghiệm này một cách an toàn bằng cách xác định phạm vi, hành động và điều kiện dừng.

Trong bối cảnh này, "chuyển đổi dự phòng" (failover) đề cập đến việc thay thế tự động một tác vụ container bị lỗi bởi bộ lập lịch ECS. Khi một tác vụ dừng, dịch vụ phát hiện sự chênh lệch giữa số lượng mong muốn và số lượng đang chạy, khởi động một tác vụ mới và đăng ký nó với load balancer. Bài kiểm tra xác minh rằng toàn bộ vòng lặp này hoàn tất mà không cần can thiệp của con người và trong khoảng thời gian đáp ứng các mục tiêu mức độ dịch vụ.

Tại sao điều này quan trọng

Đối với các nhóm quản lý phần mềm tự host hoặc nền tảng nội bộ, độ tin cậy thường được giả định chứ không được kiểm tra. Các tài liệu thiết kế có thể tuyên bố rằng một dịch vụ có sẵn sàng cao, nhưng sự trôi dạt cấu hình, lỗi quyền hạn hoặc chính sách mạng có thể âm thầm phá vỡ các cơ chế chuyển đổi dự phòng. Bằng cách tự động hóa bài kiểm tra này, các kỹ sư chuyển đổi các tuyên bố thiết kế trừu tượng thành các kiểm tra đạt/không đạt cụ thể. Điều này giảm thiểu rủi ro phát hiện các lỗi phục hồi trong những lần gián đoạn thực tế, khi hậu quả là nghiêm trọng nhất.

Hơn nữa, cách tiếp cận này làm nổi bật tầm quan trọng của các mục tiêu thời gian phục hồi. Không đủ nếu một dịch vụ cuối cùng cũng quay trở lại; nó phải làm như vậy đủ nhanh để đáp ứng kỳ vọng của người dùng. Pipeline áp đặt một thời gian chờ nghiêm ngặt, buộc các nhóm tối ưu hóa khoảng thời gian kiểm tra sức khỏe, thời gian khởi động container và độ trễ hủy đăng ký của load balancer. Điều này chuyển đổi kỹ thuật độ tin cậy từ một hoạt động phản ứng sau sự cố sang một yêu cầu phát triển chủ động.

Tuy nhiên, việc triển khai điều này đòi hỏi quản lý quyền hạn cẩn thận. Hướng dẫn chi tiết nhiều cạm bẫy phổ biến, chẳng hạn như thiếu quyền IAM để tạo các vai trò liên kết dịch vụ hoặc ARN nhóm đích không chính xác. Những chi tiết này nhấn mạnh rằng kỹ thuật hỗn loạn giới thiệu các phức tạp vận hành mới cần được quản lý song song với các nhiệm vụ triển khai tiêu chuẩn.

Bạn có thể làm gì

• Xem xét các pipeline CI/CD hiện tại của bạn để xác định nơi có thể thêm bài kiểm tra chống chịu như một giai đoạn sau triển khai.
• Bắt đầu với môi trường phi sản xuất để thử nghiệm tích hợp FIS, đảm bảo bạn hiểu các chế độ lỗi trước khi chạm vào lưu lượng truy cập trực tiếp.
• Xác định rõ ràng các mục tiêu thời gian phục hồi cho các dịch vụ quan trọng của bạn và sử dụng chúng làm ngưỡng thời gian chờ trong các bài kiểm tra tự động.
• Kiểm toán các vai trò IAM của bạn để đảm bảo các agent build có quyền tối thiểu cần thiết để khởi động thí nghiệm FIS và truy vấn trạng thái ECS.
• Triển khai các kiểm tra trước trong script thử nghiệm của bạn để xác minh hệ thống khỏe mạnh trước khi tiêm lỗi, tránh các dương tính giả từ các vấn đề hiện có.
• Tài liệu hóa hành vi mong đợi của các dịch vụ của bạn trong các lần gián đoạn một phần và sử dụng các bài kiểm tra này để liên tục xác thực những kỳ vọng đó.