2022-12-05 13:14 浏览量:491
故事的开头,是一位业务部门的同事找到我们,咨询了一个经典问题:
「需求方经常说我们做的报表看起来数据不准,有什么办法吗?」
为了解释这个问题,我以我们团队在数据质量管理中积累下来的方法,为他写下四行字:
数据质量期望——业务需求想要把数据质量保障到什么样的标准
数据质量测量——怎么评估数据质量水平的高低、是否达到标准
数据质量保障——为提升质量水平,达到质量期望,具体的保障实施动作和内容
数据质量运营——如何通过数据化运营,提高保障的成果与效率
这四行字,概括了我们在数据质量管理执行中的理论大纲。
01 关于数据质量期望
「你在需求沟通时,了解对方的数据质量期望么?」
数据质量是由需求定义的。它没有绝对的对与错,只有定性、定量的标准。我们需要事先了解需求方的质量期望,才能与需求方就「质量达标」的标准达成细节上的共识。
我举个例子,我们经常遇到一种情况:我们明知这份数据存在问题,但依然选择使用它。只要我们把这份数据的问题点抛出,下游消费者理解并接受它的问题、并做好兜底方案即可。这种方式,是通过主动降低质量期望来避免数据事故。
要如何知晓对方的质量期望?
最好不要直接询问:「你需要怎样的保障,怎样的监控?」因为需求方不一定是专业的开发人士,他们可能会遗漏,或者,他们无法用运维语言来表达。
于是我们设计了以下三组问题,在日常的数据需求沟通中,主动向需求方提问确认:
第一组:获得质量期望
第二组:评估可能存在的风险
当然,对于风险的评估,上述问题只是冰山一角。
第三组:与需求方沟通一下业务知识认知
这些问题很容易想当然,同时,也是相当致命的。比如说,需求方需要视频稿件的CTR,恰巧我们早已做好了CTR指标,便直接提供给他使用了。但如果这位需求方理解的CTR和我们的统计口径不一致呢?他得到了他期望的数据吗?
质量期望的沟通,在什么时机最合适?
从实践中我们得出,获得质量期望的最佳时机,是在需求沟通阶段。这个阶段还没有大量资源、人力的投入,发生需求变故的成本最小。
所以我们将质量期望的信息收集安排在需求预审环节。把上述三类问题组织成一个预审沟通模板,要求每一位参与需求预审的数据开发人员养成询问质量期望的习惯。
经此沟通,能够让需求方有准确的业务认知,能够建立我们与需求方、上游业务研发、下游消费者之间的质量期望与风险知晓的共识,能够引导需求方降低质量期望,或引导业务研发消除当前的风险。
02 关于数据质量测量
「你知道怎么评估数据质量水平的高低,判断质量是否达标吗?」
既然数据质量没有绝对的对与错,只有可定性、定量的标准。那么表达数据质量水平的方法,就是与标准所包含的规则做测量对比。可以称之为数据质量测量。
既然要测量,我们首先要先设计测量规则。
规则的设计,决定了我们在质量测量过程中——能够发现哪些问题、不能发现哪些问题。我们首先要明确哪些问题的暴露是需要的,哪些是不需要的。我们将规则拆分为基础规则与个性化规则。
基础规则:指可对大部分数据通用的规则。如,条数为0监控、主键重复监控等,这类异常在大部分场景都应当被暴露。
基础规则通常无须自行设计,平台会提供统一的配置,来保障基础规则的覆盖。
个性化规则:指每一份数据根据实际用数情况,做针对性设计的规则。
个性化规则要从质量期望中去提炼。我们用一个真实(经脱敏修饰)的质量期望案例来说明这个提炼过程。
我们有一份源自客户端上报的【业务对象曝光与点击日志】,它的下游消费者众多,我们从消费者的质量期望中合并出一份最高期望(取规则的并集,且每个规则取要求最高的一项)。
【业务对象曝光与点击日志】质量期望与规则提炼实例:
总得来说,质量期望一般来源于(1)场景和对象的特殊性、(2)业务流程和数据生产逻辑、(3)数据标准、(4)数据自身特点、(5)某时某地的业务背景。所以我们的测量规则也基于这些提炼。
规则又可以拆解为两个部分:规则指标、规则判定。
比如【传输丢失率<某阈值】这条规则中,【传输丢失率】为规则指标,【<某阈值】为规则判定。
规则指标分类及举例:
规则判定分类:
设计好规则,还要明确在什么时机做质量测量。
我们把测量的时机分成三种,对应三种测量形式:初始化测量、验收测量、生产测量。
为了让这三种时机融入到团队的开发工作中,我们将这三个时机与数据需求管理的流转步骤挂钩,要求需求流转的交付内容中包含三次测量的执行报告。
初始化测量:
发生在数据需求的预审期、或开发前期。以一次性数据探查的形式,探查一份新数据、或老数据的新属性存在的潜在风险。这些风险可能是业务逻辑中的缺陷、或者未做标准化定义的隐患等,所以我们除了关注数据自身的测量结果,还要关注文档等上游信息输入。
初始化测量,帮助我们规避低质量数据输入到我们的生产链路。
验收测量:
发生在数据需求的验收期。不但全新的数据需要全方位验收,变更需求同样需要。根据我们的事故经验,超过90%的数据质量事故,是由变更发布带来的。
验收测量,帮助我们规避变更发布带来的数据异常。
生产测量:
生产测量的配置和首次执行发生在需求交付前观察期,日常执行发生在交付后的日常生产过程中。稳定的生产链路理论上有稳定的质量,但不可忽视偶发性的不稳定问题,比如底层组件异常、调度服务异常等。
生产测量,帮助我们规避外界偶发性问题影响数据的产出。
有了质量测量,我们可以随时通过规则的统计与判定,来长期监控质量水平、及时发现异常问题。
03 关于数据质量保障
「如果质量测量的结果不理想,要做哪些事才能提升质量水平?」
数据质量水平的提升,是经由数据质量保障的实施才能实现的。这个「保障」具体要保障什么?做哪些事来保障?
质量测量的规则是根据质量期望来设计,那么相应的,测量报告中的指标异常,也要能告诉大家哪一条期望没有达标。我们应当先针对未达标的期望来做保障的实施。
我们延续上一小节的【业务对象曝光与点击日志】,来说明发现问题后保障实施的过程。
在质量期望中,对f5这个属性有这样一条期望描述:
而在真实的数据中,测量报告表明f5属性的质量并没有达到期望。即,f5这个属性存在大量空值。
由于这是数据源日志,尚未经过ETL处理,可认为f5属性异常发生在数据上报和数据集成接收的环节,再加上其他判断条件,我们基本认定这个异常发生在上报环节。通过对异常数据的统计分析,进一步定位到这个异常只发生在某几个页面,其余页面都是正常的。接下来,我们就要做两项实施来修复异常且使它不再发生:
根据埋点异常修复流程,由客户端修复这个上报异常。
在测试环节补充这条测试用例,在后续的变更中,可通过该测试用例阻截异常。
在这个case中:
首先,我们有质量测量来监控数据的质量水平;
其次,我们有异常修复流程来修复它,解决本次问题,也有变更流程来测试它,避免同样的问题再次发生;
接着,我们有明确的责任制度,在上述流程中,各个责任方知晓自己的执行责任;
最后,我们的各个责任方,有拨冗相应的人力工时资源,来将这个埋点的监控、修复、测试工作落地。
我习惯将质量保障的实施分为四个类别,缺一不可。
1)流程保障
为何要有流程?
在安全管理领域,极度注重标准操作流程的制定和实施。飞机乘务员关闭舱门的操作、化工厂转运化学品的操作,都有严格的标准操作流程,而这些流程强大到能够保障人员的生命安全。可见,流程保障是一种强有力的保障措施。
在我们的流程保障中,需要重点讲述的是数据准入、发布变更这两个流程。
数据准入:
曾经发生过一个case,有一个新的产品A,在做埋点上报开发时,直接copy了另一个产品B的上报脚本,导致用以区分这两个产品的关键属性appid上报为同一个值,从而影响了产品B的核心指标。
在这次case的复盘中,我们提出,任由一个新产品、新场景随意接入既存的重要埋点,显然是不合适的。因此我们建立了数据准入流程。
准入流程的建立依赖几个必要条件:
经由准入流程分配的属性值,须做双向绑定验证(上报侧与埋点管理侧)。
经由准入流程分配的属性值,上报时须由SDK或公共组件(如播放器)收敛,不可由接入业务自行填值上报。
未经准入的数据,须能限制上报、或在上报后被限制接收、使用。
最终实际的流程参考下图:
发布变更:
超过90%的数据质量事故是由变更带来的,这是我们在聊验收测量时提到的一个事实。为此,发布变更必须有一套流程来保障。
如图所示,是一个简略的埋点变更的流程。
2)制度保障
运维责任制度是必须存在的。它定义了每一份数据、每一类组件、每一项服务的责任归属认定逻辑,能够确保任何数据在各个环节都有其质量保障的执行负责人。
运维分级制度也是必须存在的。它定义了每一份数据在全生命周期的各个环节,能得到哪一层标准的保障,且高等级数据一定能获得比低等级数据更稳定的保障。
我们对分级的定义,会从以下几个方面来评估:
涉及财报、营收、资损
涉及业务重大决策
涉及线上功能服务与用户体验
涉及有关部门监管内容
事故处罚制度是可以选择的制度(当然我们推荐它存在)。它定义了异常发生后的过失成本。
我们的事故定义、事故等级的划分,会从多种指标来评估:
资损的量级
客诉的量级
数据异常的幅度和时长
数据的可恢复性
数据异常的影响PV、UV
数据修复的人力工时成本
此外,在新的周期,我们也吸收了前几个周期的经验,除了消极压力的处罚制度,还考虑增加积极鼓励的奖励制度。
3)监控保障
我们认为监控保障包含了四项工作:
1. 监视、监听:长时间观察数据生产的健康情况;
这个健康情况,包含大数据组件的稳定性、大数据资源使用用量、任务运行状态、数据产出结果的校验等。
2. 测量:即我们在前文所指的质量测量;
3. 督促:促使相关责任方去处理问题;
通常,通过群消息推送、企业微信告警、电话告警等不同等级的信息通知来实现。
4. 纠偏:辅助执行问题的处理。
告警原因分析、任务阻断等功能,就属于这一类。
4)资源保障
资源保障指的是针对不同运维等级的资源倾斜,且这里的资源包含两重意义:
物理资源:CPU和内存,磁盘容量,带宽等。
人力工时资源:测试、校验的执行排期、运维响应速度、异常修复顺序等。
继续回到【业务对象曝光与点击日志】这份数据,来看一看我们对它的上下游链路实施了哪些保障。
把上述四类保障建设完成,那么我们的数据质量保障体系就完成了从「0」到「1」的过程。
04 关于数据质量运营
「单份数据可以人工跟进保障实施情况,但成千上万的数据,怎么知道每一份数据该怎么保障、有没有实施、实施效果好不好呢?」
我们来思考一下执行质量保障措施的目的是什么。质量保障的实施,其目的在于规避异常,它需要在每个上游环节中:
发现异常
拦截异常
处理异常
由此可见,它的基础标准应当是:
确实发现了异常
确实拦截了异常
确实处理了异常
以达到最终节点规避异常的目的。
我们继续思考,谁,在什么时机,通过什么方式,消耗多少人力工时,会造成多少损失?
任何一个人都希望能规避所有异常,且即使真的发生异常,也能在造成损失前处理完毕。那么,我们要进一步提升它的标准:
在有限的测试、验收工时里最大程度拦截异常发布
上游比下游先一步发现异常
异常的告警最早通知到能处理这个异常的人
在人力介入之前,系统率先自动拦截异常
处理人员以最短路径、最小成本处理异常
不让同样的问题再一次重复发生
可以看到,质量保障的基础要求体现在通过保障避免损失,进阶要求体现在保障效率的提升。我们由此得到数据质量运营的两个运营目标:
降低事故损失
提升保障效率
作为数据工作者,我们理所当然要通过数据化运营来实现我们的目标。为此,我们设计了质量运营的指标体系。
我们的质量运营指标体系是基于我们的治理指标体系建设模型,包含:治理目标、治理策略、治理评估。下述为我们最近几个周期质量运营指标体系的概图。
其中,治理策略矩阵代表着,我们需要对生命周期中每一个环节的事前、事中、事后,都去制定保障标准、设计执行策略的规则,以及提供相应的工具能力。
(一)制定保障标准
标准是一个执行参照。
告诉所有人怎样算达标,按什么流程最安全……等等。标准统一了我们在质量保障执行过程中的意识和行为,杜绝责任推诿。
保障标准来源于各类质量期望的汇总,其中公共的、通用的部分,应对所有用户公示。它可能会经历谈判、妥协,最终达成意见的一致。它包含并不限于:
服务SLA标准
测试/监控覆盖标准
异常响应时效标准
资源划分标准
标准需要分级,不同运维保障等级,映射到不同的保障标准值。
团队的人员精力、物理资源都是有限的,要在有限范围内保障最重要的部分。
比如我们在前文提到的【业务对象曝光与点击日志】这份数据,依照运维分级制度,属于P0级。作为P0等级的数据,其数据时效保障为1分,响应时效要求是15分钟。而其他P1级甚至更低等级的数据,时效标准就会逐级放低。
(二)设计执行策略的具体规则
规则是标准展开的细则。
比如我们将事件处理标准流程展开,当异常发生时,我们的标准流程是先止损、再修复。基于这个标准,假设【业务对象曝光与点击日志】这份数据在某个环节出现异常,我们的细化规则是:
该环节的异常处理人必须直接收到告警,并在10分钟内响应;
10分钟内无响应,会上升至技术LD;
收到告警后,先通知到能够做灾备切换的人员(最快、最短链路),再将信息同步到该项目的应急响应群;
异常处理人说明异常原因,评估修复耗时;
根据该项目的灾备启动条件,灾备执行人判断是否启动灾备方案;
修复问题;
切回主方案。
这些规则使大家远离误操作,提高执行效率。也能让一个新人快速上手,降低执行难度。
另外从中我们也看到,这项事件处理规则有几个前提规则:
需要有全链路的监控覆盖
需要有灾备方案
需要有告警升级机制和通知机制
(三)提供工具能力
目前,我们已经积累了一批工具,用于数据生命周期的各个环节,提供自动执行能力。
比如监控告警工具、基线管理工具、DQC管理工具、指标异动工具、运维操作工具等,可以在公众号的其他文章中获得详细了解。
策略的执行需要评估效果好坏,以随时调整策略规则、或改进工具能力。如何评估策略的执行效果,就需要我们做评估指标的设计。
评估指标的设计原则,一是必须从第一层目标指标拆解而来,二是能够暴露出现状中的问题点,三是能够评估治理策略的执行进度,四是能够评估效果收益。这样的设计,使运营工作处于一个从指标中发现问题-问题解决后体现在指标中的持续性循环中,不断逼近、最终完成目标。
在前面的质量运营指标体系概图中,我们先将目标指标(事故次数)拆解为与事故直接相关的事故定级指标。
定级指标的值幅度降低,则事故次数就降低。
那么,接下来我们要拆解定级指标的降低与哪些执行指标相关,这一步拆解,要与策略规则直接绑定。因为无法评估效果的规则,在执行上很难有说服力,不容易落地。
测试覆盖率,与测试用例的实施绑定;监控覆盖率,与监控配置的实施绑定;修复人时,与运维工具的提效优化绑定……诸如此类。
其中概念较抽象的指标,如监控覆盖率这一项,它贯穿全生命周期,且在不同环节有不同的口径定义。
比如在数据开发环节,我们要求所有P0级数据必须配置三大类监控告警(失败、延迟、内容异常),且告警形式为电话告警 + 部门内升级。这些配置规则缺一不可,只有全部完成,才计作这份数据的“监控覆盖完成”。通过每周审计监控覆盖率,来控制我们在数据开发环节的监控保障实施。
在这里,有一个告警有效性运营的真实案例,能够解释我们的数据化运营方式。
先介绍一下背景,我们认为,监控不是越多越好,且需要随着业务变化及时调整监控规则。告警太多,会干扰执行人员的运维关注点,对告警产生麻痹或抵触情绪,乃至错过关键告警,降低异常发现率。
我们首先要确定在这个运营事项中,一个可持续的循环是怎样的。根据前面提到的指标-问题-标准-实施循环图,我们简单列举一下这个循环:
指标:需要有指标来暴露无效、未响应、缺失、越级等告警缺陷
问题:将这些缺陷视为一个待治理的问题
标准:定义有效告警的标准
实施:制定降低告警缺陷、提升有效告警的策略
为了便于理解,我先解释一下告警效果的定义。
有效告警:命中规则,且确实命中异常,同时能促使处理人员快速介入。
无效告警:命中规则,但并未命中异常,通常是规则配错、或业务活动导致。
未响应告警:命中规则,且确实命中异常,但无人响应,或响应人员无法、无权介入处理。
越级告警:数据运维等级较低,但配置了标准较高的告警形式,使起夜次数虚高。
误告:未命中规则,工具误触发告警。
告警缺失:发生异常,但无告警。
第一步,制定告警反馈机制,督促owner对告警进行分级反馈。
第二步,建设告警模块的元数据主题数仓,制作告警缺陷统计报表,给出待治理明细清单,推送治理信息给清单中的数据owner。
第三步,制定有效告警标准、执行细则,督促owner给出治理优先级,确定短期长期治理目标。细则参考下图:
第四步,定期审计告警缺陷,更新待治理清单,分析执行进度、治理余量、新增量的情况,逐步完成头部高优的部分。
第五步,工具优化方案提出,阻截不合理新增量、自动化处理长尾余量部分。
经过一个季度的运营,我们的告警缺陷从每周2000+例降低到100例以下,极好地改善了异常遗漏、夜间起夜、告警反馈成本等问题。
至此,我们的数据质量管理理论大纲就基本讲述完毕了。而我们的数据质量管理必然还没有做到头,还有非常多的细节场景有待我们围绕这个大纲去逐个解决。
下个季度、下一年,我们会不断有新的质量话题拿出来讨论。也许可以扩展广度,比如将质量运营覆盖到链路更前端的业务数据;也许可以下探深度,对埋点、任务链路等具体的保障对象做专题展开。相信我们能做得更好。
来源:数据社