企业自动化运维体系建设需关注的核心问题.docx

?

?

企业自动化运维体系建设需关注的核心问题

?

?

１、如何建设符合企业实际的自动化变更平台？

就笔者所在企业而言，直接的建设需求有如下方面：

A.同时满足系统自动化运维和应用自动化运维两部分内容；（笔者注：系统运维指操作系统、数据库、中间件等基础环境运维；应用运维指应用系统的部署和发布）

B.同时适应标准化和非标准化两类变更;

C.支持多个操作系统平台，包括LINUX\UNIX\WINDOWS;

D.可由运维专家灵活定制运维流程；

E.变更平台需要具备4A系统的特点，即集中认证（Authentication）管理、集中账号（Account）管理、集中权限（Authorization）管理和集中审计（Audit）管理。

非功能需求有如下方面：

A.高可用。不仅仅是自动化平台本身提供的服务需要高可用，其执行通道，即平台与生产服务器之间的命令通道也必须是高可用；

B.对外提供API或服务总线式的接口，以便更好地与其他运维系统，如CMDB相融合。

最终我们决定借助一些开源的组件，采用自研的方式去建设。可参看笔者文章《自动化运维体系建设关键点分析——以某大型金融企业为例》的第2章。

２、IT流程和自动化变更动作如何结合？

自动化变更并不意味着不需要审批。在DEVOPS成熟度模型里对变更管理人员和变更管理工具，定义了几个不同的成熟度。最高的5级是无人值守、4级远程值守自动变更、3级现场值守自动化变更。

许多企业现有的运维管控流程是是基于ITIL开发的，往往长时间不进行更新。在自动化运维普遍替代传统人工运维的背景下，一些管控流程实际上可以被优化。那么优化的指导原则又是什么呢？笔者认为，可以归纳为一句话：仅让需要审核的步骤被最适合审核的人审核，且不断根据实际优化或在可控范围内勇于试错。

例如，变更具体内容被平台固化了，其内容的审批实际上就应该前置到固化之前，而执行审批就可以将审批注意力集中在实施时间、关联变更上。再比如，一些常规的紧急变更，往往要经过层层审批，而这些审批动作几乎是清一色的“同意”，那么审批就没有存在的必要了，反而会在时间上阻碍变更的执行。自动化平台在数据上可以给审批者提供类似风险分级的参考，以便进行管控流程的优化。

从系统建设层面，流程管理平台实际可以和变更、监控平台将部分功能集成到一起。例如，可以将事务类步骤和运维步骤结合到一个复合流程中予以展现。下图是一个常规告警触发变更自愈的流程界面：

３、自动化运维体系各个要素之间如何进行联动？

1.变更平台、监控平台、CMDB需要能提供API，满足调用和被调用两个要求。

2.CMDB建设需要确保数据的唯一性和真实性，且数据模型需要根据实际而更新。

3.变更平台要能和企业ITSM结合在一起。一同展现。

一个结合了审批流、自动变更、人工变更、监控信息的流程案例：见上面Q2-A中的图片。

４、如何应对企业非标准化情况？

方法1：改造老系统。

方法2：在下文中有提及定义非标准化内容由统一脚本去执行的解决方案。来自《自动化运维体系建设关键点分析——以某大型金融企业为例》：

“B.应对非标准化的节点属性。节点属性可定义可不定义，在平台后端以KEY-VALUE的数据形式存放。设计这个属性的初衷是为了应对非标准化的情形。例如，软件安装路径在不同节点上不一致，就可以定义一个软件安装目录（app_directory）的属性，其值就是该节点上软件的绝对路径，这样就可以通过脚本对同一属性名称的引用，来完成对所有节点中软件安装目录的遍历。当然，如果路径都统一，这些个性化属性就可以不定义，直接存放在统一脚本中。非标准化情况越多，需要定义的属性内容就越多，我们通过这种形式变相地鼓励运维人员去尽量地完成标准化工作。”

如图所示：

-全文完-