Vận hành 24/7: SRE, AIOps và kỷ luật xử lý sự cố
Hệ thống lên production mới là lúc công việc thật bắt đầu. SLO, on-call, runbook và blameless postmortem là bộ khung giữ dịch vụ đứng vững — và giữ đội không kiệt sức.
Trực 24/7 thường được hiểu là luôn có người thức. Cách hiểu đó tạo ra một đội kiệt sức trong sáu tháng và một hệ thống không ổn định hơn chút nào. Trực 24/7 đúng nghĩa là hệ thống biết khi nào cần gọi người, gọi đúng ai, và người đó biết phải làm gì.
Khác biệt nằm ở ba thứ: cảnh báo có chủ, quy trình có mức độ, và một vòng học sau sự cố.
Một cảnh báo không có chủ là một cảnh báo sẽ bị bỏ qua
Quy tắc đơn giản để lọc: mỗi cảnh báo phải trả lời được ba câu. Ai nhận. Người đó làm gì trong năm phút đầu. Nếu không làm gì thì hậu quả nghiệp vụ là gì. Cảnh báo nào không trả lời được cả ba thì nên chuyển sang dashboard, không gửi vào kênh trực.
Đây cũng là cách duy nhất giảm nhiễu một cách bền vững. Tắt bớt cảnh báo theo cảm tính sẽ làm mất luôn cái quan trọng. Gắn cảnh báo vào SLO thì tự nhiên phần nhiễu rơi ra, vì phần lớn nhiễu vốn không ảnh hưởng đến chỉ tiêu nào cả.
- Cảnh báo gắn với triệu chứng người dùng cảm nhận được, không gắn với chỉ số hạ tầng đơn lẻ.
- Ngưỡng suy ra từ error budget, không đặt bằng con số tròn cho dễ nhớ.
- Mỗi cảnh báo có liên kết tới runbook tương ứng, mở được ngay trong lúc trực.
- Cảnh báo lặp lại mà không cần hành động thì bị xoá, và việc xoá đó được ghi biên bản.
Mức độ sự cố tồn tại để quyết định nhanh, không để phân loại cho đẹp
Bảng phân mức P1–P4 chỉ có ích khi nó gắn với hành động cụ thể: ai được đánh thức, sau bao lâu thì leo thang, và ai có quyền tuyên bố sự cố kết thúc. Một bảng phân mức không gắn hành động thì trong lúc sự cố sẽ không ai mở ra đọc.
Trong sự cố, vai trò quan trọng nhất không phải người giỏi kỹ thuật nhất, mà là người điều phối: giữ dòng thông tin, ghi mốc thời gian, và ngăn năm người cùng sửa một thứ theo năm hướng khác nhau.
Chỉ tiêu đáng theo dõi của một đội trực không phải số cảnh báo đã xử lý, mà số cảnh báo đã không cần xuất hiện nữa.
Postmortem không quy trách nhiệm — và lý do thực dụng của nó
Postmortem blameless không phải là tránh làm ai khó chịu. Nó là cách duy nhất để biết chuyện gì thật sự đã xảy ra. Ở nơi có người bị phạt vì sự cố, thông tin sẽ được gọt trước khi tới biên bản, và nguyên nhân gốc sẽ mãi là “lỗi con người”.
Một biên bản có giá trị gồm: dòng thời gian dựa trên dữ liệu, tác động nghiệp vụ đo được, nguyên nhân gốc ở tầng hệ thống, và danh sách việc phải làm có người chịu trách nhiệm cùng hạn cụ thể. Không có danh sách việc thì đó chỉ là một bài tường thuật.
Vận hành là công việc phải giảm dần khối lượng
Một đội vận hành làm đúng sẽ thấy khối lượng việc thủ công giảm theo tháng, vì mỗi lần xử lý một việc lặp lại thì lần sau nó được tự động hoá. Nếu khối lượng không giảm, đội đang chỉ chịu tải chứ không cải thiện gì.
- Đo tỷ lệ thời gian dành cho việc lặp lại so với việc cải thiện hệ thống.
- Mỗi sự cố lặp lần thứ hai phải sinh ra một hạng mục tự động hoá.
- Báo cáo vận hành định kỳ nêu cả xu hướng, không chỉ con số của tháng.
- Runbook được cập nhật ngay sau khi dùng, lúc còn nhớ chi tiết.


