WEEK 19
2026 W19
个人复盘
2026.05.10 – 2026.05.16
目标：发布新版本 → 卡在 QA，未达成
这周的核心三件事
1
独立处理了客户系统宕机事故
周三下午客户系统挂了，从发现到恢复用了 1 小时。一个人扛下来——定位、修复、回滚、通知客户，没升级、没让老板介入。因此避免了更大的客户投诉和 SLA 违约风险。
应急响应
2
写了 10 个 PR 并全部合入
保持了 W19 的代码产出节奏。大部分是功能迭代和 bug 修复，虽然版本发布被 QA 卡住了，但「我该写的部分」都写完了，也因此给下周的发布清空了代码阻塞项。
工程产出
3
读完了《非暴力沟通》
在两次客户会议上尝试了「观察 — 感受 — 需要 — 请求」四步框架。其中一次明显缓和了客户的不满——对方从「你们怎么搞的」变成了「那我们现在怎么做」。因此确认这个方法在真实工作场景中有效。
个人成长
卡点 & 学到的
卡点 / 不顺
版本发布卡在 QA。周初目标是发布新版本，到周五还在 QA 手里。周一的测试环境部署晚了半天，QA 资源被另一个项目抢走，我中间等了两天才问进展——没有主动 push，这是我的问题。
周三宕机暴露了监控盲区。客户先发现的，不是我们先发现的。宕机 1 小时对 SaaS 来说太长了，告警阈值调得太松。
5 次客户会议里至少有 2 次是「被拉着开了个会但没产出」。时间被切碎了，周三故障后尤其明显，下午基本废了。
学到的
版本发布不能「交给 QA 然后等」。需要每天问一句进展，至少知道 blocker 在哪。下次周一就对齐，把测试用例优先级排好，不让资源被抢。
客户系统监控要加一条实时 uptime 告警。PagerDuty 或等价的方案，目标是客户发现之前我们先知道。
《非暴力沟通》里「区分观察和评判」在故障场景尤其有用。客户暴躁时先说「我理解你现在的感受，我们看到了问题」，比辩解有效得多。
会议需要更明确的议程和退出条件。没产出的会，下次直接说「我这边同步完了，先下线写代码」——没人会怪你。
复盘三问
最自豪的一件
周三故障处理。一个人扛下来的感觉很好——从 panic 到冷静排查，再到恢复服务、给客户发总结邮件，全程没有呼叫救援。这种「我能搞定」的确认感，是这周最大的正反馈。
最想反悔的一件
周一周二没跟进 QA。明知版本发布是 W19 的 top priority，却因为「我已经做完了」就心安理得地等了 48 小时。如果周一就 push，可能周三前就能出结果，W19 就能 close 这个目标。
重来一周我会改
周一下午就找 QA 对齐，把 W19 版本的测试用例拆成「必测」和「可延后」两档，确保核心路径周三前跑完。另外，周三故障之后应该给自己放一小时的假，而不是硬撑着开下午的会——状态差的时候开的会，效果也差。
下周计划
-
1
推动版本发布，周二前拿到 QA 结果。SMART: 周一下午 3 点跟 QA 站会，把阻塞项列出来，周三下班前必须出 go/no-go。
-
2
给客户系统加一条实时 uptime 监控告警。SMART: 周四前完成 PagerDuty 集成，验证至少 1 条告警规则能正常触发。
-
3
把《非暴力沟通》四步框架写成一个 cheatsheet 贴显示器上。SMART: 周末前做成一张 A5 卡片，塑封或贴在工位，每次开会前扫一眼。
私房话
这周说实话有点累。周三处理完故障，晚上回家坐在沙发上什么都不想干，手机也不想看。有一种「我已经把今天的勇气用完了」的感觉。
但回头翻 commit log 和日历，这周其实做了不少事——10 个 PR、5 场客户会、一本读完的书、一次独立应急。如果只看周三那一天，会觉得这是个很糟的星期；但如果拉长到七天，其实还行。
最大的不爽不是故障，而是版本没发布。那种「我已经做完了我该做的部分，但事情就是卡在别人那里」的无力感，比写代码难多了。下周我得改这个——不是去催别人，而是让阻塞更早暴露出来。这是我的问题，不是 QA 的问题。
给未来的自己：如果有一天你回头看这一周，别只记住那个宕机的下午。记住你一个人搞定了它。记住你忍住了没跟暴躁的客户吵。记住你看完了一本书而且真的用了。这些才是 W19 真正留下的东西。