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

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

参与46

6同行回答

mornskymornsky  研发工程师 , 某银行
首先,标准化的自动化运维肯定是最理想的,但标准化存在制定、实施、管理等多环节的困难。因此,一定粒度的较容易实现的规范或标准是一个可行的现实选择。其次,标准化、自动化最基本的实现方式是可脚本或命令操作,从某种意义上可脚本化与自动化可划上等号。自动化实质上的各管控...显示全部

首先,标准化的自动化运维肯定是最理想的,但标准化存在制定、实施、管理等多环节的困难。因此,一定粒度的较容易实现的规范或标准是一个可行的现实选择。
其次,标准化、自动化最基本的实现方式是可脚本或命令操作,从某种意义上可脚本化与自动化可划上等号。自动化实质上的各管控服务器的各类操作命令或脚本的程序化管理控制。因此,我们将对自动化运维加入的标准是要能脚本或命令操作,原始操作不能是交互图形化。如果能脚本或命令操作,很容易通过简单脚本实现各类统一的标准化操作。
再次,自动化运维范畴太广,不可能一步到位,只能规范设计一些运维场景一步步实现,也才能更好地推广应用。

收起
银行 · 2019-04-02
浏览3201
  • wh85  wh85
    从简到难,循序渐进。通用脚本解决标准化准入问题,改造解决历史问题。学习了
    2019-04-02
顾黄亮顾黄亮  技术总监 , 畅销书作者
很理解你的痛苦,针对你的问题简单聊一下我们进行自动化阶段所遇到的问题。标准化对于自动化来说,是一个前置条件,如果没有标准化,自动化环节就会很盲目的新增适应现网系统的模板,而且此项工作会一直延续下去,到最后,自动化也就是失败的自动化,达不到降本增效的效果,产生的数据也无...显示全部

很理解你的痛苦,针对你的问题简单聊一下我们进行自动化阶段所遇到的问题。
标准化对于自动化来说,是一个前置条件,如果没有标准化,自动化环节就会很盲目的新增适应现网系统的模板,而且此项工作会一直延续下去,到最后,自动化也就是失败的自动化,达不到降本增效的效果,产生的数据也无法做到数据的消费。
对于标准化的理解有三种情况。1:开发模式的标准化,也就是说尽可能的使用某几种框架,使用maven进行统一管理,使用同一种协议,使用同一种开发模式。2:运维模式的标准化,运维标准化基于运维和其他团队的边界,运维内部的对象的统一和标准的制定,,包括但不限于团队的职责,技术栈的选用,脚本的编写规范,机器、实例、服务、应用等运维对象的属性,聚集分散的运维状态数据。3:IT内部流水线的建立,以交付作为核心输出能力,把研发、测试纳入到交付整体的节点。
基于以上标准化,其实自动化已经完成了70%,剩下的30%就是采用每个模块所需要的工具,搭建积木的方式来构建运维核心自动化平台。

收起
银行 · 2019-04-02
浏览3083
  • wh85  wh85
    感谢您的回复。从我所在的公司IT结构而言,目前运维自动化或者说交付仅仅是运维部门的事情,和开发之间的部门壁垒还比较深。所以您说的三种情况我们只能先将第2种先进行实施,这属于部门可控范围内的事情。长痛不如短痛,我们争取获得从上到下的理解和支持吧。
    2019-04-03
yjytiantiyjytianti  系统运维工程师 , 中原银行
个人认为在自动化运维平台实施前,需要有标准化,但不一定是立刻全部实现标准化,可以逐步推进,和自动化同时推进,不断迭代。至于范围,可以从以下2方面入手:1、工具标准化开发框架 可以自研或者引入第三方,统一开发框架,如果和开发壁垒较大,可忽略。配置管理 使用统一的配置管理工具...显示全部

个人认为在自动化运维平台实施前,需要有标准化,但不一定是立刻全部实现标准化,可以逐步推进,和自动化同时推进,不断迭代。
至于范围,可以从以下2方面入手:
1、工具标准化
开发框架 可以自研或者引入第三方,统一开发框架,如果和开发壁垒较大,可忽略。
配置管理 使用统一的配置管理工具做代码管理,主干开发或分支开发也得定个统一标准。
同时需求管理 Jira、持续集成 Jenkins、私有仓库Artifactory等这些各选择1-2个主流标准工具,工具太多势必对运维管理造成成本负担。
。。。。
2、流程标准化
资源申请制定固定的标准流程,如何申请,申请需要填写哪些信息,申请后的机器预装了哪些基础软件等。
变更申请主机变更,数据库变更,存储变更等需制定哪些内容是允许变更的,允许变更的是否可通过UI界面自助完成即可。哪些是坚决不允许变更的。
资源入库运维资源入库到cmdb标准化,如环境名称、系统名称、服务名称这些资源项在什么地方由谁定义,比如:同一个系统有的人叫电子银行,有的叫电子渠道,有的叫渠道整合。。 这是不行的,必须统一掉,便于信息在开发、测试、运维不同人群间传递。 同时明确在什么地方定义,以什么系统做载体对这些信息在不同部门之间透传。
。。。

收起
银行 · 2019-04-03
浏览2802
贺勇贺勇  产品研发部总经理 , Canway
我的观点:自动化和标准化是需要同时考虑的,他们像是DNA的双螺旋,标准化,自动化都是为了实现IT业务的目标。先做标准化的失败案例,标准化项目实施完成,交付了一堆的文档,这些文档被束之高阁,过了1年这些IT对象又变化了,标准化的文档没有什么卵用了;2.仅仅做自动化,过程中不考虑标准化...显示全部

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

  1. 先做标准化的失败案例,标准化项目实施完成,交付了一堆的文档,这些文档被束之高阁,过了1年这些IT对象又变化了,标准化的文档没有什么卵用了;
    2.仅仅做自动化,过程中不考虑标准化,自动化的效果不好,有可能会带来系统的故障。
    因此,我的建议,标准化和自动化应该是需要同时考虑的,标准化的对象需要通过工具实现自动化交付,标准化的规范流程又可以保障自动化的效果。
    聚焦运维,标准化执行的过程中我的建议如下:
  2. 标准化要分为管理的标准化和技术的标准化;如数据库的命名,生命周期管理等都属于管理的标准化;
    2.标准化不仅仅涵盖实际的运维对象,还包括架构、运维事件、运维服务等这些对象的标准化
    3.标准化的文档需要分级,操作规范和要和管理规范混合在一起。
收起
系统集成 · 2019-04-03
zjwy82zjwy82  系统架构师 , bank
传统企业在自动化运维实施过程中都会面临一些历史包袱问题,个人建议标准化必须做,在自动化实施前应设立一些原则,如标准化、参数化、脚本化等,并制定一些规范,以指导实施。具体在实施过程中可以遵循系统新建、重大改造时必须做标准化,历史系统可适当保持现状。针对配置差异、不...显示全部

传统企业在自动化运维实施过程中都会面临一些历史包袱问题,个人建议标准化必须做,在自动化实施前应设立一些原则,如标准化、参数化、脚本化等,并制定一些规范,以指导实施。具体在实施过程中可以遵循系统新建、重大改造时必须做标准化,历史系统可适当保持现状。
针对配置差异、不同类型,采取对象分组的方式,将自动化脚本和组对象做柔性关联,通过参数化来解耦自动化脚本与变更对象的绑定关系,实现复用。

收起
银行 · 2019-04-02
浏览2829
a8757906a8757906  系统运维工程师 , 三一重工
第一:明确需求。首先自动化平台建设最开始的时候要收集用户需求,基础部有哪些需求,应用部有哪些需求。根据需求去开发相应的功能。第二:系统资源交付时要标准化。例如系统安装、数据库安装、DG库安装、中间件安装等标准化等,减少系统环境之间的差异性。第三:自动化脚本编写规范...显示全部

第一:明确需求。首先自动化平台建设最开始的时候要收集用户需求,基础部有哪些需求,应用部有哪些需求。根据需求去开发相应的功能。
第二:系统资源交付时要标准化。例如系统安装、数据库安装、DG库安装、中间件安装等标准化等,减少系统环境之间的差异性。
第三:自动化脚本编写规范化、原子化。规范化:脚本的编写要考虑到环境的差异性,判断环境的差异性,然后再做具体操作。原子化:脚本原子化之后,将某一个功能用一个脚本实现,后期如果有其他功能的脚本需要此功能的实现,可以直接进行编排调用。减少人工对脚本的编写和维护。
第四:确保CMDB数据准确。确保CMDB数据准确。确保CMDB数据准确。信息的错误,在做变更类操作时,将可能导致生产事故。
此上,希望我的回复起到抛砖引玉的作用,望各位大师发表自己的见解。

收起
机械装备 · 2019-04-03
浏览2740

提问者

wh85
wh85014
系统工程师某大型保险公司

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2019-04-02
  • 关注会员:8 人
  • 问题浏览:6037
  • 最近回答:2019-04-03
  • X社区推广