企业自动化运维巡检管理方案Word文档格式.docx
《企业自动化运维巡检管理方案Word文档格式.docx》由会员分享，可在线阅读，更多相关《企业自动化运维巡检管理方案Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。
3.系统巡检
4.敏捷部署
5.批量变更
6.自动化应急响应
需求列出来了，那么，是否企业中能够使用自动化运维来实现所有的这些应用呢？
貌似还不是那么一回事儿，举个例子：
批量变更，这是自动化运维的一个功能点，但是，目前传统企业中，所有的变更是要遵从“变更管理”的，所以，很多变更只能“一个应用一个应用”的变更，那么感觉上的“批量”，就变成了“小批量”甚至是“微批量”，那么，自动化运维在批量变更上的引入，是否不仅没有降低作业工作量，反而增加了管理复杂度了呢？
2自动化运维出错后的风险控制问题
以我行实际案例为例，自动化运维确实可以给运维人员带来方便，减轻工作量。
但自动运维有一个致命的缺点：
操作透明、运维程序出错后容易导致不可逆的生产故障。
自动化运维，我们简单来说，有3大类操作：
规范遵从、部署、操作变更。
部署实际上不会有你所说的风险问题，因为系统还没有上线。
规范遵从、操作变更都会产生风险，那么如何降低风险：
1.遵从变更流程，即便用了自动化运维，也只能在变更窗口进行变更，不能突破企业的变更流程。
2.变更推送，管理员控制变更的动作，而不是系统自己处理，这就是puppet里面说的pull还是push。
3.用了自动化运维，实际上就算是DevOps了，那么你的一个变更动作，要先测试的，puppet中的测试环境，就是干这个用的，先测好，然后小规模变更，然后大规模批量变更。
换句话说，就是要“半自动“，而不是互联网那种”全自动“
从运维实际出发，其实运维从诞生到发展至今都是为了提供业务稳定，高效的运行，而使用自动化与人工的差别是一种批量化处理大规模性问题与精细化处理对口故障，国外优秀成功的案例就是分而治之，我想用在中国也是很合适的。
1.自动化运维机制的制定，针对专业系统制定专业方案，提供相应的运维制度
2.人员配备上，将复杂问题简单化，系统问题，专业化，各司其职，互相配合
3.开发对口的专业运维系统，将具体的故障问题可视化，故障发生做到事出有源，事后可控。
4.强化专业知识技能，面对大规模性事件，做好模拟响应，这个很重要，我们在实验室就是模拟各种灾难...
3适合中小银行使用的自动化运维产品
想找到一款适合中小银行使用的应用级别的自动化运维产品主要实现自动巡检系统信息采集新系统上线前合规性检查程序自动部署生产系统与灾备系统间应用版本比对等功能（chaozi84北京银行系统运维工程师）
现在可以使用的工具很多，最常用的就是puppet和ansible，在一些银行中都有相关案例。
puppet比较适合做状态保持类的工作，建行用的就是puppet
ansible适合做一次性批量工作
但是，我有一些建议：
1.银行中的“批量”工作实际上并没有那么多，这个是受限于银行的变更流程，所以
2.puppet+mco也可以实现批量的命令执行，但是，在进行批量命令执行的时候，要注意黑白名单的问题，避免误操作导致大批系统的故障，目前这些工具还不怎么提供黑白名单的功能，这个需要自行开发
我在客户现场使用的foreman+puppet+mcollective，然后自己按照客户需求做了定制的界面和定制的功能，包括一些基于安全的风险防范。
提问者（追问）：
请问这两种产品哪个更适合应用系统层面的自动化运维？
我们的需求很明确：
1、系统安全策略等的合规检查
2、设备管理：
可以通过抓取各种版本信息的方式来代替传统设备管理方式
3、已上线的系统可以定期做安全策略检查
4、自动巡检
5、自动化上线部署
6、多数据中心间的应用程序版本比对
puppet足矣
“多数据中心间的应用程序版本比对”，这个用自动化工具原生实现不太好做，我脑子里还么有特别成熟的方案，因为这个“对比”，要去构建对比关系，这是一个额外的信息，维护起来可能会比较麻烦。
nitkeyECT系统架构师：
你说的这些需求我感觉上面上面任何一个软件都可以满足，但都需要自己根据需求去编写脚本，软件本身是不会集成这些个性功能的。
多数据中心应用对比不是重点比较侧重上文中的1、2和4其中自动巡检、设备信息和软件版本比较重要不知道您提到的puppet产品是否适合这类运维管理需求主要前期想解决应用层面的人工巡检和大量设备的软硬件版本维护工作。
就应用层面的巡检我想问一下该产品是怎么解决不同应用系统的个性化需求因为应用层面的巡检不像操作系统那样有规可循可能千人千面不同的应用系统巡检方法也不一样难道需要逐个去定制巡检脚本？
这个问题是怎么解决的谢谢
主机信息管理应该可以搞定你说的设备信息和软件版本问题。
巡检也可以。
这两个在我之前项目中都是用puppet的fact机制来实现的，很多工具都有类似的机制。
应用的巡检，这个比较麻烦，因为就像自动化生产线一样，产量太低的时候，生产线的投入都收不回来，今天早上看书，说集装箱刚刚使用的时候，做集装箱运输的公司赔得一塌糊涂，连集装箱之父公司都抗不下去黄掉了。
自动化运维也是一样的，这就是我们所说的“纳管”问题，进行纳管的对象，必须数量足够多。
前段时间，跟一个朋友讨论一个mongo集群的puppet实现，后来才发现只有一个集群，4个节点，我说：
大哥，你写个脚本装吧，别放到puppet里了....
不过，哪位大哥说，老子有的是钱，你干不干？
你们猜什么结果？
。
我屈服了！
4企业是否要制定Linux标准化规范，这些规范都包含哪些内容？
企业制定统一的Linux标准化规范，是非常有必要的，会带来以下几方面好处：
＊有利于标准化的建立，Linux作为分布式系统或集群中的基本os单元，其标准化的程度决定了整个分布式系统的标准化程度；
＊便利于自动化，标准化是自动化的基础，只有统一的标准化基础设施，才有可能实现高度自动化和运维智能化；
＊便于运维效率提高，经过标准化后的linux系统，运维不再构建于人，更多的是自动化工具和运维规范及流程。
常见的Linux系统规范主要从以下几个方面开展：
1，硬件规划级别：
＊磁盘分区及挂载标准，比如只能使用uuid进行挂载，必须写入／etc／fstab；
磁盘挂载参数；
＊网络配置标准，比如网卡配置标准，网卡bonding标准
2，系统级标准：
＊主机名配置标准
＊基本配置标准：
dns配置标准，端口划分标准，swap配置标准
＊基本内核参数配置标准：
文件系统参数，内存flush配置，网络配置参数标准
＊系统级服务配置标准：
ssh标准配置，mysql等标准配置
＊安全防护配置：
apparmor配置，pam配置，security配置等
3，应用级别
＊应用相关系统级参数：
文件打开数，core参数配置等
＊应用部署路径规划：
应用数据路径、日志路径、函数库路径等
＊日志切分配置
＊应用级资源划分标准：
比如端口分配等
目前企业的系统建设大多基于X86+Linux平台，实际上，在之前的小机时代，规范的建设是很成熟的，只是这几年Linux的快速发展，我们在企业中欠了一些债务需要尽快偿还
Linux规范主要包含以下几方面内容，实际上和一楼的内容差不多：
1.部署规范
主要是分区、初始软件包，这地方实际上主要是一个分区规范，要针对物理机、虚拟机分别指定不同的分区规范，然后操作系统采用最小化安装即可，把其他的内容放到配置阶段实现
2.OS基础规范
主要指定和OS系统相关的，主要包括安装的软件包、开启和关闭的服务、网络的配置、主机名、时区等
3.OS安全规范
安全规范是企业比较关注的，主要分为：
账户安全设置（密码规范、密码复杂度、密码有效期、密码更改策略、禁用账户），服务安全设置（开启的每一个服务，例如ftp、ssh都要有针对性的设置安全内容），登录安全（登录超时退出、登录锁定），系统账户设置（root账户、管理员账户、巡检账户、密码管理账户、应用账户），网络安全设置，内核安全设置，审计的配置
4.OS优化规范
Linux的基本配置没有考虑到现在NB的硬件平台，所以，设置都是很弱的，所以，要设定一个基础的优化设置，主要包括：
网络优化、内核优化、tuned的配置、打开文件数、打开进程数
5.业务软件规范
业务软件规范分为2个层面，一个是归系统部门管的，包括软件的部署目录、软件的数据目录、软件登录账户、软件启停脚本。
另一个是归软件部门管得，主要是日志规范，包括日志的内容和分割，日志的业务规范（例如业务交易ID、信息内容）
需要注意的有几点：
1.这些规范，可能会涉及到2个部门，所以，要根据部门职责来分布实现规范，不可作为一个规范统一实施，避免部门之间的沟通成本。
2.还是沟通的问题，规范制定后，最好是能够和开发、测试一同过会，这样才能有效的在整个软件流程中进行规范的推广。
5传统行业面对开源自动化运维软件，如何进行取舍？
传统企业特别是IOE型信息架构的传统企业，都有IOE等大厂商提供的成熟的监控软件，如IBM的Tivoli等，但相比于现如今种类繁多的开源监控软件，他们在系统的监控深度上面还是具有一定优势，而我认为这种优势体现在各大厂商监控程序与各自设备的兼容性较好、公司的信息安全制度、运维人员对原监控软件的熟悉程度等，既然要讨论将自动化运维应用到传统行业，那么势必会面对的问题就是，如何处理原监控体系和对自动化运维体系的选型（qq373793057交通银行系统工程师）
1.还是那句话，不是技术推动项目，而是需求推动项目，所以，不要吧眼光盯在技术上，而是盯在自己单位有没有响应的需求，如何实现这些需求。
很多时候，需求的实现，只有30%取决于人员对技术的掌握，主要是运维理念，就像一个产品，最重要的是产品思路。
2.别太把开源当回事儿，开源仅仅是一种软件的开发方式而已，针对我们企业来说，开源带来的好处只有2个：
1）更低的成本，2）更大的灵活性。
实际上每一个开源软件，基本上都有对标的商用软件。
现在的ansible、puppet什么的，替换的是原来BMC、HP的一堆方案。
再说了技术的东西是可以学习的，不管啥软件，有半年基本上就熟练了，1年就精通了。
关于选型，也不要仅仅从技术角度入手，PHP和JAVA谁是世界上最优秀的语言：
）
主要选型是要考虑整个生态的，你的朋友中会puppet、用puppet的多，你就用puppet。
你的行业中，别人用啥，你也尽可能用啥。
这样的好处有：
1.有些坑别人都趟过了。
2.万一出了事儿好找人3.想挖人也好挖：
我觉得传统行业不像互联网行业一样没有历史包袱，可以一上来就各种开源。
传统行业原有的运维软件和架构往往已经磨合的比较成熟，运行也比较稳定，用开源软件完全替代初始成本也会比较高，我觉得可以互相借鉴，共存。
说到开源的选型，同意@galaxy1975的观点，尽量选用成熟的，业界广泛使用的软件，遇到的坑会少一点，出了问题也好找资源。
我对开源自动化运维软件接触的也是比较少，目前我们自动化运维软件还是在使用BMC，每日对系统做健康性检查，每月对各系统做合规和安全性检查，而对操作系统的网络、CPU.内存；
中间件的健康状态、数据库的负载等的实时监控还是利用Tivoli每隔一段时间进行数据的搜集，然后根据预先设定的阈值进行判断，产生告警仅此而已。
本次讨论的议题2如何实现实时的主机信息管理，想跟各位了解下，大家都是如何在一个统一的平台里面实现对操作系统、中间件、数据库的实时信息监控和管理的？
一句话：
脚本：
）在puppet中，你可以吧你想收集的任何结果，写个脚本（支持shell、python、ruby），这个脚本返回一个Key=Value的KV键值对，后台就会把这个键值对存到数据库里。
关于如何区分各种KV值的意义，比如那些事巡检，那些是数据库信息什么的，这个实现约定，算是自动化运维的“开发约定”。
您说的很对，实际上，这么多年，运维需求并没有太多改变，之前的工具已经实现的不错了，现在的开源，只是提供了一种新的可能。
同时，开源还能满足人”不服管“的心态，因为可以随便折腾，心有多大，你的方案就有多大。
提问者（回复）：
面对监管机构的要求和系统合规性的考虑，对于新的运维模式，在现阶段只能是说从技术上面可以畅想下，理想的落地实现，还是要一段距离。
6.CMDB在企业中是如何实现的，有什么缺点，目前企业要构建什么样的CMDB？
CMDB业内做的最好的应该是HP和BMC了，不少传统企业都实现过了，现在说说缺点：
1.老问题，不够灵活
2.成本高，特别是现在大量的“屌丝”系统（X86+Linux）
3.实施周期长，客户现在都想构建“小而精”的系统
4.以前的CMDB更多面向“管理团队”，而不是“运维团队”
5.信息不实实。
目前我的想法是，企业要构建的CMDB，实际上把它叫成CMDB有些太大了，我平时称为“主机信息管理系统”，和自动化运维平台进行整合，系统安装完成后，就已经纳入到主机信息管理系统中，可以从各个维度搜索查看相对应的主机信息并进行统计。
总体来说，是一个面向“运维”团队的CMDB。
举例：
除了openssl的漏洞，官方给的数据是在6.4一下版本中都有该Bug，那么，以前的CMDB要通过什么样的手段才能Run出来6.4版本以下的系统信息呢，Run出来之后，如何进行统一变更呢？
所以，CMDB也是要和自动化运维平台进行整合，这样，信息才能帮到操作。
我在之前的项目中，通过puppet的fact机制，收集主机信息到数据库中，1.为了运维的方便，所有系统一定纳入到了puppet管理中，所以，不会存在着“不在管理”的系统。
2.按照一定条件，搜索出来的主机可以直接进行自动化运维操作，一站式！
转一个吧，剖析的很透彻：
1.缺乏合理化、整体化的规划
需求不清晰，定义了不合理的配置广度和深度。
在大而全?
还是小而深?
方面犹豫不决：
这种决策机制在项目初期往往耗费了大量时间，但随着新技术的不断涌现，这种方式已经无法适应越来越敏捷的IT环境，我们发现一种相对静态的CMDB模型已经不能满足纳管新IT组件的要求。
如何解决？
用一种更为灵活的CMDB模型扩展机制。
采用了不正确的管控策略：
按照经典ITIL的管控和项目实施机制，配置管理规划，尤其是CMDB模型的规划往往由项目组承担，一旦规划完成后整个模型也就变得很难再进行扩展，应该说这里采用的是一种集中管控的策略。
但在实际IT运维工作中，我们发现对于CMDB使用最多的是各个二线团队，不同团队之间对于CMDB深度和广度的要求，以及管控方式都有较大差别。
基于集中分布式的理念建立CMDB管控体系
2.配置管理人员职责定义不清晰
配置经理、配置管理员、配置Owner之间职责不清晰：
按照ITIL或ISO20000中对于这三类角色的定义往往过于宽泛，没有进一步考虑实际运维人员的运维场景，以及使用的运维工具，导致职责定义和实际做事方式脱节。
结合运维场景、运维工具、流程角色职责，对于各角色的职责进行重定义。
角色职责和岗位的对应不明晰：
在没有ITIL以前，在企业IT部门或数据中心往往找到不到一个现成岗位对于IT配置信息进行集中管理，而是每个人各管一摊。
实施ITIL后，究竟由哪个部门的哪个岗位承担配置经理这一职责往往是最让人伤脑筋的，最后往往是赶鸭子上架。
这种角色定义方式最终导致体系无法运转。
基于集中分布式的理念设定角色和岗位的对应关系
3.配置管理成了IT运维的负担
这其实是CMDB在企业落地所面临的最大挑战，无法充分调动运维人员的积极性，主要体现在：
初始数据收集工作量大：
存量的配置数据往往基数很大，一般配置的量级在5000以上，考虑到云化环境的海量运维场景，这个基数还会更大。
随着分布式应用架构以及微服务架构的兴起，未来一套新应用系统上线引入新的配置项数量也无法简单通过手工输入的方式来完成。
借助自动化手段进行数据采集
单一的自动化配置发现工具只是一种幻想：
如前所说，约从2007年开始，业内引入了自动发现工具用以解决配置数据的初始化问题，但由于这类工具往往由某个厂商提供，导致了配置发现的局限性，企业往往也要付出较大成本。
建立适配多类自动化工具的CMDB架构，将企业现有的脚本、监控工具、自动化工具、云平台都转化为配置数据的提供方。
投产后由于变更频繁，数据无法保证及时准确：
以往企业一般采用变更操作驱动配置修改（人工修改、或自动化发现修改）的方式以确保配置数据的准确性，这种方式往往出现了配置信息的不一致。
建立基于配置基线驱动的IT环境变更（操作）架构，即建立通过配置修改事件触发变更操作的事件响应模型。
对于未来软件定义环境，这种架构是一种必然选择。
如何让人人“乐于”参与：
这里的参与主要体现在二个方面：
1）需要使用与自己相关的配置数据时，CMDB可以立即提供；
2）遇到CMDB无法提供的数据时，IT部门可自行在一定标准和约束下扩展满足本部门运维CMDB模型，支撑部门级的运维场景。
建立小、快、灵的CMDB架构，支撑快速扩展、快速纳管、快速交付数据。
4.配置数据的价值无法呈现
缺乏清晰的场景定义，包括流程价值、监控价值、BSM价值、云价值等：
单一流程驱动CMDB的场景，无法让CMDB中的数据流动起来，随着时间的推移CMDB中的数据就逐渐腐败—不及时也不准确。
同时，CMDB在技术上作为一个“数据库”，要让其中的数据能够流动起来，必须明确与之匹配的运维场景。
场景是用来描述与CMDB中某些配置项交互的一组活动，满足IT部门某一方面的运维管理目标，这一目标可以被度量、跟踪、改进、可视化，与此同时，CMDB的价值也随之呈现。
建立基于场景驱动的CMDB解决方案集合;
缺乏有效、明确的配置数据集成策略：
如前所述，CMDB是一个逻辑上的数据库，其中的数据需要和企业现有IT环境中的多类数据源进行整合，一套行之有效的数据集成策略和ETL（数据抽取、转换、转载）工具也必不可少。
建立数据集成策略，引入ETL。
升级会员 