Cách Anthropic dùng Claude Tag làm 'trợ lý trực chiến' xử lý sự cố CI/CD

Thiết lập chế độ trực sự cố (on-call) với Claude của riêng bạn bằng bộ công cụ cài đặt của chúng tôi.

Vài tuần trước, tôi đang trong ca trực thì đồng nghiệp gửi tin nhắn qua Slack lúc 10 giờ tối: khoảng 44 bài kiểm thử (test) trên một dịch vụ mới không chạy được.

Trước đây, tôi sẽ phải dừng công việc đang làm, ngồi vào máy tính, thở dài ngao ngán và bắt đầu quy trình điều tra và sửa lỗi kéo dài cả tiếng đồng hồ. Nhưng giờ đây, quy trình làm việc của tôi đã hoàn toàn khác: tôi gọi @Claude vào và hỏi xem nó thấy những gì.

Trong trường hợp này, Claude phát hiện các bài kiểm thử biến mất khi một tính năng (feature flag) được bật vào sáng hôm đó, và cũng cho biết rằng việc hoàn tác (revert) là an toàn. Tôi yêu cầu đồng nghiệp hoàn tác tính năng đó. 3 phút sau, Claude ping tôi trên Slack để xác nhận rằng các quy tắc bỏ qua (skip rules) đã thực sự được gỡ bỏ và tỷ lệ lỗi đã trở lại mức bình thường.

Trong vài tháng qua, Claude Tag đã trở thành người phản ứng đầu tiên cho các sự cố CI/CD tại Anthropic. Điều này không chỉ giúp ích cho đời sống cá nhân của chúng tôi mà còn cung cấp cho mỗi sự cố CI một người phản ứng tức thời: Claude đã soạn thảo báo cáo tình hình đầu tiên trong mọi sự cố gần đây, thường đưa ra phân tích đầu tiên trong vòng 15 phút.

Trong bài viết này, chúng tôi sẽ hướng dẫn những gì chúng tôi đã xây dựng và cách thức hoạt động của nó để bạn có thể tự thiết lập và không còn cảm thấy sợ hãi mỗi khi đến lượt trực.

Thiết lập Claude on-call của chúng tôi

Trước khi đi sâu vào từng giai đoạn của quy trình phản ứng sự cố, tôi sẽ cung cấp cái nhìn tổng quan về thiết lập của chúng tôi tại đây để bạn có cái nhìn bao quát trước khi chúng ta đi vào chi tiết.

Một tác nhân (agent) trực sự cố cần có bộ nhớ để ghi nhớ những gì đã thực hiện; các kết nối và quyền truy cập để có thể điều tra, thấu hiểu và hành động; lịch trình để biết khi nào cần quay lại làm việc; và các hướng dẫn để biết cần phải làm gì.

Claude Tag là xương sống của tác nhân trực sự cố của chúng tôi. Claude Tag lưu trữ bộ nhớ trên kênh Slack trực sự cố và giao diện để cung cấp các hướng dẫn theo từng lượt trong suốt sự cố. Claude cũng hành động theo thời gian thực đối với các sự kiện trong kênh trực sự cố và các kênh khác. Việc lập lịch trình cho các thói quen, hoặc các hành động thường xuyên mà Claude thực hiện, cũng diễn ra trên kênh này với các câu lệnh ngôn ngữ tự nhiên như “chạy bàn giao CI vào mỗi thứ Hai lúc 9:00 sáng EST.”

Claude Tag có tài khoản dịch vụ riêng và quyền truy cập vào các công cụ mà một kỹ sư CI tại Anthropic cần như Datadog hoặc Grafana. Việc này được quản trị viên thiết lập một lần cho kênh (xem cách thực hiện tại đây).

Ngoài kênh trực sự cố, chúng tôi thiết lập để Claude theo dõi các kênh liên quan khác mà Claude Tag cũng là thành viên, nhờ đó nó có thể nắm bắt thêm ngữ cảnh như các cảnh báo dịch vụ, thay đổi cấu hình hoặc cập nhật về các PR.

Các hướng dẫn thường trực được lưu dưới dạng tệp markdown như các kỹ năng (skills), được commit vào một kho lưu trữ GitHub. Bằng cách này, nhiều đồng đội có thể cùng chỉnh sửa và chúng tôi có thể quản lý các thay đổi giống như cách quản lý mã nguồn. Nó cũng bao gồm các thông tin quan trọng như hướng dẫn định tuyến, chính sách và nhật ký các bài học kinh nghiệm như một phần của vòng lặp tự cải thiện.

Thiết lập này chỉ tốn của chúng tôi vài giờ, không phải vài ngày. Chúng tôi đã tạo một bộ công cụ thiết lập on-call tổng quát trên GitHub để giúp bạn bắt đầu với một tác nhân tương tự. Nó chuyển đổi lịch sử sự cố của nhóm bạn thành các playbook xử lý và để lại một Claude ở chế độ chỉ đọc trong kênh sự cố của bạn, giúp chẩn đoán, leo thang và học hỏi. Bạn có thể xem nó chạy thử với lịch sử của một nhóm giả định trong khoảng mười phút.

Tóm tắt các bước theo phong cách TL;DR (Quá dài, không đọc)

Bây giờ, hãy đi sâu vào chi tiết về sự chuyển đổi này trông như thế nào ở mỗi bước của một sự cố.

Phát hiện

Claude không chỉ thay đổi cách bạn phản ứng với sự cố, nó còn thay đổi cách bạn phát hiện ra chúng ngay từ đầu. Trước đây, có hai chế độ lỗi chính khi phát hiện sự cố.

Rất khó để con người có đủ tầm nhìn xa để thiết lập các quy tắc hoàn hảo với các ngưỡng hoàn hảo mọi lúc. Điều này đặc biệt khó khăn khi bạn không có đủ dữ liệu để phân tích các mô hình lưu lượng truy cập.

Để giải quyết vấn đề này, chúng tôi để Claude phân tích dữ liệu và các cảnh báo đến trong vài ngày đầu của một dịch vụ mới nhằm đề xuất các quy tắc bổ sung và tinh chỉnh bất kỳ quy tắc nào quá rộng hoặc quá hẹp.

Chế độ lỗi chính thứ hai khi phát hiện sự cố là sự mệt mỏi vì cảnh báo (alert fatigue): việc kiểm tra và xác minh mọi cảnh báo kích hoạt là rất tẻ nhạt. Tuy nhiên, Claude không bị mệt mỏi theo cách con người vẫn bị.

Claude giám sát mọi cảnh báo liên quan trong mỗi kênh cảnh báo và xem xét các tiêu chí trong tệp root oncall.md để xác định xem có thể đợi đến sáng hay cần phải gọi người trực (page). Ví dụ, sau khi được tinh chỉnh từ việc phân tích dữ liệu, một quy tắc trong tệp có thể là: “Nếu tỷ lệ lỗi lớn hơn 2% trong hơn 5 phút VÀ không nằm trong khung thời gian triển khai đã biết, hãy gọi người trực, nếu không thì ghi vào lessons.md.”

Có hai cách khác mà quy trình cảnh báo on-call của Claude có thể kích hoạt:

Điểm mấu chốt ở đây là quy trình cảnh báo mang tính xác định (deterministic), trong khi việc leo thang sự cố có cả con đường xác định và con đường tác nhân (agentic).

Phân loại (Triage)

Việc Claude lọc bớt nhiễu cảnh báo là một chuyện, nhưng lợi ích thực sự đến từ quá trình điều tra. Claude đăng phân tích dựa trên bằng chứng đầu tiên của mình với thời gian trung vị là 14 phút sau khi sự cố mở ra, và trong những trường hợp nhanh nhất, nó xác định nguyên nhân gốc rễ trong vòng 4 phút ở báo cáo đầu tiên.

Khi một cảnh báo đã được leo thang thành sự cố, Claude thường sẵn sàng trong kênh Slack của chúng tôi với một giả thuyết dựa trên bằng chứng mà chúng ta có thể xem xét. Claude Tag khởi động một quy trình làm việc động với một tác nhân điều phối, tác nhân này sẽ kích hoạt các tác nhân con thực thi để điều tra từng phụ thuộc và nguồn dữ liệu tin cậy.

Đối với chúng tôi, đó là Grafana, kho lưu trữ nhật ký, PagerDuty, GitHub, Kubernetes và các kênh sự cố Slack – tất cả được kết nối qua các MCP Connector. Claude có thể theo đuổi nhiều đầu mối song song, giúp giảm MTTR (thời gian trung bình để giải quyết sự cố).

Các tác nhân thực thi báo cáo kết quả lại cho tác nhân điều phối, tác nhân này tổng hợp và hiển thị thông tin trong một báo cáo tình hình (SITREP) mạch lạc.

Các tác nhân điều phối và thực thi không tìm kiếm một cách mù quáng. Chúng được hướng dẫn bởi một kỹ năng điều tra với các tệp markdown tham khảo chi tiết hơn cho từng loại lỗi.

Ví dụ, một kỹ năng điều tra dài 617 dòng cho các lỗi phân kỳ bóng (shadow divergence) mã hóa mọi bước tôi thực hiện trong một cuộc điều tra điển hình. Tôi đã xây dựng nó bằng cách khắc phục sự cố cùng Claude từng bước trong một trong các sự cố và sau đó yêu cầu nó tạo tệp từ trải nghiệm đó.

Lessons.md cũng hướng dẫn Claude khắc phục sự cố. Tệp markdown này là nhật ký liên tục của mọi sự cố chúng tôi đã giải quyết: chuyện gì đã xảy ra, nguyên nhân gốc rễ, cách sửa lỗi và những điểm cần lưu ý. Claude tự động thêm nội dung vào đó. Mọi cuộc điều tra mới đều bắt đầu bằng việc đọc tệp này, vì vậy giả thuyết đầu tiên của Claude bắt đầu với những gì đã xảy ra gần đây.

Nếu cùng một mô hình xuất hiện đủ nhiều lần, chúng tôi sẽ đưa nó vào chính kỹ năng điều tra. Mục yêu thích của tôi là mục Claude viết về tôi. Tôi đã đưa ra một giả định từ tệp cấu hình trước khi kiểm tra các chỉ số, và tệp lessons.md hiện ghi: "hãy truy vấn dữ liệu trước, sau đó mới đưa ra lý thuyết. Cấu hình cho bạn biết những gì có thể sai; chỉ số cho bạn biết những gì đã thực sự sai."

Ngay cả với những công cụ và ngữ cảnh này, Claude không phải lúc nào cũng làm đúng ngay lần đầu tiên. Trực giác và kinh nghiệm của con người vẫn rất quan trọng. Claude Tag cho phép nhóm khắc phục sự cố ở chế độ nhiều người chơi. Bất kỳ ai trong chúng tôi cũng có thể điều hướng cuộc điều tra hoặc thêm giả thuyết theo thời gian thực, cùng nhau.

Giải quyết