My Awesome Project

Appearance

Vòng Đời Incident: Detection → Triage → Mitigation → Resolution ​

Tại sao mô hình này quan trọng ​

Rất nhiều đội kỹ thuật xử lý incident như một khối công việc duy nhất — "sửa cho nó chạy lại" — mà không phân biệt các giai đoạn có tính chất hoàn toàn khác nhau. Hậu quả thực tế của việc gộp chung này là hai loại lỗi thường gặp: (1) trì hoãn việc dừng thiệt hại vì đang cố tìm nguyên nhân gốc rễ triệt để, khiến incident kéo dài không cần thiết; (2) tuyên bố incident đã "xong" ngay khi triệu chứng biến mất, trong khi nguyên nhân thật vẫn còn đó và sẽ tái diễn trong vài ngày tới dưới một dạng khác.

Cách khắc phục nằm ở việc mô hình hoá incident như một state machine có bốn trạng thái tách biệt, mỗi trạng thái có exit criteria riêng: Detection, Triage, Mitigation, Resolution. Đây không phải là một quy trình hành chính vẽ ra cho vui — mỗi lần chuyển trạng thái đại diện cho một sự thay đổi thật về mục tiêu, về công cụ được dùng, và về ai cần tham gia.

Internal model: bốn trạng thái và exit criteria ​

Detection — điều kiện tiên quyết là alert phải dựa trên triệu chứng ​

SRE Incident Management Guide của Google đặt Detection ở giai đoạn "Prepare", với nguyên tắc cốt lõi: "Alert in a timely manner: Minimize the user impact prior to incident response beginning." Điều kiện để một hệ thống alerting thực sự hữu ích trong giai đoạn này là nó phải bao quát chức năng hướng đến người dùng, dựa trên triệu chứng chứ không phải nguyên nhân nội tại, và phải cho phép hành động ngay lập tức khi nhận được.

Về mặt cơ chế, đây chính là lý do alerting dựa trên SLO burn rate (đã trình bày ở Chapter 42) tốt hơn hẳn so với alerting dựa trên ngưỡng tài nguyên tuyệt đối như "CPU > 80%". CPU cao không nhất thiết là vấn đề của người dùng — có thể hệ thống đang autoscale đúng như thiết kế. Nhưng latency p99 vượt SLO trong 5 phút liên tục là bằng chứng trực tiếp rằng người dùng thật đang bị ảnh hưởng ngay lúc này.

Exit criteria của Detection: một signal đã vượt ngưỡng alerting policy VÀ đã có ít nhất một người xác nhận (acknowledge) rằng đây là sự kiện có thật, không phải false positive. Trạng thái này kết thúc khi incident được "declare" chính thức — một hành động rời rạc, có chủ đích, không phải một cảm giác mơ hồ rằng "có gì đó không ổn".

Việc yêu cầu một bước acknowledge tường minh, thay vì để hệ thống tự động coi mọi alert là một incident, có lý do cơ chế cụ thể: alert dựa trên ngưỡng thống kê (kể cả SLO burn rate) vẫn có tỷ lệ false positive khác không — nhiễu tạm thời, một đợt traffic bất thường nhưng vô hại, hoặc chính công cụ giám sát gặp trục trặc. Nếu declare incident tự động ngay khi ngưỡng bị vượt, tổ chức sẽ nhanh chóng gặp hiện tượng "alert fatigue" — đội on-call bị đánh thức liên tục cho những sự kiện không thật, và theo thời gian sẽ có xu hướng xem nhẹ mọi alert, kể cả những alert thật. Bước acknowledge của con người, dù chỉ mất vài chục giây, là điểm kiểm tra tối thiểu để lọc bỏ phần lớn nhiễu trước khi huy động toàn bộ cơ chế ICS đã trình bày ở file 01.

Triage — funnel ba tầng: Metrics → Logs → Trace/Error Reporting ​

Triage trả lời câu hỏi: phạm vi ảnh hưởng là gì, và điểm lỗi nằm ở đâu trong hệ thống. Đây là giai đoạn dễ bị lãng phí thời gian nhất nếu không có kỷ luật về thứ tự công cụ sử dụng, vì lượng dữ liệu khả dụng trong một incident thực tế là khổng lồ và không có cấu trúc rõ ràng sẽ dẫn đến "data paralysis" — nhìn vào hàng nghìn dòng log mà không biết bắt đầu từ đâu.

Thứ tự đúng về mặt cơ chế — và đây không phải là quy ước tuỳ tiện mà phản ánh đúng độ chi tiết (granularity) tăng dần của từng loại tín hiệu — là: metrics trước để hiểu impact, logs tiếp theo để điều tra lỗi, và trace để tìm chính xác service nào đang chậm hoặc đang fail trong chuỗi request phân tán.

  1. Cloud Monitoring (metrics) trả lời "ảnh hưởng lớn cỡ nào, ở đâu, từ khi nào". Đây là tầng rẻ nhất để truy vấn (đã được aggregate sẵn) và cho cái nhìn rộng nhất — bao nhiêu % request lỗi, region nào bị ảnh hưởng, xu hướng đang tăng hay giảm. Dùng metrics trước tiên vì nó giúp xác định có nên tiếp tục điều tra sâu hơn hay không trước khi tốn thời gian vào log chi tiết.

  2. Cloud Logging (logs) trả lời "lỗi cụ thể là gì". Cloud Logging cho phép index và truy vấn từng field riêng lẻ trong structured log — ví dụ lọc theo jsonPayload.userId = 99 hoặc jsonPayload.latencyMs > 500 ngay trong Logs Explorer — nghĩa là bạn không cần grep toàn bộ log thô mà có thể thu hẹp ngay xuống đúng tập request bị ảnh hưởng. Đây là bước quan trọng để chuyển từ "cái gì đang sai" sang "vì sao nó sai" ở mức message/exception cụ thể.

  3. Cloud Trace và Error Reporting trả lời "chính xác service/span nào trong request chain đang chậm hoặc đang fail". Đây là tầng chi tiết nhất và cũng đắt nhất để tạo ra (do sampling), nên chỉ nên dùng sau khi đã thu hẹp phạm vi bằng hai tầng trên.

Kinh tế học của granularity: vì sao thứ tự funnel không thể đảo ngược ​

Lý do sâu xa khiến thứ tự metrics → logs → trace là bắt buộc, chứ không phải một thói quen tiện tay, nằm ở chi phí thu thập và lưu trữ tăng dần theo độ chi tiết. Metrics được aggregate liên tục cho 100% traffic với chi phí gần như cố định bất kể lưu lượng — đây là lý do nó luôn sẵn sàng ngay lập tức và là điểm khởi đầu an toàn. Logs ghi lại theo từng request nhưng thường không sample (mọi request có structured log riêng), nên chi phí truy vấn tăng theo khối lượng dữ liệu cần quét — vẫn khả thi nhưng chậm hơn nếu không thu hẹp phạm vi trước bằng bộ lọc field cụ thể. Trace, do chi phí lưu trữ chi tiết từng span của từng request là rất lớn ở quy mô cao, gần như luôn được triển khai với một tỷ lệ sampling (ví dụ chỉ 1–10% request được trace đầy đủ) — nghĩa là nếu bạn nhảy thẳng vào Cloud Trace ngay từ đầu mà chưa biết chính xác khung thời gian và service nào cần soi, xác suất bạn tìm đúng trace của một request lỗi cụ thể trong hàng triệu request là rất thấp. Thu hẹp phạm vi bằng metrics và logs trước không chỉ tiết kiệm thời gian con người — nó còn là điều kiện thống kê cần thiết để việc tra cứu trace (vốn bị giới hạn bởi sampling) thực sự tìm ra đúng mẫu cần xem.

Điểm cơ chế đáng chú ý nhất trong tầng thứ ba: Cloud Trace tự động truy vấn Cloud Logging để lấy log cùng khung thời gian với trace, khớp theo trace ID và span ID, và hiển thị các log này như node con nằm dưới đúng span tương ứng — nghĩa là bạn không cần tự tay join log với trace bằng tay, cơ chế correlation đã được xây sẵn ở tầng UI. Điều kiện để cơ chế này hoạt động là trace context phải được propagate xuyên suốt request (đã bàn ở Chapter 53), và log phải mang trace ID trong structured payload.

Với Error Reporting, có hai điều kiện kỹ thuật bắt buộc để nó phân nhóm lỗi đúng và hữu ích trong lúc triage căng thẳng: log phải ở mức severity ERROR trở lên (log dưới ERROR sẽ bị Error Reporting bỏ qua hoàn toàn, kể cả khi đó thực sự là một exception), và log phải chứa field serviceContext — thiếu field này, Error Reporting không thể gắn nhãn lỗi theo đúng service và version, khiến việc phân biệt "lỗi này mới xuất hiện sau lần deploy nào" trở nên bất khả thi ngay giữa lúc bạn cần câu trả lời đó nhất.

Bản chất của Error Reporting so với raw logs: log cho bạn thấy từng dòng sự kiện chi tiết, còn Error Reporting ưu tiên hoá dữ liệu đó bằng cách gom nhóm các lỗi có cùng gốc (cùng stack trace) — giá trị này đặc biệt lớn khi hệ thống đang phun ra hàng chục nghìn dòng log lỗi trong vài phút của một incident thật, và bạn cần biết "có bao nhiêu loại lỗi khác nhau đang xảy ra" thay vì đọc từng dòng một.

Exit criteria của Triage: đã xác định được phạm vi ảnh hưởng (bao nhiêu % traffic, service nào, region nào) VÀ đã có ít nhất một giả thuyết đủ cụ thể để hành động (ví dụ: "revision mới nhất của service X đang gây lỗi 500 cho toàn bộ traffic vùng asia-southeast1").

Mitigation — dừng chảy máu, tách biệt hoàn toàn khỏi Resolution ​

Đây là điểm dễ hiểu lầm nhất và cũng là nguyên tắc quan trọng nhất trong toàn bộ vòng đời incident. SRE Workbook định nghĩa thứ tự ưu tiên tuyệt đối: "Assess the impact of the incident. Mitigate the impact. Perform a root-cause analysis." — đánh giá tác động, giảm thiểu tác động, rồi mới phân tích nguyên nhân gốc rễ. Thứ tự này không phải ngẫu nhiên: workbook khuyến cáo rõ ràng không nên trì hoãn việc mitigate chỉ để chờ tìm ra root-cause đầy đủ trước.

Về mặt cơ chế, mitigation là bất kỳ hành động nào làm giảm hoặc loại bỏ tác động lên người dùng mà không nhất thiết phải hiểu vì sao vấn đề xảy ra. Rollback về version trước, chuyển traffic sang region khác, tắt một feature flag, tăng gấp đôi số replica để hấp thụ tải bất thường — tất cả đều là mitigation hợp lệ ngay cả khi đội ngũ chưa biết chính xác dòng code nào gây lỗi. Chi tiết kỹ thuật của các cơ chế mitigation phổ biến nhất (rollback, feature flag, circuit breaker) được trình bày sâu ở file 03 của chapter này.

Exit criteria của Mitigation: triệu chứng đã biến mất hoặc giảm xuống dưới ngưỡng chấp nhận được đối với người dùng thật (không phải: đội ngũ tin rằng vấn đề đã hết). Đây là lúc severity có thể được hạ cấp và phần lớn người tham gia có thể rời khỏi trạng thái phản ứng khẩn cấp — nhưng incident chưa đóng.

Resolution — sửa tận gốc, khép lại vòng lặp nguyên nhân ​

Resolution là khi nguyên nhân gốc rễ đã được xác định và một thay đổi lâu dài đã được triển khai để nó không tái diễn theo cùng cơ chế. Khoảng cách thời gian giữa Mitigation và Resolution có thể là vài giờ (một hotfix được review và deploy đúng quy trình) hoặc vài tuần (một thiết kế lại kiến trúc để loại bỏ một race condition hiếm gặp). Điều bắt buộc về mặt cơ chế là: trong suốt khoảng thời gian này, hệ thống đang chạy ở trạng thái "đã vá tạm" chứ không phải "đã lành", và mọi người liên quan phải ý thức rõ điều đó — nếu không, root cause analysis sẽ bị bỏ lửng và không bao giờ hoàn tất vì "vấn đề đã hết rồi mà".

Exit criteria của Resolution: root cause đã được xác định với đủ bằng chứng (không phải suy đoán), và một thay đổi khắc phục lâu dài đã được triển khai hoặc đã có action item cụ thể với owner và deadline để triển khai nó — đây là cầu nối trực tiếp sang postmortem, được bàn ở file 05 và file 06.

Một hệ quả vận hành cần lưu ý trong khoảng "đã vá tạm nhưng chưa lành": hệ thống giám sát cho đúng vùng vừa bị ảnh hưởng nên được giữ ở mức chú ý cao hơn bình thường (ví dụ giữ nguyên một dashboard riêng đã dựng trong lúc incident, thay vì đóng lại ngay) cho đến khi Resolution thực sự hoàn tất. Lý do: một mitigation như rollback hay bật circuit breaker thường chỉ che giấu triệu chứng mà không loại bỏ được điều kiện gây ra nó — nếu điều kiện đó tái xuất hiện trong lúc đội ngũ đã chuyển sự chú ý sang việc khác, khoảng thời gian phát hiện lại (time-to-redetect) sẽ chậm hơn hẳn so với lần đầu, vì mọi người đã có niềm tin sai lệch rằng "vấn đề này đã được biết và đã xử lý".

Constraints, trade-offs và failure mode khi scale ​

Detection gap — lỗ hổng giám sát chỉ lộ ra khi khách hàng phàn nàn ​

Một trong những tiêu chí Google Cloud Architecture Framework liệt kê để bắt buộc phải viết postmortem là "monitoring failures requiring manual discovery" — tức là trường hợp incident chỉ được phát hiện vì khách hàng report, không phải vì hệ thống alerting tự phát hiện ra. Đây là failure mode nghiêm trọng nhất của toàn bộ giai đoạn Detection: nó có nghĩa là khoảng thời gian từ lúc vấn đề bắt đầu đến lúc có người biết (time-to-detect) không được kiểm soát bởi hệ thống mà bị phó mặc cho việc người dùng đủ kiên nhẫn để report. Ở scale lớn, đây thường xảy ra với các lỗi "âm thầm" — dữ liệu bị ghi sai nhưng không throw exception, hoặc latency tăng dần từ từ dưới ngưỡng alerting cứng nhắc thay vì đột biến.

Triage paralysis khi thiếu kỷ luật về thứ tự công cụ ​

Khi một đội không có thói quen đi theo đúng thứ tự metrics → logs → trace, hành vi phổ biến dưới áp lực là nhảy thẳng vào grep log thô hoặc mở hàng chục tab dashboard cùng lúc mà không có giả thuyết dẫn đường. Hệ quả ở scale là thời gian triage kéo dài tuyến tính theo lượng log sinh ra trong incident — càng nhiều traffic bị ảnh hưởng, log càng nhiều, và nếu không thu hẹp bằng metrics trước, đội ngũ sẽ tự chôn mình dưới chính dữ liệu lẽ ra để giúp họ.

Nhầm lẫn Mitigation với Resolution — nguyên nhân gốc rễ của incident tái diễn ​

Đây là failure mode có hệ quả dài hạn nghiêm trọng nhất: khi một đội tuyên bố "đã fix" ngay khi triệu chứng biến mất (ví dụ sau khi rollback), họ thường đóng incident và chuyển sang việc khác mà không bao giờ quay lại để làm root cause analysis, vì áp lực đã giảm và động lực điều tra tiếp cũng giảm theo. Vài tuần sau, cùng một nguyên nhân gốc (một memory leak, một race condition, một giới hạn quota chưa được nhận ra) sẽ kích hoạt lại — có thể dưới một triệu chứng bề mặt khác khiến đội ngũ không nhận ra đây là "cùng một vấn đề lần thứ hai". Cơ chế phòng tránh duy nhất là ràng buộc tổ chức: incident không được đóng hoàn toàn (chỉ hạ severity) cho đến khi có postmortem hoặc quyết định rõ ràng rằng postmortem không cần thiết, theo đúng tiêu chí đã định nghĩa trước.

Anti-pattern: đuổi theo root cause hoàn hảo trước khi mitigate ​

Một sai lầm tinh vi hơn xảy ra ở những đội có kỷ luật kỹ thuật cao: vì muốn hiểu "đúng và đủ" trước khi hành động, họ trì hoãn rollback hoặc kill switch để tiếp tục điều tra sâu hơn, với lý do "rollback bây giờ sẽ làm mất dấu vết để tìm root cause". Đây là hiểu lầm về bản chất ưu tiên trong incident: root cause analysis có thể — và nên — được thực hiện sau khi mitigation, dựa trên dữ liệu đã thu thập trong live incident document, log đã được export, và trace đã được lưu lại. Chi phí của việc trì hoãn mitigation (người dùng tiếp tục chịu ảnh hưởng) gần như luôn lớn hơn chi phí của việc mất một phần dấu vết điều tra, và trong tuyệt đại đa số trường hợp, dấu vết không hề mất — vì Cloud Logging, Cloud Trace và Cloud Monitoring đều lưu trữ dữ liệu độc lập với trạng thái hiện tại của hệ thống.

GCP-native implementation guidance ​

Ví dụ truy vấn Logs Explorer thu hẹp phạm vi điều tra ở giai đoạn Triage — lọc lỗi theo service, severity, và trace ID để nhảy thẳng sang Cloud Trace:

resource.type="k8s_container"
resource.labels.namespace_name="checkout"
severity>=ERROR
jsonPayload.latencyMs>500
timestamp>="2026-07-18T02:00:00Z"

Sau khi xác định trace_id cụ thể từ kết quả trên, mở trực tiếp trace tương ứng trong Cloud Trace để xem toàn bộ span breakdown và log con được tự động khớp theo trace/span ID — bước này chuyển từ "biết có lỗi" sang "biết chính xác span nào trong chuỗi gọi dịch vụ đang chậm hoặc fail".

References ​