On-call là cách tổ chức trách nhiệm vận hành để đảm bảo khi có incident xảy ra trong môi trường production, luôn có người được chỉ định nhận page, triage, phối hợp remediation và theo dõi đến khi service recovery.

Trong DevOps và SRE, on-call thường đi kèm với các thành phần như on-call rotation, paging, escalation policy, runbook, postmortem.

Ví dụ: Nếu hệ thống có alert rule báo lỗi 5xx tăng đột biến và vượt ngưỡng paging, hệ thống paging sẽ gửi page đến người đang on-call. Người on-call sẽ triage, xác định scope, rồi thực hiện remediation hoặc escalate theo escalation policy.

On-call phản ánh một phần rất quan trọng của reliability, vì nó quyết định tốc độ phát hiện và phản ứng khi production gặp sự cố.

On-call cho biết điều gì?

On-call giúp trả lời nhanh các câu hỏi cơ bản:

• Khi có incident, ai là người chịu trách nhiệm nhận page và điều phối xử lý?
• Thời gian phản hồi và thời gian khôi phục service đang ở mức nào?
• Alerting hiện tại có tạo ra quá nhiều noise và gây alert fatigue hay không?

Tuy nhiên, cần lưu ý: on-call không phải là giải pháp thay cho reliability engineering. Nếu hệ thống thường xuyên page vì alert rule kém hoặc vì thiếu automation, on-call sẽ nhanh chóng trở thành bottleneck về con người.

On-call khác alerting và incident response ra sao?

On-call thường được hiểu trong mối quan hệ với các khái niệm sau:

• Alerting: cơ chế phát hiện tín hiệu bất thường dựa trên metrics, logs, tracing và alert rule.
• Paging: cơ chế escalated notification, chỉ dùng cho tình huống cần action ngay để bảo vệ user impact.
• Incident response: quy trình xử lý incident end-to-end, bao gồm triage, mitigation, communication, remediation và postmortem.

Một hệ thống có alerting đầy đủ chưa chắc vận hành tốt nếu paging bị lạm dụng hoặc escalation policy không rõ ràng.

Cách hiểu on-call

Một số nguyên tắc cơ bản khi vận hành on-call:

• On-call phải gắn với mục tiêu rõ ràng như SLO và user impact, không phải gắn với mọi alert.
• On-call rotation cần minh bạch, có backup, có escalation policy và có handoff.
• Runbook cần đủ cụ thể để người on-call có thể action nhanh, giảm MTTR.

Ví dụ:

• Page ít nhưng đúng, runbook rõ, escalation policy rõ ràng: on-call nhẹ, MTTR tốt, reliability ổn.
• Page nhiều do noise, thiếu dedup, thiếu suppression: alert fatigue tăng, quality của incident response giảm.
• On-call thường xuyên phải làm manual remediation: thiếu automation, dễ tạo bottleneck và rủi ro human error.

On-call thường được tổ chức như thế nào?

Tuỳ quy mô team và kiến trúc hệ thống, on-call thường có các thành phần sau:

• On-call rotation: lịch trực theo ca, có primary và secondary.
• Escalation policy: quy tắc escalate nếu primary không acknowledge trong thời gian quy định.
• Handoff: chuyển ca có checklist để tránh missing context.
• Runbook: hướng dẫn triage và remediation cho các alert phổ biến.
• Incident channel: kênh phối hợp, ghi lại timeline và quyết định.

Trong vận hành thực tế, nên bắt đầu từ mô hình đơn giản primary và secondary, sau đó tối ưu dần theo mức độ page và độ phức tạp của incident.

Những yếu tố có thể làm on-call bị quá tải

Một số nguyên nhân khiến on-call trở nên nặng và kém hiệu quả:

• Alert rule không gắn với user impact, paging cả những cảnh báo không cần action ngay.
• Thiếu dedup, grouping, suppression khiến một sự cố tạo ra hàng loạt page.
• Thiếu runbook, thiếu ownership, thiếu escalation policy rõ ràng.
• Thiếu automation cho các remediation lặp lại, khiến on-call phải làm manual work.
• Không có postmortem hoặc postmortem không tạo ra action item cụ thể.

Vì vậy, on-call nên được cải thiện bằng cách giảm noise, nâng chất lượng alert rule, chuẩn hoá runbook và ưu tiên automation cho các tác vụ lặp.

On-call được dùng để làm gì trong DevOps?

Ở mức cơ bản, on-call thường được dùng cho:

• Đảm bảo có người chịu trách nhiệm phản ứng khi production có incident.
• Rút ngắn time to acknowledge và giảm MTTR thông qua runbook và escalation policy.
• Là tín hiệu để ưu tiên reliability work, dựa trên số lần page, top alert, và recurring incident.
• Kết nối với SLO và error budget để quyết định khi nào cần freeze release hoặc ưu tiên remediation.

Metrics nên theo dõi để cải thiện on-call

Một số metrics hay dùng khi review on-call:

• Time to acknowledge
• MTTR
• Số lần page theo service và theo alert rule
• Tỉ lệ page ngoài giờ và phân phối theo on-call rotation
• Top recurring incident và tỉ lệ action item hoàn thành sau postmortem

Các metrics này giúp team xác định đâu là nguồn noise, đâu là bottleneck, và đâu là automation opportunity.

Kết luận

On-call là cơ chế vận hành để đảm bảo khi production có incident, luôn có người nhận page, triage và phối hợp remediation đến khi service recovery.

Tuy nhiên, on-call chỉ bền vững khi paging được dùng đúng chỗ, alert rule có chất lượng, runbook rõ ràng, và team liên tục giảm noise thông qua automation và postmortem action item.