Chaos Engineering: Tiên phong mới của AI trong môi trường sản xuất

Chaos Engineering: Tiên phong mới của AI trong môi trường sản xuất

Đây là một câu hỏi mà không công cụ Chaos Engineering nào hiện nay có thể trả lời: Thí nghiệm gần đây của bạn có kiểm tra đúng thứ không?

Không phải là "Nó có nằm trong ngân sách không?", đó là việc mà SLO error-budget gating xử lý. Cũng không phải "Hệ thống có sống sót không?", đó là điều mà các điều kiện hủy bỏ đo lường. Câu hỏi ở đây là liệu thí nghiệm có được thiết kế để kiểm chứng một niềm tin cụ thể về hành vi của hệ thống hay không, và kết quả của nó có thay đổi những gì đội ngũ của bạn biết về sự lan truyền lỗi (failure propagation) trong stack hay không.

Nếu câu trả lời trung thực của bạn là "chúng tôi đã chấm dứt một số pod và chúng đã phục hồi", bạn đã chạy một thí nghiệm an toàn. Nhưng liệu bạn có học được điều gì hữu ích hay không là một câu hỏi riêng biệt mà các công cụ hiện tại không đề cập đến.

Bài viết này đưa ra một lập luận cụ thể: Chaos Engineering hiện nay có một lớp an toàn (safety layer) trưởng thành nhưng gần như không có lớp ý định (intent layer). An toàn cho bạn biết nên phá vỡ bao nhiêu. Ý định cho bạn biết việc phá vỡ đó sẽ dạy được điều gì. Đây là hai vấn đề thiết kế khác nhau đòi hỏi các công cụ khác nhau, và việc nhầm lẫn giữa chúng là lý do khiến các chương trình Chaos ở quy mô lớn có xu hướng tích lũy các kịch bản (script) mà không tích lũy được sự thấu hiểu.

Lớp An toàn là tốt, nhưng chưa đủ

Hãy bắt đầu bằng cách công nhận mô hình hiện tại. Khung SLO error-budget, được Google phổ biến qua thực hành SRE, đã mang lại cho Chaos Engineering cơ chế an toàn nguyên bản đầu tiên. Việc gắn việc thực hiện thí nghiệm với ngân sách lỗi còn lại có nghĩa là bạn không tiêm lỗi vào một hệ thống đang tiêu thụ hết độ tin cậy của nó. Các điều kiện dừng (stop conditions) của AWS Fault Injection Service, điểm độ tin cậy của Gremlin và các chính sách Rego của Harness ChaosGuard đều đại diện cho các triển khai trưởng thành, sẵn sàng cho môi trường sản xuất của ý tưởng này.

Những công cụ này trả lời một câu hỏi được đặt ra tốt: cho trạng thái hiện tại của hệ thống, có an toàn để chạy thí nghiệm ngay bây giờ không? Câu trả lời có thể tính toán, tự động hóa và khá chính xác. Nhưng câu hỏi mà chúng không trả lời cũng quan trọng không kém: cho trạng thái hiện tại của hệ thống, thí nghiệm nào sẽ cung cấp nhiều thông tin nhất nếu chạy ngay bây giờ?

An toàn và tính cung cấp thông tin là trực giao. Một thí nghiệm có thể thỏa mãn mọi ràng buộc an toàn, nằm trong ngân sách, không kích hoạt hủy bỏ, không gây suy giảm đáng đoán, nhưng vẫn không tạo ra gì hữu ích. Nếu nó kiểm tra một thành phần không nằm trên đường dẫn quan trọng (critical path) của bất kỳ hành vi nào hướng tới người dùng, bạn đã tiêu ngân sách để không học được gì cả.

Kiến trúc Chaos Engineering dựa trên ý định

Hình 1: Kiến trúc hệ thống Chaos Engineering dựa trên ý định.

Góc nhìn từ các chuyên gia thực tế

Các quan sát sau đây được thu thập từ các chuyên gia thực hành. Khảo sát kỹ sư ở nhiều ngành nghề khác nhau đã xây dựng các chương trình Chaos trong môi trường sản xuất đều hội tụ về một khoảng trống cấu trúc giống nhau từ các góc độ khác nhau.

Abhishek Pareek, Founder & Director tại Coders.dev, người xây dựng công cụ cho hệ thống phân tán, có nhận định sắc bén nhất về vấn đề này:

"Những gì chúng ta thiếu là sự hiểu biết về khả năng phục hồi dựa trên ý định (intent-based resiliency). Các công cụ hiện nay chủ yếu dựa trên kịch bản, và chúng ta cần tạo ra các công cụ có thể mô hình hóa tác động của một lỗi cụ thể lên một số lượng lớn vi dịch vụ trước khi thực hiện thí nghiệm. Chúng ta cần AI hiểu được lý do đằng sau lỗi ngoài cơ chế của lỗi."

Edward Tian, CEO của GPTZero, người vận hành cơ sở hạ tầng suy luận AI ở quy mô lớn, cũng chia sẻ:

"Các công cụ Chaos hiện tại tiêm các điểm lỗi tùy ý nhưng không cung cấp bất kỳ hướng dẫn có ý nghĩa nào cho người dùng về những gì họ đang cố gắng xác thực. Sự tiến hóa tiếp theo của Chaos sẽ bao gồm việc nhắm vào các câu hỏi cụ thể về khả năng phục hồi, chẳng hạn như 'hệ thống của chúng ta có duy trì được sự suy giảm trong việc truy xuất dữ liệu không?' thay vì sử dụng một kịch bản chung cho tất cả."

Kiến trúc dựa trên Ý định (Intent-Based Architecture)

Bằng sáng chế Mỹ 12242370B2 mô tả một hệ thống trong đó các tham số thí nghiệm Chaos được dẫn xuất từ các đặc tả hành vi (behavioral intent) thay vì được mã hóa cứng bởi kỹ sư.

Đặc tả Ý định (Intent Specification)

Đặc tả là đầu vào mà hệ thống yêu cầu trước khi tạo ra bất kỳ thí nghiệm nào. Dưới đây là một ví dụ cụ thể cho bài kiểm tra khả năng phục hồi quy trình thanh toán (checkout):

# intent_spec.yaml
intent:
  id: exp-checkout-inv-2025-01
  target_behavior: checkout_completion
  hypothesis: >
    Quy trình thanh toán hoàn thành trong SLO khi dịch vụ tồn kho
    trải qua độ trễ đọc tăng cao (p99 > 500ms).
    Cầu chì (circuit breaker) trên inventory_read sẽ ngắt trước
    khi tỷ lệ lỗi người dùng vượt quá 0.1%.
  acceptance_criteria:
    checkout_p99_latency_ms: 400
    checkout_error_rate_pct: 0.1
    slo_budget_fraction: 0.001   # tối đa 0.1% ngân sách lỗi hàng ngày
  exclusion_zones:
    - payment_auth
    - fraud_detection

Hãy lưu ý những gì mã này mã hóa mà một kịch bản Chaos thông thường không làm được: giả thuyết là một tuyên bố có thể bác bỏ về hành vi của hệ thống, không phải là mô tả về những gì sẽ bị phá vỡ. Các tiêu chí chấp nhận định nghĩa thế nào là "đạt" theo các thuật ngữ hành vi.

Đánh giá an toàn thời gian thực: Vượt qua ngưỡng tĩnh

Ishu Anand Jaiswal, Senior Engineering Leader tại Intuit, chỉ ra thành phần giúp đánh giá an toàn thực sự thông minh thay vì chỉ tự động hóa:

"Điều còn thiếu cho Chaos thực sự thông minh là một trình lập kế hoạch AI hiểu được cấu trúc liên kết trực tiếp (live topology) và 'ngân sách khả năng phục hồi' (resilience budget). Nó nên liên tục ước lượng bao nhiêu độ trễ, mất mát hoặc cạn kiệt tài nguyên bổ sung mà hệ thống có thể hấp thụ, sau đó chọn và sắp xếp trình tự các thí nghiệm nhằm tối đa hóa việc học trong khi vẫn nằm trong ngân sách đó."

Khái niệm "ngân sách khả năng phục hồi" khác với ngân sách lỗi SLO. Ngân sách lỗi đo lường mức độ tin cậy bạn đã tiêu dùng trong kỳ này. Ngân sách khả năng phục hồi là triển vọng: cho trạng thái hiện tại của hệ thống, nó có thể hấp thụ bao nhiêu căng thẳng bổ sung của một loại cụ thể trước khi các hành vi nằm ngoài phạm vi thí nghiệm bắt đầu suy giảm?

Vấn đề ngữ cảnh người dùng mà chỉ số hạ tầng không thể giải quyết

Isabella Rossi, CPO tại Fruzo, đã xây dựng các cơ chế Chaos dựa trên các tín hiệu hành vi thay vì chỉ số hạ tầng. Quan sát của cô chạm đến một vấn đề mà kiểm soát bán kính ảnh hưởng (blast-radius control) không thể giải quyết:

"Các công cụ Chaos Engineering thường coi khả năng phục hồi của hệ thống là một thuộc tính tĩnh. Chúng tiêm căng thẳng dựa trên thời gian trong ngày hoặc ngưỡng tải, điều này bỏ qua việc hệ thống có thể mong manh như thế nào trong một ngữ cảnh người dùng này và hoàn toàn ổn định trong ngữ cảnh khác. Một thời gian chờ cơ sở dữ liệu trong quá trình đăng ký là thảm họa. Cùng một thời gian chờ đó trong một tính năng tùy chọn thì khó ai nhận thấy."

Bảng dưới đây minh họa cách cùng một lỗi, trên cùng một thành phần, tạo ra mức độ nghiêm trọng bán kính ảnh hưởng rất khác nhau tùy thuộc vào hành vi người dùng nào đang hoạt động:

Lỗi	Thành phần	Ngữ cảnh người dùng	Mức độ nghiêm trọng
DB write timeout	user_profile_db	Signup flow	NGHIÊM TRỌNG, phiên bị chấm dứt
DB write timeout	user_profile_db	Cập nhật tùy chọn	THẤP, tự động fallback mặc định
Pod termination	inventory_service	Đang thanh toán	CAO, thanh toán có thể thất bại
Pod termination	inventory_service	Đồng bộ hàng loạt ban đêm	KHÔNG ĐÁNG KỂ, tự động thử lại

Tại sao đây là vấn đề của AI, không chỉ là vấn đề Điều phối (Orchestration)?

Sự phản đối hợp lý tại thời điểm này là mọi thứ được mô tả ở trên nghe có vẻ như là công việc kỹ thuật, duyệt đồ thị phụ thuộc, so sánh ngưỡng, ghi log có cấu trúc. Liệu chúng ta có thực sự cần AI cho việc này, hay chỉ cần hệ thống ống dẫn (plumbing) tốt hơn?

Hệ thống ống dẫn xử lý các quyết định xác định: nếu tỷ lệ tiêu thụ vượt quá X, hãy hủy bỏ. Nếu độ trễ vượt qua Y, hãy dừng lại. Những vấn đề yêu cầu mô hình đã học là những vấn đề mà không gian quyết định không thể liệt kê được:

1. Dự đoán bán kính ảnh hưởng trên cấu trúc liên kết mới: Dự đoán các tác động cấp hai của lỗi trên các thành phần không được nhắm mục tiêu trực tiếp yêu cầu khái quát hóa từ các mô hình hành vi trong các thí nghiệm trước đó.
2. Tạo giả thuyết: Dịch "kiểm tra khả năng phục hồi thanh toán dưới sự suy giảm tồn kho" thành danh sách được xếp hạng các loại lỗi được sắp xếp theo tính cung cấp thông tin mong đợi không phải là thực thi quy tắc.
3. Học trọng số nhạy cảm: Các trọng số cạnh trong đồ thị phụ thuộc không phải là thuộc tính tĩnh. Chúng thay đổi theo mô hình lưu lượng truy cập và thay đổi triển khai.

So sánh Chaos dẫn hướng bởi An toàn và Ý định

Hình 2: So sánh Chaos dẫn hướng bởi An toàn và Chaos dẫn hướng bởi Ý định.

Kết luận

Chaos Engineering có các nguyên mẫu an toàn đúng đắn. Điều nó thiếu là một cách tiếp cận có nguyên tắc tương xứng về tính cung cấp thông tin. Nếu không có lớp ý định, các chương trình Chaos có xu hướng rơi vào hai chế độ thất bại: các kịch bản kiểm tra lặp đi lặp lại cùng một thứ, và các thí nghiệm nằm trong ngân sách nhưng không tạo ra gì đáng để học hỏi.

Kiến trúc dựa trên ý định được đề cập trong bài viết này không thay thế các cơ chế an toàn mà lĩnh vực này đã xây dựng. Nó thêm một lớp làm cho các cơ chế đó có ý nghĩa hơn, dựa trên những gì người vận hành thực sự cố gắng học hỏi, dẫn xuất các thí nghiệm từ các đặc tả hành vi thay vì folklore kỹ thuật, và tích lũy một mô hình về động thái thất bại của hệ thống được cải thiện với mỗi lần chạy.