解读

面试官真正想验证的是：

1. 你是否理解 Chaos 实验（Litmus）与性能测试结果的关联——混沌故障往往是性能劣化的“根因”之一；
2. 你是否能把实验结论自动沉淀到企业现有缺陷流程（Jira）里，形成“发现→记录→分派→复测→关闭”的闭环，而不是让报告躺在对象存储或邮箱里；
3. 你是否熟悉国内主流 DevOps 工具链（阿里云 ACK、腾讯云 TKE、Jira 中国版、企业微信/飞书、钉钉审批），能给出可落地的“人、工具、流程”方案，而非纯理论。

知识点

1. Litmus 架构：ChaosCenter Portal、ChaosAgent、ChaosExperiment CR、ChaosResult CR、Probe 机制。
2. ChaosResult 包含 .status.experimentStatus.verdict（Pass/Fail/Stopped）与 .status.probeSuccessPercentage，可作为“是否创建 Jira Bug”的判据。
3. Jira 中国版（Atlassian 托管在阿里云）REST API v3 认证方式：Basic Token、API Token、OAuth2（国内常用前两种）。
4. 国内公司常用的“事件总线”：阿里 EventBridge、腾讯云 TDMQ、自研 Nacos + RocketMQ；用来解耦 Chaos 与 Jira，避免直接调用失败导致实验状态丢失。
5. 闭环关键字段：
   • 自定义字段“ChaosEngine”记录实验名；
   • 标签“performance-blocker”方便看板过滤；
   • 关联字段“Performance Test Task”指向性能测试 Jira 主任务；
   • Fix Version 与 Sprint 字段保证排期可见。
6. 国内合规要求：日志与审计必须留痕 6 个月以上，因此集成侧需要把 ChaosResult JSON、Jira Issue Key 统一落到公司日志中心（如阿里云 SLS、腾讯 CLS）。

答案

给出一个在国内金融场景落地过的“三阶段”方案，全部基于开源或已备案 SaaS，符合等保与审计要求。

阶段一：结果透出

1. 在 Litmus ChaosCenter 里启用“通用 Webhook” 通知，Payload 模板固定为：
   {“experiment”: “{{ .Name }}”, “verdict”: “{{ .Verdict }}”, “probeSuccessPercentage”: “{{ .ProbeSuccessPercentage }}”, “cluster”: “{{ .Cluster }}”, “time”: “{{ .Time }}”}
2. 将 Webhook 地址指向公司统一事件网关（阿里 EventBridge 公网入口已做域名备案与 HTTPS 证书）。

阶段二：事件处理

1. EventBridge 配置过滤规则：verdict=Fail 且 probeSuccessPercentage<80%，才向下游投递；避免抖动误报。
2. 投递目标选择“函数计算（FC）”或“云原生 Serverless（Knative）”实例，函数内完成：
   a) 调用 Jira REST API 创建 Bug：POST /rest/api/3/issue，project.key=PERF，issuetype.name=缺陷，summary=“[Chaos] {{.experiment}} 探测成功率仅 {{.probeSuccessPercentage}}%”，description 里嵌入 ChaosResult 的原始 JSON 链接（OSS 预签名 URL，有效期 7 天）。
   b) 将返回的 Issue Key 写回 EventBridge 事件，同时写入阿里云 SLS（project: chaos-audit，logstore: jira-bug），方便审计。

阶段三：闭环验证

1. 开发修复后，在 Jira 里流转到“待复测”状态；
2. Jira 通过 Automation 触发 Jenkins Pipeline，Pipeline 调用 Litmus CLI 重新运行同名实验；
3. 实验结果再次进入 EventBridge，函数内查询先前创建的 Jira Issue，若 verdict=Pass，则添加评论并自动关闭；若仍 Fail，则重新打开并 @ 责任人；
4. 企业微信/钉钉群机器人通过 Jira Webhook 同步消息，实现 IM 通知。

整个链路全部脚本化（Terraform 编排事件总线与函数计算，Helm 安装 Litmus），可在 30 分钟内一键重建，满足国内“灾备切换+审计”双重要求。

拓展思考

1. 灰度场景：如果实验仅针对 5% 流量金丝雀集群，需在 Jira Issue 里增加“灰度范围”字段，防止开发误操作全量修复。
2. 性能基线联动：把 Prometheus 性能基线（P99 RT、CPU 涨幅）也作为 Probe，实验失败但基线未突破阈值时可降级为“Warning”而非 Bug，减少噪音。
3. 多租户隔离：集团下有多个子公司共用同一套 Jira，需在函数里根据 cluster 标签自动选择 project.key，避免 A 子公司的实验跑到 B 子公司的看板。
4. 合规留痕：EventBridge 与函数计算日志默认保存 7 天，需要配置 OSS 转储+日志审计服务，保留 6 个月以上，满足国内等保 2.0 三级要求。