今天我分享的主题是有三大块：一个是介绍目前携程应用运维体系，我们自己做得比较好的实践；然后介绍运维自动化建设的历程，同时第三点介绍一下在运维方面所作的一些探索。

我们先可以来看一下数字，这是目前携程数据中心的情况。我们一共有4个数据中心，也有几万台服务器，有30多个BU和SBU，这就是相当于30多个子的小公司，每个公司都有不同的技术团队和架构。

当前活跃用户数是有5000多个，可能大家单单对数量没感觉，如果是在行业里面做比较的话，据我了解的情况，美团和点评合并以后加起来的应用数量是3000多个。

然后每天的请求是30亿次，这是指Requst。这是携程的技术站，我们用得最多的是Net和Java，除此之外还有一些小语言，VTS、NOD。当然用得最多的是Net，所以我们的服务器都是Windows，很多运维人员对Windows是深恶痛绝，因为它有很多的补丁还有不是开源的。

除此之外还有什么挑战呢？为什么主题叫洪荒之力的生存指南。一个是业务要求技术架构支撑业务10倍的成长，最近根据统计，流量每年翻番100%成长，业务变化非常快，平均每周有4000多次发布次数。

我们第三点也是有携程特色的，部署模式是单机多应用，一台Windows主机上部署6个以上的应用，多的话一台机器部署40—50个都有，这给运维带来很大地困难。

单机多应用比单机单应用多维度。我了解到的行业绝大多数公司都是单机单应用。然后我们的耦合度非常高，依赖层级可达15+，就是A依赖于B，B依赖于C，最多的应用是依赖曾级可达15。

所以对可用性要求高，目标要求是99.9%，是行业内比较高的标准，最近一年我们是达到了这个目标。特别是今年的一季度，我们达到了99.99%，当然这当中是需要一些运气的。

很多人不太了解应用运维是干什么的，什么是应用运维工程师，在我的了解你，应用运维工程师主要是系统运维与产品研发之间的桥梁，要搭建整个配置和交付的路径，把我们研发开发出来的产品，稳定可靠地交付到用户手中，并且保持良好的用户体验。

举个例子来说，把我们的业务看成是高速公路上行驶的汽车，系统运维就是汽车的服务厂商，研发就是产品，是这一辆车上的乘客。

对于运维来说，既是这一辆车的司机也是维修工，不仅操作这一辆车避开各种故障，也要负责加油、换轮胎甚至是升级改造的工作。第二个定位是网站可靠性工程的实现者，现在比较火的是SRE概念，所谓SRE是把运维当成软件产品来做。

工程师并不是系统管理员，他实际上是要把运维工作服务化、产品化，并且通过技术手段实现它。所以说对于应用运维工程师来说，是非常需要全面的知识和技能，我这边例句了硬件、网络、存储、应用交给、CDN、操作系统、软件开发等都要知道。一个开发人玩懂前端、后端全站工程师，那对运维来说，就是全站工程中的战斗机。

刚才是把运维当成软件来说，软件工作量占了运维工作很大地比例，基本上50%。下面我们看一下我理解的应用运维工程师的目标，稳定性不多说，所有的运维一切根本就是稳定性。

没有稳定性，其他做得再好也无用。性能也是我们关注的一点，页面打开慢了一点，你的转化率就下降，就要求我们的网站不仅仅是能用还要好用。

在互联网行业比较重要的是效率，不仅是产品迭代快，交付效率也很重要。还有一点是成本，因为任何公司都会比较在意成本，那对于运维来说成本是有两部分，一个是基础设施、网络服务器等硬件成本，第二个是运维工程师的人力成本。

运维我们一个是要通过架构改造，系统的架构优化，提高资源利用率，把硬件成本降低下来，同时通过把一些自动化，使我们运维工程师的人力成本降下来。也就是运维工程师的人数增长不能与业务增长一致的，要低于业务增长的程度。

还有一点是安全，对于应用工程师来说，每个人都是有能力把网站搞垮的，所以能力越大责任越大，所以安全对于应用运维也很重要。安全不仅仅是帐号要保存不能随便泄露，还有开发时要保证充分的授权设定，有没有并发操作的限制，一次性操作多少机器。有了这些，才能避免被人滥用或者是有意地滥用。

下面介绍一下携程应用运维开展的工作，也是我们觉得比较好的实践。一个是运维评审的机制，每一个应用上线前，我们会请研发的工程师和运维工程师在一起评估应用。

刚才我们说有30个SDU，很多工程师对于我们研发的环境和规范并不很了解，很有可能他的应用有缺陷，高可用性没有考虑到等，这方面应用运维工程师与它沟通，帮助它设计部署架构，同时也会帮助它评估，像你这样的应用上线需要多少资源。

另外我们还会问一些问题，进行它应用的非功能性的需求，比如说应用本身是不是无状态的，因为有状态就代表你的高可用。

对于非功能需求要弱依赖。包括还有熔断机制，还有服务降级。历史上我们出现过当酒店的点评信息出不来，服务信息出不来，导致酒店的详情页都打开不了，所以我们认为应用运维工程师是可以帮助研发工程师考虑这些问题。

第二个是对容量管理，这关注到刚才我们所说的稳定性、性能以及成本的考虑。需要我们做到的是说应用的资源既是合理的不会浪费的，在它增长时我们也能及时地为它补充资源，确保它的性能不会受到影响。

这块我们怎样来做呢？

首先我们建立预测模型，对它进行容量分析，说白了就是把应用和业务指标和系统指标关联起来，业务和系统的指标最典型的就是承载的请求数量和响应时间，系统也有很多，CPU使用率，带宽等，我们会跟踪服务器上指标的关系为它建立模型，不同的应用模型差异很大，因为根据应用本身相关算出来的模型也是不一样，我们都会通过对它的跟踪和计算把这些数据分析出来，建立模型以后就可以推测，当业务量增长到一定的程度，需要多少的资源满足它，而且这些分析是需要自动去做的，从应用去做难以跟上。

模型做出来还要验证它，怎样知道这个模型是否准确，特别是有一些应用量小数据波动比较小，这时候模型的可行性很难确保高。

我们会做一个在线压测，会调整单提服务器的权重，让它承载的比例不断变化，然后跟踪刚才所说的业务指标和系统指标，一旦业务指标达到我们设定的阈值，我们认为它很有可能对业务产生影响时我们会停止，通过这样的方式验证我们的模型是否准确。

有了这一模型我们很容易跟上增长，包括有时候一些营销活动双12的时候，只要业务给一个故障量，大概用户流量增加多少，我们就知道需要准备多少的资源应对。

这套体系出来以后我们也是做到全自动扩容，不需要研发人员提出，当每天计算的容量到一定量级需要扩容了，我们就会发邮件，应用服务器要进行扩容了，那就直接进行扩容。给大家看到的这份报表每天都可以查到的，根据时间的不同变化，当前的容量。

还有通过业务  来做一个DR容灾站点。做容灾站点，首先我们的规模很大，单数据中心容纳不了所有的业务，所以我们希望做到两点。

第一个是让单个数据中心具备独立运行所承载业务的能力，任何数据中心挂，其他数据中心的业务部受影响。另外还有一些核心业务，会在多个业务中心同时部署，当某个数据中心挂的时候，需要在其他数据中心也能承载这样的业务，确保业务可持续性。

这样我们会把核心业务包括基础的组建，框架和支付、风控等这些业务包识别出来，在多数据中心进行部署。

并且我们是在多数据中心可以实现流量灵活分配，而且还可以做到快速切换，有些业务重构或者是上的时候还可以做蓝绿发布，先让一个流量中心切掉，然后发布以后通过以后再把流量放过去。

当涉及到很多应用，应用回馈比较慢，然后把流量切到原来的数据中心，业务很快就恢复到原来的状态。然后我们定期进行切换演练，确保有效，这些都是在凌晨做这些事情。

还有携程如何处理网站的故障，这张图是我们的NOC所在的控制中心，这上面最显眼的是有32个大屏幕，每一个屏幕显示很多的监控指标，并且这些是配备很多的监控模式是可以随时切换的。

当我们产生一些比较严重的故障时，比如说订单受损或者是页面大不开，时间比较长了，我们会升级到高优先级的故障，因为有7×24小时的NOC，会立即召开电话会议。

电话会议核心的是把应用运维工程师叫进来，也会叫一些对应的研发的工程师，但是往往比较复杂的故障，是应用运维工程师起到比较大地作用，因为应用运维工程师对整个网站的基础架构比较了解，同时对我们的监控工具、日志分析工具都应用熟练。

然后排障还会用到IRC工具，大家知道这是一个经典的聊天软件，我们发现故障处理时非常好用，能够做到多人的实时交互，我们在这上面做了改造，我们通过复制粘贴在IRC里面贴图，然求还用IRC输入指令，你只要输入某某服务器的指标，然后IRC直接调出报表。

还有一个是COE（持续卓越运营），这是对故障的回顾，我们要求事故的责任方对原因做责任分析，这个要具体到引发故障的那一行代码，这当中不仅仅是对于故障的根本原因，也要看整个环节当中有没有其他的地方和工具进行改善的，有人说你的应用挂了我也挂了，我们都会去看，把COE总结出来以后，一个是改进措施有人跟进，确保类似故障不会发生第二遍，然后会在整个技术团队分享，因为我们有不同的SDU，希望大家从当中都学到不同的东西。

刚才主要是介绍携程在整个技术保障中心的实践，接下来介绍一下携程运维自动化的建设历程。

首先给大家看一下，这是数年前应用运维工程师的日常，服务器安装、应用环境配置、负载均衡DNS配置变更，监控绳检处理、CMDB信息维护、应用配置信息维护，还有用户需求响应，我要查一下日志，看一下成员状态有没有宕过。我总结下来是需求驱动、响应式、手工劳动。基本上是累成狗，不知道现在多少在座的会会心一笑。

整个运维自动化建设分几个阶段，第一阶段是工具化，工具化的核心是先把双手解放出来，用一些工具和界面远程操作代替手动操作。举一些例子，以前运维人员最讨厌变更，变更是文字操作，但是很多的变更是很类似的。

所以我们做了变更自动生成的工具，把一些关键的属性变进去，就会自动生成，同时做一些校验，指向对不对，目标能不能拼得通。然后远程操作，以前所有的操作都是登到服务器一台台做，利用Windows本身和WSA的机制，把这些远程操作掉。

还有批量处理外挂，有时候一些故障，10台、20台机器报警，最早我们一个一个处理，我们批量处理外挂，把相同引起的事件一次性关闭。这里面没有高大上的东西，也没有很系统化地做，但是这也很重要，把双手、时间解放出来才能投入到后面SRE的建设。

第二阶段是数据化，因为我们是应用运维，我们要建立以应用为核心的配置数据库，要把服务器管理进化到应用管理，原来的维度是单台服务器，因为每个应用都会有监控的指标，你要上新的就要扩容了，我要怎样配置吗？把以前的那台指标挖出来参考一下。

我们把应用维度，把应用级的集群集合起来然后有一个库的概念，把配置、安装、组件等都到这个库上，然后应用扩容时非常简单，这后面说的是全自动化基础，如果没有数据库，最早的CMDB做不到。而且CMDB是人工维护，准确性和时效性很难保证。

所以我们核心的是数据更新要自动的，自动的一个是我做完立即推动数据库，第二个是定时采集，确保我们的数据是很准确，并且是很实时的。

第三个阶段是做平台化，最主要的是完全做到自动化、无人值守。中间很重要的一点是引擎渠道，腾讯有蓝鲸，携程也有自己的，叫什么名字反正不叫海豚。

然后这些设计理念是类似的，首先整个自动化不是一蹴而就的，同时有人工和自动化工具都存在，我们遇到需要自动化的工单，我们会有一个Ticket  Service，工作流把这个要做的事情推到Ticket Service    ，然后对这张工单进行分解，分解成一台太机器和组件，把对应的推送到消息队列，然后有很多执行原子化任务的功能，它的工作是可以调用各种其他第三方的就口。

这些要做的任务非常明确清晰知道自己做什么，然后做完汇报给自己的Service，然后Service也会回报给Ticket Service，然后所有完成以后关闭掉这张工单。这套引擎做的不仅仅是服务器上线和变更，后面会讲到在所有的自动化里面，比如说一些故障处理中也会起到一些作用。

前面讲到自动化的历程，后面也介绍一下我们自动化的工具。这是我们现在整个运维团队应用比较多的工具，是可以以应用的维度，把配置中心和实时的状态显示出来，这是以集群为单位，每个集群有多少服务器，当前是在线还是离线的，每个服务器当前的CPU类型是多少，这些以应用把它整合起来查起来很方便。

包括和监控系统的对接，有多少异常数都可以看出来。

包括还可以做很多管理的操作，如果对于有权限的人来说，只要开单把服务器拉开，然后对容器重启，这对大部分运维工作直接通过这一个系统就可以完成。

在这当中我总结出一点，开发运维工具，或者是直接面对运维工程师的工具，最重要的是工具的开发者要是工具的使用者，只有这样工具才能好用，所以之前说到运维工程师50%的时间就是在写工具。

后面简单介绍一下我们在智能运维方面的探索，这方面刚刚开始。

一方面是故障自动修复，这方面首先我们是有一个故障的传感器，当监控系统报了某一个系统，某一个容器僵死了，然后我们会有一个规则引擎分析是否采取自动修复，这个修复是有一定的条件和规则的，往往我一台服务器出单点故障重启，如果是整个都出那肯定是代码的问题，怎样重启都没用，然后我有一个规则引擎有一个窗口，在这个窗口判断这是否可以自动修复，如果自动修复是不是单点比例，如果都满足就会触发修复器，然后自动修复。

然后检测故障有没有修复好，持续跟踪，在后续看这个故障有没有再次爆发，如果再次爆发认为自动修复没用，人工处理。但是绝大多数的都可以修复好，这可以节约运维人员很多的时间。

后面还有故障根源定位，我们之前说到耦合层非常抢，达到15层级。我们知道哪一层出了故障呢？首先理清应用关系，在框架层埋点，还有一些没有框架，那我们系统层抓TCP连接，哪台机器依赖哪台机器，我们也知道哪台机器在应用，可以找到关系。那有了这些我们在做定位的时候，可以转化为应用链，把每一条的路径都找到。

有了这个依赖链以后，当出现故障时，我们就可以根据故障报警的应用，在整个链条中告警的情况来分析哪个应用最有可能是这个故障的根源，我们也设计一些算法，比如说根据与时间片的相关性，比如说这几个应用报警是连续性，如果是连续性的，这一列故障可能性比较大。

如果是越处底层的应用，出故障的可能性越大。通过这些方式会进行面积算法，哪一个应用最可能故障。现在不一定非常准确，但是基本上可以至少排除掉很大范围，让我们知道重点关注哪些应用。这是我们在智能运维方面做的探索和尝试，应该说还是处于初步的阶段。

我分享的内容就这些，其实我有点感悟。应用运维工程师在我看来是比较乐趣，比较有技术挑战性的工作，如果大家对这个有兴趣也欢迎加入我们！

提问环节

主持人：感谢陈总！

高峻：刚才讨论能否做到40岁，我刚过40岁，十年前还在讨论30岁以后能不能做软件，我觉得40岁还在讨论这是一个进步，可能再过十年大家会讨论50岁能不能做运维，有一些焦虑和危机感是好事，但是不要被吓到。

陈劼：借着这个问题我讲一下，做运维，尤其是应用运维你完全不要担心。到时候不想做运维了，你换个新鲜的什么都可以做。

问：高总，您好，大家都在讨论40岁，我借这个问题说一下，这是伪命题，关键是你能做什么。我也差不多快满40岁了，我想我在美国时那几个老头可能五、六十岁，背个电脑跑外面培训我觉得也挺Happy的。我的问题是这样的，我们现在还在起步阶段，但是我还在构想这方面的自动化的引擎，我看里面更多的是去做  运维自动化这块的工作，我的问题是说我是否能够把这个工作流引擎扩得更大一点范围。从工作流来看的话，某种程度上你可以看成变成的东西及某种逻辑可以编程起来，然后再扩展到别的应用上是否会被滥用？

高峻：问题很好，工作流是很多年的一个模型和平台。在运维当中，很多地方都有工作意义存在，像OpenStack也有。用工作流是没有疑问的，你是不是做一套  体系出来，把大大小小不同层面的都放里面，这个好像不太好。比如说数据库我不用来存数据，但是否一个数据库管所有数据库呢？工作流的概念很简单，但是随着不同的工作场景是有变化。我刚才讲在运维场景它有特殊性，不同的环境中涉及到的数据是有差异，所以你会有不同的变革，所以这种作为大全到最后反而不要放太多在里面把思路搞乱。

问：携程是比较大，既有国内的用户也有国外的用户，我想了解一下，这种情况下怎样保障国外用户和国内用户都可以用并且是一致的，是否拉根专线？

陈劼：本身我们的部署是在国内，国外是通过CDN的，CDN有静态加速和动态加速，在这个应用交付的场景，用动态加速进行海外的，也是通过第三方的服务商来进行。

问：数据方面是怎样保证一致性的？

陈劼：如果你在国外建站就会存在这样的问题，你的应用服务其，你的数据库放国内那肯定是有问题，在国外用了CDN技术，就是反向代路，真正的是在国内的，只是做了链路优化，用了光纤等方式还原，但是出口在美国，这样用户体验比较好，也解决部署上如果在海外的话延时的问题。

问：之前看过58自动化运营也做了很多的工具，今天携程也做了很多的工具。所以工具的创建有没有标准，哪些做成工具，哪些做成小系统这样的，有没有这块的标准？因为如果不做一个标准的话，我觉得我做那个工具做着做着上百个上千个越来越多。

高峻：工具有时候一开始会让人误解的，5年前开始做运维方面的工具，以前我是做系统什么的，工具感觉比人矮了半截。但是实际上简单的是工具，复杂的才是系统，我们现在的工具是泛的，与很多接口打交道，你看这个接口很简单，它是一个工具，但是它后面是很大的系统。其实讲哪些工具不能做庞大，哪些要控制规模，这是所有软件发展都有这样的过程，哪些大了我缩小，哪些小了  我扩大，这都是有共性的。

陈劼：我是这样看这个问题，工具本身是会进化的，比如说最早人类猎食用弓箭后来用枪，你说怎样防止工具越来越来越扩大化，自然而然好的工具会替换掉坏的工具，不会存在工具越来越多，如果你做的事情很多，也确实需要很多的工具满足它。

问：刚才说了很多你们在业务结构方面的实践的想法，能否说得具体一点，在具体实践当中怎样进行转型或者是根据业务选择不同的。

陈劼：这块讲起来范围很大，你可以举一个你关注的点。

问：你们常用的。

陈劼：就是监控来说，开源当中用得比较广的是（英文），但是它到了一定的规模就没有办法满足监控的数量。现在我们正在替换中的是自研的，其实也是开源的一套自研系统叫（英文）。其他方面如果想了解的话可以加微信，因为应用运维的范围真的是非常广。

主持人：感谢两位嘉宾的精彩分享！（陈劼原创）

今天我分享的主题是有三大块：一个是介绍目前携程应用运维体系，我们自己做得比较好的实践；然后介绍运维自动化建设的历程，同时第三点介绍一下在运维方面所作的一些探索。

我们先可以来看一下数字，这是目前携程数据中心的情况。我们一共有4个数据中心，也有几万台服务器，有30多个BU和SBU，这就是相当于30多个子的小公司，每个公司都有不同的技术团队和架构。

当前活跃用户数是有5000多个，可能大家单单对数量没感觉，如果是在行业里面做比较的话，据我了解的情况，美团和点评合并以后加起来的应用数量是3000多个。

然后每天的请求是30亿次，这是指Requst。这是携程的技术站，我们用得最多的是Net和Java，除此之外还有一些小语言，VTS、NOD。当然用得最多的是Net，所以我们的服务器都是Windows，很多运维人员对Windows是深恶痛绝，因为它有很多的补丁还有不是开源的。

除此之外还有什么挑战呢？为什么主题叫洪荒之力的生存指南。一个是业务要求技术架构支撑业务10倍的成长，最近根据统计，流量每年翻番100%成长，业务变化非常快，平均每周有4000多次发布次数。

我们第三点也是有携程特色的，部署模式是单机多应用，一台Windows主机上部署6个以上的应用，多的话一台机器部署40—50个都有，这给运维带来很大地困难。

单机多应用比单机单应用多维度。我了解到的行业绝大多数公司都是单机单应用。然后我们的耦合度非常高，依赖层级可达15+，就是A依赖于B，B依赖于C，最多的应用是依赖曾级可达15。

所以对可用性要求高，目标要求是99.9%，是行业内比较高的标准，最近一年我们是达到了这个目标。特别是今年的一季度，我们达到了99.99%，当然这当中是需要一些运气的。

很多人不太了解应用运维是干什么的，什么是应用运维工程师，在我的了解你，应用运维工程师主要是系统运维与产品研发之间的桥梁，要搭建整个配置和交付的路径，把我们研发开发出来的产品，稳定可靠地交付到用户手中，并且保持良好的用户体验。

举个例子来说，把我们的业务看成是高速公路上行驶的汽车，系统运维就是汽车的服务厂商，研发就是产品，是这一辆车上的乘客。

对于运维来说，既是这一辆车的司机也是维修工，不仅操作这一辆车避开各种故障，也要负责加油、换轮胎甚至是升级改造的工作。第二个定位是网站可靠性工程的实现者，现在比较火的是SRE概念，所谓SRE是把运维当成软件产品来做。

工程师并不是系统管理员，他实际上是要把运维工作服务化、产品化，并且通过技术手段实现它。所以说对于应用运维工程师来说，是非常需要全面的知识和技能，我这边例句了硬件、网络、存储、应用交给、CDN、操作系统、软件开发等都要知道。一个开发人玩懂前端、后端全站工程师，那对运维来说，就是全站工程中的战斗机。

刚才是把运维当成软件来说，软件工作量占了运维工作很大地比例，基本上50%。下面我们看一下我理解的应用运维工程师的目标，稳定性不多说，所有的运维一切根本就是稳定性。

没有稳定性，其他做得再好也无用。性能也是我们关注的一点，页面打开慢了一点，你的转化率就下降，就要求我们的网站不仅仅是能用还要好用。

在互联网行业比较重要的是效率，不仅是产品迭代快，交付效率也很重要。还有一点是成本，因为任何公司都会比较在意成本，那对于运维来说成本是有两部分，一个是基础设施、网络服务器等硬件成本，第二个是运维工程师的人力成本。

运维我们一个是要通过架构改造，系统的架构优化，提高资源利用率，把硬件成本降低下来，同时通过把一些自动化，使我们运维工程师的人力成本降下来。也就是运维工程师的人数增长不能与业务增长一致的，要低于业务增长的程度。

还有一点是安全，对于应用工程师来说，每个人都是有能力把网站搞垮的，所以能力越大责任越大，所以安全对于应用运维也很重要。安全不仅仅是帐号要保存不能随便泄露，还有开发时要保证充分的授权设定，有没有并发操作的限制，一次性操作多少机器。有了这些，才能避免被人滥用或者是有意地滥用。

下面介绍一下携程应用运维开展的工作，也是我们觉得比较好的实践。一个是运维评审的机制，每一个应用上线前，我们会请研发的工程师和运维工程师在一起评估应用。

刚才我们说有30个SDU，很多工程师对于我们研发的环境和规范并不很了解，很有可能他的应用有缺陷，高可用性没有考虑到等，这方面应用运维工程师与它沟通，帮助它设计部署架构，同时也会帮助它评估，像你这样的应用上线需要多少资源。

另外我们还会问一些问题，进行它应用的非功能性的需求，比如说应用本身是不是无状态的，因为有状态就代表你的高可用。

对于非功能需求要弱依赖。包括还有熔断机制，还有服务降级。历史上我们出现过当酒店的点评信息出不来，服务信息出不来，导致酒店的详情页都打开不了，所以我们认为应用运维工程师是可以帮助研发工程师考虑这些问题。

第二个是对容量管理，这关注到刚才我们所说的稳定性、性能以及成本的考虑。需要我们做到的是说应用的资源既是合理的不会浪费的，在它增长时我们也能及时地为它补充资源，确保它的性能不会受到影响。

这块我们怎样来做呢？

首先我们建立预测模型，对它进行容量分析，说白了就是把应用和业务指标和系统指标关联起来，业务和系统的指标最典型的就是承载的请求数量和响应时间，系统也有很多，CPU使用率，带宽等，我们会跟踪服务器上指标的关系为它建立模型，不同的应用模型差异很大，因为根据应用本身相关算出来的模型也是不一样，我们都会通过对它的跟踪和计算把这些数据分析出来，建立模型以后就可以推测，当业务量增长到一定的程度，需要多少的资源满足它，而且这些分析是需要自动去做的，从应用去做难以跟上。

模型做出来还要验证它，怎样知道这个模型是否准确，特别是有一些应用量小数据波动比较小，这时候模型的可行性很难确保高。

我们会做一个在线压测，会调整单提服务器的权重，让它承载的比例不断变化，然后跟踪刚才所说的业务指标和系统指标，一旦业务指标达到我们设定的阈值，我们认为它很有可能对业务产生影响时我们会停止，通过这样的方式验证我们的模型是否准确。

有了这一模型我们很容易跟上增长，包括有时候一些营销活动双12的时候，只要业务给一个故障量，大概用户流量增加多少，我们就知道需要准备多少的资源应对。

这套体系出来以后我们也是做到全自动扩容，不需要研发人员提出，当每天计算的容量到一定量级需要扩容了，我们就会发邮件，应用服务器要进行扩容了，那就直接进行扩容。给大家看到的这份报表每天都可以查到的，根据时间的不同变化，当前的容量。

还有通过业务  来做一个DR容灾站点。做容灾站点，首先我们的规模很大，单数据中心容纳不了所有的业务，所以我们希望做到两点。

第一个是让单个数据中心具备独立运行所承载业务的能力，任何数据中心挂，其他数据中心的业务部受影响。另外还有一些核心业务，会在多个业务中心同时部署，当某个数据中心挂的时候，需要在其他数据中心也能承载这样的业务，确保业务可持续性。

这样我们会把核心业务包括基础的组建，框架和支付、风控等这些业务包识别出来，在多数据中心进行部署。

并且我们是在多数据中心可以实现流量灵活分配，而且还可以做到快速切换，有些业务重构或者是上的时候还可以做蓝绿发布，先让一个流量中心切掉，然后发布以后通过以后再把流量放过去。

当涉及到很多应用，应用回馈比较慢，然后把流量切到原来的数据中心，业务很快就恢复到原来的状态。然后我们定期进行切换演练，确保有效，这些都是在凌晨做这些事情。

还有携程如何处理网站的故障，这张图是我们的NOC所在的控制中心，这上面最显眼的是有32个大屏幕，每一个屏幕显示很多的监控指标，并且这些是配备很多的监控模式是可以随时切换的。

当我们产生一些比较严重的故障时，比如说订单受损或者是页面大不开，时间比较长了，我们会升级到高优先级的故障，因为有7×24小时的NOC，会立即召开电话会议。

电话会议核心的是把应用运维工程师叫进来，也会叫一些对应的研发的工程师，但是往往比较复杂的故障，是应用运维工程师起到比较大地作用，因为应用运维工程师对整个网站的基础架构比较了解，同时对我们的监控工具、日志分析工具都应用熟练。

然后排障还会用到IRC工具，大家知道这是一个经典的聊天软件，我们发现故障处理时非常好用，能够做到多人的实时交互，我们在这上面做了改造，我们通过复制粘贴在IRC里面贴图，然求还用IRC输入指令，你只要输入某某服务器的指标，然后IRC直接调出报表。

还有一个是COE（持续卓越运营），这是对故障的回顾，我们要求事故的责任方对原因做责任分析，这个要具体到引发故障的那一行代码，这当中不仅仅是对于故障的根本原因，也要看整个环节当中有没有其他的地方和工具进行改善的，有人说你的应用挂了我也挂了，我们都会去看，把COE总结出来以后，一个是改进措施有人跟进，确保类似故障不会发生第二遍，然后会在整个技术团队分享，因为我们有不同的SDU，希望大家从当中都学到不同的东西。

刚才主要是介绍携程在整个技术保障中心的实践，接下来介绍一下携程运维自动化的建设历程。

首先给大家看一下，这是数年前应用运维工程师的日常，服务器安装、应用环境配置、负载均衡DNS配置变更，监控绳检处理、CMDB信息维护、应用配置信息维护，还有用户需求响应，我要查一下日志，看一下成员状态有没有宕过。我总结下来是需求驱动、响应式、手工劳动。基本上是累成狗，不知道现在多少在座的会会心一笑。

整个运维自动化建设分几个阶段，第一阶段是工具化，工具化的核心是先把双手解放出来，用一些工具和界面远程操作代替手动操作。举一些例子，以前运维人员最讨厌变更，变更是文字操作，但是很多的变更是很类似的。

所以我们做了变更自动生成的工具，把一些关键的属性变进去，就会自动生成，同时做一些校验，指向对不对，目标能不能拼得通。然后远程操作，以前所有的操作都是登到服务器一台台做，利用Windows本身和WSA的机制，把这些远程操作掉。

还有批量处理外挂，有时候一些故障，10台、20台机器报警，最早我们一个一个处理，我们批量处理外挂，把相同引起的事件一次性关闭。这里面没有高大上的东西，也没有很系统化地做，但是这也很重要，把双手、时间解放出来才能投入到后面SRE的建设。

第二阶段是数据化，因为我们是应用运维，我们要建立以应用为核心的配置数据库，要把服务器管理进化到应用管理，原来的维度是单台服务器，因为每个应用都会有监控的指标，你要上新的就要扩容了，我要怎样配置吗？把以前的那台指标挖出来参考一下。

我们把应用维度，把应用级的集群集合起来然后有一个库的概念，把配置、安装、组件等都到这个库上，然后应用扩容时非常简单，这后面说的是全自动化基础，如果没有数据库，最早的CMDB做不到。而且CMDB是人工维护，准确性和时效性很难保证。

所以我们核心的是数据更新要自动的，自动的一个是我做完立即推动数据库，第二个是定时采集，确保我们的数据是很准确，并且是很实时的。

第三个阶段是做平台化，最主要的是完全做到自动化、无人值守。中间很重要的一点是引擎渠道，腾讯有蓝鲸，携程也有自己的，叫什么名字反正不叫海豚。

然后这些设计理念是类似的，首先整个自动化不是一蹴而就的，同时有人工和自动化工具都存在，我们遇到需要自动化的工单，我们会有一个Ticket  Service，工作流把这个要做的事情推到Ticket Service    ，然后对这张工单进行分解，分解成一台太机器和组件，把对应的推送到消息队列，然后有很多执行原子化任务的功能，它的工作是可以调用各种其他第三方的就口。

这些要做的任务非常明确清晰知道自己做什么，然后做完汇报给自己的Service，然后Service也会回报给Ticket Service，然后所有完成以后关闭掉这张工单。这套引擎做的不仅仅是服务器上线和变更，后面会讲到在所有的自动化里面，比如说一些故障处理中也会起到一些作用。

前面讲到自动化的历程，后面也介绍一下我们自动化的工具。这是我们现在整个运维团队应用比较多的工具，是可以以应用的维度，把配置中心和实时的状态显示出来，这是以集群为单位，每个集群有多少服务器，当前是在线还是离线的，每个服务器当前的CPU类型是多少，这些以应用把它整合起来查起来很方便。

包括和监控系统的对接，有多少异常数都可以看出来。

包括还可以做很多管理的操作，如果对于有权限的人来说，只要开单把服务器拉开，然后对容器重启，这对大部分运维工作直接通过这一个系统就可以完成。

在这当中我总结出一点，开发运维工具，或者是直接面对运维工程师的工具，最重要的是工具的开发者要是工具的使用者，只有这样工具才能好用，所以之前说到运维工程师50%的时间就是在写工具。

后面简单介绍一下我们在智能运维方面的探索，这方面刚刚开始。

一方面是故障自动修复，这方面首先我们是有一个故障的传感器，当监控系统报了某一个系统，某一个容器僵死了，然后我们会有一个规则引擎分析是否采取自动修复，这个修复是有一定的条件和规则的，往往我一台服务器出单点故障重启，如果是整个都出那肯定是代码的问题，怎样重启都没用，然后我有一个规则引擎有一个窗口，在这个窗口判断这是否可以自动修复，如果自动修复是不是单点比例，如果都满足就会触发修复器，然后自动修复。

然后检测故障有没有修复好，持续跟踪，在后续看这个故障有没有再次爆发，如果再次爆发认为自动修复没用，人工处理。但是绝大多数的都可以修复好，这可以节约运维人员很多的时间。

后面还有故障根源定位，我们之前说到耦合层非常抢，达到15层级。我们知道哪一层出了故障呢？首先理清应用关系，在框架层埋点，还有一些没有框架，那我们系统层抓TCP连接，哪台机器依赖哪台机器，我们也知道哪台机器在应用，可以找到关系。那有了这些我们在做定位的时候，可以转化为应用链，把每一条的路径都找到。

有了这个依赖链以后，当出现故障时，我们就可以根据故障报警的应用，在整个链条中告警的情况来分析哪个应用最有可能是这个故障的根源，我们也设计一些算法，比如说根据与时间片的相关性，比如说这几个应用报警是连续性，如果是连续性的，这一列故障可能性比较大。

如果是越处底层的应用，出故障的可能性越大。通过这些方式会进行面积算法，哪一个应用最可能故障。现在不一定非常准确，但是基本上可以至少排除掉很大范围，让我们知道重点关注哪些应用。这是我们在智能运维方面做的探索和尝试，应该说还是处于初步的阶段。

我分享的内容就这些，其实我有点感悟。应用运维工程师在我看来是比较乐趣，比较有技术挑战性的工作，如果大家对这个有兴趣也欢迎加入我们！

提问环节

主持人：感谢陈总！

高峻：刚才讨论能否做到40岁，我刚过40岁，十年前还在讨论30岁以后能不能做软件，我觉得40岁还在讨论这是一个进步，可能再过十年大家会讨论50岁能不能做运维，有一些焦虑和危机感是好事，但是不要被吓到。

陈劼：借着这个问题我讲一下，做运维，尤其是应用运维你完全不要担心。到时候不想做运维了，你换个新鲜的什么都可以做。

问：高总，您好，大家都在讨论40岁，我借这个问题说一下，这是伪命题，关键是你能做什么。我也差不多快满40岁了，我想我在美国时那几个老头可能五、六十岁，背个电脑跑外面培训我觉得也挺Happy的。我的问题是这样的，我们现在还在起步阶段，但是我还在构想这方面的自动化的引擎，我看里面更多的是去做  运维自动化这块的工作，我的问题是说我是否能够把这个工作流引擎扩得更大一点范围。从工作流来看的话，某种程度上你可以看成变成的东西及某种逻辑可以编程起来，然后再扩展到别的应用上是否会被滥用？

高峻：问题很好，工作流是很多年的一个模型和平台。在运维当中，很多地方都有工作意义存在，像OpenStack也有。用工作流是没有疑问的，你是不是做一套  体系出来，把大大小小不同层面的都放里面，这个好像不太好。比如说数据库我不用来存数据，但是否一个数据库管所有数据库呢？工作流的概念很简单，但是随着不同的工作场景是有变化。我刚才讲在运维场景它有特殊性，不同的环境中涉及到的数据是有差异，所以你会有不同的变革，所以这种作为大全到最后反而不要放太多在里面把思路搞乱。

问：携程是比较大，既有国内的用户也有国外的用户，我想了解一下，这种情况下怎样保障国外用户和国内用户都可以用并且是一致的，是否拉根专线？

陈劼：本身我们的部署是在国内，国外是通过CDN的，CDN有静态加速和动态加速，在这个应用交付的场景，用动态加速进行海外的，也是通过第三方的服务商来进行。

问：数据方面是怎样保证一致性的？

陈劼：如果你在国外建站就会存在这样的问题，你的应用服务其，你的数据库放国内那肯定是有问题，在国外用了CDN技术，就是反向代路，真正的是在国内的，只是做了链路优化，用了光纤等方式还原，但是出口在美国，这样用户体验比较好，也解决部署上如果在海外的话延时的问题。

问：之前看过58自动化运营也做了很多的工具，今天携程也做了很多的工具。所以工具的创建有没有标准，哪些做成工具，哪些做成小系统这样的，有没有这块的标准？因为如果不做一个标准的话，我觉得我做那个工具做着做着上百个上千个越来越多。

高峻：工具有时候一开始会让人误解的，5年前开始做运维方面的工具，以前我是做系统什么的，工具感觉比人矮了半截。但是实际上简单的是工具，复杂的才是系统，我们现在的工具是泛的，与很多接口打交道，你看这个接口很简单，它是一个工具，但是它后面是很大的系统。其实讲哪些工具不能做庞大，哪些要控制规模，这是所有软件发展都有这样的过程，哪些大了我缩小，哪些小了  我扩大，这都是有共性的。

陈劼：我是这样看这个问题，工具本身是会进化的，比如说最早人类猎食用弓箭后来用枪，你说怎样防止工具越来越来越扩大化，自然而然好的工具会替换掉坏的工具，不会存在工具越来越多，如果你做的事情很多，也确实需要很多的工具满足它。

问：刚才说了很多你们在业务结构方面的实践的想法，能否说得具体一点，在具体实践当中怎样进行转型或者是根据业务选择不同的。

陈劼：这块讲起来范围很大，你可以举一个你关注的点。

问：你们常用的。

陈劼：就是监控来说，开源当中用得比较广的是（英文），但是它到了一定的规模就没有办法满足监控的数量。现在我们正在替换中的是自研的，其实也是开源的一套自研系统叫（英文）。其他方面如果想了解的话可以加微信，因为应用运维的范围真的是非常广。

主持人：感谢两位嘉宾的精彩分享！（陈劼原创）