在这个过程中，我们做的时间其实不长，比较短，目前只是做了一些相对来说较为简单的一些事情，但取得的成果在公司内部感觉还是比较好的。
今天跟大家分享一下我们在应用开发过程中的一些案例，即如何让数据技术在运维实践中得到充分的应用，希望对大家的工作有一些参考价值。
分为四个部分进行分享：
- 数据处理技术应用
- 数据分析技术应用
- 数据挖掘技术应用
- 应用生态建设及规划
在运维中我们会碰到各种各样的问题，如下图：
但有些问题我们经常重复遇到，并且形成了一些提问范式，如：
- “有问题或故障发生吗？”，这个提问转换成数学问题就是建立“异常检测”模型。
- 当我们确认有问题时，我们本能地会问“哪里出了问题”，这便是一个“根因分析”问题。
- 对于一家电商公司来说，促销前总是要对线上系统进行容量评估和扩容，这里便有一个“预测”模型需要被建立。
- 当我们每做完一个项目，需要对项目需要达成的目标进行定量的评估，这便是一个“绩效分析”的问题。
目前各类数学模型的输出在我们的具体工作中主要被用作辅助决策，有两个原因使我们还不能直接把结果自动地用于决策：
- 我们对数据的使用能力还不能做到面面俱到，很多业务知识还无法用算法描述。
- 算法的输出结果一般都是有概率的，在很多需要“绝对正确”的场合只能作为参考。
在实际工作中，算法和业务规则库都会进行建设，用来帮助运维人员更容易和正确地做出决定。
今天给大家重点介绍“数据处理技术”、“数据分析技术”、“数据挖掘技术”这三个方面在唯品会的应用实践，主要会讲到一些应用场景，最后谈下“数据技术”在运维的生态建设和一些规划。
数据处理技术应用
对于数据处理技术来说，我们主要解决以下五个方面的问题：
- 数据的准确性、及时性
- 海量数据的实时计算
- 多维数据的实时监控
- 多维数据的展示
- A/B 测试实现方法
这里有些问题在行业里已有比较成熟的解决方案，有些可能不是每个公司都会碰到。
数据采集
首先我们看数据采集，对唯品会来说，我们主要是两类数据：
- 日志数据
- 数据库数据
对于日志数据来说，我们有两类采集：
- 客户端的日志采集
- 服务器端的日志采集
对于服务器端的日志采集，实际上是比较简单的，一般来说就是落到本地盘之后，通过 Flume 传送到公司的 Kafka 集群，然后大家在上面消费。
对于客户端行为的采集，分成两种：
- Web 端的采集，一般来说就是通过异步请求在 Nginx 上落日志。
- APP 端的采集，一般是通过一个接口调用的方式，把这些数据落到服务端，再由服务端把这个数据收集起来。
对于数据库的采集，实际上我们也是有两种方法：
- 直接在从库上来做这种指标的计算。
- 对于复杂的应用，我们会把 DB 的 Binlog 做一些解析，解析完了之后放到一个消息总线上，实际上就放到 Kafka 上，然后让大家来进行一个消费，每个应用都是根据自己的特点，重构自己的数据结构。
有些会还原数据库，有些就直接用消息来计算指标，具体要根据情况进行分析。
上图主要描述了唯品会用到的一些主要开源产品，基本上是这样。
数据计算
数据计算是比较重要的一环，实际上要兼顾性能和灵活性两个方面。
对日志的处理，会有一个日志解析程序来消费 Kafka 的消息，“日志解析”实现一个实时 ETL 的过程，我们会根据配置（基本配置也跟 ETL 差不多）去生成预定义的标准格式，后续就交给 Spark 做聚合。
“日志解析”由于日志之间没有相关性，可以 Map 之后并行计算，吞吐量和资源的投入是成正比的，这样效率就没有什么太多的问题。
对于 Spark 的聚合配置，一般来说我们会把日志解析完的数据进行定义，定义各个字段是维度或是指标，然后会做一个全维度的聚合。
这里面实际上也是有个要求的，我们要求所有的指标在各个维度上都具有累加性。
如果不具备累加性（比如百分比这种指标），我们在 Spark 里是不做聚合的，只是在展现的时候重新计算，计算好的数据会放到一个 OLAP 和 MOLAP 的数据库里。
还有一种情况，是通过脚本在数据库从库上直接进行指标的计算，一般用于只有时间维度的指标计算，配置好的计算脚本，我们会用公司开源的一个产品 Saturn 来进行一个分布式调度。
Saturn 这个东西还是不错的，推荐大家去尝试一下。对于日志的详细查询，我们还是放到 ES 里，通过全文检索的方式来查询。
数据展现
数据展现是最终的结果输出，实际工作中，我们对结果数据的查询效率要求比较严苛，因为这些结果数据不仅用于前端，还用于告警输出等各个方面。
对于告警的数据我们需要做到毫秒级响应，前端界面一般要求是在 3 秒内渲染完成。
为了完成这个要求，我们构建了一个 ROLAP 数据库，还有一个 MOLAP 的数据库，在 ROLAP 的数据库里，一般只存当天的多维数据，而在 MOLAP 的数据库里，会存历史数据。
对于 MOLAP 数据库的检索，由于应用主要是切片方面的需求，基本上都是 K-value 模式的一个检索，所以它比较快。
MySQL 里一般是存放单维度指标，应该这么讲，它不是多维数据。Redis 缓冲里，一般会存放我们的秒级数据，还有一些配置信息。
这个架构中，最后通过 Application Server 进行一个数据的整合，来满足前端数据的一个展示要求。
多维分析界面案例
这是一个多维分析案例的界面，左边是我们的分析平台，右边是我们的实时监控平台。
从这上面大家能看到，我们实际提供的功能主要是对数据切片的能力，这个能力基本可以满足我们目前所有的需求。
A/B 测试实现
对于数据分析来说，基于 A/B 测试的对比分析是一种重要的方法，因为 A/B 测试对比的结果容易被业务理解，如果没有 A/B 测试，你说我做了一件事情，这件事情带来了一个好的效果，还是很难经得起挑战的。
在 A/B 测试中，它需要一些技术来支撑的，因为我们在线上同时会有很多 A/B 测试的案例同时在跑，你自己的 A/B 测试不应该被别人干扰。
在这种情况下实际上是要求各个 A/B 测试之间的用户分布得具有正交性，也就是说别人的 A/B 测试集用户应该平均分布在你的 A/B 测试集上。
这种实现我们大约有两种方法，一种是会在 APP 端设置开关，每个开关管理一个 A/B 测试的实验。
更多的 A/B 测试，是统一请求后端的 A/B 测试分组服务，这个服务通过算法来保证各个试验之间相互独立。
一般来说，当客户端发起 A/B 测试场景的时候，就会向 A/B 测试分组服务发个请求，然后 A/B 分组服务会返回这个用户是属于 A 组还是 B 组，一般是这样的。
数据分析技术应用
这部分会简单介绍具体的分析方法，并主要说下应用场景和案例。我们的运维数据分析技术主要是用于解决两方面的问题：
- 绩效分析
- 根因分析
绩效分析
以前我们做了挺多的项目，这些项目一般来说 WBS 分解之后，我们会对项目的结果做一个简单的跟踪，只是说做完了，还是没做完，一般也不会对它做一些定量的分析或者说对这个质量有一个看法。
这种情况在我们的项目中非常常见，这种项目一般来说比较小，都是靠个人技术能力就能控制住。
但在大型项目中这种做法就很困难，它会面临更多的一个挑战，尤其是跨部门合作等情况，因为大家的沟通手法不仅仅是技术的，可能还有一些管理上的，这时就需要大家用数据在各个部门之间作为一个沟通的桥梁。
绩效分析-全站 HTTPS 项目案例
于是数据分析人员开始介入来进行分析体系的设计，主要包括：分析指标的设计和分析维度的设计，同时和研发确认数据采集方案、A/B测试方案、统计口径等。
指标主要是根据项目中各项工作都关注什么问题来设计，而维度的设计是从当指标不满意时，可以在哪些方面着手改进来进行。
在这个项目中可预见的是，由于证书握手的原因，TCP 连接时间会变长，可能会影响用户体验，同时也会减少劫持从总体上提高用户体验，所以项目的目标设置为转化率至少不下降，最好能有上升。
我们实际上是做了一个 HTTPS 的全站项目，在项目开始之初，我们就有意识地把数据分析团队和技术人员整合到一起跟进项目，取得了不错的结果。
数据分析人员在项目的初期就已经开始介入，来进行分析体系的设计，主要包括：分析指标的设计和分析维度的设计，同时和研发确认数据采集方案，A/B 测试方案，统计口径等。
分析人员会把这些工作做好，可他们怎么来设计这个项目的一些指标呢？一般来说，在 WBS 分解之后，我们关注什么问题，就会把这个问题变换成一个主要的监控指标。那如何去设定这些维度呢？
实际上这些维度都是我们能解决问题的一些角度，也就是说实际上所有的维度都是我们能控制、能改善的地方。
首先 HTTPS 项目，不知道大家有没有了解，如果了解可能知道 HTTPS 项目，因为 TCP 握手时间会延长，这一点上可能会损失一部分的用户体验，但在防劫持等方面，又会加强整体的用户体验。
在这种情况下，我们项目设立了一个最终的主要目标，也就是保证转化率，这个转化率不能下降，最好还有一点点提升。
在这个主要目标上，我们就控制这个主要目标，不停地灰度放量，不停地调整，这个效果是比较好的。
因为在这个过程中我们发现了很多的问题，同时这个项目持续了大约 8 个月，在 8 个月中我们没有发生过任何重大的故障。
这个案例是对错误率的分析和监控，有一次发现我们的错误码是 HTTPS 的证书认证过不去。
这种情况在某个省某个运营商大规模地发生，我们从分析的角度看这些节点 IP 是不是我们自己的 IP，这样我们就知道在这个地方发生了大规模的 DNS 劫持问题，于是就去协调当地的运营商把这个事情搞定。
数据分析也会发现一些代码中的问题，我们做 HTTPS 项目，可能要对代码进行一些修改，比如说在整个 HTML 里是不能存在 HTTP 协议的硬编码。
但由于历史原因，这种地方还是比较多的，开发人员很难排查完，实际上需要分析人员通过数据分析手段去查，把这些没有改过的代码找出来。
还有一些图片的问题，我们发现一些图片的拼接错误，当然是报了 404。
报了 404 之后，我们对这个错误码分析，发现突然多了，把报错的 URL 做一个排序后发现一些是拼接的错误，还有一些是由于特殊字符引起而导致了无法生成正确的请求。
我们对 TCP 的握手时长也会进行跟踪，在做灰度选型阶段，我们在不同的入口采用了不同的技术类型，通过分析各个入口的握手时长来辅助运维人员进行一个加速卡的选型，还有一些参数调整等工作。
绩效分析-其他案例场景
这个项目进行完成之后，我们总结了很多经验，慢慢地在其他的项目中也逐渐有意识地运用数据分析技术，把数据分析人员和技术人员有效地结合在一起。
这里面也有几个案例：
- 比如说 CDN 厂商切换时，我们要跟踪错误率、响应时间这样的一些指标，来决定切换是否需要回滚。
- 促销前的一些流量调度，我们也要分析调度策略的预期结果，比如说各个入口的流量是不是按我们的计划把这个流量调度到位了。
- 每次 APP 版本的更新，我们也需要不停地来跟踪它的访问连通率、网络连通率等一些关键指标。
根因分析
在数据的基础上，我们也可以做一些原因的查找，通过数据分析进行的原因查找有时可以直接帮我们定位到问题，在更多的时候可以有效地帮我们缩小问题的范围。
通过数据来查找原因，这其实是有一定局限性的，局限性就在于数据的维度，因为我们只能在分析的维度上来进行查找，如果故障的原因没有在我们已知维度上，实际上是找不出来的，但大部分时候还是能起到比较关键的作用。
对于直接利用多维数据进行问题的分析，我们大约有三个步骤：
- 确定问题，确定问题之后，就确定了是哪个指标有问题。
- 做一些数据上的分析。
- 找到问题之后，我们要做数据和业务上的一些验证。
主要的方法有两种：
- 排序表，这个最简单了，就是人眼看，通过排序我们可以解决70-80%的问题。
- 数据探索，有点自动化的意思，它有一个原理，实际上并不是所有的数据都能进行探索，我们目前就是假设这个数据在任意切片上，在时间维度上它是属于均匀分布的。
在这种情况下，我们认为这个误差值是符合正态分布的，就可以比较容易地做一个异常的检测来看每个数据切片上是否有问题，当所有的数据被探索完之后，问题的原因也基本能找到。
根因分析-案例
这是非实时根因分析的一些案例：
我们有一次网络连通率连续三个月下降，我们分析到最后，发现这个 APP 的版本有些问题，某天之后所有新发布的 APP 版本连通率下降都比较大，跟研发反馈之后，他们就在 SDK 做了一些调整。
实际上真正错在哪，我们并不知道，我们只能知道这个版本有问题，更多地去帮助技术人员缩小这个范围。
图片错误率上升，刚才已经介绍过了，再就是实时的根因分析，刚才讲的都是一些平时的案例，而实际上我们也做实时的系统，这些实时的系统就是希望利用多维数据，在系统告警后，能够帮助大家更快定位一些问题。
这里也有两个例子：
连通率下降之后，我们会发现某类错误码是影响的一个主要因素，有针对性地解决问题后，发现连通率恢复了，这样基本上可以定位故障。
某一个应用的错误率有上升，我们会看到有些省份影响比较大，具体看是一些 CDN 节点的故障，切换后，故障得到恢复。
总体看，实时分析还是能够比较快地帮助运维人员定位问题。
数据挖掘技术应用
对于数据挖掘来说，我们目前所应用的场景，或者说能帮我们解决的问题主要有三类：
- 预测。
- 异常检测，主要是用来做告警阈值自动的设置。
- 做一些根因的分析，它的目的和刚才讲的基于数据分析的根因分析是一样的，但在实现上算法有些不同。
预测
我们现在的预测，主要是做了一些业务指标的预测，比如像 PV、UV、订单、购物车这样的一些业务指标，下面我讲一下订单的预测。
如上图，是我们的订单预测图。当时做这个预测，实际是有应用的场景，当故障发生时，需要实时跟踪预计的损失，以便于我们确定故障的等级，还有就是调度解决故障需要的资源量。
大家可以看到，这种预估我们还是比较容易可以算出来的，在什么时候这个故障已经好了，什么时候它的损失达到什么程度，我们的故障是不是需要升级。
这里面有一个技术点需要解决，就是说我们在故障的时候，实际值已经掉下去了。
而我们的预测算法需要前一分钟和前几分钟的数据，为了不把故障的数据引入到算法中，在故障的时候，是用预测值代替真实值。
具体来说，就是用上一周的数据做一些平均的加成来替换，然后再做下一次的预测。
对于预测算法，我们开始采用的是时间序列中的 holt-winters 算法，因为我们公司的数据周期性比较明显，我们在时间序列上做拟合时还是比较准确的，应该来说效果还比较好。
但这个算法到了一定时候，我们就碰到了一些问题：
- 促销和平时不太一样，也就是说促销的数据，我们是拟合不上的。
- 在告警和一些夜晚流量低峰时，这个数据波动还是比较大的，告警的准确率也不是很高，我们怎么来解决这个问题呢？
先看促销，对订单量来说，订单达到高峰之前，我们的 PV、UV 包括收藏数等业务指标已经开始启动了，我们就会把这些业务指标引入我们的分析模型。
也就是我们会把 PV、UV、收藏数，包括上周同期的这些数据，和上周我们要预测那个时间点的订单数全部都引进来，然后用一个机器学习的办法，基本上就可以解决这个问题。
在双 11 促销后观察了一下预测的情况，现在促销预测的数值还是比较准的。
当基于预测进行告警时，碰到主要问题是夜晚低峰时数据波动较大，如果按每个时间点的指标直接进行告警非常容易误报。
我们采用的办法是预估损失累计的报警方法，当累计预估损失达到 100 单时就进行告警，这样调整后，我们从上线到现在基本已经没有了误告。
这个 100 单的设置，跟我们公司的制度有关，因为我们公司达到了 200 单、300 单，那就是重大故障了，我们在 100 单的时候，就把这个警报给拉起来，是可以防止重大故障发生的。
根因分析
最后在数据挖掘这部分的应用，给大家介绍一下根因分析。
我们这套算法经过几个案例的尝试，基本上都能找出原因，首先就是它跟多维分析的“根因分析”不太一样。
多维分析的“根因分析”是建立在已经计算好的多维数据基础上，而这个算法实际上是从原始数据来抽样的。
比如说，像错误率上升的一个根因分析，我们首先会抽一些数据，把错的和正确的日志各抽 50%，对非数据列进行预编码。
预处理之后，我们会用 Spearman 和 Mutual Information 这两种算法来计算各个维度和结果之间的相关性程度。
如果这两种方法结果一致，则直接按相关性值大小进行排序，然后会用 One hot encoding 做一个转码，转码之后放入逻辑回归模型中，选择 L1 的惩罚项；如果它的系数算出来是负值，这个负值所代表的维度就是原因所在。
如果上述方法两个结果不一致，采用 Random Forest 和 Adaboost 的方法构建树模型，查看模型给出的维度重要性，这里我已经画得很清楚了。
如果两个模型的重要性排序一致，就走上次那个步骤；如果不同，则用该模型对数据进行预测，选择预测结果较高的相关性排序。
应用生态建设及规划
最后跟大家一起讨论一下，如何让数据成为运维的大脑，根据我们的经验，首先从组织结构上来说，我们需要一个独立的分析团队。
因为在这个分析团队成立之前，公司的运维体系实际上也在使用数据，使用数据的方法和分析团队后来使用分析数据的方法也是大同小异，但因为它本身是一个自发的，没有一些强制性的要求。
在把数据分析融入到工作流程之后，我们发现效率会得到一个比较大的提升，同时知识的传承，包括统计口径等这些比较令人困惑的问题也都可以得到一个比较好的管理和解决。
这样的组织架构在我们的实践中，感觉可以更好地帮助运维专家来解决问题。
从平台建设上来说，应该是说现在已经开始了，着力打造的是两个平台：
- 数据分析平台，数据分析平台说到底就是运维的数据仓库，它使用现在大数据的一些传统技术来做这件事情。
- 统一信息平台，“统一信息平台”主要考虑到在互联网公司，不管是不是在野蛮成长阶段，系统都特别多，信息也是特别分散，我们还是想把这些分散的关键信息看怎么收集起来，然后看能不能做一些事情。
目前我们会把发布平台的一些发布信息，还有 ITIL 平台的一些事件信息、变更信息，CMDB 的一些基础架构信息，再有就是各种各样的监控系统的值班表信息和告警信息（这种监控系统我们有好几十套），我们都会把它们放到信息库里面。
在信息库建设之后，我们算法虽然可以实际有效地解决点上的问题，但还没能很好地解决关联性上的问题，这块还是挺困难的。
只能是说当前是一件事情一件事情去解决，那这种复杂的关联性我们靠什么呢？
靠的是规则库，用业务知识补充当前阶段算法上的一些不足，也就是说在整个系统建设中，实际上算法库和规则库都是一起建设的。
不会说，就用算法，不要规则了；或只有规则，算法也没什么用，它是一体建设的。
而且它们能解决的问题不一样，算法我们是解决点上的问题，规则我们是用来解决这种关联性的问题，尤其复杂业务关联的问题，都靠规则来配置的。
整个这套平台的建设，它主要有两个目标：
- 对告警进行有效的一个压制、管理、合并。
- 想能够解决自动故障定位的问题。
目前是有一定的成效，但准确率还没有那么高，以后能做得好的时候，我们会通过 ITIL 平台来驱动自动化平台对现网的故障进行自动化的处理。
比如说像重启、降级，限流，磁盘空间管理，流量调度等工作，应该是说为了自动化运维、解决故障一起努力吧！
以上就是我们对数据应用在未来一个时期内的定义，也是想在未来大约半年到一年能够看到更多成果的一个实践。
