滴滴客服业务属于强运营的业务,运营的核心抓手是指标数据。这些指标有的是为了达成战略目标的OKR指标,有的是为了达成与合作伙伴结算的结算指标,做好数据稳定性,对整个客服业务的运营来说至关重要。
解读数据故障治理建设目标
实时类指标,包括进线量、排队量、接起率、触达率等指标。滞后类指标,包括解决率、关单率、升级率、满意度、服务质量等指标。
过去两年,为了保障业务的连续性,我们投入了比较多的精力在稳定性建设上。整体建设分为三个阶段:
第一阶段:以故障为中心的稳定性建设,围绕系统故障的事前、事中、事后系统性落地了一系列的工程能力、流程机制、建设方法论;围绕降发生、降影响,最终故障数和故障时长大大降低。
第二阶段:以业务为中心的稳定性建设,围绕业务特点,从业务的实际情况出发,成立横向跨组织专项团队,解决业务与技术衔接部分存在的稳定性问题,实现技术对于业务连续性保障的全局最优。
第三阶段:常态化能力建设,随着稳定性建设工作的不断深入,组织上对于稳定性团队工作的要求越来越多,已经从单纯的围绕技术稳定性的工作,升级到了覆盖安全合规、降本增效等相关工作内容。为了避免运动式的工作投入,让稳定性工作实现低成本、可持续,会围绕完善自动化工具提效,建设可持续的运营机制,最终塑造团队的稳定性工作文化。
我们去年完成了系统稳定性建设的第一阶段工作,形成了对于实时类指标的保障。数据稳定性建设属于第二阶段的工作,它的工作内容和业务特点强相关,主要解决业务滞后类指标的生产和使用过程中的稳定性问题。系统稳定是数据稳定性的基础,只有做好了系统稳定性,才有实现数据稳定性的基础。
为了做好数据稳定性建设,我们先做了以下几件事。
制定数据故障定级标准,做数据分级
我们有1000+指标,由于资源有限,不可能面面俱到,制定数据故障定级标准,其实是回答了我们要保什么样的数据,以及保到什么程度。清晰的定义了什么样的影响是故障、什么样的故障影响对应什么级别、什么样的指标对稳定性要求更高。
经过这一步,我们明确了数据分级需要保的指标类型包括:OKR指标、结算指标、其他指标。其中OKR指标涵盖了工作效率维度、服务质量维度、安全维度和风险维度。
目标拆解
有了数据指标定级标准后,我们就需要考虑如何做好数据稳定性保障这件事了。
稳定性建设工作需要三方共建(研发、数仓、数据),三方共同服务业务,需要彼此分摊一定的故障比例,将稳定性目标拆解到三方头上,让大家劲往一处使。
明确打法
目标拆解之后,需要明确相关打法和节奏,包括完成目标的具体原则、计划和动作。具体计划涵盖事前、事中、事后环节,目标是降低故障数和降低故障级别。相应的方法论是围绕:目标体系、人员意识、人员素质和系统工具。
很多技术同学对做系统稳定性有比较多得了解,但数据稳定性建设在原则上还是有非常多的不同的,简单介绍几条。
数据故障最看重什么?
先说答案,是时间。影响时间有两点:数据影响总量和数据修复时长。
区别于系统可用性故障