在联想14年的冷显慧，在工作的大部分时间都是在机房中和数百台服务器设备打交道，而他的故事正是联想运维人中的一个缩影，在数字化转型的过程中，每个信息系统的稳定稳定运行，都离不开背后运维人员的努力。

我叫冷显慧，在联想集团14年，其中7年是在联想研究院企业及云计算研究室（Enterpeise & Cloud Research Lab，ECR Lab）度过的。每天打理机房的数百台服务器等硬件设备，这些设备构建了ECR Lab所有的IT基础架构与各种云服务。上面承载着ECR Lab的代码库、项目管理系统（JIRA）、文档管理系统（Confluence）、镜像仓库和制品库等数十个内部业务系统，时光荏苒，我有幸见证了它们的成长。

运维工作或许无味，大部分是基础保障性的工作，但这些设备及系统的正常运行，关系到全研究室及部分研究院其他团队上百位研发同事的工作是否能顺利开展，比如代码库的系统运行状态影响到研发人员能不能及时提交代码、项目管理系统关系到到项目经理、产品经理、测试团队与研发团队是否能顺利能跟踪各个问题的最新状态等。

平日里的我是一个八面玲珑的八爪鱼

研发的同事们需要稳定、高效、便捷、全面的软硬件服务，包括服务器、网络、存储、监控、信息安全、数据备份等，小小的运维团队需要身兼数职，麻雀虽小但要五脏俱全，各个技术方向的技术储备都要有所涉猎，背后的努力和艰辛可想而知。在运维工作中，最难处理的是复杂环境的故障分析和诊断（Trouble Shooting）。

在近期有一个客户定制化交付项目，用到了ECR研发的联想边缘计算平台Lenovo Edge Computing Platform（LECP），LECP是Lenovo 3S战略中，横跨了端、边、云、网、智的一体化边缘计算平台。测试团队在内部测试过程中发现，在模拟管理接入100个边缘终端（可简单理解为一个PC机）时，部署在IDC（Internet Data Center）的云端管理平台存在CPU资源耗尽问题，而在Lab内的研发环境并无此现象，且无法复现。研发同事经过诊断和讨论，初步怀疑是IDC机房的网络带宽性能异常（曾经出现过网络性能问题），或者部署在IDC的私有云平台的性能存在问题。

接到研发同事的反馈时，距离项目组内部制定的阶段性计划deadline只有4天时间。而这种涉及广域网的系统故障是比较难定位的场景之一，牵扯到多种软件系统（LECP、私有云平台）、硬件（服务器、网络设备、防火墙），不同的网络类型如Lenovo研发网、IDC网络，每一个环节都可能存在问题，哪怕是一根网线的松动都可能导致故障发生。

根据研发同事怀疑的2个方向，我先分析了IDC机房最近2周的网络流量监控数据，流量没有明显异常，说明由IDC网络导致的影响可能性比较低，同时请测试团队的同事帮我做了边缘终端的数据下载测试，至少证明在测试的时间点时，可以达到IDC的标称的带宽性能（无法验证是否有间接性异常）。另外检查云平台的后台，多个服务器的运行状态结果显示系统资源比较富裕，根据多年的运维经验判断，云平台的性能不存在瓶颈（云平台是ECR参与研发的云计算私有云产品ThinkCloud，可提供虚拟云服务器，已经投入生产运行并运维多年）。

如果研发同事怀疑的2个方向可能不是主要影响因素，那我如何进一步证明或者复现故障现象呢？

我先从研发环境和测试环境的差异来比较入手分析。最大的差异是网络连接带宽不一样，研发环境的边缘终端和管理平台均部署在公司研发网，边缘终端与管理平台之间的网络连接带宽比较高，可以理解为是一条信息高速公路。

而测试环境的边缘终端在研发网，管理平台却部署在北京郊区的IDC机房，它们之间是通过Internet连接的，经过的网络设备很多，网络连接质量的波动也比较大，且边缘终端与管理平台之间的网络连接带宽只有研发网的1/14。另外，研发网的Internet下行下载带宽比较低，研发网上千台设备的网络资源竞争也会影响终端的网络数据下载性能。但是由于之前的下载测试可以达到理想效果，说明研发网的带宽很可能也不是瓶颈。

既然两个环境的最大的差异是网络连接带宽，我最终决定调整研发环境的网络带宽，尽量模拟测试环境的网络条件，将带宽限制到与IDC相同带宽，经过3个多小时等待，通过监控系统发现，成功在研发环境复现了CPU资源耗尽的现象。至此可以得出结论，故障原因很可能是管理平台的某个组件导致，进而交由研发同事继续定位产生故障的根本原因(root cause)，使项目进度可以顺利推进。

工欲善其事，必先利其器

由于团队成员少，且要全方位兼顾运维领域，因此我比较注重运维工具系统的建设，只有提升工作效率，才能给研发团队提供更好的IT服务。

针对不同的运维领域需求，需要用适合的软件来解决问题。有的需求需要查找最适合的软件工具来解决，而且需要进行功能性、稳定性、兼容性、易用性等方面的测试。比如为了第一时间发现软硬件故障并及时修复处理，分别针对软件监控、硬件监控引入了2套监控系统，并通过数据可视化系统，将运行状态和告警信息展示在电视大屏上。

研发同事经常有重新安装服务器操作系统需求，部分服务器每天都要重装系统，而且安装配置要求也多种多样。曾经运维人员习惯用光驱到机房现场手工安装系统，每一台逐一安装，费时费力，还要忍受机房的噪音。现在运维人员甚至研发人员，通过访问一个网页，点击几下鼠标即可完成。而且可以同时处理几十台甚至几百台服务器。这是因为经过几年不断的实践，测试过超过30款以上的软件，最终找到一款最适合ECR工作场景的企业级数据中心批量部署操作系统的软件。

8月初有个紧急任务，是将研发人员使用的代码库迁移到新服务器，传统的办法是将每一个代码工程手工导出成备份文件，再导入到新服务器上，只有这样才能保留全部数据，而涉及的代码工程有126个，如果全手工操作，不仅效率低下，而且极易出错。而且只能在周末处理。

为了解决这个问题，我在博客搜索到的一些方案经测试并不理想，依然无法批量处理。然后又在Github（全球最大的开源软件项目代码分享与托管的网站，程序员必备）检索是否有能解决此类问题的开源项目，在看过100多款软件的简介，并测试了20几个之后，找到一款与我们使用的代码仓库相匹配的开源软件项目。

在正式迁移之前，我做了迁移演练，发现最多一次只能迁移20个。开源软件项目通常是作者是根据自己实际使用场景编写的，可能没有充分考虑到各种可能的场景，其他人使用开源代码时发现无法满足自己的场景是很正常的，但是由于有源代码，是可以自己进行修复软件缺陷或者二次开发进行功能增强。经过分析源代码，最后发现是程序有个小BUG。修改了源代码之后，再修改几个配置文件，执行程序后就可以耐心的等待了，剩余的任务会由程序全自动化的进行处理。正式迁移时，用了不到4个小时就成功迁移了全部的代码库，而且准确率是100%。

为了提升ECR自研软件的产品质量，ECR推行了Dogfood策略。这是来自微软的方法，微软开发的软件先在自己公司内部试用，让研发人员在使用软件过程中发现并提前解决软件缺陷，避免到客户环境中才发现，从而提升产品质量。因此我们运维的ECR IT基础设施架构是基于ECR及其他联想自己的软件产品构建的，比如LECP 、ThinkCloud私有云、ThinkCloud Storage（分布式存储系统）、LKS[1]、LXCA[2]、LXCO[3]等。这样既解决内部研发对资源的使用需求，又验证了产品的稳定性和可靠性，一举多得。

在我们的精心呵护下，所有的服务器及应用系统运行良好，各项运行数据为智能运维研究团队的研究提供真实生产系统数据做数据分析，如磁盘故障预测、慢盘检测等，这些功能被集成在ECR Lab目前的主要产品LECP和Lenovo Infrastructure Solutions Group（ISG）的 Lenovo XClarity Orchestrator（LXCO[3]）中。

我们运维的私有云平台，不仅对ECR Lab内部的研发团队提供服务，也提供给研究院AI Lab、智慧教育、智慧医疗、区块链等多个研究院的兄弟团队使用，支持更多的客户项目。我作为运维接口人，跟这些团队沟通使用需求及使用故障处理。研究院兄弟团队使用的ECR的云服务器资源，相较于使用公有云，每年至少为公司节省350万，累计节省上千万人民币。

疫情100%到岗为IT基础设施保驾护航

每年公司园区都会停电检修电路，且每次都是安排在元旦、中秋节，国庆节等法定假日，为了保障研发人员在假期结束后能第一时间投入工作，我们每次至少在假期期间用1-3天时间来提前恢复服务器及解决各种软硬件故障，确保各个系统的正常运行。

自2019年疫情开始，研究院在疫情严重时，实行内部轮换远程办公，只有运维团队成员始终100%到岗，为的是机房设施出现故障时可以在现场第一时间及时处理，以及当研发人员对研发测试环境的基础设施拓扑有变更需求时，可以在现场快速响应，提供高效、专业的IT服务，保障产品的研发进度。

2022年5月下旬，北京疫情出现反复，海淀区要求全区公司居家办公，而此时既有产品研发需要进行，又有客户项目交付，为保障研发及项目交付的稳定推进，我主动申请在居家办公期间在公司留守值班一周。很感谢运营的同事，很贴心的组建了一个陪我唠嗑的微信群，几十位同事在晚上的时候陪我聊天解闷。

远程办公对部门的项目交付产生了很大影响。一些同事的工作必须在现场才能处理。因此在此期间，我几乎每天白天在机房，帮同事做支持客户项目的终端测试（因为项目使用了PC终端，必须在现场进行测试），及海光服务器集群应用故障处理支持。晚上支持另一个客户项目，协助研发同事对开发板调试，一开始软件始终无法与开发板通信，经过多天的努力，最终找到适合开发机的BIOS最佳配置，最终成功驱动开发板及电机，使项目可以继续推进，很有成就感。

熬过一周本以为结束了，没想到疫情防控结果依然不乐观，海淀的居家办公要延长一周，而原计划安排的留守替换人员，却因突发情况被集中隔离。而其他同事对机房业务不熟悉，因此我再一次主动提出申请，继续在公司留守一周。

一路走来，我和机房里的这些大宝贝们有过很多辛苦又骄傲的回忆。正是这些回忆让我怀抱初心，永远冲劲十足。