Xử lý sự cố và on-call

Bài toán

Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:

• Ai được gọi, và làm sao tìm ra người đó trong vài phút khi có hàng nghìn service?
• Ai chỉ huy, ai sửa, ai nói với khách hàng, để người sửa không bị kéo đi trả lời tin nhắn?
• Lịch trực được xếp, cập nhật và đánh giá thế nào khi người vào, ra, chuyển team liên tục?
• Làm sao để quy trình không chỉ nằm trên giấy, và để người trực không kiệt sức?

Trang này nói về quy trình, vai trò, công cụ và tổ chức trực. Nội dung và bài học của từng sự cố nằm ở Sự cố và postmortem; tự động hoá thao tác vận hành nói chung nằm ở Tự động hoá vận hành và auto-remediation.

Diễn tiến theo thời gian

• 2015→2017 · LinkedIn: NOC escalate tay không theo kịp số alert → Iris (escalation plan nhiều bước, theo mức ưu tiên, người nhận tự chọn kênh, role tra động) + Oncall (lịch trực, nguồn sự thật cho role). Tự động hoá làm mất lớp gộp alert ngầm của NOC; theo LinkedIn, cách sửa thật là gom và chỉnh lại alert. LinkedIn 2017
• 2017 · Booking.com: bộ phận gần 2.000 người tự deploy 24/7. Nguyên tắc "escalations are cheap": không chắc thì cứ gọi nhóm phản ứng nhanh, chống quá tải bằng quyền tự rời đi. Vai trò: Incident Leader chỉ điều phối và giao việc, Comms lo liên lạc. Khôi phục cho khách trước, tìm nguyên nhân sau. Booking.com 2017
• 2017 · LinkedIn: Project STAR* sửa lịch trực của app flagship (hơn 600 engineer, khoảng 10.400 commit/quý). Danh sách trực sinh tự động từ commit (từ 5 commit/tháng), xếp trước 60 ngày, nhắc ở 4/2/1 tuần, có lịch shadow cho người mới; nhận xét về người trực gửi tới manager trực tiếp để on-call được tính vào đánh giá; tuần trực là 100% thời gian. "Việc thường ngày cản trở việc trực": 84% → 9% (theo khảo sát của LinkedIn). LinkedIn 2018
• 2017 · Airbnb: không có đội vận hành, mỗi team tự trực; alert viết bằng Ruby DSL trong repo (Interferon), sinh theo inventory host với metadata sở hữu nên một alert chung định tuyến tới chủ của từng role; peer review, kiểm cú pháp ở pre-commit, dry-run hiện delta, đồng bộ với Datadog mỗi giờ (dùng từ cuối 2014). Airbnb 2017
• 2018 · Shopify: vai IMOC theo Incident Command System, trực để điều phối, không trực để sửa; SRM lo liên lạc với merchant. Bot Spy gắn sự cố vào một kênh #war-room, trả lời "đang có sự cố gì", chạy thao tác giảm thiểu ngay từ chat (failover DC, khoá deploy), sinh tài liệu từ ghi chú gắn emoji, và gọi người thay khi IMOC trực quá lâu. Shopify 2018
• 2018 · Stack Overflow: phân cấp alert trong Bosun: site offline (Pingdom) hoặc tỉ lệ lỗi cao thì gọi PagerDuty cho SRE on-call; lỗi khẩn đẩy vào chat; còn lại gửi email kèm truy vấn chi tiết và 10 lần alert gần nhất. Alert được chạy thử trên dữ liệu lịch sử trước khi bật. Stack Overflow 2018
• 2018 · Heroku: Chống mệt mỏi on-call khi fleet roll: chỉ lên lịch thay máy trong giờ làm việc của người đang trực vì edge case chưa tự động hoá sinh thêm page. Heroku 2018
• 2019 · PayPal: các team tự chủ cao, không có cơ quan trung tâm quy định quy trình. Một nhóm tình nguyện liên phòng ban định nghĩa thế nào là sự cố, mức nghiêm trọng, phân loại; tài liệu cố ý giữ ở mức cao kèm sơ đồ một trang; cổng báo cáo chung tự đăng lên kênh Slack công khai để thấy mẫu lặp giữa các sự cố. PayPal 2021
• 2019 · Booking.com: team reliability lo một hệ mà hàng chục team sản phẩm cùng đẩy code, ai cũng kỳ vọng reliability làm hết. Reliability Collaboration Model liệt kê mọi việc vận hành và chia theo ba mức hỗ trợ: mặc định mức 3 (team sản phẩm tự lo, giữ pager), mức 1 thì team reliability nhận hết trừ pager vẫn chia chung với developer. Độ quan trọng do lãnh đạo sản phẩm quyết; Ownership Map (mức hỗ trợ × độ quan trọng) lộ hệ được hỗ trợ thừa hoặc thiếu. Booking.com 2019
• 2019→2023 · Zalando: gom playbook sự cố về một chỗ khi chuẩn bị Cyber Week 2019; đến 2023 có hơn 1.200 playbook cho 850+ app, 100+ team trực. Playbook là thủ tục giảm cấp được Business Owner duyệt trước (điều kiện, tác động kinh doanh, tác động vận hành, thời gian phục hồi), nên người trực làm ngay không chờ quyết định; quản lý như code (CODEOWNERS, ngày hết hạn, bắt buộc với app quan trọng), diễn tập trong game day. Zalando 2023
• 2019 · Monzo: thêm tuyến hai specialist theo mảng (payments, Cassandra) do chính team đó trực (xác nhận trong 1 giờ, £300/tuần) sau tuyến primary + shadow (15 phút, £500/tuần, trả theo tuần chứ không theo sự cố); primary chỉ huy, specialist khắc phục; alert có chủ rõ thì gọi thẳng specialist. Đích dài hạn: đảo vai, tuyến một chỉ là lưới an toàn; vướng ở chỗ hệ thống chưa biết alert ở tầng nào là triệu chứng của team nào. Monzo 2019
• 2019 · SoundCloud: page theo triệu chứng (vi phạm SLO), ticket theo nguyên nhân; tỉ lệ 5xx theo backend đo ở tầng HAProxy biên. Bốn alert multiwindow, multi-burn-rate (page: 1h+5m ×14,4 và 6h+30m ×6; ticket: 1d+2h ×3 và 3d+6h ×1), thêm for ngắn khác với SRE Workbook. Cấu hình Alertmanager sinh tự động từ registry sở hữu qua nhãn system. SoundCloud 2019
• 2019 · Nubank: gộp nhiều team vào một lịch trực chung để mỗi người trực ít ngày hơn; điều kiện: runbook cho mọi alert (thử với người ngoài team), không alert chập chờn, dashboard dễ hiểu. 5 ca/tuần, lớp hai best-effort là cả team sở hữu; bắt đầu bằng hai team gần nhau, dọn alert trước (phần lớn team chỉ có 4–5 alert đáng đánh thức người), có thể trả team gây quá nhiều alert về tự trực. Nubank 2019
• 2019 · GitLab: đội phân tán khắp múi giờ quyết định không bàn giao cho ca châu Âu vì người đang xử lý hiểu rõ nhất; thay vào đó viết kế hoạch "break glass" (MR có đủ thay đổi và hướng dẫn) để ca sau dựng lại được nếu sập thật trong đêm. GitLab 2019
• 2020 · Netflix: team sở hữu tự trực service của mình; team trung tâm CORE không sở hữu service nào, chỉ trực alert trên KPI kinh doanh (lượt bắt đầu stream/giây), gọi team liên quan và làm Incident Manager (điều phối, quyết định như sơ tán region, ghi chép, liên lạc). Sau sự cố lo phân tích theo góc nhìn sociotechnical và chia sẻ toàn công ty. Netflix 2020
• 2020→2023 · Goldman Sachs: alert thời gian thực có leo thang thay email batch là điều kiện cho trực theo vòng mặt trời (mỗi khu vực 6 người xoay tuần); metric mới đến từ action item sau sự cố và SLO mới. Goldman Sachs 2023
• 2020 · GitLab: status page cập nhật từ chính issue sự cố: background job chuyển mô tả và bình luận đánh dấu công khai thành JSON tĩnh, đẩy lên S3, vì GitLab.com chạy trên Google Cloud còn trang trạng thái phải sống khi GitLab sập; thay việc người trực chép tay mỗi 15 phút. GitLab 2020
• 2021 · Monzo: mô hình primary/shadow trực tuyến đầu cho mọi thứ (hợp với khoảng 50 engineer) kẹt khi lên 150+: ngưỡng vào lịch primary tăng hằng tuần, phụ thuộc vài người. "On-call 3.0": alert định tuyến thẳng tới team sở hữu, nền tảng cung cấp monitoring và định tuyến, engineering manager chịu trách nhiệm lịch trực và nghỉ bù; thêm nhóm technical incident manager gọi được 24/7. Monzo 2022
• 2021 · Dropbox: ngân sách 21 phút down/tháng chia cho phát hiện, chẩn đoán, phục hồi. Tự động khai báo SEV; dịch vụ kiểm tra cấu hình on-call của mọi team qua API PagerDuty theo chuẩn bắt buộc; vai IMOC/TLOC/BMOC; IMOC bị hiểu sai dần (biết quy trình nhưng không chắn nhiễu) nên lập Backup Response Team. Dropbox 2021
• 2021→2022 · Mercari: mô hình SRE nhúng: thành viên Microservices SRE vào từng team sản phẩm vài tháng, trực on-call ở đó, đưa SLO và error budget thành điều kiện release, thêm SLI gần người dùng (độ trễ từ lúc cập nhật sản phẩm tới lúc search thấy). Mercari 2022
• 2021 · Loveholidays: định tuyến alert theo nhãn team gắn trên resource Kubernetes: nhân query gốc với kube_*_labels (giá trị 1) bằng group_right để kéo nhãn vào alert, một rule chung tự tới đúng team; bỏ cách chép rule theo team và định tuyến theo namespace. Loveholidays 2021
• 2021 · SoundCloud: on-call tự nguyện, trả theo giờ; rotation gồm nhiều team, cấp 1 cho mọi hệ của rotation, cấp 2 kiểu cố gắng cho hệ của team mình; theo SoundCloud khoảng 3 ngày trực mỗi tháng là tối ưu nên rotation 8–12 người; bàn giao sau khoảng 4 giờ; rotation không sắp lại theo sơ đồ tổ chức vì kiến thức tích luỹ. SoundCloud 2021
• 2021→2023 · Slack: rút một AZ được thiết kế làm biện pháp chung cho người trực: an toàn, tăng dần, đảo ngược được, nên dùng thử được khi chưa rõ nguyên nhân (rút, không đỡ thì trả lại). Slack 2023
• 2022 · Airbnb: hơn 1.000 microservice, hàng trăm team. Bot Slack là phễu duy nhất: mở ticket Jira, tạo kênh, page qua danh mục service của PagerDuty, gom timeline từ tin nhắn gắn emoji, nhắc hạn ticket khắc phục. Log4j (12/2021): bot page hơn 300 team trong vài phút. Airbnb 2022
• 2022 · Nubank: thực hành alert cho model real-time (model có thể sai mà không lỗi): alert ghi giá trị kỳ vọng và khung thời gian, kèm link hành động (DLQ, playbook, cấu hình scale, feature flag), chỉnh ngưỡng/snooze/ack được ngay từ alert, viết theo người nhận; heartbeat cho sự vắng mặt của sự kiện, ngưỡng cỡ mẫu tối thiểu cho mùa vụ, tính alert trên mẫu ngẫu nhiên để giảm chi phí. Nubank 2022
• 2022 · Stack Overflow: thay việc đội sự cố chặn IP bằng tay theo từng đợt bằng script đọc log traffic và tự đưa IP vào blocklist của Fastly; mỗi đợt phản ứng nhanh hơn. Stack Overflow 2022
• 2023 · Nubank (NuSeguros): SLO đặt lúc thiết kế, vi phạm SLO tự mở ticket cùng hàng đợi với support; trực theo tuần, ngoài giờ chỉ ticket mức cao; người trực viết/cập nhật playbook; metric nguyên nhân gốc tạo mới so với đã giải. Nubank 2023
• 2023→2025 · Zalando: sau sự cố, phần tổng hợp xuyên postmortem (vốn cần người đọc 15–20 phút mỗi bài) được giao cho pipeline LLM; người vẫn kiểm 10–20% mẫu và biên tập báo cáo cuối. Zalando 2025
• 2025 · Meta: DrP: playbook điều tra viết thành code (analyzer), tự chạy khi alert bắn, kết quả gắn vào alert cho người trực; theo Meta hơn 300 team, 50.000 lần phân tích/ngày, MTTR giảm 20–80%. Meta 2025
• 2025 · Mercari: đội Network viết sẵn và thử quy trình bắt gói tin cho developer tự làm, vì quy trình không định sẵn thì vô dụng đúng lúc sự cố gấp. Mercari 2025
• 2026 · Upstash: mất một replica cũng page on-call dù khách không thấy; tách kênh cảnh báo "chậm" (không đánh thức ai) khỏi "chết"; sự cố chỉ đóng khi check bên ngoài xanh từ mọi điểm và latency về nền. Upstash 2026
• 2026 · Grab: sự cố dữ liệu (DPI) có vòng đời riêng: chỉ vi phạm hợp đồng dữ liệu mới thành sự cố (alert nền tảng chỉ là tín hiệu), khử trùng và gom theo nguyên nhân, phân loại lỗi thô (upstream, platform, job, data) để tự giao chủ; DPI hạ nguồn thừa kế chủ của DPI upstream. Hơn 95% DPI do hệ tự mở, MTTR của DPI tự động nhanh gấp 6 lần. Grab 2026
• 2026 · Salesforce, 9/2026: alert cho agent dẫn thẳng tới các phiên bị ảnh hưởng và tới bước, trường liên quan (ngữ cảnh sai, bài kiến thức thiếu, tool lỗi, flow kém); vòng đời phát hiện–báo–chẩn đoán–sửa mới làm hai bước đầu, đang thử agent giải thích "vì sao alert bắn" và đề xuất sửa, tự sửa khi khách duyệt. Salesforce 2026

Các lựa chọn và đánh đổi

Quy tắc rút ra

1. Tách vai chỉ huy khỏi vai sửa. Người chỉ huy giữ bức tranh chung, liên lạc, giao việc; người sửa không phải viết email (Booking 2017, Shopify 2018, Dropbox 2021).
2. Hạ chi phí của việc báo động khi tổ chức lớn lên; chống quá tải bằng quyền rời đi chứ không bằng ngưỡng cao (Booking 2017; tự khai báo SEV ở Dropbox 2021).
3. Định tuyến alert tới team sở hữu khi số service vượt khả năng hiểu của một nhóm trực chung; giữ một nhóm chỉ huy chung cho sự cố lớn (Monzo 2021).
4. Tra người trực là bài toán dữ liệu: danh mục service → team → lịch trực phải có sẵn và đúng, nếu không thì sự cố "một lỗi, hàng trăm chủ" không xử lý nổi (Airbnb, Log4j 2021).
5. Lịch trực phải tự động sinh từ nguồn sự thật (commit, sơ đồ tổ chức), báo sớm và xác nhận; danh sách làm tay luôn cũ (LinkedIn 2017).
6. On-call phải được tính vào đánh giá và được dành thời gian, nếu không nó luôn thua việc sản phẩm (LinkedIn 2017; nghỉ bù, giảm việc trong tuần trực ở Monzo 2021).
7. Đừng để các bước nằm trong trí nhớ người đang chịu áp lực: bot nhắc status page, gom timeline, nhắc hạn action item (Shopify 2018, Airbnb 2022).
8. Định nghĩa "sự cố" và "xong sự cố" trước khi mua công cụ: thế nào là sự cố và mức nghiêm trọng (PayPal 2021); xong là khi khách thấy xong, không phải khi dashboard nội bộ đẹp (Upstash 2026).
9. Quy trình lệch khỏi thực tế dần; phải đo (khảo sát, kiểm cấu hình tự động) và diễn tập để thấy (Dropbox 2021, LinkedIn 2017).
10. Giữ developer trong lịch trực ngay cả khi có team reliability; chia việc vận hành theo mức, nhưng pager vẫn chia chung để người viết code thấy hậu quả (Booking 2019).
11. Ra quyết định đánh đổi trước, thực thi trong sự cố: playbook giảm cấp do chủ sở hữu kinh doanh duyệt sẵn, xếp theo tác động thấp nhất trước (Zalando 2019–2023).
12. Có một tầng alert trên KPI kinh doanh, do một nhóm nhìn toàn hệ trực, để bắt sự cố liên service mà alert từng team bỏ sót (Netflix 2020).
13. Với dữ liệu, sự cố là vi phạm hợp đồng với consumer chứ không phải mỗi alert của nền tảng; khử trùng theo điều kiện đang hỏng và giao chủ theo nguyên nhân upstream. Grab 2026
14. Page theo triệu chứng, ticket theo nguyên nhân: alert gọi người dậy dựa trên tốc độ đốt error budget (cửa sổ dài + ngắn), còn cháy chậm thành ticket (SoundCloud 2019). Phần lớn team chỉ có vài alert đáng đánh thức người (Nubank 2019). SoundCloud 2019 Nubank 2019
15. Định tuyến alert theo metadata sở hữu, không chép rule theo team: sinh cấu hình định tuyến từ registry sở hữu (SoundCloud 2019) hoặc kéo nhãn team từ resource vào alert (Loveholidays 2021); có chủ rõ thì gọi thẳng người trực của team đó (Monzo 2019). SoundCloud 2019 Loveholidays 2021 Monzo 2019
16. Muốn người ngoài team trực được thì tri thức phải nằm trong runbook và alert phải đáng tin: runbook cho mọi alert, thử với người ngoài team, không alert chập chờn; trả team gây quá nhiều alert về tự trực (Nubank 2019). Nubank 2019
17. Alert sinh theo inventory + metadata sở hữu, viết một lần cho mọi role, review như code; khi mỗi team tự trực, quyền sở hữu phải lấy từ dữ liệu hạ tầng chứ không nhập tay. Airbnb 2017
18. Công cụ chẩn đoán sâu phải có quy trình viết sẵn, đã thử, và tự phục vụ được (quyền tạm, Role định sẵn), vì lúc sự cố gấp không ai kịp nghĩ ra lệnh. Mercari 2025
19. Kênh báo trạng thái sự cố không được phụ thuộc vào hệ đang sự cố: khác nhà cung cấp cloud, nội dung tĩnh, sinh tự động từ chỗ người trực đang viết. GitLab 2020 Xem Cloudflare 2025.
20. Kích thước rotation suy từ tần suất trực mong muốn (khoảng 3 ngày/tháng → 8–12 người); quyền được page người khác và giới hạn thời gian một người gánh sự cố (khoảng 4 giờ) nên thành quy tắc nói rõ. SoundCloud 2021
21. Alert tốt trả lời trước ba câu: bình thường là bao nhiêu, trong khung nào, bước tiếp theo là gì (link); và phải chỉnh, snooze, ack được ngay tại alert vì ngưỡng sẽ lỗi thời. Sự vắng mặt của sự kiện cần heartbeat riêng. Nubank 2022

Câu hỏi mở

• Các nguồn đều tự đánh giá quy trình của mình (khảo sát nội bộ, giờ tiết kiệm ước tính); chưa có số liệu kiểu MTTA/MTTR trước và sau thay đổi. Meta 2025 (DrP) là nguồn đầu tiên nêu mức giảm MTTR (20–80%), nhưng cho công cụ chẩn đoán tự động chứ không cho thay đổi quy trình trực, và vẫn là tự đo (Meta 2025).
• Khi nào nên chuyển từ nhóm trực chung sang trực theo team? Monzo đổi ở khoảng 100–150 engineer; chưa có nguồn thứ hai nêu ngưỡng theo số người. Booking 2019 trả lời theo hướng khác: không có ngưỡng chung, mà chọn theo từng hệ, dựa trên độ quan trọng kinh doanh (mức hỗ trợ 1–3). Netflix 2020 kết hợp cả hai: team tự trực service, nhóm trung tâm trực KPI kinh doanh. Nubank 2019 đi chiều ngược: gộp lịch trực của nhiều team nhỏ (2–8 người) thành pool chung để mỗi người trực ít hơn, giữ lớp hai best-effort của team sở hữu (Nubank 2019); Monzo 2019 là bước giữa (tuyến một chung + specialist theo team) trước khi đổi hẳn năm 2022 (Monzo 2019). SoundCloud 2021 đi theo trục khác: rotation gom nhiều team, kích thước định theo tần suất trực (8–12 người), và không sắp lại theo sơ đồ tổ chức (SoundCloud 2021).
• Ba mô hình SRE (trung tâm ở Netflix, nhúng ở Mercari, theo mức ở Booking) đều do chính công ty tự mô tả; chưa có nguồn so sánh kết quả giữa các mô hình. Phần này đã tách thành Mô hình tổ chức SRE.
• Bot ChatOps là phụ thuộc trong lúc sự cố: nếu Slack hoặc chính bot hỏng thì sao? Các nguồn không nói về đường dự phòng.
• Liên hệ: Sự cố và postmortem (nội dung từng sự cố, postmortem), Tự động hoá vận hành và auto-remediation (tự động khai báo, ChatOps), Nền tảng nội bộ cho service (đường ray chung) (nền tảng monitoring và định tuyến alert cho team), Deploy và release an toàn (khoá deploy, rollback trong sự cố).
• Liên hệ: Observability và monitoring (hạ tầng alert, giám sát từ bên ngoài, chẩn đoán tự động khi alert bắn), Mô hình tổ chức SRE (đội reliability đứng ở đâu trong tổ chức, cách nhân rộng thực hành SRE).