工行侯志荣：一体化和自动化运维体系探索

“数据中心操作系统”公众号正式推出《大咖谈运维》栏目，每月邀请3名企业级运维大咖发表原创文章，聚焦大型企业新一代运维理论体系和最佳实践探索

作者简介

侯志荣

工商银行软件开发中心某部门总经理，全国金融五一劳动奖章获得者。其所在团队主要负责行内开放平台基础技术研究，基础设施云平台、分布式技术平台、运维自动化平台、信息安全管理平台和终端管理平台的研发工作。

精彩观点早知道

• 工行自主研发的智能运维平台成功上线，纳管全行数万个节点，侯总综合IT服务管理（ITSM）、数据中心自动化（DCA）、开发运营一体化（DevOps）理论，融合工行多年实践，探讨新一代运维自动化体系。

• 运维是个专业密集型、知识密集型工作，但今天，它在一定程度上还是劳动密集型工作。我们做IT的，一直在努力解放别人，暮然回首，却发现我们还未曾解放自己

• 相对于办公自动化和管理流程自动化，不少企业在技术运维自动化建设方面的重视程度并不够

• 由于IT环境、IT规模、运维人员规模的不同，传统企业和互联网企业在IT管理体系建设方面的做法有明显差异。传统企业大都优先强调管理流程的建设，运维自动化建设工作则在其次，互联网企业大都优先推进技术运维自动化建设，而后再逐步考虑管理流程体系的建设。

• 企业级运维应该聚焦于技术运维工作，重视数据中心技术运维工作的新变化和新挑战，务实地面对技术运维自动化的迫切需求，扎扎实实地打牢这个基础，以便更好地实现IT服务管理和价值创造。

• 运维自动化软件看作是业务系统，其架构设计也可遵循“业务架构→应用架构→技术架构→数据架构”的设计方法论。建立运维自动化体系，应先清晰描述运维业务需求，抽象出业务模型，以确保实现的运维自动化软件最大程度匹配业务模型。

• 提炼出“OASR运维业务参考模型”：对象、活动、场景、角色。（具体描述见正文第三部分）

• 3层面运维自动化功能建设思路：面向资源的运维自动化功能、面向应用的运维自动化功能和面向业务的运维自动化功能。三个层面最好能统筹组织，特别是面向业务的运维自动化功能建设，往往需要从更高层面予以组织推动。

• 4种运维自动化建设的组织模式：分散模式、集中模式、平台模式、自助模式。工行智能运维平台已经达到平台模式，正在向自助模式转换。

以下是万字雄文，阅读全文需要30分钟，建议收藏后阅读，欢迎给公众号发表观点进行讨论。

一、前言

在IT服务管理和运维自动化这个领域，业界近年来的发展比较快。从IT服务管理（ITSM）、数据中心自动化（DCA）到开发运营一体化（DevOps），相关概念和理论不断涌现。从IBM、BMC、HP等传统厂商各类工具产品纷纷面市到Puppet、Ansible、Saltstack等开源解决方案风起云涌，各类工程实践也是精彩纷呈。

放眼如今各类技术论坛、交流大会，运维自动化已然成为专题，各路豪杰纷纷登台，分享案例，探讨方向，令人目不暇接。在这个领域，我虽然在企业内部有一些工程实践经验，但更多的还是一名学习者，经常“潜水”于各种讨论群，关注相关公众号，努力从同行的经验中吸取营养，不断调整我们自己的工作方向。

年前，云霁科技的智总问我能否写篇文章，谈谈关于运维自动化建设方面的意见。是时，恰逢我们团队研发的智能运维平台第一阶段工作完成，将行内数万个节点纳入了管理。我想可以借此机会把这几年的一些思考作一总结，以期抛砖引玉，与同行探讨交流，于是便答应下来。也就有了如下零散的总结，不成体系，还请各位专家指正。

二、运维的定义

（一）运维概念探讨

论及运维自动化建设，首先有必要先讨论一下运维的定义。通常，我们把运维看作是英文“Operation”的翻译。当然，这个单词也可以翻译为“运营”。于是业内也有不少专家同行撰文研究运维和运营的联系与区别。比如，优诺科技CEO陈傲寒曾写过一篇文章《IT：从运维到运营》，里面就有一番独到的论述，感兴趣的同志可参考。

对于我们一线工作者而言，概念和理论固然重要，但如何进行工程实践却是我们更为关注的话题。我们讨论运维的定义，更多的是希望明确其所指代的工程范围。当然，这本身也是一个见仁见智的问题。

于我个人而言，倾向于把运维的含义界定为数据中心各专业技术岗位的日常运维工作，具体而言，就是各专业技术岗位人员与各类软硬件运维对象进行交互操作的活动。需要补充说明的是，技术运维也只是数据中心各专业技术岗位人员技术管理工作（Technical Management)的一部分。因为，这些专业岗位的人员日常还需要完成技术文档整理，技术培训，各类申请提交等技术相关任务。但是，由于这些工作与运维对象并不进行直接的交互，所以不考虑纳入技术运维的范围。如果从ITIL理论体系来讲，这里的运维定义大致可圈定在服务运营（Service Operation）中的IT运营管理（IT Operations Management）范围；如果从DevOps供应链的视角来看呢，则又可对应于技术运营（Technology Operations）的部分。

本文界定的运维工作范围可用下面的图1来表示。

图1 运维定义

（二）聚焦小运维

这样的范围界定，可以说是“小运维”的视角，看起来可能有些“狭隘”。毕竟，在IITL体系中，从V2版本就开始强调要从运营维护的层面上升到服务管理的层面，V3版本则更是强调了服务生命周期管理的理念，如果我们再回过头来讨论技术运维工作，的确有“思想倒退”的嫌疑。另一方面，DevOps也开始讨论如何突破传统的部门壁垒，推进组织文化的革新，以追求更加敏捷高效的IT交付，如果我们还停留在运维部门这一环的具体专业工作，似乎也有些跟不上时代潮流。诚然，按照这些先进理论来推进企业级“大运营”体系的建设无疑是正确的方向，我们不仅不会反对，而且还要一直努力追随。

然而，我在这里聚焦于“小运维”的概念，主要是出于如下几点考虑：

• 无论过去、现在，还是将来，技术运维都是数据中心的基础工作，提升这部分工作的“生产力水平”对于提升整个数据中心运营水平和服务能力至关重要。这既是实现大运营体系建设的基础，也是大运营体系建设的重要内容。

• 随着虚拟化技术、分布式架构、云计算解决方案的广泛应用，企业IT环境正在快速变化，人员流动的风险也在不断增加，数据中心技术运维工作正面临着新的挑战和变化。

• 从实践经验看，生产运行风险很大一部分出在技术运维环节。技术运维操作失误导致重大生产事件的情况我们时有耳闻（就在笔者整理这篇文章的时候，大洋彼岸就传来了GitLab误删除数据库的消息）。这些事件的发生，当然有技术管理方面的问题，但也与技术运维生产方式密切相关。正所谓，生产力决定生产关系。刀耕火种的落后生产方式，必然制约着先进生产关系的建立。运维是个专业密集型、知识密集型工作，但今天，它在一定程度上还是劳动密集型工作。我们做IT的，一直在努力解放别人，暮然回首，却发现我们还未曾解放自己。

• 过去一段时期，相对于办公自动化和管理流程自动化，不少企业在技术运维自动化建设方面的重视程度并不够。比如，有些很早就建立了IT服务流程自动化平台，实现了事件管理、变更管理流程的自动化。但其背后系统、网络、应用、安全各专业的大量技术维护工作长期以来还是由技术人员手工完成。在这个过程中，虽然也在逐步引入或者建设一些工具平台，发挥了一定成效，但并未根本改变运维工作模式。

（三）传统企业 VS 互联网企业

就自己不完全的观察与总结，在技术运维领域，似乎存在两个比较明显的现象：

• 过去从事专业技术运维工作的人员大多定位为管理（Administrator），他们对各类产品的技术原理、命令操作、问题诊断、性能调优等都有相当深入的理解和掌握，其中不少骨干还通过了业界比较有影响力的专业认证。但是他们在开发技能方面好像比较欠缺，有些甚至对完成脚本编写这样任务都感到困难；

• 传统企业和互联网企业在IT管理体系建设方面的做法也有明显差异。传统企业大都优先强调管理流程的建设，运维自动化建设工作则在其次，很多时候优先级还比不上测试自动化建设；而互联网企业呢，大都优先推进技术运维自动化建设，而后再逐步考虑管理流程体系的建设。

对于上述两个现象背后的原因，我也做了一些分析。除了有企业文化和管理理念方面的差异之外，我想还有两个重要因素也不能忽略：

• 技术环境的差异

• 传统企业过去的IT环境，大多是基于商用软硬件构建的，在IT管理方面，通常也引入了专业化的工具产品，因此技术运维要求主要侧重于“能用 ”、 “会用”、“用好”这些工具或产品；

• 互联网企业的IT环境，基于开源和自研构建的比较多，几乎很少采购商业工具软件，因此不得不“自己动手、丰衣足食”，因此我们明显感到他们运维人员“动手能力比较强”。

• IT规模和运维人员规模的差异

对于传统企业而言，

• 虽然近10年IT规模也在不断增大，但因为大多采用集中式架构，单台设备的配置也比较高，所以IT设备的规模控制比较好，大多都在万台以内，少数大型企业也没有突破十万这个数量级（其中很大程度也是近年来虚拟化技术不断引入的贡献）。

• 人员配置方面，国内传统企业普遍比较重视，一些大型企业中，上百甚至近千人的专业技术运维队伍配置也是常见的。

  因此，过去较长一段时期内，这些企业的运维工作大多采用人工维护为主，工具支持为辅的模式。当然，这样也能够满足日常工作需求，所以技术运维自动化建设的需求和压力并不不是十分迫切，不成其为主要矛盾；

而对于互联网企业而言，

• 大多采用了分布式架构，通过大规模比较廉价的服务器集群来支持海量的业务压力，加之近年来又广泛使用DOCKER等容器技术，因此不少企业的IT环境规模都比较庞大，十万级，甚至百万级节点规模在大型互联网企业中并不鲜见。

• 人员配置方面，由于互联网企业的业务发展较快，市场竞争激烈，在较短时间内配备一定数量的专业化运维队伍并非易事，加之面对如此庞大的运维规模，自动化运维自然就成了必然选择。

不过，近几年我们也看到，传统企业和互联网企业在IT架构方面已经开始逐步走向融合。不少传统IT企业也开始尝试引入分布式技术架构和一些较为成熟的开源产品，走上了集中式架构与分布式架构相互融合，相互补充的道路。沿着这个道路走下去，必然会导致IT运维的规模快速扩张，IT运维的复杂度也将不断增加。最后，技术运维自动化自然也就会成为大家共同的追求。实际上，我们已经看到各传统企业正在纷纷加大技术运维自动化的建设方面的投入（包括智能化运维方面的尝试），当然，这还有一个发展过程。

这两年，Google SRE运维经验在国内同行中引起了较大反响，其核心的一条理念就是：SRE团队的运维工作限制在50%以内，剩余时间应该花在研发项目上。我想这也代表着专业运维未来的一种发展趋势（旁白：笔者在5年前也开始预感到运维开发是大势所趋，因此启动了第一个运维自动化工具自主研发项目，几年下来逐步培养了一支运维开发队伍，但这个规模还是很小，离50%这个比例相去甚远）。未来企业IT运维能力的竞争，运维开发能力必将成为越来重要的因素。

（四）小结

综上所述，我们在这里把运维聚焦于技术运维工作，并不是要“开历史的倒车”，而是呼吁大家更加重视数据中心技术运维工作的新变化和新挑战，务实地面对技术运维自动化的迫切需求，扎扎实实地打牢这个基础，以便更好地实现IT服务管理和价值创造。对于安全生产而言，产品质量是根本，生产运维亦是关键，这正如一块硬币的两面。毕竟，在业务系统整个生命周期中，在开发测试运行的完整链条中，生产运行这个环节的周期最长，对客户服务也有直接影响。我们不能让这个环节成为短板。

三、运维业务模型

（一） 好的运维业务模型要求

如果把运维自动化软件看作是业务系统，其架构设计也可遵循“业务架构→应用架构→技术架构→数据架构”的设计方法论。因此，我主张在研究运维自动化技术方案之前，应该先对运维业务有个清晰的描述，最好能抽象出业务模型，以确保实现的运维自动化软件最大程度匹配业务模型。当然，这里的运维业务仍然是上文讨论的技术运维范畴。

在我看来，一个比较好的运维业务模型应该能满足如下六项要求：

• 能够完整地描述数据中心技术运维工作中的业务对象、业务活动、业务流程和业务角色。

• 能够适用于系统、网络、应用、安全等多个专业（即每个专业的运维都是这些内容）；能够适用于传统数据中心和未来云计算数据中心的环境。

• 独立于运维生产模式，即无论手工方式，还是自动化方式，或者智能化方式，都能适用。业务本身和做业务的方式要能“解耦”。

• 独立于运维自动化工具和技术体系，即无论是外购、自研，还是引入开源解决方案，这个模型都要有较好的适用性。

• 独立于数据中心的组织架构。因为不同企业的数据中心组织架构往往不同，即便是同一企业的数据中心组织架构，在不同的阶段也可能发生变化。

• 能够有效支持运维自动化软件应用架构、技术架构的设计和开发实现；能够有效地支持运维功能的组织，以形成结构层次清晰的的服务体系（或者说业务功能树的构建）。

（二）OASR运维业务模型

如前文所述，在ITIL理论V3版本中，技术运维相关内容主要集中在服务运营这部分。但我发现ITIL理论更侧重于大运营流程建设，对于更具体技术层面的运维工作，虽时有提及，但也是放在大流程中进行统一描述，并未有给出体系化总结。

此前，我曾看到国内一些专家提出了“监管控”一体化建设解决方案，抽象度较高，也比较简洁。但这里“管”的维度，其内涵界定弹性较大，完全可拓展到IT服务管理的范畴。也就是说，这个模型差不多可以涵盖数据中心的全部工作，与我们这里讨论的运维范畴并不十分匹配（当然，这里也不能否定这个模型的合理性，关键要对每个维度的内容进行具体界定）。

下面，我也给出一个自己总结归纳的OASR运维业务参考模型，具体如图2所示。

图2 运维业务模型

对上述模型的说明如下：

• 运维对象。运维对象主要包括：

• 物理设施（Facilities），即机房、空调、电源等；

• IT基础架构（Infrastructure），即硬件（设备）、软件、网络（线路）

• 应用（Applications）。“应用”这个对象的含义，在这里有狭义和广义之分：狭义的应用，是指应用程序软件（无论自研还是外购），它与操作系统、数据库、中间件等系统软件相对应；广义的应用，是指提供相关业务功能的应用系统，物理上是一组硬件、系统软件、应用软件和数据的集合。一个应用系统往往由多个应用节点组成。

• 运维活动

因为前面我们已经将运维界定为专业技术维护工作，所以这里的运维活动主要是指各专业技术人员基于各类运维对象开展的技术维护操作，进一步归纳为4类：

• 部署（Deploy），其内涵界定为针对各运维对象的安装配置、升级（包括打补丁）以及删除操作。部署活动的结果是产生（或删除）运维对象，也是运维对象运维生命周期的起点或终点；

• 监控（Monitor），其内涵界定为依据一定的规则和逻辑，对各类运维对象的状态、性能、规则符合性等进行跟踪、比较和判断。监控活动的结果是产生报警事件（Alert Event）或实时视图（Dashboard Report）；

• 操作（Operate），其内涵界定为针对各类运维对象的日常技术操作，包括命令执行、周期性任务执行（比如定期巡检、批量操作等）、技术变更实施、备份与恢复、高可用（或灾备）切换与回切等。技术操作活动的结果是改变或恢复运维对象的某种状态、属性或模式。

• 分析（Analyze），其内涵界定为对各类运维对象的状态、性能、过程、变化、数据等进行分析，也包括依据一定规则实施问题诊断。分析活动的结果是生产分析报告、趋势预测或决策建议等。

• 运维场景

运维场景是基于各类运