近几年来，随着云计算、大数据、人工智能技术的高速发展，DevOps、AIOps等新文化、新理念的冲击，几乎所有企业的信息技术部门都在谋求变革，不仅仅是为了跟上技术潮流，更是为了能适应随着业务而一起发展的IT系统的运维复杂度和体量，有的走的比较靠前的企业信息部门甚至完成了从支撑业务到引领业务、技术输出的转型。在这场席卷全球企业的变革中，自动化运维体系建设就是非常重要且基础的一部分内容。

针对自动化运维平台，已经有许多技术专家撰文专门论述，其中大部分内容偏重于平台建设本身。而自动化运维体系则不仅仅包括自动化运维平台，还包括与之结合紧密的企业运维管理制度、运维专家的作用、运维流程的演进等内容，仅仅完成平台建设是不足以达到自动化运维的目标的。

本期活动针对企业自动化运维体系建设进行了讨论，涉及了变更平台、监控平台、CMDB、ITSM、管理制度、企业文化和未来发展方向等方面。主要讨论的问题包括以下几个方面：

一、企业自动化建设体系的目标和方向

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

嘉宾回复：
就笔者所在企业而言，直接的建设需求有如下方面：
A.同时满足系统自动化运维和应用自动化运维两部分内容；（笔者注：系统运维指操作系统、数据库、中间件等基础环境运维；应用运维指应用系统的部署和发布）
B.同时适应标准化和非标准化两类变更;
C.支持多个操作系统平台，包括LINUX\UNIX\WINDOWS;
D.可由运维专家灵活定制运维流程；
E.变更平台需要具备4A系统的特点，即集中认证（Authentication）管理、集中账号（Account）管理、集中权限（Authorization）管理和集中审计（Audit）管理。

非功能需求有如下方面：
A.高可用。不仅仅是自动化平台本身提供的服务需要高可用，其执行通道，即平台与生产服务器之间的命令通道也必须是高可用；
B.对外提供API或服务总线式的接口，以便更好地与其他运维系统，如CMDB相融合。

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

在自动化体系建设过程中，需要协调好哪些关系？

嘉宾回复：
1、和决策层的关系。周期性向决策层汇报进展，最大程度获取理解和支持。
2、和用户的关系。关注用户反馈和功能体验，吸纳用户有益建议的同时适当予以引导。
3、和关联项目团队的关系。接口类功能需要与关联项目组达成一致意见。
4、和企业研发部门的关系。自动化部署往往意味着需要一定程度的标准化，标准化从研发开始会相对更容易推广和实施，并能保障生产和开发环境的一致性。

自动化运维体系建设的原则是什么？

嘉宾回复：
建设目标确定以后，不忘初心。
还有，安全的红线不能碰。

自动化运维体系建设的目标和意义是什么？

嘉宾回复：
一般一个信息系统项目的发起或产生有两种方式：自上而下由管理层发起，自下而上由员工发起。而许多企业自动化运维平台的发起往往是两者均有，这种奇特的现象说明了企业管理层和运维员工同时意识到其必要性，前者往往是为了节约成本，而后者主要为了提高工作效率。
一些业内人士认为，自动化运维是“双刃剑”，给运维工作带来高效率的同时也将原有的生产风险放大了。诚然，如仅仅是将原有运维动作批量化执行，不附加任何系统、管理和流程上的约束，确实有此可能，但一个精心设计的、符合企业实际的自动化运维平台是可以同时提高运维的安全程度的。
综上所述，节约成本、高效、安全，这三者组成了自动化运维平台的建设目标。不同企业侧重点有所不同，但基本都会在这三个目标范围内。

每个企业的情况不尽相同。俗话说得好，磨刀不误砍柴工。在确定自动化体系建设目标的时候要根据企业痛点、组织构成、技术栈等情况进行综合考虑。
可以列一些问题清单，自问自答，例如：
1、资源拥有者(领导层)态度如何，是否可以被改变？
2、能否组建专有团队？如可以，参与人员会是哪些？是否需要额外培养？
3、目标有高低，本企业近、中、长期目标是否可以确定？
4、按现有情况 ，完成各类目标所需各类资源（时间、人员、预算）大概需要多少？
5、各类目标的可预见的收益如何？
6、用户（运维人员）对体系的建设期望值如何？是否会涉及习惯的改变，接受程度如何？
……

回答好本企业的诸如此类问题以后，可召集干系人一同确定建设目标。

二、自动化体系的设计

自动化运维平台设计时，需要考虑哪些因素？

嘉宾回复：
1、执行和监控代理的兼容。代理需要同时兼容这些不同的操作系统版本，但是注意在顶层使用时不要暴露技术差异性给用户。
2、脚本执行的校验，不同操作系统脚本执行器语法不同，设计时可以考虑在系统前端进行一些校验。例如，在linux平台执行的语法检查规则可以预定义好，在执行前或定义脚本时予以校验。

抛开对多样化支持而言，自动化运维平台还需要考虑安全、可扩展性、服务化等方面。

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

嘉宾回复：
1、变更平台、监控平台、CMDB需要能提供API，满足调用和被调用两个要求。
2、CMDB建设需要确保数据的唯一性和真实性，且数据模型需要根据实际而更新。
3、变更平台要能和企业ITSM结合在一起。一同展现。
一个结合了审批流、自动变更、人工变更、监控信息的流程案例：

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

嘉宾回复：
方法1：改造老系统。
方法2：在我的文章中有提及定义非标准化内容由统一脚本去执行的解决方案。
以下内容节选自《自动化运维体系建设关键点分析——以某大型金融企业为例》：
“B.应对非标准化的节点属性。节点属性可定义可不定义，在平台后端以KEY-VALUE的数据形式存放。设计这个属性的初衷是为了应对非标准化的情形。例如，软件安装路径在不同节点上不一致，就可以定义一个软件安装目录（app_directory）的属性，其值就是该节点上软件的绝对路径，这样就可以通过脚本对同一属性名称的引用，来完成对所有节点中软件安装目录的遍历。当然，如果路径都统一，这些个性化属性就可以不定义，直接存放在统一脚本中。非标准化情况越多，需要定义的属性内容就越多，我们通过这种形式变相地鼓励运维人员去尽量地完成标准化工作。”
如图所示

会员回复：
老系统老运维方法；
新系统标准化方式运维；
把老系统改造成标准化成本太高了。

底层监控与网络和应用监控用的不同厂家产品，在建设自动化运维平台时，不同厂家的产品如何进行合并对接？

嘉宾回复：
题主好：这个问题我们也遇到了，说实话，目前还没有特别完备的解决方案。
我们公司最最早有基础环境监控（网络、主机、机房等）、之后再建设了应用监控平台（类似ELK的技术栈）、最后才建设了自动化运维（变更）平台。这些平台一开始互相之间都独立且不相关。
现在我们正在做一些尝试，进行合并和整合：
1、监控类信息，根据CMDB信息，以业务应用为单位进行前端的整合。
2、建立健全信息链的监控（数据流、逻辑流）
3、监控信息标准化，并向自动化运维平台提供接口，供分析或变更使用。

自动化运维平台设计时，应如何考虑平台对未来可能到来的服务器等大规模扩展的支撑？

嘉宾回复：
1、平台考虑进行一些微服务化的设计，功能分离成相对独立的服务，部署在容器内，实现动态扩容就很容易了。
2、对纳管服务器的代理执行效率，一般情况下需要达到并发几千以上。这种并发效率对于一般企业使用足够了。

自动化运维平台建设时，需要开发agent来管理吗？

嘉宾回复：
ssh有先天缺陷：安全性低、效率低。但是其使用和部署方式相对简单。适合小规模应用。
开源agent如saltstack等安全性、效率都相对较高。缺点之一是系统功能需要在其接口上进行开发。
开发agent成本高，好处是可以自主掌控，灵活定制。

我们公司经历了 SSH-开源agent-自研agent的发展路线。

会员回复：
agent效率很高, ssh 建立时间太慢而且消耗资源太多。

自动运维平台的交互界面，如何设计，可以使运维人员更方便的使用和管理？

嘉宾回复：
这个问题实际上每个产品都会遇到。管理界面和提升用户体验是每个产品经理的必修课。建议研读《人人都是产品经理》。

三、自动化体系的安全

自动化备份进行设计时，如何保证安全性？

嘉宾回复：
备份本质上也是变更的一种。我们企业在设计自动化变更系统时，提供了一种非常灵活的、可拖拽式的变更流程定义界面，流程规则符合BPMN2.0规范。每个流程步骤，可以在任意权限内服务器上执行任意脚本，调用任意系统的API。理论上可以实现任意组合的运维动作。

有这样一个系统，关键是将企业各方面的原有运维流程进行自动化的固化。

比如备份流程，备份结束后，可以设计一些校验环节，采用测试环境进行恢复测试；也可以单独定义一些备份演练恢复流程。

自动化安装部署过程中，在交付之前，需要进行哪些安全和风险预防上的设置？

嘉宾回复：
安装部署软件还是安装部署应用？
部署应用的话，各个企业都有自己的上线流程，继续遵循上线流程的要求就行了，自动化系统只是将其过程自动化实现而已。一般的上线流程会包括对测试和验证环节的检查、监控和备份策略的启用等。
另外，采用自动化平台的化，更便于进行灰度发布、蓝绿部署等安全上线方式。

四、自动化体系的推广、运用和传承

如何组建和培养自动化团队？

嘉宾回复：
自动化运维体系建设一般由企业的运营中心（或数据中心）承建，而这类部门往往没有研发背景。所以，自动化团队的第一要务是要组建开发团队。团队人员可以通过组织内招募、招聘、培养等手段进行补充。如是企业内参与开发的运维人员，要适当降低或免除其日常运维工作，并修改对其的考核方式。
自动化团队还应包括脚本专家团队，这一点通常容易被忽视。自动化平台是工具，核心还是运行其上的各类运维脚本。自动化这个双刃剑舞得好不好基本全部要靠这个团队。
最后一个是组织推广、完善体系的项目团队，这个团队人员可以由上述两类人员兼任。

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

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

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

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

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

会员回复：
金融行业自动化变更是不可能被获准的,
it流程在做变更前要通知相关人员, 然后由人员启动变更操作,
安全基线不能碰。

自动化备份的设计，应重点考虑哪些因素？

嘉宾回复：
题主好：连同您提出的另一个问题《自动化备份进行设计时，如何保证安全性？》在此一并回答。

备份本质上也是变更的一种。我们企业在设计自动化变更系统时，提供了一种非常灵活的、可拖拽式的变更流程定义界面，流程规则符合BPMN2.0规范。每个流程步骤，可以在任意权限内服务器上执行任意脚本，调用任意系统的API。理论上可以实现任意组合的运维动作。

有这样一个系统，关键是将企业各方面的原有运维流程进行自动化的固化。

比如备份流程，备份结束后，可以设计一些校验环节，采用测试环境进行恢复测试；也可以单独定义一些备份演练恢复流程。

在自动化建设过程中可能遇到的困难和阻力有哪些？如何解决？

嘉宾回复：
1、运维习惯和运维流程的改变。
自动化建设就像造车，造好了车子，还需要教会大家去开车、去遵守交规。这没有捷径可走，只能慢慢培养、潜移默化地去影响。
2、团队开发能力的欠缺。
组织内一般由运维团队承建，往往缺乏开发经验。可通过重点培养对开发感兴趣、有能力的人员先参与，再以点带面的方式进行扩充和培养。
3、组织内部对于安全的要求，以及对自动化系统错误的认识，认为自动化建设会带来安全的风险。
建设过程中需要特别关注安全有关的功能建设并进行宣导，例如命令黑名单功能等之前没有的、系统建设能额外提供的功能。

自动化运维建设中，脚本标准化如何建立？

嘉宾回复：
确定专家-组建虚拟团队-初步规范-完善现有脚本-完善规范
文本内容的版本管理工具推荐用git，可以在企业内部搭建私服。

会员回复：
每个工程师使用的脚本语言和编写风格都不同，在实际生产活动中，很难将其标准化(除非该团队是以编码为主要工作内容)，随之而来的问题就是：脚本在设计、开发、测试、调优、上线等一系列的生命周期过程中，均为一个人搞定，无法避免的存在问题遗漏等风险，而其他人也没办法、甚至是不愿意去很好的阅读或者测试验证，为生产环境带来隐患。解决该问题，就需要将以上工作提升高度，不是某个工程师犯懒，想写一套自动化脚本，而是从架构层面，为了降低人为参与导致的风险、减少工作量，团队需要一个这样那样的自动化程序，从需求挖掘开始就要多个人参与，这样的工作分配会将个人因素导致的脚本不健全风险降低。即：写脚本不是一个人的战斗！

关于运维脚本如何在运维人员之间传承和再利用的问题？

嘉宾回复：
根据企业的规模不同，解决方法也不尽相同。如果企业不是很大，脚本量也不多，建议可以通过管理手段进行约束。如果规模较大，建议选择通过如下手段进行传承和再利用：

1、将脚本编写拟定规范，根据企业实际不断进行完善。例如命名规范、语法规范、适用范围、适用时间等。

2、设立脚本专家团队，对脚本的生产准入进行把关或者直接编写规范和脚本。例如，脚本是否符合规范，是否经过验证测试，规范是否需要进行更新完善等。

3、通过版本化工具管理脚本。不要再将脚本存在自己的个人电脑中，而是将其存在于版本化管理工具中，例如GIT。谁、什么时间、因为什么原因修改了脚本的什么地方，都需要有记录。

4、尽量原子化设计脚本，让脚本功能尽量单一，提高可阅读性和可维护性。

5、注释。企业文化和个人习惯直接其实是有关联的，作为管理人员可以有意无意地培养。

6、通过自动化平台将脚本封装成系统功能，例如某个软件的安装。

大家可以根据自己企业的实际情况逐步解决这个问题。

会员回复一：
这个问题很常见，不要说脚本在运维人员间传承，就连自己写的脚本，过6个月，我宁愿再写一个。。。
如何解决，按照软件开发流程，标准化。。。这个不容易，运维工程师有多少是有过开发经验的，那具体如何解决，第一：注释，第二：注释，第三，注释。短脚本不讨论，长脚本编写时按模块，每个模块写清楚作用，实现，接收传递的参数等重要信息，就算读不懂，大不了自己写一个，能实现相同功能就行了，其中模块还能单独拿出来使用。反正我是只读注释，包括自己写的，因为感觉看代码不如再写一遍。

会员回复二：
制定规范，写好注释，写好文档，最好有个流程图。然后就够了。

会员回复三：
按照开发管理过程规范来要求运维开发，包括脚本。

会员回复四：
在编写脚本的时候就根据既定的规范写好注释，完成脚本后提交脚本的使用手册。