Mở đầu — vì sao bài này quan trọng
Ở Bài 16, bạn đã hiểu nền tảng của on-call và incident management: severity levels, alerting, escalation. Nhưng có một khoảng cách rất lớn giữa "biết một sự cố đang xảy ra" và "xử lý sự cố đó một cách gọn gàng". Khoảng cách đó chính là nội dung của Bài 17.
Hãy tưởng tượng cảnh này: 2 giờ sáng, hệ thống thanh toán của một sàn thương mại điện tử sập. Ba kỹ sư nhảy vào cùng lúc. Người A khởi động lại service, người B rollback deploy, người C sửa config database — cả ba làm đồng thời mà không ai biết người kia đang làm gì. Kết quả? Hệ thống rối loạn hơn, thời gian downtime kéo dài, và không ai dám chắc thao tác nào đã thực sự khắc phục vấn đề. Đây không phải vấn đề về năng lực kỹ thuật. Đây là vấn đề về cấu trúc ứng phó — thiếu playbook và thiếu phân vai rõ ràng.
Một tổ chức trưởng thành không xử lý sự cố bằng bản năng và sự anh hùng cá nhân. Họ xử lý bằng quy trình đã được luyện tập trước. Với vai trò Tech Lead, bạn không chỉ là người debug giỏi nhất trong phòng — bạn còn là người thiết lập được cấu trúc để nhiều người phối hợp hiệu quả dưới áp lực. Bài này dạy bạn hai thứ cụ thể: các vai trò trong một incident (ai làm gì) và playbook ứng phó (quy trình từng bước). Đây là bộ kỹ năng phân biệt giữa một team panic mỗi lần sập và một team xử lý sự cố như một cỗ máy được bôi trơn tốt.
Khái niệm cốt lõi
Incident Response là gì và không phải là gì
Incident Response (ứng phó sự cố) là tập hợp các hoạt động có tổ chức nhằm phát hiện, phản ứng và giải quyết một sự cố production đang ảnh hưởng đến người dùng. Điểm mấu chốt nằm ở chữ "có tổ chức". Response không phải là hành động vá lỗi ngẫu hứng, mà là một quy trình có vai trò, có kênh giao tiếp, có nhịp cập nhật, và có tiêu chí kết thúc rõ ràng.
Cần phân biệt hai giai đoạn: mitigation (giảm thiểu — làm cho người dùng hết đau) và resolution (khắc phục gốc rễ). Trong lúc incident, ưu tiên số một luôn là mitigation, không phải tìm root cause. Nếu rollback làm hệ thống chạy lại, hãy rollback trước, điều tra nguyên nhân sau. Rất nhiều incident kéo dài vì kỹ sư mải đi tìm "tại sao" trong khi đáng lẽ nên "dừng chảy máu" trước đã.
Các vai trò trong một incident lớn
Với sự cố nhỏ (SEV3), một người có thể đảm nhiệm tất cả. Nhưng khi sự cố lớn (SEV1/SEV2), bạn cần tách vai. Đây là các vai trò chuẩn theo mô hình của Google SRE và PagerDuty:
Incident Commander (IC) — Chỉ huy sự cố. Đây là người ra quyết định cuối cùng và điều phối toàn bộ quá trình. Điều quan trọng nhất — và cũng phản trực giác nhất — là IC không tự tay fix. Vai trò của IC là giữ bức tranh tổng thể: ai đang làm gì, quyết định nên rollback hay chờ, khi nào cần escalate, khi nào tuyên bố incident kết thúc. IC là người "chỉ tay", không phải người "cầm bàn phím". Lý do: khi bạn cắm đầu vào debug, bạn mất khả năng quan sát toàn cục. Một IC vừa gõ code vừa chỉ huy sẽ làm hỏng cả hai việc.
Tech Lead / Subject Matter Expert (SME) — Người xử lý kỹ thuật. Đây là người thực sự debug, deploy fix, rollback, chạy query. Trong nhiều team, Tech Lead của service bị ảnh hưởng sẽ đảm nhận vai này. SME đề xuất giải pháp cho IC, và IC là người phê duyệt hành động có rủi ро cao (ví dụ: "có nên xóa cache toàn hệ thống không?").
Communications Lead (Comms) — Người truyền thông. Trong sự cố lớn, có rất nhiều người muốn biết thông tin: sếp, đội chăm sóc khách hàng, bộ phận PR, đôi khi cả khách hàng lớn. Nếu để IC hoặc SME trả lời từng câu hỏi này, họ sẽ không còn thời gian xử lý sự cố. Comms Lead đứng ra làm "tường lửa": cập nhật status page, gửi thông báo nội bộ định kỳ, trả lời stakeholder — để IC và SME được yên tĩnh làm việc.
Scribe — Người ghi chép. Ghi lại timeline: mấy giờ phát hiện, ai làm gì, kết quả ra sao. Bản ghi này cực kỳ quý giá cho postmortem sau này (Bài 18). Không có scribe, sau sự cố mọi người chỉ nhớ mơ hồ "hình như là do deploy lúc chiều".
Nguyên tắc vàng: một người có thể kiêm nhiều vai khi sự cố nhỏ, nhưng không bao giờ để một vai bị bỏ trống khi sự cố lớn. Và luôn phải có đúng một IC — không được có hai người cùng ra quyết định.
Playbook và Runbook — khác nhau thế nào
Hai từ này hay bị dùng lẫn. Runbook là hướng dẫn kỹ thuật cụ thể để xử lý một loại sự cố cụ thể (ví dụ: "Runbook khi database connection pool cạn kiệt" — gồm các lệnh cần chạy, dashboard cần xem). Playbook là quy trình tổng quát về cách tổ chức ứng phó cho mọi sự cố (ai làm gì, khi nào escalate, cách giao tiếp). Runbook trả lời "sửa cái này như thế nào"; playbook trả lời "chúng ta phối hợp với nhau như thế nào". Một team tốt cần cả hai.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT Việt Nam và sự cố thanh toán Black Friday
Một sàn thương mại điện tử lớn tại Việt Nam (gọi là "ShopViet") gặp sự cố đúng đêm Black Friday, 22h30, lúc lưu lượng đạt đỉnh. Cổng thanh toán trả lỗi 15% giao dịch. Với mức GMV khoảng 8 tỷ đồng/giờ vào đêm sale, mỗi phút downtime tương đương gần 20 triệu đồng doanh thu thất thoát.
Lần trước gặp sự cố tương tự, team của ShopViet đã panic: 6 kỹ sư nhảy vào Slack, ba luồng thảo luận song song, CTO liên tục hỏi "sao rồi" khiến team lead vừa gõ vừa trả lời tin nhắn. Sự cố kéo dài 90 phút.
Lần này họ đã có playbook. Ngay khi alert nổ, on-call engineer tuyên bố SEV1 và chỉ định ngay: một senior làm IC, chính anh làm Tech Lead/SME xử lý cổng thanh toán, một người ở bộ phận platform làm Comms. IC lập một "war room" trên Google Meet + một channel Slack riêng #inc-payment-bf. IC ra lệnh: "Mọi thảo luận chỉ trong channel này. Ai không có vai trò, xin theo dõi im lặng." Comms đứng ra cập nhật CTO và đội CSKH mỗi 15 phút. SME phát hiện một service phụ trách chống gian lận bị timeout, kéo theo toàn bộ luồng thanh toán. IC quyết định: tạm tắt tính năng chống gian lận (chấp nhận rủi ro trong 1 giờ) để khôi phục thanh toán. Sự cố được mitigate trong 18 phút.
Bài học: Cùng một đội ngũ kỹ sư, nhưng cấu trúc vai trò và một kênh giao tiếp duy nhất đã rút thời gian từ 90 phút xuống 18 phút. IC dám ra quyết định đánh đổi (tắt chống gian lận) — đó là quyết định mà một kỹ sư đang cắm đầu debug khó đưa ra được vì thiếu góc nhìn kinh doanh tổng thể.
Ví dụ 2 — Grab và bài học "single channel of truth"
Các công ty công nghệ lớn ở Đông Nam Á như Grab vận hành hàng nghìn microservice. Trong một sự cố giả định hợp lý: dịch vụ định vị (location service) bị lag khiến việc ghép tài xế – khách hàng chậm trên toàn Jakarta vào giờ cao điểm. Có tới 4 team liên quan: location, matching, mapping, và infrastructure.
Vấn đề ở những sự cố đa-team không phải là thiếu người giỏi, mà là hỗn loạn thông tin. Mỗi team có channel riêng, mỗi team tưởng team kia đang xử lý phần overlap, dẫn đến vừa trùng lặp vừa bỏ sót. Cách xử lý đúng: IC ngay lập tức lập một incident channel trung tâm và yêu cầu mỗi team cử một đại diện (SME) vào đó. IC không cần hiểu chi tiết từng service — công việc của IC là hỏi đúng câu: "Team location, các bạn có thể mitigate độc lập không, hay cần matching phối hợp?" và điều phối thứ tự hành động để tránh xung đột (ví dụ: không cho hai team cùng deploy một lúc).
Bài học: Ở quy mô lớn, giá trị của IC không nằm ở kiến thức kỹ thuật sâu mà ở khả năng điều phối và cắt nhiễu. "Single channel of truth" — một nơi duy nhất chứa thông tin chính thức — là công cụ quan trọng nhất để tránh hỗn loạn khi nhiều team cùng vào cuộc.
Ví dụ 3 — Startup nhỏ và cái bẫy "anh hùng cá nhân"
Một startup fintech giai đoạn đầu (khoảng 12 kỹ sư) có một kỹ sư "ngôi sao" tên Minh, người hiểu toàn bộ hệ thống. Mỗi khi có sự cố, cả team mặc định gọi Minh, và Minh một mình xử lý mọi thứ. Nghe có vẻ hiệu quả — cho đến ngày Minh đi du lịch ở vùng không có sóng, và hệ thống sập. Không ai biết bắt đầu từ đâu, không có runbook, không có playbook. Sự cố kéo dài 4 tiếng.
Sau lần đó, họ áp dụng một quy tắc đơn giản: mỗi sự cố phải có ít nhất hai người, và người hiểu ít hơn sẽ làm IC, người hiểu nhiều hơn (như Minh) làm SME. Nghe ngược đời, nhưng nó buộc kiến thức phải được nói ra thành lời — IC phải hỏi, SME phải giải thích — và mọi thứ được scribe ghi lại thành runbook.
Bài học: "Anh hùng cá nhân" là một điểm yếu (single point of failure) chứ không phải điểm mạnh. Cấu trúc vai trò không chỉ giúp xử lý sự cố hiện tại mà còn ép tổ chức lan tỏa kiến thức, giảm phụ thuộc vào một cá nhân.
Hướng dẫn từng bước
Đây là playbook mẫu bạn có thể áp dụng ngay cho team mình. Sáu bước:
Bước 1 — Declare (Tuyên bố sự cố). Ai đó phải chính thức nói "Đây là một incident, mức SEV-X". Việc tuyên bố rõ ràng chấm dứt trạng thái mơ hồ "có gì đó lạ" và kích hoạt quy trình. Đừng ngại tuyên bố — over-declare còn hơn under-declare.
Bước 2 — Assign roles (Phân vai). Người tuyên bố mặc định làm IC cho đến khi bàn giao. IC lập tức chỉ định SME, và với SEV1/SEV2, chỉ định thêm Comms và Scribe. Nói to và rõ: "Tôi là IC. Anh Nam là Tech Lead. Chị Lan lo comms."
Bước 3 — Establish comms (Thiết lập kênh giao tiếp). Mở một channel/war room duy nhất. Tất cả thảo luận về sự cố diễn ra ở đây. Đây là "single source of truth".
Bước 4 — Mitigate first (Giảm thiểu trước). Ưu tiên làm người dùng hết đau. Rollback, tắt feature flag, chuyển traffic, scale up — bất cứ hành động nhanh và có thể đảo ngược nào. IC phê duyệt các hành động rủi ro cao. Đừng đi tìm root cause trong giai đoạn này.
Bước 5 — Communicate on a cadence (Cập nhật theo nhịp). Comms cập nhật stakeholder theo nhịp cố định (ví dụ mỗi 15–30 phút), kể cả khi chưa có tiến triển — "chúng tôi vẫn đang xử lý" cũng là thông tin có giá trị, nó ngăn stakeholder liên tục hỏi.
Bước 6 — Resolve và bàn giao cho postmortem. Khi hệ thống ổn định và được xác nhận, IC tuyên bố incident kết thúc. Scribe chốt timeline. Sự cố chuyển sang giai đoạn postmortem blameless (Bài 18).
Một mẹo thực tế: viết playbook này thành một trang một mặt A4, ghim lên wiki, và diễn tập nó qua các bài "game day" (mô phỏng sự cố). Playbook chỉ có giá trị khi đã được luyện tập, không phải khi nằm im trên tài liệu.
Lỗi thường gặp & mẹo
Lỗi 1 — IC cầm bàn phím. Đây là lỗi phổ biến nhất với Tech Lead mới lên. Bạn giỏi kỹ thuật nên bản năng muốn tự fix. Nhưng khi bạn debug, bạn không còn điều phối được. Mẹo: nếu bạn là người giỏi nhất về kỹ thuật, hãy làm SME và giao vai IC cho người khác — hoặc ngược lại, ép mình rời bàn phím nếu bạn nhận vai IC.
Lỗi 2 — Không ai là IC, hoặc có hai IC. Không có IC thì không ai ra quyết định, mọi người chờ nhau. Hai IC thì ra quyết định mâu thuẫn. Luôn phải có đúng một IC tại mọi thời điểm, và việc bàn giao IC phải được tuyên bố rõ ("Tôi bàn giao vai IC cho anh Hùng").
Lỗi 3 — Đi tìm root cause khi đang chảy máu. Trong lúc người dùng đang bị ảnh hưởng, tìm nguyên nhân gốc là xa xỉ. Rollback trước, điều tra sau. Root cause thuộc về postmortem.
Lỗi 4 — Im lặng với stakeholder. Khi kỹ sư tập trung fix, họ quên báo cáo, khiến sếp và CSKH hoảng loạn và liên tục làm phiền. Mẹo: cử Comms Lead ngay cả khi "chưa có gì mới để nói" — cập nhật đều đặn là cách tốt nhất để được yên tĩnh làm việc.
Lỗi 5 — Nhiều kênh giao tiếp song song. Thông tin phân mảnh trên Slack, Zalo, điện thoại, email. Ép mọi thứ về một channel duy nhất.
Mẹo bổ sung: Chuẩn bị sẵn template khai báo incident (một tin nhắn mẫu điền vào chỗ trống: mức SEV, ai là IC, link war room). Khi 2h sáng đầu óc còn ngái ngủ, template giúp bạn không bỏ sót bước nào.
Bài tập thực hành
- Viết playbook một trang cho team bạn. Dựa trên 6 bước ở trên, soạn một playbook ứng phó sự cố phù hợp với công cụ team bạn đang dùng (Slack/Zalo/Meet). Ghi rõ: ai có quyền tuyên bố incident, cách chỉ định IC, channel nào là war room.
- Phân vai một tình huống. Giả sử service login của bạn sập lúc 9h sáng, ảnh hưởng toàn bộ người dùng, team có 5 kỹ sư đang online. Hãy viết ra: ai làm IC, ai làm SME, ai làm Comms, và ba câu đầu tiên IC sẽ nói trong war room.
- Tự kiểm tra "hero risk". Liệt kê các hệ thống trong team mà chỉ đúng một người hiểu. Với mỗi hệ thống, đề xuất một hành động cụ thể (viết runbook, pair debugging) để giảm phụ thuộc.
- Thiết kế một "game day". Lên kịch bản một buổi diễn tập sự cố 30 phút cho team: giả lập một lỗi (ví dụ tắt một service ở staging), cho team chạy đúng playbook, rồi rút kinh nghiệm. Ghi lại ba điều team làm chưa mượt.
Tóm tắt
Incident Response hiệu quả không đến từ tài năng cá nhân mà từ cấu trúc đã được luyện tập trước. Hai trụ cột của bài này là:
- Vai trò rõ ràng. Incident Commander điều phối và ra quyết định nhưng không tự fix; Tech Lead/SME xử lý kỹ thuật; Comms Lead làm tường lửa thông tin với stakeholder; Scribe ghi timeline. Sự cố nhỏ một người kiêm nhiều vai; sự cố lớn không được để vai nào trống, và luôn chỉ có đúng một IC.
- Playbook sáu bước: Declare → Assign roles → Establish comms → Mitigate first → Communicate on a cadence → Resolve. Nguyên tắc bao trùm là "mitigation trước, root cause sau", và "một single channel of truth".