金融行业自动化运维规划建设实践与应用难点（同行共识总结）

@yjytianti 运维工程师 河南某银行：

从两个方面来考虑：

1.基础设施型号不宜过多：在考虑X86和信创架构时，建议分别选择1到2家具有主流次新型号的厂家，避免型号过多。过多的型号会导致管理复杂，增加自动化实施的难度，并且不容易管理。

2.管理平台方面：基础资源统一平台管理方面，选择兼容性高且技术实力强的厂家。尤其是目前市面上的云管平台、容器云平台产品众多，需结合公司自身的管理诉求，综合评估。不能单单看厂家具备什么能力，而更应该考虑自身诉求的能力场景具备了多少。

@三虎 中国邮政储蓄银行 系统运维工程师：

负责构建关键基础设施资源的平台，例如云计算平台或其他相关管理平台等，通常具备较为丰富和功能较为完善的API接口。这些接口设计得既方便二次开发，又易于后续与其他管理系统进行高效对接，以实现自动化管理的目标。例如，当资源需求系统与云管理平台结合使用时，一旦资源需求获得审批，便可以迅速实现资源的分配和创建。

在选择基础设施时，建议选择那些较为通用或技术成熟的软件产品。这样在部署或进行后期维护时，可以充分利用现有的自动化案例或接口，直接实施自动化操作，从而大大简化后续的自动化运维和管理流程。这种策略能够提高整体效率，降低维护成本，同时保证系统的稳定运行。

@penghuasheng 广发证券 技术经理：

1.如果企业还没落地相关技术平台，则建议引入云资源管理平台，平台选型建议找行业主流的供应商。

2.如果企业已经构建了一体化的多云管理，且基于多云管理实现了自动化的纳管、弹性伸缩、装机、监控、成本优化等自动化能力，基础设施软硬件的选型建议适配多云管理的标准。

@wykkx 某基金公司 系统架构师：

1.基础设施应该是在所在行业有较高的市场占有率，建议考虑TOP5的品牌；

2.在采购前的POC阶段应进行充分的测试，尤其是对于在后续自动化建设过程中非常重要的节点；

3.基础设施必须具备开放接口，接口可以是API也可以是cmd shell，且接口必须具备鉴权机制；

4.基础设施的开放接口应具备向下的兼容性，防止基础设施升级后，配套的流程发生错误；

5.基础设施的维护团队需具备一定的开发能力，在接口出现问题时能够协助问题排查；

@yjytianti 运维工程师 河南某银行：

显然不是所有的基础设施操作都需要进行自动化，该提问可进一步转化为：哪些基础设施操作实现自动化是最佳实践？以下是我的一些建议：

1.首先，需要明确一下自动化的定义，什么叫自动化？根据科学百科的定义，自动化（Automation）是指机器设备、系统或过程（生产、管理过程）在没有人或较少人的直接参与下，按照人的要求，经过自动检测、信息处理、分析判断、操纵控制，实现预期的目标的过程。

2.其次，从定义中明确自动化的含义。

（1）自动化并不是不需要人工参与，是允许有较少人参与的。

（2）自动化是一个过程，而不是结果。

3.再次，基于以上分析，基础设施操作中可实现自动化的最佳实践建议如下。

（1）资源申请操作：如VMware资源、青云资源、容器资源、物理机资源等。

（2）软件安装类：如OS，Oracle 、MySQL、JDK、Weblogic等软件安装操作。

4.最后，个性化的操作建议做成自助化+自动化。如：网络续期、用户新建等，这类操作在技术上可以做成自动化，但是考虑到管理诉求，建议做成自助化+自动化。由用户自助申请，运维人员自动执行。

@三虎 中国邮政储蓄银行 系统运维工程师：

不是所有基础设施操作都应该自动化，自动化应聚焦于操作频次高，操作风险低，结果与预期无差别的一些场景。故反观之，操作次数低，风险大，不可预估结果的操作不建议使用自动化实现。

@penghuasheng 广发证券 技术经理：

1.按SRE的消费“琐事”的思路，其指导方向是自动化的则自动化。其逻辑是“琐事”会从效率、成本、情绪等多个方面对运维人员有负面影响。

2.自动化需要一些条件，擅长重复性、有规律、可标准化，且环境比较稳定，只有那些达到条件的操作才能自动化。

3.自动化手段代替了人工低价值的工作，但自动化也有失效的可能性，以及运维人员对生产运行的敬畏心。所以，从管理角度可适当保留人工操作、检查、复核的工作要求，比如例行强态化的巡检与自动化的监控并存。

@wykkx 某基金公司 系统架构师：

在我看来，并不是所有的基础设施操作都需要进行自动化，应该遵循如下原则：

一是操作发生频率和操作影响范围，对于发生频率较高且影响范围有限的基础设施操作，建议使用自动化的方式，例如：云主机的创建、中间件的创建与升级、网络策略的开通、存储资源的分配、HW常见操作等；但是对于发生频率较低的场景，不太建议自动化；

@penghuasheng 广发证券 技术经理：

在《运维数字化转型》中的思路是：一体化运维平台方案包括“ 6 平台 + 场景 ”，即：“ 6 平台”是资源管理平台 、 监控平台、服务平台、信息安全平台、操作平台、运维数据平台 ， “ 1 场景 ”是指 场景平台。其中，场景的作用是基于实际稳定性工作场景 ， 达到数据、 工具 、 协同、人、机器等整合 ， 实现上类似于应用工厂的作用 ， 提供移动端、桌面端、大屏等多终端管理 ， 需要具备多用户、可组装、互联互通、快速迭代等能力 。场景化是一种整合的思路。

如这个问题中的自动化运维平台特指“自动化操作”平台，平台可以考虑支持面向统一代理管控、脚本仓库、低代码的工具构建、服务总线、操作管控、操作感知等基本能力，以及支持对其他企业现有的自动化操作工具接口的调度。有了自动化操作的平台能力后，就要推动上层构建自动化操作场景工具。另外，工具是面向一线运维人员的的生产力工具，平台对工具的操作风险进行管控与监控。

@wykkx 某基金公司 系统架构师：

统一管理多个自动化运维平台，单就这个问题本身而言需要从以下几个方面考虑：

一是各个自动化运维平台必须提供相应的API接口，通过接口实现对各个平台数据获取和任务的下发；

二是统一管理平台自身需要具备较强的扩展性，统一管理平台需要能够通过配置、低代码或者是二次开发的方式来支持与其他自动化运维平台的对接；

三是通过统一平台进行任务的执行记录和每个平台独立进行执行的记录需要统一在管理平台进行记录，方便管理工作的进行。

四是制定统一的自动化运维标准与规范，各个自动化运维平台应该按照相同的标准与规范设计自动化流程任务。

五是统一的监控手段。统一管理平台应该能够通过统一监控的方式对各个平台的任务执行情况进行监控。

六是身份授权管理机制，一种是通过SSO的方式，只允许通过统一管理平台进行登录和操作，第二种是除了通过统一管理平台进行登录外，同样也支持各个平台自身的登录，无论是哪种方式，都需要对登录进行权限管理和记录。

@三虎  中国邮政储蓄银行 系统运维工程师：

基础设施自动化一定会与CMDB进行联动，充分发挥资产数据价值，实现自动化与CMDB的南北向交互。

具体来看，自动化实施依赖于CMDB，资产信息在CMDB中，自动化要操作对象，要展示的信息均来自于CMDB，且操作对象信息可能贯穿不同层次的CMDB信息，如删除某个虚机对象，需要查询虚机信息、物理设备、存储设备、存储明细等等信息，最终才能完成动作。自动化操作完成后，还需要将过程、结果回写到CMDB，最终保证资产数据的一致性、准确性。

此外，如监控自动化平台、流程管控平台、故障自愈平台同样高度依赖底层CMDB数据来完成自身的工作。

@penghuasheng 广发证券 技术经理：

1.从CMDB作为企业IT资产台账角度看，基础设施的管理平台内涉及CMDB的CI项数据，基础设施的管理平台内的配置信息可作为CMDB的联邦数据源之一。

2.从基础设施管理平台的自动化场景工具角度看，CMDB有基础设施平台内没有的纵向部署、横向调用，以及其他平台没有的资产对象信息，CMDB是平台自动化实现互联互通的必要数据源。除了操作自动化，基础设施的资源成本、资源运行效率也依赖CMDB提供的数据支撑。

@wykkx 某基金公司 系统架构师：

基础设施自动化与cmdb的结合应该从两个方面考虑：

一是“读”的方面，基础设施在进行自动化的过程中需要从CMDB中获取配置信息（CI信息），例如：在进行资源创建时选择从哪个资源池进行创建，使用什么样的配置模板，创建的资源应该属于哪个系统或者应用，这些数据都应该从CMDB中进行读取；

@三虎 中国邮政储蓄银行 系统运维工程师：

ITSM是流程管控平台，而自动化运维中涉及的变更动作，是需要经过审批后实施的，当管理员在ITSM平台上提交了变更需求的同时，可以通过ITSM同步创建对应的自动化任务，实现审批后即自动化执行（按时间计划）；此外，ITSM如果有故障、告警工单，经过人工确认告警内容、处置手段后，在关联自动化任务后实现故障的自动化处置。

@penghuasheng 广发证券 技术经理：

1.如果此处的ITSM认为线上工单或流程系统，可以考虑工单的表单数据作为入参，流程引擎支持对自动化接口的调用：比如资源申请后的自动化分配等。其还可以构建服务目录，推动一切皆服务的思路。

2.如果将ITSM认为是服务管理，可以扩展得比较广，比如“故障管理”的服务目标是为了尽可能减少故障时间，则其设计上就要从故障前的风险挖掘、常规的在线值班、在线监控告警管理、故障快速识别、故障启动后的指挥调度、故障应急、应急预案、故障复盘等各环节的在线化、自动化建设。

@wykkx 某基金公司 系统架构师：

基础设施设施自动化主要是为了通过ITSM将基础设施自动化通过服务化的方式进行推广，在结合过程中可以参考如下方式：

一是将已经实现的基础设施资源自动化能力，通过ITSM的服务目录的方式进行对外发布，使得使用者可以快速便捷的找到自己需要的基础设施自动化能力；

二是ITSM在制作服务目录的时候，应该准确获取到对应自动化流程所需的参数信息，并将这些参数信息进行表单化处理，一方面方便申请者对信息进行填写；另外一方面可以将参数传递给后端的基础设施自动化流程，以便驱动流程的运行；

三是ITSM应该能够读取到基础设施自动化平台的执行结果，并将结果进行保存，以便后续的数据分析工作；

@yjytianti 运维工程师 河南某银行：

实践中，我们是基于分层监控的思路去落地自动化运维。

1.基础资源层

基础资源层：部署Prometheus等监控工具先实现硬件、CPU、内存、存储、网络等基础资源层的监控，保障基础资源可用。

2.进程层

基础资源层没问题，仅代表支撑层面没问题，但是主机上的服务进程或端口未必是正常的。需要对进程存活状态、端口连通性等进程级别进行监控。

3.接口层

进程存活和端口正常也不能够代表系统之间的接口调用是正常的，所以，还得配置接口层的报文探测监控，调用真实的接口报文，监控接口级别的服务响应状态。

@penghuasheng 广发证券 技术经理：

这问题与稳定性保障中的“故障发现”相关，我理解可以从以下点切入：

1.已知问题的“监控”。这个没有太多好办法，是一项细致活，比如：出故障后的复盘、学习同类系统的举一反三、上线前左移了解到应该要增加的监控项、人工巡检的自动化等。

2.潜在风险的“分析”。潜在风险的识别分析，可以往“比不同”的角度切入，比如：业务与技术的指标、系统状态、配置内容、程序版本、容量水位等发生变化的信息都可以作为风险项来分析。

3.未知问题的“智能”。我觉得“智能”主要是解决人工规则分析难度大的领域，比如指标异常检测涉及的动态基线应对海量的指标、业务日志模式的识别应对海量数据的异常分析。

@wykkx 某基金公司 系统架构师：

自动化运维与监控和监控数据的分析是离不开的，主要需要做好以下几方面的工作：

一是需要监控工具或者平台能够充分采集自动化运维对象的各个方面的指标数据，能够通过多维指标的方式将自动化运维对象量化出来，尤其是自动化运维过程中可能导致运维对象发生变化的指标。

二是需要将监控工具或者平台采集到的数据，按照一定的规则进行数据清洗，将清洗后的数据进行分析，找到自动化运维对象的数据特征，并总结出正常的指标阈值范围。

三是自动化运维平台与监控和数据分析平台能够联动，从而在自动化执行过程中，能够及时观察被运维对象的各项指标是否异常，通过告警及时进行通知。

@yjytianti 运维工程师 河南某银行：

1.严控数量，减少重复

同一个主机上可能会安装多个Agent ，不同的部门有不同的诉求。基础设施团队需要Agent去安装一些初始化的操作系统软件，安全中心需要Agent 去部署行为分析工具，等等。所以，第一步就是要明确管控原则，不能无限制的安装Agent，最好能够实现OneAgent。

2、求同存异，功能合并

针对不同团队的需求，梳理出相同点和差异性，对Agent 功能进行合并，减少重复采集。

3、因地制宜，动静结合

针对不同的功能，设置不同的采集频次。

比如静态数据，定期采集：针对操作系统版本、软件版本、CPU配置、内存配置等静态数据，此类数据较固定，一天采集一次即可。

动态数据，频繁采集:针对资源使用率、进程存活状态等动态数据，需进行频繁采集，如5分钟采集一次。动静结合，有序平衡Agent的资源消耗。

@wykkx 某基金公司 系统架构师：

自动化运维的实现其实分为agent方式和无agent方式，对于前者来说功能更加强大，对于后者来说不会占用主机资源。我们分析下agent方式，为了防止agent方式对主机占用过多资源，可以从以下几个方面进行：

一是在进行POC选型测试时，就充分测试agent在自动化运维场景下的资源消耗情况，对于不符合预期的产品直接淘汰；

二是现在很多基于anget的自动化运维平台都支持对于agnet使用资源的限制，包括CPU、内存等，可以通过配置限制的方式，将agent的资源消耗控制在可以接收的范围内；

三是对agent使用的资源进行监控，当限制机制出现问题，导致agnet使用资源超出监控值时，将agent进行停止，防止其对正常的业务造成影响。

@zjwy82 某银行 系统架构师：

对于运维agent的资源占用，一直是自动化运维的一个重点关注项。这个问题需要从三方面来做把控，一是资源监控，二是资源限制，三是任务限制。

首先，要做到资源不占用太多的前提就是我们知道使用了多少资源，需要有自监控的机制，包括计算、存储和内存等等资源。资源的使用数据获取频率也需要关注对本地资源的消耗。

其次是要监控任务执行并发度及其对资源消耗的关联关系，一般而言几个任务调度和上千个任务调度对资源的要求会有明显区别。

最后对于资源的控制从两方面，一是尽量精简agent非必要的功能，轻量化运行态，保障代码质量和效率。二是结合容器等技术限制资源使用上限，避免资源超用。三是利用任务执行监控和资源使用监控，动态控制资源的使用。

@penghuasheng 广发证券 技术经理：

1.首先应该评估是否可以复用现有成熟的代理，生产环境运行的代理通常经过了一些坑，有能力支持的情况下优先考虑复用。

2.现在有不少代理有做一些执行数量、资源配额和限制等管控，可以参考一些行业主流的代理的设计。

3.代理也可能出现异常，需要配置一些监控策略，监控代理的资源占用。

4.主机上可能已经部署了多个代理，可以考虑让代理相互管控、监控。

5.定期统计分析代理运行指标，提前发现风险。

6.建立一个统一的代理管控工具，包括代理版本更新、数据采控、脚本执行等能力。