六个人如何运维一万台服务器？

今日给大家共享的主题风格是“携程网应用运维自动化技术演变之途”。自动化技术搭建全过程中所碰到的阻碍及其我们都是如何超越这种阻碍，大家碰到了什么坑，及其如何补平这种坑的全过程。

我 2013 年加入携程网，一直在从业运维开发设计工作中。携程网运维开发设计有一个特性，全部开发设计既当 PM，又当 QA，都没有区别前面工作中还是后面工作中，用如今较为时兴得话说，我们是全栈工程师。

添加去哪这几年，我做的工作中也是较为零碎的，哪有要求就到哪去。

归纳起來主要涉及到主机管理方法、应用管理方法、监管、警报服务平台等设计方案，开发设计和运维这几层面的工作中。

下边简单介绍一下大家的运维精英团队：

• 大家的运维精英团队承担企业全部的服务器、网络等硬件系统的运维工作中。
• 一部分工作人员从业日常运维，包含 QVS 的布署，Nginx 的配置，应用发布的适用，储存的布署等，还包含警报的告之、常见故障的通告和追踪。
• 2013 年上下，大家逐渐产品研发自身的运维服务平台。
• 承担企业内部网的应用，这种内部网包含 OA 系统、HR 系统，也有 IT 投资管理服务平台这些。

携程网应用运维服务平台介绍

最先简单介绍一下携程网应用运维服务平台。

我们知道一个应用从开发设计到网上运作，它的生命期主要牵涉到四个一部分：

• 应用的资源优化配置，这种資源包含应用布署需要的主机、应用的照片、文档，阿里云oss所需要的服务器资源，应用通讯和别的的网络带宽，也有应用所需要的云计算服务器这些。
• 为了更好地提升应用开发设计的高效率，而且确保应用开发设计的标准，大家企业会提供公共性的分布式数据库，这种分布式数据库包含日志搜集、应用配置申请注册、联动报警指标值的搜集，也有应用启用途径。
• 为了更好地将大家的应用公布到网上，大家需要对应用进行代码管理和搭建测试到公布到网上，这需要 CI/CD 不断公布和持续集成。
• 当一个应用公布到网上以后，大家需要对这一应用的性能参数和业务流程指标值进行监管、警报和剖析，那样就需要应用有关的监管、警报和日志剖析服务平台。

携程网的业务流程也是一步步发展趋势起來的，设备从几十台到上万部，在发展趋势的全过程中大家碰到了许多难题，在不一样的环节大家也明确提出了不一样的处理方案。

携程网历经的环节分为四个一部分：

运维设备总数较为少，绝大多数的工作中全是紧急运维。例如大家发觉一个应用有什么问题了，大家登陆到这一应用的有关设备上，手动式实行 Linux 指令，去查询这一设备的資源使用状况。

例如 CPU 是否太高了，是否硬盘布满了，这一环节都没有采用太繁杂的脚本制作，大部分全是手动式实际操作，几十台上下。

伴随着规模扩张，手动式写了许多脚本制作，拥有这种脚本制作以后大家就可以大批量去执行任务，能够在几台设备上大批量布署应用和监管。

这一环节，大家称之为脚本制作运维的环节，即运用脚本制作而且融合开源系统的系统，进行对数百台设备的运维。

伴随着规模越来越大，脚本制作运维不足用了，远远地不可以满足需求。脚本制作很有可能全是归类的脚本制作，并沒有历经有效的编辑，那样脚本制作的实行次序就较为关键，沒有有效编辑很有可能会造成一些难题。

大家开发设计一些有关的系统，用系统把有关的脚本制作串连起來，编辑好构成一个一个分离出来的实际操作。例如一台设备的新创建和删掉便是独立的实际操作，把这种制成系统，运维工作人员能够在页面上实际操作。

这一环节，大家称作公司分立系统，数据信息大部分在每个系统中间沒有完成一个比较好的共享。这一环节能运维的主机总数也较为比较有限，数千台的主机是比较好的。

随后携程网的设备规模提升了万部之上，此刻大家考虑到能否从一个较为高的视角去有效设计方案一下运维服务平台。

为大家的运维工作中提供一站式的服务项目，在一站式服务的基本上大家完成数据信息互通，那样就可以互动起來，做一些自动化技术的工作中。这一阶段也是今日大家主要要讲的內容，即运维服务平台的基本建设。

应用运维服务平台的三个关键环节

运维服务平台的基本建设全过程中，大家遭受了许多艰难也碰到了许多坑，在这种艰难当中汇总出去三个关键环节：

• 主机管理方法。
• 联动报警。
• 数据信息互通。

主机管理方法

携程网的主机管理方法系统是以 OpenStack 和 DNSDB 为关键的， OpenStack 承担生产调度建立虚拟机， DNSDB 是域名解析系统。

根据 DNSDB 我们可以将一个设备的名字、单位、主要用途和它所属的机房构成一个唯一的网站域名，大家用这一唯一的网站域名来标志这台主机。

在 OpenStack 、 DNSDB 以上，大家写了很多的脚本制作文本文档和专用工具，将这种脚本制作文本文档和专用工具编辑起來，封裝成一个一个的实际操作，而且大家给这种实际操作授予一些有关的管理权限。

大家把主机的信息内容、商品流通的管理方法、管理权限的配置也有实际操作日志的查看都是会存有日志杜兰特。最终大家会把一个主机管理方法系统的页面曝露给运维工作人员，运维工作人员根据这一页面来管理方法大家的主机。

拥有主机管理系统以后，运维工作人员就可以十分便捷的在这个服务平台上建立、消毁主机，查询主机的有关信息，例如它的配置、过保信息内容这些。

我们在添加每台设备的全过程上都会默认设置给这一设备再加上联动报警，设备有警报的情况下也会通告到有关的责任人。

那样做还是会存有一个较为大的难题，即大家这一系统是怎么开发设计给运维工作人员使用的，开发者并沒有管理权限登陆这一系统。

倘若说开发者明确提出来一个要求，我想建立一台主机，就需要给 OPS 发送邮件，OPS 建立这台主机的情况下，实际上并沒有十分精确的纪录到这一责任人到底是谁，他很有可能会写在备注里，这一备注伴随着時间的变化，有可能禁止了。

由于那时候的责任人很有可能辞职了或是换岗，这类状况全是常常产生的。

这一设备所承担的单位都没有去非常好的纪录，由于这一单位许多仅仅反映在主机这一名字上，可是有可能这台设备在使用的全过程中很有可能会转入别的业务流程线的单位使用，那样大家取得的单位信息内容也不是精确的。

还有一个难题 DB 系统只对运维工作人员对外开放，业务流程线参加非常少，造成全部主机的有关信息实际上是不足精确的，由于 OPS 工作人员终究比较有限，不太可能十分精确的维护保养这种信息内容。

那样大家就想起一个方案，根据应用树去处理。

携程网把业务流程线依照功能分区区划到每个 BU，应用树 BU 做为第一级，下边有单位，单位下边也有更小的单位，这一等级可能是好几个的。

最终一级是单位下边所承担的应用，应用是做为最终一级的。大家把全部的等级都做为一个连接点，在每一个连接点上面能够关联主机，给连接点加上责任人，给连接点加上审核人，下边我能介绍审核人的管理权限和人物角色。

拥有这一应用树以后，业务流程线开发设计参加进去，参加管理方法主机，她们的责任人和单位信息内容更为精确。

一台设备出现异常，我觉得十分快速寻找这一设备的责任人也很容易。

倘若说宿主机立刻要过保了，它上边的全部的虚机我还需要寻找这一虚机的责任人，通告这些人去实行有关的实际操作，例如像虚机退出、应用退出，那样能够防止许多运维宿主机过保而造成的常见故障。

由于设备的责任人较为精准了，大家的警报通告会默认设置把设备的联动报警都通告给有关的责任人，由责任人来解决设备有关的基本硬件配置警报。

每一个一季度都是会统计分析資源的耗费，也会对下个季度设备的购置做整体规划和费用预算。

取得较为上级领导的单位，例如取得一个 BU 连接点，能够根据应用树非常容易取得这一单位下都有哪些设备，他这一月的增长率多少钱，大家就可以很便捷的预测分析下个季度大家需要购置多小量的设备，进而制订更为有效的费用预算。

拥有客户以后，责任人、单位和设备的关联全是较为确立的。

可是存有一个难题，申请办理資源的情况下，依然需要由 OPS 进行实际操作，账户加上也是由 OPS 承担，一个开发者要想扩充一台设备或是给一个设备去加上账户，要怎么做？

他就需要给实际操作 OPS 的 team 发送邮件，说我想给应用扩充两部主机，或是给哪台主机加上一个账户。

那样做有哪些弊端，一是 OPS 不太可能即时线上也不太可能盯住系统，那样 OPS 响应十分慢，邮件查询起來十分不方便，并且电子邮件时间长了很有可能遗失，精准定位也不易。

怎么解决这个问题？下面又干了2个系统：第一个是主机申请办理系统，第二是账号申请系统。

这两个系统以主机管理方法、应用树和审核管理中心为基本，启用主机管理方法、应用树和审核管理中心为插口，根据启用插口去编辑一些有效的主机申请办理和账号申请的步骤。

刚刚大家提及主机申请办理的情况下，哪里有管理权限申请办理，应用树枝的每一个连接点的责任人都是有管理权限去申请办理这一单位的主机或是这一应用的主机，连接点上的审核人他就会有管理权限去审核这一连接点下的主机。

那样 OPS 就无需参加过多，她们能够全自动申请办理主机和账户。

最终大家干了一个页面，把这个页面曝露给开发者，开发者能够去申请办理主机、注册账号。

根据应用树、主机管理方法、主机申请办理、账号申请这四个平台干了闭环控制，关键是应用树连接点，应用树连接点把四个一部分串连起來。

应用树连接点有哪些难题，大家会更改它，例如一开始有一个 portal 应用放到 OPS 开发设计下，有一天发觉这一放的部位不太对，需要立即放到 OPS 下边就可以了，那样就需要把 portal 从运维开发设计移动到 OPS 下边。

还有一个， portal 伴随着业务流程提高，应用越来越大，需要拆分为好多个一部分，例如需要拆分为 portal-web 和 portal-api ，这类树连接点更改会造成哪些？

大家每一个系统纪录的全是应用树连接点，每一个应用树连接点的更改每个系统都需要去同歩，这就等同于在一个分布式系统系统里有一个有情况的控制模块，便是应用树连接点这一控制模块。

它是有情况的，有情况就造成大家分布式系统较为艰难，大家想把应用树连接点营销推广到大量的系统中，那么就会十分艰难，便会持续遭遇同歩的难题。

这个问题怎么解决，例如针对一个一般的住户而言，怎样在每个系统中间共享数据信息，例如我一个人怎样在公安机关系统、在户口系统、在金融机构系统这些每个系统中间，如何共享我的信息。

实际中就有一个很好的实践活动，那便是使用身份证件，身份证件有唯一的 ID，根据那样一个唯一的 ID，就可以标志这一应用，而且这一 ID 始终不会更改。

大家怎样去寻找那样一个 ID，第一个方案，用数据库里的自增 ID 或是 UUID 来标志应用。

那样能够确保应用 ID 唯一且不更改，可是由于自增 ID 和 UUID 在文本上沒有确立实际意义，大家开发者取得这一 ID 不有利于记忆力，都不有利于沟通交流。

倘若得用自增 ID 或 UUID ，需要用此外一个系统去专业看着我有多少那样的 ID，先寻找这一 ID，再和别的系统进行互动、沟通交流，十分不方便。

第二个方案，参考身份证件，用数字，例如 110 意味着北京市，后边意味着区县，意味着自身的出世日期。

参考身份证件 ID，大家使用了那样一个叫 Appcode 的方案来标志应用。Appcode 大部分下列滑触切分的，第一个是应用所属的单位，第二个是应用的叙述，这一等级还可以十分长。

用那样一个 Appcode 去替代应用数连接点，既能确保唯一且不能更改，有利于大家记忆力，沟通交流也较为便捷，大家最终选的是第二套方案。

联动报警

下边看一下我们都是怎样在运维服务平台去做联动报警的。做为一个互联网公司，确保 7x24 小时提供服务项目是一个最基本上的规定，我们要如何去确保 7x24 小时服务项目？

倘若说系统有什么问题的情况下，大家可以提早预警信息发觉，等系统真真正正出现难题的情况下，大家可以立即的发觉。要确保这两个方面，大家就需要联动报警系统。

携程网的联动报警系统也是经历了很长期的挣脱，一开始每一个单位都是会维护保养自身的一套系统，一开始是 Cacti 和 Nagios 这两个控制模块去构建的，那样存有什么问题？

Cacti 布署在单机版上，不可以横着扩展，造成特性较为差。倘若单机版出现异常乃至服务器宕机，那大家的联动报警系统就彻底不能用，因此这是一个非高可用性的方案。

每一个单位都是会维护保养一套自身的监管系统，乃至较为大的单位，像酒店机票这类大单位，她们很有可能会维护保养许多套，每一套都需要有专业的工作人员来运维，运维成本费也十分高。

因为以前的系统沒有非常好的管理权限，这一系统只有由专业的人来承担，由于放宽给别人管理权限是较为风险的，很有可能有些人一不小心实际操作了哪些，把警报删除或是改动警报配置，因此只有把警报交到专职人员承担。

要订制一个警报监管沟通成本十分高，大家需要联系自身的有关责任人，随后再去警报配置。

开发者感觉太麻烦了，索性不干了，或是做得很少，造成大家监管的面不足全，很有可能有一些异常乃至是常见故障也没有及时处理，高效率是较为不高的。

怎么解决这个问题？大家干了一个公司货的统一联动报警服务平台 Watcher 。

警报服务平台有那样好多个总体目标：

高可用性，一台设备或多台设备挂掉，对大家沒有影响或是影响不大。

较为非常容易的让大家去配置这一警报，大家干了一个管理权限系统，也是参考应用树干了一个树形结构的管理权限系统，把全部 Watcher 页面对外开放给全部的开发者，那样大家就可以十分便捷的配自身的警报和监管。

简单介绍一下 Watcher ， Watcher 是基于 Graphite 深度开发的， Watcher 服务平台既适用主机基本联动报警，与此同时也适用业务流程联动报警，都是在一个统一的服务平台上，联动报警能够由开发者在统一的页面上查询和配置。

Watcher 大约 2014 年逐渐做，现在有三年時间，在企业也营销推广得非常好。

如今 Watcher 早已接入 1500 个之上的应用， 现阶段的指标值总数早已超出了 2000 万，警报总数早已超出了 40 万，接入了基本监管的设备总数也超出了 4 万部。

Watcher 这么大的规模，大家用了哪些一个构架呢？

这一框架图仅仅大家一个 Watcher 群集的框架图，我们在打数的情况下会区别每一个指标值要打进哪一个群集上，大家如何判断？

以 Metrics 做为标志，例如全部的测试数据信息测试指标值都以 t 开始，全部的主机数据信息都以 h 开始。

大家用 s.flat 就意味着飞机票这一单位，飞机票这一单位全部指标值打数的情况下就需要配置好一个服务器，这一服务器也是用网站域名来表明的，它自身自身就意味着一个飞机票的联动报警群集。

在上面的群集框架图里，最下面翠绿色的是 Graphite 原来的部件，在原来部件上我们自己开发设计了好多个有关的部件。

第一个是 Relay ，每一个指标值打回来以后，大家根据 Relay 把指标值遍布在几台设备上，这个是根据一致性哈希来完成的。

等大家取数的情况下， Graphite-api 这一部分也是我们自己开发设计的， Graphite-api 里也是有一样的一致性哈希优化算法，根据这一优化算法寻找这一指标值在这个群集的哪一个设备上，启用这一设备上的 Graphite-web 下的 api，随后拿有关的数据信息。

这是一个群集的构架，大家有好几个群集。Watcher 要做一个统一的页面，在这个页面上配置自身的监管的情况下，挑选数据库，针对打数的人他清晰这一指标值在哪儿。

能否做一个统一的数据库，让客户来使用，那样大家就在部件里再加上了一个纯指标值的数据库，每一次总流量回来以后，大家便会把这个指标值的名字写到大家数据库里一份，与此同时纪录它在哪个群集。

那样大家就可以对外开放报一个统一的 Graphite-api ，倘若说一个指标值我们要起 s.flat-xx 的指标值，最先是启用api，去找 s.flat-xx 这一指标值在什么群集里，发觉在飞机票的群集里，再根据一致性哈希就可以把这个指标值取下来啦。

Graphite-api 上第一部分是借这一 Dashboard 来警报。讲详细个的 Watcher 构架，下边看一下主机监管是怎么做的？

最先有一个硬件配置管理系统，维护保养着主机监管的有关信息。

最主要的是会编辑代理商，去维护保养代理商的版本号配置，会不断的去扫描仪这一主机，往主机上布署，也会按时查验指标值是不是搜集了。

倘若这一主机指标值出现中断点了或是有什么问题了，会警报去查验，到底是 Collectd 出难题了还是系统出难题了还是网络出难题了。

每一个主机上布署 Collectd 以后会依据不一样的配置打不一样的指标值，例如 CPU 的使用状况，运行内存的使用状况，网络带宽的使用状况，这种都将指标值弄成了 Watcher。

每一个主机的指标值很有可能全是同样的，如何判断不一样主机的指标值，大家就以主机的名字做为区别。接入到 Watcher 以后，大家就可以启用 api，在 Dashboard 上启用。

业务流程监管也是较为相近的，应用接入以后会显现出 api，里边便是近期 1 分鐘以内应用的监管数据信息，每分 Qmonitor server 从全部的设备上来拉这一文档，拿了文档以后做集中化的剖析，剖析完以后做相对应的解决。

例如对应用进行记数，算完以后以 Appcode 做为标志来区别不一样的指标值，将指标值消息推送到 Watcher。消息推送到 Watcher 以后，一样能够查看监管，查验应用指标值的身心健康情况。

数据信息互通

下边讲一下大家怎样在全部运维服务平台完成数据信息互通的。我们在联动报警和主机管理方法里都提及了一个 Appcode ，在携程网 Appcode 究竟是什么？

实际上它便是唯一的一个标志应用，大家将一个应用进行了抽象概念，含意更为理论了。

在携程网一个应用能够是一个 Web 服务项目，还可以是一个 GPU 云案例，还可以是 MySQL 案例，乃至能够是一组交换机，还能够是别的的。

为何要对应用做那样的抽象概念，做抽象概念的益处便是大家无需去考虑到服务项目和資源的实际关键点，就用一个 App 意味着一个服务项目或是意味着一个資源，在这个抽象概念的全过程中可以不考虑到这一服务项目究竟 干什么，这一資源究竟 哪些。

给理论的应用界定一同的特性，包含这一应用的责任人、应用的管理权限、应用的信用卡账单这些。

拥有这种一同的特性，大家就可以将 Appcode 在好几个系统中进行拓展，遍布在每个系统中去共享数据信息。那样做的功效是啥？

拥有 Appcode 以后，大家就可以在大家的每个系统中产生一种一同的语言表达，这一共同话题便是 Appcode 。

拥有这一共同话题以后，大家就可以把每个系统中间的数据信息相互连接，最终完成一个数据信息的互通。完成数据信息互通以后有哪些好处呢？

• 大家把 Appcode 放到每个系统当中监管，例如主机、储存、测算，它是应用的資源一部分。

Appcode 遍布在好几个系统当中，好几个系统中相互影响，一个数据信息只有遍布的连接点越多，对这一数据信息的精确性规定越高，由于这一数据信息很有可能在好几个系统间使用，它的责任人便会更为高度重视这一份数据信息，因此她们更想要让这一数据信息越来越更为精确。

• 数据信息更精确以后，它就越来越更为有效，每个系统中间由于数据信息精确了，都想要使用这一份数据信息，产生较为良好的绿色生态循环系统。

由于数据信息互通了，大家就可以做一个 Portal 服务平台，对外开放曝露一个统一的页面，能够对大家应用所涉及到的全部一部分进行一站式管理方法。

Portal 服务平台介绍

简单介绍一下 Portal 服务平台，如今也是已经开发设计中的服务平台。

Portal 便是以 Appcode 为基本，在 Appcode 的基本上联接了每个运维系统。

例如主机、账户、GPU 云、ES 云，应用申请注册、应用配置、应用分布式数据库，自然环境配置、代码仓库、测试、公布、监管、警报、日志搜集，常见故障管理方法。

大家把这种系统都归纳到一个 Portal 页面上曝露给开发者，开发者进到这一系统以后就可以一站式的把应用有关的想要做的事儿都做完。

数据信息互通此外一个益处，刚刚讲主机管理方法，主机很有可能会出现不一样层面来表述这一主机不是太一样的。

例如应用公布，有公布主机目录，算钱单的情况下有一个信用卡账单主机目录，搜集日志的情况下也是有主机目录，搜集联动报警也是有主机目录。

只需数据信息互通以后，大家就可以将这种数据信息串连起來。例如大家应用，它的主机需要扩充了，扩充两部主机，扩充以后大家就可以全自动依据这一应用上的责任人去为主机加上相匹配的账户。

那样它的责任人就可以运用这一账户登录相对应的系统，进行相对应的实际操作。

数据库也有别的的例如 IP 授权管理限制，拥有数据信息互通以后，一个应用它的授权管理配置就没必要纪录在每一个主机到了，就纪录在 Appcode 就可以了。

CI/CD一部分，应用公布的主机也是和 Appcode 关联的，应用扩充以后公布的主机也是一样同歩回来，公布挑选这种主机立即公布就可以了，不需要手动式再去填好这种主机目录。

监管分为2个层面，一个是基本监管，一个是业务流程监管。基本监管也是根据 Appcode 层面能够查询有关的主机的基本监管。

针对业务流程监管在应用监管指标值的搜集，还可以根据 Appcode 来取得它的主机目录，全自动去给业务流程监管指标值搜集加上这种设备目录，加上完以后搜集上去这种应用有关主机的监管指标值和日志。

警报系统，由于拥有 Appcode 以后，它会相匹配着一些一同的联动报警项，例如像 Java 里的 GC 警报。

大家拥有 Appcode 以后，就可以给每一个 Appcode 上的全部设备都默认设置加上 GC 警报。这一 GC 警报联系人便是 Appcode 一个责任人，每台设备扩充以后它的 GC 警报也就全自动加上了。

日志搜集也是一样的，以前大家很有可能还是需要在这个服务平台手动式维护保养，拥有 Appcode 就可以同歩这一目录。

数据信息互通也有此外一个益处，有 Appcode 以后大家就可以十分便捷的去测算这一应用所消耗的信用卡账单。为何要测算一个应用的信用卡账单？

一方面，使我们提升了成本意识，成本意识在型号选择全过程中也是需要考虑到的。

例如一个业务流程线它有一些数据信息需要记下来，它能够挑选一切系统，还可以挑选数据库，还可以挑选 Watcher 。

倘若说这一业务流程浏览的頻率极低，例如一天就几回、十几次，把这个数据信息纪录到 Watcher 实际上成本费十分昂贵，由于 Watcher 数据信息澎涨十分强大，挑选数据库或是日志更划得来。

第二能够优化完成，倘若你因为优化算法造成设备資源很多使用，拥有信用卡账单以后，她们会有目的去节约成本。

拥有成本意识以后，我们可以更为有效的资源分配。例如有的应用自身并不是很重要，还申请办理了尤其多的设备，设备使用率都不高，取得信用卡账单一看，那么一个不重要的应用居然消耗这么大的信用卡账单，随后她们便会收购 一部分資源。

现阶段大家也在持续的去接入各式各样的应用信用卡账单，例如主机信用卡账单、网络带宽信用卡账单、联动报警、日志搜集、很多的储存，也有云计算服务器信用卡账单，也有别的的一系列的信用卡账单，都是会渐渐地接入进去。

汇总

最终做一下汇总，在携程网运维自动化技术过程中，大家经历了不一样的环节。

大家发觉等应用扩张到一定规模的情况下，需要运维平台化，全自动的或是全自动的方法是十分消耗人力资源管理的，而且它也会大概发觉一些不正确乃至是常见故障。携程网运维自动化技术也是做得十分非常好的，如何来反映？

我 2013 年新员工入职，我新员工入职的情况下日常运维的工作人员大约有五六个，如今大家日常运维的工作人员依然是六个，大家又发布了一个运维智能机器人，运维第七人。

大家还是维持在六人的情况，大家规模扩张了许多倍，从上百台到万部，扩张了上千倍的规模，可是大家日常运维工作人员并沒有提升，它是运维服务平台自动化技术产生的益处。

应用的易用性需要联动报警系统的确保，大部分在一个应用发布以前便会去把它全部重要的警报和监管架好，那样应用有什么问题得话便会快速回退或是去 debug 。

由于大家有健全的联动报警系统，因此携程网的常见故障还算较为少的，均值而言一天也就两三个常见故障。

可是携程网的常见故障和别的的常见故障很有可能不太一样，携程网的常见故障规定较为严苛，一次网络常见故障大家便会纪录批号的常见故障。

例如 Watcher 的监管系统出不来图了，超出 5 分鐘了，大家很有可能会细究 P1 和 P2 的常见故障。

在那样的严格管理下，大家的常见故障也不会太高，我新员工入职四年来，如今总计的常见故障数也就 3000 个上下。

要确保大家全部运维绿色生态的发展趋势，大家需要将数据信息连通，连通需要给应用一个 ID，拥有这一 ID 以后，大家就可以在每个运维系统友谊台子上共享数据信息，产生一个良好的绿色生态循环系统。

郑松宽，携程网高級运维技术工程师。2013年添加携程网服务平台业务部，从业运维开发设计工作中。工作上主要承担企业监管系统的开发设计，应用管理系统 Portal 的设计方案、开发设计和运维。