事件管理(Incident Management)是一个被动性的任务，也就是减少或消除存在或可能存在于IT服务中的干扰因素给IT服务带来的影响，以确保用户可以尽快恢复自己的正常工作。因此，我们要将事件(Incidents)记录下来并分类，再分配给适当的专业人员去处理；我们也要监控事件的发展；并在事件得到解决之后将其终止。

基本术语

1. 事件

ITIL服务支持参考书中对“事件”的定义如下：
从上述定义可以看出，ITIL扩展了“事件”(Incident)这个概念的内涵，它把服务台接收到的几乎所有呼叫——只要这种呼叫是可记录的和可监控的——都称之为“事件”。
根据上述定义，“事件”不仅包括了与软件和硬件有关的错误，还包括服务请求——因为对两者的处理方法是类似的。换句话说，事件管理流程涉及服务的整个生命周期。
服务请求(Service Requests)也可作为“标准服务(standard services)”：它是根据服务级别协议(SLA，Service Level Agreement)提供的；其提供是根据既定程序进行，而这些程序是经过协商的且具有适当的检查和控制功能；它也应该保存在维护记录的地方，如配置管理数据库(CMDB，Configuration Management DataBase)。

服务请求的例子包括：
● 功能方面的问题或请求
● 状态查询
● 口令重置
● 对批处理活动、恢复以及口令认证的请求
● 数据库的提取
● 要求提供具有一定IT技能或服务的新雇员的请求

一个服务请求可能是要求进行一个标准变更，但是只要它属于“标准服务”的范畴，那么就应当由事件管理而不是变更请求流程进行处理。如果被请求的服务不是事先已经定义好的“标准服务”，并且它将改变IT基础设施的状态，那么我们将据此提交一个变更请求(Request For Change，RFC)。变更请求(RFC)并不由事件管理流程处理，而是由变更管理流程负责对其进行正式的处理。

2. 影响度、紧急度和优先级

当同时处理若干事件时，必须设定优先级。优先级是根据错误对用户和正常业务带来的影响的严重程度来确定的。服务台通过与用户进行协商，并根据服务级别协议(SLA)确定事件的优先级。优先级决定了事件得到处理的先后顺序。当事件被提升至二线(第二层)、三线(第三层)或者更高级别的支持小组时，其优先级的维护及调整仍是在与服务台进行协商后确定的。
当然，每个用户都会认为自己的事件应该有最高的优先级，但是用户的要求通常比较主观。为作出一个客观的评价，可与用户按照以下准则进行协商：
影响度(Impact)—— 影响度指就所影响的用户或业务数量而言，事件偏离正常服务级别的程度。重要事件是指那些对用户团体带来非常严重影响的事件。而有些在时间上极度紧迫的需要解决的事件也应当作重要事件来处理。
紧急度(urgency)—— 紧急度指解决故障时，对用户或业务来说可接受的耽搁时间。
优先级(priority)—— 主要基于紧急度和影响度来决定。而对于具有同样优先级的事件，可按解决他们需花费的精力的多少来安排顺序。例如，对某个影响不大且容易解决的故障，可先于一个影响较大且需要大量精力解决的故障。

3. 升级

如果某一事件不能在规定的时间内由一线支持小组解决，那么更多有经验的人员和有更高权限的人员将不得不参与进来。这就是升级，它可能发生在事件解决过程的任何时间和任何支持级别。
升级分为职能性升级和结构性升级。两者的区别如下：
职能性升级(Functional escalation，又称为水平升级、技术升级)：职能性升级意味着需要具有更多时间、专业技能或访问权限(技术授权)的人员来参与事件的解决。这种升级可能会超越部门界限而且可能会包括外部支持者。
结构性升级(Hierarchical escalation，又称为垂直升级、管理升级)：结构性升级意味着当经授权的当前级别的机构不足以保证事件能及时、满意地得到解决时，需要更高级别的机构参与进来。
事件管理经理对事件管理流程负有全部责任，他的目标是要为满足一个事件的职能性升级的需要做好预备工作，以避免结构性升级的发生。

4. 1线、2线和N线支持

上面我们介绍了事件的流程线路或者说职能性升级。事件的处理流程线路是由所需的专业等级、紧急度和权限等因素决定。1线支持(也称为第1层次支持)通常由服务台来提供；而2线支持则通常由管理部门提供；3线支持则多由软件开发人员和系统结构人员提供；4线支持由供应商提供。公司(组织)越小，则可供升级的级别数就越少。在较大的公司(组织)里，事件管理经理可在相关部门指定故障协调人来支持自己的工作。例如，协调人在整个事件管理过程与处于各线的支持机构之间可充当接口的角色。每一个协调人协调他本身所在的支持团队。

目标

事件管理的目标是要在给用户和公司正常的业务活动带来最小影响的情况下，尽快恢复到SLA中定义的正常服务级别。事件管理需要保留事件的有效记录以便能够权衡并改进处理流程，给其他的服务管理流程提供合适的信息，以及正确报告进展情况。
能带来的好处
对于整个业务来说：
● 更及时地解决事件可减少事件对业务的影响；
● 提高用户的工作效率；
● 独立的、面向用户的事件监控；
● 基于SLA的业务管理信息的可用性。
对IT部门来说：
● 改善监控，对SLA的执行情况可进行更为准确的评测；
● 有用的关于服务质量的管理报告和服务级别协议(SLA)报告；
● 更好地和更有效地使用人力；
● 避免事件和服务请求的丢失或被不正确地记录；
● 更准确的配置管理数据库(CMDB)。因为当根据配置项对事件进行注册时对配置管理数据库(CMDB)的检查是必不可少的；
● 提高用户和顾客的满意度。
而在执行事件管理时的失败可能会导致下面一些负面影响：
● 由于无人负责监控和升级事件，事件可能会无谓地加剧并降低服务的等级，事件得不到解决，用户不断地被迫求助于其他部门；
● 专业人员经常会受到用户打来电话的干扰，这意味着他们将不能正常地完成工作。结果是，几个人可能会同时参与到对同一事件的处理工作上，既浪费时间，又可能会得出相互冲突的解决方案；
● 与用户和服务相关的管理信息的缺乏。
由于以上问题，由业务部门和IT部门耗费的成本会比正常的高出许多。

流程

事件管理活动
事件可能由基础设施的任何一个部分引起，且通常是由用户报告的。事件也可能由组织里的其他业务部门或IT部门发现并且通过已建立起的监控系统来自动跟踪应用事件和技术架构事件。
与其他流程之间的关系
1. 配置管理
配置管理数据库(CMDB)在事件管理中有着重要的地位，因为它定义了资源、服务、用户与服务级别之间的关系。例如，配置管理显示基础设施的某一部分由谁来负责，这样当与该部分有关的事件发生时可以迅速地进行追查。
配置管理数据库(CMDB)还有助于确定合适的应急措施，如转移打印队列，将用户转移到另一台服务器等。在进行事件注册时，配置信息也被关联到了事件记录以提供更好的相关错误信息。在有必要的地方，可以更新基础设施的某一相关部分在配置管理数据库(CMDB)中的状态。
2. 问题管理
问题管理流程需要了解事件记录以便查出任何潜在错误。而问题管理通过提供与特定问题有关的信息、已知错误、应急措施以及当前修补方法等来给事件管理流程提供帮助。
3. 变更管理
可通过实施变更来解决事件，如更换监视器等。变更管理为事件管理提供关于预定变更及其状态的信息。此外，不正确的执行变更或者包含错误的变更也可能引发事件。此时，事件管理也可以为变更管理提供关于这类事件的信息。
4. 服务级别管理
服务级别管理流程对与客户签订的有关将要提供的支持的协议进行监控。事件管理必须熟悉服务级别协议(SLA)以便在与用户进行沟通时可用到这些信息。事件记录可用来生成报告来判断是否真正地提供了规定级别的服务。
5. 可用性管理
为了评估服务的可用性，可用性管理流程需要使用由配置管理流程提供的事件记录和状态监控信息。某一服务可被指定为“不可用(Down)”状态，就像配置管理数据库(CMDB)中的一个配置项一样。这种信息可用于判断一种服务真正的可用性以及服务提供者的响应时间。这种能力要求在事件处理的各个过程(从早期的检查到最后的关闭)记录下时间戳(time-stamping)。
6. 能力管理
能力管理流程关注由于能力(capacity)不足导致的事件，如由缺少磁盘空间或响应时间过长导致的事件。业务经理、系统经理或系统本身可将这些事件告知事件管理流程。

活动

图4-5描述了事件管理流程中的各个步骤。
● 事件的接收和记录：发现并报告事件，同时生成一个事件记录；
● 分类和初步支持：根据事件的类型、状态、影响度、紧急度、优先级、SLA等来对其进行编码。可由此向用户提供建议来解决或处理问题，哪怕这些建议仅仅是临时性的；
● 如果呼叫是关于服务请求的，则启动与处理服务请求有关的程序；
● 匹配：检查一下事件是否是已知的，或是可能与某一现存事件、问题或已知错误有关的，看看是否有解决方案(solution)或应急措施(workaround)；
● 调查和诊断：如果不存在已知的解决方案则需要对事件进行调查；
● 解决与恢复：一旦找到了解决方案，问题便能得到解决；
● 终止：询问用户对问题的解决过程和结果是否满意，如果满意的话，将事件终止；
● 进展监控与跟踪：监控整个事件生命周期，如果估计事件不能及时得到解决或以当前的专业级别无法解决，则进行事件升级。

接收和记录

在大多数情况下事件会由服务台进行记录。所有的事件都应被迅速记录下来，原因如下。
● 记录以前堆积下来的工作通常并不能做到面面俱到；
● 只有记录事件才能监控事件的发展情况；
● 已有的事件记录有助于对新发生的事件进行诊断；
● 问题管理可通过对事件的记录来发现问题的原因；
● 如果所有的来电呼叫都被记录下来，那么对某一事件的影响度的判断会容易一些；
● 如果没有事件记录，那么将不能监控协商好的服务级别是否得到满足；
● 及时地对事件进行记录可以避免在解决问题时出现几个人同时解决同样的问题，或在对某一事件的处理过程中什么工作都没有做等情形。

在什么地方发现事件，决定了谁将报告这个事件。对事件的发现可有以下几种方式。
● 由某一用户发现：用户将此事件报告给服务台；
● 由系统发现：当捕捉到一个应用基础设施或技术基础设施方面的事件，如突破某个关键的临界值时，就将其在事件记录系统中登记为一个事件，并在必要的时候将其转交由某个支持小组处理；
● 由服务台人员发现：该服务台人员确保将事件记录下来；
● 由其他IT部门的人发现：该人在事件记录系统中记录下事件或将其报告给服务台。
要避免对同一事件进行重复记录的情况出现。因此，在记录某一事件时需要进行一项检查来确定是否已有相似的记录。
● 如果有(而且是关于同一事件的记录)：则应该更新事件信息或将事件单独记录后将其关联到主事件记录；如果有必要，可对其影响度和优先级进行一些修正，同时加上一些与事件的发现者相关的信息；
● 如果没有：则增加一条新的事件记录。
尽管第一种情况比第二种情况简单很多，但在两种情况下记录事件的方法是相同的。
● 分配一个事件索引序号：大多数情况下系统会自动分配一个惟一的事件索引序号。通常，在后续沟通过程中用户可使用通过提供的查询序号来引用事件。
● 记录基本的诊断信息：时间、症状、用户、处理问题的人、地点以及受影响的服务或硬件等信息。
● 附加事件信息：包括与事件相关的其他信息(例如一个脚本或交流过程记录)或配置管理数据库中的一些信息(通常以数据库中定义的关系为基础)。
● 警告：如果存在一个具有高影响度的事件，例如某台关键服务器的瘫痪，则应警告其他用户和管理部门。

归类

事件归类的目的是确定事件的种类以便监控和报告。分类的选择越广泛越好。但是，这也需要更高级别的人事委托(commitment)。有些时候会有人试图将几个类别的内容合并到一个单一的表中，这样通常会造成混乱。因此，使用一些简短的列表会更好一些。
在这一节我们将讨论与归类有关的问题。
1. 类别
归类活动的第一步是将事件归入某一类别或某一子类，如按事件发生的可能原因分类或按与事件相关的支持小组进行分类。可参考如下方法进行分类。
● 中央处理器相关：包括接入、系统、应用等的故障；
● 网络相关：包括路由器、集线器、IP地址等的故障；
● 工作站相关：包括显示器、网卡、磁盘驱动器、键盘等的故障；
● 功能和使用相关：服务、能力、可用性、备份、手册等相关故障；
● 组织和程序相关：命令、请求、支持、沟通等；
● 服务请求相关：用户对服务台提出的请求，要求提供支持、交付、信息、建议或文档等。这类事件可以通过一套单独的程序处理，也可以按照与其他事件相同的方式处理。
2. 优先级
在确定事件的类别后，需要确定事件的优先级以确保支持小组对问题予以足够的关注。优先级通常用一个数字来表示。而这个数字通常是根据紧急度(恢复事件的迅速程度)和影响度(如果不及时修复事件，会造成多大的损失)来决定的。
优先级=紧急度×影响度
3. 服务
按照SLA的有关要求，需要用一个列表来标识与事件相关的服务。这个列表同时也提供了按照SLA对相关服务的升级时间。

4. 支持小组
如果服务台不能在事先规定的时间内解决事件，就要决定应该由哪个支持小组来负责处理该事件。这种转移(也被称为职能性升级)通常是按已分配好的事件所属的类别来进行的。如果对各个类别进行了定义，就不得不考虑支持小组的结构问题。
合理的事件处理转移机制对有效的事件管理非常重要。因此，关于事件管理流程质量的关键绩效指标应该是“被恰当转移的事件的数量”。
5. 时间表
以优先级和服务级别协议(SLA)为基础，受影响的用户将会被通知预计解决问题的最长时间(生命周期)，以及什么时候可进行进一步的升级。系统应该记录下这些时间。
6. 事件索引号
告知用户的事件索引号以便其以后根据此索引号来查询事件。
7. 工作流状态
事件状态表明了其在事件工作流中的位置。事件状态的例子有：
● 新建
● 已接收
● 已计划
● 已分配
● 激活状态
● 已暂停
● 已解决
● 已终止


匹配
对事件进行分类之后，要检查以前是否发生过类似的事件。如果发生过，则查看是否存在解决方案和应急措施。如果新事件与某一问题或某一已知错误具有相同症状，那么就可将事件与这些已知的问题或错误进行关联。

调查与诊断
服务台将那些没有快速解决方案或超过他们专业水平的事件安排给具有更高专业水平和技术能力的支持小组。此支持小组将对事件进行调查并尽量加以解决。如不能解决，则将其转交给其他的支持小组。

解决与恢复
成功完成对事件的分析和解决之后，负责解决问题的支持小组在系统中记录下事件的解决方案。对某些解决方案来说，须向变更管理提交一个变更请求(Request For Change, RFC)。在最不理想的情况下，如果没有找到合适的解决办法，那么事件将一直处于待解决(Open)状态。

终止
一旦实施完毕解决方案，支持小组把事件回交给服务台。然后服务台联系事件的报告人以确认事件是否解决好。如果服务台可以确认事件已经得到了很好的解决，那么它就终止该事件；否则事件管理流程需要在适当的地方重新开始处理。
在终止事件的过程中，必须要对事件的记录进行更新以反映事件的最终分类和优先级，受影响的服务、用户和客户，以及导致事件发生的组件(CI)等。

进度跟踪与监控
作为所有事件的拥有者，服务台负责对事件的发展情况进行监控以及通知用户事件的状态。用户在某一状态发生改变后可能会做出适当的反馈，如在预期的事件周期内发生的进一步的事件转交或变更等。在对事件进展进行跟踪和监控时，可能会出现将事件进行职能性升级，转交给其他支持小组来处理，或进行结构性升级，以加强处理事件的力度的情况。

流程控制

流程控制以对不同目标群体的报告为基础。事件经理负责这些报告，同时负责拟定报告接收者清单和报告分发日程表。报告可以非常详细或者按照以下角色定制：
事件经理——报告需要包括：
● 找出处理过程中遗漏的环节；
● 找出与服务级别协议(SLA)有冲突的地方；
● 对事件处理保持跟踪；
● 确定事件的发展趋势。
一线IT管理人员——给支持小组管理人员提供报告以方便他们对各自小组的控制。这类报告需要以下信息：
● 事件解决的进展情况；
● 事件在各个支持小组的周转时间。
服务级别管理人员——提供给这些人员的报告主要包括所提供的服务质量方面的信息。服务级别管理经理需要所有为提供服务级别报告给客户时所需要的信息。提供给客户的报告应该提供在事件管理流程中服务级别协议得到遵守情况的相关信息。
其他服务管理流程的流程经理——对其他流程的经理的报告将主要是提供信息。例如，事件管理应该提供如下事件记录方面的信息：
● 已记录和已报告的事件的数量；
● 已解决的事件的数量，并按照解决时间进行细分；
● 将事件按照不同时期、来自不同客户、由不同支持小组处理以及根据服务级别协议(SLA)对其的处理结果等方式进行分类的情况；
● 按类别和优先级以及支持小组对事件的分类情况。

关键成功因素

成功地进行事件管理需要：
● 一个及时更新的配置管理数据库(CMDB)来帮助评估事件的影响度和紧急度。虽然评估影响度和紧急度所需的信息同样也可从用户那里得到，但是这种方式得到的信息会少一些，而且可能会非常主观，此外收集信息的时间也可能很长；
● 一个知识库(例如一个及时更新的问题数据库或已知错误数据库)来帮助识别事件，以及可用来解决这些事件的既有解决方案和应急措施。知识库中还可以是供应商和其他第三方的数据库；
● 一个适当的自动系统用于记录、跟踪和监控事件；
● 与服务级别管理流程之间的紧密联系以确保合适的优先级和解决时间。

绩效指标

评估流程的绩效需要明确定义目标以及为实现这些目标所设定的可测量的指标。这些指标通常被称为绩效指标。绩效指标由事件经理定期(如每周)报告，以获得一些可据此判断事件发展趋势的历史数据。
事件管理流程的关键绩效指标举例如下：
● 事件的总数；
● 平均解决时间；
● 按优先级计算的平均解决时间；
● 在SLA的目标之内解决的事件所占的百分比；
● 由一线支持解决(不将事件转交)的事件所占的百分比；
● 每个事件的平均支持成本；
● 每个服务台工作站或每个服务台员工平均解决的事件数；
● 不需拜访用户就解决的事件数；
● 初步分类正确的事件数量(或所占的比例)；
● 正确转交的事件数量(或所占的比例)。

职责和角色
流程的执行涉及公司的多项职能或多个部门，故只有当与流程的各项活动相关的责任和权限被清晰地描述，它才可能成功运作。从灵活性的角度考虑，利用基于角色的方法可能会比较合适。当公司规模较小或为降低成本时，可将多个角色合并。例如，许多公司将变更管理和配置管理的角色合并。

1. 事件经理
事件经理负责以下事项：
● 监控事件处理流程的效率和效果；
● 控制支持小组的工作；
● 为改进工作提供建议；
● 开发并维护事件管理系统；
在许多公司里，事件经理的角色被指派给了服务台经理。
2. 支持小组人员
一线支持小组负责记录、分类、匹配、转交、解决(除指派给其他支持小组之外的)和终止事件。
其他的支持小组主要参与调查、诊断和恢复工作。这取决于对事件设定的优先级。

成本和可能产生的问题

成本

与事件管理相关的成本包括初始执行成本(如对流程和过程的定义以及相互间的沟通)、培训和指导人员(客户和支持人员)成本，以及选择和购买支持流程的工具的成本等。对工具的选择可能相当耗费时间。另外，还有与人事和工具使用相关的成本。这些成本在很大程度上取决于事件管理的结构、活动范围和责任，以及与该流程有关的场所的数量等。

可能产生的问题

对事件管理的导入和执行可能会受到以下问题的影响：
● 用户和IT人员故意避开事件管理程序—— 如果用户不经过一系列的处理过程而是自己解决错误或者直接联系一些专业人员帮助他来解决，那么与此事件相关的一些信息可能就不会完整，而这些信息对问题管理、配置管理的成功实施非常重要。此外，IT部门也不会得到服务级别以及错误数量等信息，这会导致管理报告不能充分地反映当前情况。
● 事件处理超载和堆积—— 如果事件的数量过多，就可能出现一种还没有来得及对每个事件进行有效的记录，下一个事件又来了的情况。这将导致不能清楚地描述事件，同时也可能导致不能成功地对事件进行分配和转交。因而对解决事件就会变得事倍功半。因此，适当具有某些技能和能力以及资源是必要的。此外，单单强调从头到尾的“通路”也能导致下游工作流的问题。
● 升级—— 如果事件不能得到及时解决或者需要更高层次的专业资源才能解决，就会进行事件升级。过多的升级可能会打乱专业技术人员的正常工作而产生负面影响。
● 定义和协议不清晰—— 如果支持的服务和产品以及支持的级别在服务目录里没有清楚的定义或者没有符合服务级别协议(SLA，Service Level Agreements)、运作级别协议(OLA，Operational Level Agreements)以及支持合同(UC，Underpinning Contracts)，那么事件管理将很难达到客户和用户所期望的要求。
● 缺少管理层的承诺(commitment)—— 用基于流程的方法解决事件需要管理层和工作人员的一致共识。因为，如果在一个公司内部导入这种方法需要对现在的工作方法做重大改变，那么可能会在公司内部受到严重的抵制。

● 服务和质量——主要论述由客户组织体验到的质量和用户体验到的质量之间的关系，以及由IT服务提供者进行的质量管理。
● 组织和政策——主要涉及一些概念，如愿景(vision)、目标(objectives)和政策(policies)等，同时讨论诸如规划、公司文化以及人力资源管理等方面的问题。还探讨了一个公司的业务流程和IT活动之间的协调问题。
● 流程管理——主要论及IT服务管理流程的控制


我们在商店购买产品之前，通常会对其质量诸如外观、用途、耐用性等方面进行评估。这时，客户很难有机会对产品的质量进行把关，因为产品是在工厂里生产的。通过有效地控制工厂生产流程，制造商试图提供一种持续的质量。在这个例子里，产品的制造商、销售商和消费者是完全分离的。

然而，服务的交付则是在与客户的互动过程中进行的。服务不能事先得到评估，而只能在其交付的过程中进行。服务的质量在一定程度上取决于服务提供者和客户互动的方式。相对于产品制造过程而言，客户和提供者还是能够在服务提供过程中作出某些变更的。客户对服务的体验以及服务提供者对其所提供的服务的评价在很大程度上都取决于他们个人的经验和期望。

在服务提供过程中，客户的体验是非常重要的。客户通常会通过下列问题去评估服务的质量：
● 服务满足期望了吗？
● 我在下一次得到同样的服务吗？
● 服务是以合理的成本提供的吗？
服务是否实现了客户的期望(expectations)主要取决于如何以有效的方式与客户就所提供的服务项目达成一致意见，而不是取决于服务提供者提供了多好的服务。
与客户进行持续的沟通(continuing dialogue)对于提升服务质量和确保客户以及服务提供者都清楚彼此对服务的期望是非常重要的。在一家餐馆里，服务员总是首先向客人介绍菜单，并且在端上一道菜时询问客人是否对前面的菜肴表示满意。在整个进餐的过程中，服务员积极地协调了供应和需求之间的关系。客户得到这样的体验有助于改善将来的客户关系。

质量保证

提供产品或服务需要进行一些活动。而产品或服务的质量又在很大程度上取决于这些活动被组织起来的方式。
● 计划(Plan)——做什么，何时做，谁来做，怎样做以及用什么来做？
● 实施(Do)——计划的活动得到实施。
● 检查(Check)——确定活动是否达到了预期的效果。
● 改进(Act)——根据检查中收集的信息对计划进行调整。
有效而及时的调整意味着活动应当被分解为一个个的流程，并且针对每个流程都制定具体的计划和确定检查的时机。应当明确的是，谁负责组织这些活动，他们拥有多大的权限来修改计划和活动的规程，这些计划和规程不仅仅是针对每一项活动，同时也包括每一个流程。

质量管理(Quality Management)是在提供服务的组织中工作的每一位员工的职责。每一位员工必须清楚，他们对组织的贡献会对他们同事的工作质量产生什么样的影响，以及最终会对组织作为一个整体所提供的服务产生何种影响。质量管理同时也意味着要持续地寻找改进组织的机会和实施质量改进活动。
质量保证(Quality Assurance)是组织内部的一个政策(policy)。它是指被组织用来确保其所提供的服务能够持续地满足客户的期望及相关协议的一整套措施(measures)和规程(procedures)。质量保证可以确保由质量管理所产生的质量改进能够得以维持。
质量体系(Quality System)是与职责、规程和实施质量管理所需的资源相关的组织架构。ISO 9000系列标准通常被用来开发、定义、评估和改进质量体系。

组织和政策

愿景、目标和政策

组织是人们进行合作的一种形式。任何组织，从一个标枪俱乐部到一家跨国公司，其存在都建立在这样的理念之上，即为什么值得在这样一个组织内进行合作。其愿景(vision)可能是你希望通过销售个人电脑(PC)赚更多的钱。然而，为了吸引所有利益相关者(如客户、投资者、职员)的合作，你的组织必须向他们传达为什么他们应该和你合作。这样，你可能倾向于描绘一幅可行的关于未来的愿景，并且提出诸如“让事情变得更好”或“绝不会让你独行”之类的口号。为了传达其愿景，组织可以通过使命说明(Mission Statement)来加以定义。使命说明是关于组织目标及其信仰价值的一个简单而清晰的描述。
组织的目标(Objectives)更为详细地描述了组织希望完成的具体任务。一个定义良好的目标应当包括5个基本的要素(SMART)：具体(Specific)、可度量(Measurable)、适当(Appropriate)、现实(Realistic)以及具有明确的时间范围(Time-bound)。
组织的政策(Policy)是用来定义和实现组织目标的所有决策和手段的总和。在政策中，组织应当为各种目标排定优先级，并确定如何实现这些目标。 当然，这种优先级也会随着时间而发生变化，这取决于具体的环境。所有的利益相关者越是清楚组织的政策，对职员们应该如何开展他们的工作进行具体定义的必要性就越低。没有详细的操作规程，职员们一样可以独立地运用政策作为其工作方针。明确表述的政策有助于提高组织的灵活性，因为组织内所有级别的职员都可以针对变化的环境迅速作出反应。

通过具体的活动来实施政策需要进行规划(Planning)。计划通常被分解成多个阶段，并提出若干个里程碑，这样就可以对进度进行监控。例如，可根据政策来制定一个年度计划，然后再据此拟订年度预算。根据年度计划可以制定更为详细的部门计划、季度计划或项目计划。每个这样的计划都包含下列一些要素：活动安排，所需资源以及就所要提供的产品或服务的质量和数量达成的一致意见。

实现计划中的活动需要采取行动(Action)。行动被分配给具体的职员或外包给外部组织则称之为任务(Task)。

IT服务管理

IT服务管理(ITSM，IT Service Management)主要是一种最初被称之为IT管理的以流程和服务为中心的管理方法。凡是流程都应当有其既定的目标。IT服务管理流程的目标就是要改进IT服务的质量。质量管理和流程控制构成了组织及其政策的一部分。在运用以流程为中心的方法时，我们同样需要考虑组织的实际情况(如政策、文化、规模等)。ITIL，作为最广为人知的IT服务管理方法，并没有规定其适用的组织的具体类型，而是描述了流程内各种活动之间的关系，这与任何组织都是相关的。它为组织之间交流经验提供了一个框架。该方法还为学习动态型组织的经验提供了框架。

ITIL对客户/用户的效益：
● IT服务的提供变得更加以客户为中心，同时在服务质量上的协商一致会改进双方的关系。
● 服务内容可以以客户的语言和更为恰当的详细程度得到更好的描述。
● 可以对服务质量、可用性、可靠性和服务成本进行更好的管理。
● 通过对联系点的协商一致改进与IT部门的沟通。

ITIL对IT部门的效益：
● IT部门会形成一个更为明晰的架构，从而变得更有效率和更为关注公司目标。
● 更加有利于IT部门对其负责的基础设施和服务实施控制，同时变更也变得更易于管理。
● 一个有效的流程架构为有效地外包某些IT服务提供一个框架。
● 遵循ITIL最佳实践可以促进文化变革从而有助于服务质量的改进，还可以对采纳基于ISO 9000系列标准或BS 15000的质量管理体系提供支持。
● ITIL为内部沟通和外部供应商沟通，以及程序的标准化和识别提供一个一致的参考框架。

应用ITIL过程中可能产生的问题和错误：
● ITIL的引进需要花费很长的时间和很大的努力，并且需要组织进行文化变革。一个过于激进的引进方案可能遭到挫败，因为其目标不可能实现。
● 如果将完善流程结构变成一个孤立的目标，服务质量也可能会受到负面的影响。在这种情况下，不必要的或巧于设计的程序也可能被视为官僚性(bureaucratic)的障碍，如有可能，这种情况应当尽量避免。
● 由于对相关流程应当产生的结果、恰当的绩效指标和怎样对流程进行控制缺乏基本的了解，无法对IT服务实施改进。
● 由于没有可作为比较参照的基线数据和(或)确立了错误的目标，在服务质量和成本降低方面的改进不是很明显。
● 一项成功的实施需要组织内各层次人员的参与和承诺。只有专家部门参与流程结构的开发可能使该部门在组织中受到孤立，从而其设定的方向不能被其他部门所接受。
● 如果在适当的培训和支持工具方面缺乏足够的投资，流程可能不会产生应有的作用，从而服务无法得到改进。如果组织实施了过多的IT服务管理活动而又不是使用“最佳实践”，则可能在短期内需要更多额外的资源和人力。

客户和用户如何获得恰当的服务来支持他们的活动和业务，以及这些服务怎样得到支持
● 服务台(Service Desk)
● 事件管理(Incident Management)
● 问题管理(Problem Management)
● 配置管理(Configuration Management)
● 变更管理(Change Management)
● 发布管理(Release Management)

1.服务台
服务台是用户与IT部门的单一联系点。在ITIL以前版本的书籍中，它被称为帮助台(Help Desk)。帮助台最大的任务就是记录、解决和监控IT服务运作过程中发生的问题。而服务台则具有更宽的职责范围(如接受变更请求RFC，Requests For Change)，它可以实施属于其他多个流程的活动。它是用户与IT服务提供者的首次联系点。
2.事件管理
对事件(Incident)和问题(Problem)加以区分可能是ITIL对IT服务管理领域所作的最广为人知但往往不一定最受欢迎的一项贡献。尽管这种区分有时候会令人觉得很迷惑，但它有一个最大的优点在于，它可以区分快速恢复服务以及确认事件产生原因并加以补救之间的区别。
事件管理的首要目标是要解决事件并尽快恢复服务的供应。事件被记录下来，并且这种记录的质量能够影响其他多个流程运作的有效性。
3.问题管理
如果怀疑在IT基础设施中出现了一个问题，则问题管理的目标就是要查明该问题产生的潜在原因。由于事件的发生，可以怀疑可能存在某个问题。但是显然的是，该流程的目标是要在可能的情况下主动地防止故障的发生。
一旦问题产生的原因已经查明并已制定出相关的应急措施，则该问题就归类为已知错误(Known Error)，并且需要从业务上决定是否需要进行一次永久性的修改以防止同样的事件再次发生。作出修改的流程是通过一项变更请求(RFC)触发的。如果从业务上认为没有必要作出修改，但已确认了临时性的应急措施或永久性的解决方案，则该问题仍然被归类为已知错误。
4. 配置管理
配置管理主要是关于对不断变化的IT基础设施进行控制(标准化和状态监控)，识别基础设施内所有重要的组件，收集、记录和管理有关这些组件的信息，以及为所有其他的流程提供有关这些组件的信息的流程。
5. 变更管理
变更管理讨论有关对IT基础设施实施变更所进行的审批和控制。该流程的目标是，通过对变更进行评估，从而确保能够在对IT服务产生最小负面影响的情况下实施这些变更，同时通过在组织内进行有效的协商和沟通，确保所有的变更都具有可追溯性。变更是在与配置管理的状态监控活动、变更请求的发起人、问题管理以及其他多个流程进行协调后得到实施的。变更的实施需要遵循定义、规划、构建、测试、验收、实施和评估这样一个特定的路径。
6. 发布管理
一项发布是指经过测试并导入实际运作环境的一组配置项(CI’s，Configuration Items)。发布管理最主要的目标是确保发布首次被导入实际运作环境取得成功，包括整合、测试和存储。发布管理需要确保只有那些经过测试和授权的正确的软件版本和硬件才能供应给IT基础设施。发布管理与配置管理和变更管理活动具有密切的联系，实际的变更实施一般是通过发布管理活动来执行的。

有时需要对用户的输入作一些必要的检测，如限制输入的长度和类型等。下面举例要求用户必须输
入六个数字，如果输入有非数字字符，或者长度不等于六个，就提示错误信息。脚本源码如下:

小结
Shell的用法还远不止这些，Shell命令、Shell编程都是Linux用户应该掌握的基础知识。用户在熟悉了Shell的基本命令和语法结构后，根据需要、善加运用就可让Shell焕发无穷魅力，为工作和学习带来无限乐趣。

在Linux下，用户如果想删除文件中的空行，一般使用“grep”，这里给出另外的几种方式：
1.使用“cat”命令，示例如下：
2.使用“sed”命令，示例如下：
3.使用“awk”工具，示例如下：

在Linux中, Shell命令“watch”的作用是以全屏方式重复地执行指定的命令。用户可以通过它
了解命令的运行情况。例如用户如果想实时观察内存变化，那么可以输入如下命令:
这样就可以动态地观察内存中各个指标在某段时间内的变化情况了。
如果用户要观察虚拟内存的变化, 而不想耽误当前终端的操作，那么可以通过打开另外一个终端达
到这个目的。命令如下:
这样就会弹出一个终端串口显示有关虚拟内存的情况。

前段时间配置的iptables+squid做的proxy server，一直工作正常。今天我上控制台上发现

IP_conntrack表示连接跟踪数据库(conntrack database)，代表NAT机器跟踪连接的数目，
连接跟踪表能容纳多少记录是被一个变量控制的，它可由内核中的ip- sysctl函数设置。每一个跟踪
连接表会占用350字节的内核存储空间，时间一长就会把默认的空间填满，那么默认空间是多少？我以
redhat为例在内存为64MB的机器上是4096，内存为128MB是 8192,内存为256MB是16376，那么
就能在/proc/sys/net/ipv4/ip_conntrack_max里查看、设置。
例如：增加到81920，可以用以下命令:
那样设置是不会保存的，要重启后保存，可以在/etc/sysctl.conf中加：
按照此方法改变后一切正常，要是再满了可以加大该值

关闭网卡：
然后改地址：
然后启动网卡: