大数据运维的思考

一个企业的IT部门有业务和分析系统之分，这里就叫作OLTP和OLAP吧，IT部门一般算是业务部门的乙方，而IT部门的OLAP系统则是OLTP系统的乙方，因为OLAP系统处于OLTP的下游，一般可用性要求也不高，在传统企业内，CRM挂了是天大的事情，但同样的事情发生在BI等OLAP系统上则可以容忍很长时间。

传统企业的OLAP系统侧重对内支撑，除了必须的生产报表，不是必需品，更多像是奢侈品，有了可能好一点，没有影响也不大，比如精确营销。

随着大数据时代到来，企业对内数据化、精益化运营的要求越来越高， OLTP系统迫切需要OLAP的分析力，OLAP则需要嵌入到OLTP流程中发挥价值，两者相互渗透，我中有你，你中有我，OLTP与OLAP系统融合的趋势将越发明显。

同时，很多企业开始推进大数据价值变现， OLAP系统的地位就发生了根本变化，即OLAP系统越来越跟企业的直接价值创造相关，比如以前OLAP挂了，只要对内部客户做些解释也许就能消化影响，现在则会造成外部客户投诉，在阿里等企业大数据平台挂了肯定是不可想象的事情。

相信每年阿里双11前大数据平台运维的人会很忙，即使如实时大屏数字显示这类都需要强大的运维保障能力，而很多企业搞大型营销活动往往只关注OLTP系统的稳定，OLAP系统的运维人员会悠闲的多，这是数字化企业和非数字化企业的差距。

DT的趋势不会改变，无论是对内还是对外，打造一个健壮的大数据运维体系必不可少，由于OLAP与OLTP特点不一样，不是简单的照搬OLTP系统的运维方式就可以了，需要走出自己的路，这里分享一下笔者最近关于大数据运维的一些思考。

1、数据运维的组织架构

笔者经历过很多种BI运维组织架构，一种是开发和运维纵向一体化，BI没有交维动作，开发人员直接为维护负责，在长达6-7年的时间，笔者所在的BI团队就是这种模式，每个人按照业务条线进行划分，为这个业务条线的所有数据负责。

这种运维的效率其实是很高的，对于个人的锻炼价值也很大，既做需求，也做开发，更做维护，还要会交流，但其最大的问题就是缺乏标准，处理过程不透明，无法进行运维承诺，规模很难扩大。

第二种就是开发和运维完全分离，即横向切割，很多企业发展到一定阶段，系统越来越庞大，IT部门为了保障系统稳定制定了大量的标准化规范和流程，为了确保运维管理的集中高效执行，运维团队必须从开发中剥离出来，传统的观点认为开发和运维的职责存在天然的冲突，需要实现制衡。

从笔者的经历看，这种BI运维模式，从短期来看有效果，但长期看，存在着很多弊端，总体来讲，并不是最好的运维模式。

开发和运维要实现理想的交接，前提是交接的东西标准化程度要高，能够说得清楚，告诉你这个东西不会变形成其他东西，因此，越稳定，越容易封装的东西越容易交接，也即越容易维护。

OLTP很多时候是有这个特点的，但OLAP系统则完全不同，OLTP能清楚的说清楚提供了多少种服务，这些服务之间的关系如何，也即组合是可以穷举的，但数据的指标和维度是如此之多，相互之间的组合关系是无穷的，数据封装本身就是个伪命题，数据要交维需要的是对于业务和数据的深入理解，而不是告诉维护这张表交给你管理，数据维护最大的一类工作数据质量稽核需要代码级别的溯源能力。

因此，BI要实现理想交维往往只有一种可能，维护人员跟开发人员具备同样的技能，君不见核查数据问题基本是要开发参与的，只懂封装的数据运维人员除了能监控、告警、作业调度启停一下，可做的事情很少，因此，这种浅层次的运维到底有多大的价值？

随着数据交维的东西越来越多，运维人员会疲于奔命，很多沟通协调工作只是为了转述问题，一个问题的解决流程会拉的很长，这种运维模式满意度其实很难提升，同时运维人员的专业技能也很难获得增长。

第二种模式短期来看的确有效，因为其通过复用OLTP已有的机制、流程经验来获得价值，但长期是有致命缺陷的，其缺乏成长性，笔者一直认为运维是系统改进的核心驱动力，而不是由项目规划人员指东打西，很多时候，规划人员提出的东西跟解决运维的实际问题相差甚远，谁对这个系统有真正发言权呢？也许，专业能力最强的人员应该放到运维，而不是开发、规划或项目，如果稳定是企业最核心的工作的话。

第三种模式，笔者认为是均衡模式，维护要有的放矢，提倡中台类的系统、产品或数据进行交维，创新、探索、变动类的系统或数据不用交维，谁做的谁自己管去。

何谓中台类的系统或数据，就是企业真正沉淀下来的资产，成熟一个，纳入一个，比如基础平台、标签库、基础模型、融合模型等， 对于这类系统或数据，要求能提出合理的监控和告警要求并部署，运维团队要确保能自行处理大多数的故障，要能提出持续优化的建议，在未来系统改进上具有主导发言权。

2、故障分级和故障升级流程

运维最核心的就是故障管理流程，这里从应用分级，故障等级，升级流程等方面给出一个实践案例。

首先，数据运维涉及平台、应用和数据等管理对象，这些对象又可以根据重要性划分为核心、重要及一般三个等级，以下是一个划分示例，供参考：

每个企业应该根据自身实际划分等级，诸如BDI是基础平台，挂了数据就没法采集进来了，因此是最重要，这里划分为核心等级，数据类里有重要和一般之分主要是这些数据跟重要应用相关，必须划分为同一个等级，这个时候血缘分析就很重要，需在知道哪些数据跟这个应用相关从而判定这个数据的重要等级，体现的是数据和应用一体化的思想，数据变现事关直接收入，因此这里也划分为重要等级。

这张表的设计其实涉及了很多的原则，包括平台保障原则，收入优先原则，数据与应用一致性原则，表也是需要动态维护的，每次纳管一个平台、数据或应用，就应该同步更新。

其次，就到故障的具体分级了，我们将其划分为灰、蓝、黄、橙及红五个层级，首先要考虑时间维度，即异常的持续时间，以下是一个示例：

时间维度显然还不足以表示故障的严重程度，还需加上影响范围，这里特别增加了数据完整性这个影响指标，因为如果数据大范围的延迟，我们也认为是个较大的故障，即使没有一个投诉：

有了这些判定标准，维护在出现故障时就有章可循，可以根据这些标准明确最后的故障等级，然后依据不同的故障等级走不同的升级流程。

最后，是一个故障处理升级流程示例，明确了什么时刻需要做什么事：

以下是故障短信发送对象的一个示例，故障严重的时候，需要让老板知道：

3、数据采集保障

BDI（数据采集平台）当前采集接口2000多个，其中分钟/小时/月接口400多个，日接口1500个，日接口中重要接口300多个，采集接口涉及155个数据源（库），复杂度是比较高的，必须根据接口重要性及时间要求进行及时性保障。

以下是一个示例：2点前完成58%的“重要”级接口，4点前完成78%，6点前完成85%，8点前完成88%，12点前完成100%，鉴于集群计算性能时有波动，数据采集及时性保障目标设定各时段达成率90%以上，再不重要的接口，也要有个保障底线，用数据来说话，很多企业的数据几个月没采集都不知道，是由于缺乏明确的保障要求。

数据准确性方面也类似，每个数据接口采集设置数据量波动性检查、空值检查等。

4、数据作业保障

我们将大数据模型和应用数据的生成都纳入到DACP管理，包括融合模型、挖掘模型和数据应用大作业共计762个，其中月作业189个，日作业573个，日作业中重要级作业333个，根据作业重要性及时间要求进行及时性保障，其中4点前完成15% 的“重要”级作业，8点前完成65%，12点前完成85%。

针对重要应用涉及的作业，设置了应用结果数据的质量检查机制，以便提前发现问题，这里针对所有变现类应用的数据做了波动性等告警设置，做这个事情主要是由于对外变现出现了多次数据异动客户投诉的情况，因此尽量做到末雨绸缪，虽然不能解决所有问题，但能做一步算一步。

5、平台保障

基础平台牵一发而动全身，企业已经将大数据处理平台纳入私有云统一运维体系，其他诸如采集平台和数据管理平台，必须具备高可用，并能在短时间内进行容灾切换，这是运维的底线。

在大数据运营刚开始的时候，我们在数据管理上还是侧重于去解决采集、建模等问题，往前冲的比较多，在创新上花了不少心思，但随着运营深入，运维逐步成为数据管理最为核心的工作，因为如果没有这个健壮的“1”，所有的工作都将失去意义。

最后谈一点体会。

和我们走过的路一样，很多企业BI的运维仍然像个羞答答的姑娘，很多没有明确规范，比如每个接口的及时率要求，很多杂乱无章，比如不知道某个数据的影响大小，很多规范没有真正落地，比如投诉的统一归口，大多时候还是需求或开发人员去直面业务人员的问题。

虽然其实处理的效率也不错，但作为管理者心是不安的，因为很多投诉变得没有痕迹，很多问题已经被掩盖，意味着很难去评价真实的运维水平，也意味很难去提升，数据管理者就这样被过顶传球了。

数据运维最怕的也不是出事情，而是完全的事务驱动，总是去救火，投更多的人去救火，却很少有人能从运维的角度提出真正的问题和改进要求，这个可比救火难多了， 100个接口的时候，如果我们不去做规划和管理，到1万个接口的时候，可能已经来不及了，所谓积重难返。

大数据是新的机会，对于运维也是重新的开始，未来的挑战很大，与大家共勉吧。