自动化运维平台实施前是否需要进行标准化，范围如何？

　　保险行业自动化运维平台实施前是否需要进行标准化，范围如何？

　　金融保险企业自动化运维的需求也是日益强烈，在人员紧缺和缺乏经验的情况下要做好自动化平台的实施还是困难。自动化变更对象，有操作系统、中间件、数据库、应用程序、配置等，如果各类变更对象在安装、配置过程中因历史原因产生了不统一的情况，自动化系统在实施前是否应调整这些不一致的情况？产生的工作和事务成本如何克服？这个问题在我们团队内部也一直困扰着我们，没有答案，想听听各位专家的经验。（问题来自社区会员wh85某大型保险公司系统工程师）

　　@mornsky某银行研发工程师：

　　首先，标准化的自动化运维肯定是最理想的，但标准化存在制定、实施、管理等多环节的困难。因此，一定粒度的较容易实现的规范或标准是一个可行的现实选择。

　　其次，标准化、自动化最基本的实现方式是可脚本或命令操作，从某种意义上可脚本化与自动化可划上等号。自动化实质上的各管控服务器的各类操作命令或脚本的程序化管理控制。因此，我们将对自动化运维加入的标准是要能脚本或命令操作，原始操作不能是交互图形化。如果能脚本或命令操作，很容易通过简单脚本实现各类统一的标准化操作。

　　再次，自动化运维范畴太广，不可能一步到位，只能规范设计一些运维场景一步步实现，也才能更好地推广应用。

　　@顾黄亮苏宁消费金融有限公司技术总监：

　　很理解你的痛苦，针对你的问题简单聊一下我们进行自动化阶段所遇到的问题。

　　标准化对于自动化来说，是一个前置条件，如果没有标准化，自动化环节就会很盲目的新增适应现网系统的模板，而且此项工作会一直延续下去，到最后，自动化也就是失败的自动化，达不到降本增效的效果，产生的数据也无法做到数据的消费。

　　对于标准化的理解有三种情况。1：开发模式的标准化，也就是说尽可能的使用某几种框架，使用maven进行统一管理，使用同一种协议，使用同一种开发模式。2：运维模式的标准化，运维标准化基于运维和其他团队的边界，运维内部的对象的统一和标准的制定，，包括但不限于团队的职责，技术栈的选用，脚本的编写规范，机器、实例、服务、应用等运维对象的属性，聚集分散的运维状态数据。3：IT内部流水线的建立，以交付作为核心输出能力，把研发、测试纳入到交付整体的节点。

　　基于以上标准化，其实自动化已经完成了70%，剩下的30%就是采用每个模块所需要的工具，搭建积木的方式来构建运维核心自动化平台。

　　@he7yongCanway研发工程师：

　　我的观点：自动化和标准化是需要同时考虑的，他们像是DNA的双螺旋，标准化，自动化都是为了实现IT业务的目标。

　　1.先做标准化的失败案例，标准化项目实施完成，交付了一堆的文档，这些文档被束之高阁，过了1年这些IT对象又变化了，标准化的文档没有什么卵用了；

　　2.仅仅做自动化，过程中不考虑标准化，自动化的效果不好，有可能会带来系统的故障。

　　因此，我的建议，标准化和自动化应该是需要同时考虑的，标准化的对象需要通过工具实现自动化交付，标准化的规范流程又可以保障自动化的效果。

　　聚焦运维，标准化执行的过程中我的建议如下：

　　1.标准化要分为管理的标准化和技术的标准化；如数据库的命名，生命周期管理等都属于管理的标准化；

　　2.标准化不仅仅涵盖实际的运维对象，还包括架构、运维事件、运维服务等这些对象的标准化

　　3.标准化的文档需要分级，操作规范和要和管理规范混合在一起。

　　@yjytianti中原银行系统运维工程师：

　　个人认为在自动化运维平台实施前，需要有标准化，但不一定是立刻全部实现标准化，可以逐步推进，和自动化同时推进，不断迭代。

　　至于范围，可以从以下2方面入手：

　　1、工具标准化

　　开发框架可以自研或者引入第三方，统一开发框架，如果和开发壁垒较大，可忽略。

　　配置管理使用统一的配置管理工具做代码管理，主干开发或分支开发也得定个统一标准。

　　同时需求管理Jira、持续集成Jenkins、私有仓库Artifactory等这些各选择1-2个主流标准工具，工具太多势必对运维管理造成成本负担。

　　2、流程标准化

　　资源申请制定固定的标准流程，如何申请，申请需要填写哪些信息，申请后的机器预装了哪些基础软件等。

　　变更申请主机变更，数据库变更，存储变更等需制定哪些内容是允许变更的，允许变更的是否可通过UI界面自助完成即可。哪些是坚决不允许变更的。

　　资源入库运维资源入库到cmdb标准化，如环境名称、系统名称、服务名称这些资源项在什么地方由谁定义，比如：同一个系统有的人叫电子银行，有的叫电子渠道，有的叫渠道整合。。这是不行的，必须统一掉，便于信息在开发、测试、运维不同人群间传递。同时明确在什么地方定义，以什么系统做载体对这些信息在不同部门之间透传。

　　@zjwy82某银行系统架构师：

　　传统企业在自动化运维实施过程中都会面临一些历史包袱问题，个人建议标准化必须做，在自动化实施前应设立一些原则，如标准化、参数化、脚本化等，并制定一些规范，以指导实施。具体在实施过程中可以遵循系统新建、重大改造时必须做标准化，历史系统可适当保持现状。

　　针对配置差异、不同类型，采取对象分组的方式，将自动化脚本和组对象做柔性关联，通过参数化来解耦自动化脚本与变更对象的绑定关系，实现复用。