AI-Assisted Root Cause Analysis Techniques

Khi hệ thống production sập giữa đêm, thứ quyết định bạn mất 20 phút hay 3 tiếng để tìm ra nguyên nhân không phải là bạn giỏi đến đâu, mà là bạn có biết cách biến hàng nghìn dòng log hỗn loạn thành một context gọn gàng để AI giúp bạn suy luận hay không.

Root cause analysis (RCA - phân tích nguyên nhân gốc rễ) là kỹ năng phân biệt một kỹ sư senior thực thụ với một người chỉ giỏi viết code mới. Khi có sự cố, áp lực thời gian, số liệu thiếu, log rời rạc và tâm lý hoảng loạn của cả team khiến việc suy luận logic trở nên cực kỳ khó khăn. AI, đặc biệt là các coding agent như Claude Code hay Cursor, có thể là một cộng sự điều tra cực kỳ hiệu quả — với điều kiện bạn biết cách "nạp" đúng dữ liệu và đặt đúng câu hỏi. Bài này sẽ đi từ framework điều tra sự cố kinh điển, cách chuẩn bị context cho AI, đến một buổi thực hành đầy đủ về một sự cố latency thanh toán thực tế.

Framework điều tra sự cố có cấu trúc

Trước khi đưa bất kỳ thứ gì cho AI, bạn cần một khung tư duy để tự mình không bị cuốn theo cảm tính. Ba framework kinh điển vẫn còn nguyên giá trị trong thời đại agentic, vì chúng cho AI (và cả bạn) một cấu trúc rõ ràng để bám vào thay vì đoán mò.

5 Whys là kỹ thuật đơn giản nhất: hỏi "tại sao" liên tiếp cho tới khi chạm đáy vấn đề. Ví dụ: Tại sao checkout API trả lỗi 504? → Vì request tới payment service timeout. Tại sao payment service timeout? → Vì nó đang chờ kết nối tới fraud-check service. Tại sao chờ kết nối? → Vì connection pool tới fraud-check service đã cạn. Tại sao pool cạn? → Vì một thay đổi cấu hình giảm pool size từ 50 xuống 10 trong bản deploy gần nhất. Đây chính là root cause. Điểm mạnh của 5 Whys là dễ áp dụng, điểm yếu là nó giả định nguyên nhân là một chuỗi tuyến tính — trong hệ thống phân tán (distributed system) hiện đại, sự cố thường có nhiều nguyên nhân đan xen (nguyên nhân gốc + yếu tố kích hoạt + yếu tố khuếch đại), nên 5 Whys chỉ nên là bước khởi động.

Fishbone diagram (Ishikawa) phù hợp khi nguyên nhân có thể đến từ nhiều nhóm khác nhau: code (bug logic), config (thay đổi cấu hình), infrastructure (hạ tầng, mạng, tài nguyên), dependency (bên thứ ba), data (dữ liệu bất thường), và con người/quy trình (deploy sai giờ cao điểm). Khi brainstorm với AI, bạn có thể yêu cầu nó liệt kê giả thuyết theo từng nhánh này thay vì đưa ra một câu trả lời duy nhất — cách này ép AI (và bạn) không bỏ sót các khả năng ít rõ ràng hơn như "network partition giữa hai availability zone" hay "certificate hết hạn".

Timeline reconstruction (dựng lại dòng thời gian) là kỹ thuật quan trọng nhất khi làm việc với AI, vì LLM cực kỳ giỏi khi có một chuỗi sự kiện được sắp xếp theo thời gian rõ ràng để tìm tương quan (correlation). Bạn liệt kê mọi sự kiện có timestamp: deploy, thay đổi feature flag, spike traffic, cảnh báo (alert) được bắn ra, thay đổi trong dependency bên ngoài — rồi xếp chúng cạnh biểu đồ latency/error rate. AI sẽ giỏi phát hiện "thời điểm latency tăng trùng khớp 98% với thời điểm deploy X" hơn là bạn tự dò bằng mắt qua nhiều tab Grafana.

Trong thực tế, cách hiệu quả nhất là kết hợp cả ba: dùng fishbone để không bỏ sót nhóm nguyên nhân, dùng timeline để tìm tương quan thời gian, và dùng 5 Whys để đào sâu vào giả thuyết có xác suất cao nhất.

Mẹo: Luôn viết timeline sự cố ra một file text (kể cả khi đang rối), theo format [timestamp] [nguồn] [sự kiện] — đây chính là artifact quý giá nhất bạn có thể đưa cho AI ngay sau khi ổn định hệ thống (mitigate xong).

Đưa dữ liệu sự cố cho AI

Đây là bước nhiều kỹ sư làm sai nhất: họ copy-paste một đống log thô, không có ngữ cảnh, rồi hỏi AI "tại sao lỗi?" và thất vọng vì câu trả lời chung chung. AI không thiếu khả năng suy luận — nó thiếu ngữ cảnh (context) đủ tốt.

Có bốn loại dữ liệu chính cần đưa vào, và thứ tự ưu tiên rất quan trọng vì context window có giới hạn:

Log đã lọc, không phải log thô. Đừng đổ nguyên 50,000 dòng log từ Datadog/CloudWatch vào. Hãy lọc theo service, theo time range quanh sự cố (thường là trước 15-30 phút và trong lúc sự cố), và ưu tiên log ERROR/WARN kèm một ít INFO xung quanh để có ngữ cảnh. Nếu log quá dài, tóm tắt các pattern lặp lại (ví dụ "lỗi X lặp lại 4,200 lần từ 14:02 đến 14:18") thay vì dán từng dòng.
Metrics dạng số cụ thể, không phải ảnh chụp màn hình mô tả chung chung. "Latency tăng cao" vô dụng với AI. "p50 latency ổn định ở 180ms, p99 tăng từ 220ms lên 4,200ms trong vòng 6 phút, error rate từ 0.2% lên 11.8%" thì AI dùng được ngay. Nếu bạn dùng công cụ có khả năng đọc ảnh (như Claude với vision), chụp biểu đồ Grafana vẫn hữu ích, nhưng luôn kèm số liệu text để AI trích dẫn chính xác trong phân tích.
Distributed trace (dấu vết phân tán) từ các công cụ như Datadog APM, Jaeger, hay Honeycomb. Đây là dữ liệu giá trị nhất cho sự cố latency vì nó cho thấy chính xác request đi qua service nào, span nào chiếm bao nhiêu thời gian. Trích một vài trace ID đại diện cho request chậm nhất, paste dạng breakdown theo span thay vì raw JSON.
Lịch sử deploy và thay đổi cấu hình. 80% sự cố production bắt nguồn từ một thay đổi nào đó — deploy code, thay đổi feature flag, migration database, thay đổi cấu hình hạ tầng (autoscaling, load balancer). Luôn đưa cho AI danh sách các thay đổi trong 24-48 giờ trước sự cố, kèm timestamp chính xác.

Một sai lầm phổ biến khác là đưa dữ liệu rời rạc qua nhiều lượt hỏi (prompt) riêng lẻ, khiến AI mất khả năng liên kết. Thay vào đó, hãy gộp tất cả vào một context package duy nhất (xem phần tiếp theo) và đưa trong một lần.

Mẹo: Với log lặp lại hàng nghìn dòng, dùng lệnh như grep -c hoặc jq để nhóm và đếm trước khi paste — AI phân tích 20 dòng đã tóm tắt tốt hơn nhiều so với 5,000 dòng thô bị cắt bớt giữa chừng vì vượt context window.

Xây dựng gói ngữ cảnh sự cố chất lượng cao

"Incident context package" là thuật ngữ để chỉ một tài liệu duy nhất, có cấu trúc, tổng hợp mọi thứ AI cần để đưa ra giả thuyết root cause đáng tin cậy. Một gói tốt thường gồm các phần sau, theo đúng thứ tự:

Tóm tắt triệu chứng (symptom summary): dịch vụ nào bị ảnh hưởng, triệu chứng cụ thể (lỗi gì, latency bao nhiêu), thời điểm bắt đầu, mức độ ảnh hưởng (bao nhiêu % người dùng, doanh thu ước tính bị ảnh hưởng nếu có).
Timeline sự kiện như đã nói ở trên, gồm cả deploy, alert, hành động của on-call (người trực).
Kiến trúc/dependency graph liên quan: không cần toàn bộ system, chỉ cần các service nằm trên đường đi của request bị lỗi. Vẽ nhanh bằng text dạng Client -> API Gateway -> Checkout Service -> Payment Service -> Fraud Check Service -> Database là đủ.
Log đã lọc và số liệu như mục trên.
Giả thuyết đã loại trừ: rất quan trọng nhưng hay bị bỏ qua. Nếu team đã kiểm tra và loại trừ khả năng "do CDN" hay "do DNS", hãy nói rõ với AI, để nó không lãng phí thời gian gợi ý lại hướng đã chết.
Ràng buộc và câu hỏi cụ thể: bạn muốn AI trả lời gì — xác định root cause? Đề xuất hành động khắc phục ngay (mitigation)? Viết postmortem? Nêu rõ để AI không lan man.

Ví dụ cấu trúc một context package thực tế:

INCIDENT SUMMARY
- Service: checkout-api
- Symptom: p99 latency 220ms -> 4200ms, error rate 0.2% -> 11.8%
- Start: 2026-07-08 14:02 UTC, ongoing 22 minutes, mitigated 14:24 UTC
- Impact: ~9,400 failed checkout attempts, est. $47k GMV at risk

TIMELINE
14:00 - deploy #4821 to payment-service (adds retry logic for fraud-check calls)
14:02 - p99 latency on checkout-api begins climbing
14:05 - PagerDuty alert: checkout-api error rate > 5%
14:07 - on-call (An) acknowledges, checks Grafana dashboard
14:09 - fraud-check-service connection pool metric shows 100% utilization
...

ARCHITECTURE (relevant path)
Client -> API Gateway -> checkout-api -> payment-service -> fraud-check-service -> Postgres

FILTERED LOGS
[payment-service] ERROR "connection pool exhausted, waited 5000ms" x 1,847 occurrences 14:02-14:24

RULED OUT
- Not a database issue: Postgres CPU/connections normal throughout
- Not a CDN/network issue: latency to API Gateway from client unaffected

QUESTION
Identify the most likely root cause of the pool exhaustion and propose an immediate mitigation plus a permanent fix.

Gói ngữ cảnh như trên tuy mất 5-10 phút chuẩn bị nhưng biến AI từ "trợ lý đoán mò" thành "đồng đội điều tra thực thụ" — vì nó có đủ tín hiệu để loại trừ giả thuyết sai và tập trung vào giả thuyết đúng.

Mẹo: Lưu template context package này thành một file .md trong runbook của team, để bất kỳ ai trực on-call cũng điền vào nhanh chóng thay vì soạn lại từ đầu lúc đang hoảng loạn.

Vai trò của AI trong viết postmortem

Sau khi sự cố được khắc phục, viết postmortem (báo cáo sau sự cố) là công việc quan trọng nhưng thường bị trì hoãn vì kỹ sư đã kiệt sức. Đây là nơi AI tỏa sáng rõ rệt nhất, vì công việc chủ yếu là tổng hợp và trình bày lại thông tin đã có, không phải suy luận mới.

AI làm tốt các việc sau:
- Chuyển timeline thô thành văn xuôi mạch lạc, đúng giọng văn khách quan, không đổ lỗi (blameless) theo chuẩn ngành (kiểu SRE của Google hay Etsy).
- Tóm tắt impact thành các chỉ số rõ ràng cho stakeholder không rành kỹ thuật: số phút downtime, số request lỗi, ước tính doanh thu ảnh hưởng.
- Soạn action items theo format chuẩn (owner, deadline, priority) dựa trên các điểm yếu đã phát hiện trong quá trình điều tra.
- Kiểm tra tính nhất quán: đọc lại toàn bộ timeline và chỉ ra chỗ mâu thuẫn, ví dụ hai người report giờ khác nhau cho cùng một sự kiện.

Tuy nhiên, AI không nên là người quyết định nguyên nhân cuối cùng viết vào postmortem chính thức mà không có kỹ sư đã trực tiếp xử lý sự cố xác nhận lại. Lý do: postmortem là tài liệu có tính trách nhiệm (accountability) và ảnh hưởng tới quyết định đầu tư kỹ thuật sau này — nếu AI ghi sai root cause (ví dụ do thiếu một mẩu log quan trọng không được đưa vào context), sai lầm đó có thể lan sang các quyết định sai tiếp theo (như đầu tư sai chỗ để "sửa" một nguyên nhân không có thật).

Một cách dùng AI hiệu quả cho postmortem là để nó viết bản nháp đầu tiên (draft) toàn bộ, sau đó Incident Commander (người chỉ huy sự cố) và các kỹ sư liên quan review, chỉnh sửa phần root cause và action items — AI xử lý phần "văn phong và cấu trúc" tốn thời gian, con người xử lý phần "phán đoán và trách nhiệm".

Prompt mẫu để nhờ AI soạn nháp postmortem:

Based on the incident context package above and the final confirmed root cause
(connection pool size reduced from 50 to 10 in config change #4821-cfg),
draft a blameless postmortem following this structure:
1. Summary (2-3 sentences)
2. Impact (quantified)
3. Timeline (bulleted, UTC timestamps)
4. Root cause (technical explanation, no blame on individuals)
5. What went well / what went poorly during response
6. Action items (owner: TBD, priority: P0/P1/P2)
Keep tone factual and blameless. Do not speculate beyond the confirmed facts provided.

Mẹo: Luôn thêm câu "Do not speculate beyond the confirmed facts provided" vào prompt viết postmortem — nếu không, AI có xu hướng "làm đẹp" bằng cách suy diễn thêm chi tiết nghe hợp lý nhưng không được xác nhận.

Giới hạn của AI trong root cause analysis

Hiểu rõ giới hạn của AI quan trọng không kém việc biết cách dùng nó, vì tin tưởng sai chỗ trong lúc sự cố có thể khiến bạn đi sai hướng và kéo dài thời gian downtime.

AI không có quyền truy cập trực tiếp vào hệ thống của bạn (trừ khi bạn cấp qua tool/MCP). Nó chỉ suy luận trên dữ liệu bạn đưa vào. Nếu bạn quên đưa một log quan trọng hoặc một thay đổi cấu hình, AI sẽ tự tin đưa ra giả thuyết sai dựa trên phần dữ liệu không đầy đủ — và vấn đề là nó thường trình bày giả thuyết sai đó với giọng điệu chắc chắn y hệt giả thuyết đúng.

AI có xu hướng thiên vị về nguyên nhân phổ biến (common cause bias). Vì được huấn luyện trên lượng lớn dữ liệu về các sự cố điển hình (timeout, memory leak, N+1 query, race condition), AI sẽ có xu hướng gợi ý các nguyên nhân "sách vở" trước, ngay cả khi sự cố của bạn có nguyên nhân đặc thù (ví dụ: một quirk riêng trong cách hệ thống nội bộ xử lý retry). Đây là lý do bạn luôn cần một kỹ sư hiểu hệ thống thực tế để đánh giá lại giả thuyết của AI, chứ không nhận nó "as-is".

AI không thể phân biệt correlation và causation tốt hơn con người có kinh nghiệm. Nếu deploy X và sự cố Y xảy ra gần nhau về thời gian, AI sẽ tự nhiên gợi ý deploy X là nguyên nhân — điều này thường đúng nhưng không phải luôn luôn. Bạn vẫn cần verify bằng cách khác: rollback thử nghiệm, so sánh với canary không có thay đổi, hoặc kiểm tra chi tiết code diff.

AI không có "cảm giác" về độ tin cậy của từng nguồn dữ liệu. Một kỹ sư senior biết rằng metric từ APM đôi khi bị sai lệch do sampling, hoặc log timestamp có thể lệch múi giờ giữa các service. AI mặc định tin tưởng mọi con số bạn đưa vào là chính xác tuyệt đối, trừ khi bạn cảnh báo trước.

Nguyên tắc thực dụng: dùng AI để mở rộng không gian giả thuyết nhanh và tổng hợp thông tin, nhưng luôn giữ bước xác minh thủ công (verification) trước khi công bố root cause chính thức — đặc biệt với sự cố ảnh hưởng tới thanh toán, dữ liệu khách hàng, hoặc compliance. Mức độ tin tưởng giả thuyết của AI nên tỷ lệ thuận với: (1) độ đầy đủ của context bạn đưa vào, (2) mức độ giả thuyết đó được xác nhận chéo bởi ít nhất hai nguồn dữ liệu độc lập (ví dụ log + metric, hoặc trace + config diff).

Mẹo: Luôn hỏi ngược AI "What data would falsify this hypothesis?" (dữ liệu nào sẽ chứng minh giả thuyết này sai?) — nếu nó không thể trả lời cụ thể, giả thuyết đó chưa đủ chắc để công bố.

Thực hành: Điều tra sự cố tăng đột biến latency thanh toán

Hãy cùng đi qua một sự cố mô phỏng gần với thực tế: hệ thống thanh toán (checkout) của một sàn thương mại điện tử gặp sự cố latency trong một đợt flash sale.

Bối cảnh sự cố: 14:00 UTC ngày flash sale, traffic tăng gấp 6 lần bình thường. Lúc 14:02, dashboard PagerDuty bắn cảnh báo: checkout-api p99 latency > 2000ms. Đội on-call (bạn) nhận alert lúc 14:05.

Bước 1 — Xác nhận và định lượng triệu chứng. Trước khi hỏi AI bất cứ điều gì, tự kiểm tra Grafana và Datadog để có số liệu cứng:

checkout-api p50: 190ms -> 210ms (bình thường)
checkout-api p99: 220ms -> 4,200ms (tăng 19 lần)
error rate (5xx): 0.3% -> 11.8%
throughput: 1,200 req/s -> 7,400 req/s (do flash sale)

Bước 2 — Dựng timeline nhanh bằng cách kiểm tra deploy log, feature flag dashboard, và alert history:

13:45 - feature flag "flash-sale-checkout-v2" enabled at 100%
14:00 - deploy #4821 to payment-service: "add retry logic for fraud-check calls, max 3 retries, 2s timeout each"
14:02 - checkout-api p99 latency begins climbing
14:05 - PagerDuty page fires, on-call acknowledges
14:06 - fraud-check-service connection pool utilization metric hits 100% (Datadog APM)
14:09 - payment-service logs show "HikariPool-1 - Connection is not available, request timed out after 30000ms"
14:11 - checkout-api starts returning 504 to ~12% of requests

Bước 3 — Soát dependency graph liên quan:

Client -> API Gateway -> checkout-api -> payment-service -> fraud-check-service -> Postgres (fraud_db)
                                       -> inventory-service (unaffected, latency normal)

Bước 4 — Đóng gói context và đưa cho AI. Đây là prompt thực tế bạn sẽ gõ vào Claude Code hoặc Cursor, với toàn bộ dữ liệu trên gộp lại:

I'm investigating a production incident on checkout-api. Here is the full context:

METRICS
- checkout-api p99 latency: 220ms -> 4,200ms starting 14:02 UTC
- error rate (5xx): 0.3% -> 11.8%
- traffic: 1,200 req/s -> 7,400 req/s (expected, flash sale campaign)

TIMELINE (UTC)
13:45 - feature flag "flash-sale-checkout-v2" enabled at 100%
14:00 - deploy #4821 to payment-service: adds retry logic for fraud-check calls
         (max 3 retries, 2s timeout each, no circuit breaker)
14:02 - checkout-api p99 latency begins climbing
14:06 - fraud-check-service DB connection pool utilization hits 100% (Datadog APM)
14:09 - payment-service logs: "HikariPool-1 - Connection is not available,
         request timed out after 30000ms" (1,847 occurrences between 14:09-14:24)
14:11 - checkout-api starts returning 504 to ~12% of requests

ARCHITECTURE (relevant request path)
Client -> API Gateway -> checkout-api -> payment-service -> fraud-check-service -> Postgres (fraud_db)

RULED OUT
- inventory-service: latency normal throughout, not on the critical path for this error
- API Gateway / CDN: latency from client to gateway unaffected
- Postgres (fraud_db) CPU/memory: normal, no slow query alerts

QUESTION
1. What is the most likely root cause of the connection pool exhaustion?
2. What immediate mitigation would you recommend right now, with minimal risk?
3. What data would confirm or rule out your top hypothesis?

Bước 5 — Đánh giá phản hồi của AI. Với context đầy đủ như trên, một AI assistant tốt sẽ suy luận ra hướng hợp lý nhất: retry logic mới thêm trong deploy #4821 không có circuit breaker và không giới hạn concurrency — khi traffic tăng 6 lần do flash sale, số lượng request gọi tới fraud-check-service tăng vọt, mỗi request lỗi được retry tối đa 3 lần, mỗi lần giữ một connection trong pool tới 2 giây — khiến connection pool (vốn được cấu hình cho traffic bình thường) bị chiếm dụng và cạn kiệt nhanh, tạo hiệu ứng "retry storm" (bão retry) tự khuếch đại. AI sẽ đề xuất: (a) mitigation ngay lập tức — tắt feature flag retry mới hoặc rollback deploy #4821, tăng tạm connection pool size; (b) fix lâu dài — thêm circuit breaker, giới hạn concurrency, và bulkhead pattern để cô lập tài nguyên.

Bước 6 — Verify giả thuyết trước khi hành động. Đây là bước không được bỏ qua: kiểm tra connection pool config trong code diff của #4821 để xác nhận đúng là pool size bị ảnh hưởng gián tiếp bởi retry logic (không phải bị giảm trực tiếp như ví dụ ở phần 5 Whys phía trên — hai kịch bản khác nhau tuy triệu chứng giống nhau!). Xác nhận bằng cách so sánh số connection đang mở thực tế trong pool metric với pool size cấu hình, và kiểm tra tỷ lệ request có retry_count > 0 trong log có tương quan với thời điểm pool đầy hay không.

Bước 7 — Mitigate và xác nhận hồi phục. Sau khi rollback deploy #4821 lúc 14:24, latency giảm về mức bình thường trong vòng 3 phút, error rate về 0.4%. Ghi nhận kết quả này vào timeline — đây chính là bằng chứng thực nghiệm xác nhận giả thuyết root cause của AI là đúng (vì hành động mitigate dựa trên giả thuyết đó có hiệu quả).

Bước 8 — Dùng AI viết postmortem draft với context package đã cập nhật thêm phần "confirmed root cause" và "mitigation timeline", theo prompt mẫu đã trình bày ở phần trước.

Qua ví dụ này, có thể thấy AI không "phát hiện" root cause bằng phép màu — nó suy luận cực nhanh và chính xác trên nền context bạn đã chuẩn bị kỹ. Nếu bạn bỏ qua phần "RULED OUT" hoặc không đưa chi tiết retry logic trong deploy #4821, AI rất có thể sẽ chỉ dừng ở "có vẻ liên quan tới traffic tăng do flash sale" — một kết luận đúng nhưng vô dụng vì không actionable.

Mẹo: Khi nghi ngờ retry storm, luôn kiểm tra xem retry logic mới có kèm circuit breaker và jitter (độ trễ ngẫu nhiên giữa các lần retry) hay không — đây là nguyên nhân phổ biến bậc nhất của các sự cố cascading failure (lỗi lan chuỗi) trong hệ thống phân tán khi traffic tăng đột biến.

Những điểm chính

Dùng framework có cấu trúc (5 Whys, fishbone, timeline reconstruction) để tự tổ chức suy nghĩ trước khi đưa dữ liệu cho AI — đừng để AI thay bạn tư duy từ đầu.
Chất lượng câu trả lời của AI tỷ lệ thuận với chất lượng context: log đã lọc và tóm tắt, metric dạng số cụ thể, distributed trace, và lịch sử deploy/config đều quan trọng hơn là dán log thô.
Gói ngữ cảnh sự cố (incident context package) nên có: tóm tắt triệu chứng, timeline, dependency graph liên quan, log/metric đã lọc, danh sách giả thuyết đã loại trừ, và câu hỏi cụ thể.
AI xuất sắc trong việc viết nháp postmortem (tóm tắt, trình bày timeline, soạn action items) nhưng root cause cuối cùng luôn cần kỹ sư con người xác nhận trước khi công bố chính thức.
Giới hạn cốt lõi của AI: không có quyền truy cập hệ thống trực tiếp, thiên vị về nguyên nhân phổ biến, không tự phân biệt correlation/causation tốt hơn con người, và tin tuyệt đối vào dữ liệu bạn cung cấp dù dữ liệu đó có sai lệch.
Luôn xác minh giả thuyết của AI bằng ít nhất hai nguồn dữ liệu độc lập, và hỏi ngược "dữ liệu nào sẽ chứng minh giả thuyết này sai" trước khi công bố root cause với sự cố có tác động lớn như thanh toán hay dữ liệu khách hàng.
Retry logic thiếu circuit breaker/jitter là nguyên nhân kinh điển của retry storm và cascading failure khi traffic tăng đột biến — luôn là một trong những giả thuyết đầu tiên cần kiểm tra với sự cố latency tăng đột ngột trong dịp cao điểm.