由腾讯浅谈服务器海量运营

更多腾讯海量技术文章，请关注云加社区：https://cloud.tencent.com/developer/column

作者：鹅厂网事

＂鹅厂网事＂由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营，我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息，同时分享腾讯在网络与服务器领域，规划、运营、研发、服务等层面的实战干货，期待与您的共同成长。

网络平台部以构建敏捷、弹性、低成本的业界领先海量互联网云计算服务平台，为支撑腾讯公司业务持续发展，为业务建立竞争优势、构建行业健康生态而持续贡献价值！

导语

2015年春节，微信红包引爆全球，当各种惊人数据展示在大家面前的时候，从基础架构这个角度来看，必有一套完善的体系支撑如此巨量的业务数据。而对于服务器这个体系中的一环，在支撑多个巨型业务时，面临着巨大的运营压力。我们可以从下面这些数字，来看看海量运营的挑战：数十万台服务器，数百万服务器部件的资产管理和运营，包含多厂商、多型号、多平台等多个维度；服务器年交付量超过十万台，其中配合业务发展导致的紧急交付次数超过数十次；服务器年搬迁量超过数万台，搬迁距离加起来可绕地球650圈；服务器年告警量超过百万条；服务器服务请求年达到几十万台次……

08年我们做过一项预测，以当时的运营水平（基本靠人抗）为依据，当服务器的规模翻两番时运营团队的规模可能需要过百人，假如服务器的规模达到一个量级的增长，依赖再多的人力也将是无法支撑。从那时起，腾讯的服务器运营团队就逐步寻找一条切合互联网服务器海量运营的方法，在过去的几年中，通过经验总结，初步形成了一套行之有效、符合业务实际场景的自动化运营体系。本文主要就自动化运营体系三个最基本也是最重要的方面进行浅谈，希望起到抛砖引玉的作用。

一、可审计的基础架构配置管理（CMDB）

这里的配置管理即为基础架构关联关系的信息管理，作为一个基础数据，往往被各种流程调用、同步，是各种系统的信息枢纽，是一个必不可少的管理系统，可以说CMDB的准确性决定了整个海量运营的自动化程度。因此，要支撑服务器的海量运营，首先需要建立和维护一套基础架构的CMDB。如图所示，配置管理主要记录与服务器相关的基础架构关联关系，包括位置信息、网络信息、业务信息等。

关联关系的准确与否，将决定海量运营的可靠性及自动化程度。当过往我们服务器量少，规模小的时候，对服务器的信息管理，我们更多地借助机房负责人线下excel的记录和管理，将信息的准确作为一项KPI靠人来维护，在这个时候是最为合适的，也是完全可以支撑当时的运营场景的。随着规模慢慢发展，当一个机房负责人需要管理多个机房，甚至分工更细，一个机房由多人维护，特别是机房现场引入外包机制时，这种线下维护方式就会制约运营的质量和效率，比如设备的位置变更，网络端口的变更、IP信息的变更等，输入源的不同，容易导致信息的不准确，从而带来如重启、重装错服务器等运营事故。因此，当服务器量大了以后，必须要有一套线上的关联关系，才能保证数据的准确性，而只有数据准确了才能做自动化。

要建立关联关系，可以从机房建设标准化录入、关系变更流程等进行把控。而在日常运营中，各种各样的情况可能都会导致这张初始的关系表变的不准确，因此在运营中还需要一些自动化的手段进行监控和审计。比如通过服务器的检测发现系统，实时采集服务器的相关信息，与配置信息及网络交换机的实时信息对比，一旦关键信息出现变化，立刻告警通知，通过多种类似的手段来保证CMDB在动态运营中的准确性。

二、自动高效的故障修复体系

数十万体量的服务器，即使将故障率控制的很好，也会带来为数众多的故障单，加上受基础环境（如网络异常）等影响引发的告警，每天会产生大量重复的运营工作：现场健康巡检、一线告警确认、报障维修、线下沟通等，这样的局面只会让运营人员疲于奔命。另外一方面，当所有故障都是紧急的，都需要第一时间处理的时候，故障处理犹如洪水野兽般涌入，这样的情况下，即使投入再多的人力也将于事无补。因此，我们需要大幅提升人均运营效率，把好钢用在刀刃上，对整个故障处理进行端到端的服务和流程设计。

1建立服务器分级机制，提升处理效率

通过对服务器设立不同的服务级别，区分响应处理的紧急程度，将大比例的服务器放入大时长的级别，使得大量优先级低的故障维修采用SO（Schedule Operation）模式，成为有计划的任务，采用类似Facebook等国外企业的做法，在固定的时间点，集中进行维护，批量化的处理，实现了化繁为简，从而提升处理效率。对于少量真正重要的机器，采用实时响应的模式进行维修，确保业务的稳定性。

2建设智能化监控系统，减少人工干预度

日常运营过程中，告警除了常规的ping、进程检测等跟操作系统相关的类型外，还有不少属于硬件类的，而这部分告警过往通常是靠现场巡检，通过服务器前面板的指示灯来发现，这样的告警既容易造成漏报，引发不必要的损失（如双硬盘红灯），又不能提前预警，只有真正故障后才能发现。为了提升故障告警的及时、准确性，减少人力投入，如图所示，我们从服务器的OS和硬件两个层面深入研究，通过对服务器的OS进行日志采集分析，以及对硬件底层的监控分提升告警的准确性和预知性。如通过硬盘SMART信息的分析，获得硬盘的健康状况；通过BMC信息的分析，获得服务器温度的变化状况等，进而进行下一步的处理。

同时，当告警自动告出后，每天数千条的告警量给到一线人员，一线人员需要不断地检测这些告警是否是真正意义上需要处理的告警。通过对一些场景的梳理和过往经验的积累，抽象出一系列的收敛规则，当大量告警发生时，系统根据这些规则进行自动的收敛，大量减少一线人员的工作量。

3建立适合业务特点的故障处理流程

告警明确后，就需要进行故障处理，如图所示，将故障处理分为四个阶段：源头发现、告警确诊、沟通授权和故障维修。在这四个阶段中源头发现和告警确诊主要依靠上面第2点所说，将大量的告警进行收敛，将真正需要处理的告警进行明确化（如一个Ping不通告警，通过监控分析明确为到底是CPU故障还是内存故障）。在沟通授权阶段，当不能真正做到无需知会直接处理的时候，就必须进行人工沟通，而这往往是一线、现场人员最大的工作量：统计分析发现原有故障处理80%的人工耗时用在了沟通上。我们通过SO模式、系统API应答、自动语音寻呼授权这三种流程工具的配合，实现系统的自动流转，将这块的人工消耗基本降为0。在维修阶段，通过与厂商系统的对接，直接进行报修，并在维修完成后，由监控系统自动检测，告知维修结果。通过这样一套故障处理流程，在完成大量故障处理工作的同时，降低人员的参与度。

4附：腾讯自动化故障处理模型

三、闭环的服务器资源交付管理

服务器的资源交付是运营中一个很大的挑战：如何能将大量的服务器快速上架和初始化，满足资源调度和业务上线的需求？细看工作内容，服务器的交付并非简单的上架、装OS，而是涉及到很多的环节和团队，是一个将整个基础架构的服务进行打包交付的过程。下图所示，为一台服务器到机房后需要做的操作，可以看到一台服务器的交付，是一个漫长的链条，涉及到很多环节，既需要执行规范，如保证服务器上架标准化的上架接线；也需要流程支撑，如涉及到商务计费的机架开电；还需要技术实现，如快速的OS部署等。而这些环节错综复杂，一个环节出错，就会直接影响后续的交付（如Raid设置错误）。

理清关联环节后，资源交付看起来似乎把控好各个环节的质量，就会是一件不太难的事，但从以前的经历来看，除了质量控制外，流程的灵活性和健壮性也是一个很大的挑战：最初我们要么优化工具系统，要么优化流程，但最终这种头痛医头脚痛医脚的方式效果不佳，导致运营苦不堪言，研发也每年进行重构开发。现在回顾头来看，我们做的每一个系统或者流程，都能满足当时的场景，但当面对互联网高速发展带来的复杂、多变的运营场景时，就显的力不从心，表现出流程不顺、自动化程度低的窘态。为了快速适应和支持这样多变的运营场景，我们主要从以下两方面进行考虑和建设：

1面向服务器生命周期的管理

服务器运营并非一锤子买卖，在服务器完成上架后很长的一段时间内还有很多的事情要做，以前为了赶时间、赶交付，没有进行与运营相关的质量控制，工具系统也没有从服务器的整个生命周期进行考虑，导致服务器进入运营后，出现各种水土不服，比如，为了提升机器性能，在原有机型上新增了一个SSD启动盘，结果在服务器引入后，后面的运营环节不知道，将SSD被识别为最后一个盘符，导致该改进没有起到应有的作用，甚至容易导致在重装的时候导致数据丢失。

因此，需要从源头开始建立一套面向服务器生命周期管理的机制，如下图所示，从需求规划、引入测试开始，充分考虑从服务器采购到最终报废整个链条中，涉及到的各个环节的系统、工具和质量指标。通过对整个全生命周期的管理，可以从源头完成服务器与各个运营流程的适配，也可以保证服务器关键属性和信息的一致性。

2按运营场景快速组合的流程引擎

抽象、封装的原子操作流程。通过服务器的生命周期来看，运营涉及到的工具和系统有很多的地方是重合的，是可以复用的，特别是如机架开电、交换机启用、IP分配这类标准化程度高的操作流程，如果在服务器每个运营流程中都进行一次开发，不仅效率不高，而且当这些操作流程有调整时，涉及到的所有运营流程都需要及时调整。因此，需要梳理出这些公用的操作，并对它们进行抽象和封装，所有的变化、调整都闭环在原子操作流程中，而主体流程只需按需调用，即可快速实现。

快速组合的流程引擎。互联网的高速发展，也使得服务器的运营流程同样是快速多变的，即使同一个运营流程，在不同的业务场景下也会有不同的流转过程，因此，在将操作流程原子化后，还需要一个可以快速组合的流程引擎。如下图所示，当有新的流程需要新建或变更时，运营人员只需要描述清楚流程的业务逻辑和流程，开发人员将业务方案转化为IT方案后，在流程引擎上进行快速组合，最后在流程节点上，进行原子操作流程的调用，即可完成整个流程的上线。

结束

服务器的海量运营是一个持续的课题，在不同的时期会有不同的挑战，只有不断地思考和优化，才能在持续运营的过程中，乘风破浪!