














去年部门里很重要的OKR 就是线上问题SLA达成率,背后的核心就是需要近可能快速响应商家的咨询和反馈,服务好金主爸爸,在当前的世道下,只有服务好客户才能活下去。在H1的减员增效后,就没剩下几个技术支持了,客满、服务同学的问题大多都需要研发承接,需要安排值班的同学来承接这部分线上问题,对于研发的吞吐量是一定的损失,但好的一面也是有的,研发可以更近距离的了解自己产品的线上质量和收集商家的咨询反馈。
为了达成线上问题及时处理,首先需要和开发一起约定一套线上问题处理和复盘的流程。
首先开发前后端需要各安排一个值班同学专门处理线上问题,虽然线上bug都是由开发直接处理的,但是测试也需要有一个值班介入线上问题处理,主要做的事情:
在关注问题处理时效的时候,我通过写了一个机器人定时扫描快过期的问题进行通知值班和测试(不得不说飞书机器人挺好用的),来督促值班人员及时处理问题以及让测试/tl 介入关注问题无法及时解决的原因。

在初期的一段时间内,测试人员通过介入和观察超期的jira,发现了jira无法及时处理的主要原因,以及指定了相应的对策:
在每周结束,值班人员收集和统计线上问题,跟研发tl和产品一起过一下线上问题,主要关注的是如何减少线上问题和提高问题处理的效率:
通过上述的机制和措施,研发侧问题处理的规范性和效率有了一定提高。虽然站在研发侧角度看问题处理的耗时不长,但站在端到端的角度来看,还是有一些线上问题超期,很多是前置流程里的客满、技术支持同学耗时过长,导致线上问题转到研发侧时可能已经超时了。所以线上问题治理需要确保各个环节效率都比较高,目前系统已有的杀器,通过推荐算法推荐一些相似的问题来帮助客满同学快速找到答案

另外研发这边也给客满、技术支持同学提供一些排查工具,即将问题定位排查的能力赋能给他们,进一步问题解决的速度和释放研发排查的人力。
业务域的问题处理达标率从H1的85%提升到了H2的95%,在这个过程中沉淀了研发aciton和产品优化项70+,帮助业务域的线上问题下降10%
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。