Engineering weekly: delivery, quality metrics and risks

A Chinese engineering team's weekly update, made from release notes, an issue-tracker export, a quality-metrics workbook and dependency notes: delivery status, quality against targets, defect trends, an editable system diagram showing where this week's changes landed, risks and next week's priorities. Week 2 was made from week 1's deck plus the new material. Illustrative data.

What it was given

Week 2: last week's deck, plus this week's release notes and dependency notes (Markdown), issue export (CSV) and quality metrics (Excel).

With these instructions 这是下一周（W44）的研发周报。第一个来源是上周（W43）已经发出的周报：保持它的页面顺序、版式、图表类型和系统结构图，用本周的发版记录、问题导出、质量指标和依赖手记（其余来源）更新所有数字、交付、缺陷、风险和下周优先级；系统结构图要体现对账服务已拆分。在概览之后增加一页“相比上周”：哪些指标回到目标内、上周的风险与依赖进展、新增风险。云栈支付平台研发组技术周报（W44），由研发负责人向技术与业务负责人汇报。把发版记录、问题导出、质量指标和依赖手记整理成简洁的研发周报：版本交付（本周发布内容与迭代完成率）、上周 10/23 故障的后续措施、质量指标对比目标（可用性、P99 延迟、支付成功率、CI 通过率、覆盖率、缺陷逃逸，用原生可编辑图表或表格）、缺陷趋势（按严重度）、重点问题与负责人、外部依赖与风险、下周优先级；用一张可编辑的系统结构图说明本周改动发生在哪个服务。采用固定、可复用的周报结构：每周同样的页面顺序、版式和图表类型，下周只需更新数据与结论。用汇报人的口吻；数据均为虚构，含数据的页面标注“演示数据”，来源行写“来源：云栈研发组发版记录、缺陷系统与监控平台（演示数据）”。演讲者备注要帮助讲清本周的故事：先讲结论，再讲原因、影响和需要的决定或支持，不要逐字重复页面文字。

Download the .pptx79 KB Download week 43's deck Make a deck in this look

Free to download, no sign-in needed. Open it in PowerPoint and change anything.

Look: Dark Tech
Deck type: Technical Deep Dive
Images: No images
Slides: 11
Deck language: 中文 (简体)

Every slide, unedited

Click a slide to see it large.

1质量已回升，依赖闭环是下周主线

Speaker notes
各位好，本周我汇报的核心结论是，交付和质量都取得了进展，但还不能把运行风险视为已经解除。迭代完成率达到90%，五项质量指标回到目标内，接下来需要把这份改善落实为剩余问题关闭和跨团队依赖兑现。我会先说明交付与质量恢复的依据，再讲下周的优先级和需要大家协调的资源；本次汇报使用的均为演示数据。
2完成率达90%，运行质量同步回升

Speaker notes
先从交付和运行结果一起看，本周计划十项需求、完成九项，两次发布分别推进了服务拆分、缓存上线和时区偏差修复。与上周相比，五项质量指标已经达标，但覆盖率仍低于第四季度目标，所以我们要区分已经验证的改善和仍待完成的工作。
3相比上周：五项指标回归目标，风险转向依赖闭环

Speaker notes
把这些结果与上周对照，最明显的变化是，可用性、下单延迟、支付成功率、CI通过率和缺陷逃逸都回到了目标内，退款超时、舍入不一致和下单延迟问题也已关闭。覆盖率虽然提高到70%，距离第四季度至少75%的目标仍有差距。外部依赖从等待确认推进到了明确节点：证书已申请，数据库扩容窗口已确认，风控联调环境承诺11月4日交付。但渠道C签名失败和风控同步超时仍在处理中，证书生产更换距离到期只有一天，因此下周的重点是把承诺变成实际完成的结果。
4两次发布完成9项需求，交付完成率达90%

Speaker notes
这些改善背后，先看本周具体交付了什么：计划十项完成九项，完成率90%，仍有一项未完成。10月29日的版本把对账拆成独立服务，上线订单详情缓存，并修复批量退款超时和分账舍入问题。10月31日又通过热修复处理了对账文件时区偏差，因此本周交付既涉及部署边界，也涉及性能和业务正确性。我会继续用运行指标和缺陷变化验证效果，而不把两次发布完成当作验收终点。
5对账已拆为独立服务，订单缓存已上线

Speaker notes
其中，对账拆分需要单独说明，因为它改变的是实际部署边界，而不只是功能名称。对账现在通过消息队列接收支付消息，作为独立服务部署和扩容，不再留在支付服务内部；订单详情缓存也已经上线。但订单到风控仍然是同步调用，风控超时仍会影响下单，这部分风险没有随着对账拆分而消失。11月8日的新接口切换属于后续安排，不能算作本周已经交付的能力。
610/23回调修复已落地，本周可用性恢复达标

Speaker notes
明确了本周改动的边界，再回看上周故障，也需要把历史修复与当前问题分开判断。10月23日，回调重试缺少幂等键，叠加商户接口限流，导致约1.8%的支付通知延迟或重复，持续22分钟；这不是支付交易失败率。次日已经完成幂等修复并新增限流告警，历史故障已关闭，本周可用性也恢复到99.97%，超过99.95%的目标，但不能把整周改善全部归因于这一次修复。林岳目前与渠道方排查的退款回调签名失败是另一项新问题，仍需独立推进关闭，不能直接认定为旧故障复发。
7五项质量指标达标，覆盖率仍需提升

Speaker notes
因此，判断恢复是否成立，还是要看整组质量指标，而不只看故障单状态。运行侧，可用性从99.91%升至99.97%，下单P99从420毫秒降至330毫秒，支付成功率从98.9%升至99.3%，都回到了各自目标内。工程侧，CI通过率从91%升到95%，线上缺陷逃逸从三个降到一个，也达到目标，但这两项目前都处于目标边界。覆盖率从68%提高到70%，仍低于第四季度75%的目标；同时，上周P99关联大促预热场景，本周是缓存上线后的记录，后续还要持续观察，不能把周度改善理解为所有场景都已验证。
8下周从质量恢复转向风险闭环

Speaker notes
基于这些结果，下周我会把重心从推动质量恢复，转向守住恢复结果并关闭剩余风险。具体按缺陷收敛、依赖兑现和演练验证来组织工作，不用发版完成替代运行风险验收。
9P1降至2个，剩余问题均有负责人

Speaker notes
先看缺陷收敛，最重要的变化是未关闭P1从五个降到两个，而不是仅仅保持P0为零。本周新增十一个、关闭十九个，未关闭总数从四十二个降到三十四个，积压净减少八个。剩余两个P1中，林岳负责渠道C退款回调签名偶发失败，正在与渠道方排查；何川负责风控同步超时，当前等待11月8日的新接口。问题记录中的0.2%描述的是下单失败影响，不能直接从周度支付成功率中相减；这份重点清单也不代表全部未关闭缺陷。
10依赖已有时间承诺，证书更换缓冲仅一天

Speaker notes
这两个P1要继续收敛，离不开外部依赖兑现，而目前最紧的时间风险是证书更换。证书安排11月10日在测试环境更换、11月14日在生产更换，距离11月15日到期只有一天缓冲，所以申请提交并不意味着风险已经解除。风控组魏然已确认11月4日交付联调环境，需要衔接11月8日的新接口；数据库扩容则已确认11月12日凌晨两点到四点的窗口，但预案仍需演练。我请求大家支持这些节点的资源协调，同时继续推动渠道方排查签名问题，避免把日期承诺当作已经完成。
11请支持按四项优先级守住质量恢复成果

Speaker notes
围绕这些依赖，下周我会按四项优先级推进：先在11月10日前完成分库扩容预案演练，再按11月10日安排推进证书测试环境更换，持续收敛剩余两个P1，并衔接风控环境与新接口联调。请大家重点支持DBA演练、证书更换、风控环境和渠道排查的跨团队协调。我会用质量指标是否守住、两个P1是否关闭、依赖承诺是否兑现来复核成效，而不只检查动作有没有执行。本周证明了质量正在恢复，下周我们要把这份恢复变成更可持续的运行结果，谢谢大家。