PartⅠ腾讯服务器运营平台进化历史
腾讯公司刚成立的时候，服务器数量非常少，公司创始团队亲自上阵维护，也没有什么自动化运营平台的说法。故老相传，很多年前的那些月黑风高的夜晚，一众大佬常欲潜入东门机房，掌匙大爷验证之后方得入内。多年以后，公司的年轻后生继维护之事，大爷还常常问起“那个志东怎么好久不来了呢？”。
逐渐服务器数量达到数百台规模，这期间的服务器重点工作是运维。先买机器到公司，拆包、刷机之后再扛到机房、上架，有故障问题也常要自己上阵检修。团队的同学们不但是技术高手，还得要是威猛的汉子（包括女汉子，据说能一人能扛两台的可以优先考虑）。这阶段只有些零星的技术工具，也没有运营平台什么事儿。
再往后，业务量和装机量增长太快，这种方式已经玩不下去了。但是因为采购量上去了，厂商同意每XX台出一个驻场工程师。如何定义厂商驻场和腾讯之间的工作界面和接口就成为一个现实问题。这阶段是平台的朦胧雏形阶段，线上的工作流工具开始引入，同时开始导入ITIL理念并建立重点的业务流程。
当服务器发展到数十万台的阶段，业务发展需要更丰富优质的服务，因此需要有更强的平台控制力。在平台能力整合厂商差异的基础上，基本不需要登陆厂商的专用工具或页面，只要在平台上进行按单操作的标准作业即可。因此，原有的厂商own驻场模式就没有什么必要了，新的现场外包模式登场并逐渐铺开。如何规划和管理好外包的现场工作、提供更清晰明了的流程和工具支持成为重点考虑的问题。整合底层设备设施的技术管理、串接流程和应用管理、面向业务/现场/二线等不同角色的服务管理成为平台的应有之义。这才是真正的平台建立阶段。
PartⅡ海量服务器运营平台挑战与应对如上所述，在海量条件下，服务器运营平台面对的挑战更加复杂。包括：
技术管理复杂性的挑战：在海量场景下，业务需求的服务器类型丰富、涉及到的厂商机型繁多、长期积累的在网运行服务器往往跨代甚至跨越不同的技术平台，各种设备的采集/监视/控制机制差异很大，技术管理的复杂性大大增加；
服务器运营需要生命周期管理：因为基数庞大，每年服务器的引入、部署、运营、退役作业达数十万量级。同时，海量场景下的服务器运营管理模型也大大复杂化，例如每年数万台的搬迁、现场的备件仓库管理、设备回收再用等场景都成为需要面对的课题。因此，平台必须提供完整的服务器生命周期管理，支撑服务器资源的海量调度，并实现流程的自动化运营，否则因此造成的人力投入、管理成本、数据风险都是不可承受的；
用户需要标准化的服务手段：一方面平台面对数千的内部用户、以及可能的第三方合作伙伴用户，用户数量庞大；另一方面部分核心用户管理的服务器数量庞大，甚至一人名下可达到数千台之巨，其自身往往也有维护工具。因此平台必须提供标准化的服务界面，包括Web页面、触点管理、API接口等多种服务方式。
因此，服务器运营平台的目标是实现服务器技术/运营/服务的平台化管理，向下跨平台跨厂商整合服务器底层技术、中间层依托平台提供的自动化运营流程和数据管理支撑服务器资源管理和稳定运营、向上为公司内的各业务部门提供统一的服务器运营管控服务。其中分层的功能场景和设计重点如下：
一设备管控统一封装底层的服务器管控操作，向上提供标准化的技术管理能力。主要包括：1信息采集海量服务器场景下，服务器的信息采集有一些重要的问题需要应对。标准化的采集工具目前采集工具分为带内（在机器OS之上部署采集插件）、带外（通过IPMI通道上报）两种方式，因此需要为不同版本的Linux/Window系统准备相应的插件，并且还要封装不同厂商的带外接口。每次插件升级都需要灰度测试过程。更为细致的采集项为了支持业务运营和监控需求，不仅采集传统的静态配置信息、CPU/内存/硬盘/网络等利用率信息、系统运行日志信息，还需要采集服务器的Eventlog/SDR/SMART等信息。海量数据的及时处理如上所述，数十万台服务器的数据采集，带来每天数十亿条海量数据的冲击。一方面针对数据源进行分级别管理，根据其属性细化采集颗粒度，降低需处理的数据量。例如利用率信息按分钟级、部件配置按小时级进行采集和记录、部分数据采用增量记录的采集方式等。采取这些方式之后，每天需加工的原始数据仍然达到数T级别，必须在数据解析之后进行处理和过滤。部分过程性数据在解析处理后只保留记录关键信息、将原始数据抛弃掉，有未来分析价值的数据则存入数据仓库。2设备监控海量场景下，系统每天产生的异常告警信息也是海量级别，如果按照传统方式进行人工处理，成本是不可承受的，需要考虑以下应对措施：
监控的精细化甄别通过对硬件标准的深入研究和理解，细化部件故障的明确判断标准；对于不明确类故障（例如ping不可达），通过关联的系统关键信息进行尽量的明确化，减少需人工诊断的数量。告警信息收敛通过预先设定的不同级别场景下的不同阈值，进行批量告警收敛，避免瞬时突发告警对用户造成困扰。至少需要支持按机房/机架/责任人/业务模块进行批量收敛。尝试自动修复对于某些故障场景，系统首先尝试重启解决。另外，通过对硬盘的精细化监控和处理，对故障硬盘进行尝试修复，经测试可以降低2/3的硬盘故障单。故障预警通过对硬盘故障特征的深入挖掘，建立硬盘故障模型，提前2-7天预警硬盘故障，可以从容的迁移数据、例行的故障修复等。3远程管控海量场景下，服务器跨越上百个机房，对服务器的部署安装/重启/重装等运维不能再照搬原始的远程登录模式，必须要考虑建设一个统一的管控层，向上提供标准化的服务。
要解决这个问题，需要搭建分布式的管控系统，在各个机房模块内部署代理服务器，向下可以访问同模块内的各个服务器，向上与管控核心通信，这种架构可以提高系统性能/分块隔离/带宽效率。
除了常规的部署系统、带外系统之外，还可以考虑把网络访问/跨平台设备控制/信息安全传输等基础能力整合起来，向用户提供定制化的、底层透明的远程管控服务（参见鹅厂网事-海量服务器安全高效管控系统设计）。
二流程管理如前所述，海量服务器运营要实现完整的生命周期管理，需要高效的自动化流程支撑。由于海量条件下的运营模型复杂化，流程类工作分为如下几种：
资源交付类流程为了向用户快速交付服务器资源的流程，包括自动验收检查、自动部署、预置环境调整等服务支持类流程为了保障用户正常使用服务器的流程。例如故障处理、重启/重装、语音通知等资源调度类流程为了实现资源分布优化的流程。例如服务器搬迁、改造、回收、备件调拨等生命周期末端流程为了完善服务器下线处理的流程。例如服务器退役、利旧拆解、报废处理、硬盘消磁等在海量环境下，每个流程都要实现尽可能的高度自动化运营，这需要：抽象管理过程通过流程设计建立每个流程的模型，一般每个流程都要涉及到十数个部门角色和系统，需要确定关键环节、职责分工、系统间接口流程引擎自动调度将上述抽象的流程过程，基于流程引擎实现，就类似于一个高度自治的大脑，自动调度各类系统工具/人员、自动派单和结单处理，同时记录流程过程数据，方便流程查询和分析。
为了降低流程开发成本，需要考虑原子流程-组合流程-业务流程的分级实现模式。
识别并定义常用的原子模块，例如IP分配/VLAN切换等，设定其外部接口，实现其处理逻辑并记录相应数据。
原子流程可以组成组合流程，完成某个特定场景的作业，例如机架开电、物资出库等，但是组合流程一般不会独立承担业务需求，只是在原子流程基础上组装的分子级流程，供更上层的业务流程调用。
业务流程即指上述的四大类数十种流程，其调用组合流程或者原子流程，组织成一个整体的解决方案来承载业务场景。
三展示交互海量场景下，服务器运营平台的展示层已经不仅仅只是传统意义上的等客来赏的Web页面，而是需要考虑以下问题：
平台为数千内部用户提供服务，既包括用户主动提交的服务、也包括用户被流程系统所牵引/指派应完成的工作环节，交互方式不仅限于页面，而是全时空的Web/RTX/短信//语音等人机交互界面，因此需要提供跨平台的一致性体验规划。
平台每月实施数十万次作业，需要尽可能的自动化和智能化，从而尽量减少人的参与、提高效率。一方面通过系统间对接实现自动化系统交互，另一方面通过不断的规律总结和数据挖掘、完善运营的细节模型，从而使得系统可以理解/实现更多场景的业务逻辑，进一步减少人工操作。
为此，需要重点考虑以下几个方面来增强平台的展示交互：
扁平化门户首先统一各系统的操作页面，避免分散入口带来用户的记忆成本和跨平台操作成本。然后通过服务化设计，整合规划各服务模块的一站式APP，将每类服务的下单、查询、作业、配置、报告都统一到一个APP下。这样用户的每类应用场景都被服务化聚合起来，不需要再为一个事情而东奔西走。在此基础上，通过扁平化的门户实现应用市场风格设计，方便用户自由选择，定制自己的门户和加载的服务列表。
开放化API因为各个BG用户运营管理的成熟度不同、有各自复杂而灵活的服务使用场景，以往统一的服务内容和级别无法满足用户日益个性化的需求。我们需要在服务梳理过程中识别应赋予用户定制权限的节点、尽量实现运营的配置自动化管理，同时在针对业务发展的弹性规划设计基础上，实现架构的相对稳定性。例如，语音系统辖多路电话通道、月拨打数千用户、数万通电话，在新架构上可以满足用户自定义接收人员/尝试次数/拨打间隔/语音内容/自动结单/自助取消等众多灵活定制、统一的API和页面服务，系统却能够通过更合理的线路池调度、配额管理、超时管理等极大提升平台架构的适应性。通过重新定义的API，平台同时对接数十个用户系统，不论用户系统成熟度差异、运营模式差异（例如是机器负责人运营还是值班制运营）、是否需要多级管理，都可以根据自己的实际情况使用我们的开放接口进行灵活定制、自我升级。这种开放和弹性的解决方案也可以最大程度的保障平台核心架构的稳定性。
交互方式可定制用户可以通过服务器平台门户或者API通道，对各个业务场景下的交互方式进行定制，例如自定义服务器故障的通知人员/通知方式/屏蔽时长等策略，并实现跨屏的统一体验。
四数据管理数据是海量服务器自动化运营的生命线，包括：配置数据设备的身份标识，这是平台自动化运营的基础，需要实现数十万台设备/近千万部件/上百项CI的准确管理，必须建立相应的CMDB，并通过系统接口进行写入和查询管理流程数据设备的档案，每月数十万次的作业会产生大量的流程数据采集数据设备的健康记录，如前述，每日采集数据达到T级别。各类数据如下图所示：海量数据的存储和处理是一个难题。基于腾讯内部大数据平台提供的强大能力，我们得以将需要的海量数据保存在数据仓库中，并通过其提供的大数据存储和运算等服务进行海量数据的挖掘处理，在硬盘故障预测、备件预测、运营指标体系等方面进行不断的数据积累和挖掘优化。
PartⅢ海量服务器运营平台的未来进化方向在平台初具的基础上，未来发展重点在哪里、会有哪些进化的方向？参考类似业务和平台发展历程、深入观察服务器领域的发展趋势，我们可以尝试判断平台未来进化的主题方向。
精细化运营背景下基于场景的端到端自动化海量场景下，运营效率的提升和成本的压缩成为重要的目标。平台已经实现了很多节点的自动化作业，降低了人工投入。在此基础上，可以将运营重点转向更细致的运营规划，根据运营场景设计串接各个自动化节点，逐渐形成自动化运营的场景闭环。例如在故障处理流程中，之前已经有了故障监控、自动修复等自动化工具，但是整个故障管理的场景仍然需要授权、诊断、验收等环节的人员参与，并且与备件管理等流程未能实现联动。在平台和数据基本完善的基础上，未来可以将故障预测、备件调拨、故障自动化修复、故障现场处理、资产出入库管理等全面闭环起来，针对故障管理场景实现各流程和数据的联动自动化运营，进一步降低人力投入、提升处理时效。
服务器运营平台向底层技术领域施加更大的影响力在初期，服务器运营平台雏形阶段主要凸显其工具化属性，需要平台开发和运营对于不同厂商设备的管理、操作系统等技术知识有深入的了解，以便基于厂商标准/OS特性进行工具化定制。服务器运营平台对于厂商的技术影响力还不够，其主要原因是平台自身对于服务器运营领域的整体规划管理尚不够深入。
随着现场外包模式、业务和平台发展，需要平台将底层设施的技术特点进行封装，以便标准化运营工作降低其技术复杂度。例如，各家厂商提供了不同的带外管理GUI和API，如果不能很好的在其上封装一层标准的带外作业管理，则带来众多同学的大量学习成本。我们不但将带外作业进行了统一封装，而且根据用户使用场景提供了简洁的Web入口、标准化的API接口，屏蔽了带外管理的复杂性，甚至大部分用户根本就感觉不到带外系统的存在、却可以方便的重启机器和拉取信息。
随着平台统一和能力的进一步拓展，对于运营场景和用户需求进行标准化封装和出口管理的基础上，我们可以就平台角度对厂商和业界发挥反向影响和标准定制能力。我们在规范化整机和部件引入、标准化的信息采集、自动化的部件测试、整机柜3.0管理等领域，通过平台能力逐渐形成定制化的解决方案，输出企业标准并推动行业的标准化。通过对底层技术的深度介入管理，平台可以协助研判技术的实际价值、促进技术落地、为用户提供更透明的服务。
大力拥抱智能化，慎防蝴蝶之翼智能化是运营平台发展的必然之路，我们也已经做了很多智能化的探索。例如，我们的服务器备件智能调拨，能够根据过往的故障率预测未来一段时间的故障数，并与当前备件库中的备件数对比，根据设定的阈值/兼容信息/算法自动发起调拨；自动识别需要利旧的部件和需要退役的部件，并自动调拨到相应的仓库。整个过程可以不需要运营管理员的参与，流程自动触发并调度现场工程师执行作业即可。未来我们还会引入更多的智能化运营场景，例如硬盘故障预测触发数据提前迁移/维修作业/数据恢复、资源池设备自动健康度筛查和触发退役后期处理等。
但是另一方面，我们对于智能化场景的规范化管理，还在探索之路上。原始刀耕火种式的运营可能造成多发的零散风险，但是武装上了不完善的智能化（加上作业的自动化）之后则可能隐含更严重的系统性风险。远者如股票市场数次乌龙指造成各交易商系统链式反应、市场大幅波动（尤其是无熔断机制的市场），近者如携程5.28内部运维误操作导致故障。智能化开启了魔盒，必须要加以更高明的设计、更细心的管理，在特定级别特定场景下设置全面的checkpoint，方可有效驾驭。Elon Musk和霍金警告人工智能的无序发展能够带来毁灭，服务器运营领域的无序智能化也可能带来不可预知的后果。运营的智能化和规范化管理双螺旋相斥相吸、共同作用，两者不可偏废。
后记海量服务器运营平台统一化的实践体会之前，我们竖井化建成了很多服务器运营领域的系统工具。例如海量服务器的自动化信息采集和配置管理系统、自动化部署系统、故障告警监控管理系统、远程管控系统、资产管理系统、流程管理系统、数据分析系统等，这些系统对于大多数做过运营系统的同学来说并不陌生，对于腾讯服务器交付和运营管理的大部分场景也能够很好的支持。
但是随着业务发展和管理的不断深入，原有的各类别系统工具分离的方式面临很多问题，例如系统间数据不一致导致的作业失败、流程和用户体验割裂、数据离散难以支撑精细化运营、各系统分离建设导致的设备和运维成本高企/专业化程度不够等。这已经难以满足精细化的业务发展要求，例如运营指标体系建立、服务器健康度评估、部件级资源管理和交付等课题，必须要在统一平台能力的基础上才能承载。
因此，“统一”就成为进化过程中的重要一环。除了上文中提到的技术实践之外，还有一些实践帮助我们加快了这个进化过程：
服务器相关组织架构闭环在“人”这个最重要的因素上实现统一，就能够迅速调整团队的关注点和力量部署。这里一方面是实现服务器相关业务的闭环管理，因为服务器运营平台毕竟是服务服务器运营的，那么必须要和服务器技术/运营紧密闭环；另一方面是实施团队的闭环，平台开发团队需要紧密的闭环管理
服务器运营平台产品规划统一统一产品规划，需要对平台用户、承载业务、服务器技术、现有系统能力、后续业务和平台发展等方面深入分析、主动规划、布道产品推广
服务器运营平台架构统一统一门户/API/用户触点、接入层、数据库/日志、流程引擎和后台架构、服务器和资产数据等各能力层，以及管控Agent、数据采集、数据仓库等专业功能工具，可以快速稳定的交付和质量管理、平台自身设备利用率、各能力层专业度等方面明显提升
服务器运营平台从最初粗糙简易的大一统入口、到各专业的系统工具独立发展，再到今天必须要考虑各类系统的深度整合，以集约化搭建平台、提供开放和定制能力、促进创新跨界的业务管理，仍在不断上升螺旋发展中，也期盼和大家进行全方位深入探讨！
-------------------------------------------
运维帮技术沙龙群：
运维帮订阅号，关注获取更多技术分享