4小时：打破常规，打造黑石物理服务器极限交付

作者：代明敖

一、4小时前……

服务器生产部署、重装交付，是服务器运营的重要工作之一。或许有人会说，不就是安装或者重装个操作系统嘛，我光盘1个小时搞定，OK，如果是仅仅一台机器，那么你赢了！而服务器运营面对的是70W级别的服务器，每天重装和部署都有约2000台的数量，是不是需要再重新考虑下这是否还是个简单的事情？生产部署和重装看似安装操作系统那么简单，实则非常复杂，服务器运营经过近十载的积累，伴随公司海量业务的发展而逐步成长，由08年的刀耕火种到17年的全程自动化无人值守交付，交付峰值从100台/周到2.2W+台/周，提升200多倍。按照当前的自动化能力，当公司服务器过百万时，依然可以泰然处之。然而腾讯云黑石的出现，犹如平静的湖面投入一块石头，打破了海量业务下服务器运营的平静。

二、4小时：知易行难

腾讯云是公司的重要战略，基于物理机售卖的黑石，是腾讯云的重要一部分，因此对黑石服务器的运营支撑是服务器运营的重要环节。俗话说”台上一分钟，台下十年功”，这句话用在黑石服务器运营上也非常贴切。如下图黑石官网的描述：“获取服务器时间将被缩短至4小时”；黑石对外的这个服务承诺，服务器运营用了大半年的时间来逐步提升运营水平最终顺利达成对外承诺，坚定不移的做好专业服务伙伴，为腾讯云的发展保驾护航。

图一 腾讯云黑石首页

了解服务器运营或者熟悉公司资源交付业务的同学，可能都比较清楚，服务器生产交付的标准SLA是3天，即服务器从上架完成到交付到业务使用，运营需要不超过3天的时间来完成操作系统的部署；但黑石承诺只需要4小时就能交付设备，相对于公司海量业务，效率提升整整18倍；面对黑石交交付带来的挑战，如何把交付时间从3天缩短到4小时，这是服务器运营面临的难题，也是黑石前期生产交付的主要矛盾；另外海量业务模式下，相同厂商同型号服务器硬件配置和软件配置都是完全相同的，举个例子， 相同厂商同机型的BIOS的配置是完全相同的，由厂商已经按照要求在出厂时设置完毕；但到了黑石业务模式，由于第三方公司对服务器性能和配置要求的差异，同机型的BIOS配置存在很大差异，因此4小时完成交付不但包含了传统的生产部署操作，还要额外增加BIOS差异化的配置工作，来满足外部客户各种个性化的需求；对于服务器运营，这些操作系统部署以外的操作无疑是雪上加霜，4小时内完成操作系统部署已经是一个很大的挑战，现在还要进一步实现差异化的系统配置。按照传统的方法，这些操作需要派单给现场由人工来操作，那么达成黑石对外承诺的4小时交付OS基本上是纸上谈兵了。但作为专业的服务伙伴，服务用户和解决用户的问题，是我们的责任。如何协助云平实现黑石对用户的承诺，做好云平专业的服务伙伴，是服务器运营面临的最大挑战！

在黑石业务模式下，服务器运营面临的主要挑战有：

• 交付速度快

黑石业务要实现物理机类虚拟机的生产交付速度体验，即实现把海量业务下的3天交付缩短到4个小时内完成。与传统海量业务3个工作日的SLA相比，这是天翻地覆的变化，对运营生产交付的极限挑战。为什么说4小时交付是极限挑战呢？我们先来看看海量业务的生产交付流程及各个阶段的OLA，如下图二海量业务生产流程及OLA：

图二 海量业务生产部署流程及OLA

注：各个阶段的OLA处理时效，是指该阶段出现异常后相关环节的负责人需要在OLA时效内完成；如果无异常自动化处理时间会低于上述OLA的值。

从上图海量业务生产交付流程及各个环节OLA时效来看，黑石要实现4小时的快速交付，可能性是非常小的，主要困难是：

首先，生产交付的整个流程非常的长，有十几个步骤的操作任务要执行，在每个步骤都是全自动化完成的前提下，也未必能达到4小时交付的目标；

其次，十几个操作步骤的任务执行，难免会有自动化执行异常的情况，任何一个异常都会导致无法实现4小时交付。这时候需要100%的自动化系统，可是没有人能保证设计和开发的系统是100%不出问题的。

所以从3天（72小时）到4小时这样效率提升18倍的“硬骨头”，服务器运营也是第一次面对，心里基本没有把握，唯一的感觉是压力山大！

• 质量高（交付质量99.99%）

在海量业务模式下，用户对服务器的核心需求是海量，即业务需要大量的可用服务器，所以交付及时率是主要矛盾；在保障及时交付的前提下，我们通过各种交付检查手段，保证交付质量达到99%可用，剩下1%可能存在异常的服务器最多会导致业务出现毛刺，而不会影响业务正常的运行，因为海量业务自身有冗余设计，对服务器个体故障基本无感知，如服务器、机架、甚至是机房的故障，可能都不会对业务产生大的影响，系统都能快速完成灾备切换。

黑石第三方业务，往往都有以下两个特点：第一，业务普遍处于发展期，运营和容灾意识匮乏，更多的精力是在发展业务提升用户，或者说如何让产品活下去，并且架构缺少冗余设计，单点场景会比较多；第二，成本是用户非常关心的问题，为了降低业务成本，短期可能是损失健壮性和业务冗余性，综合这两点来看，用户对服务器故障感知特别明显，一台服务器宕机就有可能导致整个业务不可用。

由成千上万个电子元器件组成的服务器，是必然会出现故障的。根据业界公认的“浴盆曲线”理论（如下图三浴盆曲线），服务器故障会经历“早期故障”、“中期平稳”、“后期故障”三个阶段，

图三 浴盆曲线

因此设备交付初期业务刚上线时可能会触发相对较多的故障，如何降低浴盆曲线中的早期故障，把黑石交付质量由99%提升到99.99%，是压在运营团队心头的一块大石头。

• 个性需求多

腾讯海量业务下，生产部署功能比较单一，只需要按照既定的模板完成生产部署即可；但黑石业务从诞生开始，就区别于传统业务，有很多个性化需求。

举个真实的交付案例：当时滴滴打车进驻黑石时，需要100台关闭BIOS超线程的机器。可是海量业务下没有过这样的需求，运营还没有自动化手段批量修改服务器的BIOS设置。传统的方法是派工单给机房现场人工进行修改，最终通过人肉耗时1天多完成100台机器的BIOS超线程关闭操作。

我们再看看黑石的自定义分区需求，这个也是与海量业务分区差异较大的地方。海量业务下我们所有的OS默认只有4个分区，并且已经固化在操作系统镜像中；而黑石自定义分区如果使用海量业务的方法，不同的分区格式对应一个系统镜像，那么需要维护的系统镜像会是几何倍数的增长，已经推动可维护性和可操作性了。

因此，如何在海量业务的背景下快速满足黑石的个性化需求，也是摆在运营面前的一个难题。另外黑石的个性化需求远远不止上述的两个，请看列表：

网络架构特殊：underlay/overlay，mgt/去mgt，NO，VPC，MGTGW…… 服务器种类多：各种不同配置的自定义机型， 操作系统种类多：centos，debian，ubuntu，redhat，gentoo…… Agent：用户可以选择是否安装，且还有EMR、CBS等功能性agent OS分区自定义：用户自定义分区大小及挂载点 RAID结构多样化：2RAID1+10NORAID，12NORAID…… BIOS设置多样化：超线程、C-State、P-State……

三、明知山有虎，偏向虎山行

面对黑石业务带来的挑战，服务器运营积极探索，分析当前海量业务与黑石业务的差异，针对黑石的业务特点，对症下药，提出一系列创新的建设性方案（例如首次提出资源池的概念），对当前的业务流程进行提炼和优化，并附以更多自动化工具的支撑；与服务器技术团队和厂商深入协作，建设部件性能基准以及推行压力测试，并积极学习和吸收业界经验，稳步应对黑石挑战：

1、建设黑石资源池，统一资源生产环境，提高生产部署成功率

根据服务器运营的经验，生产部署过程中，最容易出现问题的环节，都是在部署前准备的操作，如机架开电、切换部署VLAN、开机PXE等操作。例如，服务器机架开电操作，需要由机房驻场向机房运营商提交开电申请，运营商审核通过后才能安排专有人员进行开电操作；另外可能还会遇到机架超电等异常情况，这时还不能直接开电，需要再发起搬迁流程，把设备转移到其它电力负载较低的机架，整个过程耗时少则半天，多则2天都未必能完成。如果黑石也沿用海量业务的流程，那么黑石达成4小时交付的目标，基本落空了。

那么如何解决部署前可能产生的种种异常呢？有没有方法把部署前的各种异常提前识别发现，并加以处理，达到一个统一的环境，当用户购买设备后，直接发起部署操作呢？答案就是建设黑石资源池！

黑石资源池通过定时自动扫描发现约定的业务模块下的设备，然后把设备加入到黑石资源池，通过自动化流程实现设备接入到minios状态，并对设备进行20多项健康检查，完全抹平服务器生产部署前的环境差异，从而实现用户购买时的快速部署交付。如下图三黑石资源运营框架：

图三 黑石资源池运营框架

通过建设上述黑石资源池，一方面实现把生产部署前期出错机率最大的环节提前识别并加以解决，设备以minios状态行，可以随时投入生产环节以快速生产；另一方面我们可以基于minios进行一系列的信息采集和及操作，如下文将提及的相关部件性能和压力测试。

2、建立部件性能基准，推行性能测试和压力测试

如上所述，服务器故障是不可避免，但黑石用户又对服务器故障特别敏感，如何缓解这个矛盾呢？这个问题的关键是如何降低服务器故障率，提高服务器质量，提升服务器可用性。

根据服务器运营经验和服务器类电子元器件的故障规律，对服务器进行部件性能测试和模拟一定的业务压力进行压力测试，可以提前识别潜在坏件，甄别异常服务器，提升服务器质量。基于这个结论，服务器运营联合服务器技术，分两步走来实现服务器质量的提升。

第一步，构建腾讯服务器部件性能基准，所有服务器交付前进行部件性能测试。没有标准的情况下，部件虽然可以正常工作，但无法确定性能是否达标；性能的不达标，也很可能是故障的前兆。所以建设部件性能基准，推行部件性能测试是提升服务器质量行之有效的方法。目前实现了服务器三大基础部件CPU、内存、硬盘的性能测试，并与标准进行比较。如下图四腾讯服务器部件基准数据所示：

图四 服务器部件性能基准

第二步，实施压力测试。部件性能测试保证单个部件是健康的，且性能达标，那么多个部件通过主板组合起来后，部件协同工作是否正常？整体性能是否达标？这还是一个未知数。压力测试紧跟部件性能测试，来验证整机是否正常，有没有潜在的问题。由于黑石资源池设备随时可能被用户购买，所以不能一次对所有设备进行压力测试，当前的压力测试策略是每天凌晨选择若干数量的设备循环进行压力测试。

3、摒弃冗余节点，提升流程效率

黑石发展初期，黑石和海量业务使用同一套生产部署流程，后来发现由于黑石业务的个性化需求比较多，且与海量业务存在不兼容的情况，因此分离创建单独的黑石生产部署流程。黑石生产部署流程来源于海量业务流程，但又与海量业务流程有区别，黑石有资源池保证入口环境的统一性，因此原有流程的中的部分节点，如“机架开电”、“带外检查”、“交换机检查”等步骤已经不再需要，且已经成为提高黑石生产力的障碍。另外由于黑石部署都是由资源池设备发起的，资源池已经保障了设备成功安装minios，且保证机器已经开电、带外可用、交换机也已经开电且状态是正常的，抛弃这些为海量业务设计又不适用于黑石业务的节点，是提升黑石部署效率的捷径。请看下图五，优化前和优化后的黑石部署作业流程对比：

图五 黑石部署作业流程优化前后对比

上图可以看到，优化后的黑石部署作业流程非常简洁，且完全对接黑石资源池的功能：资源池把设备接入minios并完成健康检查，部署流程直接从健康设备的minios开始进行后续OS安装操作，基本实现一气呵成，流程效率得到极大提升。

流程经过优化后，效率提提升，但新的问题又出现了。新的问题是黑石RAID修改问题，主要表现在两个方面：第一，黑石机器的RAID结构，在用户发起购买前是不知道的，所以无法提前构建，资源池不能解决RAID修改问题；第二，传统模式下RAID修改操作是在pxe下执行的，而黑石部署的第一步就是minios，因此修改RAID就需要重新接入pxe，一方面降低了资源池的设计效果，另一方面RAID修改逻辑中，会有删除minios、关机、开机进pxe、RAID修改、安装minios一系列步骤，虽然都是自动化完成的，但耗时也差不多需要1个小时，且难以避免自动化失败的场景，耗时就不可估量了。如何解决RAID修改的问题，运营侧创新性的实现了在minios下修改RAID功能，即把传统的“删除minios、关机、开机进pxe、修改RAID结构、安装minios”优化为“修改RAID结构”一步达成需求，实现由盘山公路到隧道一样的变革，效率得到很大提升。

4、DevOps解耦部署系统，支持个性化

相比海量业务，黑石业务支撑了用户极大的个性化需求：包括已实现的机型硬件配置定制、BIOS配置指定，分区指定、RAID类型穷举支持、Agent指定等，以及正在规划中的用户自定义镜像部署支持，几乎覆盖了整个生产链路。 而海量业务下的流程体系，部署实现方式，工具系统在开发效率和功能上都难以支撑类似需求，为了更好的解决这个问题，我们在DevOps方面也进行了一些初步探索和实践。

这里以系统分区自定义举例说明，海量业务下，分区规划以及文件系统挂载文件/etc/fstab由于母盘镜像定义，这种方式无法支持不同用户对于系统分区的独特需求。而在黑石业务下，我们将部署系统的分区方式从固化模式抽象成一个独立的部署功能模块，它可以接受指定分区挂载点以及对应的每个分区的大小，并具备校验和容错机制以防止需求不合理时造成的异常。uwork process流程再整合该部署功能模块封装为API接口供云平黑石系统调用。类似的思想也应用在了RAID类型穷举，BIOS配置指定等方面，而这仅仅是在部署底层吸收了DevOps的一些思想，它实现了一些个性化需求的支撑，但从部署底层和Process的结合情况来看，还是属于传统的一种开发模式。

而实际上，运营侧和开发团队还一直在进行更深入的DevOps探索和实践中，比如部署process从偏流程化，封闭化（流程固化，新功能接入开发上线周期长）改为更开放化，平台化（即插即用，新功能接入无需代码改动），在部署底层和process之间定义双方的交互界面和输入输出。这样运营侧新发布的功能模块可以更快速的接入平台，也可以更好的支持个性需求的快速迭代和发布。

四、4小时以后……

通过上述的各项努力，2017年中我们最终达成黑石对外承诺的物理机4小时交付的目标，交付时效如图五所示：

图五 黑石4小时交付趋势图

一路走来虽然很艰辛，踩了很多坑，也走了一些弯路，但与周边团队的协作及通力合作，达成目标的成就感，以及由0到1实现物理机快速交付跻身业界前列，是辛苦付出的回报，也是收获的最大快乐。短期的交付效率目标虽然已经达成，但提升交付质量的课题已经摆在眼前，这里只是小憩，稍作整顿和回顾，继续向新的征途出发。