ISO20000标准及练习题.doc

国际 ISO/IEC 标准 20000-1第一版2005-12-15信息技术服务管理规范前言4简介41 范围52 术语与定义62.1 可用性62.2 基线62.3 变更记录62.4 配置项（CI）62.5 配置管理数据库（CMDB）62.6 文件62.7 事件（Incident）62.8 问题72.9 记录72.10 发布72.11 变更请求72.12 服务台72.13 服务级别协议72.14 服务管理72.15 服务提供商73 管理体系要求83.1 管理职责83.2 文件要求83.3 能力、意识和培训84 服务管理的策划与实施94.1 服务管理的策划（计划）94.2 实施服务管理并提供服务（实施）104.3 监视、度量和评审（检查）104.4 持续改进（改进）104.4.1 策略104.4.2 改进管理114.4.3 活动115 新服务或变更服务的策划与实施116服务交付流程126.1 服务级别管理126.2 服务报告126.3 服务连续性及可用性管理126.4 IT服务的预算及核算管理136.5 能力管理136.6 信息安全管理147 关系流程147.1 总则147.2 业务关系管理147.3 供应商管理158 解决流程168.1 背景168.2 事件管理168.3 问题管理169 控制流程169.1 配置管理169.2 变更管理1710 发布流程1710.1发布管理流程17参考文献19前言ISO（国际标准化组织）和IEC（国际电工委员会）形成了全世界标准化的专门体系。作为ISO或IEC成员的国家机构，通过相应组织所建立的涉及技术活动特定领域的委员会参加国际标准的制定。ISO和IEC技术委员会在共同关心的领域里合作，其它与ISO和IEC有联系的政府和非政府的国际组织也参加了该项工作。在信息技术领域，ISO和IEC已经建立了一个联合技术委员会ISO/IEC JTC1。国际标准的起草符合ISO/IEC规范第2部分的原则。联合技术委员会的主要任务是起草国际标准。联合技术委员会采纳的国际标准草案分发给国家机构投票表决。作为国际标准公开发表，需要至少75%的国家机构投赞成票。本标准中的某些内容有可能涉及一些专利权问题，对此应引起注意，ISO不负责识别任何这样的专利权问题。ISO/IEC20000-1由BSI起草，由ISO/IEC JTC(信息技术)根据“快速跟进程序”采纳称为国际标准，并经过ISO和IEC的国家组织的批准。ISO/IEC20000标准族是“信息技术服务管理”标准，包括：第1部分：规范第2部分：实施指南简介本标准鼓励在交付被管理的服务时采用综合流程方法，以满足业务和客户要求。为使组织有效运作，必须识别和管理众多相互关联的活动。通过利用资源和关联，将输入转化为输出的一项活动，可以视为一个流程。通常，一个流程的输出可直接形成下一流程的输入。服务管理流程的系统应用可以提供持续的控制、更高的效率以及持续改进的机会。活动和流程的开展要求有效管理服务台、服务支持、服务交付和运营小组的人员使之进行协作。此外，也需采用适当的工具来确保流程的有效性和效率。实施本标准的前提条件是实施人员具备相应的资质和能力。一个国际标准的宗旨并非包含合同所需的全部内容。国际标准的用户负责标准的正确应用。符合国际标准并不能免除组织的法律责任。信息技术服务管理第1部分：规范1 范围本标准规定了组织向其客户交付客户可接受的质量的范围的要求。它的使用者可以是：a) 为外包服务寻找竞标的组织；b) 要求供应链中的所有服务提供商采用一致性方法的组织；c) 对IT服务实施标杆管理的服务提供商；d) 作为独立评估的基础；e) 需要证实其有能力提供满足客户要求的服务的组织；f) 通过流程的有效应用来监视并改进服务质量，旨在改进服务的组织。服务交付流程信息安全管理IT服务预算和核算管理能力管理服务连续性和可用性管理服务等级管理服务报告控制流程关系流程配置管理变更管理发布流程发布管理解决流程业务关系管理供方管理事故管理问题管理图1：服务管理流程本标准规定了许多紧密相关的服务管理流程，如图1所示。流程之间的关系依赖于流程在组织内的应用，这些关系通常都过于复杂而无法在模型中表达。因此，图中并未展示流程之间的关系。本标准中包含的目标和控制措施清单并不详尽，组织应根据自己的实际情况采纳其他的目标和控制措施，以满足特定的业务需求。服务提供商和业务之间关系的特点将决定如何实施本标准的要求，以满足整体目标。本标准是基于流程的标准。本标准的目的并非用于产品评估。然而，组织在开发服务管理工具、产品和系统时，可以使用本标准及实施指南，以支持服务管理的最佳实践。2 术语与定义本标准采用下列标准及定义。2.1 可用性服务或组件在一定的时间或时间段内提供所需功能的能力。注：可用性通常用服务实际可用时间与约定服务时间的比率来表示。2.2 基线服务或单一配置项在某一时间点上的陈述。2.3 变更记录关于经过授权的变更可能影响哪些配置项以及如何影响的详细信息的记录。2.4 配置项（CI）处于或即将处于配置管理控制之下的基础设施组件或项目。注：配置项在复杂性、规格和类型方面可能差异巨大，配置项可以是一个整体系统（包括所有的硬件软件和文档），也可以是一个简单的模块或很小的硬件组件。2.5 配置管理数据库（CMDB）包含每一个配置项以及配置项之间重要关系的详细情况的数据库。2.6 文件信息及其承载媒体。注1：本标准认为文件不同于记录（见2.9），因为记录的作用是作为活动的证据而非意图的证据。注2：文件的类型可包括方针说明、计划、程序、服务级别协议和合同。2.7 事件（Incident）不包含在标准服务操作之内的事件，导致或可能导致服务中断或服务质量降低的事件。注：事件可能包括请求的问题，如“我如何来做？”2.8 问题一个或多个事件的未知的根本原因。2.9 记录阐明所取得的结果或提供所完成活动的证据的文件。注1：本标准认为文件不同于记录，因为记录的作用是作为活动的证据而非意图的证据。注2：记录的类型可包括审核报告、变更请求、事件报告、个人培训记录和传递客户的信息。2.10 发布经测试并引入真实环境中的新的和/或变更的配置项的集合。2.11 变更请求用于详细记录服务或基础设施内配置项的变更请求的表格。2.12 服务台直接面对支持小组的客户，其构成了全部支持系统中的重要部分。2.13 服务级别协议服务提供商和客户之间签订的书面协议，该协议中明确规定了服务和约定的服务级别。2.14 服务管理管理服务以满足业务要求。2.15 服务提供商致力于实现ISO/IEC 20000标准的组织。3 管理体系要求目的：提供管理体系，包括有效管理和实施所有IT服务所需的方针和框架。3.1 管理职责最高/执行管理者应通过领导并采取措施，对其开发、实施并改进服务管理能力以开展组织业务并满足客户要求的承诺提供证据。管理者应：a) 建立服务管理的方针、目标和计划；b) 向组织传达满足服务管理目标和持续改进的重要性；c) 确保客户要求的确定与满足，旨在增强客户满意；d) 指定多个管理者负责所有服务的协调与管理；e) 确定并提供策划、实施、监视、评审和改进服务交付和管理所需的资源，如招聘合适的人员，管理人员的更新；f) 管理服务管理组织和服务的风险；g) 按计划的时间间隔进行服务管理评审，以确保其持续的适宜性、充分性和有效性。3.2 文件要求服务提供商应提供文件和记录，以确保服务管理的有效策划、运行和控制。文件应包括：a) 文件化的服务管理方针和计划；b) 文件化的服务级别协议；c) 本标准所要求的形成文件的流程和程序；d) 本标准所要求的记录。应建立不同类型文件和记录的编制、评审、批准、保持、销毁和控制的程序和职责。注：文件可采用任何形式或类型的媒体。3.3 能力、意识和培训应定义并保持所有服务管理者的角色和职责以及有效履行这些角色和职责所需的能力。应评审并管理人员的能力和培训需求，以确保他们能够有效履行他们的角色。最高管理者应确保其员工认识到所从事活动的相关性和重要性，以及如何为实现服务管理目标做出贡献。4 服务管理的策划与实施PDCA方法可以应用于所有的流程。PDCA描述如下：a) 计划：建立符合客户要求和组织策略的交付结果所需的目标和流程；b) 实施：实施这些流程；c) 检查：根据策略、目标和要求监视并度量这些流程，并报告结果；业务要求服务管理服务管理顾客要求实施实施服务管理其他流程，如：业务、供方和顾客要求d) 改进：采取措施持续改进流程绩效。业务要求业务要求顾客要求策划策划服务管理新/变更服务请求新/变更服务请求改进持续改进其他流程，如：业务、供方和顾客要求业务要求检查监视、度量和评审业务要求图2PDCA方法在服务管理流程中的应用图2中的模型展示了流程（第4条款到第10条款）及流程之间的关系。4.1 服务管理的策划（计划）目的：策划服务管理的实施与交付。应进行服务管理策划。这些计划至少应规定以下方面的内容：a) 服务提供商的服务管理的范围；b) 服务管理所要实现的目标和满足的要求；c) 将要执行的流程；d) 管理角色和职责的框架，包括高层负责者、流程所有者及供应商管理；e) 服务管理流程和活动协调方式之间的接口；f) 在实现既定目标的流程中拟采用的识别、评估和管理问题和风险的方法；g) 创建或修改服务的项目接口方法；h) 实现既定目标所需的资源、设施和预算；i) 适用的支持流程和工具；j) 管理、审核和改进服务质量的方法。应建立清晰的评审、授权、传达、实施和保持计划的管理指导，并规定文件化的职责。流程的特定计划应与服务管理计划相一致。4.2 实施服务管理并提供服务（实施）目的：实施服务管理目标和计划。服务提供商应实施服务管理计划以管理并交付服务，包括：a) 资金及预算分配；b) 角色和职责分配；c) 记录并保持每一流程或系列流程的方针、计划、程序和定义；d) 识别并管理服务风险；e) 管理团队，即招聘、开发合适的人员以及管理人员的连续性；f) 设施和预算管理；g) 团队管理，包括服务台和运营；h) 按计划的要求报告流程；i) 服务管理流程的协作。4.3 监视、度量和评审（检查）目的：监视、度量并评审服务管理目标和计划的完成情况。服务提供商应采用适宜的方法来监视服务管理流程，并在适当时进行度量。这些方法应证实流程实现所策划的结果的能力。管理者应按策划的时间间隔进行评审，以确定服务管理要求是否：a) 符合服务管理计划及本标准的要求；b) 得到有效实施与保持。应策划审核方案，策划时应考虑拟审核的流程和区域的状况和重要性以及以往审核的结果。应在程序中规定审核的准则、范围、频次和方法。审核员的选择和审核的实施应确保审核流程的客观性和公正性。审核员不应审核自己的工作。应记录服务管理评审、评估和审核的目标、发现，以及识别的任何整改措施。应与相关方沟通不符合或关注的重要区域。4.4 持续改进（改进）目的：改进服务交付和管理的效率和有效性。4.4.1 策略应建立书面的服务改进策略，应补救任何与标准或服务管理计划的不符合/不合格。应规定清晰的服务改进活动的角色和职责。4.4.2 改进管理应评估、记录、排定优先顺序并授权所有建议的服务改进。应使用服务改进计划来控制服务改进活动。服务提供商应实施流程以识别、度量、报告并管理持续的改进活动。应包括：a) 流程所有者可使用日常的人力资源来实施单个流程的改进，即实施单个的纠正和预防措施；b) 跨组织或涉及多个流程的改进。4.4.3 活动服务提供商应采取下列活动：a) 收集并分析基线数据，升级组织的管理和交付服务管理能力；b) 识别、策划并实施改进；c) 咨询所涉及的所有相关方；d) 设定质量、成本和资源使用方面的改进目标；e) 从服务管理流程的所有方面考虑改进的相关输入；f) 评价、报告并传达服务改进情况；g) 需要时，更新服务管理策略、计划和程序；h) 确保所有的改进措施都被执行，并实现其预期目的。5 新服务或变更服务的策划与实施目的：确保在成本和质量的约束条件下，管理并交付新服务或服务的变更。新的或服务变更的方案应考虑由服务交付和管理所导致的成本、组织的、技术的和商业上的影响。新的或变更的服务的实施（包括服务终止），应进行策划并经过变更管理者的正式批准。策划和实施应包括服务交付和管理所需的资金和资源。计划应包括：a) 实施、运行和保持新的或变更服务的角色和职责，包括客户和供应商将实施的活动；b) 现有服务管理框架和服务的变更；c) 与相关方沟通；d) 新的或变更的合同和协议以与业务需求的变更保持一致；e) 人力资源和招聘的要求；f) 技能和培训的要求，如用户和技术支持人员；g) 将使用的与新的或变更的服务有关的流程、度量、方法和工具，如能力管理和财务管理；h) 预算和时间表；i) 服务接收准则；j) 以可度量的术语表达的、新服务运行的预期结果。在真正实施以前，新的或变更的服务应被服务提供商所接受。服务提供商应根据策划的安排，在新的或变更的服务实施后报告所取得的效果。应通过变更管理流程进行计划的实施后评审，即将真实的效果与计划的相比较。6服务交付流程6.1 服务级别管理目标：定义、协商、记录并能管理服务级别。所有方面应协商并记录：所提供的服务、相应的服务级别目标以及工作量特性。应在一个或多个服务级别协议（SLAs）中书面规定所约定的服务。所有相关方应协商并记录服务级别协议（SLAs）、支持性服务约定、供应商合同和相应的程序。服务级别协议（SLAs）应处于变更管理流程的控制之下。应通过所有相关方定期评审的方式来保持服务级别协议（SLAs），以确保服务级别协议的更新和持续有效。应根据目标来监视并通报服务级别，报告中应展示当前的信息以及发展趋势。应报告并评审不符合的原因。应记录这一流程中所确定的改进措施，并作为服务改进计划的输入。6.2 服务报告目的：为有效沟通和制定决策而及时编制的可靠的、准确的并达成一致的报告。每一服务报告应清晰阐明其标识、目的、目标读者以及数据来源。应编制服务报告以满足确定的需求和客户要求。服务报告应包括：a) 与服务水平目标相比较的业绩；b) 不符合及问题，即违反服务级别协议及安全违规；c) 工作量特征，即能力和资源使用率；d) 重大事件的业绩报告，即重大事件或变更；e) 趋势信息；f) 满意度分析。应考虑服务报告的发现并据此确定管理决策和纠正措施，并与相关方沟通。6.3 服务连续性及可用性管理目的：确保在所有情况下都可以实现向客户承诺的服务连续性和可用性。应基于业务计划、服务级别协议和风险评估来确定可用性及服务连续性要求。要求应包括访问权限、响应时间以及系统组件端对端的可用性。应开发可用性及服务连续性计划，并每年至少评审一次，以确保从正常情况到主要服务失效的所有情况下都可以满足要求。应保持这些计划以确保他们反映约定的、业务所需的变更。当业务环境发生重大变更时，应重新测试可用性及服务连续性计划。变更管理流程应评估变更对可用性及服务连续性计划的影响。应度量并记录可用性。应调查计划之外的不可用并采取适当的措施。注：可行时，应预测潜在的问题并采取预防措施。当正常的办公访问被阻止时，应确保服务连续性计划、合同列表和配置管理数据库的可用性。服务连续性计划应包括返回正常工作状态的内容。应依据业务需求对服务连续性计划进行测试。应记录所有的连续性测试，应在改进措施计划中简述测试失效的情况。6.4 IT服务的预算及核算管理目的：制定预算并核算服务提供成本。注：本节涵盖了IT服务的预算及核算管理。实际上，许多服务提供商都将涉及到对此类服务的收费。然而，因为收费是一个可选的活动，并未被本标准所涵盖。如果服务提供商进行收费，建议应充分规定进行该活动的机制，并被所有方面理解。使用的所有财务实践应与组织更为广泛的财务实践保持一致。应为下列活动建立清晰的策略和程序：a) 应为所有的组件（包括IT资产、共享资源、企业的一般管理费用、外部提供的服务、人员、保险和许可）制定预算并进行核算管理；b) 分配服务的间接费用和直接成本；c) 有效的财务控制和授权。应制定详细的成本预算，以确保有效的财务控制和决策制定。服务提供商应依据预算来监视并报告成本情况，评审财务预算并相应地进行成本管理。应计算服务变更的成本，并经过变更管理流程的批准。6.5 能力管理目的：确保服务提供商在任何时候都有足够的能力以满足与客户约定的、客户当前和未来的业务需求。实施能力管理，应编制并保持能力计划。实施能力管理阐述业务需求并包括下列内容：a) 当前和预测的能力和绩效要求；b) 识别服务升级的时间表、限度和成本；c) 评价预期的服务升级、变更请求、关于能力的新技术和方法的影响；d) 预测外部变更的影响，如立法机构；e) 预测分析所需的数据和流程。应确定监视服务能力、协调服务业绩和提供充足能力所需的方法、程序和技术。6.6 信息安全管理目的：在所有服务活动中有效管理信息安全。注：ISO/IEC17799信息技术安全技术信息安全管理指南提供了关于信息安全管理的指南。经过适当授权的管理者应批准信息安全策略，并传达给所有相关人员，适用时与客户沟通。应实施适当的安全控制以：a) 实施信息安全策略的要求；b) 管理与服务或系统访问有关的风险。控制措施应形成文件，阐述相关的风险以及控制措施的运营和保持方式。在实施变更前，应评估控制措施变更的影响。有些组织可以访问信息系统和服务。有关这些组织的安排应基于正式的协议，协议中应规定全部所需的安全要求。应按照事件管理程序的规定记录安全事件，并尽快报告。应实施程序，以确保可以调查所有的安全事件并采取管理措施。应采取机制，以量化并监视安全事件和失效的类型、程度和影响。应记录流程所确定的改进措施，并作为服务改进计划的输入。7 关系流程7.1 总则关系流程阐述了两个相关的方面：供应商管理和业务关系管理。7.2 业务关系管理目的：基于对客户及其业务驱动的了解，形成并保持服务提供商与客户之间的良好关系。服务提供商应识别并记录服务的利益相关方和客户。服务提供商和客户应每年至少进行一次服务评审，来讨论服务范围、服务级别协议、合同或业务需求的任何变更，并按达成的时间间隔召开中间会议来讨论进展、成绩、问题和改进计划。这些会议应形成书面的会议记录。也可邀请其他的服务利益相关方出席会议。如果出现合同变更，那么适当时在这些会议上应讨论服务级别协议变更的问题。这些变更应遵循变更管理流程。服务提供商应了解业务需求及重大变更，从而为响应这些需求做好准备。应建立投诉处理程序。应与客户协商确定正式的服务投诉的定义。服务提供商应记录、调查、响应、报告并正式关闭所有的服务投诉。当不能通过正常渠道反馈投诉时，客户应获得其他的升级渠道。服务提供商应任命一人或多人负责管理客户满意和整个业务关系流程。应建立通过定期的客户满意度调查获取反馈并做出响应的流程。应记录在这一流程中识别出的改进措施，并作为服务改进计划的输入。7.3 供应商管理目的：确保服务提供商提供高质量的连续的服务。注1：本标准的范围不包括供应商的获取。注2：服务提供商可能使用供应商来提供部分服务。服务提供商需展示对这些供应商管理流程的符合性。下图给出了一个复杂关系的示例。供方1服务提供商（内部或外部）供方2业务关键供方3分包方图3：服务提供商与供应商的关系示例服务提供商应记录供应商管理流程，并为每一供应商指定合同管理者。应就供应商所提供服务的要求、范围和级别以及沟通流程与所有方面达成一致，并在服务级别协议或其他文件中书面记载。与供应商签订的服务级别协议应与业务的服务级别协议保持一致。应协商并书面规定所有方面使用的流程接口。应清楚规定关键供应商与分包方之间的角色及关系。关键供应商应能够展示确保分包方能够满足合同要求的流程。应建立合同或正式协议的重要评审流程。评审每年至少进行一次，以确保仍能继续满足业务需求和合同要求。适当时，合同或服务级别协议的变更应紧随评审之后或在其他要求的时间。任何变化应遵从变更管理流程。应建立解决合同争议的正式流程。应建立流程以管理服务的预期或提前终结或将服务转嫁给他方。应根据服务级别目标来监视和评审业绩。应记录在这一流程中确定出的改进措施并作为服务改进计划的输入。8 解决流程8.1 背景事件和问题管理尽管有着紧密的联系，但二者又相互独立。8.2 事件管理目的：尽快恢复约定的业务，或响应服务要求。应记录所有的事件。应建立程序来管理事件的影响。程序应规定所有事件的记录、优先排序、业务影响、分类、更新、升级、解决和正式关闭。应通知客户，使其了解其报告的事件或服务请求的进展情况，当不能达到约定的服务级别或无法完成约定的措施时应提前警告客户。事件管理所涉及的所有人员应都可以访问相关的信息，如已知错误、问题解决方案和配置管理数据库。应对重大事件进行分类并根据流程进行管理。8.3 问题管理目的：通过事件原因的预先识别、分析、管理直至关闭，来最小化对业务的影响。应记录识别的所有问题。应建立程序以识别、最小化或避免事件或问题的影响。程序应规定所有问题的记录、分类、更新、升级、解决和关闭。应采取预防措施，以减少潜在的问题，如事件数量和类型的趋势分析之后的后续活动。纠正问题的根本原因所需的变更应提交变更管理流程。应监视、评审问题的解决并报告其有效性。问题管理者有责任确保事件管理者可获得关于已知错误和已纠正问题的最新信息。应记录在这一流程中确定的改进措施，并作为服务改进计划的输入。9 控制流程9.1 配置管理目的：规定并控制服务和基础设施组件，并保持正确的配置信息。在进行配置管理的变更和策划时应采用综合方法。服务提供商应规定与资产管理财务流程的接口。注：财务资产会计不属于本章范围。应制定关于配置项及组件定义的策略。应规定每一项目应记录的信息，包括有效的服务管理所需的关系及文档。配置管理应提供可识别的服务和基础设施组件的识别、控制和追溯版本的机制。控制的程度应充分满足业务需求、失效的风险和服务的重要性。配置管理应为变更管理流程提供与变更请求对于服务和基础设施配置影响有关的信息。适当时，配置项的变更应是可追溯的和可审计的，如软件和硬件的变更和活动。配置控制程序应确保保持系统、服务和服务组件的完整性。应在发布到实际运行环境之前建立配置项的基线。数据配置项的主拷贝应控制在安全的物理或电子数据库中，并参见配置记录，如软件、测试产品和支持文件。所有的配置项应能被唯一的识别，并记录在CMDB（配置管理数据库）中。应严格控制对CMDB的升级访问。应主动管理并验证CMDB，以确保CMDB的可靠性和准确性。需要的人员应可获得配置项的状态和版本、位置、相关的变更和问题以及相关的文档。配置审计程序应包括记录偏差、发起纠正措施和结果报告的内容。9.2 变更管理目的：确保以一种受控的方式对变更进行评估、批准、实施和评审。应清楚规定服务和基础设施变更的范围，并形成文件。应记录并分类所有要求的变更，如紧迫、紧急、重大和轻微等。应评估变更请求的风险、影响和业务收益。变更管理流程应包括恢复和补救失败变更的方法。应批准并检查更新，并以受控的方式实施。应评审所有变更以确保成功以及实施后所采取的措施。应建立策略和程序，以控制紧急变更的授权和实施。计划的变更日期应作为制定变更和发布时间表的基础。时间表应包括批准实施的所有变更以及建议实施日期的详细信息。应保持时间表并与相关方沟通。应定期分析变更记录，以检测日益增多的变更级别、频繁发生的类型、出现的趋势以及其他相关信息。应记录变更分析所得出的结果和结论。应记录有变更管理所确定的改进措施，并作为服务改进计划的输入。10 发布流程10.1发布管理流程目的：交付、分发并追溯在发布到实际运行环境中的一个或多个变更。注：发布管理流程应与配置管理和变更管理流程综合管理。应与相关方协商发布策略并形成文件。发布策略应包括发布类型和频次。服务提供商应根据业务要求对服务、系统、软件和硬件的发布进行策划。应在所有相关方之间就如何启动发布计划达成一致，并经过他们的授权，如客户、用户、操作人员和支持人员。流程应包括一旦发布失败，返回或补救的方式。计划应记录发布的日期及可交付成果，并参见相关的变更请求、已知的错误和问题。应就这些情况与事件管理流程进行沟通。应评估变更要求对发布计划的影响。发布管理程序应包括配置信息和变更记录的升级和变化。应根据既定的流程来管理紧急发布。紧急发布流程应与紧急变更管理流程有接口。应建立受控的接收测试环境，以在分发之前建立并测试所有的计划发布。应设计并实施发布和分发，以确保在安装、处置、包装和交付的流程中保持硬件和软件的完整性。应度量成功或失败的发布。度量应包括发布之后于发布有关的事件。分析应包括对业务、IT运行和支持性人力资源影响的评估，并作为服务改进计划的输入。参考文献1 ISO/IEC 20000-2信息技术服务管理 第2部分：实施指南2 ISO/IEC 17799 信息技术安全技术 信息安全管理指南3 ISO/IEC 12207 信息技术 软件生命周期流程4 ISO/IEC TR 15271 信息技术 ISO/IEC 12207指南（软件生命周期流程）5 ISO/IEC TR 16326 软件工程 项目管理中应用ISO/IEC 12207指南6 ISO/IEC 15288 系统工程 系统生命周期流程7 ISO/IEC TR 19760 系统工程 ISO/IEC 15288使用指南8 ISO/IEC 155041信息技术 流程评估 第1部分：概念和术语9 ISO/IEC 155042信息技术 流程评估 第2部分：评估实施10 ISO/IEC 155043信息技术 流程评估 第3部分：评估实施指南11 ISO/IEC 155044信息技术 流程评估 第4部分：流程改进和流程能力确定应用指南12 ISO/IEC 155045信息技术 流程评估 第5部分：流程评估模型示例13 ISO 10007 质量管理体系 配置管理指南14 ISO 9000 质量管理体系 基础和术语15 ISO 9001 质量管理体系 要求16 ISO/IEC 9003 软件工程 计算机软件应用ISO 9001:2000标准指南IT服务案例历惊心48小时抢救35亿交易数据-IT服务没有小事，只有重视！以前总听说老大们遇到DOWN机的事情怎样怎样，多么急迫怎样怎样，但却一直没有感觉，总以为老大们言过其实。但是前不久一次真实的经历，让我终于对存储工程师这一职业有了更深层的认识 起因是某月某日某时，我的一个哥们准备在新上的IBM DS4800盘阵上做RAID，刚刚做完时钟同步，就看见客户方所有的技术人员一阵风似的全部冲进了机房，带头的主管劈头就是一句：你们干什么了？不待我们缓过神来，6、7个人就开始疯狂的查找各自负责的部分。“赶快，赶快，查找原因！” 在过后的几个小时情况调查的时候，我们终于知道，当时的盘阵上面存储着该客户35亿的交易记录和10条要人命的信息！然而，当我哥们完成时钟同步的操作后，盘阵上的所有Volumn Group全部不见！噩梦开始，35亿交易记录不翼而飞 只见客户方6、7个人分别查找各自的原因，数据库配置，光纤交换机，网络，主机上的应用，甚至电源、机柜都一一仔细检查过，统统没有问题。于是，所有人的目光都转向了我们：你们到底做了什么？ 我们一下子也没回过神：“只是，只是在还没有使用的盘阵上做了时钟同步，怎么会和生产系统扯上关系？” 大家的目光随即投向了连接KVM和盘阵的HUB。咦？上边怎么还有两根线缆？那么我们现在操作的这两根线缆是？生产系统盘阵上的！而且使用的是默认IP！.我的天！我们前面的操作是做在哪里了啊？为什么没有出现IP冲突？ 这时我们才意识到我们犯了什么样的错误：我们将KVM连在了生产系统的HUB上，对客户新上的盘阵DS4800和原有生产系统上的盘阵DS4300同时做了一个DEMO，并进行了时钟同步，于是，所有的Volumn Group掉下去了，生产停止了四处支援，各路神仙爱莫能助 搞清楚状况后，已经2个小时过去了。客户方的人也不再理我们，所有的人开始打电话，寻求技术支持。在此后的4个小时中，分别有来自各方的支持陆续赶到，其中包括原设备维护厂商，新设备厂商、总代。以及陆续到来的7位IBM的工程师。我哥们至少20次的向各路神仙说明故障原因，客户方也不停的展示目前盘阵的状况，但事情仍然陷入僵局 在我们感叹客户方主管巨大能力的同时，也被打入冷宫了，被安排在一个办公室里不能出来，更别说进机房。还好客户方还允许我们继续找人支持和打800报修，所以我也有机会看了一眼客户受重创后的盘阵，除了ROOTVG，其他的全都没了，就好像连在一个完全空白的新盘阵一样，我当时那个汗啊！ 回到办公室继续打800报修，提示音之后是长时间的废话，我一遍一遍的报上姓名地址，说明情况，无论你磨破嘴皮，只有一个结果：除了产品硬件故障不能派人解决。我狂晕！ 先来的是我们找的代理商方面的小型机和存储技术支持，分别来的3个人同一个看法，这些操作按道理不会出现这样的状况，除了重新启动下看看情况以外好像都别无办法。 后来的总代技术明显要略胜一筹，从了解实情经过的方式和建议都是更加的谨慎，看得出来经验丰富。他在打电话给他的公司的时候加上意味深长的一句：记住这个教训吧。但是结论仍然是没有什么办法。 与此同时，公司通过其它渠道联系上IBM工程师，于是大家苦等IBM工程师。 在此之前总有耳闻，说现在的IBM工程师水平也是一般，于是在心理并没有对他们有多大的期待，心想用户就是迷信，干脆重起得了。事情发生后4个小时，所有人都看完了现场以后，IBM工程师到了。先是2位，再来又是2位，然后是3位。分别来自不同的TEAM负责不同的系统，有负责小机的，有负责存储的，还有售前方案的，但是他们在一起却能很好的协商和达成一致，没有人口出狂言或者轻举妄动。这里不得不客观评价，IBM工程师还是训练有素。 实在是我们的误操作愚蠢得太不可原谅，最后IBM的7位工程师也不敢贸然给出任何的动作和建议，唯一的举措就是将现场情况抓图整理，上传给2线。希望有人在线，能有解决的办法 然后，IBM的工程师也走了紧急预案，又出节外生枝 与此同时，客户方也临时召开紧急会议，经讨论后给我们公布了他们的紧急预案措施：冻结原有的业务存储系统DS4300，连夜在新的存储系统DS4800上做RAID，建Volumn Group，将所有应用和数据转移，先让系统跑起来，数据再说。于是，大家纷纷给家人电话或者短信“今晚通宵加班，我不回去了。“ 这时回到那两台为了配置它们而闯祸的DS4800面前，它们却吓得再不敢抬眼看我们，死活就是不和我们的管理系统连接。气得我?#￥% 客户算是有水平了，并没有在这个时候追究责任。而是让我们去处理问题，如果这个问题都没处理好。那，那。 看来连DS4800也指望不上的时候，一直在一边帮助客户协调跑前跑后的我们公司的销售经理突然对我说：“你跑一趟，和XXX联系，这是电话，拉一台DS4300回来，再带6块300G的硬盘，就对他说是X总叫你来取的。”我当时那个乐啊！赶紧屁颠屁颠的就打车过去了（那时都半夜了）。到了销售说的地方，领到机器，也顾不得新洗的白衣服了，和司机、库管一起把机器扛到了车上。 车刚要发动返回客户现场，就收到销售的短信：硬盘拿了么？车还没开到客户大门，老远就看见销售在门口蹲着等着了所有的人都在期待这台DS4300，但是，新拉来的DS4300却没有接上 原来，在场的人七手八脚的把这台救命稻草DS4300抬上楼，打开箱子一瞅，乐了。原来打算用6块300G的硬盘做临时空间有点紧张，只能做RAID5，不能做hotspare，没想到上面整整齐齐的插着7块146G的硬盘，再加上6块300G硬盘，嘿，这下够了！ 销售在这个时候还不忘打趣：“慢点慢点，这可是咱们的最后一棵救命稻草，有了它我就算是有了一条活路，没它我就得从这窗户口跳下去了。嘿嘿。”要知道，当时我们可是在19层的机房啊。 上好架，通上电，开始练。第一个分区100G，ok！第二个分区，400G，咦？怎么出错了？ 再来一遍还是不行！这时候，一直镇定的，老练的，不懂技术的销售一直直勾勾瞅着屏幕，憋不住了问一句：“这是怎么回事？”操刀的哥们没有回答，让我把某一块盘拔出来，等一下再插上故障依旧，关掉再开盘柜故障还是依旧柳暗花明，35亿交易数据失而复得 销售看不下去了，但是毕竟好涵养，压了压焦虑的心情，拉我到外面抽烟去了。烟雾缭绕中，给我讲了上次误操作将一所大学的学籍档案全部删除的事情。最后，掐灭了烟头：“走，回去看看！” 回到机房，RAID居然已经做好了。问了我哥们，原来是这样：这台DS4300上原来的几块盘是做过RAID的，但是缺少了一块。于是盘阵总认为后来插上的硬盘就是原来缺的那块硬盘，但实际上不是，而且我们还插了不止一块盘，所以就出错了。 哥们将所有的盘都拔出去，再将盘阵重起，清除里面的信息，再关闭，把盘都插回去，就一切OK了。 哦，这样啊！心算是放回肚子里了。再接着就是普通的划区后的工作，忙到了天亮。 这边问题暂时解决了，但原来的阵列还一动不动躺在那里，里面的数据仍然没法儿拿出来，所有人的希望也就寄托在IBM的二线上，希望他们能够拿出最佳的解决方案来。 第二天早上9点整，IBM的工程师来了，并且带来了2线的解决方案。很可惜具体的操作方式他们不肯透露，大意是将上面的RAID按照原来最初的重新做一遍。由IBM的工程师讲解方案，客户方系统维护人员操作。整个恢复过程中，现场气氛紧张啊，连插拔光纤的动作都做得极为谨慎，所有操作完成后，一查看，35亿的交易数据总算是失而复得！ 当时那个兴奋啊，要是有蛋糕都能开个PARTY！然后是一些后续的工作，又忙了大半天才结束。 走出客户的大厦时正是第二天中午，我这才意识到已经2天没有看到这轮太阳了，沐浴在久违的阳光下，发现周围的一切都是这样的美好！后记：噩梦方醒不忘经验教训 曾经听老大们讲过，小型机和存储盘阵的操作都极为复杂，很多地方和PC机器完全不同。操作PC机的，可以经常自己尝试和摸索，但在小型机和存储系统上瞎鼓捣就是自己找死。只要做过客户系统维护的人员都能深切感受到这份压力，不少都曾经亲身经历过这种要人命的时刻。曾经听说过有人深夜3点打车去五百里之外，和夜里9点打车去千里之外的情况，一旦客户系统发生问题，影响业务运营，就是打飞机也一定要赶到客户现场。 还有一个问题就是，由于实施维护的时候压力大强度大，所以经常工作到深夜，加上开的窗口会比较多，这个时候是极易出现人为错误的时候。所以老大们告诫我们，再复杂的工作一定要一步一步按部就班，另外每做一步操作，保留数据的备份是极其重要的，否则敲错一个命令，就有可能带来追悔莫及的损失，而这样的例子也的确不在少数。 上周四刚刚将借来的那台DS4300还了回去，仍然记得那天打车去取这台机器的紧张劲儿。心中不免还是有点那么担心：如果给的方案不好用呢？如果这台备机不好使呢？如果在后面长时间、高负荷、紧张的情况下操作失误呢？如果再有其他设备的损坏？如果我实在不敢想象下去了。如果，这件事能给所有的同行一点帮助，我就会很欣慰了。评价：噩梦开始往往是细节的疏漏，文章开始于一个小的疏忽，接踵而至是各路神仙爱莫能助的技术问题。面对这样的严重事件，从ITIL角度看，应该算是启动了紧急预案。没有循规蹈矩地走事件、问题处理流程，只有现场的特殊处理流程。从文章对事件的描述过程没有看出慌乱，虽然实际过程一定很紧张，但是看得出处理的步骤仍然是井井有条。“分别来自不同的TEAM负责不同的系统，有负责小机的，有负责存储的，还有售前方案的，但是他们在一起却能很好的协商和达成一致，没有人口出狂言或者轻举妄动”文中对IBM工程师的评价可以作为IT服务协同合作的标准了。不同的部门却能在在处理问题上达成一致，没有推脱，没有看笑话的成分。问题解决了，再回到文章的开头。KVM连接的时候为什么没有人注意到连错了HUB？也许这是一个业务上的疏漏，也许是人的疏忽。业务疏漏再追溯一下，可能是没有一个明确的流程来指导服务器作Raid操作，工程师们象往常一样凭经验操作，但没想到这一次出了大纰漏。因为凭成功经验的做法导致事件严重的几率较少，所以很多时候我们仍然相信经验，而忽视对流程、步骤的重视。认为那是多余、繁琐、呆板和没有创造性的。“出来混迟早要还的”无间道的这句话在ITSM同样适用。只是不同的领域对这句话的体会各有不同，类似这次35亿交易数据的存储领域的体会可谓刻骨铭心。他们下次一定会老老实实地按照“多余、繁琐、呆板和没有创造性的”的流程和步骤去作Raid。但是其它不一定带来“刻骨铭心”领域呢？他们是否愿意这么做，还是依然认为“多余、繁琐、呆板和没有创造性的”？这是最可怕的！人的疏忽造成严重事件发生。有严格的流程和步骤但依然我行我素。也许是因为凭经验从来没有失过手，没有撞到南墙，他们是不会回头。对于此，真的没有什么好的办法。只有等到他们亲自体验到“刻骨铭心”的教训之后才能意识到未雨绸缪的真正含义。所以，惊心动魄的48小时抢救35亿交易数据的故事还会再发生。贴上这篇文章的用意在于警告自己：IT服务没有小事，只有重视！ 培训练习题1. ISO20000总体理解选择题：1) ISO20000在IT服务管理中扮演什么样的角色？A. 提供一种基于最佳实践原则的方法B. 作为IT服务管理的国际标准C. 作为IT服务提供的标准模型D. 作为流程设计的理论框架2) 什么是IT服务管理？A. 经济有效地管理IT服务的质量B. 根据ITIL最佳实践进行IT基础设施的管理工作C. 以流程的方式管理IT基础设施。这种方式可让IT组织能够以专业的方式为客户提供IT产品和服务D. 促进更多的人了解IT服务3) IT服务管理是如何改善IT服务的质量的。A. 以正式的内部、外部客户以及供应商的服务协议B. 定义服务级别普遍适用的标准C. 提高IT组织中所有员工的客户关注程度D. 计划、实施、管理一系列流程以提供IT服务4) 硬件、系统和应用软件以及数据通讯设施都是IT基础架构（IT infrastructure）的组成部分。下面哪些组件也可以被视为IT基础架构的一部分？1 程序2 文档3 人员A. 1和2B. 1和3C. 2和3D. 1，2和35) 在某个保险公司里，由于电力的中断导致局域网和所有PC都宕机了。因此，该公司的业务受理系统和理赔系统都不能正常使用。一个小时后，电力中断的故障被解决了，服务也恢复至电力中断之前的状态。该事件对服务提供造成了哪种影响？A. 影响很小，因为在一个小时内客户就被告知电话通知可以继续办理业务了，并且客户对这种情况表示理解。B. 影响重大，因为该事件使得正常的服务提供不能实现。这对公司的形象造成了损害。C. 没有影响，因为所有的数据都可以先记录在纸质文档上并可以在电力恢复后在录入系统。D. 影响非常小，因为该事件是由电力故障而不是硬件或软件错误引起的。思考题：组织实施IT服务的首要目标是确保IT服务和业务需求保持一致，这一目标可通过哪些方面实现？2. 服务级别管理与服务报告：选择题：1) 服务级别经理已经与客户签订服务级别协议（SLA），但IT部门却不能满足服务级别协议（SLA）中规定的要求。导致这种情况出现的主要原因是采购部门每个月只购买一次硬件，而IT部门经常不能等到那个时候才拿到所需要的硬件，因为服务级别协议（SLA）已经规定要“按需”供应。为了避免这种情况，IT部门应与购买部门共同签订或审查哪些问题？A. 运作级别协议（OLA）B. 服务级别需求（SLR）C. 服务说明书