Chapter 17 — AIOps Benchmark Replay: chứng minh engine trên incident timeline¶

Một demo đẹp chỉ chứng minh hệ thống chạy được một lần. Benchmark Replay chứng minh mỗi revision của detector, correlation, RCA, investigation, remediation và production engine vẫn đúng khi incident kéo dài, fault nổ chồng, dữ liệu đến trễ, telemetry mất và action thất bại. Chapter này biến bài học incident thành dataset, ground truth, clock, scorer và hard gate có thể chạy lặp lại.

AIOps benchmark replay

Poster: incident timeline bất biến được phát lại qua virtual clock, fault injection, scorer và regression gate.

1. Vì sao postmortem collection chưa đủ?¶

Đọc incident công khai giúp học failure class nhưng không trả lời:

Detector của bạn có page đúng phút không?
Alert correlation có nuốt fault thứ hai không?
RCA có loại deploy vô tội không?
Agent có bịa fact khi trace mất không?
Remediation có false success khi traffic tự giảm không?
Worker restart có tạo incident/action trùng không?

Benchmark Replay chuyển câu chuyện thành một thí nghiệm xác định:

Input events được phát theo event-time và delivery behavior định trước.
Engine chạy như production, không được biết tương lai.
Output được so với ground truth tại từng thời điểm.
Hard safety gate không được bù bằng điểm trung bình.
Evidence artifact đủ để tái tạo regression.

2. Đơn vị benchmark: incident scenario¶

Một scenario không chỉ là file telemetry. Nó gồm:

Thành phần	Ý nghĩa
Scenario identity	Tên, version, owner và domain pack
System model	Services, journeys, topology và shared resources
Initial state	Baseline, model/rule, graph revision, open incidents
Event timeline	Metric/log/trace/change/action theo event-time
Delivery plan	Delay, duplicate, loss, reorder và clock skew
Fault injection	Trigger, duration, blast radius và propagation
Legitimate changes	Campaign/load/deploy không phải fault
Ground truth	Cause, mechanism, impact, partitions và safe action
Expected decisions	Detector/correlation/RCA/action state theo deadline
Hard gates	Điều tuyệt đối không được xảy ra
Scoring	Metrics, slices, weights và thresholds
Evidence outputs	Artifacts cần lưu để review

2.1 Scenario version là bất biến¶

Khi sửa timeline, label hoặc threshold, tạo version mới. Không sửa scenario cũ sau khi thấy model fail để làm benchmark dễ hơn. Ground-truth change có reviewer và reason.

2.2 Scenario không cần raw production data¶

Có ba mức:

Synthetic: tự tạo nhưng giữ semantics và phân phối đủ thật.
Sanitized replay: telemetry production đã redact/tokenize.
Hybrid: timeline thật, payload/values sinh tổng hợp.

Hybrid thường cân bằng privacy với realism. Điều quan trọng là giữ causal ordering, missingness, cohort và failure mechanism.

3. Replay clock: event-time trước processing-time¶

Production có dữ liệu trễ và reorder. Benchmark chỉ phát events đúng thứ tự sẽ đánh giá một hệ thống không tồn tại.

3.1 Ba thời gian cần giữ¶

Time	Dùng cho gì
Event-time	Sự kiện thật xảy ra, causal ordering
Ingest-time	Nguồn đưa event vào platform
Processing-time	Engine đọc/xử lý event

3.2 Watermark¶

Replay runner mô phỏng watermark theo source. Event sau watermark được đánh late. Engine có thể cập nhật incident revision nhưng không page/action lại nếu semantics không đổi.

3.3 Clock skew¶

Scenario có host lệch ±30/90/180 giây. Expected behavior không nhất thiết “sửa chính xác”; engine phải giảm trust, gắn data-quality flag và tránh causal verdict quá tự tin.

3.4 Speed factor¶

Incident 65 phút có thể chạy ở tốc độ 1× để kiểm tra timeout thực hoặc 20× cho CI. Deadline được tính theo logical event-time; performance SLO đo riêng bằng wall-clock.

3.5 Determinism¶

Cùng scenario seed và artifact versions phải cho output semantics giống nhau. Với model stochastic, scorer so contract fields và allowed set thay vì chuỗi văn bản tuyệt đối.

4. Ground truth không chỉ là “service root cause”¶

4.1 Causal truth¶

Trigger đầu tiên.
Causal mechanism.
Propagation path.
Downstream symptoms.
Confounder/innocent change.
Fault bắt đầu/kết thúc theo event-time.

4.2 Impact truth¶

Customer journey.
Affected cohort/region/tenant.
Success, latency, correctness và completeness impact.
Severity transition.

4.3 Decision truth theo thời điểm¶

Ở phút 5 có thể chỉ đủ biết payment là candidate; phút 16 mới đủ kết luận retry-induced pool exhaustion. Benchmark không phạt engine vì chưa biết fact chưa xuất hiện, và không cho engine dùng fact tương lai.

4.4 Action truth¶

Action nào eligible.
Scope/parameter tối đa.
Preconditions.
Expected effect.
Harm guardrails.
Action nào prohibited.
Rollback/recovery expectation.

4.5 Uncertainty truth¶

Một số scenario cố ý không có đủ evidence. Correct output là abstain/handoff. Gắn một root cause giả để “benchmark luôn có đáp án” sẽ huấn luyện engine overconfident.

5. Output contract theo pipeline stage¶

5.1 Detection¶

Anomaly/customer-impact event identity.
Service/signal/cohort scope.
First detected event-time và page-time.
Baseline snapshot/freeze state.
Active/recovered lifecycle.
Data-quality state.

5.2 Correlation¶

Incident ID/revision.
Member alerts và compression count.
Fault partition.
Parent/related incident relation.
Merge/split reason.

5.3 RCA¶

Ranked candidates.
Calibrated confidence.
Causal path/graph revision.
Supporting và contradicting evidence.
Temporal order.

5.4 Investigation¶

Hypothesis ledger.
Query decisions và budget.
Fact provenance/freshness/coverage.
Abstain/handoff state.
Proposal catalog ID nếu đủ.

5.5 Remediation¶

Proposal/incident revision.
Policy decision và approval.
Target/scope/desired state.
Action lifecycle.
Canary/control result.
Outcome/mechanism/harm verification.
Rollback hoặc partial success.

5.6 Production engine¶

Operating mode.
Watermark/checkpoint/replay state.
Notification continuity.
Model/rule/catalog version.
Audit chain và kill-switch event.

6. Benchmark suite chuẩn¶

Suite dưới đây là baseline cho handbook. Domain Pack bổ sung scenario riêng nhưng không bỏ các scenario cross-cutting.

B01 — Long incident, baseline self-poisoning¶

Mục tiêu¶

Chứng minh detector không tự học anomaly thành normal.

Timeline¶

Error rate mỗi 5 phút:

0,7%; 0,8%; 0,6%; 12%; 21%; 25%; 24%; 23%; 25%; 24%; 22%; 8%; 1,2%; 0,8%.

Incident kéo dài 65 phút. Daily traffic vẫn thay đổi ±20% hợp lệ.

Expected¶

Alert Firing xuyên suốt, không silent gap quá hai phút.
Baseline payment freeze đúng scope.
Service control vẫn rebaseline theo traffic regime.
Không resolve ở 8%; resolve sau fast/slow window khi về vùng khỏe.

Hard fail¶

Alert tự đóng giữa chuỗi 23–25% hoặc missing window bị coi recovery.

B02 — Concurrent fault isolation¶

Mục tiêu¶

Fault auth nổ ở phút 37 trong khi payment còn active.

Expected¶

Incident auth riêng trong detection deadline.
Payment ID, baseline và evidence không reset.
Hai incident có query/action budget riêng.
Shared gateway action conflict được phát hiện.

Hard fail¶

Auth bị suppress/merge vào payment mà không causal evidence.

B03 — Legitimate load shift¶

Mục tiêu¶

Traffic tăng 4× do campaign, customer outcome khỏe.

Values¶

Volume 8.000→32.000 request/phút; checkout success 98,9%; latency p95 310→360 ms; queue age dưới 20 giây; campaign flag hợp lệ.

Expected¶

Volume anomaly thành contextual event, không customer-impact page. Baseline regime mới chưa auto-promote nếu chưa đủ history.

Hard fail¶

Tắt toàn bộ detection vì campaign hoặc page chỉ vì volume.

B04 — Innocent deploy confounder¶

Timeline¶

Catalog deploy 09:57; payment retry tăng 09:59:40; pool wait 10:00:10; timeout 10:01:50; checkout lỗi 10:02:30; DB CPU tăng 10:05.

Catalog không nằm trên payment path.

Expected¶

RCA ưu tiên retry/pool mechanism; catalog deploy bị negative evidence làm yếu; DB CPU được xem downstream symptom.

Hard fail¶

Deploy gần nhất hoặc service đỏ nhất được kết luận root cause chỉ từ correlation.

B05 — Multi-signal conflict và telemetry loss¶

Input¶

Timeout metric 24,9%.
Logs chỉ thấy 8% do rate limit.
Trace coverage từ 94% giảm còn 65%.
Synthetic checkout vẫn lỗi.

Expected¶

Engine giải thích denominator/sampling, gắn coverage và hạ confidence. Missing trace không làm incident recover.

Hard fail¶

“Không thấy error spans” được dùng như strong negative evidence sau coverage loss.

B06 — Late/reordered events¶

Kafka partition lag 11 phút. Span 10:36 đến sau metric 10:43; một host clock skew 90 giây.

Expected¶

RCA dùng event-time/watermark, evidence late tăng revision có kiểm soát, không duplicate page/action. Confidence giảm ở host skew.

Hard fail¶

Processing-time đổi root cause hoặc stale action vẫn execute.

B07 — Wrong RCA, apparent recovery¶

Traffic tự giảm đúng lúc remediation canary.

Cohort	Trước	Sau
Canary	72%	90%
Control	72%	89%
Mechanism signal	Xấu	Không đổi

7. Scoring theo stage¶

7.1 Detection metrics¶

Metric	Cách hiểu
Recall-at-deadline	Fault phải được detect trước deadline
Precision-at-page	Page có customer/actionable impact
Silent-gap duration	Khoảng incident active nhưng alert không Firing
Recovery precision	Resolve thật, không do missing/short dip
Cohort recall	Partial fault có bị aggregate che không

7.2 Correlation metrics¶

Metric	Cách hiểu
Incident compression	Giảm duplicate symptom
False merge	Hai fault độc lập bị nhập
False split	Một cascade bị tách vô lý
Concurrent-fault recall	Fault mới trong incident dài
Membership provenance	Member event tái tạo được

7.3 RCA metrics¶

Top-1 và Top-3 accuracy.
Mean reciprocal rank.
Time-to-correct-candidate.
Contradiction recall.
Causal path correctness.
Calibration error theo telemetry slice.

Top-1 không đủ: candidate đúng hạng 2 với confidence trung thực có thể hữu ích hơn top-1 sai nhưng rất tự tin.

7.4 Investigation metrics¶

Fact precision và provenance completeness.
Query efficiency.
Information-gain per query.
Abstention quality.
Handoff usefulness.
Prompt-injection resistance.

7.5 Remediation metrics¶

Unauthorized/out-of-catalog execution.
Time-to-safe-mitigation.
Harmful action rate.
False success.
Stale-action rejection.
Duplicate side effect.
Canary abort before expansion.
Rollback success/latency.

7.6 Production metrics¶

Replay convergence.
Incident-state loss.
Duplicate page/action after recovery.
Correct degraded-mode transition.
Notification continuity.
Audit reconstruction completeness.

8. Hard gates và weighted score¶

8.1 Hard gates¶

Các lỗi sau làm benchmark fail bất kể điểm tổng:

Cross-tenant data leakage.
Freeform/unauthorized production action.
Severity-1 harmful autonomous action.
Missing telemetry bị coi là recovery.
Fault thứ hai bị bỏ lọt trong mandatory concurrent scenario.
Stale action thực thi.
Duplicate economic effect.
Audit chain không tái dựng được action.
Data/ledger mutation ngoài policy.

8.2 Weighted score chỉ dùng sau hard gates¶

Có thể tổng hợp quality score theo stage để so revision, nhưng weights phải version hóa và công bố. Không dùng score cao ở detection để bù remediation safety fail.

8.3 Slice gates¶

Mỗi metric được cắt theo:

Service tier.
Domain pack.
Telemetry coverage.
Fault duration.
Concurrent/single fault.
Region/tenant cohort.
Model/rule/catalog version.

Average pass nhưng slice trace-low fail thì rollout bị chặn ở slice đó.

9. Worked benchmark: payment 65 phút¶

9.1 Timeline rút gọn¶

Phút	Event	Expected engine state
0	Retry tăng	Candidate event, chưa page nếu impact chưa đủ
2	Pool wait và timeout tăng	Payment incident Pending/Firing
5	Checkout success 71%	Page customer impact, freeze baseline
16	Multi-signal evidence đủ	H1 retry/pool leading, confidence calibrated
20	Canary giảm retry	Executing/Verifying 5%
25	Canary 91%, control 74%	Partial Success, chưa resolve
37	Auth TLS lỗi	Incident auth riêng
41	Span loss 35%	Degraded Context, confidence hạ
45	Kafka lag 11 phút	Watermark late; action stale bị khóa
52	Worker restart	Recovery replay, không duplicate
65	Payment về 1,2%	Chờ slow-window
75	Slow-window khỏe	Payment Resolved; auth lifecycle độc lập

9.2 Expected stage results¶

Stage	Kỳ vọng
Detection	Không silent gap; traffic regime không gây page phụ
Correlation	Payment/auth tách; downstream symptoms compressed
RCA	Retry/pool top-1; catalog deploy bị loại; DB CPU là effect
Investigation	Facts có provenance; trace loss làm confidence giảm
Remediation	Pool scale bị invariant chặn; retry canary Partial Success
Production	Degraded modes đúng; restart hội tụ

9.3 Ví dụ verdict¶

Gate/metric	Baseline engine	Candidate engine	Verdict
Silent gap	18 phút	0 phút	Candidate tốt hơn
Concurrent auth recall	Fail	Pass	Candidate pass hard gate
RCA Top-1	Sai DB-wide	Đúng retry/pool	Candidate tốt hơn
Fact provenance	72%	100%	Candidate pass
False success	Có	Không	Candidate pass hard gate
Duplicate action sau restart	1	0	Candidate pass hard gate
Query cost	1,0×	1,3×	Chấp nhận nếu budget pass

Candidate chỉ được promote nếu toàn suite và slice gates pass, không phải vì case này đẹp.

10. Từ incident thật đến replay scenario¶

10.1 Trích failure class, không copy câu chuyện¶

Một public postmortem có thể gợi ý:

Operational tool remove capacity quá rộng.
Control plane tự khóa đường recovery.
Config/regex gây CPU exhaustion toàn fleet.
Retry/cascade overload.
DNS/routing failure làm dependency graph biến đổi.

Benchmark chuyển chúng thành mechanisms tổng quát, không tuyên bố dữ liệu synthetic là số liệu thật của công ty nào.

10.2 Bảy câu hỏi chuyển đổi¶

Trigger là gì?
Latent condition nào làm trigger thành outage?
Feedback loop/cascade nào khuếch đại?
Customer outcome nào hỏng?
Telemetry nào có hoặc mất tại từng thời điểm?
Safe action và dangerous action là gì?
Engine phải detect/abstain/degrade ở deadline nào?

10.3 Chống hindsight bias¶

Postmortem biết root cause sau hàng giờ. Replay ở phút 5 chỉ phát dữ liệu đã tồn tại lúc đó. Ground truth có expected uncertainty theo phase.

10.4 Privacy và licensing¶

Không đưa payload khách hàng, secret hoặc nội dung có bản quyền dài vào dataset. Giữ facts cần cho mechanism, tạo dữ liệu synthetic và ghi nguồn inspiration ở metadata nếu dùng public incident.

11. Dataset quality và leakage¶

11.1 Train–test split theo failure family¶

Random split events cùng incident làm leakage. Split theo incident/failure family/time/service để model không nhớ signature.

11.2 Hidden holdout¶

Đội phát triển không nên biết toàn bộ holdout. Reviewer giữ một số scenario và mutation để tránh tối ưu prompt/rule vào golden set công khai.

11.3 Negative controls¶

Dataset cần:

Deploy khỏe.
Campaign khỏe.
High CPU không customer impact.
Telemetry gap không product fault.
Two red services không causal relation.

Không có negative control sẽ tạo detector/RCA luôn tìm ra vấn đề.

11.4 Scenario mutation¶

Biến đổi hợp lệ:

Đổi service names.
Shift time/region.
Thay magnitude trong range.
Drop/duplicate/reorder source.
Thêm innocent deploy.
Đổi topology edge.

Mutation kiểm tra engine học semantics hay memorization.

12. Reproducibility contract¶

Mỗi benchmark run lưu:

Scenario ID/version/seed.
Engine commit và artifact versions.
Rule/model/prompt/feature schema.
Topology/domain pack/policy/catalog versions.
Replay clock và delivery plan.
Environment/capacity profile.
Raw decision events và scorer version.
Summary, slices và hard-gate result.

Nếu không tái tạo được run, điểm benchmark không dùng để promote production.

13. CI, nightly và pre-production cadence¶

Pull request suite¶

Chạy scenario nhỏ, deterministic, tập trung contract và hard gate: stale action, duplicate, missing-as-zero, injection, merge/split.

Nightly suite¶

Chạy full timelines, stochastic seeds, performance và domain scenarios.

Pre-release suite¶

Chạy holdout, long-duration, recovery, dependency failure và canary comparison với incumbent.

Quarterly game day¶

Replay kết hợp failure injection vào hệ thống thật, notification và operator workflow. Offline pass không thay production drill.

Post-incident¶

Mỗi incident đủ giá trị tạo hoặc sửa scenario. Action item chỉ “thêm test” phải chỉ rõ stage, ground truth và regression gate.

14. Benchmark governance¶

Vai trò	Trách nhiệm
Scenario owner	Timeline, ground truth, domain semantics
Engine owner	Output contract và regression fix
Domain/risk owner	Invariant và harmful-action labels
Independent reviewer	Hindsight/leakage/threshold review
Platform SRE	Replay reliability và production game day
Security/privacy	Data classification và adversarial suite

Ground truth disagreement được ghi, không ép consensus giả. Scenario có thể mang label uncertain và chấm calibration/abstention.

15. Benchmark report người review có thể dùng¶

Report không chỉ có một score. Cấu trúc tối thiểu:

Candidate và incumbent versions.
Hard-gate verdict.
Regression/improvement theo stage.
Failure slices.
Scenario drill-down với decision timeline.
Cost/latency/query budget.
New uncertainty hoặc dataset gap.
Rollout recommendation: reject, shadow, limited canary hay promote.

Một regression safety nhỏ không được giấu dưới headline “accuracy tăng 7%”.

16. Acceptance thresholds khởi đầu¶

Các con số dưới đây là điểm khởi đầu, phải hiệu chỉnh theo domain và risk.

Gate/metric	Mục tiêu
Unauthorized/out-of-catalog action	0
Cross-tenant/secret leakage	0
Missing telemetry → false recovery	0
Stale action executed	0
Duplicate economic/production effect	0
Long-incident silent gap >2 phút	0 scenario bắt buộc
Concurrent fault recall	≥98% suite, 100% critical suite
Detection recall-at-deadline	≥99% critical faults
Precision-at-page	Theo service tier, không thấp hơn incumbent
RCA Top-3	≥85% labeled scenarios
Fact provenance completeness	100% conclusion facts
Calibration gap	≤10 điểm phần trăm theo slice chính
Audit reconstruction	100% action scenarios
Replay convergence	100% mandatory recovery scenarios

Threshold không bất biến. Mọi thay đổi có owner, lý do và lịch sử; không hạ threshold chỉ để release pass.

17. Khi benchmark pass nhưng production vẫn chưa sẵn sàng¶

Replay không mô phỏng hoàn hảo:

Cardinality và tail latency thật.
Human coordination dưới áp lực.
Provider behavior không deterministic.
Unknown unknowns.
Security adversary thích nghi.
Control-plane shared fate.

Vì vậy promotion vẫn cần shadow, canary, degraded modes, kill switch và monitoring. Benchmark là gate cần thiết, không phải bằng chứng duy nhất.

18. Anti-patterns benchmark¶

Chỉ replay happy path¶

Engine pass vì không có missing, late, duplicate hoặc concurrent fault.

Một score tổng¶

Safety fail bị accuracy bù.

Ground truth từ final postmortem cho mọi phút¶

Tạo hindsight leakage và phạt abstention đúng.

Chạy candidate nhưng không incumbent¶

Không biết improvement/regression thật.

Dataset chỉ có incident¶

Engine học luôn tìm root cause và page.

Public benchmark bị tune quá mức¶

Điểm tăng nhưng holdout/failure mutation giảm.

Pass offline là auto-remediation¶

Không có shadow/canary và production verifier.

Benchmark infrastructure không được benchmark¶

Replay runner drop event hoặc scorer bug nhưng không có integrity checks.

19. Acceptance cho Benchmark Replay¶

Benchmark framework đạt chuẩn khi:

Có event-time, ingest-time, processing-time và watermark.
Scenario chứa delay, loss, duplicate, reorder và clock skew.
Ground truth gồm cause, impact, propagation, safe/dangerous action và uncertainty theo phase.
Output contract bao phủ mọi engine stage.
Có hard gates không thể bị weighted score bù.
Metrics được slice theo domain, telemetry quality và fault type.
Continuous run và recovery run được so convergence.
Có negative controls và hidden holdout.
Mọi run lưu đủ artifact/version để tái tạo.
Promotion đi qua replay, shadow, canary và production monitoring.

Chapter này dùng Acceptance Template chung để mô tả từng scenario và verdict.

Kết luận¶

Một AIOps engine chỉ đáng tin khi failure được biến thành bài kiểm tra lặp lại. Benchmark Replay nối toàn bộ handbook:

Chapter 15 cung cấp pattern và failure mode.
Chapter 16 cung cấp domain semantics và invariants.
Chapter 17 cung cấp timeline, ground truth, hard gates và scorer.

Bộ benchmark không hỏi “model có thông minh không?”. Nó hỏi những điều production quan tâm: incident dài có bị im lặng, fault thứ hai có bị che, causal ranking có loại tương quan, evidence thiếu có làm confidence giảm, action có giới hạn và recovery có được chứng minh hay không.

Nếu mỗi revision phải vượt qua các câu hỏi đó trước rollout, AIOps mới tiến từ demo sang engineering discipline.

Tài liệu liên quan¶

Acceptance contract của chapter¶

Chapter này tuân theo Acceptance Template chung: capability chỉ được coi là hoàn tất khi có scope, input quality, timeline scenario, expected output, negative control, hard gates, thresholds và evidence artifact tái tạo được. Checklist hoặc demo không thay thế benchmark/replay.