Reliability không nằm ở dashboard

Reliability không nằm ở dashboard

Một case study về cách nhìn AI ops như hệ thống quyết định, không phải màn hình cảnh báo đẹp. Bài dành cho team đang build AI vào vận hành thật.

Có một kiểu họp incident rất quen: dashboard đỏ rực, Slack ping như mưa dông, ai cũng mở thêm tab, rồi cuối cùng câu hỏi quan trọng nhất vẫn treo lơ lửng: “Cái này có ảnh hưởng khách hàng không, hay chỉ là metric đang khó ở?”

Mình đã thấy nhiều team Việt Nam bước vào AI ops bằng cách thêm một lớp chatbot lên log, gọi là “trợ lý vận hành”. Demo thì mượt. Hỏi “service nào đang lỗi?” nó trả lời có vẻ tự tin. Nhưng đến lúc production nổi gió, chatbot lại chỉ đọc lại cảnh báo, không giúp quyết định nên rollback, chặn deploy, hay gọi người phụ trách nào.

Case của Azure Brain đáng nhìn ở chỗ đó. Không phải vì “AI vận hành cloud” nghe hoành tráng, mà vì nó gợi ra một nguyên tắc khá lạnh gáy: giá trị của AI trong reliability nằm ở lớp quyết định và hệ quả, không nằm ở lớp kể lại tín hiệu.

Sơ đồ minh họa cho bài Reliability không nằm ở dashboard

Sơ đồ tóm tắt ý chính của bài viết.

Bối cảnh: khi observability chưa đủ để vận hành

Azure Brain được Microsoft mô tả là một hệ thống AIOps trung tâm cho reliability của Azure. AIOps ở đây nghĩa là dùng AI/ML để hỗ trợ vận hành hệ thống: gom telemetry, phát hiện bất thường, hiểu phụ thuộc dịch vụ, và đánh giá tác động.

Điểm đáng chú ý không phải là “có AI”. Cloud platform lớn nào cũng có cả núi telemetry: metric, log, trace, health signal, deployment event, dependency graph. Vấn đề là các tín hiệu này thường nằm rải rác như sương mù buổi sáng: nhìn đâu cũng thấy, nhưng rất khó biết đường nào dẫn tới nguyên nhân thật.

Azure Brain đặt một lớp “cloud reliability intelligence” phía trên Azure Resource Graph. Resource Graph hiểu đơn giản là bản đồ tài nguyên và quan hệ trong cloud: VM nào, region nào, service nào, workload nào, phụ thuộc vào đâu. Khi ghép bản đồ này với telemetry và mô hình AI/ML, hệ thống không chỉ hỏi “metric nào lạ?” mà hỏi gần hơn với vận hành thật: “dịch vụ nào bị ảnh hưởng, khách hàng nào có thể đang đau, và hành động nào nên bị chặn hoặc kích hoạt?”

Đây là khác biệt lớn với một dashboard đẹp. Dashboard trả lời “đang có gì xảy ra”. Một hệ thống reliability intelligence phải tiến thêm một bước: “vậy quyết định vận hành nào cần thay đổi?”

Quyết định kiến trúc: xây bản đồ trước, thêm AI sau

Nếu bóc hệ thống này theo lớp, mình sẽ không bắt đầu từ model. Mình sẽ bắt đầu từ ba lớp ít hào nhoáng hơn.

Lớp 1: digital twin cho cloud health.
Digital twin là bản sao số của hệ thống thật, dùng để mô phỏng và theo dõi trạng thái. Trong ngữ cảnh cloud, nó không phải mô hình 3D cho vui, mà là cách biểu diễn tài nguyên, region, service dependency và tình trạng health theo thời gian.

Không có lớp này, AI rất dễ biến thành người trực tổng đài đọc log. Có bản đồ phụ thuộc, hệ thống mới phân biệt được lỗi ở service gốc với lỗi lan truyền. Ví dụ cụ thể: API checkout chậm có thể không phải do checkout service, mà do database region phụ đang nghẽn, kéo theo retry tăng, làm queue phình ra. Nếu AI chỉ đọc log checkout, nó sẽ nhìn sai tâm bão.

Lớp 2: impact model — mô hình hóa tác động.
Đây là phần nhiều team bỏ qua. Một alert CPU cao chưa chắc cần đánh thức cả đội. Nhưng một thay đổi nhỏ trong service xác thực có thể ảnh hưởng đăng nhập trên diện rộng. Impact model là cách hệ thống ước lượng “ai bị ảnh hưởng, ảnh hưởng kiểu gì, mức nào”, thay vì chỉ đếm số cảnh báo.

Lớp 3: decision hooks — điểm móc vào quyết định.
Theo mô tả của Microsoft, Brain đã tham gia vào resource health notifications, deployment safeguards và outage declaration. Dịch ra công việc: nó không chỉ ngồi xem, mà có đường dây nối tới những quyết định như thông báo health cho khách hàng, bảo vệ quá trình deploy, hoặc hỗ trợ tuyên bố sự cố.

Đây mới là phần đáng học. AI ops không nên dừng ở câu trả lời “có vẻ đang lỗi”. Nó phải gắn với một hành động có chủ sở hữu, có tiêu chí, có rollback path.

Hệ quả: AI bắt đầu thay đổi quy trình, không chỉ giao diện

Khi một hệ thống như Brain đứng giữa telemetry và vận hành, hệ quả đầu tiên là incident workflow đổi hình.

Trước đây, quy trình quen thuộc là: alert nổ → người trực mở dashboard → đoán phạm vi → hỏi team liên quan → quyết định incident severity → thông báo khách hàng nếu cần.

Sau khi có lớp intelligence đủ tốt, workflow có thể chuyển thành: tín hiệu bất thường → hệ thống liên kết dependency → ước lượng customer impact → đề xuất hoặc kích hoạt guardrail → con người xác nhận quyết định quan trọng.

Ở đây có một tradeoff lớn: càng để AI gần quyết định vận hành, bạn càng phải đo được chất lượng quyết định, không chỉ độ chính xác trả lời. Guardrail là hàng rào an toàn để giới hạn hành động của hệ thống; trong production, guardrail quan trọng hơn prompt hay.

Giả sử team bạn 5 người đang vận hành một SaaS B2B. Bạn muốn dùng AI để hỗ trợ on-call. Nếu chỉ nối model vào log, bạn sẽ có bản tóm tắt nhanh hơn. Tốt, nhưng chưa đủ. Nếu bạn thêm service map, deployment history, danh sách khách hàng theo tier, và runbook rollback, AI mới có cơ hội trả lời câu đáng tiền hơn: “đợt deploy 14:05 có liên quan đến lỗi tăng ở nhóm khách hàng enterprise không, và có nên chặn rollout tiếp không?”

Nói gọn lại: AI ops trưởng thành khi nó biết bảo vệ quyết định, không chỉ mô tả thời tiết.

Bài học cho builder: framework 4 lớp trước khi gọi model

Nếu bạn là tech lead đang cân nhắc build “Brain mini” cho hệ thống của mình, đừng mở đầu bằng câu “dùng model nào?”. Mở bằng khung này:

1. System map: hệ thống của bạn liên kết ra sao?

Bạn cần một bản đồ tối thiểu:

Không cần hoàn hảo từ ngày đầu. Nhưng nếu không có map, AI chỉ nhìn từng mảnh rời.

2. Signal contract: tín hiệu nào đáng tin?

Không phải metric nào cũng cùng trọng lượng. Hãy phân loại:

Nếu mọi tín hiệu đều ngang hàng, model sẽ rất giỏi kể chuyện nhưng yếu ưu tiên.

3. Decision boundary: AI được quyết cái gì?

Đây là lớp hay bị né vì đụng quyền hạn. Nhưng né là nguy hiểm.

Bạn nên viết rõ:

Với hệ thống nhỏ, mình thường để AI ở mức recommendation with evidence: đề xuất kèm bằng chứng. Đừng cho nó tự bấm nút nguy hiểm chỉ vì demo tuần trước chạy êm.

4. Feedback loop: quyết định sau đó được học lại thế nào?

Nếu incident đã kết thúc mà hệ thống không học được gì, bạn chỉ đang thuê AI làm thư ký tạm thời. Cần lưu lại:

Feedback loop là vòng phản hồi để cải thiện hệ thống sau mỗi lần vận hành. Với AI ops, đây là nơi chất lượng tăng dần, thay vì phụ thuộc vào lần prompt may mắn.

Điều dễ bị thổi quá mức

Phần “agentic AI cho cloud operations” chắc chắn sẽ làm nhiều người phấn khích. Agentic AI là kiểu AI có thể lập kế hoạch, gọi tool, thực hiện nhiều bước thay vì chỉ trả lời văn bản. Nhưng với vận hành cloud, agent không phải nhân vật chính ngay từ đầu.

Thứ tự an toàn hơn là:

  1. gom và chuẩn hóa tín hiệu
  2. dựng bản đồ dependency
  3. đo customer impact
  4. gắn vào decision workflow
  5. sau đó mới tăng mức tự động hóa bằng agent

Nếu đảo ngược, bạn sẽ có một agent rất chăm chỉ chạy quanh phòng điều khiển, nhưng không biết cửa thoát hiểm ở đâu.

Cũng đừng mặc định hệ thống của Microsoft bê nguyên về là phù hợp cho startup hoặc team nội bộ. Azure vận hành ở quy mô cloud platform, còn team bạn có thể chỉ cần 20% ý tưởng: bản đồ service, phân loại signal, và rule chặn deploy khi impact vượt ngưỡng. Giá trị nằm ở quyết định đúng cho quy mô của mình.

Áp dụng trong một buổi chiều

Nếu muốn bắt đầu mà không biến thành dự án nửa năm, bạn có thể làm một phiên 3–4 tiếng như sau:

Bước 1: chọn một flow quan trọng nhất.
Ví dụ: login, checkout, tạo invoice, hoặc sync dữ liệu đối tác.

Bước 2: vẽ dependency graph thô.
Không cần tool xịn. Một file markdown cũng được:

Flow: Checkout
- frontend-web -> checkout-api
- checkout-api -> pricing-service
- checkout-api -> payment-gateway
- checkout-api -> orders-db
- checkout-api -> event-queue
Critical customers: enterprise, marketplace sellers
Rollback owner: platform-oncall

Bước 3: gắn 5 tín hiệu có nghĩa.
Chọn ít nhưng sắc: latency p95, error rate, payment failure, queue backlog, deploy event.

Bước 4: viết decision rule trước khi viết prompt.

Nếu payment failure tăng rõ rệt sau deploy mới:
- freeze rollout
- ping owner checkout-api
- tạo incident draft
- yêu cầu human approve rollback

Bước 5: mới cho AI tóm tắt và đề xuất.
Prompt lúc này không còn mơ hồ. Nó có bản đồ, tín hiệu, rule, và boundary.

Sau bài này, điều mình muốn bạn nghĩ khác là: đừng hỏi “AI có hiểu log không?”, hãy hỏi “AI có làm quyết định vận hành bớt mù sương không?”

Reliability không nằm trong dashboard đỏ hay model mới nhất. Nó nằm ở khoảnh khắc team biết nên đứng yên, rollback, hay kéo còi báo động. Trời có thể nổi áp thấp, nhưng hệ thống tốt là hệ thống giúp người trực không phải đoán hướng gió bằng cảm giác.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo