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