Mở đầu — vì sao bài này quan trọng
Có một sự thật mà mọi Technical PM cần khắc cốt ghi tâm: hệ thống của bạn sẽ hỏng. Không phải "nếu" mà là "khi nào". Dù bạn có thuê những engineer giỏi nhất, viết test phủ 95% code, hay chi cả đống tiền cho hạ tầng, thì vẫn sẽ có ngày một database treo, một deploy lỗi, hay một service bên thứ ba sập kéo theo cả sản phẩm của bạn.
Điều phân biệt một tổ chức kỹ thuật trưởng thành với một tổ chức non nớt không phải là "có sự cố hay không", mà là "phản ứng với sự cố như thế nào". Và đây chính là nơi vai trò của bạn — một Technical PM — trở nên cực kỳ quan trọng. Trong lúc engineer đang lao vào sửa lỗi, ai sẽ điều phối thông tin? Ai trả lời câu hỏi từ CEO và bộ phận chăm sóc khách hàng? Ai quyết định khi nào thì thông báo cho khách hàng, và thông báo cái gì? Ai đảm bảo rằng sau khi "dập lửa" xong, tổ chức thực sự học được điều gì đó để lần sau không lặp lại?
Nhiều PM nghĩ rằng incident response là "việc của engineer". Đó là một hiểu lầm tai hại. Khi sự cố xảy ra, kỹ thuật chỉ là một nửa câu chuyện; nửa còn lại là điều phối con người, quản lý truyền thông, và ra quyết định dưới áp lực thời gian — đó đều là sở trường của PM. Bài học này sẽ trang bị cho bạn tư duy và quy trình để trở thành chỗ dựa vững chắc khi mọi thứ bốc cháy, và quan trọng hơn, biến mỗi sự cố thành một cơ hội để hệ thống và đội ngũ mạnh lên.
Khái niệm cốt lõi
Incident là gì?
Một incident (sự cố) là bất kỳ sự kiện ngoài ý muốn nào làm gián đoạn dịch vụ hoặc làm giảm chất lượng dịch vụ mà người dùng đang nhận. Lưu ý: không phải mọi bug đều là incident. Một nút bị lệch vài pixel là bug, nhưng không phải incident. Một lỗi khiến người dùng không thanh toán được trong giờ cao điểm thì chắc chắn là incident.
Phân loại mức độ nghiêm trọng (Severity)
Xương sống của mọi quy trình incident response là một thang đo severity rõ ràng. Nó giúp cả đội biết phải phản ứng nhanh đến mức nào, ai cần được đánh thức lúc 3 giờ sáng, và ưu tiên nguồn lực ra sao. Một thang đo phổ biến gồm bốn cấp:
- SEV1 (Nghiêm trọng nhất): Toàn bộ hệ thống sập (full outage), mất dữ liệu (data loss), hoặc lộ lọt bảo mật (security breach). Đây là loại sự cố đáng để gọi điện đánh thức người ta lúc 3 giờ sáng. Ví dụ: cả website thương mại điện tử không truy cập được, hoặc cổng thanh toán không xử lý được bất kỳ giao dịch nào. Phản ứng phải tính bằng phút.
- SEV2: Một tính năng lớn ngừng hoạt động, hoặc một tập lớn người dùng bị ảnh hưởng (large subset of users). Hệ thống vẫn chạy nhưng một phần quan trọng bị hỏng. Ví dụ: tính năng tìm kiếm sập nhưng người dùng vẫn duyệt và mua hàng được; hoặc người dùng trên Android không đăng nhập được trong khi iOS vẫn ổn.
- SEV3: Sự cố nhỏ, ảnh hưởng giới hạn, có workaround. Ví dụ: một báo cáo nội bộ bị chậm, hoặc một tính năng phụ lỗi với một nhóm nhỏ người dùng. Có thể xử lý trong giờ hành chính.
- SEV4: Lỗi cosmetic hoặc rất nhỏ, gần như không ảnh hưởng trải nghiệm. Đưa vào backlog xử lý bình thường.
Các vai trò trong một sự cố
Khi SEV1 hoặc SEV2 xảy ra, hỗn loạn là kẻ thù lớn nhất. Vì vậy cần có vai trò rõ ràng:
- Incident Commander (IC): Người chỉ huy, điều phối tổng thể, ra quyết định. IC không tự tay sửa code — nhiệm vụ của họ là giữ cho mọi thứ có trật tự, phân công, và quyết định khi nào leo thang. Đây thường là vai trò mà PM kỹ thuật có thể đảm nhận rất tốt.
- Communications Lead: Người phụ trách truyền thông — cập nhật cho stakeholder nội bộ, status page, và khách hàng. PM rất hay đóng vai này.
- Operations/Resolver: Các engineer trực tiếp chẩn đoán và sửa lỗi.
- Scribe: Người ghi lại timeline — mọi hành động, thời điểm, quyết định. Tư liệu này là vàng cho postmortem sau này.
Postmortem là gì?
Postmortem (còn gọi là retrospective hoặc post-incident review) là tài liệu và buổi họp phân tích sau khi sự cố đã được giải quyết, nhằm trả lời: chuyện gì đã xảy ra, vì sao, ta xử lý ra sao, và làm gì để nó không tái diễn. Nguyên tắc tối thượng của postmortem là blameless (không đổ lỗi) — tập trung vào hệ thống và quy trình, không phải vào việc trừng phạt cá nhân. Văn hóa này khởi nguồn từ Google và Etsy, và nay là chuẩn mực ngành.
Tình huống thực tế
Tình huống 1: Tiki và sự cố flash sale (giả định hợp lý)
Hãy hình dung một sàn thương mại điện tử lớn tại Việt Nam — gọi là Tiki — tổ chức flash sale lúc 12 giờ trưa ngày 12/12. Đúng phút mở bán, lượng truy cập tăng gấp 8 lần dự kiến. Database read replica quá tải, latency tăng vọt, và 40% người dùng thấy lỗi khi thêm hàng vào giỏ.
Đội on-call phân loại đây là SEV1 vì ảnh hưởng trực tiếp tới doanh thu trong khung giờ vàng. PM kỹ thuật đảm nhận vai Incident Commander, mở một "war room" trên Slack, phân công: một nhóm scale thêm replica, một nhóm điều tra query chậm. Communications Lead cập nhật status page mỗi 15 phút và soạn tin nhắn cho đội CSKH để trả lời khách hàng nhất quán. Sau 35 phút, đội scale hạ tầng và bật cache aggressive cho trang sản phẩm, hệ thống ổn định trở lại.
Bài học rút ra: Sự cố không được "dập" bằng việc ai đó hùng hục sửa trong im lặng, mà bằng điều phối có cấu trúc. Việc PM đứng ra làm IC giúp engineer tập trung sửa lỗi thay vì phải vừa sửa vừa trả lời câu hỏi từ sếp. Và quan trọng: load testing trước sự kiện lớn (như đã học ở các bài về capacity planning) là tuyến phòng thủ đầu tiên.
Tình huống 2: Sự cố cấu hình của một ngân hàng số
Một ngân hàng số tại Đông Nam Á (tương tự các sự cố thật của nhiều fintech) triển khai một thay đổi cấu hình tưởng chừng vô hại lúc 2 giờ chiều thứ Sáu. Vài phút sau, hệ thống xác thực bắt đầu từ chối đăng nhập của khoảng 60% người dùng. Đây là SEV1.
Trong lúc rối ren, một engineer đề xuất "rollback ngay". IC (là một Technical PM giàu kinh nghiệm) hỏi một câu quyết định: "Rollback có an toàn không, hay nó sẽ gây mất phiên đăng nhập của những người đang dùng được?" Nhờ câu hỏi này, đội kiểm tra và phát hiện rollback đơn giản sẽ làm tình hình tệ hơn. Họ chọn cách roll-forward bằng một hotfix nhỏ. Sự cố kéo dài 50 phút.
Postmortem sau đó chỉ ra root cause không phải là "engineer làm sai", mà là: không có quy trình review cho thay đổi cấu hình và không deploy vào thứ Sáu cuối ngày (một anti-pattern kinh điển). Hành động khắc phục: thêm bước peer review bắt buộc cho config change, và đóng băng deploy sau 3 giờ chiều thứ Sáu.
Bài học rút ra: Phản ứng vội vàng có thể gây hại. Vai trò của IC là làm chậm lại đúng lúc để đặt câu hỏi đúng. Và root cause gần như luôn nằm ở quy trình/hệ thống, không phải ở một con người.
Tình huống 3: Cloudflare 2019 — sức mạnh của postmortem công khai
Tháng 7/2019, Cloudflare gặp sự cố toàn cầu khiến lượng lớn website không truy cập được trong khoảng 27 phút. Nguyên nhân: một quy tắc trong hệ thống WAF (tường lửa) chứa một biểu thức chính quy (regex) gây ra hiện tượng "catastrophic backtracking", làm CPU tăng vọt lên 100% trên toàn bộ máy chủ.
Điều đáng học không phải bản thân lỗi, mà là postmortem công khai mà Cloudflare đăng ngay sau đó. Họ mô tả timeline đến từng phút, thừa nhận thẳng thắn quy trình test của họ đã bỏ sót, và liệt kê các hành động khắc phục cụ thể. Bài viết này được cộng đồng kỹ thuật toàn cầu ca ngợi và càng củng cố niềm tin vào Cloudflare.
Bài học rút ra: Một postmortem minh bạch, trung thực, blameless không làm tổn hại uy tín — nó xây dựng uy tín. Khách hàng B2B đặc biệt đánh giá cao sự minh bạch này.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng. Chia làm hai giai đoạn: trong lúc sự cố (response) và sau sự cố (postmortem).
Giai đoạn 1 — Trong lúc sự cố:
- Phát hiện và xác nhận (Detect). Sự cố thường được phát hiện qua alert tự động (monitoring), hoặc từ báo cáo của khách hàng/CSKH. Bước đầu tiên là xác nhận đây có thật là sự cố không, tránh báo động giả.
- Phân loại severity (Triage). Gán SEV1–SEV4 dựa trên tác động. Cấp này quyết định ai được gọi và phản ứng nhanh thế nào.
- Kích hoạt vai trò (Mobilize). Với SEV1/SEV2, chỉ định Incident Commander, Comms Lead, và Scribe ngay. Mở một kênh chuyên dụng (war room).
- Giảm thiểu, đừng vội tìm root cause (Mitigate). Mục tiêu số một là khôi phục dịch vụ cho người dùng — bằng rollback, bật feature flag, scale hạ tầng, hay chuyển traffic. Việc hiểu vì sao lỗi để dành cho sau. "Stop the bleeding first."
- Truyền thông liên tục (Communicate). Cập nhật stakeholder nội bộ và status page theo nhịp đều đặn (ví dụ mỗi 15–30 phút), kể cả khi chưa có tiến triển. Im lặng tạo hoảng loạn.
- Tuyên bố giải quyết (Resolve). Khi dịch vụ ổn định và đã xác nhận, IC tuyên bố sự cố kết thúc và lên lịch postmortem.
- Dựng lại timeline. Dùng ghi chép của Scribe để tái hiện chính xác mốc thời gian từ lúc phát hiện đến lúc giải quyết.
- Tìm root cause. Dùng kỹ thuật 5 Whys (hỏi "tại sao" liên tiếp) để đào sâu. Đừng dừng ở triệu chứng bề mặt.
- Đo lường tác động. Bao nhiêu người dùng bị ảnh hưởng, trong bao lâu, thiệt hại doanh thu/uy tín ước tính.
- Liệt kê action items. Mỗi hành động khắc phục phải có người chịu trách nhiệm và deadline cụ thể, được đưa vào backlog thực sự (không phải lời hứa suông).
- Chia sẻ rộng rãi. Lan tỏa postmortem trong tổ chức để cả những đội khác cũng học được.
Lỗi thường gặp & mẹo
Lỗi 1: Biến postmortem thành phiên đấu tố. Khi không khí trở thành "ai gây ra lỗi này?", người ta sẽ che giấu thông tin và không dám nhận trách nhiệm ở lần sau. Mẹo: Luôn dùng ngôn ngữ trung lập, hướng vào hệ thống: "Quy trình deploy đã cho phép thay đổi này đi qua mà không review" thay vì "Anh A đã deploy code lỗi".
Lỗi 2: Nhầm lẫn mitigation với resolution. Bật lại được service không có nghĩa là xong. Nếu bạn chỉ restart server mà không hiểu nguyên nhân, nó sẽ sập lại. Mẹo: Phân biệt rõ "đã giảm thiểu" (người dùng ổn rồi) và "đã khắc phục triệt để" (root cause đã được xử lý).
Lỗi 3: Action item không có chủ và không có deadline. Postmortem đẹp mà không ai làm gì thì vô nghĩa. Mẹo: PM nên đích thân theo dõi (track) các action item như một phần của backlog, và review chúng trong sprint planning.
Lỗi 4: Định nghĩa severity mơ hồ. Nếu đội tranh cãi 20 phút về "đây là SEV1 hay SEV2", thì thang đo của bạn quá mơ hồ. Mẹo: Viết các tiêu chí rõ ràng kèm ví dụ cụ thể cho từng cấp.
Lỗi 5: Không truyền thông vì sợ "trông tệ". Im lặng tệ hơn nhiều so với một thông báo trung thực. Mẹo: Chuẩn bị sẵn template status update để không phải nghĩ từ đầu lúc đang căng thẳng.
Mẹo nâng cao — đo MTTR: Theo dõi MTTD (Mean Time To Detect — thời gian trung bình để phát hiện) và MTTR (Mean Time To Resolve — thời gian trung bình để giải quyết). Đây là hai chỉ số sức khỏe quan trọng cho thấy quy trình incident response của bạn đang tốt lên hay xấu đi theo thời gian.
Bài tập thực hành
Bài tập 1 — Xây thang severity. Cho sản phẩm hiện tại của bạn (hoặc một sản phẩm bạn quen thuộc như Grab, Shopee, một app ngân hàng), hãy viết định nghĩa cụ thể cho SEV1, SEV2, SEV3 kèm ít nhất 2 ví dụ thực tế cho mỗi cấp. Tiêu chí phải dựa trên tác động người dùng/doanh nghiệp.
Bài tập 2 — Đóng vai Incident Commander. Tình huống: Lúc 8 giờ tối thứ Sáu, cổng thanh toán của bạn ngừng xử lý mọi giao dịch, đúng lúc đang có khuyến mãi. Hãy viết ra: (a) bạn gán severity gì và vì sao, (b) ba hành động đầu tiên trong 10 phút đầu, (c) nội dung tin nhắn cập nhật đầu tiên gửi cho ban lãnh đạo và một bản cho khách hàng trên status page.
Bài tập 3 — Viết postmortem blameless. Lấy một sự cố thật bạn từng trải qua (hoặc Tình huống 2 trong bài). Viết một postmortem hoàn chỉnh gồm: timeline, root cause dùng 5 Whys, đánh giá tác động, và ít nhất 3 action item có chủ và deadline. Tự kiểm tra: tài liệu có chỗ nào đang ngầm đổ lỗi cho cá nhân không?
Tóm tắt
Incident response và postmortem không phải là "việc của riêng engineer" — đó là một trong những nơi giá trị của Technical PM thể hiện rõ nhất. Hãy ghi nhớ những điểm cốt lõi:
- Hệ thống chắc chắn sẽ hỏng; điều quan trọng là cách bạn phản ứng, không phải việc tránh được mọi sự cố.
- Severity (SEV1–SEV4) phải dựa trên tác động tới người dùng và doanh nghiệp, giúp đội biết phải phản ứng nhanh đến mức nào.
- Trong lúc sự cố, ưu tiên giảm thiểu trước, tìm nguyên nhân sau ("stop the bleeding first"), và truyền thông liên tục, trung thực.
- Vai trò rõ ràng (Incident Commander, Comms Lead, Scribe) biến hỗn loạn thành trật tự — và PM rất phù hợp làm IC hoặc Comms Lead.
- Postmortem phải blameless, tập trung vào hệ thống và quy trình, kết thúc bằng những action item có chủ và deadline thực sự.
- Theo dõi MTTD và MTTR để biết quy trình của bạn đang cải thiện hay thoái lui.