20150924淡然

续上








4.2中期建议

n建立问题管理和变更管理流程，实现IT服务的主动管理，同时实现完善的IT服务级别管理（SLM）；

v问题管理

在近期目标中，我们重点实现了事件管理，如果事件在第一时间没有办法解决，就需要转入问题管理（ProblemManagement）流程，问题管理流程的主要目标：

1)使突发事件和问题对业务所造成的影响减少到最小；ITSS考试

2)较少和避免相关错误的重复发生；

3)提高IT服务质量；

4)减少事件的数量；

5)通过提供已有问题的解决方案，完善知识库，提高一线解决率；

问题管理流程最终完成找到问题发生的根本原因，也只有找到原因，才能根本解决问题，避免同样的问题一而再，再而三的发生。建议将问题管理分成两个部分建设，一个是建设被动问题管理的部分——等事件通报变成了问题，再来分析问题，找出问题发生原因，加以诊断，再提出解决方法及步骤。另一个是建设主动问题管理的部分，分析事件发生趋势，事前先找出可能的潜在问题，主动提出解决方法及步骤，预防问题将来发生。

在问题的被动管理方面，建议包含两个层面上的管理，问题管理（ProblemControl）和错误管理（ErrorControl）。当事件通报到问题管理流层后，进入问题控制阶段，在这个阶段，我们主要诊断并分析问题，当找出问题发生原因时，它就转变成已知错误（KnownError）。找出问题发生的原因后，就可以找出问题的解决方法和方案，必要时提出变更需求（RequestForChange），通过变更流程实现问题的最终解决。

在问题的主动管理建设方面，透过事件的趋势分析及定期检讨事件统计报表，找出未来可能发生的问题。另外产品提供厂商的报告或建议，也会建议一些措施以防范未来可能发生的问题。通过这些主动方法，便可在事件发生之前就找出可能潜在的问题，主动提出解决方法和方案。

很多实际案例显示，通常80%的服务品质下降导因是20%的问题，所以专注于这20%问题的解决，就可以大大的提升服务。

v变更管理

在近期目标实现中建立了配置管理，配置管理的数据库CMDB的维护主要依赖事件管理的某些变通手段，并没有从真正规范意义上去维护CMDB，保障CMDB数据的完整和准确性。变更管理的目标就是确保IT基础架构中所有的变更都能用有效和快速标准的方法和步骤来管理，其目的就是减少或防止变更对业务产生影响或将事件数减少，希望能在变更需求与变更所可能造成的影响两者之间取得平衡，同时，配合配置管理模块保证CMDB数据的准确性。总的看来，建立变更管理的主要意义：

1)IT服务和业务之间更好的整合；

2)改善变更的风险评估；

3)减少由于变更所造成的对IT服务和服务级别协议的负面影响；

4)可以更好的评估计划中的变更所需要的费用；

5)减少失败的变更次数；

6)提高问题管理和可用性管理的效率；

7)提高IT服务的质量；

8)与配置管理形成接口，保证CMDB数据的准确性；ITSS认证

RFC（RequestForChange，变更请求，简称‘RFC’）的提出，表示有人需要在目前的IT基础架构上做变动，那么这样的行为该怎么样规范控制呢？RFC开始先送到变更管理员处，由变更管理员先加以过滤。如果是常规变更，如，新员工帐号建立，即可立即核准；否则，则加以分类，指定优先等级，然后根据类别提到该类的CAB（ChangeAdvisoryBoard，变更咨询委员会，简称”CAB”）等待核准。

CAB审核这些RFC，并根据公司业务需要建议公司接受或拒绝变更。考量因素包括对目前服务的影响、变更的成本、风险等等，最后根据这些因素提出建议。如果该RFC被核准可以执行，就正式通知相关的技术小组来执行这些变更。变更执行之前，变更管理员都应该准备《变更检讨报告》（ChangeReview），作为下次CAB讨论的主题。通常CAB会议的议程会包括失败或测试不成功的变更请求、新的需要审核的变更请求、变更请求执行成功后的后续追踪。一个成功的变更请求如果经过追踪成效良好，最后变更管理员就可以结案该变更请求的整个过程。在所有过程中，变更管理员推动并监督整个过程。

v建立完善的IT服务级别管理(SLM)

通过近期目标的实现，可以通过事件管理和配置管理流程收集客观、准确的事件处理数据：事件分类处理数据、设备发生事件的数据、分类事件平均处理时间、设备有故障时间、设备无故障时间等。

通过对这些数据的深入分析可以建立关键业务的服务级别协议(SLA)，并有相应的服务流程去监视实际服务水平，定期回顾服务状况，找出与服务级别的差距或可改进的领域，从而制定服务改进计划(SIP)，并进行相应跟踪。

在服务级别管理过程中还包含另外关键指标操作等级协议(OLA)。是指两个以上IT实体之间的内部协议，它规定了所有参与方的职责，规定这些参与方要根据双方同意的质量和数量提供某种服务（或服务组件-例如硬件、软件等），同时限制用户对合同中规定并得到双方同意的服务限度提出额外要求。

注意，如果IT支撑部门向某个业务团体承诺的SLA是提供99.9%的服务可用性，则可能需要准备许多OLA才能满足这个承诺。例如，负责网络支持的IT支持小组承诺提供高可用性的网络，支持组织（各级组织）都必须承诺非常具体的响应时间和逐级上报步骤，负责建立和安装服务器的IT实体可能需要承诺安装高可用性的服务器，等等。

许多IT公司都在努力更加面向服务，但它们经常遇到分不清SLA和OLA之间关系的情形。下表通过将两者特点进行比较显示了SLA和OLA之间的一些内在差别。

服务等级协议(SLA)	操作等级协议(OLA)
描述IT和一个或多个客户之间的协议中的服务、条款和条件；	描述内部服务提供者（IT实体）要求的服务组件、要求和条件；
SLA的有效期有具体说明，指明了起始日期和终止日期；	经常被查看，以便了解每天提供的服务有什么变动；
侧重商业和客户；	侧重内部IT；
描述IT承诺的具体业务度量标准和报告频率；	描述服务组件度量标准以及内部服务提供者（IT实体）测量这些度量标准的频率；ITSS培训
描述客户和IT的角色和职责；	描述IT员工和个人的角色和职责；
描述IT与客户的业务联系；	描述IT服务提供商与客户的日常联系；

待续http://www.ITILxf.com/thread-52429-1-1.html

本帖关键字：ITSS

20150924淡然

续上








4.2中期建议

n建立问题管理和变更管理流程，实现IT服务的主动管理，同时实现完善的IT服务级别管理（SLM）；

v问题管理

在近期目标中，我们重点实现了事件管理，如果事件在第一时间没有办法解决，就需要转入问题管理（ProblemManagement）流程，问题管理流程的主要目标：

1)使突发事件和问题对业务所造成的影响减少到最小；ITSS考试

2)较少和避免相关错误的重复发生；

3)提高IT服务质量；

4)减少事件的数量；

5)通过提供已有问题的解决方案，完善知识库，提高一线解决率；

问题管理流程最终完成找到问题发生的根本原因，也只有找到原因，才能根本解决问题，避免同样的问题一而再，再而三的发生。建议将问题管理分成两个部分建设，一个是建设被动问题管理的部分——等事件通报变成了问题，再来分析问题，找出问题发生原因，加以诊断，再提出解决方法及步骤。另一个是建设主动问题管理的部分，分析事件发生趋势，事前先找出可能的潜在问题，主动提出解决方法及步骤，预防问题将来发生。

在问题的被动管理方面，建议包含两个层面上的管理，问题管理（ProblemControl）和错误管理（ErrorControl）。当事件通报到问题管理流层后，进入问题控制阶段，在这个阶段，我们主要诊断并分析问题，当找出问题发生原因时，它就转变成已知错误（KnownError）。找出问题发生的原因后，就可以找出问题的解决方法和方案，必要时提出变更需求（RequestForChange），通过变更流程实现问题的最终解决。

在问题的主动管理建设方面，透过事件的趋势分析及定期检讨事件统计报表，找出未来可能发生的问题。另外产品提供厂商的报告或建议，也会建议一些措施以防范未来可能发生的问题。通过这些主动方法，便可在事件发生之前就找出可能潜在的问题，主动提出解决方法和方案。

很多实际案例显示，通常80%的服务品质下降导因是20%的问题，所以专注于这20%问题的解决，就可以大大的提升服务。

v变更管理

在近期目标实现中建立了配置管理，配置管理的数据库CMDB的维护主要依赖事件管理的某些变通手段，并没有从真正规范意义上去维护CMDB，保障CMDB数据的完整和准确性。变更管理的目标就是确保IT基础架构中所有的变更都能用有效和快速标准的方法和步骤来管理，其目的就是减少或防止变更对业务产生影响或将事件数减少，希望能在变更需求与变更所可能造成的影响两者之间取得平衡，同时，配合配置管理模块保证CMDB数据的准确性。总的看来，建立变更管理的主要意义：

1)IT服务和业务之间更好的整合；

2)改善变更的风险评估；

3)减少由于变更所造成的对IT服务和服务级别协议的负面影响；

4)可以更好的评估计划中的变更所需要的费用；

5)减少失败的变更次数；

6)提高问题管理和可用性管理的效率；

7)提高IT服务的质量；

8)与配置管理形成接口，保证CMDB数据的准确性；ITSS认证

RFC（RequestForChange，变更请求，简称‘RFC’）的提出，表示有人需要在目前的IT基础架构上做变动，那么这样的行为该怎么样规范控制呢？RFC开始先送到变更管理员处，由变更管理员先加以过滤。如果是常规变更，如，新员工帐号建立，即可立即核准；否则，则加以分类，指定优先等级，然后根据类别提到该类的CAB（ChangeAdvisoryBoard，变更咨询委员会，简称”CAB”）等待核准。

CAB审核这些RFC，并根据公司业务需要建议公司接受或拒绝变更。考量因素包括对目前服务的影响、变更的成本、风险等等，最后根据这些因素提出建议。如果该RFC被核准可以执行，就正式通知相关的技术小组来执行这些变更。变更执行之前，变更管理员都应该准备《变更检讨报告》（ChangeReview），作为下次CAB讨论的主题。通常CAB会议的议程会包括失败或测试不成功的变更请求、新的需要审核的变更请求、变更请求执行成功后的后续追踪。一个成功的变更请求如果经过追踪成效良好，最后变更管理员就可以结案该变更请求的整个过程。在所有过程中，变更管理员推动并监督整个过程。

v建立完善的IT服务级别管理(SLM)

通过近期目标的实现，可以通过事件管理和配置管理流程收集客观、准确的事件处理数据：事件分类处理数据、设备发生事件的数据、分类事件平均处理时间、设备有故障时间、设备无故障时间等。

通过对这些数据的深入分析可以建立关键业务的服务级别协议(SLA)，并有相应的服务流程去监视实际服务水平，定期回顾服务状况，找出与服务级别的差距或可改进的领域，从而制定服务改进计划(SIP)，并进行相应跟踪。

在服务级别管理过程中还包含另外关键指标操作等级协议(OLA)。是指两个以上IT实体之间的内部协议，它规定了所有参与方的职责，规定这些参与方要根据双方同意的质量和数量提供某种服务（或服务组件-例如硬件、软件等），同时限制用户对合同中规定并得到双方同意的服务限度提出额外要求。

注意，如果IT支撑部门向某个业务团体承诺的SLA是提供99.9%的服务可用性，则可能需要准备许多OLA才能满足这个承诺。例如，负责网络支持的IT支持小组承诺提供高可用性的网络，支持组织（各级组织）都必须承诺非常具体的响应时间和逐级上报步骤，负责建立和安装服务器的IT实体可能需要承诺安装高可用性的服务器，等等。

许多IT公司都在努力更加面向服务，但它们经常遇到分不清SLA和OLA之间关系的情形。下表通过将两者特点进行比较显示了SLA和OLA之间的一些内在差别。

服务等级协议(SLA)	操作等级协议(OLA)
描述IT和一个或多个客户之间的协议中的服务、条款和条件；	描述内部服务提供者（IT实体）要求的服务组件、要求和条件；
SLA的有效期有具体说明，指明了起始日期和终止日期；	经常被查看，以便了解每天提供的服务有什么变动；
侧重商业和客户；	侧重内部IT；
描述IT承诺的具体业务度量标准和报告频率；	描述服务组件度量标准以及内部服务提供者（IT实体）测量这些度量标准的频率；ITSS培训
描述客户和IT的角色和职责；	描述IT员工和个人的角色和职责；
描述IT与客户的业务联系；	描述IT服务提供商与客户的日常联系；

待续http://www.ITILxf.com/thread-52429-1-1.html

本帖关键字：ITSS