Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng 2 giờ sáng thứ Bảy. Hệ thống thanh toán của một sàn thương mại điện tử lớn tại TP.HCM đột nhiên ngừng nhận đơn. Mỗi phút trôi qua là hàng chục triệu đồng doanh thu bốc hơi, và hàng nghìn khách hàng đang bực bội. Câu hỏi sống còn lúc này không phải là "hệ thống hỏng ở đâu" — mà là "ai sẽ nhấc máy và bắt tay vào xử lý ngay bây giờ?".
Đó chính là lý do tồn tại của On-Call — chế độ trực sẵn sàng ứng cứu sự cố. Ở các bài trước, bạn đã học về vòng đời của một incident và các vai trò trong đó. Nhưng vòng đời ấy chỉ khởi động được khi có một con người thực sự cầm điện thoại, phản hồi, và bắt đầu chữa cháy. On-Call chính là "lớp con người" đảm bảo rằng hệ thống của bạn không bao giờ rơi vào cảnh "báo động hú inh ỏi mà không ai nghe".
Điều khiến On-Call trở thành một chủ đề đáng học riêng một bài — chứ không chỉ là "phân công ai trực đêm" — là vì nó nằm ở giao điểm giữa kỹ thuật, quy trình và con người. Làm On-Call sai cách sẽ khiến kỹ sư giỏi nhất của bạn kiệt sức (burnout), nghỉ việc, và để lại một đội ngũ sợ hãi mỗi khi đến lượt trực. Làm đúng, nó trở thành một văn hóa lành mạnh, nơi trách nhiệm được chia sẻ công bằng và hệ thống ngày càng ổn định hơn theo thời gian. Bài học này sẽ giúp bạn hiểu On-Call không chỉ như một lịch trực, mà như một hệ thống được thiết kế có chủ đích.
Khái niệm cốt lõi
On-Call là gì và mục đích thật sự
On-Call là trạng thái mà một (hoặc vài) kỹ sư cam kết sẵn sàng phản hồi sự cố production trong một khoảng thời gian nhất định. Người đang On-Call phải mang theo điện thoại, giữ kết nối, và có khả năng bắt đầu xử lý sự cố trong vòng vài phút kể từ khi nhận cảnh báo.
Mục đích cốt lõi rất đơn giản: luôn có người chịu trách nhiệm response khi production có vấn đề. Nhưng "luôn có người" không nhất thiết là 24/7. Điều này phụ thuộc vào SLA (Service Level Agreement — cam kết mức dịch vụ) mà bạn đưa ra với khách hàng:
- Một ngân hàng số hay ví điện tử như MoMo cần response 24/7/365, vì tiền của người dùng không ngủ.
- Một công cụ nội bộ dùng trong giờ hành chính có thể chỉ cần On-Call theo giờ business (ví dụ 8h–20h các ngày làm việc).
Rotation — vì sao phải luân phiên
Không ai có thể On-Call mãi mãi. Sức khỏe tinh thần, giấc ngủ và cuộc sống cá nhân là có giới hạn. Vì vậy trách nhiệm On-Call được luân phiên (rotation) giữa các thành viên trong đội. Một rotation tốt cần đảm bảo ba yếu tố:
- Công bằng: mỗi người gánh một phần tương đương, không ai bị dồn ca đêm hay cuối tuần liên tục.
- Đủ độ phủ: mọi khoảng thời gian đều có người trực, không có "lỗ hổng" nào.
- Bền vững: khoảng nghỉ giữa các ca đủ dài để người ta hồi phục.
Các mô hình rotation phổ biến
Follow-the-sun (theo mặt trời). Đây là mô hình dành cho các tổ chức có đội ngũ trải khắp nhiều múi giờ. Ý tưởng đúng như tên gọi: khi mặt trời di chuyển, ca trực cũng di chuyển theo. Ví dụ, một công ty có văn phòng ở Singapore, Berlin và San Francisco. Đội Singapore trực ban ngày giờ châu Á, khi họ tan làm thì đội Berlin đã bắt đầu ngày mới và nhận bàn giao, rồi đến lượt San Francisco. Kết quả: không ai phải trực đêm — mọi ca On-Call đều rơi vào giờ làm việc bình thường của người trực. Đây là mô hình lý tưởng nhất cho sức khỏe con người, nhưng đòi hỏi tổ chức phải đủ lớn và phân bố địa lý phù hợp.
Rotation theo tuần (weekly rotation). Phổ biến nhất ở các công ty vừa và nhỏ, hoặc đội chỉ hoạt động trong một múi giờ. Một người ôm trọn cả tuần, kể cả đêm và cuối tuần. Ưu điểm là bối cảnh liên tục — người trực nắm được diễn biến suốt tuần. Nhược điểm là nếu tuần đó "cháy nhà", họ sẽ rất mệt.
Primary / Secondary (chính/phụ). Đây không hẳn là một mô hình rotation riêng mà là một lớp bổ sung: luôn có hai người trực song song. Người Primary nhận cảnh báo trước. Nếu sau vài phút họ không xác nhận (acknowledge), hệ thống sẽ escalate — chuyển cảnh báo lên người Secondary. Điều này tránh thảm họa "kỹ sư ngủ quên, không ai biết hệ thống đang chết". Secondary cũng là chỗ dựa khi sự cố quá lớn, cần thêm người.
Escalation policy — mạng lưới an toàn
Escalation policy là quy tắc định nghĩa: nếu người đầu tiên không phản hồi trong X phút, cảnh báo sẽ chuyển cho ai tiếp theo, và tiếp theo nữa. Một chuỗi escalation điển hình: Primary (5 phút) → Secondary (5 phút) → Team Lead → Engineering Manager. Đây là tấm lưới an toàn đảm bảo không có cảnh báo nào bị "rơi vào hư không".
Các công cụ hỗ trợ
Bạn không tự tay quản lý lịch On-Call bằng Excel và gọi điện thủ công. Có những công cụ chuyên dụng: PagerDuty, Opsgenie, Grafana OnCall, hoặc VictorOps. Chúng quản lý lịch rotation, tự động gọi điện/nhắn tin/gọi push đến đúng người đang trực, xử lý escalation tự động, và ghi lại lịch sử để phân tích. Với đội nhỏ và ngân sách hạn chế tại Việt Nam, nhiều nhóm bắt đầu bằng Grafana OnCall (miễn phí, mã nguồn mở) tích hợp với Telegram — một kênh rất quen thuộc với kỹ sư Việt.
Tình huống thực tế
Tình huống 1: Startup fintech Việt và bài học "đội quá nhỏ"
Một startup fintech tại Hà Nội với đội backend chỉ 3 người quyết định làm On-Call 24/7 vì họ xử lý giao dịch tiền. Họ chia rotation theo tuần: cứ 3 tuần một người lại ôm trọn cả tuần trực đêm. Ban đầu mọi thứ có vẻ ổn.
Sau ba tháng, hậu quả lộ rõ. Anh trưởng nhóm — người giỏi nhất — bị đánh thức trung bình 4 lần mỗi đêm trong tuần trực của mình, phần lớn là các cảnh báo nhiễu (một dịch vụ phụ thi thoảng chậm, không thực sự nghiêm trọng). Anh mất ngủ triền miên, hiệu suất ban ngày giảm sút, và cuối cùng nộp đơn nghỉ việc. Khi anh rời đi, đội chỉ còn 2 người, đồng nghĩa cứ 2 tuần lại đến lượt trực — một vòng xoáy tử thần.
Bài học: On-Call 24/7 cần tối thiểu 4–6 người để bền vững. Nếu đội quá nhỏ mà vẫn phải trực đêm, hãy làm hai việc trước: (1) mạnh tay dọn dẹp cảnh báo nhiễu để không bị đánh thức vô cớ, và (2) cân nhắc nới lỏng SLA ban đêm cho các dịch vụ không thực sự sống-còn. Đừng lấy sức khỏe con người ra để bù đắp cho một hệ thống cảnh báo cẩu thả.
Tình huống 2: Grab và mô hình Follow-the-sun
Grab, với các trung tâm kỹ thuật ở Singapore, Việt Nam (TP.HCM) và Ấn Độ (Bangalore), là ví dụ điển hình về Follow-the-sun ở quy mô Đông Nam Á. Thay vì bắt kỹ sư ở bất kỳ đâu phải thức trắng đêm để trực, họ tận dụng chênh lệch múi giờ: một sự cố xảy ra lúc 3 giờ sáng giờ Singapore sẽ được đội Bangalore (khi đó đang là buổi tối, vẫn trong khung giờ hợp lý hơn) hoặc đội trực ban ngày ở múi giờ phù hợp tiếp nhận.
Điểm khó của mô hình này không nằm ở lịch, mà ở bàn giao (handoff). Khi ca chuyển từ đội này sang đội khác, nếu đang có một sự cố dở dang mà không bàn giao rõ ràng, người mới nhận ca sẽ mất phương hướng. Grab giải quyết bằng cách chuẩn hóa handoff: mỗi lần chuyển ca đều có một bản tóm tắt ngắn về các vấn đề đang mở, những gì đã thử, và điều gì cần theo dõi.
Bài học: Follow-the-sun bảo vệ giấc ngủ nhưng đánh đổi bằng độ phức tạp trong giao tiếp. Chất lượng của handoff quyết định thành bại của mô hình này. Không có handoff tốt, bạn chỉ đơn giản chuyển vấn đề cho người không hiểu bối cảnh.
Tình huống 3: Đội SaaS nhỏ và bù đắp công bằng
Một công ty SaaS B2B tại Đà Nẵng với 5 kỹ sư áp dụng rotation theo tuần, có Primary và Secondary. Ban đầu họ coi On-Call là "một phần công việc, không cần bù gì thêm". Dần dần, kỹ sư bắt đầu ngầm né tránh — người thì xin đổi ca vào tuần có sự kiện gia đình, người thì "quên" xác nhận cảnh báo. Tinh thần đội đi xuống.
Ban lãnh đạo nhận ra vấn đề và thay đổi chính sách: mỗi tuần On-Call được trả thêm một khoản phụ cấp cố định, và nếu bị gọi vào ban đêm, kỹ sư được nghỉ bù (time-off-in-lieu) vào sáng hôm sau. Ngoài ra, họ đưa "sức khỏe On-Call" thành một chỉ số theo dõi công khai: số lần bị gọi đêm mỗi tuần. Thái độ của đội thay đổi hẳn — On-Call trở thành trách nhiệm được công nhận và tưởng thưởng, thay vì gánh nặng vô hình.
Bài học: On-Call là công việc thật, ngoài giờ, có áp lực. Ghi nhận nó — bằng phụ cấp, nghỉ bù, hoặc ít nhất là sự công nhận rõ ràng — là điều kiện để văn hóa On-Call bền vững. "Miễn phí" nghĩa là bạn đang âm thầm rút cạn thiện chí của đội.
Hướng dẫn từng bước
Nếu bạn được giao thiết lập On-Call cho đội mình, đây là lộ trình thực tế:
- Xác định phạm vi và SLA. Trả lời câu hỏi: dịch vụ nào cần On-Call, và cần response nhanh đến mức nào? 24/7 hay chỉ giờ business? Đừng mặc định mọi thứ đều 24/7 — điều đó cực kỳ tốn kém cả tiền lẫn con người.
- Đếm quân số và chọn mô hình rotation. Nếu đội dưới 4 người mà cần 24/7, hãy dừng lại và cân nhắc: thuê thêm người, thu hẹp SLA, hoặc dùng chung rotation với đội khác. Có đủ người rồi, chọn weekly rotation cho đội một múi giờ, hoặc Follow-the-sun nếu bạn đủ phân bố địa lý.
- Thiết lập Primary/Secondary và escalation policy. Định nghĩa rõ: ai là Primary, ai là Secondary, và chuỗi escalation khi không ai phản hồi. Đặt thời gian escalation hợp lý (thường 5 phút cho mỗi cấp).
- Chọn và cấu hình công cụ. Cài đặt PagerDuty, Opsgenie hoặc Grafana OnCall. Nhập lịch rotation, kết nối với hệ thống cảnh báo (Prometheus, Datadog...) và kênh thông báo (điện thoại, Slack, Telegram).
- Chuẩn bị "hành trang" cho người On-Call. Đảm bảo mỗi người trực có quyền truy cập cần thiết, biết runbook ở đâu, và có kênh để nhờ trợ giúp. (Runbook — sổ tay xử lý sự cố — sẽ được học kỹ ở bài sau; ở đây chỉ cần biết người On-Call phải có sẵn nó.)
- Thiết lập nghi thức handoff. Định nghĩa cách bàn giao ca: một tin nhắn tóm tắt các vấn đề đang mở mỗi khi chuyển ca. Với Follow-the-sun, đây là bước sống còn.
- Đo lường và cải thiện. Theo dõi các chỉ số: số lần bị gọi mỗi ca, số lần bị gọi ban đêm, tỷ lệ cảnh báo nhiễu. Dùng số liệu này để liên tục giảm gánh nặng — mục tiêu là mỗi ca On-Call ngày càng yên tĩnh hơn.
Lỗi thường gặp & mẹo
Lỗi: Đội quá nhỏ vẫn cố làm 24/7. Đây là lỗi phổ biến nhất và tàn khốc nhất, như tình huống fintech ở trên. Mẹo: dưới 4–6 người thì đừng làm 24/7 một mình; hãy gộp rotation, thuê thêm, hoặc nới SLA đêm.
Lỗi: Cảnh báo nhiễu (alert fatigue). Khi người On-Call bị gọi vì những chuyện không cần hành động, họ dần mất niềm tin vào cảnh báo và bắt đầu phớt lờ — kể cả cảnh báo thật. Mẹo: mọi cảnh báo đánh thức người đêm khuya phải actionable (có việc để làm ngay) và cấp bách. Nếu không, hạ nó xuống mức không gọi đêm. (Chiến lược cảnh báo tín hiệu-vs-nhiễu sẽ được đào sâu ở bài về Alerting Strategy.)
Lỗi: Không có Secondary hoặc escalation. Chỉ dựa vào một người là canh bạc. Người ta ngủ say, hết pin, mất sóng. Mẹo: luôn có Primary/Secondary và một chuỗi escalation lên tới quản lý.
Lỗi: Handoff mập mờ. Ca mới nhận không biết chuyện gì đang xảy ra. Mẹo: chuẩn hóa một mẫu bàn giao ngắn gọn, bắt buộc mỗi lần chuyển ca.
Lỗi: Coi On-Call là miễn phí. Rút cạn thiện chí của đội. Mẹo: phụ cấp, nghỉ bù, và ghi nhận công khai.
Mẹo vàng: "Bạn dọn cái mình làm bẩn". Người On-Call tuần này nên là người ưu tiên khắc phục gốc rễ những gì đã đánh thức họ. Điều này tạo động lực tự nhiên để cải thiện hệ thống, biến mỗi ca trực thành cơ hội làm hệ thống ổn định hơn cho ca sau.
Bài tập thực hành
- Thiết kế rotation cho đội của bạn. Giả sử đội bạn có 5 kỹ sư và cần On-Call 24/7. Hãy vẽ ra lịch rotation cho 5 tuần: ai Primary, ai Secondary mỗi tuần. Tính xem mỗi người On-Call bao lâu một lần, và đánh giá nhịp độ đó có bền vững không.
- Viết escalation policy. Với đội trên, hãy viết ra chuỗi escalation cụ thể: nếu Primary không xác nhận trong 5 phút thì sao, tiếp theo là ai, và điểm dừng cuối cùng là ai. Ghi rõ thời gian chờ ở mỗi cấp.
- Tình huống ra quyết định. Đội bạn chỉ có 3 người nhưng sếp yêu cầu On-Call 24/7 cho một dịch vụ nội bộ mà thực tế ban đêm gần như không ai dùng. Hãy viết một đoạn ngắn (5–7 câu) trình bày với sếp lý do nên nới lỏng SLA ban đêm, kèm đề xuất cụ thể.
- Soạn mẫu handoff. Thiết kế một mẫu bàn giao ca gồm 4–5 mục mà người On-Call phải điền mỗi khi kết thúc ca. Nghĩ xem người nhận ca cần biết những gì để không bị mất phương hướng.
Tóm tắt
On-Call là "lớp con người" đảm bảo luôn có ai đó response khi production gặp sự cố — 24/7 hoặc theo giờ business, tùy SLA. Trách nhiệm này được luân phiên (rotation) để bảo vệ sức khỏe và sự công bằng, với các mô hình phổ biến gồm Follow-the-sun (di chuyển ca theo múi giờ để không ai trực đêm), rotation theo tuần, và lớp Primary/Secondary kèm escalation policy làm mạng lưới an toàn.
Ba bài học lớn từ thực tế: đội quá nhỏ không nên gồng gánh 24/7 (câu chuyện fintech Hà Nội); Follow-the-sun bảo vệ giấc ngủ nhưng sống chết nhờ handoff tốt (Grab); và On-Call là công việc thật cần được ghi nhận, không phải gánh nặng miễn phí (SaaS Đà Nẵng). Kẻ thù lớn nhất của một văn hóa On-Call lành mạnh là cảnh báo nhiễu — hãy đảm bảo mọi thứ đánh thức con người lúc nửa đêm đều đáng để họ tỉnh dậy. Làm được vậy, On-Call không còn là nỗi sợ, mà trở thành động lực để hệ thống ngày một ổn định hơn.