Vì sao chúng tôi đặt một gateway trước mọi agent AIOps

Bản pilot đầu tiên không có gateway. Chúng tôi nối thẳng một agent vào observability stack, cấp cho nó công cụ để query metrics và đọc runbook, rồi thả nó vào một luồng alert. Demo thì chạy ngon. Nhưng nó vỡ ngay tuần đầu tiên khi gặp lượng tải thật.

Đây là câu chuyện về cái gì đã hỏng, và một quyết định kiến trúc duy nhất — một gateway đứng giữa các agent và phần còn lại — đã khiến cả hệ thống trở nên kiểm soát được.

Một pilot AIOps thực ra giải bài toán gì

Lời chào hàng của AIOps rất hấp dẫn: kỹ sư trực thức dậy với một sự cố đã được phân loại, thay vì một bức tường alert. Agent đã tự tương quan cú spike, kiểm tra các lần deploy gần đây, kéo log liên quan, và viết một bản tóm tắt hai dòng kèm điểm tin cậy.

Đó là đầu ra. Phần khó là tất cả những gì nằm giữa lúc alert kích hoạt và lúc bản tóm tắt đó rơi vào Slack — và gần như không phần nào trong đó là model.

Khi vẽ lại luồng thật, một task đơn giản "phân loại alert này" toả ra cả chục lời gọi công cụ: query metrics backend, tra chủ sở hữu service, đọc ba bản runbook gần nhất, kiểm tra deploy log, tìm các sự cố cũ có cùng dấu hiệu. Mỗi cái là một credential, một rate limit, một timeout, và một thứ có thể gọi điện dựng chúng tôi dậy lúc 3 giờ sáng nếu nó cư xử sai.

Cái gì hỏng khi không có gateway

Ba thứ, xếp theo mức độ đau.

Credential vương vãi khắp nơi. Mỗi agent cần truy cập trực tiếp vào mọi backend. Tức là một secret nằm trong môi trường của từng agent, nhân với từng backend, và không có một chỗ duy nhất để xoay vòng hay thu hồi. Vòng review bảo mật mắc kẹt ngay đây — và đúng là phải mắc kẹt.

Không quan sát được gì. Khi một agent làm điều gì đó ngớ ngẩn — và chúng hay làm vậy — chúng tôi không có một điểm chạm duy nhất để xem nó đã gọi công cụ nào, với tham số gì, và nhận về cái gì. Debug nghĩa là đọc log rải rác qua năm service rồi đoán thứ tự.

Chi phí và rate limit vô hình cho tới khi nhận hoá đơn. Một agent kẹt trong vòng lặp retry có thể nện vào metrics API cả nghìn lần trước khi ai đó để ý. Chúng tôi không có backpressure, không có ngân sách theo từng agent, không có nút tắt nào ngoài việc gỡ cả deployment.

Không cái nào trong số này là vấn đề của model. Chúng là vấn đề đường ống. Và vấn đề đường ống cần một giải pháp đường ống.

Topology chúng tôi chốt

Chúng tôi đặt một agent gateway duy nhất giữa các agent và thế giới bên ngoài. Mọi lời gọi công cụ — mọi query, mọi lần đọc runbook, mọi lần ghi ngược vào kênh sự cố — đều đi qua nó. Các agent không còn giữ credential hay biết backend nằm ở đâu. Chúng biết gateway, và gateway biết tất cả phần còn lại.

Một nước đi đó gom ba vấn đề về một chỗ mà bạn thực sự có thể suy luận được:

• Auth nằm ở gateway. Backend tin gateway, không tin các agent. Xoay một credential là một thay đổi, không phải mười hai. Thu hồi một agent là bật một cái cờ.
• Mọi lời gọi đều được log tại gateway. Một điểm chạm, đầy đủ request/response, đúng thứ tự. Lần đầu tiên có thể replay đúng đường ra quyết định của một agent, thời gian để hiểu "à, thì ra là vậy" giảm từ cả buổi chiều xuống vài phút.
• Policy nằm ở gateway. Rate limit, ngân sách theo từng agent, và một allow-list về việc agent nào được phép chạm tới công cụ nào — tất cả được thực thi trước khi một request kịp chạm vào backend. Sự cố vòng lặp retry trở thành một mã 429 mà agent phải tự xử lý, chứ không phải một bất ngờ trên hoá đơn.

Hình dạng này nhàm chán một cách có chủ đích. Cũng chính là lý do bạn đặt một API gateway trước các microservice, hay một service mesh giữa chúng: khi có N thứ nói chuyện với M thứ, bạn không muốn N×M quan hệ. Bạn muốn N+M, với một đường nối được kiểm soát ở giữa.

Các agent trở nên đơn giản hơn khi gateway xuất hiện. Chúng thôi đóng vai một thành phần của hệ phân tán và quay về làm đúng việc chúng giỏi: suy luận trên dữ liệu mà gateway trao cho.

Gateway không phải là gì

Rất dễ để cái đường nối này phình thành một god object. Chúng tôi giữ vững hai ranh giới.

Gateway không suy luận. Nó định tuyến, xác thực, ghi log, và thực thi policy. Khoảnh khắc nó bắt đầu quyết định runbook nào mới liên quan, bạn đã dồn phần logic thú vị vào đúng cái thành phần khó test độc lập nhất.

Gateway không phải một cache giả làm bộ não. Chúng tôi có cache các lần đọc idempotent — cùng một query metrics trong một lần triage không nên chạm backend hai lần — nhưng cache là một tối ưu trong suốt, không phải nơi để mã hoá phán đoán.

Pilot có đáng không?

Câu trả lời thật lòng: giá trị của pilot không nằm ở việc chứng minh một LLM có thể phân loại alert. Chúng tôi biết là nó làm được. Giá trị nằm ở chỗ phát hiện ra model chỉ chiếm chừng 20% công việc, và 80% còn lại là phần hạ tầng nhàm chán nhưng then chốt — thứ quyết định liệu bạn có thể vận hành cái này một cách an toàn hay không.

Nếu bạn đang lên phạm vi cho một pilot AIOps, hãy tính ngân sách theo hướng đó. Dành tuần đầu cho cái đường nối — gateway, mô hình auth, khả năng quan sát — rồi các agent sẽ có một nền vững để đứng. Bỏ qua nó, bạn vẫn sẽ tốn tuần đó thôi, chỉ là ở môi trường production, lúc 3 giờ sáng, debug một agent vừa gọi điện dựng cả team dậy.

---

Chúng tôi thiết kế và xây hạ tầng platform và AI kiểu như thế này theo hướng trọn gói. Nếu bạn đang dựng một thứ tương tự và muốn thêm một cặp mắt soi vào topology, liên hệ với chúng tôi.