2018-03-21 16:30
前面嘉宾的分享有一句话我很感叹，开发不容易。我想说的从开发做云维也是好多坑。我是研发，由于公司的组织架构调整，从去年3、4月份转到运维的团队，所以刚刚我进入运维团队的时候，我们团队有一种被抛弃的感觉，为什么我们一个研发需要转到运维，究竟我们能做什么，我们研发进了运维部门以后能为运维提供怎样的改进？实际上我是来自畅捷通，是用友的子公司，用友做传统ERP的比较牛的企业。所以在这种企业面临转型的时候，现在我们最大的口号是传统的ERP往云上发展的时候肯定会带来运维职责以及运维背景的一些变化，我们就是从原来传统的做ERP，到现在的ERP往云上切，再从研发到运维的部门可能经历了这样一个转变的过程。在这样探索的过程当中给大家分享一下现在我们这个研发在运维这边能做的一些东西。
我的分享主要是分为这样四个部分：第一部分是需求背景和业务分析，实际上就是诉苦，我们研发刚刚进入运维的时候，一直在探索我们研发能够为运维带来什么，我们应该去做什么。第二部分当业务分析与需求背景分析清楚了以后我们就提出从我们研发的角度如何去解决你运维中的一些痛点，现在比较火的微服务化，为什么呢？我们一直在找寻研发在运维部门当中的目标，最终我们找到的一个目标是希望将运维的能力、运维的工具能够以服务化的形式去呈现和沉淀下来，这是我们最终研发在运维部门当中给自己的一个定位。
在这个探索过程中现在有两种架构（见图），这两个设计都是面对前面诉苦的内容针对的一些痛点。还有一部分是数据分析，前面刚刚一些老师的分享可能都有了，可能是围绕报警体系故障的定位，围绕着报警故障的预测，我们现在公司也有这方面的探索。
首先从需求背景说起，原来的传统模式从底下到上面可能说我有多少台机器，我就需要有多少人来管理，然后有多少人的IT团队，有多少人的运维团队，多少人的研发团队承载我多大的业务量，这是你传统的一个模式。可能说原来对于IT在整个公司中的定位就是我如何降低成本，我如何去承载你这个业务的发展。到现在以后我更多地围绕IT团队的时候是围绕业务价值来，我不再说我只是一个成本的部门我要去该低成本，要去承载业务量，而是说我整个IT团队是不是能够承载灵活地应对你业务的变化，能够快速地响应市场，这可能是现在我们很多IT团队建队的一个目标，这时候我们就将它进行一些流程化的处理。就是我大部分的需求过来以后，我通过简单地对流程的调整应对你在业务层面带来的这种冲击和变化。这样是不是就可以了呢？举一个很简单的例子，现在比如突然间来了一个公司，比如说公司多少周年，我需要很多ERP的产品，我需要做一个促销，一个简单的需求过来以后，可能我需要研发的调整、一些促销的价格的计算，一些促销价格、订单、出货单等等很多的一些调整，还有很大一部分精力在哪边呢？就使我底层IT基础设施的一个调整，就是我有可能说在今天的促销，我有可能会多少个产品的订单过来，我可能要部署多少台机器，我可能需要多少的数据库，需要多少的Web服务器等等等等，等你这样一些需求过来以后，再需要运维人员配合处理完了以后，可能这个市场推广活动的周期就已经过了。所以从这个方面来说，IT基础设施在云计算的背景上能否实现这种自动化的运维是决定你能否围绕以业务价值为中心的IT团队能够成功的一个很重要的方面。
根据康威定律，系统架构的变化一定会反映到你组织结构的变化，在传统的架构变化，有可能有前端、后端，有运维、DBA很多是传统的架构。但是现在微服务化了以后，这时候我可能说我是以业务价值为中心、去交付业务价值，很多都是以微服务这样的形式去存在于公司，所以说你整个运维团队、运维组织结构的变化，肯定你运维的职责也会发生相应的变化。原来运维的职责更多是以底层物理设备打交道，可能我有物理机、交换机很多很多，但是现在在云计算的这样一个背景下面，运维的职责不再只是简单地与物理设备打交道，更多与云、与很多的，运维基本工作不是添加一台服务器入库，不是简单的一个脚本阿里云要扩容的API，我需要部署新申请一个数据库或者扩容很多的都是与云各方面打交道，所以运维职责在现在的背景下面会带来很大的变化。
刚刚很多老师讲现在我们运维当中存在的一些系统承载着怎样的一些功能，最重要的是有一个监控层，监控的物理机，现在可能有容器、有阿里云很多的网络设备，有很多这样一个被管理对象，我通过监控什么样的数据，然后我主要包含的一些系统功能，有一些告警管理、报表，我们在进行运维人员研发过来了以后，实际上运维人员的一个考核，就是这个系统可用性是由谁负责的，刚刚进来之前运维是没有的，我没法说理清楚责任，基本上都是扯皮，就是说现在我是负责这个产品的运维，但是有可能职责划分不清，考核标准就不一样。研发进来以后，对告警关联性的数据分析看你达到业务层的健康程度可用性以及很多的指标衡量运维的能力，给它进行打分。
业务功能纷繁复杂，实际上真正到运维的层面对应着纷繁复杂的运维工具。从底层监控的工具我们公司用了不下五种，不同的监控产品能满足我们公司的某一些监控的业务需求，所以说很多层面的一些工具，还有报表、仪表盘、刚刚展示区域的，在我们公司也有看着很熟悉、很亲切，所以说这么多纷繁复杂的工具、这么多纷繁复杂的人。以前我们运维为什么说我们研发进入到运维之后强调了运维能力的沉淀，因为运维的工具纷繁复杂，当一个人可能在我的公司是某一个人、某一个运维我很熟悉运维工具的操作，对他的一些配置管理都很熟悉，但是他一旦离职了，我是不是还有人才备份的机制去填补他的漏洞，很多时候不是这样的，可能我对某一个对运维工具很熟悉的运维人员走了以后，这块监控业务、监控指标对于我来说很长时间是缺失的，新招的人要熟悉反复的一套流程。在这样的背景下面，我们研发进去了以后，我们怎么做？实际上我们提出了这样一个模式，在这个图上面包含两个部分，第一部分是微服务发布平台，这个平台是干什么的呢？就是说我能很快的将运维的一些能力进行服务化，进行发布出来，它的这个运维能力有哪些呢？可能是我的CMDB的数据库，有可能是我的运维脚本，有可能是日志文件的系统，在运维研发能力不是太强的时候，能否给他们提供一种快速的将运维能力以及运维工具的能力快速地以微服务的形式发布出来，这是微服务发布平台所需要解决的主要的一个痛点。
第二个平台叫事件管理平台，第一步我们将运维能力以微服务的形式发布出来以后，这些微服务一定需要进行编排，一定需要进行协调，然后才能去完成某一个我的业务目标、业务需求，所以在这个事件的管理平台，主要就是收集了很多很多的数据来源，叫事件源，有可能是你监控层的，我们有四、五种开源的监控工具监控过来的数据。还有消息中间件，很多是从业务系统过来的，现在很多业务系统通过消息进行沟通，当业务系统中某一个业务消息很有价值的时候，我如何把这个事件、这个业务事件也发布到事件管理平台从而对它进行一些运维方面的分析。
在中间这部分实际上是我们各个运维发布的微服务，可能是运维脚本、也可能是CMDB数据库、也可能是文件系统，当这些微服务发布了以后，每一个微服务都嵌入系统服务，Engine，这个主要的作用是什么？是为了协调起来满足我们的业务需求。
这个是我们基于DreamFactory自主在上面拓展研发的微服务的发布平台，它主要对运维的能力进行发布和管理，有一些很多像人员之类的管理，目前没有特别复杂的权限的管理，这个平台的作用现在目前就是这样。
刚刚我们构建了这样一套体系和平台之后是如何完成这样的业务需求和业务目标的，这是我们报警事件处理的大致的流程：由事件处理中心接收到了报警事件，当然如果有界面给大家展示会更加清晰一点。第一步接收到报警事件，由事件中心对报警事件进行预处理，可能会切割、可能会填充字段、映射、查询相关联的信息。第一步处理以后再将报警事件发布到事件总线上面去，这个事件有这样几个服务订阅了该事件，第二个是报警事件标签服务，这个是做什么的呢？本身报警信息量是非常有限的，可能报了一个报警信息可能是某一个应用，报了某一个IP、某一个机房报出报警内容，比如磁盘空间少于多少，报警内容非常有限，这时候我们基于有限的报警的字段通过CMDB可能会查询到相关联的信息，关联到我的负责人，我的运维是谁，我的开发是谁，所以说如果是一个公网的IP，还有一些标签的信息，是给报警最后进行故障定位的时候做的数据的来源，这是其中报警事件标签的服务。
第二个服务组合服务，叫通知服务，这个服务是干什么的呢？它订阅了报警事件，它的业务逻辑有可能是根据我报警的级别进行不同的操作，在我们的公司可能对报警分了很多的级别，有指示通知等等很多分层的四、五级的警报，每一级的警报应该执行不同的操作，利马要发短信、邮件等等发给负责人。如果只是通知类的5分钟治愈了都不用发了。通知类的服务是这样。
还有一类服务是故障订阅服务，订阅了报警事件以后会对事件类型进行匹配，现在我们目前通过Anserful（音）的脚本，如果当你报出来的事件匹配到相应的治愈的脚本，这时候我们直接治愈了这个服务，直接调用治愈的微服务，直接治愈就可以了。
下面我们看看刚刚的流程，界面的形式给大家展示一下。这是刚刚过来的报警，知道开源报警的可能很熟悉，L3212win主机磁盘C：小于5%，机房位于园区，有一个IP，级别是Disaster，故障状态是OK，后面是时间。这是在实践平台里面收到的原始的报警的消息，怎么办呢？我们事件里面有事件的模板，当你这一串报警过来以后我应该如何对它进行切割，如何对它进行字段的补充，在我们平台会有事件模板的这样一个定义。当收到报警之后我们通过事件模板进行格式化和业务语意的增加，L3212代表应用ID，报警等级、报警状态，这是第一步，对数据进行预处理。为什么要有预处理这样的一个步骤呢？因为报警的工具太多，格式的东西也太多，格式的数据、数据的格式也非常多，包括像我们收到一些网络的报警，可能过来的就是一串文本，而且还是很多毫无意义的信息是在里面的，所以这边是提供一个进行事件预处理这样一个步骤。
第二步可能就是我这个事件我会看这个报警事件有哪些微服务进行了订阅，就是报警过来以后，我会通过配置订阅的步骤查看，比如报警事件来了有哪些服务进行了订阅，我会进行处理。
图上展示的数据是我打完标签以后，这只是很少量的数据，我只是展示了一部分。刚刚在上面是报警故障有限的信息，我打完标签以后，大家可以看到一个变化，我属于哪个工程、属于哪个应用、属于哪个研发、属于哪个部门，负责人是谁，我是直接发给相应的负责人了，这是打标签的服务，可能我会根据你报警的字段调用一些关联信息给你的报警打上一些标签。
再看一下，这个试管上是我们通知服务，这是在米达斯（Midas）事件中心里面运维人员直接可以看到的组合服务，有可能根据报警信息里面的某一个字段，刚刚是报警级别决定哪些微服务，有可能是短信或者是微信，这样的业务流程组成了服务，由它订阅了报警事件，由这部分进行后面相应的操作。
这是米达斯（Midas）事件处理中心简单的架构，主要分为两部分，刚才说的比较清楚了。第一部分是客户端，在每一个微服务当中进行事件和命令的接收和处理，另一部分是事件处理的中心，在这个中心里面主要是提供了我的命令主线、事件主线，下面我们实现了报表读写的分离，比如说报警的一些信息我需要对它进行归类、需要对它进行一些考核的指标出来，会有数据库。这里面牵扯到很重要的概念，一个是事件、一个是命令，这二者有什么不一样？为什么要做这样的区分？很简单，我一个事件过来以后微服务直接这样操作就可以了，那么大家想一下，这个流程的编排，刚刚通过警报的级别执行不同微服务的编排，我是把它放在中心，还是把它分布到微服务当中去完成业务目标。
我举一个复杂的例子来完成刚才说的场景，说明事件和命令之间会有怎样的不同。我大概说一下稍微复杂一点的业务场景，在我们那个公司有自己基于CloudFounder，基于这个自己做了云平台，云平台为了节省资源有这样一个策略，当用户一个虚机，我们当时是一个用户对应一个虚机。当我的一个用户在两个小时之内不进行访问的时候，我会将他进行挂起，会将这个虚机的状态从内存到内盘上，是一个Stop的状态，服务路由会将该虚拟机访问的URL注销掉，从外部访问的时候是访问不到已经处于停止状态的虚拟机。当你过两、三个月还不访问的时候，有可能我将你虚拟机的状态直接从硬盘上删除了，你的一些数据进行备份了。就是这样的一个策略，当有用户进行访问的时候，从服务路由上发现不到该虚拟机的一个服务地址，这时候我们有一个微服务叫做虚拟机唤醒服务，当未知域名访问事件由虚拟机唤醒服务接收到以后，服务端可以执行怎样的操作呢？一个是虚拟机状态的校验，有可能这个虚拟机是Stop，有可能是Delete了，我要对虚拟机的版本和状态进行校验。第二个命令是我虚拟机版本的校验，有可能用户一、两个月，两三个月不访问了，我已经将他的虚拟机删除了，这时候我的产品进行了一些功能的更新，这时候如果用户想访问到我们新的产品功能的时候，这时候需要将虚拟机应用的版本、应用的程序以及数据库进行升级，这是版本的校验。第三虚拟机唤醒，有这样的一个微服务，订阅了未知域名的访问事件，然后有虚拟机这样一些状态的操作。为什么有命令和事件的区分呢？就是为了避免分布式事务这样一些很头疼的问题，即便在命令这边我是做到重复执行的，在我们所有补偿机制里面超时重试就可以了，不用涉及到复杂的分布式的业务。
我们大概看一下有这样三个微服务，这一整个未知域名访问事件的处理流程，在这下面我这个PPT做的比较大，下面看不太清楚，实际上就是说在我画虚线的部分，就是在服务处理的边界，它接收到未知域名的访问事件，它对自己的命令进行编排，第一步进行虚拟机状态的校验，如果虚拟机状态只是从内存到硬盘当中了，我直接对你的虚拟机进行唤醒，从你的硬盘当中两、三秒直接运行就可以。如果虚拟机的状态已经删除了，这时候我会直接发布虚拟机开通的命令，直接由我的XPush虚拟机开通服务执行开通命令就OK了。重点在什么地方呢？由我嵌入的米达斯客户端，我使每一个微服务具有了对自己的命令进行编排的这样一个能力，每一个微服务的边界，可能我发出一个什么命令到一个微服务，或者我发出一个什么到事件主线，它的功能边界就这样OK了。但是如果它以传统的工作流，很多的BPM，它的不同点在哪？我会将编排能力分散到各个微服务当中，微服务级别的编排实际上是由我的米达斯实验中心由它提供编排，由这两种级别的编排实现一些复杂的业务场景。
刚刚说了一个我们主要的通过以事件命令这样的一个模式实现运维能力的一个沉淀，实现了能力之间复杂的协作完成一些业务目标，还有一个痛点在哪儿呢？微服务，API给我的直接是一个数据，格式化的字符串的数据或者怎样的一些数据，这样一些数据每一个都会有不同的入口，每一个微服务都会有自己不同的入口，所以说这时候我们做了一个什么操作呢？就是基于服务能力的呈现，我通过ChatOps（音）这种模式对服务进行统一的输出，我需要调用某一个微服务呈现出某一个能力的时候，我只需要在聊天对话框里面输入一个聊天的命令就可以了。这是我们一些命令的展示，就是已经基于ChatOps（音）呈现的一些数据，就像QQ聊天之后给你一些数据的呈现。
最后一部分就是我们通过一个统一的平台，把很多很多一些事件包括你的业务事件，包括你的报警事件，很多很多的数据来源以后，我们可以做简单的关联啊，通过报警的形式直接发通知，这样一些简单的功能就已经OK了。
还有一部分功能就是一个关联性的挖掘，我可能在同一个时间维度，在业务规划当中明显看起来没有关联的两个服务最后发生故障的时候可能他们两个人的相关联达到90%多，为什么？是否我们通过这个运维关联性的挖掘去发现业务问题的推动业务的一些发展，刚刚在前面的服务当中提到了报警的标签的服务，这个服务是干什么的呢？实际上就是为我们后面进行报警信息的相关联性的挖掘进行故障定位提供一个数据的来源。
这是我们大概的一个结构，由监控系统收集到了这样的数据，有性能数据、有报警数据、有应用日志的数据，然后到我的事件处理中心我进行归类、格式化，处理完以后传到阿里云的一个大数据处理平台。然后当所有的这样一些关联的一些信息传达到云以后我们信息都是已经格式化好了。开始我们的方案是这样的，把我们整个CMDB的系统很多的关联性的数据全部放到阿里云，在阿里云上做一些关联的东西，最终我们还是选择我们自己建了这样一个处理中心以后，将这些关联性的数据，将报警的这样一些数据直接格式化完了以后传到阿里云上面，一部分减轻了负担，因为阿里云是要钱的。实现了这样的流程，数据传到阿里云，经过关联性的分析，进行一些故障的定位，有可能我哪些关联性的信息会对你故障最准确的一个定位，有可能说一个故障来了，好比一个网络段，应用层报警、数据库报警、系统层报警、业务层报警，如何在纷繁复杂的报警信息里面快速地准确地定位到我出问题的位置，就是通过报警信息打的业务标签、打的系统标签，在系统标签进行一些聚合最终准确地定位这个报警。
这是我们的一个展示（见图）。在我们的报警当中，一部分左上角打的是一些业务的标签，可能我们一些产品，CIA、工作圈等等简单的一些业务标签，在右边有可能是数据库、网络，有很多系统层的标签，当我所有的报警关联信息过来以后，我会对这个标签进行一些聚合处理，聚合处理以后最终哪些是频率最高的、关联性最高的有可能最终红色的就是你最终定位的故障来提高你这种故障定位的准确率。
第二部分的应用实际上就是你周期性的一个分析，就是刚刚说的，前面根据关联性的分析可以进行故障的定位，我根据周期性的数据的分析，我可以进行故障的一些预警。定位是我同意时间维度不同的业务报警、不同的业务指标在同一个时间维度呈现出来的这种关联性。周期性是说我同一个指标在不同的周期当中我呈现的一种规律性。像这种应用场景需要大量的故障模型和大量的业务指标进行匹配的，好比现在我们某一个应用产品发生了一个用户登陆失败这样一个故障，在发生这个故障的时候，我各项性能指标、各项报警信息、各项上线信息、各项性能的一些指标呈现出怎样的一个规律？当我在实时采集到你这样一些数据以后，我需要对你的故障进行一些匹配，当到达某一个阈值的时候，直接告诉你这个直接不可用了，这样一个报警导致这样多的指标呈现了相关联性。但是这块目前我们还没有很多的应用，还需要很多的数据去进行训练。
这是和刚刚进行故障定位相关联性分析的场景差不多，也是同样收集完以后进行数据的处理，处理完以后传到阿里分一些周期性的数据和实时采集的数据。通过周期性的数据以后，形成一个曲线，就是业务在平稳的时候呈现怎样的规律，这时候我在实时采集完以后，这个曲线呈现的又是怎样的规律，这个规律再进行比对，比对之后再进行故障的预测，就是有可能会发生、将要发生怎样的故障，这是我们大概的处理流程。
谢谢大家！