ZTFROM |
| 57448/71810 |
| 作者：一颗平和的心 |
| 活动 |
| 事件的接受和记录：发现并报告事件，同时生成一个事件记录； |
| 分类和初步支持：根据事件的类型、状态、影响度、紧急度、优先级、SLA等来对其进行编码。可由先向用户提供建议来解决或处理问题，哪怕这些建议仅仅是临时性的。 |
| 如果呼叫是关于服务请求的，则启动与处理服务请求有关的程序 |
| 匹配：检查一下事件是否是已知的，或是可能与某一现存事件、问题或已知错误有关的，看看是否有解决方案solution或应急措施workaround。 |
| 调查和诊断：如果不存在已知的解决方案则需要对事件进行调查 |
| 解决和恢复：一旦找到了解决方案，问题便能得到解决 |
| 终止：询问用户对问题的解决过程和结果是否满意，如果满意的话，将事件终止。 |
| 进展监控与跟踪：监控整个事件生命周期，如果评估事件不能及时得到解决或以当前的专业级别无法解决，则进行事件升级。 |
|
| 接收和记录 |
| 在大多数情况下事件会由服务台进行记录。所有的事件都应被迅速记录下来，原因如下： |
| 记录以前堆积下来的工作通常并不能做到面面俱到 |
| 只有记录事件才能监控事件的发展 |
| 已有的事件记录有助于对新发生的事件进行诊断 |
| 问题管理可通过对事件的记录来发现问题的原因 |
| 如果所有的来电呼叫都被记录下来，那么对某一事件的影响度的判断会容易一些 |
| 如果没有事件记录，那么将不能监控协商好的服务级别是否得到满足 |
| 及时地对事件进行记录可以避免在解决问题是出现几个人同时解决同样的问题，或在对某一事件的处理过程中什么工作都没有做等情形。 |
| 在什么地方发现事件，决定了谁将报告这个事件。对事件的发现可有以下几种方式。 |
| 由某一用户发现：用户将此事件报告给服务台 |
| 由系统发现：当得到一个应用基础设施或技术基础设施方面的事件，如突破某个关键的临界值时，就将其在事件记录系统中登记为一个事件，并在必要的时候将其转交由某个支持小组处理 |
| 由服务台发现：该服务台人员确保将事件记录下来 |
| 由其他ＩＴ部门的人发现：该人在事件记录系统中记录下事件或将其报告给服务台 |
| 要避免对同一事件进行重复记录的情况出现。因此，在记录某一事件时需要进行一项检查来确定是否已有相似的记录。 |
| 如果有（而且是关于同一时间的记录）：则应该更新事件信息或将事件单独记录后将其关联到主事件记录；如果必要，可对其影响度和优先级进行一些修正，同时加上一些事件的发现者相关的信息。 |
| 如果没有：则增加一条新的事件记录 |
| 尽管第一种情况比第二种情况简单的多，但在两种情况下记录事件的方法是不同的。 |
| 分配一个事件的索引号：大多数情况下系统会自动分配一个惟一的事件索引序号。通常，在后续沟通过程中用户可使用通过提供的查询序号来引用事件。 |
| 记录基本的诊断信息：时间、症状、用户、处理问题的人、地点以及受影响的服务或硬件信息。 |
| 附加事件信息：包括与事件相关的其他信息（例如一个脚本或交流过程记录）或配置管理数据库中的一些信息（通常以数据库中定义的关系为基础） |
| 警告：如果存在一个具有高影响度的事件，例如某台关键服务器的瘫痪，则应警告其他用户和管理部门。 |
转播
分享
淘帖
()
