精彩观点早知道

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

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

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

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

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

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

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

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

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

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

一、前言 二、运维定义        （一）运维概念探讨        （二）聚焦小运维        （三）传统企业 vs 互联网企业        （四）小结 三、运维业务模型        （一）好的运维业务模型六项要求 （二）OASR运维业务参考模型 四、运维自动化功能层次 五、运维自动化建设组织模式 六、几个关系的讨论 七、小结

一、前言

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

·         运维场景

运维场景是基于各类运维对象DMOA四类活动的特定组合，进一步还可能与其它流程系统进行联动，以实现特定运维目标的任务。我们可以给出运维场景的一些具体例子。比如，

§  某个运维对象产生监控告警之后，系统可根据预先确定的规则执行某个应急操作（场景1=监控+应急操作）；

§  有些情况下，还需要进一步自动创建一个事件单（场景2=监控+应急操作+创建事件单，这里与服务管理流程进行了联动）；

§  如果满足预先定义的一定条件，可能还要求同时向一定范围的人员发送短信通知（场景3=监控+应急操作+创建事件单+短信通知，这里进一步与办公自动化流程进行了联动）。

对于运维工作而言，场景的特定性和灵活性是很普遍的。比如技术变更，每次实施的目的和内容往往不尽相同，我们可称之为一个特定的“运维场景”。业界很多同行也提出了场景化运维的概念，我想大家的认识是一致的。

这里再补充说明运维场景和运维活动的关系：

§  运维活动主要是指遵从技术规律的客观活动，比如安装一套操作系统，具体步骤和实现方法是由操作系统产品的技术特性确定，对于不同企业而言，都是一致的；

§  运维场景一般包含运维活动又不限于运维活动，往往需要与管理活动等进行联动和融合，后者与具体的管理环境和运维目标（需求）密切相关，不同企业（或需求）差异可能较大，甚至同一企业的不同时期也可能发生一些变化。因此，我们可以说，运维活动是运维场景的基础，但并不完全等于运维场景。

·         运维角色

数据中心的岗位主要可分为三类：专业技术岗位、生产管理岗位和服务支持岗位。虽然不同企业具体部门和岗位设置有所差异，但上述三类性质的岗位应该是包含的。

在这里的运维业务模型中，运维角色主要对应于专业技术岗位。对于专业技术岗位的运维角色划分，建议基于不同的运维对象和运维活动进行组合，从而确定不同的角色。运维对象和运维活动的粒度可适当灵活，以满足不同精细化、专业化分工的管理要求。进一步，我们就可以将运维角色和人员岗位对应起来（即进行授权）。实际工作中，有些企业专业技术岗位划分和分工比较精细，而有些企业可能综合一些，甚至要求“全栈工程师”。此外，数据中心往往有技术值班的安排，如果某个人员承担技术值班的工作，就可能需要进行“临时动态”授权，赋予其一些特定的运维角色。采用这样的运维角色定义方法和授权方式，应该可比较好地适应各类情况。

·         运维流程

流程（process）一般是指一系列步骤（或子流程）的有序组合。因此，无论是前面提到的运维活动和运维场景，大多数情况下在技术层面都会表现为一个流程（当然也有部分场景只需要执行某个命令或某个脚本，这就谈不上一个流程）。因此，在运维自动化软件架构体系中，流程引擎是不可或缺的一个组件。

毋庸讳言，本文提出的运维业务模型，其科学性和严谨性肯定有值得商榷之处。但总体看来，它基本能够满足前面提出的六项要求。在运维自动化建设的工程实践中，这个模型可能提供如下一些帮助：

·         无论是外购产品、自研工具或者开源方案，如何确保运维自动化技术体系的相对完整？参考上述模型，我们可以从OASR四个维度进行梳理，看看对象、活动、场景是否覆盖？有无遗漏？是否为各类角色都提供了对应的自动化服务功能?

·         如果是多个专业、各部门分头建设、多个产品组合推进，如何尽量确保“业务”一致性？如果参照上述模型，大家在运维自动化功能层次、维度、粒度的划分方面就拥有“共同语言”，能分亦能合，这样才便于进一步组合，满足企业级灵活多变的跨专业运维场景。

·         具体到运维自动化软件体系的建设，上述模型也有助于需求的分类组织和服务功能的有序扩展，确保建设过程中，技术体系和功能架构相对稳定，避免不断地“从头再来”。

四、运维自动化功能层次

这部分要讨论的话题，不知道冠以功能层次的标题是否恰当。但涉及的具体内容，的确是需要我们在运维自动化建设工作中加以研究和区分的。比如，我们经常听到面向应用的监控、面向业务的监控这样的概念，那么它们具体的含义是什么？有什么联系和区别？针对这个问题，这里我提出一个三个层面的运维自动功能建设思路，供大家参考。

这三个层面为：面向资源的运维自动化功能、面向应用的运维自动化功能和面向业务的运维自动化功能。三个层次既相对独立，又有一定的关联关系。

（1）面向资源的运维自动化功能（ROA，Resource Oriented Automation）。

这里的资源是指数据中心各类物理设施和软硬件资源。面向资源的运维自动化就是针对每类资源，实现DMOA各项自动化功能，并组合实现各类运维自动化场景，主要目标是解放各专业技术人员的手工劳动。这个层的运维自动化建设比较容易推动建设，往往也是企业运维自动化最先建设的部分。面向资源的运维自动化功能建设的主要挑战在于各专业是否均衡有序推进，要关注各专业的短板。

（2）面向应用的运维自动化功能(AOA，Application Oriented Automation）。

这里的应用主要是指各应用系统，其运维自动化功能建设主要是两个方向：

·         以应用为单位，归集整合该应用下各类资源运维自动化功能。

【例】某个应用某天需要实现几台应用服务器的自动化扩容，如果要端到端实现整个场景的自动化，大致需要把如下几类资源部署自动化功能的整合：服务器自动扩容（比如自动分配虚拟机）、应用程序（或镜像）自动化部署与配置、分配IP地址和加入负载均衡的自动化 。

·         基于该应用各资源的关联关系，进一步构建以应用为单位的综合性运维自动化功能。

【例】对于确定的某个应用，其所属的各类节点（如WEB服务器、应用服务器、数据库服务器）之间的访问关系也是确定的，在这个基础上，就可以新增出实现该应用各节点访问关系是否正常这个综合性监控指标。

面向应用的运维自动化功能建设的主要挑战在于各资源专业团队与应用团队是否能进行有效配合，同时也要求对应用逻辑有比较深入的了解，往往需要应用开发团队的支持。此外，如果企业中应用系统数量较多，而各应用往往差异较大（通常不如资源层面运维自动化建设的标准化程度），因此工作量和组织难度也比较大。

（3）面向业务的运维自动化功能（BOA，Business Oriented Automation）。

这里的业务是指为向企业客户提供的业务服务。IT最终的目的还是为业务服务。因此，如果能够将运维自动化功能和业务服务关联起来，就能更好地体现IT服务的价值，这也正是大家努力追求的目标。面向业务的运维自动化功能建设得好，不仅可以为数据中心提供服务，也可以为业务部门提供服务。

由于大多数业务功能都是需要跨越多个应用系统来实现的。比如在银行的柜面取款，整个交易数据流将跨越柜面系统、前置系统和业务处理系统等多个应用系统，因此，要实现面向业务的运维自动化功能（比如交易响应时间的监控），就需要在资源监控、应用监控的基础上进一步归集、整合和构建，并把运维对象需进一步关联到业务对象，即具体的业务产品、业务组件和业务交易。

面向业务的运维自动化功能建设的工程难度比较高，其最大的挑战在于对业务流程、业务对象、业务交易进行系统化梳理并将其与IT运维对象建立起映射和关联。一般都需要跨应用的业务架构师参与，通常也要求应用开发团队配合进行应用改造，仅仅以数据中心运维团队来推进实现的难度很大。在实践中，一个常见的误区是以某个应用系统代替业务系统，以面向应用的运维自动化功能代替面向业务运维自动化功能。

下面的图3给出了资源、应用和业务三者之间的关系示意。对于企业运维自动化体系建设而言，这三个层面的功能可以分头推进，但最好还是能统筹组织，特别是面向业务的运维自动化功能建设，往往需要从更高层面予以组织推动。一些企业组建了相对独立的专业化部门，也是一种不错的选择。

图3 资源、应用及业务的关系

五、运维自动化建设组织模式

运维自动化建设不仅要求具备通用的软件工程能力，还需要熟练掌握各专业对象技术特性的专业技术人员参加。从软件工程角度来看，运维自动化软件的需求提出者、开发实现者以及使用者都是IT人员。这种情况，是一件好事，也不一定是好事，因为大家都“懂技术”，在一定程度上都可以动手，有时反而不一定能很好形成共识，形成合力。因此，组织模式对于运维自动化建设来说也是一个重要考虑因素。根据自己的观察与总结，企业运维自动化建设的组织模式，大致有如下四种情形：

·         模式一：分散模式

各专业，各部门分头建设，无统一规划与设计，百花齐放。

§  这种模式的优势是能充分发挥各方积极性和创造性，在较短时间内便能产生一定生产力。

§  不足是各专业各部门建设维度不同，难免出现重复建设；各专业资源投入比较分散，力量有限，往往难以整合形成企业级生产力，更多的是产生一些小型工具。此外，多样化的工具部署到生产环境，不仅有较大维护成本，也可能给生产稳定运行带来风险。

·         模式二：集中模式

由某一团队牵头集中规划和推进建设，其他团队配合并负责提出需求。

§  这种模式的优势是有一定统一规划和设计，有一定规模的专业化队伍，因此可以推出企业级运维自动化系统，实现比较完整的功能。

§  缺点是运维自动化建设的积极性更多在于牵头团队，其它团队是被动配合，很可能导致瓶颈，或引起其他团队的配合不力，甚至不满或抱怨。另一方面，企业级运维自动化需求整合和规划也面临挑战，不少个性化需求往往难以得到满足，用户满意度可能受到影响（我们都了解，对于运维工作而言，多样性和个性化是其重要的特征）。

·         模式三：平台模式

由某一团队牵头规划设计并负责基础技术平台的建设，具体的运维功能可以由各专业，各部门自行开发维护和发布，形成1十N的组织模式。开源产品Puppet就是采用这样的模式，其基础功能和核心框架由自己负责，但使用Puppet的各用户必须要进行二次开发才能拥有符合自身运维场景需求的运维自动化功能，并不能做到“开箱即用”。

§  这种模式的优势是能发挥多个积极性，各取所长。在企业内部采用这样的模式，也能较好地兼顾共性和个性，从而推动形成比较完备的企业级能力。

§  面临的挑战在于对技术平台的基础功能和核心框架要求很高，一旦这个基础平台出现风险和问题，对企业全局建设也会带来影响，所谓“一荣俱荣，一损俱损”，因此关键在于能否驾驭这个挑战。另一方面，这种模式也要求企业内部其他团队具备较强的运维开发能力。

·         模式四：自助模式

各专业、各部门、各应用在统一架构、统一平台、统一接口下各自独立开发运维自动化功能，发布之后持续集成，形成有机的企业级运维能力，我们也可把这种模式称作应用自带运维（BYOO），或者看作是DevOps理念的一种实践。

§  这种模式的优势是运维已经成为统一规范和规则下的各专业、各应用自身能力建设的一部分，并不需要数据中心主动去推动，从而形成人人皆运维的局面，运维自动化功能建设会变得更加主动而高效。

§  但这种模式的条件要求也很高，关键的一点就是要有企业级统一的架构规划、技术平台和开发接口，并在企业内部形成广泛共识，同时还需要具有全员运维开发和集成能力。

从另一角度，上述四种模式也可以看成是企业运维自动化能力建设不断走向成熟的四个阶段，最终的目标是实现自助运维。

笔者所在企业，可以说已经经历了前面三个阶段，智能运维平台建设采用的就是第三种模式（或者说第三个阶段），同时这两年也开始在一些应用系统中探索第四种模式。

无论哪种模式，很重要的一点就是需要持续加大运维研发资源的投入，特别是越往后面的阶段推进，对运维开发能力和资源投入的要求越高，这也是运维队伍转型的方向。

六、几个关系的讨论

（1）运维自动化与ITIL服务管理流程的关系。

主要是联动。比如实施生产变更，为了控制风险，我们都需要按一定流程进行审批，有无运维自动化体系，这都是必然要求。

如果有了运维自动化体系，就可以实现两者的联动。比如，变更审批通过之后就可以直接启动变更操作自动化功能，完成之后再将实施结果自动反馈到变更管理流程中，实现流程的关闭。

另一方面，如果具备了运维自动化功能，还有助于简化服务管理流程。还是以变更管理为例，在手工执行变更的情形下，为了控制变更风险，我们往往要求在变更申请单中附上详细的变更实施步骤，有时候就是长达几页的文档，不仅编写工作量大，而且审核的工作量也不小。如果实现了变更自动化操作功能，可能只需要在变更申请单上说明变更自动化功能执行的简单步骤，相关环节可大大简化。

（2）运维自动化与云平台、容器等新技体系的关系。

我想从两个方面来说明：

·         云平台（主要是IaaS平台和PaaS平台）建设目标之一就是实现运维自动化。参照前面的模型，主要是部署自动化功能，其次还包括部分操作自动化（如弹性扩缩）和监控自动化功能。

·         云平台和容器等自身也是数据中心新的运维对象，比如OpenStack、Docker容器等，它们自身组件也涉及运维自动化问题，比如需要实现自动安装配置等功能。

（3）运维自动化技术体系自己的运维自动化问题

大型企业级运维自动化软件的部署规模一般都不小。我们对其可用性、健壮性等也有很高要求，因此也必须考虑其这套体系自身运维自动化功能的实现问题。我们把这个工作称作运维自动化体系的自服务功能建设。

七、小结

以上就企业运维自动化建设谈了一些比较零碎的意见，文中并没有论及具体的技术实现方案。我想大家已经在各自的实践中“八仙过海，各显神通”并通过不同的渠道，有了不少分享与交流，在此也就没有特别展开。此外，配置管理系统建设对于运维自动化建设而言也十分重要，自动化运维和智能化运维的关系也是我们最近都比较关注的话题。此次限于篇幅，就不再展开，留待后续有机会再与大家探讨交流。（侯志荣原创）

精彩观点早知道

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

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

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

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

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

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

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

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

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

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

一、前言 二、运维定义        （一）运维概念探讨        （二）聚焦小运维        （三）传统企业 vs 互联网企业        （四）小结 三、运维业务模型        （一）好的运维业务模型六项要求 （二）OASR运维业务参考模型 四、运维自动化功能层次 五、运维自动化建设组织模式 六、几个关系的讨论 七、小结

一、前言

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

·         运维场景

运维场景是基于各类运维对象DMOA四类活动的特定组合，进一步还可能与其它流程系统进行联动，以实现特定运维目标的任务。我们可以给出运维场景的一些具体例子。比如，

§  某个运维对象产生监控告警之后，系统可根据预先确定的规则执行某个应急操作（场景1=监控+应急操作）；

§  有些情况下，还需要进一步自动创建一个事件单（场景2=监控+应急操作+创建事件单，这里与服务管理流程进行了联动）；

§  如果满足预先定义的一定条件，可能还要求同时向一定范围的人员发送短信通知（场景3=监控+应急操作+创建事件单+短信通知，这里进一步与办公自动化流程进行了联动）。

对于运维工作而言，场景的特定性和灵活性是很普遍的。比如技术变更，每次实施的目的和内容往往不尽相同，我们可称之为一个特定的“运维场景”。业界很多同行也提出了场景化运维的概念，我想大家的认识是一致的。

这里再补充说明运维场景和运维活动的关系：

§  运维活动主要是指遵从技术规律的客观活动，比如安装一套操作系统，具体步骤和实现方法是由操作系统产品的技术特性确定，对于不同企业而言，都是一致的；

§  运维场景一般包含运维活动又不限于运维活动，往往需要与管理活动等进行联动和融合，后者与具体的管理环境和运维目标（需求）密切相关，不同企业（或需求）差异可能较大，甚至同一企业的不同时期也可能发生一些变化。因此，我们可以说，运维活动是运维场景的基础，但并不完全等于运维场景。

·         运维角色

数据中心的岗位主要可分为三类：专业技术岗位、生产管理岗位和服务支持岗位。虽然不同企业具体部门和岗位设置有所差异，但上述三类性质的岗位应该是包含的。

在这里的运维业务模型中，运维角色主要对应于专业技术岗位。对于专业技术岗位的运维角色划分，建议基于不同的运维对象和运维活动进行组合，从而确定不同的角色。运维对象和运维活动的粒度可适当灵活，以满足不同精细化、专业化分工的管理要求。进一步，我们就可以将运维角色和人员岗位对应起来（即进行授权）。实际工作中，有些企业专业技术岗位划分和分工比较精细，而有些企业可能综合一些，甚至要求“全栈工程师”。此外，数据中心往往有技术值班的安排，如果某个人员承担技术值班的工作，就可能需要进行“临时动态”授权，赋予其一些特定的运维角色。采用这样的运维角色定义方法和授权方式，应该可比较好地适应各类情况。

·         运维流程

流程（process）一般是指一系列步骤（或子流程）的有序组合。因此，无论是前面提到的运维活动和运维场景，大多数情况下在技术层面都会表现为一个流程（当然也有部分场景只需要执行某个命令或某个脚本，这就谈不上一个流程）。因此，在运维自动化软件架构体系中，流程引擎是不可或缺的一个组件。

毋庸讳言，本文提出的运维业务模型，其科学性和严谨性肯定有值得商榷之处。但总体看来，它基本能够满足前面提出的六项要求。在运维自动化建设的工程实践中，这个模型可能提供如下一些帮助：

·         无论是外购产品、自研工具或者开源方案，如何确保运维自动化技术体系的相对完整？参考上述模型，我们可以从OASR四个维度进行梳理，看看对象、活动、场景是否覆盖？有无遗漏？是否为各类角色都提供了对应的自动化服务功能?

·         如果是多个专业、各部门分头建设、多个产品组合推进，如何尽量确保“业务”一致性？如果参照上述模型，大家在运维自动化功能层次、维度、粒度的划分方面就拥有“共同语言”，能分亦能合，这样才便于进一步组合，满足企业级灵活多变的跨专业运维场景。

·         具体到运维自动化软件体系的建设，上述模型也有助于需求的分类组织和服务功能的有序扩展，确保建设过程中，技术体系和功能架构相对稳定，避免不断地“从头再来”。

四、运维自动化功能层次

这部分要讨论的话题，不知道冠以功能层次的标题是否恰当。但涉及的具体内容，的确是需要我们在运维自动化建设工作中加以研究和区分的。比如，我们经常听到面向应用的监控、面向业务的监控这样的概念，那么它们具体的含义是什么？有什么联系和区别？针对这个问题，这里我提出一个三个层面的运维自动功能建设思路，供大家参考。

这三个层面为：面向资源的运维自动化功能、面向应用的运维自动化功能和面向业务的运维自动化功能。三个层次既相对独立，又有一定的关联关系。

（1）面向资源的运维自动化功能（ROA，Resource Oriented Automation）。

这里的资源是指数据中心各类物理设施和软硬件资源。面向资源的运维自动化就是针对每类资源，实现DMOA各项自动化功能，并组合实现各类运维自动化场景，主要目标是解放各专业技术人员的手工劳动。这个层的运维自动化建设比较容易推动建设，往往也是企业运维自动化最先建设的部分。面向资源的运维自动化功能建设的主要挑战在于各专业是否均衡有序推进，要关注各专业的短板。

（2）面向应用的运维自动化功能(AOA，Application Oriented Automation）。

这里的应用主要是指各应用系统，其运维自动化功能建设主要是两个方向：

·         以应用为单位，归集整合该应用下各类资源运维自动化功能。

【例】某个应用某天需要实现几台应用服务器的自动化扩容，如果要端到端实现整个场景的自动化，大致需要把如下几类资源部署自动化功能的整合：服务器自动扩容（比如自动分配虚拟机）、应用程序（或镜像）自动化部署与配置、分配IP地址和加入负载均衡的自动化 。

·         基于该应用各资源的关联关系，进一步构建以应用为单位的综合性运维自动化功能。

【例】对于确定的某个应用，其所属的各类节点（如WEB服务器、应用服务器、数据库服务器）之间的访问关系也是确定的，在这个基础上，就可以新增出实现该应用各节点访问关系是否正常这个综合性监控指标。

面向应用的运维自动化功能建设的主要挑战在于各资源专业团队与应用团队是否能进行有效配合，同时也要求对应用逻辑有比较深入的了解，往往需要应用开发团队的支持。此外，如果企业中应用系统数量较多，而各应用往往差异较大（通常不如资源层面运维自动化建设的标准化程度），因此工作量和组织难度也比较大。

（3）面向业务的运维自动化功能（BOA，Business Oriented Automation）。

这里的业务是指为向企业客户提供的业务服务。IT最终的目的还是为业务服务。因此，如果能够将运维自动化功能和业务服务关联起来，就能更好地体现IT服务的价值，这也正是大家努力追求的目标。面向业务的运维自动化功能建设得好，不仅可以为数据中心提供服务，也可以为业务部门提供服务。

由于大多数业务功能都是需要跨越多个应用系统来实现的。比如在银行的柜面取款，整个交易数据流将跨越柜面系统、前置系统和业务处理系统等多个应用系统，因此，要实现面向业务的运维自动化功能（比如交易响应时间的监控），就需要在资源监控、应用监控的基础上进一步归集、整合和构建，并把运维对象需进一步关联到业务对象，即具体的业务产品、业务组件和业务交易。

面向业务的运维自动化功能建设的工程难度比较高，其最大的挑战在于对业务流程、业务对象、业务交易进行系统化梳理并将其与IT运维对象建立起映射和关联。一般都需要跨应用的业务架构师参与，通常也要求应用开发团队配合进行应用改造，仅仅以数据中心运维团队来推进实现的难度很大。在实践中，一个常见的误区是以某个应用系统代替业务系统，以面向应用的运维自动化功能代替面向业务运维自动化功能。

下面的图3给出了资源、应用和业务三者之间的关系示意。对于企业运维自动化体系建设而言，这三个层面的功能可以分头推进，但最好还是能统筹组织，特别是面向业务的运维自动化功能建设，往往需要从更高层面予以组织推动。一些企业组建了相对独立的专业化部门，也是一种不错的选择。

图3 资源、应用及业务的关系

五、运维自动化建设组织模式

运维自动化建设不仅要求具备通用的软件工程能力，还需要熟练掌握各专业对象技术特性的专业技术人员参加。从软件工程角度来看，运维自动化软件的需求提出者、开发实现者以及使用者都是IT人员。这种情况，是一件好事，也不一定是好事，因为大家都“懂技术”，在一定程度上都可以动手，有时反而不一定能很好形成共识，形成合力。因此，组织模式对于运维自动化建设来说也是一个重要考虑因素。根据自己的观察与总结，企业运维自动化建设的组织模式，大致有如下四种情形：

·         模式一：分散模式

各专业，各部门分头建设，无统一规划与设计，百花齐放。

§  这种模式的优势是能充分发挥各方积极性和创造性，在较短时间内便能产生一定生产力。

§  不足是各专业各部门建设维度不同，难免出现重复建设；各专业资源投入比较分散，力量有限，往往难以整合形成企业级生产力，更多的是产生一些小型工具。此外，多样化的工具部署到生产环境，不仅有较大维护成本，也可能给生产稳定运行带来风险。

·         模式二：集中模式

由某一团队牵头集中规划和推进建设，其他团队配合并负责提出需求。

§  这种模式的优势是有一定统一规划和设计，有一定规模的专业化队伍，因此可以推出企业级运维自动化系统，实现比较完整的功能。

§  缺点是运维自动化建设的积极性更多在于牵头团队，其它团队是被动配合，很可能导致瓶颈，或引起其他团队的配合不力，甚至不满或抱怨。另一方面，企业级运维自动化需求整合和规划也面临挑战，不少个性化需求往往难以得到满足，用户满意度可能受到影响（我们都了解，对于运维工作而言，多样性和个性化是其重要的特征）。

·         模式三：平台模式

由某一团队牵头规划设计并负责基础技术平台的建设，具体的运维功能可以由各专业，各部门自行开发维护和发布，形成1十N的组织模式。开源产品Puppet就是采用这样的模式，其基础功能和核心框架由自己负责，但使用Puppet的各用户必须要进行二次开发才能拥有符合自身运维场景需求的运维自动化功能，并不能做到“开箱即用”。

§  这种模式的优势是能发挥多个积极性，各取所长。在企业内部采用这样的模式，也能较好地兼顾共性和个性，从而推动形成比较完备的企业级能力。

§  面临的挑战在于对技术平台的基础功能和核心框架要求很高，一旦这个基础平台出现风险和问题，对企业全局建设也会带来影响，所谓“一荣俱荣，一损俱损”，因此关键在于能否驾驭这个挑战。另一方面，这种模式也要求企业内部其他团队具备较强的运维开发能力。

·         模式四：自助模式

各专业、各部门、各应用在统一架构、统一平台、统一接口下各自独立开发运维自动化功能，发布之后持续集成，形成有机的企业级运维能力，我们也可把这种模式称作应用自带运维（BYOO），或者看作是DevOps理念的一种实践。

§  这种模式的优势是运维已经成为统一规范和规则下的各专业、各应用自身能力建设的一部分，并不需要数据中心主动去推动，从而形成人人皆运维的局面，运维自动化功能建设会变得更加主动而高效。

§  但这种模式的条件要求也很高，关键的一点就是要有企业级统一的架构规划、技术平台和开发接口，并在企业内部形成广泛共识，同时还需要具有全员运维开发和集成能力。

从另一角度，上述四种模式也可以看成是企业运维自动化能力建设不断走向成熟的四个阶段，最终的目标是实现自助运维。

笔者所在企业，可以说已经经历了前面三个阶段，智能运维平台建设采用的就是第三种模式（或者说第三个阶段），同时这两年也开始在一些应用系统中探索第四种模式。

无论哪种模式，很重要的一点就是需要持续加大运维研发资源的投入，特别是越往后面的阶段推进，对运维开发能力和资源投入的要求越高，这也是运维队伍转型的方向。

六、几个关系的讨论

（1）运维自动化与ITIL服务管理流程的关系。

主要是联动。比如实施生产变更，为了控制风险，我们都需要按一定流程进行审批，有无运维自动化体系，这都是必然要求。

如果有了运维自动化体系，就可以实现两者的联动。比如，变更审批通过之后就可以直接启动变更操作自动化功能，完成之后再将实施结果自动反馈到变更管理流程中，实现流程的关闭。

另一方面，如果具备了运维自动化功能，还有助于简化服务管理流程。还是以变更管理为例，在手工执行变更的情形下，为了控制变更风险，我们往往要求在变更申请单中附上详细的变更实施步骤，有时候就是长达几页的文档，不仅编写工作量大，而且审核的工作量也不小。如果实现了变更自动化操作功能，可能只需要在变更申请单上说明变更自动化功能执行的简单步骤，相关环节可大大简化。

（2）运维自动化与云平台、容器等新技体系的关系。

我想从两个方面来说明：

·         云平台（主要是IaaS平台和PaaS平台）建设目标之一就是实现运维自动化。参照前面的模型，主要是部署自动化功能，其次还包括部分操作自动化（如弹性扩缩）和监控自动化功能。

·         云平台和容器等自身也是数据中心新的运维对象，比如OpenStack、Docker容器等，它们自身组件也涉及运维自动化问题，比如需要实现自动安装配置等功能。

（3）运维自动化技术体系自己的运维自动化问题

大型企业级运维自动化软件的部署规模一般都不小。我们对其可用性、健壮性等也有很高要求，因此也必须考虑其这套体系自身运维自动化功能的实现问题。我们把这个工作称作运维自动化体系的自服务功能建设。

七、小结

以上就企业运维自动化建设谈了一些比较零碎的意见，文中并没有论及具体的技术实现方案。我想大家已经在各自的实践中“八仙过海，各显神通”并通过不同的渠道，有了不少分享与交流，在此也就没有特别展开。此外，配置管理系统建设对于运维自动化建设而言也十分重要，自动化运维和智能化运维的关系也是我们最近都比较关注的话题。此次限于篇幅，就不再展开，留待后续有机会再与大家探讨交流。（侯志荣原创）