活动背景

银行等信息化程度高的行业,随着业务的持续发展和不断创新，IT系统不断壮大，IT运维已经成为IT服务内涵中重要的组成部分。面对越来越复杂的业务，面对越来越多样化的用户需求，数据中心基础设施规模随之不断扩大，服务器、存储、数据库、网络资源等需求愈加旺盛，系统架构日趋复杂；在互联网和智慧化建设背景下，包括智能营销和精准获客在内的新需求大量涌现，促使应用架构呈现多元化发展趋势；监管要求日趋严格，现场监管和非现场监管、内部审计和外部审计相结合的方式，对运维标准化、规范化、合规性提出了更高的要求。

不断扩展的IT应用需要越来越合理的模式来保障IT服务能灵活便捷、安全稳定地持续保障，这种模式中的保障因素之一就是IT运维。从初期的几台服务器发展到庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求，那么标准化、自动化、架构优化、过程优化等降低IT服务成本的因素越来越被人们所重视。其中，自动化最开始作为代替人工操作为出发点的诉求被广泛研究和应用。

所谓自动化运维是指通过将日常IT运维中大量的重复性工作（小到简单的日常检查、配置变更和软件安装，大到整个变更流程的组织调度）由过去的手工执行转为标准化、流程化和自动化操作。

自动化运维通过制定IT运维工作的规范规则，辅助技术手段，促进IT运维工作尤其是应用运维的规范化、流程化和自动化, 提高工作效率，降低运行风险。宏观能通过图表流程等直观友好方式向普通运维人员和管理人员展示运维进程和运维成果, 微观能给后台技术人员提供尽量详细实时的运行情况和事后分析记录。

目前，自动化运维基本上都是以计算机主机、操作系统为对象的系统层面的操作，我称为基于系统层面的自动化运维。那么对于应用层面的自动化运维如何实现呢？系统运维实质性是对操作系统本身运行维护的一种特殊应用运维，业务作为一种或者多种应用系统的功能，通过业务--应用关联实现业务的应用遍历查询，通过与流程审批管理、服务管理等系统对接实现业务维护的自动化。应用层面的自动化运维思路，以应用为基本运维对象，整合CMDB，为我们打开了广阔的开发思路和应用场景, 相信深入挖掘，可以很大程度上真正实现统一的全方位的数据中心自动化运维。

应用层面的自动化运维面向人员比常规的系统层面自动化运维广得多,面临的各种情况和问题也多得多,业内类似开发案例也很少,需要从各方面做更全面深入的探讨研究.为了帮助企业中运维人员梳理应用级自动化运维建设思路，对应用级自动化运维的架构设计进行探索交流，社区组织了本次“企业应用级自动化运维建设思路与架构设计”线上交流探讨。

问题总结

本期活动针对应用层面的自动化运维建设中的标准化、安全风险控制、应用和业务如何加入、结果判断等提出了24个问题，并做了较深入的讨论和详细解答。这些问题大都与应用层面相关，是系统层面自动化运维建设中没有或者无关紧要的问题。

一. 自动化运维的规范化、标准化问题：

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

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

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

galaxy1975 系统架构师 , 自动化运维专家 也作了精彩解答。

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

• 先说说有标准：
  实际上，金融行业，特别是银行业的运维规范建设是要优于其他行业的，包括ITIL、运维流程、操作系统部署规范、故障处理规范、应急预案等等，几乎都有建设，这些已经建立的规范，就是构建自动化运维可以参考的“核心”。
  所以，如果是说“狭义”的自动化运维，那就是在企业内部把这些规范进行自动化实现即可，实现规范的自动推送、自动检查等工作， 同时，实现流程上的自动化，例如从资源划分一直到业务发布的流程控制等等，这些都算是自动化运维可以做的工作，也都有规范可以依从。
• 再说说没标准：
  通常在提到自动化运维建设的时候，很多企业都想实现进一步的自动化，例如往PAAS平台靠拢、引入DevOps概念等，特别是企业领导，通常希望利用这些新的平台、新的理念来优化企业的IT运行效率。但这些平台、理念在银行业还没有一个完整的标准，特别是DevOps改造、PAAS平台建设等项目还会牵扯到组织架构的调整或优化（实际上上面的自动化流程实现也会涉及到，但动作不大），那就更没有标准可以依据了，每个企业的情况都不同，所以，大家都是在摸着石头过河。 不过，目前一个通用的想法是，借助DevOps的理念，小范围，基于某个项目来进行改造，强化改造所带来的收益。

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

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

第一:系统层面尽量标准化，即服务器、操作系统、中间件、数据库及其配置信息尽量统一、规范化。
第二:应用层面尽量标准化、可脚本化，即应用的各种配置信息，服务信息(进程、日志、记录等)尽量规范化或者能通过后期简单加工处理能规范、统一。譬如通过将目录创建链接规范化目录名，通过编写启停脚本，规范化启停命令等等。
第三:运维流程标准化，即规范化各种运维审计、运行步骤。
如此，不论是否有自动化运维平台，都能实现很大程度的标准化自动化运维，自动化平台运维平台只不过是促进、管理各种规范化标准化的自动化运维工作，并实现一定程度的智能化分析。

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

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

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

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

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

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脚本都不是必须提供项，为了投产时更加灵活的进行个性化接口，相当于数据库的触发器性质。

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

二. 自动化运维的安全风险控制问题：

常规的系统层面的自动化运维由于主要供系统管理人员使用, 这方面需要考虑的问题很少,应用层面的推广使用, 人员复杂, 这方面必须重视.

【Q1】 自动化运维安全性问题？

**如何对自动化运维所做的动作，进行结果评估，从而判断是否进行相关操作？
同时，如何界定哪些自动化动作是否需要审核？需要哪些层面的审核？
个人感觉，自动化运维还是重点在日常巡检、趋势分析上；真正的自动化维护，故障处理有太多的处理模式，需慎重。**

答：自动化运维的推广应用，安全是重中之重，目前最多的系统层面的自动化运维都是针对系统管理员作出系统层次的巡检、补丁安装、重启等常规操作，没有权限概念。应用层面我们针对不同应用系统、不同类型操作作了相应的权限控制，具体有登录访问、双人复核、验证码、审核等，评估影响程度而加强控制，后台对操作用户也作了针对性的选择控制，并对操作包括输出日志作了详细记录。目前主要是平台超级用户的管理是一个问题。

【Q2】 在自动化运维平台的建设中，如何做好相关的风险控制？相应的安全权限如何进行控制与分配？

自动化运维平台作为管理控制其它系统的系统，具有很大的权限，风险控制至关重要。风险从大来源有两个方面:开发和运行。即各类应用或系统中自动化运维的程序开发和运行控制。开发方面无疑是需要尽量全面彻底的测试验证，自动化运维只能做指导性规范性的工作。但在运行方面可多方面做些控制:

①操作系统用户层次作基本控制，各应用系统相关的运维操作只在各应用的生产用户或查询用户下执行，从根本上防止运行权限的扩大，防止意外或恶意操作的影响扩大化。譬如;程序中写在某目录下删除所有文件:rm -rf *，实际运行过程中，可能因为某些原因，当时目前为/根目录，如果是超级用户，就会导致整个文件系统，如果是普通生产用户，则只会影响当前应用系统，如果是普通查询用户，则基本上对生产运行影响不大。

②自动化运维平台对各应用系统，各种运维操作作多维度的精细化的运行控制，并根据重要性加审批、复核、校验等机制。

③自动运维平台对各类运维操作做操作记录，以便复查和监督审计。

secretpower针对开发方面作了很好的分享:

自动化本身就是双刃剑，提供便利的同时必定带来一定的风险，在金融行业尤其需要慎重。两方面思路可以考虑，一个是自动化在企业中的布局推进，可以采用先在开发测试环境投入使用，再投入生产环境使用，先使用读的自动化能力比如信息收集，再使用写的自动化能力比如批量更新。即先测试再生产先读后写的推进方式。另一个是遵循基础设施即代码思路，核心代码、脚本应该纳入到代码管理的范畴，使用版本控制系统对这些代码严格进行管理，遵循先开发、再测试、再发布的过程，管理好代码的迁入迁出、控制好测试环节，可以在一定程度上控制风险。

【Q3】 采用何种有效的验证机制确保自动化不会造成大范围的故障?

自动化运维实质上的程序化的运维，是程序就可能存在考虑不周等缺陷，只能通过充分测试验证才能保证程序的可靠性。可以先在开发环境测试，无开发环境可在生产环境做运行逻辑的测试即不做实际的可产生影响的运行譬如将运行命令改为显示运行命令。

如此，在充分测试后，先做1台或少量范围的运行，然后才能大范围推广。

其次，做好运维的审批、复核、实时监控以及验证等工作，以便及时发现问题并采取措施。

三、自动化运维的业务、应用等功能问题

【Q1】复杂应用系统如何设定加入自动化运维平台? 应用的数量过多，如何进行管理，这是一个大的问题。不同业务如何区分？

任意复杂的应用系统都可以看作是运行在1台或者多台服务器上的完成一系列应用功能的程序集合。基于应用层面的自动化运维将应用系统分为应用、子应用和服务器三级结构。业务只是在一个或者多个应用系统具体功能运行中的使用属性，主要是业务部门关注的要素，应用层面的自动化运维不直接管理业务。

应用指一个应用系统，主要记录其管理属性，譬如分类码、开发公司、负责人、维护AB角等。子应用指应用系统中相对独立的有其共同操作属性的子系统，主要记录其操作属性，譬如: 部署的操作系统用户名、主工作目录等。

一个应用可能包括多个子应用，每个子应用可能部署在多台服务器中，多个应用或者子应用也可能部署在同一个服务器中。为了模型的统一，我们将没有明显的多个子应用也规定一个子应用，对于复杂的多子应用的划分，尤其是使用广泛的unix类后台应用，我们原则上以应用部署的操作系统用户作为划分子应用的标准。建议应用系统不要以操作系统的超级用户部署，将超级用户留给系统运维。我们在实际工作中发现少数以超级用户部署的应用系统,实际并不需要这么高的权限。

譬如:某管理系统部署了3台生产服务器和3台相应的备份服务器,其中1台serv1创建了workA和workB 两个操作系统生产用户,2个生产用户中都部署了一系列的相关服务, 另外2个(serv2,serv3)是双机负载均衡或者双活,即部署了相同的服务程序(双活模式可能有少量设置不同),都只创建了workC操作系统用户,则我们可以将该应用创建3个子应用,即子应用:workA,workB和workC, 其中workA和workB都关联同一个服务器serv1, workC关联2个服务器serv2和serv3.至于备份服务器，可以附加到相应的生产子应用中，也可以新建3个备份子应用关联，2种模式都各有优劣。将备份服务器独立划分子应用更便于实际使用，因为很多情况下不能与生产服务器同步修改或者备份服务器本身就会自动同步。

如果存在特别复杂的应用系统只有一个生产用户，我们也可以不必固守该模式，将应用按功能类别切分为多个子应用，以便于管理。

【Q2】 不同业务部署不同服务器，业务和服务器之间的对应关系如何管理？

这是一个很常见的现实问题。业务与服务器之间应该有应用系统，不同业务部署不同服务器这确实是个问题，如果业务部署比较分明并很关注，可通过创建不同子应用分别管理控制，如果是双活模式或多服务器负载均衡模式，只个别应用不同且关注度不高，可在应用或子应用说明中写清楚作辅助信息即可。

zjwy82 系统架构师 , bank 也针对此问题作了经验分享。

个人经验，我们在做应用自动化时对应用系统中业务服务部署组件做了抽象建模，建立一个应用系统组件模型，每个组件绑定一组服务器（一个或多个）。组件划分基于运维操作一致性选择，同一组件下的服务器所实施操作相同。

同一个服务器部署多个业务服务的，多个组件可以分别绑定同一个服务器。

以此来达到差异环境的上层组件和脚本公用。

实际上，上述子应用与组件划分控制管理思路大同小异，都是为了更好地一致地管理好应用系统的业务与服务器之间多对多的复杂关系问题。同时也说明了该思路是很有效的实现方式。

【Q3】 目前自动化运维可落地的主要功能有哪些?巡检、版本部署、OS补丁外有哪些?

自动化运维实质上只是平台或者概念，是指程序化的运维操作。任何测试验证充分的运维实际上都可落地。目前比较成熟的是系统层面的巡检、补丁安装等通用性强的简单的运维操作。应用层面的运维我们做了一些发版、服务进程检查、文件清理、数据清理等标准化过程的自动化运维，但都要先在各应用系统中先做相应的配置验证。

galaxy1975 系统架构师 , 自动化运维专家:

我们现在已经帮助用户实现的比较成功的自动化运维项目有：

1. 自动化巡检（健康检查、安全检查、合规检查、漏洞检查等）
2. 自动化配置管理（主要是和1相互配合，实现一些基本组件的配置管理
3. 自动化的主机信息管理（CMDB收录）
4. 业务自动发布（可以打通从资源管理一直到应用管理的整个流程，但目前主要实现较为简单的流程，复杂流程暂时不涉及）

总之，从技术上来说，自动化运维在企业中可以说什么都能干，但在企业中应用的时候，很多并不是技术原因，所以，尽可能的减少一个自动化动作流程所涉及到的部门、团队数量。这样项目就相对容易成功。

匿名用户:

可以结合各自实际的运维场景进行不断细化抽象，我们在部署、巡检、文件清理等场景以外还实现了运维工具自动化，联动服务请求、事件报警等ITIL流程，实现一些日常运维工作的非直接负责人实施操作.

【Q4】 如何管理业务之间的上下游依赖？

业务之间的上下游依赖，应该属于管理信息范畴或者CMDB关系，对自动化运维无实质操作，可用作辅助信息或帮助信息。譬如作为业务的分类树型显示。

zjwy82 系统架构师 , bank:

业务上下游依赖关系主要体现为交易服务间调用关系，可以定义为应用系统的配置管理。在自动化部署等实现中作用不大，对于应用系统的故障影响分析、变更风险评估、自动化业务验证等等场景会有很多帮助。

【Q5】 面对应用与应用之间复杂的依赖和调用关系，如何快速定位排查问题？

在自动化运维中或相关的CMDB中可定义业务应用以及应用之间的关联，出现问题时通过查询相关业务应用，再依次查询相关应用日志和应用记录。应用日志最好做个统一的应用日志管理分析系统，可做更强大专业的日志分析。

【Q6】 难点&痛点：如何实现自动化运维中CMDB的有效性（或者实时更新）？

CMDB如果独立建，更新准时正确问题确实难以解决。建议与自动化运维平台、数据中心监控系统之类合并建设作为其中的组成部分，更好把握和使用。

zjwy82 系统架构师 , bank:

CMDB是一个大课题，涵盖范围广泛，我理解为IT资产管理。在自动化运维初级阶段更多的关注运维对象关键属性信息，重点是要实现自动化运维中多用到的配置信息“有用、准确、及时”。有用是指会被用上，如IP、操作系统用户等；准确是指配置项归属与实际生产环境一致；及时是指生产环境发生变化能尽快更新。

【Q7】 自动化运维运行结果如何更准确灵活地监控和判断？

运维脚本或程序是不可能完全准确地反馈的，那么自动化运维运行结果如何更准确灵活地监控和判断？

我们一般对运行结果是基于返回码或者回显信息，对于经过充分验证考虑充分的程序，运行结果是可以准确反馈运行结果的。然而实际工作中，很可以存在未考虑周到的情况或者返回错误码不是致命错误，应当作为成功情况或者本来应该是错误结果，但是因为未返回错误码或者未考虑到的错误信息当作了成功结果。因此对于一般性的巡检等自动化脚本，我们可以按常规保存结果，但是同时应当保存运行日志，以便事后检查。对于日常维护等一次性的业务人工交互式运维，我们的做法是将运行信息显示，人工判断正确否。譬如：创建一个目录，完备的做法是判断该目录存在否，不存在则创建，如果脚本是直接创建，则在已存在时，是会返回错误的值，实际我们应当作为成功情况。

总之，虽然运维脚本或程序是不可能完全准确地反馈的正确运行结果，但是为了自动化运维的正常运作，在不需要人工确认场合中必须假定反馈结果是正确的，但是自动化平台必须做一些记录和监视以便审查。就象我们需要信用我们的业务系统一样,我们必须假定在应用系统能办理业务,但是必须有相应的数据记录和日志。自动化运维平台也可以看作是一种办理特殊业务的应用系统。

galaxy1975 系统架构师 , 自动化运维专家:

1.先说一个动作的验证，例如通过ansible启动一个系统服务，如果系统服务脚本写的比较垃圾，就算是启动失败了，脚本也返回成功，那么ansible就会返回成功。这就叫做脚本的误判。 在自动化运维的实现中，需要尽可能多的验证、修改这样的缺陷脚本，确保动作的返回值是准确的。

如果希望更加准确的去验证，那就验证动作的结果，例如，如果是创建一个文件，那就去检查一下这个文件是否存在了，如果是启动web服务，那就检查80端口是否监听了。

2.再说整个自动化运维动作的大闭环，在运维过程中，通常会提到“开门巡检、变更巡检、上线巡检”这样的话术，当然，有些地方可能叫另一个名次，这个实际上就是通过业务预埋的检查点，测试程序来访问某个特定的URL（或其他手段），来验证业务是否正常，例如通过url访问web服务器，到数据库中取出一个测试数据，这样一个验证过程就验证了web、业务基本逻辑、数据库这几个组件都是OK的。 那么，在相对较大的自动化运维动作执行之后，可以执行这样的“巡检”。

【Q8】 应用启动、版本发布等自动化运行后，如何对结果进行复核？如何判定是否成功？

应用启动、版本发布程序或者脚本，首先必须有最基本的成功失败反馈,我们一般都应该假定反馈是正常的，但是可能存在个别考虑不周或者意外情况。因此跟踪运行结果也非常重要，尤其是需要频繁版本发布的应用系统, 每次情况不一，测试也可能不充分。

复核直观地主要是看运行输出日志和后台日志，其次可查询相关进程或者编写专用检查脚本。我们发版等操作时一般打开两个窗口，一窗口看运行流程状态，一窗口监视运行输出。

zjwy82 系统架构师 , bank:

应用部署是否成功的判断需要分两个层面来判断，一是程序部署后是否正常启动，可以在部署任务后增加一些技术性检查，如服务进程、服务端口、日志信息等的检验检查作为自动化部署的一个必须任务。还有一项是业务服务运行是否正常，可以在部署后增加一些业务模拟交易进行自动化验证，也可以结合实际交易的监控判断，还有一些需要业务配合进行人工验证，这是目前比较难解决的问题。如果具备条件可以与业务协商建立一些模拟账户进行模拟验证，涉及应用系统开发。

galaxy1975 系统架构师 , 自动化运维专家

题主提出这个问题，实际上有些跑题了.

人们对自动化运维最大的反感就是“不知道执行结果如何”， 所以，一个自动化工具或一个自动化运维动作流程在设计的时候，就必须能够构成一个“闭环”。 例如你启动了一个系统服务，那么你的自动化动作流程的结尾就要检查该服务是否成功启动。 这个检查方法有很多，实际上，人肉运维的时候，当发起一个动作后，如何检查执行结果的呢？ 人怎么检查，机器就怎么检查就OK了。

当然，有些人工的检查手段机器无法实现，那么就有2个方向：一个是放弃这个运维动作，一个是寻找到机器可以实现的检查手段。

总之，自动化运维是要实现闭环操作的。 一个大的流程是一个大闭环，在大闭环中，每一个小动作都是一个小闭环。

呵呵，说的挺玄，实际上没那么复杂， 你在编写程序的时候，垃圾代码仅仅会做个操作，但是优秀的代码会尝试捕捉任何异常并进行对应的处理。自动化运维的编程也是如此。

匿名用户:

个人认为，自动化运维平台应提供验证功能：自动化运行后，平台应该对自动化动作的日志进行分析并判断是否成功、对进程进行验证。或者对类似网站等发布进行验证。

---这个实际上有些理想化，由于应用系统和日志的多样性复杂性，自动化运维平台除了做验证接口和规范外，是很难准确地做通用的验证，最多只能做一些定制的专用性的验证，也许将来人工智能技术有助于实现。

【Q9】 怎样利用日志审计或日志系统建设“精准定位”？

精准定位（主要是业务层的监控）：是除错误、警告等问题以外的现象进行展示。例如系统可以使用，但时长出现慢或停服务，而等一会又可以使用的现象。

答：业务日志其实是业务相关的各应用层日志。每个应用系统日志因开发商和开发人员的不同而差异较大，尤其是甲方没有相应的指导性规定情况下。如想快速容易地查看发现问题，最好的是制定全局性的相关规范等指导性日志标准，其次，目前有一些日志管理分析类系系统，可将各应用系统日志统一收集、整理，可更专业地快速综合地查找分析日志达到快速定位问题的目的。

四、自动化运维的选型建设问题

【Q1】 自动化运维平台目前有没有成功的开源实现？有哪些优秀的商业产品可供选择？

secretpower 其它 , 某金融:

每个企业对于自动化的需求是不一样的，建议自己设计运维平台，底层使用轻量级的开源技术实现，前端由专业定制开发即可。目前行业内自动化运维平台基本均采用此类模式。成熟的商业产品复杂程度过高，对厂商依赖程度过高。从配置工具的角度说，目前主流Saltstack、Puppet以及Ansible比较主流，其中Ansible是目前最主流的工具，主要特点是使用简易、学习曲线平滑、无代理、社区资源丰富、模块资源丰富。

galaxy1975 系统架构师 , 自动化运维专家:

anible、puppet、saltstack相当于可编程集成电路，playbook相当于程序，加进去后就能够实现特定的功能。

但我们在运维中通常需要实现具体的运维工作，需要人机交互，也就是我们需要的是一个带输入输出、带闪闪的LED灯、带显示屏的一个板子。

那么，我们就需要自己开发一些界面类的工作，为ansible+playbook加上显示器、键盘等等外设：

【Q2】 自动化运维需要投入的资源有哪些？

现有运维人员缺少自动化运维的经验同时不具备开发的能力，这样在自动化运维的开展中如何才能实现合理的规划及后续的有效管理？

答：正是这样，才应该引入自动化运维，并选择实施丰富的开发公司，引导并促进各项运维工作的规范化标准化操作，降低对运维开发能力和运维技术能手的依赖。至于投入主要是自动化运维平台及其客户化的费用，服务器可采用虚拟机随规模不同投入不同。

【Q3】 集团多地分布式数据中心，如何应用部署自动化运维？

医疗信息化快速发展，医院数据中心也越来越复杂，硬件、应用、业务系统、数据库的多样性，对于医院信息科自行运维愈发吃力，因此如何通过云自动化运维系统，来帮助医院解决运维难题，将所有医院数据中心集中到一个自动化运维平台中心，24小时集中监控医院软硬件运行状态、统一运维调度管理？是一个值得研究讨论的话题。

答：问题的标题与内容有些缺节。自动化运维与监控不是完全相同概念。

自动化运维可将应用的服务器按地点设置子应用，在子应用属性中设置地点属性或者直接利用服务器属性的地点信息，这样，就可按地点部署和管理各服务器，也可较好地管理应用。注:同子应用下的服务器可看作是相似的或者负载均衡式的服务器，可批量做相同的运维操作，譬如巡检、更新应用等。

zjwy82 系统架构师 , bank:

这个话题比较大，涉及到基础环境复杂度、多数据中心协同、监控和自动化调度。数据中心是否归属同一单位，各单位间的互相数据安全、网络安全要求是否对等。现有运维是否已相应工具，云运维是升级现有工具还是新建一套云运维平台对问题的解决都有不同的影响。下面尝试以新建云运维平台的思路来做个分享。

首先需要关注的是多数据中心协同问题，如果各数据中心的网络架构是统一规划的那么进行集中式的监控、调度就具备基本条件。反之则需要考虑各中心之间的网络联通与数据交互问题。

以数据中心间网络互通为基础，对监控、自动化调度做简单的描述：

1、需要建立一个相对自动化的配置管理系统/模块，将业务系统、服务器、数据库、中间件等的基本信息进行统一管理。基本-主要是为自动化、监控的基本功能模块提供基础环境信息，如服务器的IP、操作系统类型与版本、中间件类型与版本、数据库类型与版本等。与其所属数据中心信息做关联。
2、对每个数据中心管理对象结合配置信息建立业务系统为单位的运维对象模型，根据实际需要进行CI项扩展。
3、部署相应监控模块，定义各类基础环境所需的基本监控策略，对同类型运维对象进行基本数据采集与监控。个性化对业务属性相关数据进行采集与监控。
4、部署相应自动化调度模块，围绕业务系统建立自动化的调度任务管理与实施。
5、建立相应严格的数据访问控制、自动化访问控制及安全策略。

galaxy1975 系统架构师 , 自动化运维专家:

“小轻快”是当前运维环节的实现目标，如题主所构想的构建一个“分级、跨地域、跨数据中心”的集中运维平台，可以赚很多钱，但未必能用起来！

我之前曾经提出过一个想法，叫做“代码既运维”，各地数据中心采用同样的运维平台，共享一套（或者由总部下发）运维代码（例如ansible的playbook），可以很好的实现各地运维的自主性和灵活性。

当然，如果各地分公司没有运维团队，那就当我上面的话没说：）

最后，题主所提到的“监控”，这个算是监控平台，分级监控平台已经很成熟了，就不放在自动化运维中讨论了，监管控， 自动化运维狭义上只负责管和控。

从项目实现角度来说，先寻找试点，在某个医院数据中心实现一套简单、可靠、好用的运维系统，然后全集团推广，推广后如果有必要，可以在构建一个集中管理平台，将需要管理的信息上收，例如变更记录、动作日志等，最后，如果再有必要，可以在集中平台上开放权限，实现对分中心平台的管控。

【Q4】 如何实现在window环境下更便捷的部署和更稳当的自动化环境，是否有可推荐的软硬件产品？

自动化运维环境目前最好的linux环境，虽然大多数自动化运维产品都支持包括Windows在内的多种操作系统，但是Windows内置的脚本shell编写复杂脚本很困难。建议安装Python等解释器，以便做统一的复杂脚本部署。

【Q5】 对于应用级自动化运维的建设，是否需要应用系统做相应的改造？

应用级自动化运维的建设，如果以前是图形化鼠标式的人机交互操作需要改为后台命令脚本化且脚本内无输入交互的操作外，不用对应用系统作其他改变，其实，这也是所有自动化运维建设的要求。这点在自动化发版功能上表现最为明显也最复杂，为此我们制定了一整套的发版规范和相应的辅助工具，除了一些应用系统自带图形交互式上版设置且公司支持有限外，其余都很顺利地较简单地改造完成。发版等运维操作不外乎三件事：修改文件、修改数据和执行命令。只要规范指导做好这三件事就行。

zjwy82 系统架构师 , bank:

自动化建设在传统行业中一般都是人工运维出现痛点情况下引入，这时候都有了很多的资产包袱（存量应用系统）。应用级自动化建设中建议梳理建立一些场景抽象与多样性的实施方案，适用于不同类型应用，要考虑尽可能减少因自动化而引发应用程序的改造，降低开发对自动化的抵触情绪。可以在业务系统架构改造时提出针对性规范需求（非功能性需求），逐步推动应用系统适应性的改造。