Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là kỹ sư trực ca lúc 2 giờ sáng. Điện thoại reo dồn dập: trang thanh toán của một sàn thương mại điện tử lớn đang trả về lỗi 500 cho toàn bộ người dùng. Mỗi phút trôi qua là hàng chục triệu đồng doanh thu bốc hơi, là hàng nghìn khách hàng bực bội, là uy tín thương hiệu bị bào mòn. Trong khoảnh khắc đó, điều gì quyết định bạn xử lý được sự cố trong 15 phút hay 3 tiếng? Không phải may mắn. Đó là Incident Management — quy trình quản lý sự cố.
Trong vận hành hệ thống công nghệ (tech operations), sự cố (incident) không phải là chuyện "nếu xảy ra" mà là "khi nào xảy ra". Không có hệ thống nào chạy hoàn hảo mãi mãi. Server sập, database quá tải, một dòng code mới đẩy lên gây lỗi, nhà cung cấp cloud gặp trục trặc — tất cả đều sẽ đến. Sự khác biệt giữa một đội vận hành trưởng thành và một đội "chữa cháy hỗn loạn" nằm ở chỗ họ có một quy trình rõ ràng, được luyện tập, để phát hiện — phản ứng — khôi phục — và học hỏi từ sự cố hay không.
Bài này tập trung riêng vào cách tổ chức và vận hành quy trình quản lý sự cố: phân loại mức độ nghiêm trọng (severity levels), các vai trò trong đội ứng cứu, luồng xử lý từ lúc phát hiện đến lúc đóng sự cố, và các chỉ số đo lường hiệu quả. Đây là nền tảng thực chiến mà bất kỳ ai làm vận hành, SRE, hay DevOps đều phải nắm vững.
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 kế hoạch 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 cảm nhận được. Điểm mấu chốt: incident được định nghĩa từ góc nhìn của người dùng và doanh nghiệp, không phải từ góc nhìn kỹ thuật đơn thuần.
Ví dụ: một trong ba server web bị sập nhưng hệ thống vẫn phục vụ bình thường nhờ cân bằng tải — đó là một sự kiện (event) cần theo dõi, nhưng chưa hẳn là incident. Ngược lại, nếu thời gian tải trang tăng từ 1 giây lên 8 giây khiến người dùng bỏ giỏ hàng, thì dù không có server nào "chết", đó vẫn là một incident thực sự.
Severity Levels — Phân loại mức độ nghiêm trọng
Không phải sự cố nào cũng đáng để đánh thức cả đội lúc nửa đêm. Việc phân loại mức độ (severity) giúp bạn phản ứng tương xứng với mức độ ảnh hưởng. Một hệ thống phân loại phổ biến trong ngành:
| Mức | Mô tả | Thời gian phản hồi | Ví dụ |
|---|---|---|---|
| SEV1 | Gián đoạn toàn bộ, ảnh hưởng nghiêm trọng đến doanh thu/uy tín | Ngay lập tức (< 5 phút), huy động toàn lực | Sập toàn bộ website, không thanh toán được, mất dữ liệu khách hàng |
| SEV2 | Chức năng chính bị lỗi nặng, nhưng hệ thống chưa sập hoàn toàn | < 15 phút | Đăng nhập lỗi với 30% người dùng, tìm kiếm không hoạt động |
| SEV3 | Chức năng phụ bị lỗi, có phương án thay thế | Trong giờ làm việc | Không gửi được email thông báo, một báo cáo bị chậm |
| SEV4 | Ảnh hưởng nhỏ, mang tính thẩm mỹ hoặc cảnh báo sớm | Lên kế hoạch xử lý | Lỗi hiển thị giao diện, log cảnh báo cần theo dõi |
Các vai trò trong đội ứng cứu sự cố
Khi sự cố nghiêm trọng xảy ra, hỗn loạn lớn nhất không đến từ hệ thống mà từ con người: ai chỉ huy? ai sửa? ai báo cáo cho sếp và khách hàng? Nếu không phân vai rõ ràng, năm kỹ sư sẽ cùng cắm đầu vào cùng một chỗ, còn không ai trả lời email của giám đốc. Mô hình vai trò chuẩn (lấy cảm hứng từ hệ thống ICS — Incident Command System của lực lượng cứu hỏa Mỹ, được Google và nhiều công ty áp dụng):
- Incident Commander (IC) — Chỉ huy sự cố: Người điều phối tổng thể. IC không tự tay sửa lỗi, mà ra quyết định, phân công, và giữ cho mọi thứ có trật tự. Đây là vai trò quan trọng nhất và thường bị các đội non trẻ bỏ qua.
- Operations/Tech Lead — Người xử lý kỹ thuật: Người thực sự "đưa tay vào máy" để chẩn đoán và khắc phục.
- Communications Lead — Người phụ trách truyền thông: Cập nhật status page, thông báo cho khách hàng, cho ban lãnh đạo, cho các đội liên quan. Việc này giải phóng đội kỹ thuật khỏi việc trả lời câu hỏi liên tục.
- Scribe — Người ghi chép: Ghi lại dòng thời gian (timeline) của mọi hành động và quyết định. Đây là dữ liệu vàng cho buổi postmortem sau này.
Vòng đời của một sự cố
Một quy trình quản lý sự cố trưởng thành đi qua các giai đoạn: Phát hiện (Detect) → Phản hồi (Respond) → Khắc phục (Mitigate) → Khôi phục (Recover) → Học hỏi (Learn). Lưu ý điểm quan trọng: mục tiêu đầu tiên luôn là khôi phục dịch vụ, không phải tìm nguyên nhân gốc. Nhiều kỹ sư trẻ mắc kẹt vì cố hiểu "tại sao" trong khi khách hàng đang chờ. Hãy cầm máu trước, khám nghiệm sau.
Tình huống thực tế
Ví dụ 1: Sàn TMĐT sập trong ngày sale 12.12
Một sàn thương mại điện tử lớn tại Đông Nam Á (tạm gọi là "ShopFast") tổ chức đợt sale 12.12. Đúng 0 giờ, lượng truy cập tăng gấp 20 lần bình thường. Trong 4 phút, hệ thống thanh toán bắt đầu trả lỗi timeout. Đội trực ca ban đầu bối rối: có người restart server, có người sửa cấu hình cache, có người nhắn tin hỏi sếp — tất cả cùng lúc và không ai điều phối.
Sau đợt đó, ShopFast xây lại quy trình. Lần sale kế tiếp, khi cảnh báo tự động phát hiện tỷ lệ lỗi thanh toán vượt 2%, hệ thống lập tức tạo một SEV1 và gọi điện cho IC trực ca. IC mở một "war room" (kênh Slack + phòng họp video) trong 90 giây, chỉ định Tech Lead tập trung vào database, Comms Lead cập nhật status page, và Scribe ghi timeline. Họ phát hiện database connection pool bị cạn, tăng giới hạn kết nối và bật chế độ degrade (tạm tắt tính năng gợi ý sản phẩm để giảm tải). Dịch vụ khôi phục sau 11 phút.
Bài học: Sự khác biệt không nằm ở kỹ năng kỹ thuật — cả hai lần đội đều giỏi như nhau. Khác biệt nằm ở cấu trúc điều phối. Có IC, có phân vai, có war room chuẩn hóa thì thời gian xử lý giảm từ hàng giờ xuống chục phút.
Ví dụ 2: Cloudflare và sự cố cấu hình toàn cầu (2019)
Tháng 7/2019, Cloudflare — nhà cung cấp CDN và bảo mật cho hàng triệu website — gặp sự cố khiến lưu lượng toàn cầu sập trong khoảng 27 phút. Nguyên nhân: một quy tắc WAF (tường lửa ứng dụng) mới được đẩy lên chứa một biểu thức chính quy (regex) gây ngốn CPU đột biến, làm CPU các máy chủ nhảy vọt lên 100%.
Điều đáng học không phải là lỗi regex, mà là cách họ phản ứng. Đội của Cloudflare có quy trình rõ ràng: họ nhanh chóng xác định thay đổi vừa triển khai là thủ phạm, thực hiện "global kill" — tắt toàn bộ tập luật WAF đó để khôi phục dịch vụ trước, rồi mới điều tra sâu. Họ ưu tiên mitigate trước, root cause sau. Sau đó Cloudflare công bố một postmortem công khai rất minh bạch.
Bài học: Khi một sự cố nghiêm trọng trùng khớp thời điểm với một thay đổi vừa triển khai (deploy), nghi phạm số một luôn là chính thay đổi đó. "Rollback trước, hỏi sau" là một phản xạ cứu mạng. Và khả năng "tắt nhanh" một tính năng gây lỗi cần được thiết kế sẵn.
Ví dụ 3: Ngân hàng số và incident "im lặng"
Một ngân hàng số tại Việt Nam (tạm gọi "VBank") gặp tình huống tinh vi hơn: hệ thống không sập, không báo lỗi, nhưng các lệnh chuyển khoản liên ngân hàng bị treo ở trạng thái "đang xử lý" thay vì hoàn tất. Không có cảnh báo nào kêu, vì mọi server đều "khỏe mạnh" theo góc nhìn hạ tầng. Sự cố chỉ được phát hiện sau 40 phút khi tổng đài chăm sóc khách hàng bị dồn dập cuộc gọi.
Đây là loại incident nguy hiểm nhất: không được phát hiện bởi monitoring kỹ thuật mà bởi khách hàng. Sau sự cố, VBank bổ sung cảnh báo dựa trên chỉ số nghiệp vụ (tỷ lệ giao dịch hoàn tất thành công trong 5 phút) thay vì chỉ giám sát CPU/RAM.
Bài học: Giám sát sức khỏe hạ tầng là chưa đủ. Bạn phải giám sát cả trải nghiệm thực của người dùng và các chỉ số nghiệp vụ. Một incident có thể "âm thầm" trong khi mọi biểu đồ kỹ thuật vẫn xanh.
Hướng dẫn từng bước
Đây là quy trình thực chiến khi một sự cố xảy ra:
- Phát hiện và khai báo (Declare): Ngay khi nghi ngờ có sự cố, hãy chính thức "declare an incident". Đừng ngại. Việc khai báo kích hoạt quy trình và huy động đúng người. Gán severity ban đầu — nghi ngờ thì nâng mức.
- Chỉ định Incident Commander: Người đầu tiên nhận sự cố hoặc người trực ca đảm nhận vai IC cho đến khi có người phù hợp hơn tiếp quản. IC tuyên bố rõ: "Tôi là IC cho sự cố này."
- Mở kênh liên lạc tập trung (War room): Một kênh Slack/Teams riêng cho sự cố này và (nếu SEV1/SEV2) một cuộc gọi video. Mọi trao đổi diễn ra ở đây để Scribe ghi lại được.
- Ưu tiên khắc phục (Mitigate) trước: Đặt câu hỏi "làm gì để dịch vụ hoạt động lại ngay?" trước câu hỏi "tại sao nó hỏng?". Các phương án nhanh: rollback bản deploy vừa rồi, khởi động lại dịch vụ, chuyển lưu lượng sang vùng khác, bật chế độ degrade, tắt tính năng gây lỗi bằng feature flag.
- Truyền thông đều đặn: Comms Lead cập nhật status page và thông báo nội bộ theo nhịp cố định (ví dụ mỗi 15–30 phút), kể cả khi chỉ để nói "vẫn đang xử lý, chưa có thông tin mới". Sự im lặng làm khách hàng lo lắng hơn cả bản thân sự cố.
- Xác nhận khôi phục và đóng sự cố: Chỉ tuyên bố "resolved" khi đã xác minh dịch vụ ổn định thực sự qua chỉ số, không phải "trông có vẻ ổn". IC chính thức đóng sự cố.
- Lên lịch postmortem: Với mọi SEV1/SEV2, đặt lịch họp rút kinh nghiệm không đổ lỗi (blameless postmortem) trong vòng vài ngày. (Chi tiết cách viết postmortem sẽ được học ở bài riêng.)
Đo lường hiệu quả — Các chỉ số quan trọng
Để cải thiện, bạn phải đo được. Ba chỉ số cốt lõi:
- MTTD (Mean Time To Detect): thời gian trung bình từ khi sự cố bắt đầu đến khi được phát hiện. Cải thiện bằng monitoring và alerting tốt hơn.
- MTTR (Mean Time To Resolve/Recover): thời gian trung bình từ khi phát hiện đến khi khôi phục. Đây là chỉ số "vàng" phản ánh sức khỏe quy trình ứng cứu.
- MTTA (Mean Time To Acknowledge): thời gian từ khi cảnh báo phát ra đến khi có người xác nhận đang xử lý. Phản ánh chất lượng on-call.
Lỗi thường gặp & mẹo
Lỗi 1 — Không có ai làm IC, ai cũng nhảy vào sửa. Đây là lỗi phổ biến nhất. Kết quả là năm người dẫm chân nhau. Mẹo: quy tắc "một sự cố, một chỉ huy". IC có thể không phải người giỏi kỹ thuật nhất, nhưng phải là người điều phối tốt nhất.
Lỗi 2 — Lao vào tìm nguyên nhân gốc khi khách hàng đang chờ. Điều tra là quan trọng, nhưng không phải lúc dịch vụ đang chết. Mẹo: luôn hỏi "mitigate được chưa?" trước "root cause là gì?".
Lỗi 3 — Phân loại severity quá thấp vì sợ làm phiền. Nhiều người ngại "declare SEV1" vì sợ bị đánh giá là làm quá. Mẹo: xây văn hóa "declaring an incident is always OK" — khai báo sự cố không bao giờ bị chê trách, kể cả khi hóa ra là báo động giả.
Lỗi 4 — Im lặng với khách hàng. Không cập nhật gì trong lúc xử lý khiến khách hàng nghĩ bạn không biết hoặc không quan tâm. Mẹo: cập nhật đều đặn theo nhịp, kể cả khi chưa có gì mới.
Lỗi 5 — Không ghi timeline. Sau sự cố, không ai nhớ chính xác điều gì xảy ra lúc nào, khiến postmortem trở nên vô nghĩa. Mẹo: chỉ định Scribe ngay từ đầu, hoặc bật ghi log tự động trong kênh sự cố.
Mẹo vàng — Luyện tập khi trời quang. Đừng đợi sự cố thật mới lần đầu chạy quy trình. Các đội giỏi tổ chức diễn tập định kỳ để mọi người quen vai trò. Khi khủng hoảng thật xảy ra, bạn muốn phản xạ đã thành bản năng.
Bài tập thực hành
- Thiết kế bảng severity cho sản phẩm của bạn. Chọn một ứng dụng bạn quen thuộc (ví dụ một app đặt đồ ăn). Định nghĩa SEV1 đến SEV4 với ví dụ cụ thể và thời gian phản hồi tương ứng. Tự hỏi: "Chức năng nào sập thì gọi là SEV1?"
- Viết kịch bản phân vai. Giả định một sự cố SEV1: cổng thanh toán lỗi 100%. Viết ra ai làm IC, ai làm Tech Lead, ai làm Comms, và ba tin nhắn cập nhật đầu tiên mà Comms Lead sẽ gửi lên status page (mốc phút thứ 5, 20, và khi resolved).
- Tính MTTR. Cho một sự cố với các mốc thời gian: cảnh báo phát 02:03, có người ack 02:09, bắt đầu mitigate 02:15, dịch vụ khôi phục 02:41. Tính MTTA và MTTR. Chỉ ra một điểm trong dòng thời gian này mà bạn có thể cải thiện và cách làm.
- Săn incident im lặng. Nhìn vào hệ thống bạn đang làm (hoặc một hệ thống giả định) và liệt kê ba loại sự cố mà monitoring kỹ thuật hiện tại sẽ không phát hiện được, rồi đề xuất chỉ số nghiệp vụ để bắt chúng.
Tóm tắt
Incident Management không phải là chuyện "sửa lỗi cho giỏi", mà là chuyện có một quy trình rõ ràng, được luyện tập để phản ứng có trật tự khi hỗn loạn ập đến. Những điểm cốt lõi cần nhớ:
- Incident được định nghĩa từ góc nhìn người dùng và doanh nghiệp, không chỉ từ chỉ số kỹ thuật.
- Phân loại severity (SEV1–SEV4) giúp bạn phản ứng tương xứng; khi nghi ngờ, hãy nâng mức.
- Phân vai rõ ràng — Incident Commander, Tech Lead, Comms Lead, Scribe — là thứ biến hỗn loạn thành trật tự. IC điều phối, không tự sửa.
- Mitigate trước, root cause sau. Cầm máu cho bệnh nhân trước khi khám nghiệm.
- Truyền thông đều đặn với khách hàng và nội bộ quan trọng ngang việc sửa lỗi.
- Đo lường MTTD, MTTA, MTTR để biết mình đang tiến bộ ở đâu.