LangChain xây dựng SRE Agent tự động hóa vận hành Kubernetes

Cách chúng tôi xây dựng một SRE Agent tự động cho các triển khai Kubernetes

Tôi là một Deployed Engineer tại LangChain, và phần lớn công việc của tôi gắn liền với Kubernetes. Tôi quản lý cụm (cluster) tự lưu trữ nội bộ của chúng tôi (đây cũng là nơi các tính năng tự lưu trữ mới được triển khai đầu tiên để nhóm có thể kiểm thử ngay khi chúng ra mắt), đồng thời hỗ trợ khách hàng thiết lập và nâng cấp môi trường tự lưu trữ của riêng họ. Công việc này đòi hỏi một mô hình tư duy đủ sâu về một cụm đang hoạt động để khi hệ thống gặp sự cố, tôi có thể đọc kiến trúc, tìm ra lỗi và khắc phục nó. Việc duy trì điều đó liên tục, song song với một công việc toàn thời gian, là rất kiệt sức, và tôi không phải là người duy nhất. Bất kỳ ai làm việc trong lĩnh vực hạ tầng đều hiểu những nỗi đau này.

Vì vậy, chúng tôi đã xây dựng một SRE Agent tự động để giảm thời gian phân loại và thời gian khắc phục sự cố. Mục tiêu là cải thiện độ tin cậy của hạ tầng và giảm tải nhận thức cho nhóm. Chúng tôi muốn nó tự động phân loại tình trạng sức khỏe của Kubernetes, đề xuất các bản sửa lỗi và chỉ cần sự can thiệp của con người khi cần thay đổi cụm hoặc hạ tầng. Bài viết này đề cập đến lý do tại sao, cách chúng tôi xây dựng nó, tại sao LangSmith giúp nó trở nên đáng tin cậy và những lợi ích mà chúng tôi đã thấy được.

Phần 1: Tại sao chúng tôi xây dựng nó

Kubernetes phát ra một lượng tín hiệu khổng lồ (trạng thái pod, số lần khởi động lại, trạng thái HPA (Horizontal Pod Autoscaling), điều kiện node, sự kiện cảnh báo, trạng thái sẵn sàng của deployment, trên hàng chục namespace) nhưng hầu như không có sự tổng hợp. Các kỹ sư trực ca sử dụng những tín hiệu này để trả lời ba câu hỏi: Có thứ gì đang bị hỏng không (crash loop, OOM kill, không có endpoint sẵn sàng); Có thứ gì sắp hỏng không (HPA bị ghim ở mức tối đa, service chỉ có một bản sao, thẻ ảnh:latest); Chúng ta phải làm gì với nó? Việc trả lời tốt những câu hỏi này đòi hỏi sự phán đoán, vì vậy nó thường rơi vào tay các kỹ sư hạ tầng hoặc chuyên gia, nhưng 90% công việc này là phân loại máy móc và hầu hết kết quả đều bình thường. Đây chính là công việc lặp đi lặp lại gây kiệt sức và khiến họ vô tình bỏ qua các cảnh báo quan trọng.

Phần 2: Những gì chúng tôi đã xây dựng

Giám sát chủ động. Một bộ lập lịch kiểm tra sức khỏe mỗi N phút mà không cần đánh thức toàn bộ agent. Nó thu thập trạng thái cụm thô thông qua Kubernetes Python client (không tốn LLM token), sau đó thực hiện một lệnh gọi Claude Haiku với việc bắt buộc sử dụng công cụ để tạo ra một báo cáo sức khỏe có cấu trúc gửi tới Slack, được sắp xếp theo mức độ nghiêm trọng.

Điều tra theo yêu cầu. Khi một vấn đề cần chẩn đoán, bộ điều phối sẽ phân tán công việc đến các subagent chuyên biệt chạy song song: pod-inspector, scaling-analyzer, performance-analyzer, log-analyzer, security-auditor, reliability-auditor, và nhiều hơn nữa. Mỗi subagent đọc cụm một cách độc lập trước khi tổng hợp thành một báo cáo ưu tiên.

Mô hình an toàn

Agent có thể đọc toàn bộ cụm nhưng không tự ý thay đổi bất cứ điều gì. Mọi thao tác ghi (mở rộng deployment, khởi động lại rollout, vá HPA) đều nằm trong một subagent change-executor duy nhất, và mỗi công cụ ghi đều được kiểm soát bởi cơ chế con người trong vòng lặp (HITL - human-in-the-loop). Agent đề xuất phương án khắc phục, và con người sẽ phê duyệt, từ chối hoặc chỉnh sửa ngay từ tin nhắn Slack. Việc đọc là tự động, còn việc ghi luôn được kiểm soát thông qua HITL. Điều này được thực thi về mặt cấu trúc và phản ánh qua RBAC trong cụm (đọc toàn cụm, ghi phạm vi hẹp).

Phần 3: Cách chúng tôi xây dựng nó (và tại sao)

Mỗi lựa chọn dưới đây là một ngã rẽ nơi con đường hiển nhiên và con đường đúng đắn tách biệt nhau.

Xuyên suốt kiến trúc của chúng tôi là giữ cho mọi thứ đơn giản và tiết kiệm chi phí nhất có thể. Chúng tôi chỉ chi tiêu token, sức mạnh mô hình và tăng bề mặt mạng ở những nơi cải thiện kết quả của agent đối với hạ tầng mà chúng tôi đang quản lý. Đó là điều giúp agent đủ rẻ để chạy mỗi vài phút và đủ an toàn để áp dụng vào môi trường production.

Phần 4: LangSmith giúp chúng tôi gỡ lỗi và cải thiện Agent như thế nào

Mọi quyết định trong Phần 2 đều chạy dưới dạng một LangSmith trace: kiểm tra định kỳ của Haiku, mỗi cuộc điều tra của subagent, mọi thao tác đọc và đề xuất ghi. Các phần Deep Agents và LangGraph được trace tự động; các lệnh gọi Anthropic trực tiếp của bộ lập lịch được bao bọc bởi @traceable.

Những gì các trace đã bắt được

Từ những phát hiện đó đến bộ kiểm thử hồi quy (regression suite)

Những lần chạy được gắn nhãn đó tạo thành xương sống cho các đánh giá của chúng tôi. Một pod bị phân loại sai hoặc một lỗi OOM bị bỏ sót sẽ được đưa vào tập dữ liệu LangSmith kèm theo câu trả lời đúng, và mọi tinh chỉnh về prompt hoặc mô hình sau đó đều được chạy thử nghiệm với LLM-as-judge và các trình đánh giá dựa trên mã nguồn, vì vậy một thay đổi gây ra hồi quy sẽ hiện lên con số màu đỏ và không được merge. Trường hợp dương tính giả về single-replica ở trên trở thành một trường hợp kiểm thử vĩnh viễn cho bộ eval của chúng tôi.

LangSmith Engine: chạy vòng lặp đó cho chúng tôi

Vòng lặp cải tiến ở trên vẫn dựa vào việc con người nhận thấy hành vi không mong muốn, tìm trace và đưa nó vào tập dữ liệu. Điều này tốn thời gian cho bất kỳ ai duy trì agent. LangSmith Engine tự động hóa công việc thủ công này. Nó giống như một kỹ sư agent chủ động theo dõi dự án tracing của chúng tôi theo ba giai đoạn.

Engine đã nhóm các trace của chúng tôi thành các vấn đề mở mà chúng tôi chưa tự ghi nhận. Một ví dụ là kiểm tra sức khỏe định kỳ không thu thập dữ liệu sử dụng. Bộ thu thập đã truy vấn node, pod, sự kiện cảnh báo, HPA và deployment, nhưng bước phân tích lại là một lệnh gọi forced-tool đơn lẻ mà không có công cụ nào khả dụng, vì vậy mô hình không thể lấy được những gì bộ thu thập đã bỏ qua. Mỗi báo cáo hàng giờ đều đặt ra một câu hỏi về năng lực mà nó không thể trả lời về mặt cấu trúc và trả lại cho chúng tôi dưới dạng hành động khuyến nghị như "kiểm tra chỉ số CPU/bộ nhớ của pod". Khả năng kubectl_top_pods và kubectl_top_nodes đã có sẵn trong repo cho agent tương tác nhưng chưa bao giờ được kết nối vào luồng định kỳ. Engine đề xuất kết nối chỉ số pod và node vào bộ thu thập, tái sử dụng logic phân tích đơn vị hiện có thay vì tạo ra logic mới, và giới hạn thay đổi trong bộ thu thập để prompt phân tích và thuộc tính zero-token không bị ảnh hưởng. Nó được gửi dưới dạng một pull request đã được xem xét, thêm vào tập dữ liệu của chúng tôi như một ví dụ, kiểm thử với tập dữ liệu để ngăn chặn hồi quy và chứng minh bản sửa lỗi hoạt động, sau đó được merge.

Phần 5: Tiếp theo là gì

Chúng tôi sẽ tiếp tục sử dụng SRE Agent nội bộ và đã bắt đầu triển khai nó cho một số khách hàng hiện tại của LangSmith. Chúng tôi đang tích cực phát triển và mở rộng khả năng của nó cho Kubernetes và các phần khác của stack. Một số cải tiến tiếp theo sẽ là làm cho trạng thái trở nên bền vững cho HITL, và làm cho vòng lặp giám sát có trạng thái để nó có bộ nhớ về các sự cố gần đây đã báo cáo. Nó là mã nguồn mở và có sẵn tại đây: https://github.com/langchain-samples/sre-agent. Hãy thoải mái dùng thử, đóng góp hoặc cung cấp phản hồi.