|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
问题管理流程应定期或不定期地提供有关问题、已知错误和变更请求等方面的管理信息，这些管理信息可用做业务部门和IT部门的决策依据。其中，提供的管理报告应说明调查、分析和解决问题和已知错误所消耗的资源和取得的进展。具体来说包括以下几个方面：
|
|
|
|
（1）事件报告。支持小组和供应商花费与问题同质、错误控制和问题地方的时间。
|
|
|
|
（2）产品质量。根据故障、问题和已知错误信息发现经常受错误影响的产品，并确认供应商的产品是否符合要求。
|
|
|
|
（3）管理效果。说明问题解决前后故障的数量、变更请求数量和解决的已知错误的数量。
|
|
|
|
（4）常规问题管理与问题预防管理之间的关系。积极的预防比消极的应对故障的出现更能体现出问题管理流程运营的成熟性。
|
|
|
|
（5）问题状态和行动计划。说明已对问题采取了何种行动、将采取何种行动及所需的时间和资源。
|
|
|
|
（6）改进问题管理的意见和建议。根据上面的信息，判断问题管理流程是否达到了服务质量计划的目标。如果没有到达，则审计管理流程，提出改进的意见和建议，并估计所需的资源和费用。
|
|
|
|
最后的管理报告与问题管理的范围有很大关系。如果范围扩展到产品和服务开发阶段，则问题管理甚至从这个阶段就要开始定义和监督已知问题和已知错误，从而管理报告也要包括这个阶段的有关问题和已知错误的解决和预防情况。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.已解决问题的记录（如果已消除了故障产生的原因）。
|
|
|
|
|
|
|
|
问题管理流程主要涉及问题控制、错误控制、问题预防和管理报告4种活动，下面分别对这4种活动做简要介绍。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
作业（Job）是用户提交给操作系统计算的一个独立任务。一般每个作业必须经过若干个相对独立又相互关联的顺序加工步骤才能得到结果，其中，每一个加工步骤称一个作业步（Job Step）,例如，一个作业可分成编译、连接装配和运行三个作业步，往往上一个作业步的输出是下一个作业步的输入。作业由用户组织，作业步由用户指定，一个作业从提交给系统，直到运行结束获得结果，要经过提交、收容、执行和完成四个阶段。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
变更请求是关于修改任何文档、可交付成果或基准的正式提议。变更请求被批准之后将会引起对相关文档、可交付成果或基准的修改，也可能导致对项目管理计划其他相关部分的更新。其他变更请求包括必要的预防措施或纠正措施，用来防止以后的不利后果。变更请求可以是直接或间接的，可以由外部或内部提出，可能是自选或由法律/合同所强制的。
|
|
|
|
|
|
.纠正措施：为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动。
|
|
|
|
.预防措施：为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。
|
|
|
|
.缺陷补救：为了修正不一致的产品或产品组件而进行的有目的的活动。
|
|
|
|
.更新：对正式受控的项目文件或计划等进行的变更，以反映出修改或增加的意见或内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
信息系统软件交付之后就进入了运维阶段，该阶段短则4～5年，长则可达10年以上。运维的目的是保证信息系统软件能正常而可靠地运行，并能使系统不断得到改善和提高，以充分发挥作用。运维的过程也就是不断满足用户各种维护需求的过程。用户的维护需求是不断变化的，所以需要持续地对信息系统软件进行修改和维护。这一过程从本质上来说是一个P、D、C、A（P-Plan，策划；D-Do，实施；C-Check，检查；A-Act，处理）循环，不停顿地周而复始地运转。按照戴明质量控制理论，信息系统软件运维的管理流程如下图所示。
|
|
|
|
|
|
|
|
信息系统软件运维服务的四个关键要素是：人员、资源、技术和过程，每个要素通过关键指标反映运维服务的能力。在运维服务提供过程中，通过应用PDCA的方法论，在运维的策划、实施、检查、改进等不同阶段，通过对人员、资源、技术和过程四个服务要素的统一管理，来实现运维服务能力的持续提升。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
问题管理包括诊断事故根本原因和确定问题解决方案所需要的活动，通过相应控制过程，确保解决方案的实施。问题管理还将维护有关问题、应急方案和解决方案的信息，以减少事故的数量和降低影响。问题管理流程的目标是通过消除引起事故的深层次根源以预防问题和事故的再次发生，并将未能解决的事故影响降到最低。
|
|
|
|
问题管理的流程包括问题检测和记录、问题分类和优先级处理、问题调查和诊断、创建已知错误记录、解决问题、关闭问题、重大问题评估等。问题管理基本流程模型如下图所示。
|
|
|
|
|
|
|
|
（1）问题检测和记录。问题检测的方法包括：服务台和事故管理等提交的事故需要进一步查明潜在原因；技术支持小组在日常维护工作中发现有尚未对业务产生影响的潜在问题存在；自动化的事件／告警检测工具检测出IT基础设施或应用存在问题；供应商或承包商通告其产品或服务存在的问题；主动问题管理通过趋势分析提交潜在的问题。问题记录包含问题描述、问题状态、问题类型、服务信息和设备信息等。
|
|
|
|
（2）问题分类和优先级处理。问题的分类原则与事故管理中事故的分类相同。问题优先级处理与事故管理中事故的优先级处理方法相同。
|
|
|
|
（3）问题调查和诊断。问题调查的技术包括借助于配置管理数据库定义问题的影响级别并调查故障点；问题匹配技术和故障重现技术。问题分析和诊断的常用方法包括时序分析法、KT决策法、头脑风暴法、石川图法、帕累托分析法等。
|
|
|
|
（4）创建已知错误记录。针对调查和诊断的结果及解决方案创建已知错误记录，并将其存放在已知错误库中，以方便下次发生同样问题时能够快速匹配出已知错误。
|
|
|
|
（5）解决问题。根据制定出的解决方案，问题管理者组织问题处理人员实施方案。如果解决方案需要对基础设施进行变更，则必须首先提交变更请求，启动变更管理流程。
|
|
|
|
（6）关闭问题。当变更完成并且解决方案成功实施使得问题解决之后，可正式关闭问题记录，更新已知错误库，将问题状态置成“已解决”。
|
|
|
|
（7）重大问题评估。重大问题解决之后应当召开重大问题评估会议，需探讨的问题包括工作中的经验和教训、改进方案、预防措施、第三方责任等。
|
|
|
|
|
|
|
|
|
|
|
|
|
