第10 章 技术问题分析、判断与解决
本章编写的主要目的是使学员具备从“事实”与“意见”查看背后逻辑的能力，进而客观而准确地思考；使学员能分辨问题产生的根本原因及表面的症状，遵循科学的方法解决问题；使学员了解如何处理一个高度复杂的问题，并用有效的方法评估每个可能的选择与方案，以进行更为客观有效的决策。
10.1 概 述
当现状与标准或预期的状态有差距时，就发生了问题。
每个人都可以意识到问题，但面对纷繁复杂的信息，要做出正确的判断并非易事，只有获得与问题本质有关的有效信息，才能分析问题、解决问题。这时就必须通过提出问题来确定问题，全面地描述问题的性质，分辨可能的原因。同时，要借鉴已有的经验和知识，分析出可能导致问题产生的各种因素，详细记录实际和预期结果之间的偏差，承认原因的多样性和可能性，把这些可能的原因汇总并记录在表格上，以避免妄下结论。
问题有简单有复杂，当遇到一个问题时，是否能找到这种问题的真正原因是最重要的。当IT 服务工程师在遇到问题时，“技术问题的分析、判断与解决”将为其提供一套发现问题和解决问题的思路和框架，如下图：
10.2 问题发现
10.2.1 问题发现的流程
当接到客户报告问题时，首先是询问客户了解情况，然后做简单的估判和准备，如需要进一步判断，可以到现场实地检查，最后确定问题。这是IT 服务问题发现的一般流程。
这里最重要的是确定问题。确定问题是何时发生的、如何发生的、与何对象有关、发生的次数或数量等。
在确定问题时要注意拟定有效的问题陈述。明确的问题陈述可以指引解决问题的过程进入正确的方向。一旦进入错的方向，将徒劳无功，导致问题无法解决。不明确的问题陈述反而会使解决方法变成了问题，所以清楚的陈述可以使问题解决有准确的切入点。与需要面对的问题不相关的信息和材料，都要放弃。只有每个人对问题都有统一的认识，才有可能沿着正确的方向分析问题。
10.2.2 问题发现的方法
问题发现的一个简单而有效的方法是“4W2H 法”（4W 为What、When、Where、Who，2H为How 及How much）。4W2H 法以明确简洁又不失客观的方式来陈述问题，以问题在什么状况下发生为导向。
确定问题是将问题的特性用4W2H 格式表示出来，如表10.1 所示：
从这个案例中，我们发现客户描述的“涉及业务系统的数据库服务器宕机”现象分解如表10.2：
10.3 问题分析
分析和思考问题是对问题定义的进一步细化，搞清楚问题的来源，是哪里的问题？导致问题的真正根源是什么？原来是否遇到过类似问题等内容？分析和思考问题是否全面直接影响到后续问题的解决。
若是简单的问题则不必知道或追究其发生原因，可跳过此步骤直接进入问题解决程序。
问题分析恰恰是解决问题的桥梁。问题分析的作用在于，它能够有效地帮助IT 服务工程师观察实际发生的情况和预期目标之间的偏差，从而明确目标。只有目标明确才能真正有效的解决问题。因此，要解决问题，就要确切地学会怎样定义问题，辨别问题，以及有效的分析收集到的信息。
10.3.1 问题分析流程
问题分析一般是先找出可能影响问题的因素，再评估可能的原因，最后是确定真正的原因。其流程如下：
10.3.2 找出可能影响问题的因素
在识别可能的原因时，要运用知识、经验和常识来帮助找出若干种可能性，列举可能的原因，对收集的信息进行有效的评估。如果这样还不能找到发生偏差的原因，则可以参考使用“问题分析的常用方法和技巧”章节。
在评估可能的原因时，首先要检验上一步骤中列出的原因，分析哪些原因对解决问题更加直接、更加重要，看它能否说明问题产生后的一些事实，所以检验过程可以帮助辨别最可能产生问题的原因。
对问题的详细描述可以分辨发生的事实，也可以知道可能发生却未发生的情况，从而使围绕问题设立清楚的界限成为可能，进而缩小问题的范围。问题的原因总是与“发生”的一方有关，与“可能发生却未发生”的情况相比，问题的原因一定对“发生”一方有特殊影响，找出问题的不同点，可以帮助找到问题发生的真正原因。
问题分析的目的在于找出“发生事实”和“预期结果”之间的偏差。预期结果产生问题，一定有变化导致问题发生，如果能够有效的找到这些变化，就可以找到问题真正的原因。
找到可能和问题有关的变化可以帮助我们从收集事实阶段进入假设阶段，因而可以基于以往的经验、知识、常识，详细地叙述可能的原因。
在【场景10.1】中可能影响问题的因素：
导致数据库服务器（N240）宕机，引起数据库服务停止的原因有五种：
- 系统中病毒；
- 硬盘引导区可能损坏；
- 内存坏；
- CPU 损坏；
- CPU 风扇坏。
10.3.3 评估可能的原因
评估原因时要对照“发生”和“曾经发生、可能发生而没有发生”来进行检验。面对已有的可能，要通过大量的试验去验证每一个可能的原因，从而找到最终的原因，看看这些原因是否可以强有力地解释产生的偏差。
列举可能原因，解析原因，找出关键性的要因，验证关键性要因的可靠度。
我们通过【场景10.1】分析，评估原因如下：
10.3.4 确定真正的原因
问题分析的进展基于掌握的有效信息，要确认真正的原因，就要证实每一个疑点，确认时需要收集信息，深入观察，用实验证明。
在确认产生问题的根本原因后，问题就转化成为已知错误，问题管理也就进入错误控制阶段。如果未最终确认问题产生的根本原因，则应向事件管理人员建议实施应急措施，同时扩大调查和分析的范围，直到找到问题的根源为止。
在前面的【场景10.1】中，通过仔细分析列出“数据库服务器（N240）宕机，引起数据库服务停止”这种故障产生的可能原因：
- 系统中病毒；
- 硬盘引导区可能损坏；
- 内存坏；
- CPU 损坏；
- CPU 风扇坏。
根据数据库系统日志排查过程：
对于以上5 种原因，从检验记录中的假设入手，可以采用排除法来确定最后原因。首先检查是否系统中病毒了。由于系统采用了防毒措施，病毒库即时更新。但根据知识库，特征“数据库服务器（N240）宕机，引起数据库服务停止”不太可能是病毒所为，从这点来说“系统中病毒”可排除；第二个原因“硬盘引导区可能损坏”，通过换硬盘引导，系统可以正常启动，这说明真正的原因肯定不在硬盘上，这样也排除了“硬盘引导区可能损坏”；那么接下来就检查内存了，根据主机启动自检，没有发现内存损坏，而备机的系统日志显示内存报错，因此，断定备机内存损坏；最后查看系统日志，同时发现主机出现风扇报错信息，因此，断定主机风扇损坏。
10.3.5 问题分析的常用方法
MECE 是英文Mutually Exclusive Collectively Exhaustive 的缩写，中文意思是“相互独立，完全穷尽”，也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并解决问题的方法。MECE 分析法具有两个特点：
- 完整性，说的是分解工作的过程中不要漏掉某项，要保证完整性；
- 独立性，强调了每项工作之间要独立，每项工作之间不要有交叉重叠。
问题树就是MECE 方法的一个重要应用，要实现相互独立的一个重点就是按层次以一个中心展开的树状分析，而不是进行相互关联的网状分析或展开。问题树的分解也一样必须要能够完全穷尽对问题诊断的所有描述和内容。通过逐项的展开和分解后，就很容易展开对造成问题产生的原因进行筛选和诊断。
第一点，基于问题树的模式就是结构化问题分析和思维的模式。往往造成不独立的原因在于进行每一次分解的时候没有考虑相互独立。
第二点，问题诊断是要先对造成问题的根源进行逐层分解，分解到最后往往解决方案也就水落石出，但是我们经常犯的一个错误是跳过了中间的结构化思维步骤，而直接去分解针对问题的解决方案，这是造成没有相互独立的重要原因。因为问题树分解的最后问题原因分支和解决问题方案之间往往是多对多的关系，一个解决方案有可能会是针对多个问题根源采取的措施。没有按照MECE的一个重要原因就是将问题根源的分解过程和问题的解决过程混合在了一起，跳过了中间的一些重要的问题原因分析的步骤。
第二点旨在强调结构化思维不能代替系统思维，有时候不能简单的头痛医头，脚痛医脚。在问题树分解到最末枝的时候，这些原因之间往往存在着正负作用的相互影响。这就会造成当我们针对某一个原因制定解决方案的时候，会导致其他原因的恶化或出现新的问题和原因。脚的病往往医治好了但是头又开始痛了，你整个人仍然是一样的不舒服而没有改观。这也是针对MECE 方法我们必须要强调的一点，对于问题的分解是能够达到完整性和相互独立性，但是对于解决问题必须要考虑依赖性和相互影响，否则分解的再漂亮往往也无利于我们真正的解决问题。
10.4 问题解决
解决问题是最后一步，建立在分析问题基础上，解决问题有多条途径，如何在各种约束条件下选择出最佳的途径来解决问题是需要考虑的重要因素。问题解决后要及时进行归纳和总结，形成知识库。
10.4.1 问题处理流程
对系统中记录的历史事件进行统计分析，从中分析出潜在的问题，主动创建一个问题记录，该问题记录与相关事件信息进行关联。根据问题内容，将问题记录分派给适当的技术小组负责处理。处理完毕后应当记录问题的解决方案、变通方法、预防性措施。
10.4.2 提出被选方案
通过问题分析确定了问题的真正原因之后就可以提出被选方案了，被选方案可能有一个或多个。对于复杂的问题，或难解决的问题可以有多套选择方案以备不时之用。方案要尽量考虑可能的风险。
10.4.3 风险评估
风险评估流程包括系统调研、资产识别、威胁识别、脆弱性识别（包括现有控制措施确认）、风险综合分析以及风险控制计划六个阶段。
系统调研是熟悉和了解组织和系统的基本情况，对组织IT 战略、业务目标、业务类型和业务流程以及所依赖的信息系统基础架构的基本状况和安全需求等进行调研和诊断。
资产识别是对系统中涉及的重要资产进行识别，并对其等级进行评估，形成资产识别表。资产信息至少包括：资产名称、资产类别、资产价值、资产用途、主机名、IP 地址、硬件型号、操作系统类型及版本、数据库类型及版本、应用系统类型及版本等。
威胁识别是对系统中涉及的重要资产可能遇到的威胁进行识别，并对其等级进行评估，形成威胁识别表。识别的过程主要包括威胁源分析、历史安全事件分析、实时入侵事件分析几个方面。
脆弱性识别是对系统中涉及的重要资产可能被对应威胁利用的脆弱性进行识别，并对其等级进行评估，形成脆弱性识别表。脆弱性识别又具体分为物理安全、网络安全、主机系统安全、应用安全、数据安全、安全管理六个方面的内容。
风险综合分析是根据对系统资产识别、威胁分析、脆弱性评估的情况及收集的数据，定性和定量地评估系统安全现状及风险状况，评价现有保障措施的运行效能及对风险的抵御程度。结合系统的IT 战略和业务连续性目标，确定系统不可接受风险范围。
风险控制计划是针对风险评估中识别的安全风险，特别是不可接受风险，制定风险控制和处理计划，选择有效的风险控制措施将残余风险控制在可接受范围内。
解决方案的两面性
问题解决方案也会带来风险，一定不能忽视这个问题。
比如一个企业的应用系统，开通了几个服务，从风险评估的角度讲，这几个服务的开通会造成很多安全隐患。如果要消除安全隐患，就需要打补丁。可是一旦把安全补丁打上了，安全问题倒是没有了，企业所提供的服务却停掉了。
要消除安全解决方案带来的风险，首先，用户要对安全解决方案的两面性有清醒的认识。一样东西有好的一面，必然也有它的弊端。有的安全厂商说其安全产品可以解决一切问题，但负面的东西他却没说。所以，对于客户来说，一个安全解决方案的正面和负面的影响都要去关注；对于厂商来说，一个解决方案的好坏都应该明确告知客户。
其次，组织安全厂商和安全专家的互相讨论非常重要。这些厂商和专家会从不同的角度进行阐述，达成共识，客户将是最大的受益者。
风险评估流程
10.4.4 确定最终方案
评估风险后可以确定最终解决方案。
【场景10.1】案例的问题解决方案：
- 更换主机的风扇，将服务从将备机切换主机；
- 更换备机内存，重启系统，将双机系统恢复正常；
- 找出主机宕机引起备机上的数据库停止的根本原因，是因为主机上有个数据库监听的脚本，并该脚本停用。
10.4.5 方案执行
方案确定后，接下来就要方案执行了。
【场景10.1】的处理过程：
- 7月4 日10：00 现场工程师带风扇和内存的备件到现场，先更换了主机的风扇，正常启动后，将数据库服务切换到主机，并更换备机的内存；
- 11：30，两台服务器均运行正常，vcs 运行正常，数据库运行正常。
故障验证：
7 月6、7 日查找主机宕机影响备机上的数据库业务的根本原因，最后发现：在主机上的有个启停数据库和监听的脚本：/etc/init.d/dbora，link /etc/rc2.d/S99local 和/etc/rc0.d/K10dbora，当机器
在启动和停止时，该脚本就去启动和停止数据库的监听。主机和备机的listener.ora 里的配置都是同一个监听名和同一个地址，而oracle 9i 是可以远程停止监听的。所以，当主机 关闭时系统自动执行/etc/rc0.d/K10dbora，就把备机的数据库监听停掉，这样触发了vcs 的监控，将数据库shutdown。
最终处理结果：
发邮件给客户方写明原因，并在征求意见后将该脚本的启停数据库的语句注释掉。
故障处理关键时间点：
7 月3 日
9：15 接到故障服务请求电话电话后，当即与用户联系获取了远程登录方式并与确认了现场工程师，远程登录系统后发现主机的风扇坏，导致温度过高而宕机，另外发现备机上有内存的报错信息。而且发现主机一宕机，就会引起备机上数据库服务停止，由于该业务是关键业务，所以将主机关机，以保证在备机上的数据库正常运行。
11：15 业务正常运行，座席工程师继续申请备件。
7 月5 日
10：00 现场工程师带风扇和内存的备件到现场，先更换了主机的风扇，正常启动后，将数据库服务切换到主机，并更换备机的内存。
11：30，两台服务器均运行正常，vcs 运行正常，数据库运行正常。
7 月6 日至7 日
查找主机宕机影响备机上的数据库业务的根本原因，最后发现：在主机上的有个启停数据库和监听的脚本：/etc/init.d/dbora，link /etc/rc2.d/S99local 和/etc/rc0.d/K10dbora，当机器在启动和停止时，该脚本就去启动和停止数据库的监听。主机和备机的listener.ora 里的配置都是同一个监听名和同一个地址，而oracle 9i 是可以远程停止监听的。所以，当主机关机时系统自动执行/etc/rc0.d/K10dbora，就把备机的数据库监听停掉，这样触发了vcs 的监控，将数据库停止。
10.5 问题回顾
10.5.1 问题的跟踪和监控
在查明和记录问题后，为了评估问题可能对服务级别产生的影响，首先应对问题进行归类。问题归类应当根据问题涉及的领域、影响度和紧迫性以及优先级等因素综合确定。问题归类不是静态的，它在问题生命周期的不同阶段可能会发生调整，如应急措施可以降低问题的紧迫性，而新出现的事故却可能会提高问题的影响度。
问题分类简单地说就是把遇到的问题分成类别，便于以后形成知识库进行查找。IT 服务问题分类方法有很多种，比如，按类型故障分：硬件、软件；按严重程度（级别）分：一级、二级、三级等；按紧急程度分：特别紧急、紧急、一般等。判断准则如：
- 是突发性还是经常发生的问题？
- 是过去已发生的问题，现在的问题还是未来可能面临的挑战？
- 是迫切性的问题还是暂时没有迫切性的困扰，但未来会形成大问题？
- 是偶发性的问题还是系统性的问题？
- 是现在可以解决的问题？未来才可以解决的问题？还是永远不可解决的问题？
【场景10.1】的问题回顾：
- 主机风扇坏，引起温度过高，导致宕机需要更换备件；
- 主机上的有个启停数据库库和监听的脚本BUG，需要调整修改脚本文件；
- 相关问题已经通报问题经理，并已形成知识记录提交问题经理。
10.5.2 知识库管理
建立知识库，实现知识共享，提高一线服务工程师解决问题的速度。由技术专家对知识库内容进行定期审查和更新，维护知识库的权威性。通过知识提交、审核、发布、查询等功能自动沉淀IT服务组织日常运维中的工作经验，帮助各级支持人员提高技能水平，简化IT 服务任务，同时降低对具体个人的依赖。
系统建设的目的不仅仅是规范、记录、督促、自动化管理工作，而且要帮助各级支持人员提高技能水平，简化IT 服务任务。同时也是降低对具体某个个人赖的手段。这些需要通过知识经验的积累和共享来完成。
知识库管理主要包括以下功能：
- 提供支持人员提交经验和知识的输入接口或界面；
- 提供知识库内容的审查功能；
- 提供完善的查询功能，例如：查询关键字、知识列表等；
- 具有不同等级用户环境的区别，不同等级的用户管理不同的知识库内容；
- 提供知识库的分类整理，易于扩展、调整；
- 知识库支持Word/Excel/TXT 等格式文档作为附件的输入。
对于 【场景10.1】，需要形成的知识有2 条：
- 系统宕机，原因可能有三：风扇坏、CPU 坏、内存坏；
- 导致数据库服务停止的原因：监听的脚本BUG。
按关键字“系统宕机’”、“风扇坏”、“CPU 坏”、“内存坏”存入知识库；按关键字“数据库服务停止”、“监听的脚本BUG”存入知识库。使知识库更加丰富，为以后故障提供支持。
IT 服务工程师在实际工作中会遇到大量的技术问题，而本章通过一个实际场景贯穿了整个技术问题分析、判断与解决的全过程，给出了一整套的完备思路。这一思路分为四部分：问题发现、问题分析、问题解决和问题回顾。在问题发现中介绍了问题发现流程和问题发现的方法；在问题分析中，首先找出可能的原因，再确定真正的原因；在问题解决中，解决的方案会有多种，要进行评估，确定最终方案并执行；问题回顾主要是建立和积累知识库，为未来打基础。
************************************************************************** 返回到首页 《ITSS认证IT服务工程师培训教材》_试用版_2011_0311连载http://www.itilxf.com/thread-36464-1-1.htmlITSS、培训、服务、资格、评估、ITSS培训师、ITSS评估师、实施ITSS、ITSS符合性、ITSS服务工程师、ITSS服务项目经理、ITSS标准、ITSS咨询、ITSS工具、IT服务监理、ITSS体系、ITSS服务质量、评价、指标、运维、治理、咨询、ITSS出版物、ITSS产品、服务监理工具、服务质量评价工具、标准符合性评估工具、服务管理工具、服务治理工具、系统监控工具、辅助决策分析、服务支持管理、基础设施监控、ITSS基础教材、ITSS标准、ITSS服务人员培训教材、标准化、专业化、人员（People）、流程[1]（Process）、技术（Technology）和资源（Resource），简称PPTR、规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision），简称PIOIS、服务交付规范、资源要求、外包管理、服务交付、分类、代码、服务指南、通用要求、指标体系、ITSS落地实践交流-QQ群：21542747
|
转播
分享
淘帖
()