卓越运维之路

白凡

分享：雍浩淼-携程
编辑：白凡

讲师介绍：携程技术保障中心的雍浩淼，主要负责携程网站的运维工作，运维经验有十年，是携程发展的见证和参与者，对走过的历程和踩过的坑都非常了解，希望今天跟大家介绍一些发展历程，希望对他们有帮忙。

1. 运维发展的历史背景

卓越的定义是持续改善不但优化的过程，这个大楼是携程上海总部大楼的夜景。回顾一下历史，携程1999年成立，到现在差不多19年的历史，同期成立的还有阿里，2003年在纳斯达克上市，四年的时间登陆纳斯达克。2000年到2002年互联网行业有一个很大的事件，我不知道大家了不了解，很早的互联网行业知道，2000年到2002年是互联网泡沫破裂的时候，这个泡沫是怎么样破裂？2000年3月纳斯达克指数5132点跌到了2002年10月的1273点，跌了75%的市值，是非常大的影响。

同期在2000年初美国投资环境非常不好，很多公司因为诚信问题破产，有的财务造假等一系列的危机。最典型的是安然和世通，安然是美国最大的能源公司，在2000年底宣布破产，创造了美国有史以来最大规模的破产案，结果没过半年又出现了世通，也是因为财务造假破产，他刷新了安然的记录。
很多美国人是把自己的收入放在股市作为养老资金的投入，这个对美国民众和投资者信任影响非常大。美国国会要求所有在纳斯达克上市的公司必须要强制执行Sarbanes-Oxley法案，这个法案非常苛刻，希望用一种机制和流程对企业进行内部控制，包括企业信息系统、IT系统变更管理流程、发布，内审的数据需要CEO和CFO签字，如果出现问题会有很大金额的罚款。

携程作为互联网上市公司也需要合规，当时的合规框架比如说COBIT、COSO、BS7799、ITIL、ISO17799，COSO是面向公司治理，ISO1799、BS7799是面向公司治理，携程是选择ITIL，ITIL管理体系比较成熟，是IT管理的最佳实践规范，涉及IT日常运维过程中很多方面，大家熟知的十个领域，事件管理、问题管理、流程、服务台都有覆盖，当时选择了ITIL作为携程运维管理框架，一方面希望合规，符合Sarbanes-Oxley法案的要求，一方面提升运维的成熟度和服务水平，当时互联网没有运维规范的说法。

2. 变更管理和ITIL实施带来的效应

2.1 ITIL上线需求

这是一个比较典型的ITIL主要流程关联关系图（见下图），实际上是非常典型的，携程在落地ITIL的时候是2004年和2005年初，ITIL的概念在国内比较新，没有太多的成功案例可以借鉴、参考。公私要做这个事情的时候是自上而下的，首先要通过审计，通过Sarbanes-Oxley法案的要求，一个是被有一些咨询公司过来做一些顾问咨询，另一方面是同ITIL的官网买一些电子书，学习ITIL的理念，看ITIL怎么落地等。

比如说最开始要落地CMDB，CMDB应该放什么内容，这些CI项应该有哪些属性，CI之间的关系是怎样的？就变成涉及到一个深入的问题，比如说有一个主机，我网卡是不是需要作为独立的CI项落地进去？网卡和交换机的关系是否要作为CI项和关联关系进入进去，这都是面临挑战的问题。

2.2 变更管理

变更管理也是在落地时的分歧和讨论特别多的点，比如说定义什么是变更？比如说安装一台交换机、操作系统，重启计算机算不算变更？这个概念上大家有很多分歧，其实当时也有很多分歧，最后还有一个案例可以跟大家分享一下。当时落地ITIL的时候，整个过程很辛苦，很多东西都是不确定需要大家讨论确定，因为没有参照的成功经验。有一个问题，当时落地这个是通过审计，所以强调的是“法无授权即禁止”，如果这个事情没有相应的批准就是不允许的，当时管得非常严。

落地ITIL以后审计是通过了，通过一轮一轮内部审计、合规、用户访谈，最后通过审计。审计通过以后发现做完ITIL以后有“四有”：

• 有流程，很多事情都有流程，事件、配置、变更、问题、采购一系列都有流程，配置了专门的流程团队，做ITIL的架构落地时，公司对这个架构做了调整，专门有一个流程治理团队负责流程的定义和制定，这个团队是非常强大的，很多情况他是有类似于一票否决权。
• 有规范，你能想到一切的东西，配置、巡检、安全加固的规范、OS配置规范、容器配置规范、安全加固规范都有。
• 有文档，文档需要落地，我们任何一个新的系统上线一般必须交四篇文档：架构文档，应用系统是什么样的架构，整体的逻辑关系是什么样的，包括物理架构是什么样的，配置文档、维护文档，平时维护好系统要做什么事情，都规定得非常清楚，排错文档。对于相对比较成熟的系统会把经验积累下来，新的基本上很难。
• 有记录，所有的行为对生产环节的变化都需要有记录，为后续能进行跟踪和审计，这是非常重要的需求。

2.3 ITIL带来的负面影响

大家看上去这些东西是很美好的，该有的都有了，一切都是按照所预期的方向运转，这个过程中有很多的问题：

1，流程过重，当时的方式是强调以控制为结果，流程是控制的工具和方法，尤其是涉及到多个角色都会由流程控制，很多角色在整个流程里所发挥的意义和价值并没有那么大，可能做一些审批和简单的干预，很多节点并不增值，可能看到点一下，并不起到什么作用。

2，运维的模式是流程驱动的方式，既然定义了日常的工作应该怎么做，工程师就是按照定义的规则来做，如果没有定义的话该不该做？这就是一个问题。举一个很简单的例子，有一次一台数据库服务器僵死了，出现问题应该马上干预，比如说重启，处理这个故障的工程师，因为是半夜，他遇到这个问题他第一时间不知道该怎么做，因为重启一台服务器是属于变更，重启僵死的服务器也是变更，要打电话给CAD说我要做什么事情，CAD会问你重启服务器有什么影响？服务器已经死掉业务已经有影响了。获得授权花了20分钟，这个时间耽误了。按照现在的处置原则应该是第一时间做数据恢复，后面补一个工单就可以了。有一些不太熟的工程师可能会被吓住。

3，缺乏工具的支持，ITIL的设置是很完整的，力度还是比较弱。操作流程需要人来执行，整个流转也需要人来执行。比如说打服务器的补丁，携程很多服务器是基于Windows，Windows服务器不需要定期打补丁，基本上是每个月打一次，按照之前的方式每月打一次，一打一个月，很辛苦，基本上要一个员工连续打两个月他就会离职。流程流转需要人盯着，工作单进展到什么程度，要看工单的进展和状态，更新工单的进度，比如说已接受、已处理、已完成的状态，如果你许多及时做这个事情会有专人帮你收集数据告诉你哪些工单没有完成，整个过程缺乏工具的有效支持。

4，技术人员非技术负担重，大多数人员并不喜欢写文档，文档变成强制规范以后，要维护这个文档需要付出很多的精力，这种标准的SOP要反映当前实际的运维情况，这是非常苦难的事情，因为需要不断的更新，因为环境在不断的变化，文档的工作量是非常重大的。CMDB的准确性，既然建立CMDB必须保证CI配置项的准确性，当时是由人来保证的，人来进行录入，人来进行校验，人来进行更新，是这样的方式，这个工作量也是非常大的。又提到变更，比如说工程师需要起草一个变更，有一个计划、影响范围、实施的详细计划、回退的方案，这是变更必须具备的变更要素，假设要做一台交换机的操作，理论上把设备影响的对象关联起来，重启服务器，需要把服务器的应用做关联，这是一对一的关联。现在的关联不是重启服务器。手工管理的动作确实很复杂，工具上支持还是比较弱，生成批量列表是很痛苦的，这是当时的痛点。

5，技术导向不太足，工程师的考核主要侧重于流程的执行度、OLA的Miss率，SOP文档有编写质量，标准变更的提交率等，包括你如果通过ITIL认证是有加分的，这是对流程认可的标志。技术导向来看，鼓励工程师的创新和自动化是并不足够的。

简而言之，大家谈到技术流程和人员，相当于一个板凳的三条腿，流程太长、流程太大导致板凳不均衡。

在2012年前这个时间节点，携程运维主要是基于ITIL，之前携程是鼠标+水泥的模式，30%的预订是PC，70%是电话，大部分用户通过电话的方式下单，当时你想要估算一下携程的股价、走势比较简单，只要数一下携程预订人头数就行了，这是预订方式。当时技术占比也不高，Linux大概20%左右，80%IT方案为商业产品。以流程为中心，控制为目标整体的过程。当时运用ITIL的原因是因为Sarbanes-Oxley法案。过程中有一些变化，流程还是主导作用的。

3. 业务战略变化带来的运维变革

2012年底詹姆斯重新回归，鼠标+水泥砖成的大拇指+水泥，奉行移动优先战略，所有的东西优先于移动平台支持，也同时做了很多的事情，大幅增加了对技术的研发投入，对组织架构有了很大的变化，技术部架构有了很大的调整，人员数增长很快，包括产品迭代的周期大幅缩短，当时的战略变化产生这一系列的要素变化。

3.1 资源交付效率矛盾

主要矛盾非常凸显，最典型的是资源交付效率问题，新业务要上线需要资源的提供和支持，当时资源创建过程中基本上是手工完成的，运维对外声称SLA是两周，两周交付资源肯定是无法满足线上需要，大家肯定很清楚。要解决这个问题怎么办？大家都很清楚工具化、自动化的方式来释放提升效率。当时要做这个事情怎么做呢？一个是有没有这样的人员、有没有这样的技能，一方面人才结构，从外面招更多有经验的工程师，对自动化运营有更深刻认识和理解的工程师，鼓励现有的工程师去学习自动化运维，或是开发自动化运维的工具。我们招聘很多人员，培养他们工具开发的能力，做人才结构的调整。工程师文化的宣传，以前偏向于流程逐渐片向向工程师文化的变化，鼓励工程师更多发挥自己的能动性和积极性，用技术解决生产问题，包括绩效考评的引导也是这样，以前偏向于流程方面，偏向于创新和技术调整或是效率优化为指导方向。资深工程师会定一些全局的规范，开发一个工具的话，基本规范是什么？比如说日志怎么记录，用什么样的方式通讯，比如说要接入统一认证，接入OS进行授权，包括用户体验界面要相对一致，这些通用的规范。清楚以后由各个团队自己解决自己的问题，自己的痛要自己解决，要用双手提升自己的工作效率。

这里是携程的业务服务器上线的十个步骤，为了优化上线步骤，每个步骤的耗时以及衔接点的耗时都会展现出来，对于每个环节做优化，SLA上线时长2周到2天，2天到2小时，2小时到分钟级，现在已经做到相对比较极致的状态。
资源池化，提升效率虚拟化是必须要做的事情，很多研发用惯了物理服务器不太喜欢用虚拟机，对虚拟机很排斥，现在大家对VMs的认可度比较高。

3.2 应用部署矛盾

这块也是非常大的问题，当时携程是采用Train的方式，每周发一次车，要提前上车，错过就要等下一班，需要之前有详细的SOP计划，发布的周期会很长，也开了一个口子，可以紧急发布，紧急发布为了解决Bug或是高优先级的case，很多研发赶不上SOP，又不能Miss上线点，紧急发布占了整个发布流程很大一部分的比例，都是不合理的现象。
这个问题怎么解决？环境的梳理，要完成这个花布流程，从开发设计到生产。测试环境的优化，环境本身可能会有不一致，用户PC发布测试环境会遇到很多麻烦，这个过程会调试很长时间，环境的不一致、数据不一致起到的问题，当时成立了一个团队解决环境一致性的问题和数据的一致性问题。

应用部署的模式，刚才说了，你要发布快的话，按照单应用发布，是最好的，携程在这方面交了不少学费，包括持续流程的重构，把应用部署架构重新翻一遍的过程，这里不再赘述。单机单应用是非常重要的部署方法，发布流程和工具有很多的故事，暂时一下子说不清楚，此处省略一万字。
应用部署的模式，我相信做运维管理，特别是做应用运维，这个应用怎么部署？携程是一台机器部署多个应用，不知道在座有没有一台机器部署多个应用的场景？还是很多，很常见。一台机器部署多个应用主要原因是成本，成本是主要的因素，除了成本以外，开始不知道这样在最开始建设CMDB的时候往往是以资产为中心的，管理的对象是一个资产，服务器是一个资产，资产上关联哪些应用，是这样的关系，不是应用的角度，应用不是资产是虚拟的东西。如果要实现快速的交付和部署，持续交付能力要非常顺畅的话，需要把CMDB服务器以资产为核心的模式转为以应用为中心的管理模式，才能达到比较好的效果，当时携程一台主机上有多个应用，并且这个应用回用多个端口，大家可以知道问题在哪里。你是以物理服务器为单位创造的集群，拉出一台服务器，相当于是把物理机上的所有东西都拉出去。完成一个发布，发布A应用的话，首先是把Host1拉出去，如果要发布B应用的话，不能把Host2拉出去，要把Host1完成之后才行，所以发布的效率非常低。
单机、单应用很重要，重要的事情说三遍，单机单应用，有一个限制条件是成本怎么办。给你一台虚拟机，单机、单应用还可以。一盒一机还是有点浪费，给你一个容器单机单应用，它可以更小。如果你要真正实现单机单应用的部署，并且差钱的情况下，容器是最好的解决方案。基于JAVA的应用是跑单机单应用的模式，还有基于VMs的方式，会限制容器上的用户数，比如说限制不能超过十个或是更少，这样便于更好的管理。排障、问题处理有很好的解决方式，现在CPU很高，什么引起的？需要知道是哪个应用，应用调用关系之间是以IP的方式出现，原端口是一样的，这个时候需要做数据抓包，看应用之间的关系怎么分析。携程的用户团队基本上大多数人会做分析，这是两个必备的技能，很多开发人员不一定会，分析的时间很长，一个是专业性要求很高，分析故障的时候时间很长，毕竟故障已经产生了。

3.3 可用性矛盾

发布故障、架构缺陷、技术方案、变更工艺、代码Bug、容器问题、外部因素、硬件故障都是，掉电也是可用性影响的因素。怎么解决这个问题？

1、故障解决机制，一个是NOC中心，携程成立故障响应机制，服务台变成NOC中心的方式，携程的故障处理传导链很快，有一个微信群，里面有所有的研发HOD、BU的CEO在里面，出现一个故障的时候，特别是高级的故障，全公司的大佬都知道，这个时候处理故障的压力是非常大的。优化监控和提升完整性，基于Linux监控效率和及时性不能得到满足，我们成立了一个秒级的监控，覆盖的监控项是1000万以上的监控对象，提升定位能力不多说，一直在提升。

2、消除架构的SPOF单点，架构里面的缺陷是什么，单点故障是什么，需要做这样的优化和调整，整个架构这块主要是面向失效的设计，这是非常重要的，代码必须面向失效的设计。现在建立了应用架构的评审制度，携程在研发设计阶段介入，帮助研发评估Ops的架构，上线以后安全性问题、部署问题、容量问题、不可维护问题，变成强制标准之前，运维会介入研发的设计，会看这样的架构，把非功能导入。这些都是架构问题。

3、工具，工具一个是要更多的自动化，因为只有更多的自动化才能防止错误的产生。

4、管理，RAC复盘机制，出现问题应该怎么总结？其中有一条很好的方案，我们会用非常客观、公正的方法总结故障，故障为什么发生？发生的原因是什么，架构原因、人员原因、工艺的原因还是因为什么样的因素导致，如何再次避免，如何从故障中总结出一些模式，能把故障的发现和诊断程序化实现变成自动的模式。代码质量和工艺不用说。现在容量管理机制线上自动压测的机制，我们会对线上的应用做随机压测，如果发现应用响应时长有变化，就是应用的容量基准，用这个来做容量规划。

5、文化，ThinkTwice，我们融合到ThinkTwice里，主要是以案例的方式说明变更、故障对生产环境造成的影响，主要是培养技术人员对生产环境的敬畏之心，其实就是意识的培养，所有人都必须通过ThinkTwice的考核。

可用性有对Ctrip有多重要，每秒宕机时间影响是2万/秒。谈到可用性，怎么测定公司的可用性？需要有一个方法，要建立一个指标和KPI度量，现在通过ATP，Availability To Promise的模型，它实际上是结合用户时长和定单比例，结合权重方式计算出可用性。怎么求一个BU的ATP可用性？
实际上是求故障面积，假设中断时长是10分钟，订单下跌100%，中断时长就是十分钟，订单下跌60%，中断时长就是六分钟。谈到故障的时候我想起比较铸型的理论--莫菲定理，莫菲做导弹加速落地出现一个故障，是因为一个技术人员把仪表盘装反，他总结一个教训，任何事情只要有两种以上的方法能完成，其中有一种方法是让它产生故障的，一定会有人采用这个方法。后来被反复证明过的过程，他强调的是，如果一个事情可能往坏的方向发展，即便概率很低也一定会发生，小概率事件必然发生。

携程在2015年5月28日遭受了网站重大的众创，很多人都知道528事件，刷屏刷得很厉害，GOPS的网站也刷屏很厉害。如何避免再次发生、大面积故障如何快速互相、能在多长时间内重构一个网站？后续我们做了一系列的事情，这个Case就是因为发布系统代码Bug，对全员培训是非常重要的，让大家对生产环境具有敬畏之心的意识。这次对全员产生了很好的教育。我们成立DR Program，建设多IDC DR Site，还有一套工具可以在分钟级完成数据中心切换。以往多次故障发生都起到了很重要的作用。
建立CD Program，公司花很大的力气做这个事情，把携程整个应用系统重新翻一遍，单机单应用、单机多应用如何实现按应用进行部署，如何往单机单应用的方式过渡和部署，花了很多的精力做这件事情，在座如果有单机单应用的部署场景以后也会面临同样的问题。

3.4 去技术债

对不断发展的公司是一定面临的问题，技术债是一种妥协，为了实现短期的目标，或是当时的利益做的一些技术方面的妥协，最后会来一个坑，你看一下哪些是会做技术债的，如果背着债去前行是非常重的，很难走得很快，一定会落人家半拍，这个问题必须解决，如果不解决的话会损失很多机会，会损失很多未来快速发展的机会。

携程去技术债的问题，这个过程很痛苦，但是非常考验技术主管的决心、意识力和智慧，真的是很难的事情，一旦消除这些技债的话就会变得很轻松，可以大踏步的往前走。
这是携程运维技术鼻息发展到现在的场景，这里面太多了，100多项内容不细展开，有机会再单独分享。

现阶段是基于DevOps的方式，携程业务是拇指+水泥，90%的订单来自于手机，10%预订是PC+电话。Linux占比超过70%，技术站的类型比较丰富，Java、PHP、Go+Nodejs，windows+ net，MYSQL大于60%。

每周5000次的发布数据，数据99.978%，成本是公有云的1/2，应用数据8000以上，端到端的交付做到秒级。
这是现在目前新的计划，一个是AIOps，主要的方向是做异常检测和智能告警，携程每天有100T的监控数据，大量的数据可以做数据分析和关联，这部分已经有一定的突破，对于故障智能关联方面的准确度高于50%，每天线上的
故障自动关联可以发现50%以上。

3.5 部分新进展

Docker/SDN，Redis /DB容器化，自研SDN POC，会在新的数据中心。成本，应用画像标签，标识本身的属性，哪些是亲和性和非亲和性的，同时也是实现Online和Offine混部资源的提升。

3.6 国际化战略

2017年携程宣布海外的战略，海外如何提供有效的支持，现在是要投入很多精力的问题，目前的做法是把携程私有云和海外的公有云打通，海外的需求用海外云平台交付，现在已经在海外部署的站点、覆盖的国家数有十几个，各种各样的应用场景接入，为中国出海的用户，以及海外到海外的用户提供服务，这也是携程今后很重要的战略重点方向，近阶段我们也做了很多工作。

4. 总结

我的题目叫做卓越运维之路，卓越的本质就是不断改善和持续优化的过程，携程整个运维的发展过程也是不断改善和持续优化的过程，同时也希望把之前遇到的踩过的坑给大家一些借鉴，希望对大家有所帮助。如果大家有细节的问题需要沟通的话，可以线下交流，谢谢大家。