随着银行业务的快速发展，支撑业务的IT基础设施的变化节奏也大大加快。运维团队担负着对IT基础设施运维的重要使命，核心任务是保障生产安全运营，并提高软硬件环境的交付质量。

运维管理规模的不断扩大，运维人员的不断扩充，使我们的日常运维工作面临更大的压力与风险。

在很长一段时间里，应用运维尝试通过脚本辅助来提升工作效率，但仍然面临着繁重的工作压力：

(1)、管理工作繁重，所管理的资源类型和数量众多，但是缺乏一个准确的整体资源视图。
(2)、生产操作以手工操作为主，在手工操作时存在一些无意的误操作，给生产环境造成操作风险。
(3)、日常巡检仍需由专人负责应用系统相关的日报生成与发布。数据采集缺少统一的管理界面，数据分析工作依赖于管理员个人经验进行，出现问题缺少记录与跟踪。

在运维管理工作中就会出现以下几个主要问题：

(1)、手工操作的风险不可控：日常巡检、服务请求、问题查询都通过登录生产主机进行操作。
(2)、运维工作及时性差异：各运维人员管辖的应用系统、主机数量多，巡检工作以手工为主，无法及时有效地在系统开门前做全面巡检。
(3)、工作规范性不强：新员工对现有的工作制度、工作流程需要一个逐步适应和熟悉的过程。不同人员对应用系统的运维管理工作细致程度存在差异，缺少统一标准。

面临以上问题，企业需要建设一个服务于运维人员的统一管理工作平台——应用自动化运维系统，用来进行日常的生产系统操作任务，隔离运维人员与生产系统的直接接触。

在11月8日的线上交流活动中，围绕着自动化运维的框架、配置管理、应用发布以及自动化中的标准化等方面进行了问题的讨论，也得到了各位专家的支持，大家针对自动化运维相关问题体现出了非常大的热情，在此也对相关问题及大家的观点总结如下：

自动化平台中配置管理的作用与设计实施

典型问题：

Q1、配置信息库应该如何设计？配置信息库应该如何设计，既可以涵盖自动化所需的数据，又不庞大而繁杂不好管理？
Q2、配置信息如何利用自动化来实现动态采集？
Q3、自动化运维平台建设中的配置管理起到什么作用？要怎么做？

问题解答：

A1：配置管理是很古老的话题，我们在做自动化时采取的是小而全大集权的模式。小而全是指各专业领域建立自己的配置管理子库，管理自己所需的数据。大集权是指配置项标准集中管理，专业领域横向依赖的信息集中管理，各子库作为数据源，集中库作为信息交换源。
子库建设为各专业领域的自动化提供依据，在自动化场景中应用配置信息，使得配置信息的准确。

A2：配置信息的自动化采集需要预先建立一些标准，如配置项标准、采集模板、采集时序等，配置项要根据不同的产品类型设定，例如操作系统要区分linux unix等；采集模板在配置项标准上根据不同要求扩展。有了标准采集，设定相应采集时序，对采集内容进行定期采集入库管理，建立配置信息的基线。例如我们每天采集相应信息，与上一个基线比对，差异情况推送给相应负责人进行确认，根据确认结果更新基线。配置的准确性还依赖于使用，在使用过程中发现配置采集的准确性问题，修订配置项标准和采集模板。

A3：配置管理范围很大，在自动化中，不同领域关注信息不一样，如应用关注服务，系统关注服务器，网络关注交换机火墙及ip。自动化的操作要保证正确性，就依赖配置准确，合理建模，一个操作与预期是否一致，所操作的对象要准就依赖配置信息，配置要管理自动化自动化的操作要保证正确性，就依赖配置准确，合理建模，一个操作与预期是否一致，所操作的对象要准就依赖配置信息，配置要管理自动化自动化的操作要保证正确性，就依赖配置准确，合理建模，一个操作与预期是否一致，所操作的对象要准就依赖配置信息，配置要管理自动化

自动化发布的实时监控与安全控制

典型问题：

Q1、自动化发布都是由平台自动统一执行，对发布程序或脚本要求很高，虽然参数化模型消除了各运行环境的差异，难免有考虑不周或测试不到位情况，如何监控发布的应用后台技术情况？或者说发布时各应用开发和运维人员如何实时监控发布的详细情况？
Q2、对于使用自动化运维平台进行大规模变更，应建立什么样的审核制度进行风险控制？
Q3、自动化发布的设计时，如何保证安全性和正确性？

问题解答：

A1-1：自动化发布的目标是将应用服务按需求正确部署，传统情况下我们都是通过登录主机操作，能实时查看到输出结果，这样的操作有既视感，让操作人员心安。而自动化后怎么监控的问题会在初期困扰运维人员，我们通过将日志准实时采集展示在自动化平台上实现对后台运行情况的监控。同时也在自动化的步骤中增加验证步骤，将原有通过人观察结果判断的方式转换成自动化判断方式。
对于开发和运维人员，通过前端显示流程执行进度、状态及后台输出等信息来实现等效的手工操作观察。

A1-2：是的，自动化运维尤其是复杂多变的发布，虽说可通过状态等自动判断和验证等多种措施保证正确性，但模拟常规的查看后台运行状态等准实时监视是非常有必要的。其他应用系统有多种业务验证规则并有相应的业务人员检查，还需技术人员监控查阅后台服务情况，自动化运维系统是业务与技术合一的系统，开发技术人员往往对自己的编程过于乐观，测试也很难百分之百到位，运维实施过程中监控后台运行情况就很有必要。我们在具体实践中也证明了这一点。
我们目前的自动化发布是有一定交互功能的，流程和运行情况都能准实时显示，并可根据情中断或重启流程。这点在初期推广阶段效果很好，下一步，我们也将吸取你们经验将成熟的应用系统实现定时全自动化发布。

A2：变更是运维中最常实施的场景，大规模实施的风险控制也是我们所关注的点。在我们日常工作中，变更从发起需求到实施需要经过需求评估、方案制定与评估、变更方案验证测试、变更方案评审、生产实施几个阶段。自动化的实施在流程上各个环节依然需要具备，同时在技术上，我们采取分批，试点验证后集中实施的方式。总结来说，一是前期准备充分，二变更流程审核，三是试点实施验证，四是规模实施。

A3：安全性和正确性是自动化的基本要求。实际上这个问题在手工操作时也一样存在，只是杀伤面不一样。
对于自动化发布而言，我们提出要原子化，即操作任务拆解，应遵循单元操作功能简单，可回滚，可重新调度，可验证，有验证的原则。
安全控制依赖于多个层面，一是用户权限，要和现有用户授权平台对接（至少权限数据对接，哪些用户可用，哪些服务可操作），二是对象一致即配置准确，所操作服务器严格控制，三是开发测试生产对接，做测试

自动化平台中的脚本管理

典型问题：
Q1、应用运维自动化中的脚本标准化怎么做？
Q2、自动化运维的核心是做脚本开发吗？
Q3、自动化运维中的脚本怎么管理？是否需要进行版本管理？
Q4、为了满足需求，以及需求的不断变化，运维操作的拆解，需要拆解到什么样粒度？
Q5、自动化发布通过参数模型消除开发测试生产的差异，该思路很好，但是怎么统一各应用系统的多样性，或者说自动化发布参数模型有哪些规范要求？

问题解答：

A1：应用运维涉及到各式各样的应用系统，不同技术体系的产品，我们在做一些标准化时采取封装嵌套方式。比如服务启停，针对Windows、linux、unxi不同平台都封装了标准的统一启停脚本，脚本内部嵌套各个子服务的启停脚本，将差异性内容包装在内。这样在自动化应用中，我关注的是外层的标准脚本，内部脚本可以按需修改调整

A2：自动化运维不仅仅是实现日常运维工作脚本化的开发与管理，而应从组织、文化、管理和技术几个方面建立一个系统性的能力框架体系，形成一种运维长效机制，为数据中心向运营转型提供支撑能力。

A3：自动化离不开脚本，脚本管理上可以集中式管理和分布式管理（放在目标对象上），集中管理的好处是能够统一控制版本，避免同一操作在不同目标对象上执行不一样版本的脚本。分布式管理能够确保自动化平台对目标对象失去管控情况下的替代手段。在自动化运维时建议集中管理，能够控制版本一致性，同时可以对历史版本统一管理留存，执行时将脚本下发到目标机，可以确保一次操作的完整时序。

A4-1：拆解到你迷迷糊糊也能正确完成，或者换个新人也能按你的文档正确完成运维操作。

A4-2：楼上的回答风趣幽默而又简明直白

对于自动化操作拆解粒度，实际上也是自动化建设过程中的标准化过程。对于应用的自动化而言，由于应用系统的差异性，完全统一的标准化存在难度。但也应遵循单元操作功能简单，可回滚，可重新调度，可验证的原则。

A5：这个问题也是我们所遇见的问题之一，我们在实施过程中采取了采样分析，提取标准步骤及公共参数的方式。对共性步骤和参数抽象形成规范，增加个性步骤及参数管理的能力，利用少量的个性步骤来实现各个应用系统差异化的问题。

智能化运维探讨与人员能力变化

典型问题：

Q1、随着公司的不断发展壮大，运维量倍增，目前市场上ai比较火，如何通过ai建设aiops，降低运营成本，提高产出？
Q2、金融业智能运维开始兴起？前段时间，收到行业组织的智能运维调研，大数据、自学习、AIOps，怎么感觉是还没走稳，就开始准备跑了的节奏呢？
Q3、运维人员需要学习哪些知识去提高自己的价值？自动化运维的要求很高，不仅仅需要具备开发能力，对网络、硬件、操作系统这些也要具备才可以。但是不知道如何下手？从何开始？
Q4、自动化运维人员需要具备哪些基本技能？对于传统运维人员如何需要加强那些方面知识的学习。

问题解答：

A1-1：在我的理解运维工作量大更适合于自动化来解决。ai是解决分析决策效率问题，自动化是解决操作效率问题。aiops应该基于数据，发掘数据，发掘数据价值。手眼心脑，数据是心脏供血，监控是眼发现问题，ai是脑分析决策发指令，自动化是手做事。

A1-2：目前来讲，个人以为AI没有那么快全面接管运维自动化工作，当然密切跟踪进展没有问题。

A2：个人浅见，技术发展过程中必然会有一些先驱探索，智能运维、自动化运维、传统运维之间并无很明显的界限划分。就我们情况而言，自动化运维并未发展到完全成熟的阶段，也已经在监控领域探索一些智能化的衍进，比如对于海量告警的压缩提取有效告警、告警的根因分析、利用大数据拟合动态基线替代静态阈值进行系统运行态监控等等。

A3-1：个人建议专业的人做专业的事，能够各个专业领域通达兼济是难得的。从传统企业来说，自动化运维的建设需要一个团队或者多个团队协作，而且也应该将各方面力量拉拢一起做这件事。
从自己熟悉的专业领域做起，了解日常工作中重复事项哪些可以由机器替代，可以采用什么技术替代。在开发能力上可以关注shell或Python等语言，工具搭建上可以从ansible等开源软件熟悉。

A3-2：运维人员能力要求可大可小，最好是对业务与技术都了解，对开发能力要求其实并不高。但对数据库和脚本编程最好精通些，这样各种运维才能得心应手。

A4：从我们目前的实施应用情况来看，自动化运维工作在基础平台搭建完成后，更多的是脚本开发能力，从初期来看需要关注各类脚本的编写能力。同时，自动化运维后需要运维人员对方案制定与评估更为审慎，那么对业务系统架构与关联分析要更严谨。
因此建议传统运维人员在脚本开发能力（shell、python）、应用架构设计（网络控制、集群管理、负载均衡等）等方面多做些了解。