智能化IT运维管理平台方案建议书

1、智能化 IT 运维管理平台方案建议书1. 企业运维现状与开展趋势随着企业信息化的不断开展，运维人员需要面对越来越复杂的业 务和 越来越多样化的用户需求，不断扩展的应用需要越来越合理的模 式来保障 运维效劳能灵活便捷、平安稳定地持续。某企业从初期的几台效劳器开展到庞大的数据中心， 单靠人工已 经无 法满足在技术、业务、管理等方面的要求，那么标准化、自动化、 架构优 化、过程优化等降低运维效劳本钱的因素越来越被人们所重 视。其中，自动化开始代替人工操作在企业的运维过程中逐渐表达出 来了 强大的优势。运维随着企业业务的开展，自动化作为其重要属性之一已经不仅 仅只 是代替人工操作，更重要的是深层探知和

2、全局分析，关注的是在 当前条件 下如何实现性能与效劳最优化，同时保障投资收益最大化。通过自动化运维能最大限度地在更少的维修时间内实现运维目 标，提 高运维效劳质量。因此 ，对于越来越复杂的运维来说，将人工操作逐渐改变为自动化管理是一个重要开展趋势。2. 企业运维存在的问题与需求某企业初期只有文件共享和邮件效劳等几台效劳器， 运维工作完中心全由人工操作，随着企业的开展，新业务系统不断上线企业、建设了 机房，运维工作还是以人工为主，但是这一阶段增加了网络管理 系统和环 境监控系统，这两个系统在一定程度上减轻了运维的工作 量，根本上实现 了运维的半自动化。企业在开展，运维工作量在不断的增加，企业的运

3、维工作面临以 下的 问题及需要解决：2.1 运维人员的工作效率与工作主动性需要提升在企业运维过程中，只有当故障已经发生并且造成业务影响时才 能发 现和着手处理，这种被动 救火不但使运维人员终日忙碌，也使 运维本身 质量很难提高，导致 IT 部门和业务部门对运维效劳满意度 都不咼。运维人员日常大局部时间和精力是处理一些简单重复的问题，而且由于故障预警机制不完善，往往是故障发生后或报警后才会进行处理，使得运维人员的工作经常是处于被动的状态， 怎样才能在故障发 生前及时 发现并把故障处理掉，使运维工作变被动为主动？2.2 需要建立一套高效的运维机制企业在运维管理过程中缺少自动化的运维管理模式， 没有

4、明确的 运维 人员角色定义和责任划分，使到问题出现后很难快速、准确地找 到根本原 因，无法及时地找到相应的人员进行修复和处理。或者是在问题找到后缺乏流程化的故障处理机制， 而在处理问题 时不 但欠缺标准化的解决方案，也缺乏全面的跟踪记录，企业需要建 立一套高效的运维管理制度为运维工作提供方向和依据。2.3 缺乏高效的运维技术工具随着信息化建设的深入，企业业务系统日趋复杂，各种各样的网 络设 备、效劳器、存储设备、业务系统等让运维人员难以沉着应对， 即使加班 加点地维护、部署、管理也经常会因设备出现故障而导致业 务的中断，严 重影响企业的正常运转。出现这些问题局部原因是企业缺乏事件监控和诊断工具

5、等运维 技术工 具，因为在没有高效的技术工具的支持下故障事件很难得到主 动、快速处 理。3. 业务流程标准化与健全运维管理制度3.1 实现业务流程标准化，为自动化运维打好根底 标准化是自动化运维的根底，想要实现标准化，首先识别各个运 维对象，然后我们日常做的所有运维工作都应该是针对这些对象的运 维。如果运维操作脱离了对象，那就没有任何意义。同样，没有理清 楚对象，运维自然不得章法。例如扩容，首先确定是效劳器的扩容， 还是应用 的扩容，还是其它对象的扩容。你会发现，对象不同，扩容这个场景所实施的动作是完全不一样 的。如果把效劳器的扩容套用到应用的扩容上去， 必然会导致流程错 乱。 同时对于对象理

6、解上的不一致，也会增加无谓的沟通本钱，造成 运维效率 低下。这种情况下的自动化运维不但不能提升效率， 还会越 自动越混乱。器的对像效劳器、交换机、机柜等硬件；识别这些物理对像的属性，效劳 序列号、ip地址、厂商等信息;识别这些对像之间的关系，效劳器所在的机柜、接入哪个交换机 的哪 个接口了等信息。效劳器物理根底设施的标准化如下列图 其它设备的标准 化以此类推：库的表、视图、存储过程的标准化，表的字段名、值，索引等，表和视图之间的关联关系等。第三步是流程标准化，如备份、软件升级、杀毒，新业务上线等流程的标准化，下列图是现在的运维流程:手工操作诊断祝堪升咸川isfr 运行Th、腾本前端运维人扇杳閱

7、手工开启、更蘇工单事件告警(x.升级X手工操作诊断&椽更自动化运维是基于流程化的框架，将事件与 IT流程相关联，一 旦被 监控系统发现性能超标，超过预先配置的阀值或宕机，就会触发 相关事件 以及事先定义好的流程，可自动启动故障响应和恢复机制。自动化工作平台还可帮助运维人员完成日常的重复性工作， 提高 运 维效率，下列图是实现自动化运维的流程图：运维的自动化能够预测故障、在故障发生前能够报警，让运维人 员把 故障消除在发生前，将所产生损失减到最低。由过去的手工执行 转为自动 化操作，从而减少乃至消除运维中的延迟，实现 零延时的运维。3.2建立完整、全面的运维管理制度，为自动化运维的实现保

8、驾护航运维制度的建立包括环境管理、资产管理、介质管理、设备管理、监控管理、管理、系统平安管理、恶意代码防范管理、密码管理、变更管理、备份与恢复管理、平安事件处置，应急预案管理等制度。1. 运维管理制度是衡量运维工作的一把尺子， 完善的管理制度能 有 效的提升运维工作效率，日常工作以管理制度为依据，按规定的要 求和规 定的流程操作既快速又准确；2. 全面的运维管理制度能在问题和故障还没有出现， 没有造成损 失前保障;就被及时的发现，从而问题得到有效的处理，业务连续性得到了3. 运维管理制度为运维工作提供了标准化的解决方案， 使运维人 员在 处理问题时有章可循快速找到问题的根本原因，把问题对业务造

9、 成的损失 降到最低；4. 运维管理制度是为业务效劳的，业务是不断开展的，运维管理 制度 要跟得上业务的不断开展实现管理制度的创新。4. 自动化运维技术路线选型4.1 自动化运维概述自动化运维范围包括安装自动化、部署自动化、监控自动化、发 布自 动化、升级自动化、平安管控自动化、优化自动化、数据备份自 动化等。自动化运维系统包括商用自动化运维系统、开源自动化运维系 统，自 建研发自动化运维系统。商业的运维系统在功能上要全面一些， 效劳支持上能好一些，更 新与 升级有保障，采购本钱较高，对运维人员的技术要求相对较低。开源运维系统更灵活一些，效劳支持需要运维人员自身多投入一 些时 间和精力，更新与

10、升级更个性化一些，相对本钱较低。自建自动 化运维系 统对人员的技术要求最高， 本钱也不低，但是当企业开展到 一定规模后自 建的运维系统才能更适合企业对于自动化运维的要求。4.2 开源运维工具的应用场景与优势1Puppet 是一个开源的软件自动化配置和部署工具，它使用简单 且 功能强大，很多大型 IT 公司均在使用 puppet 对集群中的软件进 行管理和 部署。优缺点分析：优点是 Web 界面生成处理报表、资源清单、实时 节点管理， push 命令可即刻触发变更；缺点是相对其他工具较复杂、 需学习 Puppet 的 DSL 或 Ruby ，安 装 过程缺少错误校验和生成错误报表。2) Salt

11、Stack 是一种全新的根底设施管理方式， 部署轻松，在几分 钟 内可以运行起来，扩展性好，很容易管理上万台效劳器，速度够快， 效劳 器之间秒级通讯。优缺点分析：优点是可以使用简单的配置模块或复杂的脚本，Web 界面可以看到运行和监控的工作状态、事件日志，扩展能力极强； 缺 点是缺少生成深度报告的能力。3) Ansible 是新出现的运维工具是基于 Python 研发的综合了众多 老牌 运维工具的优点实现了批量操作系统配置、批量程序的部署、批 量运行命 令等功能。在进行大规模部署时，手工配置效劳器环境是不现实的， 这时必 须借 助于自动化部署工具。优缺点分析：优点是模块可以用任何语言开发、备管

12、节点不需要 安装 代理软件、有 Web 管理界面、安装运行简单；缺点是对 windows 备管节点需要加强、执行效率相对较低。下列图是 Puppet 、 Saltstack Ansible 这三款运维工具处理能力与处 理效率的比照：各种运维工具只是用于帮助人员进行运维的，每种工具都有其使 用的优势领域， Puppet 适用于软件自动化配置和部署；SaltStack 适用于根底设施管理，在几分钟内可运行起来，很容 易管理 上万台效劳器，速度够快；Ansible 适用于批量操作系统配置、 批量程序的部署、 批量运行 命令等； 下面是两个常用的开源监控系统：1) Nagios 是一款免费的开源 IT

13、 根底设施监控系统，其功能强大 , 灵 活性强，能有效监控 Windows 、 Linux 、 VMware 和 Unix 主机 状态，交换 机、路由器等网络设备的网络设置等。一旦主机或效劳状态出现异常时，会发出邮件或报警第一时间通 知 IT 运维人员，在状态恢复后发出正常的邮件或短信通知。优缺点分析：优点是配置灵活、监控工程很多、自动日志滚动、 支持冗余方式主机监控、报警设置多样性。缺点是事件控制台功能较弱、无法查看历史数据、插件易用性不 好。2) Zabbix 是一个基于 WEB 界面的提供分布式系统监视以及网 络监 视功能的企业级的开源解决方案。用于监控网络上的效劳器或效劳以及其他网络设

14、备状态的网络 管理系 统，后台基于 C, 前台由 PHP 编写，可与多种数据库搭配使 用，提供各种 实时报警机制。优缺点分析：优点是企业级开源、功能强大、入门容易、数据可 以图 形的方式呈现、提供多种 API 接口，可定制化开发。缺点是深层次需求开发难度较大、 报警设置复杂、 缺少数据汇总 功能、 数据报表需要二次开发。Nagios 适用于 IT 根底设施的监控系统，其功能强大，灵活性强， 能 有效监控各种操作系统的主机、交换路由设备等；Zabbix 提供分布式系统监视以及网络监视功能，用于监控网络上 的服 务器，效劳以及其他网络设备状态的网络管理系统。以上这五种工具都是开源的，运维人员可以根

15、据企业的规模、业 务需 要、所要实现的运维功能等要求使用多种工具组合，发挥运维与 监控工具 各自的优势。工具的使用需要人工的干预和决策， 工具不能完全代替全部运维 工作。 还需要结合实际业务逻辑和业务场景， 把工具与业务融合到一 起。例如， 按业务要求对工具进行二次开发，更好的发挥运维与监控 工具的优势，提 升运维人员工作效率。4.3 Saltstack 实现效劳器部署的自动化Saltstack 在企业中实现效劳器部署的自动化运维， saltstack 是基于 python 开发的一套 C/S 架构配置管理工具，它的底层使用 zeroMQ pub/sub 方式通信，使用 SSL 证书签发的方式

16、进行认证管理。salt 我们选择了 0.16.0 版，该版中参加了 multi-masterr 特性，在 这 种架构下所有的 minion 将连接到所有配置的 master 上去。当一个 master 出现故障可以使用其余的 master 继续提供效劳， 不会 影响我们的正常使用， saltstack 架构如下列图：Saltstack 在企业中的部署步骤： 1 、确定 saltstack 软件依赖关系 是 否满足要求： saltstack 要求 python 的版本大于 2.6 或小于 3.0 ，还 需要检查以下的库，包括 msgpack-pythor 、 yaml 、 jinja2 、 ma

17、rkupsafe apache-libcloud 、 requests 等。2、安装 master 和 minions : 我这里效劳器的操作系统是 centos 的， 安装命令如下：Wget :/dow nl .no arc h.rpmyum in stall salt-masteryum in stall salt-mi nio n注 : 安装成功，显示 Complete 。3、创立一个 master 效劳的备份节点并复制主 master 节点的 key 到备节点：Master:-saltmaster1.cccxht -saltmaster2.cccxht 默认的 master 的 pri

18、vate key 是在 目录： /etc/salt/pki/master.将该目录下的 master.pem 拷贝到备 master 节点的同一位置，对 master 的 public key 文件 master.pub 做同样的操作，启用备 master节点，在备节点接受 key4、重启 minions: 配置完成后， minion 将会对主 master 禾口备 master 进行核对，并且两个 master 都对 minion 有操作权限。注： minion 可以自动检测失败的 master, 并且尝试重连到一个更快的 master, 将 minion 端的参数master_alive_

19、interval 设置为 true ，即可开启该功能。5、saltstack 状态文件的编写， saltstack 上线后，运维工作从复杂 的重复的效劳器部署和配置工作转移到 saltstack 状态文件的编写和 维护，状态文件的编写要考虑模块化和通用性， 在大批量部署之前要 经过测试，没有问题后再部署，以下是一些经常用到的测试命令：1) 查询网络连接情况一是否能连接到客户端rootce ntos sal t# salt '*' test.p in glocalhost:Trueserver.cccxht :True 2 查询网卡 iprootce ntos /# salt &

20、#39;localhost' n etwork.i nterfaceslocalhost:ethO:hwaddr:08:00:27:59:a9:8dinet:192.168.151.255 -label: ethO-netmask: (3) 查询磁盘空间rootce ntos tmp# salt 'localhost' disk.usagelocalhost: /: 1K-blocks: 28423128 available: 21572236 capacity: 25% filesystem: /dev/mapper/vg_ce ntos-lv_root used:5

21、406132还有很多经常用到的命令在此就不一一列举了， Saltstack 可以实 现 云计算与数据中心架构编排， Saltstack 可以由 zabbix 监控事件调 用。通过 Saltstack 的 salt-cloud 实现对 docker 和 openstack 等云平 台 的支持，配合 saltstack 的 mine 实时发现功能就可以实现各种云 平台业务 自动扩展；Saltstack 可以与 CMDB 相结合实现运维平台化、自动化和智能 化。5?自动化运维方案设计5.1 自动化运维规划图提到自动化运维就不能不说 ITIL, ITIL 即信息技术根底架构库(In formati o

22、n Tech no logy In frastructure Library) ，主要适用于 IT 效劳 管 理( ITSM ) 。ITIL 为企业的 IT 效劳管理实践提供了一个客观、严谨、可量化 的标准和标准ITIL 已经成为了 IT 效劳管理的国际标准，而 CMDB 配置管理数 据 库Con figuration Ma nageme nt Database 那么是实现 ITIL 最重要的 内 容。随着企业的开展，对于运维要求越来越高，使用现有的开源工具已经不能满足企业对于运维的要求， 根据企业业务的开展与对运维的要求建设统一的运维管理平台成为了企业迫切的需求。自动化运维平台的建设以 IT

23、IL 标准为依据，按照先底层后高层的原那么先建设效劳工具区域的各个运维子系统，各个运维子系统通过 API 的方 式对上层提供效劳，最后不同的业务平台去调用这些效劳接口即可， 运维平台的各个 层面建设要全面符合管理制度的要求。5.2 自动化运维平台模块设计自动化运维平台以 ITIL 标准为依据在此标准上开发的，第一阶 段已 经做到了业务流程的标准化， 现阶段从事件管理子系统开始逐渐 完善各个 子系统，把各种配置当作效劳来看待。CMDB 也可以理解成统一的元数据库，比方说机房信息、效劳 器信 息、人员信息、效劳信息、业务信息以及他们之间的物理和业务 拓扑关系上层的所有系统都应该关联到 CMDB ，

24、以 CMDB 为中心，变更 后的数据信息必须实时反应到 CMDB 中，各个运维子系统才能看到 最新的数据信息，确保其他系统能同步这份变更，以到达统一同步的 目的。 因此把 CMDB 系统当作运维的核心系统来对待，有利于后续各 个系 统之间的互通。以下是局部模块的设计要求：事件管理：负责记录、归类和安排专家处理事故并监督整个处理 过 程直至事故得到解决和终止。事件管理的目的是在尽可能最小地影响客户和用户业务的情况下使 IT 系统恢复到 SLA 效劳级别协议 ( Service-Level Agreement) 所 定义 的效劳级别；问题与日志管理：通过调查和分析 IT 根底架构的薄弱环节、查 明

25、事 故产生的原因，并制定解决事故的方案和防止事故再次发生的措 施，将由 于问题和事故对业务产生的负面影响减小到最低的效劳管理 流程。在问题管理这局部要做好问题处理过程的日志的功能， 对于问题的处理提供查询的功能，可以追踪问题以防止类似问题再次发生。变更管理：在最短的时间窗口内完成根底架构或效劳的变更而对 其 进行控制的效劳管理流程。的可行变更管理的目标是确保在变更实施过程中使用标准的方法和步 骤， 尽快地实施变更， 以将由变更所导致的业务中断对业务的影响减 小到最低 可行性管理：通过分析用户和业务系统的可行性需求并据以优化 和 设计 IT 根底架构的可行性，从而确保以合理的本钱满足不断增长 性需求的管理流程。可行性管理是一个前瞻性的管理流程， 它通过对业务和用户可行 性 需求的定位，使得 IT 效劳的设计建立在真实需求的根底上，从而 防止 IT 效劳运作中采用了过度的可行性级别， 节约了 IT 效劳的运作 本钱。突发事件：分析业