Mở đầu — vì sao bài này quan trọng
Có một sự thật mà mọi kỹ sư giỏi đều phải học sớm hay muộn: hệ thống của bạn rồi sẽ sập. Không phải "nếu", mà là "khi nào". Server sẽ hết RAM, database sẽ nghẽn, một lần deploy tưởng chừng vô hại sẽ làm gãy checkout của toàn bộ khách hàng vào đúng 8 giờ tối thứ Sáu. Đó là bản chất của việc vận hành phần mềm ở quy mô lớn.
Điều tách biệt một đội kỹ thuật chuyên nghiệp khỏi một đội hỗn loạn không phải là "họ có gặp sự cố hay không", mà là cách họ giao tiếp trong 60 phút đầu tiên khi sự cố xảy ra. Trong một incident (sự cố production), phần kỹ thuật — đọc log, rollback, restart service — thường chỉ chiếm một nửa công việc. Nửa còn lại, và thường là phần quyết định incident đó biến thành "10 phút gián đoạn nhẹ" hay "thảm họa 4 tiếng lên báo", chính là communication — giao tiếp.
Tại sao communication lại quan trọng đến vậy trong incident? Vì lúc đó:
- Nhiều người cùng lo lắng và cùng muốn giúp, nhưng nếu không điều phối thì mười người sẽ giẫm chân nhau, cùng restart một service, cùng đọc một log, và không ai fix được vấn đề gốc.
- Thông tin bị phân mảnh. Người thì thấy alert từ Datadog, người thì thấy khách hàng phàn nàn trên Zalo, người thì thấy CPU tăng vọt. Nếu không gom lại một chỗ, không ai có bức tranh toàn cảnh.
- Áp lực từ bên ngoài đổ dồn về. Sếp hỏi "sao rồi?", Sales hỏi "bao giờ xong?", CEO nhắn "khách VIP đang gọi". Nếu engineer đang fix mà phải trả lời 5 tin nhắn mỗi phút, họ sẽ không fix được gì cả.
Khái niệm cốt lõi
Incident là gì và mức độ nghiêm trọng (Severity)
Không phải mọi lỗi đều là incident. Một incident là sự cố ảnh hưởng đến người dùng hoặc vận hành, cần phản ứng có phối hợp. Để giao tiếp nhất quán, các đội thường phân loại theo severity (mức độ nghiêm trọng):
- SEV1 / P1 — Nghiêm trọng nhất: hệ thống chính sập hoàn toàn, mất tiền, mất dữ liệu. Ví dụ: khách không thanh toán được, app trắng màn hình. Cần phản ứng ngay lập tức, huy động người.
- SEV2 / P2 — Nghiêm trọng: một tính năng quan trọng hỏng nhưng còn workaround, hoặc chỉ ảnh hưởng một phần người dùng.
- SEV3 / P3 — Nhẹ: lỗi khó chịu nhưng không chặn nghiệp vụ chính, có thể xử lý trong giờ hành chính.
Ba vai trò cần có trong mọi incident
Đây là khái niệm quan trọng nhất của bài. Trong incident, bạn cần tách bạch ba vai trò — dù đội nhỏ thì một người có thể kiêm, nhưng ý thức về ba vai trò này sẽ cứu bạn:
- Incident Commander (IC) — người điều phối. IC không nhất thiết là người giỏi kỹ thuật nhất. Nhiệm vụ của IC là điều phối: quyết định, phân công, giữ nhịp, và bảo vệ đội khỏi nhiễu. IC là người duy nhất "sở hữu" incident.
- Ops / Resolver — người thực sự đưa tay vào fix. Họ đọc log, chạy lệnh, rollback. Họ cần được bảo vệ khỏi bị làm phiền để tập trung.
- Communications Lead (Comms) — người nói chuyện với thế giới bên ngoài: cập nhật status page, trả lời sếp và Sales, viết thông báo cho khách. Comms là "tấm khiên" giữa resolver và những người đang hoảng loạn hỏi han.
"Single source of truth" — một kênh, một sự thật
Trong incident, thứ giết chết bạn nhanh nhất là thông tin phân mảnh khắp nơi: một ít trong DM, một ít trong Slack channel này, một ít trong cuộc gọi. Nguyên tắc cốt lõi: mở một kênh incident duy nhất (ví dụ Slack channel #incident-2026-06-27-checkout) và mọi thứ diễn ra ở đó. Mọi phát hiện, mọi quyết định, mọi hành động đều được ghi vào đó. Kênh này vừa là nơi phối hợp real-time, vừa tự động trở thành timeline cho buổi postmortem sau này.
Tình huống thực tế
Tình huống 1: Sàn TMĐT "ShopFast" và cú deploy chiều thứ Sáu
Bối cảnh: ShopFast là một sàn thương mại điện tử tại TP.HCM, khoảng 40 engineer. 17h30 thứ Sáu, một bạn dev deploy một thay đổi nhỏ ở service thanh toán rồi... về nhà. 17h45, tỷ lệ giao dịch thành công tụt từ 98% xuống 12%.
Diễn giải cách họ xử lý sai: Alert nổ trong #alerts, nhưng vì cuối tuần, không ai acknowledge. Một bạn on-call thấy nhưng nghĩ "chắc noise thôi". 15 phút sau, Sales bắt đầu la trong #general. CEO nhắn DM riêng cho ba engineer khác nhau. Ba người này, mỗi người tự mở terminal, tự đoán nguyên nhân, không ai biết người kia đang làm gì. Một bạn restart database (vô ích), một bạn rollback nhầm service, làm hỏng thêm. Suốt 40 phút, không có ai nói câu "Tôi là người điều phối vụ này".
Bài học: Họ mất 40 phút không phải vì vấn đề khó — root cause chỉ là một config sai, rollback đúng service là xong trong 3 phút. Họ mất 40 phút vì thiếu người điều phối và thiếu một kênh chung. Sau incident này, ShopFast đặt ra quy tắc: bất kỳ ai phát hiện SEV1/SEV2 đều phải (1) tạo channel incident, (2) tự nhận làm IC cho đến khi có người khác nhận, (3) tag on-call. Incident tiếp theo cùng loại, họ giải quyết trong 9 phút.
Tình huống 2: Fintech "VíXanh" và bản cập nhật T+0 mẫu mực
Bối cảnh: VíXanh là ví điện tử, đội SRE trưởng thành. 2h14 sáng, PagerDuty page anh Tuấn (on-call). Điều đáng học là 5 phút đầu tiên của anh:
- T+0 (2h14): Alert page. Anh Tuấn acknowledge trong vòng 2 phút ngay trên điện thoại — chỉ một thao tác để "trạng thái page tắt", báo cho hệ thống biết đã có người nhìn.
- T+3 (2h17): Anh mở laptop, tạo channel
#inc-txn-timeout, và đăng dòng đầu tiên: "Tôi đang điều tra tỷ lệ timeout tăng ở service giao dịch. Tôi làm IC. Impact: ~15% giao dịch bị chậm >5s. Chưa mất tiền. Sẽ update sau 10 phút." - T+10 (2h24): Dù chưa fix xong, anh vẫn đăng đúng hẹn: "Update: nghi ngờ connection pool cạn sau đợt traffic. Đang thử tăng pool size. Chưa xác nhận. Next update: 2h34."
Bài học: Nhịp cập nhật đều đặn và có cam kết thời gian là công cụ giao tiếp mạnh nhất trong incident. Nó biến sự lo lắng thành sự tin tưởng.
Tình huống 3: SaaS "DocFlow" và cái bẫy "hứa hẹn quá sớm"
Bối cảnh: DocFlow là công cụ SaaS B2B. Service export PDF sập. Bạn engineer trực, sau 5 phút nhìn log, tự tin nhắn cho toàn công ty: "Đã fix xong rồi nhé mọi người, do cache thôi." Rồi đóng máy đi ăn trưa.
15 phút sau, lỗi quay lại — thực ra cache chỉ là triệu chứng, root cause là một dependency bên thứ ba đang chập chờn. Nhưng vì đã tuyên bố "fixed", Comms đã gửi email "sự cố đã được khắc phục" cho khách. Giờ họ phải gửi email đính chính, uy tín tổn hại gấp đôi.
Bài học: Đừng bao giờ tuyên bố "đã khắc phục" cho đến khi bạn đã xác nhận (verify) và theo dõi ổn định một khoảng thời gian. Ngôn ngữ khi giao tiếp incident phải phản ánh đúng mức độ chắc chắn: dùng "đang điều tra", "đã xác định nguyên nhân, đang khắc phục", "đã áp dụng cách khắc phục, đang theo dõi", rồi cuối cùng mới "đã giải quyết". Mỗi từ là một lời hứa — đừng hứa điều bạn chưa chắc.
Hướng dẫn từng bước — Playbook 60 phút đầu tiên
Đây là quy trình cụ thể bạn có thể áp dụng ngay. Hãy in ra dán cạnh bàn.
T+0 — Detect & Acknowledge (0–5 phút):
- Page nổ. Acknowledge trong vòng 5 phút. Chỉ một thao tác để hệ thống và đồng đội biết "đã có người nhìn". Đừng ngủ quên qua page.
- Đánh giá nhanh: đây có thực sự là incident không? Nếu có, gán severity sơ bộ.
- Tạo channel incident duy nhất. Đặt tên rõ ràng, có ngày và mô tả ngắn.
- Tuyên bố công khai bạn là IC: "Tôi làm Incident Commander cho vụ này." Nếu bạn không đủ khả năng điều phối, hãy tìm người và bàn giao rõ ràng.
- Đăng thông điệp đầu tiên theo cấu trúc: Cái gì đang hỏng / Ảnh hưởng đến ai / Mức độ / Đang làm gì / Khi nào update tiếp.
- Nếu SEV1: kéo thêm resolver và Comms vào.
- Resolver tập trung điều tra; IC bảo vệ họ khỏi nhiễu.
- Ưu tiên "stop the bleeding" hơn là tìm root cause. Nếu rollback làm hết đau, hãy rollback ngay, để việc hiểu tại sao cho postmortem. Trong lúc dập lửa, khôi phục dịch vụ quan trọng hơn giải thích.
- Đăng update đều đặn theo nhịp cam kết (SEV1: mỗi 15–30 phút; ngay cả khi "chưa có gì mới").
- Comms cập nhật status page và trả lời bên ngoài, tách khỏi kênh làm việc kỹ thuật.
- Nếu đã khắc phục: verify kỹ, theo dõi ổn định, rồi mới tuyên bố "resolved".
- Nếu chưa: escalate — kéo thêm chuyên gia, thông báo cấp trên, đừng ôm một mình. Escalate không phải thất bại; ôm incident một mình quá lâu mới là thất bại.
- Khi đóng incident: một tin nhắn tổng kết ngắn, và hẹn lịch postmortem (sẽ học ở bài sau).
Lỗi thường gặp & mẹo
Lỗi 1 — Không ai nhận vai IC. "Ai cũng lo nên không ai điều phối." Mẹo: bất kỳ ai phát hiện đều tự nhận IC cho đến khi bàn giao. Câu "Tôi làm IC" phải được nói ra thành lời.
Lỗi 2 — Vừa fix vừa báo cáo. Resolver bị kéo vào 20 cuộc trò chuyện. Mẹo: IC/Comms làm tấm khiên. Resolver chỉ nói trong channel, không trả lời DM riêng.
Lỗi 3 — Giao tiếp trong DM và các kênh rời rạc. Kiến thức bay hơi, không ai có bức tranh toàn cảnh. Mẹo: "Nếu nó không ở trong channel incident, nó không tồn tại." Kéo mọi thảo luận về một chỗ.
Lỗi 4 — Im lặng vì "chưa fix xong nên chưa có gì để nói". Sự im lặng nuôi dưỡng hoảng loạn. Mẹo: update "chưa có gì mới" đúng hẹn vẫn cực kỳ giá trị. Luôn cam kết mốc update tiếp theo.
Lỗi 5 — Tuyên bố "đã fix" quá sớm. Mẹo: dùng thang ngôn ngữ chắc chắn (điều tra → xác định → khắc phục → theo dõi → giải quyết). Chỉ nói "resolved" sau khi verify và theo dõi ổn định.
Lỗi 6 — Đổ lỗi ngay trong lúc dập lửa. "Ai deploy cái này?!" làm mọi người phòng thủ, chậm fix. Mẹo: trong incident, chỉ tập trung khôi phục. Chuyện "tại sao" và "làm sao để không tái diễn" để dành cho postmortem blameless.
Mẹo vàng — Chuẩn bị trước khi cháy: Viết sẵn template thông điệp, có sẵn danh sách on-call, tạo sẵn command tạo channel. Lúc 3h sáng đầu óc bạn không tỉnh táo để nghĩ ra cấu trúc — hãy để playbook nghĩ hộ.
Bài tập thực hành
- Viết template thông điệp T+5 của riêng bạn. Soạn một mẫu tin nhắn đầu tiên có đủ 5 phần: Cái gì hỏng / Ảnh hưởng ai / Severity / Đang làm gì / Update tiếp khi nào. Lưu vào nơi bạn tìm được lúc nửa đêm.
- Đóng vai (role-play) một SEV1. Cùng 2 đồng nghiệp mô phỏng: "Checkout sập lúc 20h". Phân vai IC / Resolver / Comms. Chạy đủ 60 phút giả lập, mỗi người viết đúng những gì mình sẽ đăng vào channel. Sau đó đổi vai.
- Phân tích một incident thật. Tìm một public postmortem (Cloudflare, GitHub, hoặc status page của một dịch vụ bạn dùng) và đánh dấu: họ acknowledge lúc nào? Ai là IC? Update cách nhau bao lâu? Họ tuyên bố resolved lúc nào so với lúc thật sự ổn?
- Tự kiểm tra đội mình. Đội bạn hiện có quy trình khai báo incident không? Có kênh chuẩn không? Nếu chưa, viết một trang playbook 60 phút cho đội — đó có thể là đóng góp giá trị nhất bạn làm trong quý này.
Tóm tắt
Trong 60 phút đầu tiên của một incident, communication quan trọng ngang với — đôi khi hơn — kỹ thuật thuần túy. Hãy nhớ:
- Acknowledge nhanh (< 5 phút). Cho mọi người biết đã có người nhìn.
- Tách ba vai trò: Incident Commander (điều phối), Resolver (fix), Comms (nói với bên ngoài). Người fix không phải người báo cáo.
- Một kênh, một sự thật. Mọi thứ diễn ra trong channel incident duy nhất.
- Update đều đặn, có cam kết thời gian — kể cả khi "chưa có gì mới".
- Stop the bleeding trước, hiểu root cause sau. Rollback để hết đau, để lại phần "tại sao" cho postmortem.
- Ngôn ngữ phản ánh đúng độ chắc chắn. Đừng nói "đã fix" cho đến khi đã verify và theo dõi.
- Escalate sớm, không ôm một mình. Không đổ lỗi trong lúc dập lửa.