如何做好金融行业自动化运维的规范化标准化？

Posted 2021-05-01 twt企业IT社区

以下内容来自社区交流，由数位来自银行等金融行业、专注IT系统开发与运维的社区专家分享。

自动化运维在银行业是否有标准？

@mornsky：

明确意义上的自动化运维标准在银行业暂时没有，不过在运行维护管理、数据中心管理、风险控制以及类似的云平台建设等方面有明确的规范标准.

根据《中国银行业信息科技“十三五”发展规划监管指导意见》第9章第3节：提高运维自动化水平，打造智能化运维体系----提高基础资源和应用部署的自动化水平，实现快速交付、动态调整、弹性部署，降低人工操作风险，自动化部署比例不低于75%。持续推进生产运维监控精细化、自动化、智能化建设，强化系统风险和故障的早预警、早定位和早处置。实现应用层面交易全流程、全节点监控全覆盖，结合应用系统交易特性及相关数据的分析对比，提升交易过程监控的智能化水平。强化容量管理，做好相关资源的动态规划，预防非计划性、突发性的容量瓶颈问题发生。强化运维、开发、安全、风险管理的信息共享和一体化协作，提升多方联动能力。加强运维大数据分析，利用运维大数据加强业务风险防控，探索利用运维大数据推动业务流程优化并支持业务创新。

@galaxy1975：

玄学一点儿的回答就是：有标准，也没有标准：

• 先说说有标准： 实际上，金融行业，特别是银行业的运维规范建设是要优于其他行业的，包括ITIL、运维流程、操作系统部署规范、故障处理规范、应急预案等等，几乎都有建设，这些已经建立的规范，就是构建自动化运维可以参考的“核心”。 所以，如果是说“狭义”的自动化运维，那就是在企业内部把这些规范进行自动化实现即可，实现规范的自动推送、自动检查等工作， 同时，实现流程上的自动化，例如从资源划分一直到业务发布的流程控制等等，这些都算是自动化运维可以做的工作，也都有规范可以依从。

• 再说说没标准： 通常在提到自动化运维建设的时候，很多企业都想实现进一步的自动化，例如往PAAS平台靠拢、引入DevOps概念等，特别是企业领导，通常希望利用这些新的平台、新的理念来优化企业的IT运行效率。但这些平台、理念在银行业还没有一个完整的标准，特别是DevOps改造、PAAS平台建设等项目还会牵扯到组织架构的调整或优化（实际上上面的自动化流程实现也会涉及到，但动作不大），那就更没有标准可以依据了，每个企业的情况都不同，所以，大家都是在摸着石头过河。 不过，目前一个通用的想法是，借助DevOps的理念，小范围，基于某个项目来进行改造，强化改造所带来的收益。

自动化运维标准化规范需要做哪些事情？

@mornsky：

自动化运维建设，第一件事要做的是标准化，那么，标准化需要做哪些事情？

第一:系统层面尽量标准化，即服务器、操作系统、中间件、数据库及其配置信息尽量统一、规范化。

第二:应用层面尽量标准化、可脚本化，即应用的各种配置信息，服务信息(进程、日志、记录等)尽量规范化或者能通过后期简单加工处理能规范、统一。譬如通过将目录创建链接规范化目录名，通过编写启停脚本，规范化启停命令等等。

第三:运维流程标准化，即规范化各种运维审计、运行步骤。

如此，不论是否有自动化运维平台，都能实现很大程度的标准化自动化运维，自动化平台运维平台只不过是促进、管理各种规范化标准化的自动化运维工作，并实现一定程度的智能化分析。

@secretpower：

尽量少的使用不同种类的服务器类型、操作系统类型、操作系统版本、数据库软件、数据库版本、基础软件、配置信息等等IT元素去满足企业的需求，并保证每个种类中属性被正确、统一的描述，并将实际使用情况向其靠拢。“尽量少”、“统一”和“靠拢”就是标准化的工作。

企业做自动化前应具备达到什么标准的规范性操作流程、制度?

@mornsky：

自动化运维目前没有一个行业规范，只是有各种指导原则，自动化说大就大就小就小，打过比方:汽车有自动档和手动档，手动档好理解，但自动档的前进档和退档、空档还是需人工切换。自动化运维也一样，我们只需要尽量规范化标准化地简化或自动化部分运维操作也可称为自动化运维。

如何设定自动化版本发布的规范？

@mornsky：

下文是实际应用的自动化版本发布的概要, 供参考.

1.本自动化发版规范制定所遵循的原则是：

• 总结分析各系统发版工作的具体操作, 抽象地制定一个广义的通用的发版工作规范

• 规范制定应符合统筹规划原则，制定统一的技术规范和标准，要全面的考虑到各种系统、各种应用等情况，能适用各类信息系统的接入。

• 规范制定应符合严密安全原则，制定的规范不应存在技术管控盲点，规范还应充分考虑到信息系统安全稳定运行的要求。

2. 自动化发版原理

制订约定规范发版文件清单和执行脚本或者命令, 将相关发版文件打包, 在统一的自动化运维平台统一调度执行, 自动化发版已综合分析了很多系统的发版操作, 通过本规范, 将很大一部分操作标准化通用化了,并编写了一系列通用化标准化的操作程序,大幅度降低了发版操作的复杂多样性, 并能统一平台监控查看发版运行情况.

3. 限制

自动化运维平台根据一定的策略及配置在各系统后台自动处理相关作业，与人工处理做一步确认一步的方式有本质的区别。因此，保障每一个操作执行条件和输出结果的精确与正确就非常重要，必须避免发版操作中可能存在的不确定因素和操作风险，以下为发版操作(又称作业)的限制：

• 作业中无用户交互；

• 作业在运行中无图形界面；

• 作业间不能有外部变量传递；

• 避免作业执行用户的profile中有read等输入等待的命令。

4.发版文件规范

自动化运维平台支持应用发版功能，为避免每一次发版都需重新规划发版流程，我们需要制定一个通用性的应用发版流程。而应用发版的前提必要条件是发版文件，因此我们首先针对发版文件制定相关的标准规范，发版文件包括应用更新(新增和修改)的文件清单和本次应用发版辅助进行数据更新、应用等操作的数据文件或者执行脚本，其中执行脚本有一些是约定功能的指定文件名。

所有清单文件内容，都可以写注释，以#开头的行都当作为注释，注意：与shell注释不同的是#在行中间不被当作注释。

由于应用环境存在GBK和utf8等多种字符集，我们统一归类为GBK和utf8两种字符集， 对于无指定字符集的C运行环境，可归属于GBK。各应用系统发版文件，包括清单文件中的中文，请务必与应用的字符集一致。

附：总清单

描述：每次发版前需准备提供的发版文件总清单，该清单包括的内容有：

(1)应用新增或修改文件的清单文件名: upff.lst

(2)数据备份脚本名: updbbak.sh

(3)数据更新脚本名: updbrun.sh

(4)更新前及发版后检查设置文件: upcheck.ini

(5)备份前操作脚本名:upbakfront.sh

(6)更新前操作脚本名: upbinfront.sh

(7)更新后操作脚本名: upbinback.sh

(8)应用删除文件的清单名: updel.lst

(9)总清单名: uplist.lst， 自身

(10) 辅助文件: 非应用系统必需的文件，只是本次发版需要的一次性的执行脚本，相关数据文件等。 每行一个文件名,可多个,辅助文件建议不写文件路径，只写纯文件名即可，以便平台保存在该次发版相关的子应用工作目录中，便于查看和清理。

说明：以上shell脚本都不是必须提供项，为了投产时更加灵活的进行个性化接口，相当于数据库的触发器性质。

实际应用中，常用文件为:应用更新清单文件和更新后操作脚本。

如有任何问题，可点击文末阅读原文到社区原文下评论交流

 资料/文章推荐：

企业应用级自动化运维的建设思路与实践

http://www.talkwithtrend.com/Document/detail/tid/418627

某银行企业级应用运维自动化关键设计思路与技术方案实现分享

http://www.talkwithtrend.com/Document/detail/tid/420011

http://www.talkwithtrend.com/Topic/7085

下载 twt 社区客户端 APP

与更多同行在一起

高手随时解答你的疑难问题

轻松订阅各领域技术主题

浏览下载最新文章资料

或到应用商店搜索“twt”

长按二维码关注公众号