如何优雅的应对线上故障？

知识星球有同学遇到了这样一个问题：

背景：线上抽奖活动，奖品价格与需求不符，产生了资损；

根因：团队惯例全链路人员都负责，新来的产品认为事故与其无关；

问题：内部为这个故障担责问题争论较大，作为测试负责人该如何应对？

这是很典型的一个职场案例，基本上每个技术同学在工作中或多或少都会遇到。往小了说，就是线上故障如何解决的技术问题；往大了说，其实是一个管理的问题。

这篇文章，分享一下我对这个案例的思考，以及给星球同学的一些建议。

首先，详细说一下这个故障的前因后果(关键部分模糊)，方便大家理解。

迭代背景：小版本快迭代，2 天研发 1 天测试。

业务场景：典型的抽奖业务，中奖获得优惠券。

问题根因：需求描述为中奖获得价格为 X 的优惠券(一句话需求，没有详细规则和数值定义校验)，研发和测试理解为 X 可叠加。需求评审时没有无人提出异议，验收测试时产品也没有发现这个问题，直至上线后抽奖数据异常才发现故障。

问题表现：已经进入抽奖页面的用户，即使紧急回滚依然可以中奖。

问题延展：公司默认规则为线上出故障，与之相关的整个链路人员都承担一定责任(均锅制)。新来的产品认为是研发和测试的问题，该由技术团队担责，产品不对本次故障负责。

故障修复：回滚至上一个版本，由于故障比较麻烦且范围较大，修复数据耗时一周。

以上就是这个线上故障的前因后果和详细内容，有经验的同学相信都知道该怎么做了吧。

接下来，聊聊从测试负责人的角度，该如何应对和处理这个线上故障。思路很简单，大体分为四步即可：

1、承认问题：出现生产事故，无论如何，测试作为质量保障最重要的一环，肯定逃不掉。与其抱着甩锅的侥幸想法，还不如主动承认问题，并想办法分析改进。

2、分析根因：承担责任没错，但职场公事公办，只承担自己该承担的责任，而非一肩挑，否则就真的成了背锅侠。从上述问题描述来看，这个线上故障中测试该做而没做好的主要有如下几点：

• 需求评审环节，对需求的理解以及测试点的分析，没有与产品做沟通确认。

• 验收测试环节，没有发现需求描述和功能实现之间的诡异之处，错过二次挽救机会。

• 线上发布之后，测试缺乏质量巡检手段，也没有参与故障应急响应，质量保障机制存在不足。

3、解决问题：故障复盘得到问题根因后，解决问题的方法其实显而易见。下面是几点 TODO 项：

• 后续涉及到“钱”的需求，要与产品和研发三方达成一致理解。

• 梳理和“钱”有关的功能点，整理对应的防资损验证测试用例集，每次变更迭代都进行验证，持续更新该测试集。

• 建立线上定时巡检机制，对核心业务链路和场景进行不定时巡检，查漏补缺。

• 推动线上应急响应机制落地，测试深度参与，做好事前监控，事中响应验证，事后复盘主导工作。

4、持续改进：上述的几个 TODO 项仅针对本次的线上事故，但仔细思考，你会发现这个故障暴露出了很多公司和团队存在的不足。我个人认为有如下几点需要高度重视和持续改进：

• 需求描述评审不严谨：推动产品详细阐述需求设计，特别是和“钱”有关的场景。更进一步则是需求管理和需求质量的问题，这需要进一步做好质量内建(需要上层管理者支持，否则无法治本)。

• 线上的业务监控缺位：除了技术监控，应该进一步完善业务监控体系。

• 应急响应机制不完善：特别是测试没有参与其中，质量无法闭环，存在缺口，需进一步完善线上的质量巡检手段。

• 应急手段和预案不足：上述案例中回滚并没有解决问题，仅是暂时止损而已。后续改进中还应该进一步丰富线上应急预案，比如：增加业务开关，发现异常暂时关闭该业务的用户请求(类似降级)。

• 缺少故障复盘定级规范：一方面需要制定合理的故障复盘流程，另一方面需要对线上故障定级有明确的说明(按照影响范围、持续时长、损失大小来定义故障等级)，让团队每个人引起重视。

最后，聊点延伸话题。

其实在职场中，对于更高层管理者来说，其实并不是特别关心谁来担责。他们更关心的是问题是否得到解决，后续是否还会出现类似问题，以及系统的控制风险能力能否得到提升。

工作难免出现纰漏，甩锅并非上策，主动承认问题并想办法解决问题，解决领导关心的问题，更能证明自己的价值。

职场中各种人都有，遇到不友好的同事，用流程规范和机制来保障工作开展，而非默契，这是每一个成熟职场人都应该明白的生存法则。