解读

国内互联网/金融/运营商对性能缺陷“零容忍”，复盘会常由测试负责人主持，开发、运维、DBA、架构、产品、项目经理全员到场。面试官想确认两点：

1. 你是否能把“现象—根因—改进”闭环写进模板，让跨部门同事一眼看懂并落地；
2. 你是否能把“可复用资产”沉淀下来，避免换一批人又踩同样的坑。
   因此，答案必须体现“模板即流程”的思路：字段设计=角色协同=后续追踪，而不是简单罗列标题。

知识点

1. 5W2H 与 STAR 在性能场景的映射：What(场景)、Who(角色)、Where(环境)、When(时间)、Why(业务目标)、How(执行手法)、How much(达标阈值)。
2. 缺陷根因分类：代码、配置、资源、架构、数据、流程六维，对应 CAPA（纠正预防措施）。
3. 国内主流协同平台：Confluence+Jira、腾讯TAPD、飞书多维表、阿里云云效，模板字段需可直接导入这些平台生成工单。
4. 合规要求：央行《金融科技应用风险专项规范》、工信部《分布式系统性能测试指南》均要求“复测报告编号+责任人+关闭时间”可审计。
5. 可复用资产：脚本、数据、监控大盘、熔断阈值、巡检SOP，必须写清“存放路径+命名规则+版本号”，否则下次找不到等于没写。

答案

我给团队定的“一页式复盘模板”含10大要素，已跑通20+大版本，重复缺陷率从18%降到3%，可直接落地：

1. 复盘概览
   报告编号、业务线、紧急度（P0-P3）、复盘日期、下次复测日期，方便审计和OKR追踪。

2. 场景快照
   用一句话STAR法描述：在什么业务场景、什么数据量级、什么并发下，哪项指标未达标。附基准版本与对比版本，杜绝“口说无凭”。

3. 量化结果
   只放三项：峰值TPS、99RT、错误率；再给出SLA红线。让管理层5秒看懂差距。

4. 监控证据链
   按“应用—缓存—DB—网络”四层贴图路径，统一命名：{IP}{时间}{指标}.png，存Git LFS，保证半年后还能回溯。

5. 根因分析
   先打标签：代码/配置/资源/架构/数据/流程，再写“因为…导致…”的因果链，最后给证据（火焰图、SQL执行计划、GC日志片段）。

6. 影响范围
   列出受影响业务、用户量级、资金风险、监管风险，方便运维判断是否需要热修复或降级。

7. 纠正措施（CA）
   每条措施写“动作+责任人+Deadline+验证方式”，禁止写“优化代码”这种无法验收的描述。

8. 预防措施（PA）
   必须落到“流程”或“工具”：如“把慢SQL扫描加入MR门禁”、“把缓存命中率<90%加入告警”、“把该场景脚本纳入每周自动化回归”。

9. 复测结果
   给出复测报告编号、结论、性能提升百分比，并由测试+开发双签字，形成关闭条件。

10. 经验资产
    脚本路径、数据构造命令、监控大盘JSON、熔断参数、SOP链接，全部写清“仓库+目录+版本号”，并打Tag随版本发布。

把模板做成Confluence Blueprint，字段缺失无法提交；Jira建立“性能缺陷”子任务类型，复测未完成不允许关闭迭代。通过“模板=门禁”的机制，把“复盘”变成“无法跳过”的流程节点，自然避免重复犯错。

拓展思考

1. 如果下次故障由“业务突发营销活动”触发，模板如何扩展？——增加“业务输入”章节，记录活动方案、流量预估、降级预案，提前把业务变量纳入性能基线。
2. 面对金融级“两地三中心”架构，模板是否需要独立“容灾”字段？——需要，把RPO/RTO、跨城延迟、数据一致性校验结果写进量化结果，防止只看单中心指标。
3. 模板长期演化：每季度组织“复盘复盘会”，统计Top3重复根因，反向把对应检查点固化到CI/CD门禁，实现模板自我迭代。