《数据中心运维管理技术白皮书》
第一章：数据中心运维白皮书简介
本章介绍了数据中心发展现状及远景，说明运维白皮书产生的背景、紧迫性、必要性。
第二章：数据中心ITIL运维框架
本章介绍的重要ITIL流程包括：事件管理，问题管理，变更管理，服务请求管理，资产和配置管理，安全管理，服务级别管理，服务持续性管理，容量管理，发布管理，财务管理和可用性管理
ITIL：IT基础架构标准库
国际IT服务管理领域的实施标准
强调基于“以客户为中心，以流程为导向”的IT管理观念，将传统的IT管理活动按照流程的方式重新加以组织，并强调根据客户的业务需求提供质量可靠、成本合理的IT服务。
PPT原则
即受过良好培训的人员（People），通过执行明确定义的、以技术（Techonology）驱动的流程（Process），为它所支持的业务提供高质量的服务。
数据中心事件管理（Incident Management）
一. 事件管理概述
事件管理的目标就是在出现时间时尽可能快地恢复服务的正常运作，避免其造成业务中断，把对业务的负面影响降为最低，以确保服务质量和可用性满足SLA(Service-Level Agreement，服务等级协议)中定义的正常服务级别。为了实现这个目标，事件管理流程必须最佳地利用资源支持业务、开发和维护有效的事件记录，以及设计和应用统一的事件报告方法。
所谓事件是指可能会导致服务中断或服务质量下降的，不属于标准服务的事件。事件不经包括了与软件和硬件有关的错误，还包括服务请求。
事件管理不是找到引起系统异常的根本原因，而是尽快恢复系统业务功能，找到异常根本原因事问题管理流程的目的。
事件管理的主要任务是及时识别并跟踪发生的事件；对事件进行分类并提供初步支持；对事件进行调查分析，识别引发事件的潜在原因；解决事件并恢复服务；跟踪和监督所有事件的解决过程，并随时进行沟通。因此，研究事件管理对解决目前IT运维中存在的服务问题具有重要的意义，事件管理时效性将直接影响整个企业的IT服务质量和整体运营状况。
二. 事件管理的关键点
-
事件记录
事件管理记录详细的事件信息，如事件发生的时间、受事件影响的服务等。在大多数情况下，事件会由服务台进行记录，所有的事件都应该被迅速记录下来。要避免对同一事件进行重复记录的情况出现。因此在记录某一事件时，需要进行一项检查来确定是否已有相似的记录。 -
事件分类
事件分类的目的是为了确定事件的来源以便采取相应行动，尽可能快地恢复用户的正常工作，尽量避免或者减少事件对IT服务质量的影响。一般来说许多事件事重复出现的，因此，当某个事件再次出现时，只需要根据已有的经验和措施采取行动即可。当新的事件出现时，就有一个与其问题和知名错误(知识库)相匹配的过程，如果匹配成功就可直接用已有的方案将其解决，而不需要进一步调查，否则就要继续进行下面提到的其他几个步骤。
三级分类机制：分类、子分类、项目。
可以根据所报告的事件的故障情况，对事件进行分类（为事件指派类型）。根据时间的类型、状态、影响度、紧急度、优先级、SLA等来对其进行编码，由此向用户提供建议来解决或处理问题，哪怕仅仅事临时性的。 -
事件状态定义
事件状态反映了其在整个生命周期的当前状态，有时候值其在工作流中的位置。任何人都应该意识到每个时间的状态以及它所代表的含义。通常情况下，事件状态的例子有：
- 新建
- 已接收
- 已计划
- 已分配/已指派给专业人员
- 激活状态
- 已暂停
- 已解决
- 已终止
-
事件级别定义
在确定事件的类别后，需要确定事件的优先级以确保支持小组对问题予以足够的关注。决定事件级别的要素主要有三个，分别是影响度(Impact)，紧急度(Urgency)和优先处理级(Priority)。
影响度是指所影响的用户或业务数量而言，时间偏离正常服务级别的程度；
紧急度是在解决故障时，对用户或业务来说可接受的耽搁时间；
优先级是根据影响度和紧急度决定了处理事件和问题的先后问题，优先级通常用一个数字来表示，优先级=紧急度x影响度
-
事件诊断处理
经过事件的查明和记录，对事件进行初步诊断后通过技术或管理手段快速恢复。事件管理的咪表首先是快速解决问题，恢复业务的正常运作，而不是寻找问题的跟不愿意。对于未出现过的事件，一线人员无法解决，则启动事件升级，目标依然是快速恢复系统和服务。过程中往往会采用变通的解决方案（Workaround）。对于事件发生的根本原因(root cause）直至问题被彻底解决，不再重复发生，这部分属于问题管理范畴。 -
事件升级机制
对于事件不能在规定的时间内由一线支持小组解决，那么更多的有经验的人员和有高权限的人员将不得不参与进来，这就是升级。它可能发生在事件解决过程的任何时间和任何支持级别。升级分为职能升级和管理升级。
职能升级：需要具有更多时间、专业技能或接入特权（技术机构）的人员来参与事件的解决。这种升级可能会超越部门界限而且可能回包括外部支持者。
管理升级：当经授权的当前级别的机构不足以保证事件能及时、满意的得到解决时，需要更高级别的机构也参与进来。
-
事件关闭
事件解决和恢复服务后，事件到达关闭阶段，这个阶段要跟用户确认事件解决是否成功。在事件解决后，要确保所有的事件信息都得到了更新并准确被记录；同时根据事件产生的根本原因对事件的分类进行调整；对于根本原因未找到的时间确认是否已经转入问题管理。在用户同意事件解决方案和方案执行的最终结果的基础上，该事件可以被关闭。
三. 事件管理关键点的具体实例
1. 数据中心事件的分类
数据中心运维过程中发生的事件种类繁多，我们主要根据故障种类以及事件定级方法，对数据中心事件进行分类。从故障角度划分的事件包括：
供配电系统事件、制冷系统事件、物理环境事件、物理安全事件、监控系统、网络故障、IT系统故障、自然灾害等；
结合事件定级因素，将事件分为一级、二级、三级和四级等不同的等级。有的企业会划分为三级，有的为五级。
| 级别 | 状态描述 |
|---|---|
| 一级事件 | 关键服务中断，影响SLA的大达成 |
| 二级事件 | 关键服务组件出现故障，导致不满足冗余条件或服务水平下降，有潜在影响SLA的可能性 |
| 三级事件 | 非关键服务组件故障，不影响SLA的达成 |
| 四级事件 | 非关键服务的质量下降，造成轻微影响或影响可以忽略 |
2. 数据中心事件的升级
在实际事件升级中，没有统一的强制标准，是由具体的业务和管理要求决定的。
| 三级事件 | 二级事件 | 一级事件 | |
|---|---|---|---|
| 现场工程师 | 5分钟报告现场经理 | 5分钟报告现场经理 | 5分钟报告现场经理 |
| 机房经理/客服经理 | 10分钟报告事件管理经理、客服经理 | 10分钟报告事件管理经理、客服经理 | |
| 事件经理 | 15分钟报告运维总监 | 15分钟报告运维总监 | |
| 运维总监 | 30分钟报告运维总监 | 15分钟报告运维副总裁 | |
| 运维副总裁 | 15分钟报告运维总监 |
| 目标值 | 一级事件 | 二级事件 | 三级事件 | 四级事件 |
|---|---|---|---|---|
| 响应时间（分钟） | 5 | 5 | 15 | 15 |
| 派单时间（分钟） | 10 | 15 | 15 | 15 |
| 接单时间（分钟） | 15 | 60 | 工作时间 | 工作时间 |
| 管理升级时间（分钟） | 5 | 15 | N/A | N/A |
| 技术升级时间（分钟） | 15 | 30 | 12小时 | 24小时 |
| 解决时间（分钟） | N/A | N/A | N/A | N/A |
3.数据中心事件的记录
| 描述___________________________________________ | |
|---|---|
| 事件名称 | 事件的名字 |
| 严重级别 | 事件的严重级别 |
| 优先级 | 事件的优先级级别 |
| 生成时间 | 事件产生的时间 |
| 重复次数 | 事件发生的重复次数 |
| 拥有人 | 事件处理拥有人 |
| 描述 | 事件的描述 |
| 开始时间 | 当前事件开始时间 |
| 结束时间 | 当前事件结束时间 |
| 第一次发生的时间 | 事件第一次发生时间 |
| 最后一次发生的时间 | 事件最后一次发生的时间 |
| 状态 | 当前事件实际状态 |
| 事件ID号 | 事件ID号 |
| 事件显示数 | 事件计数 |
| 计数器名 | 计数器名 |
| 实例名 | 实例名 |
| 事件数据 | 事件数据内容 |
LIFE IS SHORT, YOU NEED PYTHON
while(alive){
eat();
sleep();
code();
repeat();
}
网友评论