服务器生命周期管理

编者按：推荐各位读者，优先使用公有云计算服务，公有云相比自建IDC，有以下优势：

1. 轻资产

传统IT建设方式，前期通常需要一次性投入相对较多的成本来搭建IT基础设施，包括数据中心、服务器、网络设备等。云计算无须前期资本投入，“按需分配”可以更好地帮助节约前期一次性投入。

2. 灵活

传统IT建设方式，面对业务扩容处理起来显然不够灵活，服务器从采购到上架再到投入使用通常需要半个月的时间。使用云计算的话，扩充服务则只需要天级别至分钟级别。

3. 更好的性价比、更好的体验

公有云服务的规模效应，使得云厂商有能力在单个产品方向上持续投入，沉淀能力，打磨产品，最终给用户提供性价比和体验俱佳的服务。

如果您的业务还没有使用公有云，那么服务器的完整生命周期管理，是至关重要和绕不过的一个话题，本文介绍了自建IDC环境下服务器的生命周期管理。

一台服务器从业务提出预算需求，到最终可以提供线上服务，要经过很多部门的共同协作配合才能完成。随着业务的发展，对服务器的需求也在不断增大。因此采购变得越发频繁，各业务购买的服务器数量也很多。如果整个过程还靠人来协调各部门协作，靠人来完成一些重复过程的操作（如安装系统、系统参数调整、业务依赖基础软件安装等），将会导致效率的极度下降。最终会因服务器交付延期而导致服务出现问题，甚至影响新功能上线，影响业务发展。

随着时间的推移，服务器逐渐老化，故障概率增大，故障频度也会增加。如果服务器规模较大，那么处理服务器故障更是家常便饭。在处理故障服务器时，运维工程师需要预先做很多工作，比如协调备件或新服务器，将故障服务器从集群中摘除，调整监控等。如果服务器只修不换的话，还需要进行持续的状态跟进、记录，以免后续忘记。整个过程非常耗费人力。

正因为服务器的采买、安装、运行、故障、归属调整等时刻都在发生，但过程又是如此的繁杂，所以对服务器平台化管理的需求显得非常急迫。而纵观运维自动化系统，服务器是一种非常明确的实体资源。自动化服务管理的关键能力之一就是通过调度实现服务器资源的调配，当服务器资源不足时，可以自动调配服务器，进行服务部署，并将其注册到服务集群中。而当服务器资源过剩时（如深夜），又能自动减少服务器，将过盛的资源进行归还或调度到其他服务。

服务器在各个阶段会有不同的状态，相关系统会根据状态进行相应的处理。这些状态的变化有些是人通过工单系统触发的，有些是系统执行操作后自动改变的（初始化系统、部署系统、监控系统）。我们将运维场景中产生的各种状态进行梳理，明确每个状态变更点的触发条件、保障流程等，最终形成了对服务器全生命周期的闭环管理，也就是所有状态均在平台中通过特定动作改变，不会出现人为干预而导致的服务器状态错误。这对自动化管理系统非常重要。试想：如果一台服务器正处于“维修”状态，而这时却因为使用系统操作而变为了“可使用”状态，那么它将会被调度系统分配给线上业务进行使用，后果可想而知。

在本节中，我们会介绍如何通过系统管理服务器状态，以及需要哪些前置条件等。对服务器状态的自动维护、状态的触发是工单系统、监控系统自动发现等。前置条件需要备机池，需要产品线临时机器池。

进阶：快猫星云是一家云原生智能运维科技公司，由开源监控工具“夜莺监控”的核心开发团队组成。快猫星云打造的云原生监控分析平台——Flashcat平台，旨在解决云原生架构、混合云架构下统一监控难、故障定位慢的问题。Flashcat平台支持云原生架构、公有云、物理机/虚拟机、混合云等多种环境的监控数据统一采集，集告警分析、可视化、数据分析于一体，从业务到应用到基础设施，打通metrics、logging、tracing、event，提供立体的、统一的监控解决方案。您可以使用Flashcat平台，快速搭建适合您自己的统一监控系统。

服务器状态

服务器从业务提出需求到为线上提供服务，再到故障维修、下线归还，主要经过几大环节，包括：采购、装机、服务准备、服务中、故障、下线。每个环节会有多种子状态，涉及不同的自动化系统。

1．采购

预算、采购主要是通过预算系统来完成的。工程师通过该系统提交服务器需求，各团队在此系统中完成审核、审批、生成采购单等工作。采购包括审批中、采购中、已到货三种子状态，这是由人来更新的。运维工程师可以通过此系统跟进服务器的购买进度。

2．装机

服务器到货后，会进入装机环节，系统运维工程师会进行网络资源分配、系统安装等工作，对应的子状态为“网络资源分配完成”、“系统安装完成”。这些动作都是通过相关系统完成的，涉及网络资源管理系统、自动装机系统。

3．服务准备

当系统工程师将系统装好后，服务器会进入到服务准备环节，此时服务器开始按业务的需求进行服务器命名修改、系统环境私有参数修改、服务程序部署。两种子状态分别为“私有环境初始化完成”、“服务部署完成”。此时，虽然服务器已经搭建好，但并未加入到在线集群中。一般构建好一个服务环境后，还需要进行相应的测试。

4．在线服务

线下测试通过后，准备阶段完成，该服务器会被加入到线上集群中，提供线上服务。此时进入到在线服务环节，子状态变为“服务中”。

5．离线

如果服务器资源出现过剩，则需要释放资源，我们会将服务器归还公司。服务器进入离线环节，子状态为“离线中”。在调度系统中，这种状态的机器被定义为健康的、可随时使用的资源，是被优先筛选的。

6．故障

在服务器出现故障时，我们会将其子状态设置为“故障中”，此时服务器进入故障环节。对于故障的处理方式有两种：停机维修和更换服务器。SRE会根据情况进行选择。如果故障服务器的内存等易换件坏了，我们会选择停机维修，主要是更换机器就涉及应用、数据的迁移，考虑到运维成本，这是没必要的，但这种维修一般需要的时间可能会偏长，需要业务确认是否可以容忍。如果服务器主板等维修起来很麻烦的部件坏了，一般会选择更换服务器。对于硬件故障的判别，我们主要靠带外监控来主动发现。还有一种情况是从业务上判断服务器整体性能出现下降，不如其他同型号服务器，我们可能不知道是什么原因导致的，这时就会选择更换服务器。具体的故障点系统工程师线下再去追查。当服务器修好后，会自动进入装机环节，重新安装系统等待调度（注：有一种情况不会进入到装机环节，而是进入到服务准备环节，具体场景在业务临时机器池中说明）。

7．报废

这种状态一般SRE不太关注，系统工程师会根据服务器的年限、故障情况设置其状态。

具体状态如表1所示。

在机器管理中，需要两个服务器池来放置不同状态的服务器，即公共备机池、业务临时机器池。

前置条件

在服务器管理系统建设中，需要两个服务器池来存放不同状态、不同业务归属的服务器。

1．公共备机池

这里的服务器不属于任何业务，是公共资源。服务器都处于系统安装完成状态。当某个业务资源不够时，调度系统会从中调配服务器。也可以通过系统来进行筛选，并通过工单系统发起备机申请流程，进行服务器借用。最终归还时，也会划分到公共备机池中，继续供其他业务调配使用。进入到备机池的服务器都会被强行重装系统，避免之前业务修改的系统参数影响别的服务。

2．业务临时机器池

这里的服务器属于特定的业务，是私有资源。主要是为两种场景设计的：一是特定业务定向采购的服务器，当安装完操作系统后，会自动进入业务临时机器池中，对应的服务器状态为“系统安装完成”，工程师可以随时使用；二是服务器故障，需要停机维修，因为选择了保存业务环境，所以修复后其依然归特定业务所有，此时服务器状态为“故障中”。在服务器维修好后，不会进入到装机环节，而是进入到服务准备环节的“服务部署完成”状态。在测试通过后，会由人触发，将其加入集群提供服务。如果这个步骤接驳自动化测试，则可以自动完成，但目前主要还是人工干预。

服务器管理系统

在系统设计阶段，我们对服务器管理系统提出了三大原则，以保证该系统可以作为底层服务可靠地运行。

（1）灵活扩充环节与状态。

主要因为公司的组织结构有可能发生变化。这时有可能影响整个服务器生命周期涉及的团队及流程。举例来说，公司出于安全考虑，新出规定要求所有报废的服务器必须由安全团队进行审查（审查可能是人工完成，也可能是系统完成）才能最终得到“报废”状态。这时我们就需要增加安全审查环节，制定相应子状态并与其系统对接。

（2）流程的闭环。

服务器状态的正确性是非常重要的。一旦状态出现混乱。我们将不知道哪些服务器可用，哪些不可用。调度系统也会将有问题的服务器提供给线上使用。因此，所有状态的变更必须通过明确的平台流程进行控制。主要是为了确保状态信息的准确，不会出现“遗漏”或“配错”。例如大批服务器到货，系统运维工程师安装完操作系统后，会交付给各业务的运维工程师，如果靠人来通知各业务服务器列表，再由各业务手工改变服务器状态，从历史来看一定会出现遗漏。如果自动装机系统能够自动触发状态变化，运维工程师只要查看自己业务的临时机器池中是否有新机器即可。不需要人在中间进行执行，那将不会出现实施层面的遗漏。

（3）提供统一接口获取资源。

无论是实体服务器资源还是虚拟机资源，也不管是服务于公司的私有云还是对外的公有云，都需要通过统一接口进行资源申请，获取到资源后再自行安排使用。因为如果是多套系统或多种申请方式，将导致工程师要进行频繁的工作方式切换，降低工作效率。自动化系统也要考虑各个服务器管理系统的融合（这本不该是自动化系统考虑的）。更重要的是，服务器管理涉及业务使用资产成本的问题，不统一管理，将出现资产的混乱。

如图1所示是服务器状态图，我们会针对一些关键流程进行说明。

1．私有环境初始化

服务器在系统安装完成后，只有一个临时名称，在业务临时机器池中一般命名为music-tmp100。music代表业务线，tmp100代表业务临时机器池内的服务器及数量编号。在公共备机池中的会被命名为sys-buffer199。不管服务器来源于哪里，业务都需要对其进行私有环境的初始化。我们会将其按业务需求进行改名，如music-fe30，规则同上，这个名称确定了其在music业务中用于什么。这里可能有人会问：为什么不在预算环节就定义好服务器名称，这样就可以省了这一步？这是因为在采购的这段时间，线上服务器也在发生着变化，可能会导致与预算服务器定义名称冲突，从而带来未知问题。

服务器改名完成后，开始进行业务私有环境部署，如JDK升级、Python升级等，我们称之为runtime，也就是业务运行时所需要的依赖。我们是通过Ansible自动完成这个动作的。此时服务器状态被设置为“私有环境初始化完成”。

基础环境准备好后，就可以通过部署系统部署服务程序了。只要有一个程序部署成功，系统就会将服务器置为服务部署完成状态。这里可能大家会有疑问，一台服务器上可能部署多个程序，为什么只要一个部署完成，即会改变状态？这样设计的原因主要是为后续调度系统考虑，它会根据线上情况自动决定服务器上部署什么，所以哪个程序部署成功，即代表其提供什么服务。

2．服务中

测试通过后，就可以提供线上服务了。这种状态目前由人来触发，后续接入自动化测试后，可自动完成。

3．服务器下线

下线分为两种场景。

• （1）服务器归还公共备机池。这类服务器一般是业务较长时间内不再需要这些资源，所以释放给公司，作为公共资源。资源统计系统也不再将其计为该业务成本。
• （2）服务器放到业务临时机器池中。这种情况是业务短时间内还需要使用这些资源。如果放到公共备机池中，有可能被分配走，所以临时放置在这里。但资源统计系统会定期筛查，超过一段时间没有使用，会自动将其划分给公共备机池。

4．服务器借用

当业务自己的临时备机池筛选不出服务器时，会考虑借用，来源统一为公共备机池。即便是两个不同业务线之间借用服务器，也要遵守这个规则。被借方需要将服务器归还公共备机池，需求方再从中借用。业务线之间私自调换服务器的行为一定要控制，否则在资产管理上将会出现混乱。

5．服务器故障

故障的处理分为两类。

• （1）更换服务器。主要适用一些不好修或不确定问题的场景。这个过程比较容易，分配一台新的服务器即可。但需要初始化、部署服务等环节。而旧的服务器下线修好后，会被放置到公共备机池中。
• （2）故障维修。如果只是硬盘、内存等坏了，一般会选择这种方式。迁移成本比较小。这种处理方式，在系统修好后，还属于原来的业务，启动服务即可。

环境初始化

环境初始化的需求是这样产生的：

• （1）由于基础设施的区域化自治设计，部分配置在不同区域有差异。比如内网DNS区域化自治，不同区域的服务器，在resolve.conf中配置的服务器IP地址不同，需要进行环境初始化。
• （2）随着运维基础设施的建设，每台服务器上越来越多的Agent需要安装升级，升级频度远比装机包的更新高，因此也必须额外进行环境初始化。
• （3）业务应用程序，对系统环境有特定的需求（库、语言环境、内核参数等），但这些特定的环境需求又无法统一，这是环境初始化最重要的需求。

传统模式的环境初始化，通常使用业内流行的配置管理工具完成，如Puppet/Chef/Ansible等。常见的批量管理工具大致分为Agent模式和非Agent模式两类，在性能、可靠性、易用性、可维护性等方面各有千秋。基于以下几方面考量，我们选择非Agent模式的开源工具Ansible作为统一的批量管理工具。

• Agent维护成本。Ansible使用SSHD作为Agent，不产生额外维护成本；省去了Agent端的安装、升级、进程守护等额外的管理成本。
• 权限和认证管理。Ansible的设计模式使其天生就具有认证功能，而中心控制模式容易与现有权限管理系统进行对接，实现基于用户身份的认证和访问控制。
• 功能可扩展性。模块化实现使扩展功能更容易，并且中心控制模式使扩展功能的升级更加便捷，利用扩展模块与其他自动化系统接驳和联动，使Ansible更加易用。
• 易用性。Ansible的使用方式更接近于传统SSH，更适合支持传统的运维管理方式。
• PlayBook。基于PlayBook功能，容易将基础环境配置、常用操作等固化，并结合初始化平台进行主机初始化或统一变更。

本文遵循「知识共享许可协议 CC-BY-NC-SA 4.0 International」，未经作者书面许可，不允许用于商业用途的转载、分发、和演绎。本文内容，由 Wilbur、VicLai 等共同撰写，仅代表相关个人见解和立场，与任何公司、组织无关。