我们是如何做数据稳定性保障的？

滴滴客服业务属于强运营的业务，运营的核心抓手是指标数据。这些指标有的是为了达成战略目标的OKR指标，有的是为了达成与合作伙伴结算的结算指标，做好数据稳定性，对整个客服业务的运营来说至关重要。

解读数据故障治理建设目标

实时类指标，包括进线量、排队量、接起率、触达率等指标。滞后类指标，包括解决率、关单率、升级率、满意度、服务质量等指标。

过去两年，为了保障业务的连续性，我们投入了比较多的精力在稳定性建设上。整体建设分为三个阶段：

第一阶段：以故障为中心的稳定性建设，围绕系统故障的事前、事中、事后系统性落地了一系列的工程能力、流程机制、建设方法论；围绕降发生、降影响，最终故障数和故障时长大大降低。

第二阶段：以业务为中心的稳定性建设，围绕业务特点，从业务的实际情况出发，成立横向跨组织专项团队，解决业务与技术衔接部分存在的稳定性问题，实现技术对于业务连续性保障的全局最优。

第三阶段：常态化能力建设，随着稳定性建设工作的不断深入，组织上对于稳定性团队工作的要求越来越多，已经从单纯的围绕技术稳定性的工作，升级到了覆盖安全合规、降本增效等相关工作内容。为了避免运动式的工作投入，让稳定性工作实现低成本、可持续，会围绕完善自动化工具提效，建设可持续的运营机制，最终塑造团队的稳定性工作文化。

我们去年完成了系统稳定性建设的第一阶段工作，形成了对于实时类指标的保障。数据稳定性建设属于第二阶段的工作，它的工作内容和业务特点强相关，主要解决业务滞后类指标的生产和使用过程中的稳定性问题。系统稳定是数据稳定性的基础，只有做好了系统稳定性，才有实现数据稳定性的基础。 

为了做好数据稳定性建设，我们先做了以下几件事。

制定数据故障定级标准，做数据分级

我们有1000+指标，由于资源有限，不可能面面俱到，制定数据故障定级标准，其实是回答了我们要保什么样的数据，以及保到什么程度。清晰的定义了什么样的影响是故障、什么样的故障影响对应什么级别、什么样的指标对稳定性要求更高。

经过这一步，我们明确了数据分级需要保的指标类型包括：OKR指标、结算指标、其他指标。其中OKR指标涵盖了工作效率维度、服务质量维度、安全维度和风险维度。

目标拆解

有了数据指标定级标准后，我们就需要考虑如何做好数据稳定性保障这件事了。

稳定性建设工作需要三方共建（研发、数仓、数据），三方共同服务业务，需要彼此分摊一定的故障比例，将稳定性目标拆解到三方头上，让大家劲往一处使。

明确打法

目标拆解之后，需要明确相关打法和节奏，包括完成目标的具体原则、计划和动作。具体计划涵盖事前、事中、事后环节，目标是降低故障数和降低故障级别。相应的方法论是围绕：目标体系、人员意识、人员素质和系统工具。

很多技术同学对做系统稳定性有比较多得了解，但数据稳定性建设在原则上还是有非常多的不同的，简单介绍几条。

数据故障最看重什么？

先说答案，是时间。影响时间有两点：数据影响总量和数据修复时长。

区别于系统可用性故障，数据故障最看重的是数据回溯修复的时