20150720    淡然

续上

1.7    错误控制的活动

错误控制包括了成功地纠正知名错误的流程。其目标是变更IT组件，消除影响IT基础架构中知名错误，防止事故的重复发生。

许多IT部门关注于生产环境和开发环境的错误控制，它直接与变更管理流程接口。图4示例了错误控制的三个阶段。监控和跟踪阶段包括全部的问题/错误生命周期。   

                                                            ITSS培训

图4    错误控制

1.7.1    错误识别和记录

当有故障的配置项（引起或可能引起事故的配置项）被检测到就识别了错误。当问题的根本原因被发现就被赋予知名错误的状态，同时开发临时措施。

流入错误控制系统的知名错误有两个来源，一个是生产系统中的问题控制子系统，另一个是相应的开发环境。在生产操作中发现的错误，就如在问题控制活动调查和诊断中所描述的，被识别和记录。在这种情况下，问题记录形成了知名错误记录的基础（事实上，它确实只是状态的改变）。

知名错误的第二来源是开发活动。例如，新应用或打包发布的实施可能包括了在开发阶段形成的已知但未解决的错误。当应用或发布包实施时，来自于开发的知名错误相关的数据应该对生产环境的管理人员可用。

许多IT部门参与过这样一系列事件。问题管理系统应该记录所有解决活动，向支持职员提供监控与跟踪工具。也应该提供全面的审计记录，从事故到问题、到知名错误、到变更请求或重大变更实施。                                         ITSS认证

1.7.2    错误评估

问题管理职员协同专业职员，对解决错误的方法进行初始的评估。如果必要，接下他们根据变更管理过程，完成变更请求。变更请求的优先组根据错误在业务上的紧急程度和影响来决定。变更请求的标识符应该被包括在知名错误记录中，以便维护一个完全的审计路径，或者将两者连接。

错误解决的最终进程－影响分析、需要执行的解决步骤的详细评估、配置项错误的改正、变更的测试－要在变更管理的控制下执行。在极端情况下，紧急的解决方案，进行授权执行是必要的。

* 第三方产品中的错误

卖方维护的产品中的问题可能被问题管理或专家支持小组识别，应该向卖方支持的负责人报告。应该监控卖方支持，确保在合理的时间内收到对问题报告的响应。

在设置了软件维护的目标－诸如修复的合理和最长时间，以及IT基础架构相关的可靠性和可服务性－应该在合同或许可条件中明确，应该由第三方发起补救措施，以免受到抱怨。当购买软件时，特别是在业务上具有竞争的情况下，明确维护目标的可能性应该具备。注意解决软件错误的必要的变更归属于变更管理，与内部产品一样。

* 软件环境中的错误控制

在生产环境和开发环境中的问题和错误控制流程在本质上是一样的。前面对生产环境中的问题管理所描述的支持工具，也适合于开发环境中所要求的。图5显示了在生产和开发环境中的错误控制间的循环关系。协同集成的问题管理系统促进这种情况的处理。

图5    生产与开发环境中的错误周期

在生产运营期间发现的错误导致变更求的积累，发布策略（参见发布管理）允许最终创建一个发布协同授权的变更修正系统中的错误。开发职员应该注意与打包发布相关的所有知名错误和问题，当知名错误被改正后要求被删除，加入到修订的错误数据库（或CMDB）。

当完成新的发布，这个修订的错误数据库替换以前版本的数据库作生产版本。当新的错误在生产运营中被发现，重复这个周期。

1.7.3    记录错误解决方案

每个知名错误的解决过程应该记录在问题管理系统。与所有知名错误相关的配置项数据、症状、解决方案或防止措施保存在知名错误数据库是很关键的。这些数据对于事故匹配、在将来的诊断解决事故以及防止事故方面提供指导、提供管理信息等方面都是有用的。

1.7.4    关闭错误

在成功地实施变更解决错误后，相应的知名错误记录被关闭，同时任何相关的事故或问题记录也一起被关闭。可以考虑在事故、知名错误和问题记录中插入一个中间状态“关闭但未进行实施后评价（Closed pending PIR）”，确保修正已经实际起作用。实施后评价（Post-Implementation Review,PIR）能确认最终关闭前解决的效果。

对于事故，除了打电话给用户确保他们已经满意就没有别的了，对于严重的问题和知名错误，要求进行正式的评价。

1.7.5    监控问题/错误的解决

变更管理负责处理变更请求，同时错误控制负责监控解决知名错误的进展。在整个的解决过程中，问题管理应该从解决问题和错误的变更管理进展中获得日常报告。

问题管理应该监控问题和知名错误对用户服务的持续影响。在影响变得严重的事件中，问题管理应该升级问题，可能要咨询变更咨询委员会提升变更请求的优先级，在适当的时候实施紧急变更。

问题解决的进展应该结合SLA一起被监控。典型地，SLA规定在每个测量间隔内（一般为四周）在每个严重级别上不应该有特定数量的突出错误。如果在某个严重级别上问题或错误的数量达到预先定义的限制，可能引起与SLA的不一致，就必须升级。

1.7.6    错误控制的要点

在错误控制中切记以下要点：

v       不是所有的知名错误需要被解决。组织能够决定允许保留知名错误－例如，因为解决的成本太高、技术上不可能或要求太多的时间来解决。实践中，错误控制关注于选择合理的投资来解决问题；

v       准备变更请求是错误控制的责任之一。解决方法经常是技术上的调整，但不要忘记，变更请求也可能需要包括对过程、工作方法和/或组织结构的修正；

v       对于日常的硬件故障，考虑根据特定的设备或设备分类创建标准的错误记录。使用这些来维持对故障鉴定的快速指导－尽管多数信息（例如故障和宕机间的平均时间）来自于事故数据；

v       许多硬件故障的纠正在事故控制下执行，并不通过错误控制和变更管理。然而对硬件规格的任何改变应该从属于正常的变更管理过程；

v       理想情况下，应该在生产和开发环境中的事故、问题和错误控制中使用公用工具。如果因为在开发环境使用特定的CASE工具而使这不可能，那么设计和开发一个可行的转移机制是必要的；

v        In practice, the level of detail usually required for development Configuration Management often precludes a viable shared system. The key thing is to share the data, especially in terms of passing to the live environment information on Problems, Known Errors and ongoing Changes that are being handed over with any new or changed software.                ITSS考试

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

本帖关键字：ITSS

20150720    淡然

续上

1.7    错误控制的活动

错误控制包括了成功地纠正知名错误的流程。其目标是变更IT组件，消除影响IT基础架构中知名错误，防止事故的重复发生。

许多IT部门关注于生产环境和开发环境的错误控制，它直接与变更管理流程接口。图4示例了错误控制的三个阶段。监控和跟踪阶段包括全部的问题/错误生命周期。   

                                                            ITSS培训

图4    错误控制

1.7.1    错误识别和记录

当有故障的配置项（引起或可能引起事故的配置项）被检测到就识别了错误。当问题的根本原因被发现就被赋予知名错误的状态，同时开发临时措施。

流入错误控制系统的知名错误有两个来源，一个是生产系统中的问题控制子系统，另一个是相应的开发环境。在生产操作中发现的错误，就如在问题控制活动调查和诊断中所描述的，被识别和记录。在这种情况下，问题记录形成了知名错误记录的基础（事实上，它确实只是状态的改变）。

知名错误的第二来源是开发活动。例如，新应用或打包发布的实施可能包括了在开发阶段形成的已知但未解决的错误。当应用或发布包实施时，来自于开发的知名错误相关的数据应该对生产环境的管理人员可用。

许多IT部门参与过这样一系列事件。问题管理系统应该记录所有解决活动，向支持职员提供监控与跟踪工具。也应该提供全面的审计记录，从事故到问题、到知名错误、到变更请求或重大变更实施。                                         ITSS认证

1.7.2    错误评估

问题管理职员协同专业职员，对解决错误的方法进行初始的评估。如果必要，接下他们根据变更管理过程，完成变更请求。变更请求的优先组根据错误在业务上的紧急程度和影响来决定。变更请求的标识符应该被包括在知名错误记录中，以便维护一个完全的审计路径，或者将两者连接。

错误解决的最终进程－影响分析、需要执行的解决步骤的详细评估、配置项错误的改正、变更的测试－要在变更管理的控制下执行。在极端情况下，紧急的解决方案，进行授权执行是必要的。

* 第三方产品中的错误

卖方维护的产品中的问题可能被问题管理或专家支持小组识别，应该向卖方支持的负责人报告。应该监控卖方支持，确保在合理的时间内收到对问题报告的响应。

在设置了软件维护的目标－诸如修复的合理和最长时间，以及IT基础架构相关的可靠性和可服务性－应该在合同或许可条件中明确，应该由第三方发起补救措施，以免受到抱怨。当购买软件时，特别是在业务上具有竞争的情况下，明确维护目标的可能性应该具备。注意解决软件错误的必要的变更归属于变更管理，与内部产品一样。

* 软件环境中的错误控制

在生产环境和开发环境中的问题和错误控制流程在本质上是一样的。前面对生产环境中的问题管理所描述的支持工具，也适合于开发环境中所要求的。图5显示了在生产和开发环境中的错误控制间的循环关系。协同集成的问题管理系统促进这种情况的处理。

图5    生产与开发环境中的错误周期

在生产运营期间发现的错误导致变更求的积累，发布策略（参见发布管理）允许最终创建一个发布协同授权的变更修正系统中的错误。开发职员应该注意与打包发布相关的所有知名错误和问题，当知名错误被改正后要求被删除，加入到修订的错误数据库（或CMDB）。

当完成新的发布，这个修订的错误数据库替换以前版本的数据库作生产版本。当新的错误在生产运营中被发现，重复这个周期。

1.7.3    记录错误解决方案

每个知名错误的解决过程应该记录在问题管理系统。与所有知名错误相关的配置项数据、症状、解决方案或防止措施保存在知名错误数据库是很关键的。这些数据对于事故匹配、在将来的诊断解决事故以及防止事故方面提供指导、提供管理信息等方面都是有用的。

1.7.4    关闭错误

在成功地实施变更解决错误后，相应的知名错误记录被关闭，同时任何相关的事故或问题记录也一起被关闭。可以考虑在事故、知名错误和问题记录中插入一个中间状态“关闭但未进行实施后评价（Closed pending PIR）”，确保修正已经实际起作用。实施后评价（Post-Implementation Review,PIR）能确认最终关闭前解决的效果。

对于事故，除了打电话给用户确保他们已经满意就没有别的了，对于严重的问题和知名错误，要求进行正式的评价。

1.7.5    监控问题/错误的解决

变更管理负责处理变更请求，同时错误控制负责监控解决知名错误的进展。在整个的解决过程中，问题管理应该从解决问题和错误的变更管理进展中获得日常报告。

问题管理应该监控问题和知名错误对用户服务的持续影响。在影响变得严重的事件中，问题管理应该升级问题，可能要咨询变更咨询委员会提升变更请求的优先级，在适当的时候实施紧急变更。

问题解决的进展应该结合SLA一起被监控。典型地，SLA规定在每个测量间隔内（一般为四周）在每个严重级别上不应该有特定数量的突出错误。如果在某个严重级别上问题或错误的数量达到预先定义的限制，可能引起与SLA的不一致，就必须升级。

1.7.6    错误控制的要点

在错误控制中切记以下要点：

v       不是所有的知名错误需要被解决。组织能够决定允许保留知名错误－例如，因为解决的成本太高、技术上不可能或要求太多的时间来解决。实践中，错误控制关注于选择合理的投资来解决问题；

v       准备变更请求是错误控制的责任之一。解决方法经常是技术上的调整，但不要忘记，变更请求也可能需要包括对过程、工作方法和/或组织结构的修正；

v       对于日常的硬件故障，考虑根据特定的设备或设备分类创建标准的错误记录。使用这些来维持对故障鉴定的快速指导－尽管多数信息（例如故障和宕机间的平均时间）来自于事故数据；

v       许多硬件故障的纠正在事故控制下执行，并不通过错误控制和变更管理。然而对硬件规格的任何改变应该从属于正常的变更管理过程；

v       理想情况下，应该在生产和开发环境中的事故、问题和错误控制中使用公用工具。如果因为在开发环境使用特定的CASE工具而使这不可能，那么设计和开发一个可行的转移机制是必要的；

v        In practice, the level of detail usually required for development Configuration Management often precludes a viable shared system. The key thing is to share the data, especially in terms of passing to the live environment information on Problems, Known Errors and ongoing Changes that are being handed over with any new or changed software.                ITSS考试

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

本帖关键字：ITSS