随着IT技术的快速发展，IT系统的运维复杂度不断增加，IT部门的体量不断扩大，传统的人工操作和借助管理流程的方式已不能满足日益增长的运维工作量。而智能时代的到来，无论是DevOps的思想还是AIOps思想，自动化就像人的“手”一样，决定着最终这些技术思想的是否能够落地，决定着未来一个IT运维的生产力。

在7月6日的线上交流活动中，围绕着企业自动化运维的架构设计，方案选型等进行了问题的讨论，也得到了各位专家的支持，大家针对自动化运维的相关问题体现出了非常大的热情，在此也对相关问题及大家的观点总结如下：

一、自动化运维的范围

典型问题：

Q1：
一般定义的自动化运维的范围是什么呢？业界一直在提智能运维，自动化运维，作为客户来讲，到底哪些设备，哪些工作可以实现自动化，自动化运维的边界是否有呢？通过对运维体系的边界的界定，可以初步判断实现自动化运维的ROI。

问题解答：

A1：
自动化运维是相对于之前的手动运维来定义的，目前自动化可以完成的工作有很多，比如：
1.虚拟机的分配，操作系统的安装；
2.基础软件的安装部署，如数据库中间件等；
3.应用程序的发布与部署；
4.日常巡检类。
还有更多的工作可以依靠自动化或智能化来完成，比如故障预测、告警自愈等，这些需要引入机器学习和人工智能等技术，也是未来AIOps的发展趋势。

A2：
自动化运维是概念定义，互联网自动化运维包括自动化发布，自动化部署，自动化业务注册等，如果开发还在传统业务包方式没有到微服务方式，自动化运维多是自动化脚本运维加一个portal页面加一个开源并发组件完成运维操作，面对未来无服务serverless的运维等都有长远的步伐，这些定义看你自己如何定义了，ai运维目前多是日志挖掘和负载均衡算法的优化。

二、自动化建设方向与实施路径

典型问题：

Q1：
一个传统系统，如果想实现运维自动化，最好从哪里先开始？从哪里入手，需要先做哪些工作？
Q2：
自动化运维建设建议分几个阶段完成？
Q3：
当前IT基础架构设备多样，自动化运维如何建设？
Q4：
自动化运维的实施路径？整个运维可以从上往下看，也可以从下往上看，请问一下这两种实施路径有何种建议？两者的优劣对比有吗？
Q5：
传统企业如何落地自动化运维？

问题解答：

A1：
从自身需求出发，从最繁琐最没有价值重复性最高的工作出发，这些就是你的需求。考虑选择一些技术来实现最基本的自动化，或者称为脚本化，不管是使用shell还是python还是ansible这些技术。在有了最基本的自动化能力后，可以考虑自动化平台的建设，自动化平台的建设就需要从“监”、“管”、“控”的层面去考虑你的需求。而在自动化建设的过程中，你会发现企业内部的标准化和自动化是相辅相成的，有了标准化才能自动化，自动化又会逼迫你不断的进行标准化。推进自动化的过程，也要求企业不断的提升自身的标准化程度。

A2：
个人认为，想要实现自动化，第一步先要将日常的运维工作做成脚本化，从而实现调用脚本来进行日常运维。之后再逐步搭建自动化运维平台，从前台页面进行流程编排，调用现有脚本进行自动化运维操作。

A3：
要建立系统的自动化运维，就必须了解系统出现预警/故障的症状、原因和处理办法，这类似于当年要想要证明某个程序是正确的思路，要么建立一个比现有系统更复杂的系统来维护现有系统，要么对现有系统进行形式化分析，推导可能出现的问题和对策。

A4：
借取其他单位及专家经验，一步一步来实现自动化运维落地:
1.脚本化: 先将日常人工作业脚本化，譬如系统安装、软件安装、补丁安装、系统巡检、应用发布等。
2.自动化:将上述脚本用流程串起来，利用好的自动化编排工具 如ansible, HP microfocus OO 等。
3.后续根据运维经验，将监控及事件处理智能化。

A5：
先学习 puppet和ansible，在测试环境做一些简单自动化操作。技术完全掌握后 在进行场景化运维功能开发，测试，完成业务逻辑，上生产完成自动运维场景化操作。

A6：
一般来讲分三个阶段
第一阶段：业务快速发展，服务器大量扩增，运维人员少，系统状态实时监控就无法兼顾，面对上述问题，采用IBM-Tivoli 产品实现自动化监控。
第二阶段，面对业务快速部署需求，采用了IBM PureApplication一体机实现了应用快速部署，采用PowerVC、VMware等技术实现了虚机自动发布。
第三阶段，面对大量信息系统配置变更影响需求，开始实现CMDB自动采集功能。只是列举一部分，自动化运维这条路是永无止境，需着技术发展，自动化运维将是越来越普及的。

A7：
要从企业自身需求出发，特别是要从应用场景出发明确自身需求。然后根据其各类设备的特点考虑使用不同的技术实现局部的自动化，比如X86可以考虑Cobbler实现裸机安装、使用SHELL、Ansible实现操作系统自动化、Oracle使用OEM的相关功能等等，最后将其集成到自己的自动化平台之中。

A8：
快速交付可以将企业自身的流程与自动化功能进行集成，服务请求和变更流程导向至后端的快速部署后进行交付，如果需要部署应用可以对接企业自身的版本控制系统进行快速部署，如果在持续集成中已经使用jekins也可以与jekins的管道进程集成。当然最佳的快速部署应用系统应该考虑PaaS+Docker的方式，速度更快，编排更加方便。

A9：
自动化是个比较大的话题，如果要落地个人以为一定要从企业自身需求出发，或者说从应用场景出发来建设自动化运维平台比较好，这样的收益比较明显，自动化运维平台要有集成的能力，而底层技术应该根据不同的设备、不同的平台进行选择。

A10：
手工运维——脚本化——自动化——智能化，这应该是运维的大致方向。
所以想要实现自动化，可以现将平时手工操作规范成脚本，之后建设脚本调度平台，这也就形成了自动化平台的雏形。之后再将脚本调度封装成服务，用户只需要调用对应的服务即可，无需关心是由什么脚本来完成的工作。

三、自动化运维架构设计及方案的选择

典型问题：

Q1：
自动化运维方案的选择？选择开源的工具还是商业的工具，分别有哪些优势？
Q2：
搭建运维自动化平台框架如何设计，需要掌握哪些知识点，重点注意事项有哪些？

问题解答：

A1：
个人推荐采用开源方式，或者说核心技术采用开源技术。采用商业软件的好处是比较容易达成需求，不利的地方也显而易见，主要是产品成本比较高，特别是后期维护的成本更高，且核心技术并不掌握在企业自身手上，项目容易成功，但长久来看自动化工作难以持续。开源方式，成本相对较低，技术能够掌握在自身手中，选择也比较自由，但对于疑难杂症的解决能力要看企业自身的技术能力，对开源的研究程度。

A2：
目前成熟的开源产品已经可以满足大部分自动化运维场景，如果团队有能力，建议使用开源产品，并且研究源码进行定制和改进，做到自主可控。
外购产品对厂商依赖比较大，而且成本也比较高，但是相对来说稳定，但厂商水平也参次不齐，选择时也要注意。

A3：
简单的自动化运维框架可以分为前端展示和后台工具，后台工具可选用开源组件或公司产品，这个可以根据自身情况进行选择，目前成熟的开源产品可以满足大部分场景，可以直接拿来使用。前端展示层面可进行自助研发或外包。

四、自动化工具的选择

典型问题：

Q1：
自动化运维平台底层工具选型？
Q2：
如何选择合适的自动化运维产品？当前，许多企业单位it基础架构复杂，采用的厂商产品不同，系统平台繁多，数据库类型又很多，这种情况下采用自动化运维能大大提高工作效率，但自动化产品选择应从那几个方面考虑？
Q3：
贵行的自动化运维平台调用虚拟化技术api,为什么不集成云管平台？相对于云管平台，优势在那里？

问题解答：

A1：
目前来看，主流的集中开源产品都能满足大部分自动化运维场景，所以可以直接拿来使用。
但是，所有技术都是有其生命周期的，现在最新的技术过几年也许就会落后了，社区也不能保证一直很高的活跃度。所以在使用开源产品的同时，建议研究其核心原理与源码，做到自主可控。

A2：
ansible、salt和puppet主要是操作系统或平台层的编排工具，这3个工具的选择的建议要根据企业实际情况而定，如果安全上对ssh没有特殊限制的、企业运维的服务器数量也不是很多的建议使用ansible。ansible学习曲线平滑，使用简单，社区资源丰富。性能相对salt和puppet较差，可以根据企业实际情况选择。

A3：
我们选择的是底层技术依据系统平台选择，开源操作系统和数据库采用开源技术，商业操作系统和数据库采用厂商产品提供的技术和功能，自动化平台采用集成方式达成业务功能需求。当然，对于繁多的系统平台和数据库类型这个问题企业自身应该考虑选型以减少其数量，或者在规划上应该考虑减少其数量，以减少成本和运维工作难度。

A4：
主要取决于企业自身的实际情况，个人的理解云管平台和自动化平台的定义并不是非0即1的关系，云管更适合在多云环境中使用。当然也可以将一些自动化的工作集成在云管中去。而虚拟服务器的下发的方法有很多种，可以借用IaaS云的API、也可以借用IaaS云的命令、也可以借助类似于第三方编配工具类似Ansible。是直接集成云管还是集成IaaS取决于企业对私有云、公有云以及自动化的需求和规划。

A5：
Ansible可以作为OpenStack的自动化编排工具，通过Ansible控制OpenStack的 Controller 节点，通过 Ansible 的内置模块os_server、os_volume 等模块实现在OpenStack 平台上管理 instance 和存储。

五、自动化平台的安全与审计问题

典型问题：

Q1：
企业自动化运维应用安全难点：如何在运用过程控制和方法不容忽视，特别是在测试和应急回退层面应严格把控？
Q2：
企业自动化运维架构设计难点：如何将“监”、“管”、“控”有效的结合在一起？

问题解答：

A1：
企业发展自动化应该首先要抱着一种敬畏的态度，特别是传统企业不能过于激进。在自动化的运用中，应该建立开发、测试、投产的控制流程和体系，如果是自主开发运维应该建立版本控制系统，将代码集中统一控制，摒弃代码随意修改的恶习。要将不管是脚本还是程序都当成代码进行管理，在整个过程中应该至少有代码Review、版本控制、测试和发布的控制。这样至少可以保证代码的充分测试和版本的正确性。测试要考虑环境的一致性、功能的测试，特别是无害性的测试，最重要的不是实现自动化的功能，而是确保现有的生产环境不收影响。而在自动化的投入过程中，可以考虑根据其本身自动化操作的风险做一些区别对待，先对一些低风险的操作实现自动化，比如信息的收集和发现、比如基础环境的搭建，再对一些高风险的操作实现自动化，比如批量的变更等等。

A2：
首先自动化解决了标准化和批量执行的问题，提高了运维效率，同时也可能因此造成大范围的生成事件。如何保证预期目标和执行结果的一致性，避免操作的失误和破坏性的运维行为，从以下几个方面进行把控：
a.制度控制：比如双人复核，二次授权等。
b.流程控制：比如流程审批，将测试、准生产、生产的全流程打通，保证执行动作和执行内容的一致性。
c.审计控制：比如操作记录，黑名单、白名单等。
d.代码控制：比如代码的版本管理、发布检测、场景化封装等等。

A3：
自动化运维平台的设计十分重要，很多操作都封装成流程执行，对外暴露的信息较少，所以需要对操作进行记录，主要包括以下几个方面：
1.记录用户操作日志，做到有据可查，满足“监”的要求。
2.合理设计审批流程，对于重要流程和命令操作进行审核，满足“管”的要求。
3.做好系统权限的设计，不同岗位角色具有不同权限，各司其职，满足“控”的要求。

A4：
监、管、控，一定要紧密的联系在一起，首先要建立好一个有效的管理制度或者机制，明确责任单位和责任人，对各种情况做好预案，严格执行。
架构的范围太大了，在设计之初可能会有所不足，一定要考虑预留网络入口（物理）可以不接，但要有，操作权限要有分级，后台记录要完备，包括安全的鼠标或键盘记录，定期的系统日志、安全记录导出及清除。
自动化系统是孤网存在的，要做好定期控制器、交换机、服务器的排查，定期对硬盘做好备份工作，为日后可能成为IDC做准备，这是日后的方向。
公司全范围的vlan一定要有规划做好地址池的划分，出现问题一定不能影响全局，并做好备份机制。
各种程序的改写一定好做好记录，主要是时间、修改人员、目的及过程。

A5：
监督要去完善的双人授权认证，管理有完善的日志记录，支持所有系统管理，控制场景操作为固定流程参数化，用户只能使用固定的流程进行操作完成业务上线等操作而不能随意操作目标设备。

A6：
监是监控，是对告警事件的发现和通知机制。管是管理，就是告警事件发生后如何进行管理应对，处理告警事件。控是控制，就是对于处理过的告警事件如何进行有效的管控，避免此类问题再发生。那么这就需要一个流程依托于一个平台来进行实现。关联起来就是一个告警事件的全生命周期。

A7：
主要就是在设计和建设系统阶段，将组织、制度、流程、操作、数据进行打通，各个工具系统都有各自的基因和侧重点，需要有一个全局视角才具备监管控一体化的前提。

六、自主开发问题

典型问题：

Q1：
如何解决企业自动化运维自主开发运维难点？每个企业都会考虑在自动化层面尽量发挥自身员工的能力，一方面能够做到自主可控，另一方面做到可以激励员工。自动化的话题非常大，在实际推进中，要结合员工实际能力来确定自动化自主开发运维的界限问题。这个应该如何做？

问题解答：

A1：
关于自主开发运维，个人以为要考虑企业的规模，企业对于自主研发的现状和态度。如果在自动化运维上选择了开源的方式，应该至少考虑开展自主开发运维的方式。如果将代码分为前端和后端的话，企业自身应该考虑将后端代码纳入到自主开发运维的范畴之内，后端代码更加与实际的运维技术需求相接近，而前端代码更接近专业开发，如果企业有完全自主开发的需求应该考虑由专业开发团队或是研发出身的人员来完成这些工作。运维出身的员工如果要兼顾前后端开发的难度是非常困难的。

A2：
自动化平台可分为前端页面和后台自动化工具，目前工具层有很多开源组件可以选择，也算比较成熟，多关注开源社区，如果有能力可以研究组件的源码，做到自主可控。前端页面建议自行研发，如果外包也建议掌握核心功能的架构与实现方式。

A3：
首先，对每个控制系统的了解程度不同，是导致能否解决问题的关键。
界限问题就是如何划分，开发和运维本身就是不同的性质，运维相对更简单一些，能够做好日常故障判断就可以了，大问题还是要通过开发、厂家、供应商解决的。
开发就不同了，从工艺了解、系统的选型，搭建、安装、配置、通讯、编程、试运行。。。。。等等一切的问题全部解决和完成，这是开发应具备的能力。

A4：
前端代码考虑到用户体验易用性等因素比较适合由专业的前端开发人员来实现，后端开发由运维人员根据自身的运维需求来完成，这样既能让自动化运维的开发自主可控，又能在使用时有更好的体验。

A5：
按照场景化细分每个运维操作，从中总结必须得流程步骤，和开发人员沟通开发需求，完成自动化产品开发和迭代，一个良好的自动化产品必须是自主开发得，外部采购的产品50%功能会水土不服，需要二次自主开发。所有先详细调研所有需求完成场景模式需求调研，再配合自主研发需求才能完成自动化产品的完整功能上线。

A6：
一是运维人员要熟悉系统，二是运维人员要懂一定的开发知识，这样才能听懂开发说的话，才能更好的交流，三是运维必须具备开发能力，这里的开发能力主要是指自动化运维平台开发能力。四是领导层面要重视，要允许容错。

七、自动化与配置管理

典型问题：

Q1：做自动化运维最重要的一步是做好cmdb建设，贵行是如何保障cmdb实时一致性？

Q2:企业自动化运维碎片化配置难点？

问题解答：

A1:
个人以为保证CMDB的一致性有几个方面，一是CMDB的数据范围要以用为目标来进行建设，不用的数据入CMDB会使得成本很高。二是考虑与流程紧耦合，甚至是先有CMDB的更新再有变更执行，服务请求变更流程和自动化的结合也是紧耦合的一种。三是考虑自动化的方式对数据进行发现和扫描，以更新CMDB数据，方式可以很多种，有些数据可以直接刷新、有些数据可以提供差异报表等等。

A2：
存量的问题一定是要分步解决，如果想一蹴而就很可能最终导致项目失败。
建议先针对生产中主推的服务器操作系统版本实现自动化纳管等操作，先解决见效大的问题，在第一步成功后既减少了日常大部分运维的工作量又有了后续继续推进的动力，然后分析剩余服务器的情况，快要下线的系统可以直接等待生命周期结束后淘汰掉，不用费精力去考虑，无下线计划的可根据实际情况分为可升级后实现自动化运维的，列出升级计划，分批逐步进入自动化，对于无法升级的视规模决定是否有必要进行针对性的改造。

A3：
淘汰旧服务器。
由于plc的不同，需要通过一种可以将不同的协议能够全部转换的模块，现在这种方式是各大公司都采用的方案。
上级领导对这种方式很有兴趣，苦于经费问题，硬件问题已经解决了，软件考虑自己做。

A4：
存量服务器是否可进行vm化是关键问题，如果不可以，可等其自然业务下线，可以vm化直接vm为虚拟设备 进行自动化运维管理。

A5：
建设企业的cmdb,cmdb建设过程中会发现这些隐藏问题并且在cmdb中记录和落地，后续所有信息都记录在cmdb中统一管理。