企业运维系统建立初探(1)(2)
2014-08-18 01:23
导读：（4）变更管理 保证清楚的了解变更针对一个服务中任何组件的影响, 并保证对服务水平的影响最小， 变更管理包括SLA文档和服务目录的变更, 以及组织变
（4）变更管理
保证清楚的了解变更针对一个服务中任何组件的影响, 并保证对服务水平的影响最小， 变更管理包括SLA文档和服务目录的变更, 以及组织变更和针对软件和硬件的变更。
（5）故障管理
故障管理的主要目标是尽可能快地恢复服务至服务级别协议（SLA）要求的水准，尽可能减少故障对服务运营的不利影响，以确保最好的服务质量和可用性级别。
（四）运维系统的组成
在一般的运维系统中，需要一个大房间，在大房间中分成以下几个部分，每个部分都扮演相应的角色：
第一层：大屏幕分别显示有，基于业务的视图，基于IT基础架构的视图，基于网络的视图，当故障出现时能够以特定的颜色显示出来，同时可以显示一些公司需要直观显示的数据。
第二层：服务台（Help Desk），主要提供：
●接受客户的请求
●提供客户使用上的问题咨询
●提供客户业务咨询
●记录并跟踪故障和客户意见
●根据知识库，尽快解决问题
●及时通知客户其请求的当前状况和最新进展
●根据服务级别协议，初步评估请求，经历解决它们或安排给一线工程师解决
●对客户的故障从提出到验证及终止的整个过程进行管理
●协调一线工程师和值班工程师
第三层：一线支持工程师
●根据提供的监控界面迅速定位问题并解决
●对于临时的解决办法，还要把故障提交给问题处理流程
●根据服务级别，在问题未能及时解决时及时把问题提交给值班经理
第四层：值班经理个人
●协调技术专家，根据服务协议的时间要求，解决问题
●协调供应商，根据维护协议要求，解决问题
大学排名 （五）运维系统的功能设计
基于ITIL设计理念，我们把ECC的实时监控部分设计成层次架构，如下图：
1. 事件采集层
在最基本的层次上，需要从被管理的IT基础设施中获取广泛的，实时的数据,能够从网络、系统和应用层中捕获、汇聚并处理大量数据的能力，我们通常称之为事件管理。
事件管理是整个面向服务管理系统的核心，在数据采集阶段（包括网络、系统和应用层）采集的信息，只有经过事件管理服务器，转变为统一的格式，再流入智能化的管理层，实现事件的相关性分析。
数据采集层是整个管理系统进行信息处理和智能化分析的基础，因此需要充分获得准确、实时、完整的管理数据。在数据采集层，应该进行原始数据的过滤、分类、分级等预处理操作，从中提炼出重要的管理信息。数据采集层获取信息的实时和准确性，以及对原始信息的预处理能力，将在很大程度上影响整个管理系统的管理能力和效率。
2.事件处理层
数据收集仅仅是实现业务和通信及IT基础框架管理的基础，需求最简单的先决条件。实现真正的基础框架智能化意味着能够从整个基础框架产生的大量数据中，通过采用一系列先进的过滤，事件压缩，关联和诊断的技术进行处理，抽取管理人员需要关注的重要信息。好的基础框架监控管理系统能够将网络以至IT系统的专业化知识融入在管理系统中，根据基础框架层各组成资源的特点，从原始的管理数据中智能分析系统的真实状况，判断资源实际的运行状态，分析故障发生的根源并提出解决建议，使运维人员解决问题更加准确和有效。一般包含以下功能：
（1）事件的存储
将运行维护数据与历史数据分开存储, 以确保管理的效率. 一般管理信息需要保留6个月甚至更长的数据, 以进行统计分析和存档, 而在日常运行管理中, 一般只需要查看最近一周甚至更短的信息, 一般采用运行数据与实时数据分开存储, 运行数据采用高速的内存数据库保证事件处理的实时性, 历史数据采用稳定的关系型数据库保证事件存储的可靠性和容量，这种结构使事件的处理更加合理。
（转载自科教范文网http://fw.nseac.com） （2）事件压缩
IT资源事件中有很多重复事件, 尤其在系统组件不稳定时, 有可能会产生事件风暴。过多的事件会使管理员的桌面上罗列大量事件条目，管理员无法获取真正需要关注的重要事件，因此对重复事件进行合并使事件条目清晰， 帮助管理员快速找到需要处理的故障是非常重要的。重复事件压缩就是这样的一个过程: 通过将从下层数据源所报告的相似事件加以汇总,合并成一条事件,该事件的内容包含了该事件重复的次数以及发生的起止时间。
（3）事件自动化处理
可以对各类事件信息进行逻辑判断, 并做出相应的动作, 如及时删除不必要的信息、完成不同事件之间的关联、对严重事件采用明显的声音报警、自动升级警告级别如果严重事件在一段时间内没有人响应、发送邮件进行自动通知等等。
（4）可用性的计算方法
根据故障树分析FTA(Fault Tree Analysis)方法，结合可用性的计算方法，来计算服务的可用性。
组件可用率的计算方法：组件可用率 = (AST-DT)/AST*100%
AST——约定服务时间（Agreed service time）
DT——在约定时间内的实际停机时间（Actual downtime）
（5）可用性的评估指标
通常我们采用下面几个指标来对可用性进行评估：
①平均无故障时间(MTBF-Mean Time Between Falures)，它指的是从某次事故修复到下次事故发生之间的平均间隔时间，又称为正常运营时间（Uptime），它是用来描述服务的可靠性。
②平均修复时间(MTTR-Mean Time To Repair)，它指的是事故发生到服务恢复之间的平均间隔时间，又称为停机时间（Downtime），它是用来描述服务的可维护性和适用性。
3.业务关联层
业务影响分析, 基于CFIA等分析法，定义事件和业务系统的关联关系, 自动找到故障所影响的业务和服务, 并根据关联结果创建新的服务事件报警。
内容来自www.nseac.com
4.呈现层
提供基于Web方式的监控视图, 可以为不同的管理人员提供不同的监控窗口, 以实时监控相关的事件信息, 事件窗口可以通过分组显示不同类型、级别、源、时间段内的事件信息, 管理员可以一目了然的看到目前是否有事件发生, 级别如何, 并对事件进行一系列的处理工作。
5.报表处理层
各种监控信息存储在关系数据库中，可以利用报表工具进行信息统计分析，生成各种格式的报表。
报表应用可以与实时故障监视环境实现无缝集成，为运维提供一种长期的综合视图。报表应用帮助管理人员了解其各种基础设施在各种不同期间的行为特点，从不同设备、系统和服务的层次上对各种基础架构的长期行为特点进行查看和分析。
（六）运维系统的设计要求
1.基于ITIL框架设计, 结构先进
运维系统的设计要求基于ITIL的框架, ITIL的框架是最佳实践的结晶。
2.可扩展性
如果需要一个新的展示层或者事件关联，必须能够无缝扩充或集成到现有的管理框架中。为了保证随着系统架构的延伸扩展而产生的越来越多的事件信息的处理性能，在任意一个层次增加都不会影响整体框架结构。
3.集成性
集成企业现有以及未来可能要扩充的设备和管理系统。如果需要增加新的监控对象，则最多只需简单地增加一个探针，或增加一个新的关联层 。
4.集中化
已经处理的事件(重复压缩和事件关联)集中在一个地方。因此管理员可以共享整个系统的事件信息。
5.关联
因为事件关联功能在整个系统管理中是分布的，因此为一个新服务增加新的事件关联是非常容易的。
6.冗余
数据显示层和关联层的设计将考虑冗余设计，当任何一个服务器失败，数据采集层的探针将会自动切换到另一个服务器。
（科教论文网 Lw.nsEAc.com编辑整理）
综上所述，运维系统的设计，主要从两个方面来实现，一是管理流程的设计，二是系统监控的设计，通过上面的描述，我们看到，系统监控的作用：当系统出现故障时通过对系统各个层面的监控以及事件的关联，能够保证快速定位故障，从而快速解决故障，使得故障对业务的影响降到最小，同时通过对系统性能的监控，进行预警，可以做到防范于未然，防范故障于萌芽状态，保证系统的可用性；而规范的管理流程，保证所有的问题在每一个阶段得到有效的处理。
共2页: 2
论文出处(作者):
