复盘不是写总结，是找失分项

很多团队的架构复盘开成了表彰会：列一堆做了什么，最后写一句“整体运行平稳”。但pg直营站在参与互动社区项目的复盘时发现，真正有价值的复盘只回答一个问题：延迟是从哪一段漏出去的。为此，pg直营站解决方案栏目把常见失分项排成榜单，按排查优先级从高到低排列，团队可对照自查。

这份榜单面向已完成一轮改版、准备做架构复盘的团队。pg直营站建议复盘会控制在两小时内，前半场对榜单逐条打分，后半场只讨论失分项的行动项，避免跑题。

五种常见失分项榜单

以下五项按“出现频率 × 修复收益”排序，pg直营站提醒团队不要跳过任何一项：

  • 采集端与分发端时钟不同步：埋点时间戳各算各的，延迟数据对不上账，排查时互相甩锅。验收口径是全链路统一时间源，偏差控制在毫秒级。
  • 边缘节点回源策略粗放：热门内容没有就近缓存，回源链路一长，端到端时延立刻超标。验收口径是回源比例与热点命中率双达标。
  • 客户端解码与渲染排队：解码线程被日志或动画抢占，画面到了却出不来。验收口径是渲染队列积压时长设上限并纳入监控。
  • 互动消息与媒体流争抢带宽：社区弹幕、礼物动画和视讯流挤在一条通道，弱网下一起卡。验收口径是消息通道与媒体通道分离，各自限流。
  • 告警阈值拍脑袋：阈值定得太松，用户投诉了系统还显示正常。验收口径是告警必须绑定用户侧指标，而非只看服务器负载。

pg直营站特别提示，第三项和第四项常被误判为“用户网络问题”，实际是客户端资源调度问题。复盘时把真机日志拉出来对照，比看监控大盘更有说服力。团队可用安卓与苹果 iOS 客户端分别复现，确认是否两端一致。

把失分项转成行动清单

打分之后，pg直营站建议按“一周内可改、一月内可改、需排期”三档归档：

  • 一周内可改：告警阈值调整、日志降级、渲染队列上限，改动小、见效快，复盘当周就排。
  • 一月内可改：通道分离、回源策略调优，需要联调与灰度，纳入下个迭代。
  • 需排期：时钟同步改造涉及多系统，单独立项，但必须在复盘纪要里写明负责人与验收口径。

行动清单要和八项体验指标挂钩，例如通道分离完成后，卡顿率应同步下降。pg直营站的经验是，复盘纪要里每一条行动项都带一个数字目标，下次复盘才有对照物，否则一年后还在讨论同一个问题。

复盘文化的两个小习惯

第一，复盘会先看用户侧数据再看系统侧数据，顺序反了容易自我安慰。第二，每次复盘留十分钟给一线值班同学，他们最清楚哪个环节半夜响过告警。pg直营站认为，架构复盘的价值不在于文档多厚，而在于失分项有没有被真正认领。榜单只是起点，把榜单变成团队每期的固定动作，延迟治理才不会退潮。