Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng lúc 2 giờ sáng, hệ thống thanh toán của một sàn thương mại điện tử bỗng ngừng hoạt động. Khách hàng không đặt được đơn, tổng đài bị gọi dồn dập, còn đội kỹ thuật thì mỗi người làm một kiểu: người vào xem log, người restart server, người nhắn tin hỏi "có ai đang xử lý không?". Sau 90 phút hỗn loạn, sự cố mới được khắc phục — nhưng thiệt hại đã lên tới hàng trăm triệu đồng doanh thu và vô số khách hàng bực bội.
Câu chuyện đó lặp lại ở rất nhiều công ty công nghệ tại Việt Nam, và gốc rễ hầu như không phải vì thiếu người giỏi. Vấn đề nằm ở chỗ họ không có một quy trình quản lý sự cố (Incident Management) rõ ràng: không ai biết sự cố đang ở giai đoạn nào, ai chịu trách nhiệm ra quyết định, và khi nào thì được tuyên bố "đã xong".
Ở Bài 4, bạn đã hiểu Tech Operations là gì và phạm vi của nó. Bài 5 này đi sâu vào một trong những hoạt động vận hành quan trọng và căng thẳng nhất: quản lý sự cố. Cụ thể, chúng ta tập trung vào hai trụ cột mà một người làm vận hành bắt buộc phải nắm vững:
- Vòng đời của một sự cố (incident lifecycle) — các giai đoạn mà mọi sự cố đều trải qua, từ lúc phát hiện đến lúc đóng lại.
- Các vai trò trong sự cố (incident roles) — ai làm gì, để một nhóm 5–10 người không giẫm chân nhau.
Khái niệm cốt lõi
Incident là gì, và không phải 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ụ xuống dưới mức chấp nhận được. Điểm mấu chốt là "ngoài kế hoạch" và "ảnh hưởng đến người dùng hoặc hệ thống".
Cần phân biệt rõ vài khái niệm hay bị nhầm:
- Alert (cảnh báo): một tín hiệu tự động cho biết có gì đó bất thường (ví dụ: CPU vượt 90%). Alert chưa chắc là incident. Một alert có thể tự hết, hoặc chỉ là nhiễu.
- Incident (sự cố): một tình huống thật sự cần con người vào can thiệp và điều phối.
- Problem (vấn đề gốc): nguyên nhân sâu xa đằng sau một hoặc nhiều incident. Ví dụ, một memory leak là "problem", còn các lần dịch vụ sập vì hết RAM là các "incident".
Mức độ nghiêm trọng (severity)
Trước khi nói về vòng đời, phải thống nhất cách phân loại mức độ nghiêm trọng, thường gọi là SEV (severity level). Đa số công ty dùng thang từ SEV1 đến SEV3 hoặc SEV4:
- SEV1 — Nghiêm trọng nhất: dịch vụ chính sập hoàn toàn, ảnh hưởng phần lớn người dùng, mất doanh thu trực tiếp. Ví dụ: toàn bộ trang thanh toán không truy cập được. Cần huy động ngay, có thể đánh thức cả quản lý cấp cao.
- SEV2 — Nghiêm trọng: một tính năng quan trọng hỏng nhưng còn giải pháp thay thế, hoặc ảnh hưởng một phần người dùng. Ví dụ: tìm kiếm sản phẩm chậm nhưng vẫn đặt hàng được.
- SEV3 — Trung bình/thấp: lỗi nhỏ, ảnh hưởng hạn chế, có thể xử lý trong giờ hành chính. Ví dụ: một biểu đồ trong trang admin hiển thị sai.
Vòng đời của một sự cố
Đây là phần trọng tâm của bài. Mọi incident, dù lớn hay nhỏ, đều đi qua các giai đoạn sau. Hãy hình dung nó như một đường ống mà sự cố "chảy" qua:
1. Detect (Phát hiện). Sự cố được phát hiện bằng một trong hai cách: alert tự động kích hoạt (hệ thống giám sát báo động), hoặc người dùng báo cáo (khách hàng phàn nàn, đội support tạo ticket). Mục tiêu của một tổ chức trưởng thành là tự phát hiện trước khi khách hàng phát hiện. Nếu người dùng luôn là người báo lỗi đầu tiên, hệ thống giám sát của bạn có vấn đề.
2. Acknowledge (Xác nhận). Người on-call bấm "ack" để xác nhận: "Tôi đã thấy và đang xử lý." Bước này tưởng nhỏ nhưng rất quan trọng. Nó dừng vòng leo thang (escalation) — nếu không ai ack trong X phút, hệ thống sẽ gọi người tiếp theo. Nó cũng giảm nhiễu alert: khi đã ack, các alert lặp lại cho cùng sự cố được gom lại thay vì réo liên tục. Chỉ số MTTA (Mean Time To Acknowledge) — thời gian trung bình để xác nhận — đo lường hiệu quả của giai đoạn này.
3. Triage & Assess (Phân loại và Đánh giá). Người on-call nhanh chóng trả lời: Ảnh hưởng đến ai? Bao nhiêu người dùng? Đây là SEV mấy? Đây là lúc gán severity chính thức. Nếu là SEV1/SEV2, chuyển sang huy động đội.
4. Coordinate & Investigate (Điều phối và Điều tra). Đội tập hợp lại (thường trong một "war room" — kênh chat/call riêng), phân vai, và bắt đầu điều tra: đọc log, xem dashboard, dựng lại giả thuyết về chuyện gì đang xảy ra. Đây là giai đoạn kéo dài nhất.
5. Mitigate (Giảm thiểu). Đây là điểm mà nhiều người mới hay nhầm. Mục tiêu trước mắt không phải là sửa tận gốc, mà là khôi phục dịch vụ nhanh nhất có thể. Rollback bản deploy lỗi, chuyển traffic sang region khác, tắt tính năng gây lỗi bằng feature flag — tất cả đều là mitigation. Chỉ số MTTR (Mean Time To Recover/Resolve) đo giai đoạn này. "Cầm máu trước, chữa bệnh sau."
6. Resolve (Khắc phục). Dịch vụ đã trở lại bình thường, được xác nhận qua số liệu (chứ không phải cảm tính). Người điều phối chính thức tuyên bố sự cố kết thúc và thông báo cho các bên liên quan.
7. Learn / Postmortem (Rút kinh nghiệm). Sau khi khói tan, đội ngồi lại phân tích: chuyện gì đã xảy ra, tại sao, và làm sao để không lặp lại. Phần này sẽ được đào sâu ở Bài 11 và 12 — ở đây bạn chỉ cần biết nó là một giai đoạn bắt buộc của vòng đời, không phải tùy chọn.
Một lưu ý: vòng đời này không phải lúc nào cũng tuyến tính. Trong quá trình điều tra, bạn có thể phát hiện severity thực ra cao hơn dự đoán và phải nâng cấp; hoặc một mitigation không hiệu quả và bạn phải quay lại điều tra. Nó là một vòng lặp, không phải đường thẳng.
Các vai trò trong sự cố
Với sự cố nhỏ, một người on-call làm hết là đủ. Nhưng với SEV1/SEV2, bạn cần phân vai rõ ràng để tránh cảnh "mười người cùng gõ lệnh trên một server". Mô hình phổ biến nhất, lấy cảm hứng từ hệ thống ICS (Incident Command System) của lính cứu hỏa Mỹ và được Google/PagerDuty phổ biến, gồm các vai sau:
- Incident Commander (IC) — Người chỉ huy sự cố. Đây là vai quan trọng nhất, và điều bất ngờ là IC không cần là người giỏi kỹ thuật nhất. IC không tự tay sửa lỗi. Nhiệm vụ của IC là điều phối: giữ cho cả đội tập trung, ra quyết định (nâng SEV, gọi thêm người, chọn hướng mitigation nào), và đảm bảo mọi việc chạy đúng quy trình. IC là "một nguồn sự thật duy nhất" về tình trạng sự cố.
- Communications Lead (CL) — Người phụ trách giao tiếp. Chịu trách nhiệm giao tiếp ra bên ngoài: cập nhật status page, thông báo cho ban lãnh đạo, đội chăm sóc khách hàng, và đôi khi cả khách hàng. Việc này tách khỏi IC để IC không bị phân tâm. (Cách viết cập nhật và vận hành status page sẽ ở Bài 48.)
- Operations Lead / Subject Matter Expert (SME) — Người xử lý kỹ thuật. Đây là những người thật sự "xắn tay áo" điều tra và thực thi mitigation: đọc log, chạy lệnh, rollback. Với sự cố lớn có thể có nhiều SME cho từng hệ thống (database, network, app).
- Scribe — Người ghi chép. Ghi lại dòng thời gian (timeline): mấy giờ phát hiện, ai làm gì, quyết định nào được đưa ra lúc nào. Ghi chép này là vàng cho postmortem sau này. Trong đội nhỏ, IC hoặc CL có thể kiêm luôn.
Tình huống thực tế
Tình huống 1: Sàn TMĐT Việt Nam sập giỏ hàng ngày sale 12/12
Một sàn thương mại điện tử lớn tại Việt Nam (gọi là ShopViet) bước vào đợt sale 12/12. Lúc 20:03, hệ thống giám sát báo tỷ lệ lỗi (error rate) của dịch vụ giỏ hàng vọt từ 0.2% lên 34%. Alert kích hoạt, người on-call ack sau 40 giây (MTTA rất tốt).
Người on-call nhanh chóng triage: giỏ hàng lỗi trong ngày sale = mất doanh thu trực tiếp = SEV1. Anh lập tức tuyên bố sự cố và mở war room trên Slack. Một bạn dev senior đứng ra làm IC. Vì đang trong ca, IC phân vai: hai SME lo điều tra (một người xem log ứng dụng, một người kiểm tra database), một bạn PM làm CL để cập nhật cho ban giám đốc và đội marketing (vốn đang chạy quảng cáo dồn traffic vào).
SME phát hiện: bản deploy lúc 19:50 đã thêm một truy vấn database mới không có index, khiến database quá tải khi lượng truy cập tăng vọt. Quyết định của IC: rollback ngay bản 19:50, không dừng lại phân tích tại sao truy vấn thiếu index — đó là việc để sau. Rollback xong lúc 20:19. Error rate về 0.3% lúc 20:24. IC xác nhận qua dashboard và tuyên bố resolved.
Bài học: MTTR chỉ 21 phút vì đội ưu tiên mitigate (rollback) thay vì fix tận gốc. Nếu họ ngồi tranh luận cách thêm index tối ưu ngay trong lúc cháy nhà, sự cố có thể kéo dài cả tiếng. Việc tách CL ra riêng giúp IC không bị đội marketing hỏi dồn giữa lúc căng thẳng.
Tình huống 2: Ví điện tử Đông Nam Á và cái bẫy "không ai ack"
Một ví điện tử hoạt động ở Đông Nam Á (gọi là PayFast) gặp sự cố lúc 3 giờ sáng: dịch vụ xác thực OTP chậm bất thường. Alert kích hoạt, nhưng người on-call chính đang ngủ say, điện thoại để chế độ im lặng. Sau 15 phút không ai ack, hệ thống tự động leo thang gọi người thứ hai, rồi trưởng nhóm.
Trớ trêu là do cấu hình sai, alert này lặp lại mỗi 2 phút và không được gom nhóm. Khi trưởng nhóm cuối cùng vào cuộc, kênh cảnh báo đã có 400 tin nhắn trùng lặp, che lấp cả một alert khác nghiêm trọng hơn về database. Sự cố OTP kéo dài 55 phút.
Bài học: Giai đoạn Acknowledge không chỉ là thủ tục. Ack đúng lúc sẽ dừng leo thang và gom nhiễu. PayFast sau đó sửa ba thứ: bắt buộc điện thoại on-call không được để im lặng, cấu hình gom nhóm alert (alert grouping), và đặt ngưỡng leo thang xuống 5 phút. Câu chuyện này cho thấy vòng đời sự cố hỏng ngay ở bước 2 thì mọi bước sau đều lãnh hậu quả.
Tình huống 3: Startup nhỏ và bài học về vai trò
Một startup SaaS 12 người ở TP.HCM có văn hóa "ai thấy lỗi thì nhảy vào sửa". Một hôm API chính trả lỗi 500 hàng loạt. Bốn kỹ sư cùng lao vào: một người restart service, một người rollback, một người sửa config, một người vừa deploy một hotfix — cùng lúc. Kết quả: các hành động chồng chéo khiến hệ thống rơi vào trạng thái còn tệ hơn, và không ai biết chính xác thay đổi nào gây ra hệ quả gì.
Sau sự cố, họ áp dụng quy tắc tối giản: mỗi sự cố phải có đúng một IC, và chỉ IC mới được phê duyệt hành động thay đổi hệ thống trong lúc cháy nhà. Ai muốn làm gì phải nói trong war room và chờ IC "ok". Lần sự cố tiếp theo, dù đội vẫn nhỏ, mọi thứ trật tự hẳn: một người điều phối, những người khác lần lượt thực thi.
Bài học: Vai trò không phải thứ xa xỉ chỉ dành cho công ty lớn. Ngay cả đội 12 người cũng cần ít nhất tách bạch IC với người thực thi. "Một chỉ huy" quan trọng hơn "nhiều người giỏi".
Hướng dẫn từng bước
Dưới đây là quy trình mẫu để bạn áp dụng khi một sự cố nổ ra. Hãy in ra hoặc đưa vào runbook (Bài 10) của đội:
- Phát hiện & Xác nhận. Ngay khi alert kích hoạt hoặc nhận báo cáo, ack trong vòng vài phút. Ack trước, điều tra sau — việc ack không có nghĩa bạn đã hiểu sự cố, chỉ là bạn đang cầm trịch.
- Đánh giá & Gán severity. Trả lời nhanh: ai bị ảnh hưởng, bao nhiêu, có mất tiền/dữ liệu không? Gán SEV. Khi phân vân giữa hai mức, chọn mức cao hơn — hạ severity dễ hơn nhiều so với việc phản ứng chậm.
- Tuyên bố sự cố & Mở war room. Với SEV1/SEV2, tạo một kênh riêng (Slack channel/Google Meet). Ghim thông tin cơ bản: SEV mấy, ai là IC, tóm tắt hiện trạng.
- Phân vai. Chỉ định IC trước tiên. IC sau đó chỉ định CL, SME, Scribe tùy quy mô. Nói rõ bằng lời: "Tôi là IC, An và Bình là SME, Chi là CL." Đừng để vai trò ngầm hiểu.
- Điều tra & Ra quyết định. SME đưa giả thuyết, IC quyết hướng đi. Mọi thay đổi hệ thống phải qua IC để tránh xung đột.
- Mitigate trước, fix sau. Ưu tiên khôi phục dịch vụ: rollback, feature flag, chuyển traffic. Đừng cố tìm nguyên nhân gốc trong lúc dịch vụ đang chết.
- Xác nhận khôi phục bằng số liệu. Nhìn dashboard, không tin cảm tính. Khi các chỉ số về bình thường và ổn định, IC tuyên bố resolved.
- Đóng sự cố & Lên lịch postmortem. CL gửi thông báo cuối. Scribe hoàn thiện timeline. Đặt lịch họp rút kinh nghiệm trong 24–72 giờ tới (chi tiết ở Bài 11).
Lỗi thường gặp & mẹo
- Nhầm mitigate với fix. Sai lầm phổ biến nhất. Trong lúc cháy nhà, nhiệm vụ là cầm máu, không phải phẫu thuật. Học cách phân biệt rõ hai giai đoạn này.
- Không có IC, hoặc IC kiêm luôn SME. Khi người điều phối cắm đầu gõ lệnh, không ai giữ được bức tranh toàn cục. Luôn tách IC ra khỏi việc thực thi trong sự cố lớn.
- Ack chậm hoặc không ack. Dẫn đến leo thang không cần thiết và ngập alert nhiễu. Đặt mục tiêu MTTA rõ ràng (ví dụ dưới 5 phút cho SEV1).
- Gán severity quá thấp. "Chắc không sao đâu" là câu nói nguy hiểm. Khi nghi ngờ, hãy chọn mức cao hơn rồi hạ xuống sau.
- Quên giao tiếp. Kỹ thuật lo sửa nhưng không ai báo cho support/khách hàng, khiến tổng đài bị gọi cháy máy. Vai CL sinh ra để giải quyết đúng điều này.
- Tuyên bố "xong" quá sớm. Nhìn thấy một chỉ số hồi phục rồi vội đóng, trong khi vấn đề chỉ tạm lắng. Luôn xác nhận qua nhiều số liệu và theo dõi thêm một khoảng thời gian.
- Mẹo — Chuẩn hóa trước, đừng ứng biến khi cháy nhà. Định nghĩa SEV, danh sách vai trò, và mẫu tuyên bố sự cố nên được viết sẵn trong runbook. Lúc 2 giờ sáng, bạn muốn đọc theo checklist chứ không phải phát minh quy trình mới.
Bài tập thực hành
- Vẽ vòng đời: Vẽ lại 7 giai đoạn của vòng đời sự cố bằng sơ đồ của riêng bạn. Với mỗi giai đoạn, ghi ra một câu hỏi mà người xử lý cần trả lời tại giai đoạn đó.
- Phân biệt mitigate vs fix: Cho ba tình huống sau, hãy nêu một mitigation (khôi phục nhanh) và một fix tận gốc riêng biệt cho từng cái: (a) bản deploy mới gây lỗi, (b) một region của cloud provider bị down, (c) một tính năng mới làm quá tải database.
- Đóng vai: Với đội của bạn (hoặc giả định), hãy soạn một "thẻ vai trò" một trang: liệt kê IC, CL, SME, Scribe làm gì và không làm gì. Đây là bước đầu để xây runbook.
- Tự soi hệ thống giám sát: Trong sự cố gần nhất mà bạn biết, ai là người phát hiện đầu tiên — hệ thống hay khách hàng? Nếu là khách hàng, hãy đề xuất một alert giúp tự phát hiện sớm hơn.
- Tính chỉ số: Cho một sự cố phát hiện lúc 14:00, ack lúc 14:06, khôi phục lúc 14:48. Tính MTTA và MTTR. Con số nào bạn thấy đáng cải thiện nhất, và vì sao?
Tóm tắt
- Incident là sự kiện ngoài kế hoạch làm gián đoạn dịch vụ; cần phân biệt với alert (tín hiệu) và problem (nguyên nhân gốc).
- Mọi sự cố đi qua một vòng đời: Detect → Acknowledge → Triage → Coordinate/Investigate → Mitigate → Resolve → Learn. Đây là vòng lặp, không phải đường thẳng.
- Acknowledge là bước nhỏ mà quan trọng: nó dừng leo thang và gom nhiễu alert. MTTA đo lường nó.
- Nguyên tắc sống còn: mitigate (cầm máu) trước, fix tận gốc sau. MTTR đo tốc độ khôi phục.
- Với sự cố lớn, cần phân vai rõ: Incident Commander (điều phối, không sửa lỗi), Communications Lead (giao tiếp ra ngoài), SME (xử lý kỹ thuật), Scribe (ghi chép). Không kiêm IC và SME cùng lúc.
- Severity (SEV) quyết định tốc độ và quy mô phản ứng; khi phân vân, chọn mức cao hơn.
- Chuẩn hóa quy trình trước khi sự cố xảy ra; đừng ứng biến lúc 2 giờ sáng.