Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng 2 giờ sáng một ngày cuối tháng, hệ thống thanh toán của công ty bạn ngừng phản hồi. Khách hàng không đặt được đơn, tiền không vào, và mỗi phút trôi qua là hàng chục triệu đồng doanh thu bốc hơi. Câu hỏi đầu tiên không phải là "lỗi ở đâu?", mà là: "Ai đang trực? Ai sẽ bốc máy?"
On-call — trực ứng cứu sự cố — là ranh giới mỏng giữa một công ty vận hành nghiêm túc và một công ty chỉ "may mắn chưa sập". Với một Tech Lead, on-call không chỉ là chuyện kỹ thuật, mà là chuyện văn hóa, con người và trách nhiệm. Bạn là người thiết kế lịch trực, định nghĩa thế nào là "sự cố", và quyết định đội của mình sẽ ngủ ngon hay kiệt sức vì báo động giả.
Bài này đặt nền móng: on-call là gì, vì sao cần thiết, và cách thiết lập một hệ thống trực ứng cứu lành mạnh — bền vững cho cả hệ thống lẫn con người. Đây là bài "Foundations", nên chúng ta sẽ tập trung vào tư duy nền tảng và cấu trúc cơ bản. Quy trình chi tiết khi sự cố nổ ra (playbook, vai trò Incident Commander) sẽ được đào sâu ở Bài 17, còn cách học hỏi sau sự cố sẽ ở Bài 18. Ở đây, chúng ta xây móng trước.
Khái niệm cốt lõi
On-call là gì?
On-call là trạng thái một (hoặc một nhóm) kỹ sư được chỉ định sẵn sàng phản hồi khi hệ thống production gặp sự cố ngoài giờ làm việc thông thường. Người on-call không cần ngồi trước máy tính 24/7, nhưng phải:
- Mang theo thiết bị nhận cảnh báo (điện thoại, laptop).
- Cam kết phản hồi trong một khoảng thời gian nhất định (ví dụ 5–15 phút) khi có báo động nghiêm trọng.
- Có đủ quyền truy cập và kiến thức để chẩn đoán, giảm nhẹ (mitigate) hoặc leo thang (escalate) sự cố.
Tại sao cần on-call?
Thứ nhất, production luôn cần người ứng cứu 24/7. Người dùng của bạn ở khắp nơi, và với nhiều sản phẩm — thương mại điện tử, fintech, giao đồ ăn — cao điểm lại rơi vào buổi tối hoặc đêm khuya. Hệ thống không tự sửa được. Máy móc phát hiện lỗi, nhưng con người mới ra quyết định.
Thứ hai, triết lý "You build it, you run it". Amazon phổ biến nguyên tắc này từ giữa những năm 2000: đội nào xây dựng một dịch vụ thì đội đó cũng vận hành và chịu trách nhiệm khi nó hỏng. Ý tưởng cốt lõi là tạo ra một vòng lặp phản hồi (feedback loop) khép kín. Khi chính kỹ sư viết code phải thức dậy lúc 3 giờ sáng để xử lý bug của mình, họ sẽ tự nhiên viết code phòng thủ hơn, log tốt hơn, và ưu tiên độ tin cậy. Ngược lại, khi việc vận hành bị "ném qua tường" cho một đội ops riêng biệt, người viết code không bao giờ cảm nhận được nỗi đau của một hệ thống mong manh — và họ sẽ tiếp tục tạo ra những hệ thống mong manh.
Các mô hình on-call phổ biến
- Round-robin (luân phiên): mỗi tuần một người trong đội trực. Đơn giản, công bằng, phổ biến nhất cho đội nhỏ.
- Follow-the-sun (theo mặt trời): với công ty đa quốc gia, chuyển ca trực theo múi giờ để không ai phải trực đêm. Ví dụ đội Singapore trực ban ngày, chuyển sang đội ở châu Âu khi trời tối ở châu Á.
- Primary/Secondary (chính/phụ): người chính (primary) nhận báo động trước; nếu họ không phản hồi sau X phút, hệ thống tự động gọi người phụ (secondary). Đây là lưới an toàn quan trọng.
Alert vs Incident — phân biệt sống còn
Đây là điểm nhiều đội nhầm lẫn. Alert (cảnh báo) là một tín hiệu do hệ thống giám sát phát ra khi một chỉ số vượt ngưỡng. Incident (sự cố) là một tình huống thực sự ảnh hưởng đến người dùng hoặc kinh doanh, cần con người can thiệp.
Không phải alert nào cũng là incident. Nếu CPU chạm 80% lúc nửa đêm nhưng người dùng vẫn dùng bình thường và hệ thống tự cân bằng, đó chỉ là nhiễu. Một hệ thống on-call tốt phải chỉ đánh thức người khi thực sự cần. Nguyên tắc vàng: mỗi alert đánh thức người phải có thể hành động được (actionable) và phải khẩn cấp. Nếu không hành động được, hoặc có thể chờ đến sáng, nó không nên là một page (báo động gọi dậy).
Phân tầng mức độ nghiêm trọng (Severity levels)
Hầu hết công ty phân sự cố thành các cấp, thường là SEV1 đến SEV4 (hoặc P1–P4):
- SEV1: Hệ thống chết hoàn toàn, mất tiền/dữ liệu nghiêm trọng. Đánh thức người ngay, huy động cả đội.
- SEV2: Chức năng quan trọng bị hỏng, có giải pháp tạm nhưng cần xử lý gấp.
- SEV3: Ảnh hưởng nhỏ, một phần người dùng, có thể chờ giờ hành chính.
- SEV4: Vấn đề tiềm ẩn, không ảnh hưởng người dùng ngay.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT Việt Nam và cơn ác mộng "alert fatigue"
Một sàn thương mại điện tử tại TP.HCM (giả định, quy mô ~40 kỹ sư) triển khai on-call lần đầu bằng cách... bật tất cả cảnh báo có sẵn trong hệ thống giám sát. Kết quả: người trực mỗi đêm nhận trung bình 35–50 báo động, phần lớn là "disk usage 75%", "response time tăng nhẹ", "một pod restart". Sau ba tuần, kỹ sư trực bắt đầu tắt thông báo để ngủ. Và rồi đúng vào một đêm Black Friday, khi database thật sự quá tải, cảnh báo SEV1 quan trọng bị chôn vùi giữa hàng chục cảnh báo rác — không ai phản hồi trong 40 phút.
Diễn giải: Đây là hiện tượng alert fatigue (mệt mỏi vì báo động) kinh điển. Khi con người bị bội thực báo động vô nghĩa, họ mất khả năng phân biệt tín hiệu thật. Sự cố lớn nhất không phải do thiếu giám sát, mà do quá nhiều giám sát vô dụng.
Bài học: Ít mà chất. Đội này sau đó dọn dẹp lại, chỉ giữ ~5 cảnh báo cấp page dựa trên tác động thực tế đến người dùng (đơn hàng thất bại, thanh toán lỗi, trang chủ không tải được). Số lần bị gọi dậy giảm 85%, và quan trọng hơn, mỗi lần gọi giờ đây đều đáng tin.
Ví dụ 2 — Startup fintech và bài toán "một người gánh cả đội"
Một startup fintech ở Hà Nội có đúng ba kỹ sư backend. Ban đầu, mọi cảnh báo đều đổ về Trưởng nhóm kỹ thuật — vì "anh ấy rành hệ thống nhất". Trong sáu tháng, người này bị gọi dậy trung bình 4 đêm/tuần, không bao giờ dám đi du lịch, và cuối cùng nộp đơn nghỉ việc vì kiệt sức. Khi anh đi, không ai còn hiểu hệ thống đủ để trực.
Diễn giải: Đây là mô hình single point of failure về con người. Việc để một người "anh hùng" gánh toàn bộ on-call là con dao hai lưỡi: ngắn hạn thì tiện, dài hạn thì phá hủy cả đội và tạo ra rủi ro tri thức tập trung.
Bài học: On-call phải là trách nhiệm được chia sẻ và luân phiên, ngay cả khi đội nhỏ. Startup này chuyển sang round-robin ba người, kèm mô hình primary/secondary, và bắt buộc viết runbook (tài liệu hướng dẫn xử lý) cho mọi cảnh báo. Kết quả: kiến thức được lan tỏa, không ai là điểm nghẽn duy nhất, và áp lực được san đều.
Ví dụ 3 — Grab và mô hình "you build it, you run it"
Grab, khi mở rộng khắp Đông Nam Á, không thể để một đội ops trung tâm gánh toàn bộ vận hành cho hàng trăm dịch vụ. Họ áp dụng nguyên tắc mỗi đội sản phẩm tự chịu trách nhiệm on-call cho dịch vụ của mình, kèm theo các "guardrail": ngân sách lỗi (error budget), quy định số alert tối đa mỗi ca trực, và yêu cầu mọi dịch vụ phải có runbook trước khi lên production.
Diễn giải: Ở quy mô lớn, on-call phi tập trung là bắt buộc. Nhưng phi tập trung không có nghĩa là hỗn loạn — nó cần chuẩn chung để mọi đội đều đạt mức tối thiểu về độ tin cậy.
Bài học: Với vai trò Tech Lead, bạn không chỉ trực — bạn thiết kế điều kiện để việc trực trở nên bền vững: có tiêu chuẩn, có tài liệu, có giới hạn tải rõ ràng.
Hướng dẫn từng bước
Nếu bạn phải thiết lập on-call cho đội mình từ con số không, đây là lộ trình:
Bước 1 — Xác định cái gì thực sự quan trọng. Trước khi nói đến công cụ, hãy liệt kê các "user journey" then chốt: đăng nhập được không, đặt đơn được không, thanh toán được không. Độ tin cậy được đo bằng trải nghiệm người dùng, không phải bằng CPU.
Bước 2 — Thiết kế cảnh báo dựa trên triệu chứng, không phải nguyên nhân. Thay vì cảnh báo "CPU cao", hãy cảnh báo "tỷ lệ đơn hàng thất bại > 2%". Cảnh báo theo triệu chứng (symptom-based) bám sát tác động thực tế và ít gây nhiễu hơn nhiều.
Bước 3 — Chọn công cụ điều phối. Các công cụ như PagerDuty, Opsgenie, hoặc Grafana OnCall giúp quản lý lịch trực, leo thang tự động, và gọi đúng người. Đừng dựa vào email — email không đánh thức ai lúc 3 giờ sáng.
Bước 4 — Lập lịch trực công bằng. Bắt đầu bằng round-robin. Với đội tối thiểu 4–6 người để mỗi người trực khoảng một tuần mỗi tháng. Luôn có secondary làm lưới an toàn.
Bước 5 — Viết runbook cho mỗi cảnh báo. Mỗi alert cấp page phải kèm một tài liệu ngắn: triệu chứng là gì, kiểm tra ở đâu, các bước giảm nhẹ đầu tiên, khi nào leo thang. Runbook biến một cuộc gọi hoảng loạn lúc nửa đêm thành một quy trình bình tĩnh.
Bước 6 — Định nghĩa đường leo thang (escalation path). Ai được gọi tiếp nếu primary không phản hồi? Khi nào gọi Tech Lead? Khi nào gọi cả quản lý cấp cao (với SEV1)? Viết rõ ràng, dán ở nơi ai cũng thấy.
Bước 7 — Thiết lập quyền và công cụ truy cập. Người trực phải có sẵn quyền vào dashboard, log, hệ thống deploy để rollback. Không gì tệ hơn việc phát hiện ra lỗi nhưng không có quyền sửa lúc 3 giờ sáng.
Bước 8 — Chạy thử và cải tiến liên tục. Xem lại định kỳ: tuần này bị gọi mấy lần? Bao nhiêu lần là báo động giả? Mỗi báo động giả là một cơ hội để tinh chỉnh hoặc xóa bỏ.
Lỗi thường gặp & mẹo
Lỗi 1 — Cảnh báo quá nhiều. Như ví dụ sàn TMĐT, đây là lỗi phổ biến nhất. Mẹo: Áp dụng nguyên tắc "mỗi page phải actionable và khẩn cấp". Nếu bạn không làm gì được ngay, hoặc nó chờ được đến sáng, hạ nó xuống thành ticket, đừng để nó gọi dậy.
Lỗi 2 — Không có runbook. Người trực loay hoay tự mò trong khi hệ thống đang cháy. Mẹo: Quy định "không runbook, không alert cấp page". Một alert không đáng để viết runbook thì cũng không đáng để đánh thức người.
Lỗi 3 — Để một người gánh tất cả. Mẹo: Luân phiên ngay cả khi đội nhỏ, và luôn có secondary. Sức khỏe của người trực quan trọng ngang sức khỏe của hệ thống.
Lỗi 4 — Không đền bù cho on-call. Trực đêm là công việc thật, gây căng thẳng thật. Mẹo: Có chính sách rõ ràng — phụ cấp trực, hoặc nghỉ bù sau ca trực nặng. Điều này báo hiệu công ty tôn trọng thời gian của kỹ sư.
Lỗi 5 — Trực là để "chữa cháy" mãi mãi. Mẹo: Coi mỗi lần bị gọi dậy là một khoản nợ kỹ thuật cần trả. Dành thời gian mỗi sprint để giảm nguyên nhân gốc, để số lần bị gọi giảm dần theo thời gian — chứ không phải chấp nhận nó như định mệnh.
Mẹo vàng: Đo lường "trải nghiệm on-call" như một sản phẩm. Số page/tuần, số page ngoài giờ, tỷ lệ báo động giả — đây là những chỉ số về sức khỏe đội bạn, không kém gì uptime.
Bài tập thực hành
- Kiểm toán cảnh báo: Liệt kê tất cả cảnh báo hiện tại (hoặc giả định) trong hệ thống của bạn. Với mỗi cái, trả lời: nó có actionable không? Có khẩn cấp không? Đánh dấu những cảnh báo không đạt cả hai — đây là ứng viên để xóa hoặc hạ cấp.
- Định nghĩa severity: Viết bảng phân tầng SEV1–SEV4 cho một sản phẩm cụ thể (ví dụ một ứng dụng giao đồ ăn). Với mỗi cấp, ghi rõ: ví dụ tình huống, ai được gọi, và trong bao lâu phải phản hồi.
- Thiết kế lịch trực: Với một đội giả định 5 người, hãy vẽ lịch on-call round-robin cho một tháng, kèm primary và secondary. Xác định đường leo thang khi primary không phản hồi trong 10 phút.
- Viết một runbook: Chọn một cảnh báo (ví dụ "tỷ lệ lỗi API thanh toán > 5%") và viết runbook hoàn chỉnh: triệu chứng, nơi kiểm tra, ba bước giảm nhẹ đầu tiên, và điều kiện leo thang.
Tóm tắt
On-call là nền tảng vận hành của mọi hệ thống production nghiêm túc: luôn cần con người sẵn sàng ứng cứu 24/7, và triết lý "you build it, you run it" đảm bảo chính người xây hệ thống chịu trách nhiệm về độ tin cậy của nó. Điều phân biệt một hệ thống on-call lành mạnh với một cỗ máy vắt kiệt con người nằm ở kỷ luật về cảnh báo — mỗi báo động đánh thức người phải actionable và khẩn cấp — và ở việc chia sẻ trách nhiệm qua luân phiên, primary/secondary, cùng runbook đầy đủ.
Với vai trò Tech Lead, bạn không chỉ là người trực; bạn là kiến trúc sư của trải nghiệm on-call cho cả đội. Ba ví dụ hôm nay — alert fatigue ở sàn TMĐT, người anh hùng kiệt sức ở fintech, và mô hình phi tập trung của Grab — đều chỉ về một sự thật: on-call tốt là on-call bền vững cho con người, không chỉ cho máy móc. Ở Bài 17, chúng ta sẽ bước vào khoảnh khắc sự cố thực sự nổ ra: playbook ứng phó và vai trò Incident Commander.