大数据运维的思考

一个企业的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%以上，再不重要的接口，也要有个保障底线，用数据来说话，很多企业的数据几个月没采集都不知道，是由于缺乏明确的保障要求。

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