Hệ thống SRE làm bằng AI trong một buổi tối: Giảm thời gian xử lý sự cố xuống 4 phút

Chào mừng các bạn đến với bài viết đầu tiên của tôi trên dev.to 👋

Tôi muốn chia sẻ một điều gì đó mà tôi đã xây dựng tại công ty — một hệ thống mà tôi đã hoàn thiện chỉ trong một buổi tối, hoàn toàn do chính mình thực hiện.

Tôi xây dựng nó vì tôi thấy một cơ hội — và tôi biết lĩnh vực này thực sự quan trọng đối với công ty.

Bối cảnh thực tế

Hầu hết các cải tiến trong SRE (Site Reliability Engineering) thường đi kèm với nhiều công cụ hơn, nhiều bảng điều khiển (dashboard) phức tạp hơn.

Tôi lại đi theo hướng ngược lại.

Không có hệ thống mới. Không có thay đổi hạ tầng lớn. Chỉ đơn giản là một cách làm việc khác.

Trong quá trình xử lý các sự cố (incidents), chúng tôi liên tục phải tự đặt các câu hỏi:

• Vấn đề này đang xảy ra ở đâu nhiều nhất?
• Nó có đặc thù ở từng tenant (khách thuê) không?
• Nó có liên quan đến vùng (region) cụ thể nào không?
• Đây là vấn đề mới hay tái phát?

Dữ liệu thực sự đã tồn tại — nhưng quy trình để có được câu trả lời lại chậm chạp và thiếu nhất quán.

Những gì tôi đã xây dựng

Ban đầu chỉ là một tệp Markdown đơn giản, nhưng sau đó nó đã phát triển thành một thứ gì đó lớn hơn nhiều:

Một trợ lý SRE được hỗ trợ bởi AI.

Đây là một hệ thống có khả năng:

• Hiểu rõ kiến trúc của hệ thống
• Truy vấn nhật ký (logs) và chỉ số (metrics) theo thời gian thực
• Tìm kiếm các sự cố trong quá khứ và Runbooks (sách hướng dẫn quy trình)
• Điều tra các vấn đề môi trường production từ đầu đến cuối

Nó giống như một kỹ sư cấp cao đã làm việc tại đây từ ngày đầu tiên — và có mặt 24/7.

Tóm tắt hiệu quả

• Khoảng 4 phút để phân loại (triage) các sự cố
• Điều tra từ đầu đến cuối chỉ từ một đầu vào duy nhất
• Không cần chuyển đổi ngữ cảnh giữa các công cụ
• Hiển thị sự tương quan trực tiếp giữa mã nguồn, logs và metrics

👉 Đọc toàn bộ bài viết tại đây: I Cut MTTR to 4 Minutes — My “SRE” Is a 619-Line Markdown File

Tại sao tôi chia sẻ điều này?

Ban đầu, ý định của tôi không phải là tạo ra một "giải pháp lớn lao".

Nó chỉ đơn giản là:

"Hãy làm cho các ca trực (on-call) đỡ đau khổ hơn một chút."

Nhưng cuối cùng nó lại mang lại tác động thực sự đáng kể.

Vì vậy, tôi nghĩ nó đáng để được chia sẻ — và cũng để nhận được những phản hồi từ cộng đồng.

Những gì tôi đang suy nghĩ tiếp theo

Tôi muốn đi sâu hơn chi tiết trong các bài viết tiếp theo.

Một vài hướng mà tôi đang cân nhắc:

1. Thiết kế các Kỹ năng và Tác nhân xác định (Deterministic Skills & Agents)

Cách tôi xây dựng các kỹ năng và tác nhân hoạt động một cách có thể dự đoán được —

để bạn có thể kiểm thử, mở rộng và phát triển chúng mà không làm hỏng mọi thứ.

• Kiểm thử ở các lớp khác nhau
• Mở rộng với sự tự tin
• Tránh các sự cố tiềm ẩn (regressions)

2. Những ý tưởng mới cho các Tác nhân (Agents)

Ít nói về sự hào nhoáng (hype) — mà tập trung vào:

• Các trường hợp sử dụng thực tế
• Nơi mà các tác nhân thực sự giúp ích
• Và một số phương pháp thực tế mà tôi thấy hiệu quả

Mong muốn nhận được sự đóng góp của bạn

Nếu bất cứ điều gì nghe có vẻ thú vị — hãy cho tôi biết 🙌

• Bạn muốn tôi đi sâu vào điều gì tiếp theo?
• Bạn đã thử điều gì đó tương tự chưa?
• Ca trực của bạn có cảm thấy khó khăn hơn mức cần thiết không?

Cảm ơn đã đọc ✌️