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

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

背景:线上抽奖活动,奖品价格与需求不符,产生了资损;

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

  • 需求评审环节,对需求的理解以及测试点的分析,没有与产品做沟通确认。
  • 验收测试环节,没有发现需求描述和功能实现之间的诡异之处,错过二次挽救机会。
  • 线上发布之后,测试缺乏质量巡检手段,也没有参与故障应急响应,质量保障机制存在不足。

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

  • 后续涉及到“钱”的需求,要与产品和研发三方达成一致理解。
  • 梳理和“钱”有关的功能点,整理对应的防资损验证测试用例集,每次变更迭代都进行验证,持续更新该测试集。
  • 建立线上定时巡检机制,对核心业务链路和场景进行不定时巡检,查漏补缺。
  • 推动线上应急响应机制落地,测试深度参与,做好事前监控,事中响应验证,事后复盘主导工作。

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

  • 需求描述评审不严谨:推动产品详细阐述需求设计,特别是和“钱”有关的场景。更进一步则是需求管理和需求质量的问题,这需要进一步做好质量内建(需要上层管理者支持,否则无法治本)。
  • 线上的业务监控缺位:除了技术监控,应该进一步完善业务监控体系。
  • 应急响应机制不完善:特别是测试没有参与其中,质量无法闭环,存在缺口,需进一步完善线上的质量巡检手段。
  • 应急手段和预案不足:上述案例中回滚并没有解决问题,仅是暂时止损而已。后续改进中还应该进一步丰富线上应急预案,比如:增加业务开关,发现异常暂时关闭该业务的用户请求(类似降级)。
  • 缺少故障复盘定级规范:一方面需要制定合理的故障复盘流程,另一方面需要对线上故障定级有明确的说明(按照影响范围、持续时长、损失大小来定义故障等级),让团队每个人引起重视。

 

最后,聊点延伸话题。

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

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

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

posted @ 2024-08-02 14:36  老_张  阅读(26)  评论(0编辑  收藏  举报