信息技术服务ISOIEC20000-2018版带条款解析

这是一篇关于信息技术服务ISO/IEC20000-2018版带条款解析思维导图，包含条款理解、专用术语、系列标准等。

信息技术服务 ISO/IEC20000

• 系列标准
  • ISO/IEC20000-1 服务管理体系要求
  • ISO/IEC20000-2 服务管理体系实施指南
  • ISO/IEC20000-3 ISO/IEC20000-1范围定义和适性指南（2019版）
  • ISO/IEC20000-4 过程参考模型
  • ISO/IEC20000-5 ISO/IEC20000-1实施计划示例
  • ISO/IEC20000-6 对服务管理体系进行审核和认证的机构的要求
  • ISO/IEC20000-7 ISO/IEC：20000-1:2018与1SO9001:2015和ISO/IEC：27001:2013的整合和关系指南
  • ISO/IEC20000-8 过程评模型
  • ISO/IEC20000-9 将ISO/IEC20000-1应用于云服务的指南
  • ISO/IEC20000-10
• 专用术语
  • 资产 asset
    • 对组织具有潜在或实际价值的元素、事物或实体
    • 注1：价值可以是有形的或无形的、也可以是金融的或非金偢的，包括对风险和负偾的考虑。在资产寿命的不同阶段，它可以是正面的，也可以是负面的。
    • 注2：实物资产通常是指组织拥有的设备、库存和财产。实物资产与无形资产相反，无形资产是非物质资产，如，和租约、品牌、数字资产、使用权、许可、知识产权、声誉或协议等。
    • 注：资产也可以是配置项（configuration item：需要加以控制以提供服务的元素。），但某些配置项可能不是资产。
  • 外部供应商 external supplier
    • 与组织签订合同， 参与规划、设计、转换、交付或改进服务、 服务组件或过程的组织外部方。
    • 注：外部供方包括规定的主要供方， 但不包括其分包供方。
    • 注：组织的外部组织
  • 内部供应商 internal supplier
    • 较大组织中 SMS范围之外的一部分、该部分签订有文件化协议以促进规划、设计、转換、交付或改进服务、服务组件或过程。
    • 例如：采购、基础设施、财务、人力资源、设施等（部门） 注 : 内部供方和 SMS范围内的组织都是同一个大型组织的一部分。
  • 事件 incident
    • 服务的意外中断以及导致服务质量下降但尚未对客户或用户的服务产生影响的事项。
  • 信息安全事件 information security incident
    • 由单个或一系列意外或有害的信息安全事态所组成，极有可能危及业务运行或威胁信息安全
    • 信息安全保护信息的保密性、完整性和可用性。
  • 已知错误 known error
    • 己找到根本原因，或已找到减少、消除其对服务影响方法的问题。
  • 问题 problem
    • 一个或多个实际或澘在事件的原因。
  • 发布 release
    • 作为-个或多个变更的结果，部署到运行环境的，服务或服务组件以及新服务的一个或多个变更的组合。
  • 变更请求 request for change
    • 对服务、服务组件或 SMS 进行变更的提案。
    • 注 : 服务的变更包括新服务的提供、服务的迁移以及不再需要的服务的下线。
  • 服务目录 service catalogue
    • 组织向其客户提供的服务的义什化信息。
  • 服务组件 service component
    • 服务的一部分，与其他元素组合提供完整的服务。 例如：基础架构，应用程序，文档，许可证，信息，资源、支特性服务
    • 注：服务组件可以包括配置项、资产或其他要素。
  • 服务级别协议 service level agreement; SLA
    • 组织和客户之间，用于定义服务及其达成一致的绩效所签署的文件化协议。
    • 注 1: 组织与外部供方，内部供方或作为供方的客户之间也可以建立服务级別协议。
    • 注 2: 服务级別协议可以包含在合同或其他类型的文件化协议中。
  • 服务级别目标 service level target
    • 组织承诺的服务的具体可衡量特征。
  • 服务管理 service management
    • 指导和控制用于规划、设计、转换、交付和改进服务的组织的活动和资源以实现价值的一系列能力和流程。
    • 注：本标准通过条款和子条款提供了一组要求。每个组织都可以选择如何将这些要求组合到流程中。其中，子条款可用于定义组织 SMS 的过程。
  • 服务请求 service request
    • 信息获取、咨询、服务访问或预授权变更等请求。
  • 转换 transition
    • 将新的或己变更的服务移入或移出运行环境所涉及的活动。
• 条款理解
  • 前言
    • “组织”是服务管理体范围内管理和交付服务给客户的组织。服务管理体系范開内的“组织”可能是组织的一部分，例如大型公司的一个部门。管理和交付服务给客户的组织或者组织的一部分也可以称作服务提供者。
    • 当组织声称符合本标准时，不管组织的性质如何，不能减 4~10 章的内容。其中 4-5 章的内容要求组织自身提供符合本标的证据。不能由其他方提供。6~10 章的内容可以由其他方提供支持，但需要满足 8.2.3 提出的条件。
  • 4组织环境
    • 4.1了解组织及其环境
      • 组织应确定与其意图相关的，且影响其实现 SMS 预期结果能力的外部和内部事项。
      • 内部因素，包括组织的价值观、文化、知识和绩效。例如，内部审核结果和自我评价结果、质量成本数据分析、技术趋势信息分析、容户反馈、投诉、评审结果、实际和预期的内部价值观和文化、组织绩效等。
      • 外部因素，包括国际，国家，地区和当地的政治，经济，社会，法律，科技、克争、市场和文化的各类环境素。例国际贸易条件、法律法规、经济环境和发展趋势等。
      • 说明： 1.因素可包括需要考虑的正面的和负面的要素或条件； 2.它时刻发生着变化，需要定期监视组织的环境、特別是其对组织的目标造成影响的变化和趋势。
    • 4.2了解相关方的需求和期望
      • 组织应识別：与SMS 和服务相关方；这些相关方的相关要求。 注：相关方的要求可能包括服务、绩效以及与 SMS 及服务相关的法律、法规要求和合同义务。
      • 说明： 1.可以包括组织服务管理体系范围外的一部分，如客户、用户、社区、外部供应商、监管机构、公共机构、非政府机构、投资者或员工。 2.相关方要求表达的形式是不同的、多样的，形式主要体现为合同、协议、信函、建议、会议纪要等。
    • 4.3确定服务管理体系的范围
      • 组织应确定 SMS 的边界和适用性，以确定其范围。 在确定此范围时，组织应考虑 a)4.1 提到的外部和内部事项 b)4.2 中提到的要求 c）组织提供的服务。 SMS 范围的定义应包括范围内的服务以及管理和提供服务的组织名称。 SMS 范围应形成文件化信息并可用。 注1: ISO/IEC20000-3提供了有关定义范围的指导。 注 2: SMS 范围定义声明了哪些服务属于范围。可以是组织所提供的全部或部分服务。
      • 范围举例： 1.组织范围：本体系适用于 XX 公司所有和 IT 服务业务相关的部门和人员，具体涉及的部门请参考组织结构。 2. 地点范：位于市メメ区メ路メメ大厦メ层。 3. 服务范围：提供网络系统、数据库系统和应用系统、服务器的维护服务。
    • 4.4服务管理体系
      • 组织应根据本标准的要求建立实施、维护和持续改进 SMS，包括所需的过程及其相互作用。
  • 5 领导力
    • 5.1领导和承诺
      • 最高管理层应通过以下活动，证实对 SMS 的领导和承诺: a）确保建立了服务管理方针和服务管理目标，并与组织的战略方向保持致； b）确保建立、实施和维护服务管理计划，以支持服务管理方针，实现服务管理目标和服务要求； c）确保分配适当级別的权限以做出与 SMS 和服务相关的决策； d）确保组织及其客户所应获得的价值得到确定 e）确保对服务生命周期中所涉及其他各方的管控； f）确保将 SMS 要求整合到组织的业务流程中； g）确保 SMS 和服务所需的资源可用； h）沟通有效服务管理、实现服务管理目标、提供价值并符合 SMS 要求的重要性； i）确保 SMS 达到预期结果 j）指导并支持相关人员为 SMS 和服务的有效性做出贡献 k）促进 SMS 和服务的持续改进； l）支持其他相关管理角色，以证实其适合于共责任范围的领导作用 本标准中对“业务”的引用可以广义地解释为对组织存在的目的而言是那些核心的活动。
      • 理解：强调最高管理者在 IT 服务管理体系中的角色和作用，确保通过 8 个确保、1 个沟通、1个指导、1 个促进、1 个支持实现管理体系的预期结果。
    • 5.2 方针
      • 5.2.1 建立服务管理方针 最高管理层应建立服务管理方针，该方针应： a) 与组织意图相适宜； b) 为设定服务管理目标提供框架； c) 包括对满足适用要求的承诺； d) 包括对持续改进服务管理体系及服务的承诺。
      • 5.2.2 沟通服务管理方针 服务管理方针应： a) 形成文档化信息并可用； b)在组织内得到沟通； c)适用时，对相关方可用。
      • 理解：方针是由组织最高管理者正式发布的工作意图和方向，对内是行动的方向和准则，对外是行为的宗旨和承诺。标准要求最高管理者应制定服务管理方针，并且保持服务管理方针的持续适宜，方针还应与组织的战略方向保持一致。
      • 5.3 组织的角色，责任和权限 最高管理层应确保与服务管理体系及服务相关岗位的责任和权力在组织内得到分配和沟通。 最高管理层应分配责任和权限，以： a) 确保服务管理体系符合本标准的要求； b) 向最高管理者报告服务管理体系绩效。
        • 明确要求最高管理者对相关岗位的职责权限进行分配，并确保这些人员及其他相关人员得以正确理解，职责权限分配时可考虑如下内容： ——业务过程及其有效性的需求； ——现有组织结构、方针、内部制度和岗位工作需求； ——现有人员能力及资格状况，需确保分配的职责和所需能力及资格相一致； ——可支配的资源方面，包括人员、设备设施、技术、资金等 职责权限的分配应能满足IT服务管理体系的要求，角色分配应考虑过程活动的需要。以确保过程输出能实现预期。应分配向最高管理者及组织内部报告 IT 服务管理体系绩效及其改进机会的人员及职责。职责权限的分配应有利于以顾客为关注焦点的实现。也应确保 IT 服务管理体系在变更时的完整性。例如，一个职责跨多个部门的调整，而人员不动，容易造成某些工作的不连续性。
  • 6规划
    • 6.1应对风险和机遇的措施
      • 6. 1. 1 当规划服务管理体系时，组织应考虑到4.1 中提及的事项和4.2 中提到的要求，并确定需要应对的风险和机遇，以： a) 确保服务管理体系可达到预期结果； b) 预防或减少不良影响； c) 实现服务管理体系的持续改进。
      • 6. 1. 2 组织应确认和文件化： a) 有关的风险： 1) 组织； 2) 不满足的服务要求； 3) 服务生命周期中相关方的参与； b) SMS 服务的风险和机遇对客户的影响； c) 风险可接受的标准； d) 风险管理使用的方法。
      • 6. 1. 3 组织应规划： a) 应对这些风险和机遇的措施，并确定其优先级； b) 如何： 1) 将这些措施整合到服务管理体系过程中，并予以实现； 2) 评价这些措施的有效性。 注1: 应对风险和机遇的选项包括：规避风险、承受或增加风险以追求机遇、消除风险源、改变风险的可能性或后果、通过约定的措施减缓风险、与其他方分担风险或通过正式的决定接受风险。
      • 1.风险就是不确定性的影响，即在一定坏境和一定时期内客观存在的、影响组织目标和预期结果实现的各种不确定性因素。不确定的影响可以是正面或负面的。 2.在ISO/IEC20000-1:2018 中有如下条款涉及“风险和机会”： 1)前言解释机会风险思维的概念； 2)术语：3.1.20风险，3.2.1 资产，3.2.29 价值； 3)第 6 章要求组织识別与服务管理相关的风险及机会，并制定适宜的应对措施。 ——6.1.1 策划服务管理体系：组织应考总 4.1 所描述的素和 4.2 所提及的要求，确定需要应对的风险和机会； ——6.1.3组织应策刘：a）应对风险和机会的措施及优先级。 ——6.3 策划服务管理体系，计划应考点到服务管理方针，服务管理标准，风险与机会，服务要求和本标准的要求。 4) 第 8 章要求组织确定并提供所需的服务组合时考虑风 ——8.2.2 策划服务：考虑已知限制和风险，组织应提议服务变更，以便服务于服务管理方针、服务管理目标和服务要求保持一致。 ——8.3.4.1 管理外部供应商：组织应评审外部供应商的服务等级标准或者其他合同义务与客户的服务级別一致，还应管理已识別的风险。 ——8.5.1.3 变更活动管理：组织和相关方应就变更请求的授权和优先级做出决策。决策应考虑风险、业务收益、可行性和财务影响。 ——8.7.1 服务可用性管理：按策划的时间间隔，与服务可用性有关的风险应予以评估和保留形成文件的信息。协定的要求应考虑相关的业务要求、服务要求、SLA和风险。 8.7.2 服务连续性管理：按策划的时间间隔，与服务连续性有关的风险应予以评估和保留形成文件的信息。组织应确定服务连续性要求。协定的要求应考虑相关的业务要求、服务要求、SLA 和风险。 ——8.7.3 信息安全管理 5) 第 9 章绩效评估中要求管理评审中考虑风险 ——9.3 管理评审中“K）风险评估的结果、应对风险和机会措施的有效性。”
    • 6.2服务管理目标及其实现规划
      • 6.2.1 建立目标 组织应在相关职能和层级上建立服务管理目标。 服务管理目标应： a) 与服务管理方针保持一致； b) 可测量； c) 考虑适用的要求； d) 得到监视 e) 得到沟通； f)适当时更新。 组织应保留有关服务管理目标的文档化信息。
      • 6.2.2 规划以实现目标 在规划如何达到服务管理目标时，组织应确定： a) 要做什么； b) 需要什么资源； c) 由谁负责 d) 什么时候完成； e) 如何评价结果。
        • 组织应在相关职能、层次和服务管理体系所需的过程设定服务管理目标、对过程设定服务管理目标是本标准明确提出的新要求。 服务管理目标建立和服务管理目标达成的策划，可帮助组织达成行动的一致性。组织可通过策划：要做什么（Which），需要什么资源（What), 由谁负责（Who），何时完成（When）、如何评价结果（How），即“4W1H”活动，来规定组织为策划实现服务管理目标所要做的活动，对服务管标及其实现的策划，遵循策划一评审-落实要求-检查改进。
      • 6.3 规划服务管理体系 信息技术－服务管理－服务管理体系要求1S0/IEC 20000-1 :2018 组织应创建、实施和保待一个服务管理计划。计划时应考虑服务管理方针、服务管理目标、风险与机遇、服务要求和本标准的要求。 服务管理计划应包括以下内容或包含一个相关索引： a) 服务列表； b) 影响服务管理体系的已知限制； c) 例如相关策略、标准、法律法规和合同要求的义务以及这些义务如何在SMS 和服务中得到履行； d) 服务管理体系和服务的权力和责任； e) 运行服务管理体系和服务所需的人员、技术、信息和资金资源； f)在服务生命周期中，与涉及的其他方合作的方法； g)用以支持SMS 的技术； h) 如何进行SMS 和服务有效性的测量、审核、报告和改进。 其他规划活动应与服务管理计划保持一致。
        • 1.重要的是虑参与生命周期的其他各方合作的方法。 2.ITIL将信息技术服务的生命周定义为 5 个阶段，包括服务战略、服务设计，服务转換、服务运行和持改进。当信息技术服务处于不同阶段时，会有相应的流程和规范。
          • 
  • 7 支持
    • 7.1 资源 组织应确定并提供建立、实现、维护和持续改进服务管理体系和运行服务以满足服务要求和实现服务管理目标所需的人员、技术、信息和资金资源。
      • 1.资源可以包括人力资源、基础设施、过程运行环境、监视和测量资源、也可包括技术和财务资源、组织的知识等。 2.在确定所需资源时，组织应考虑目前的能力和局限性，例如现有材料、人力资源及其能力、机械设备、信息通信系统和设施能否满足运行的要求等；若不能满足、组织宜对需要什么资源和确保资源提供做出决策、包括外部提供的资源，以达成对资源的需求。
    • 7.2 能力 组织应： a) 确定在组织控制下工作人员的必要能力，这些能力会影响组织SMS 和服务的绩效和有效性； b) 确保上述人员在适当的教育、培训或经验的基础上能够胜任其工作； c) 适用时，采取措施以获得必要的能力，并评价所采取措施的有效性；d) 保留适当的文档化信息作为能力的证据。 注：适用的措施可包括：例如针对现有雇员提供培训、指导或分配；雇佣或签约有能力的人员。
    • 7.3 意识 在组织控制下工作的人员应理解： a) 服务管理方针； b) 服务管理目标； c) 与他们工作有关的服务； d) 其对服务管理体系有效性的贡献，包括改进绩效带来的益处； e) 不符合服务管理体系要求带来的影响。
    • 7.4 沟通 组织应确定与服务管理体系和服务相关的内部和外部的沟通需求，包括： a) 沟通什么； b) 何时沟通； c) 与谁沟通； d) 如何沟通； e) 谁负责沟通。
    • 7.5 文档化信息
      • 7.5.1 总则 组织的服务管理体系应包括： a) 本标准所要求的文档化信息； b) 为服务管理体系的有效性，组织所确定的必要的文档化信息。 c) 不同组织相关服务管理体系文档化信息的详略程度可以是不同的，这是由于： 1) 组织的规模及其活动、过程、产品和服务的类型； 2) 过程、服务及其相互作用的复杂性； 3) 人员的能力。
      • 7.5.2 创建和更新 创建和更新文档化信息时，组织应确保适当的： a) 标识和描述（例如标题、日期、作者或引用编号）； b) 格式（例如语言、软件版本、图表）和介质（例如纸质、电子）； c) 对适宜性和充分性的评审和批准。
      • 7.5.3 文档化信息的控制
        • 7.5.3.1 服务管理体系及本标准所要求的文档化信息应得到控制，以确保： a) 在需要的地点和时间，是可用的和适宜使用的； b) 得到充分的保护（如避免保密性损失、不恰当使用、完整性损失等）。
        • 7.5.3.2 为控制文档化信息，适用时，组织应处理以下活动： a) 分发，访问，检索和使用； b) 存储和保护，包括保持可读性； c) 变更控制（例如版本控制）； d) 保留和处理。 组织确定的规划和运行服务管理体系所必需的外来的文档化信息，应得到适当的识别，并予以控制。 注：访问隐含着仅允许浏览文档化信息，或允许和授权浏览及更新文档化信息等决定。
      • 7.5.4 服务管理体系文档化信息 服务管理体系的文档化信息应包括： a) 服务管理体系范围； b) 服务管理的方针和目标； c) 服务管理计划； d) 变更管理方针、信息安全方针和服务连续性计划（一个或多个）； e) 组织的服务管理体系过程； f) 服务要求； g) 服务目录； h) 服务水平协议(SLA); i) 外部供应商的合同； j) 与内部供应商或作为供应商的客户签订的协议； k) 本标准要求的程序； |) 展示符合本标准和组织服务管理体系的相关证据需要的记录。 注：条款7.5 .4提供了服务管理体系的关键文档化信息清单。本标准中还有其他信息文档化的具体要求，对这些信息要进行文档化或进行记录。1S0/IEC 20000-2 提供了指南。
    • 7. 6 知识
      • 组织应确定并保持用以支持SMS 和服务运行的必要知识。 知识应是相关的，并对适当的人员可用并可获取。 注：知识是针对组织及其 SMS, 服务和相关方的。对知识进行使用和共享以支持实现预期的结果和 SMS和服务的运行。
        • 理解：2018版新增，组织知识是组织特有的知识，通常从其经验中获得，是为实现组织目标所使用和共享的信息。包括其内部自身发展生成的知识和外部对组织生存发展有用的知识。 组织识可基于： 1. 内部来源，例如，知识产权，从经验获得的知识，从失败和成功项目汲取的经验和教训，获得和分享未成文的知识和经验，以及过程、产品和服务的改进结果等； 2. 外部来源，例如，标准、学术交流、专业会议，从颐客或外部供方收集的知识等。 组织应鼓励根据不断变化的需求和趋势获取必要的知识。知识的更新瞬息万变，组织应随着内、外部环境的变化及时获取知识更新知识结构，确保可持续发展。
  • 8 运行
    • 8.1 运行规划和控制
      • 组织应规划、实施和控制必要的过程以满足要求，并依据如下要求，实施第6 章中确定的措施： a) 依据要求所建立的过程绩效指标； b) 实施过程控制以与建立的绩效指标保持一致； c) 保待必要程度的文档化信息以确保过程按照规划进行。 组织应控制对SMS 的规划变更并评审非预期的变更结果，必要时，采取措施减缓任何负面影响（见 8.5.1)。 组织应确保外包过程得到控制 （见8.2.3)。
        • 理解： 1.本条款的意图是对满足组织内外相关方要求的过程/流程(process)进行计划、实施和控制，这些过程是 6 章中所确定的行动的共性因素，通过共性因素可以规范、组合这些行动，并提高行动的工作绩效。这里有三个应明确的要点“相关方要”、“过程”、“行动”。 2.过程： ——体系认证的通用过程：文件与记录控制、内审、管理评审、持续改进； ——体系策划的宏观过程：组织环境识别、领导力策划、体系策划，以及体系运行的监视、测量、分析和评价； ——体系运行的具体过程：服务组合（服务交付、资产管理等）、关系与协议（业务关系管理、服务级别管理等）、供需（需求管理、容量管理等）、服务设计与转换（变更管理、发布与部署管理等）、解决与履行（服务请求管理、事件管理等）、服务保证（服务可用性、服务连续性等）； ——组织基本管理过程：如人力资源管理、采购管理、财务管理、供应链管理、生产运行控制等，不局限于支持 SMS。
    • 8.2 服务组合
      • 8.2.1 服务交付
        • 组织应运行服务管理体系，确保活动和资源的协调。组织应实施要求的活动以交付服务。 注：服务组合用于管理所有服务的整个生命周期，这些服务包括提出的服务，正在开发的服务，服务目录中所定义的正式提供的服务和已经下线的服务。服务组合的管理确保服务提供者有正确的服务组合。本标准中的服务组合活动包括服务规划、服务生命周期涉及的各方的控制，服务目录管理，资产管理和配置管理。
          • 目标：服务收益最大化，风险最小。 度量：建立关于服务风险和收益的度量方法（与9.1 SMS和服务的监视、测量、分析与评价结合)； 选择：服务选择和优先级方法，即面对市场与客户，选择哪些服务，怎样设定服务的优先级，对应服务规划8.2.2； 资产配置：明确哪些资产作为支持服务的资产，资产关系怎样等，资产投入是服务成本的构成，应予以优化，以最大化收益，最小化风险，对应资产管理8.2.5、配置管理8.2.6； 演进：一个服务经过建议、开发、运营、下线的完整过程，运营中的服务通常用服务目录表示，尤其是与特定客户签署合同所确定的"服务目录"，对应服务规划8.2.2、服务目录管理8.2.4： 管控：对生命周期中相关方进行管控，控制成本、降低风险，对应8.2.3； 支撑：财务管理是服务组合管理的关键输入，通过了解服务交付中采用的成本结构，公可能够确定成本基准。准确的成本计算需要了解财务信息、服务需求信息、组织的服务能力信息等、对应8.4.1。
      • 8.2.2 服务规划/策划服务
        • 已存在服务、新服务、服务变更的要求应确认和保留成文信息。 组织应基于组织、客户、用户和相关方的需求确认服务的关键性。组织应确认和管理服务间的依赖关系和复制关系。 考虑已知限制和风险，组织应提议服务变更，以便服务与服务管理方针、服务管理目标和服务要求保持一致。
          • 1.定期确定和记录处于不同进度状态下的服务及其要求（包括法律法规、合同及相关方的其他要求)，作为组织规划服务（作为服务组合管理的一部分）的依据。组织规划的服务可以是不针对特定客户，面向市场的服务，也可以是针对特定客户的服务。 2.现有服务通过服务目录呈现，新服务需要通过建议、开发等过程，成为可运营和交付的服务，服务变更通过现有或建立的SMS的变更管理予以管控。 3.服务重要性确定与如下因素相关：组织的收益和成本；客户的付费、服务所支持的业务重要性和收益、时间急性；用户的体验（如可用性等）；其他相关方的监管的合规性、供方的收益和成本等。可以针对特定客户或者围绕组织自身建立的服务重要性。无论哪种重要性均需建立评价模型予以分析评价。 4.设定优先级应考虑如下因素：产生变更请求和新服务或变更服务提议的业务需求；服务管理目标；实现变更请求和服务提议的投入和收益、风险；可用的资源；已知约束。
      • 8.2.3控制服务生命周期的相关方
        • 8.2.3.1无论任何相关方涉及到在支持服务生命周期中执行活动，组织应对本标准的要求和交付的服务负责。 组织应确认和应用本标准评估和选择服务生命周期中的其它相关方。其它相关方可以是外部供应商、内部供应商和客户充当的供应商。 其它相关方不应提供和运行服务管理体系范围内所有的服务、服务组件或流程。 组织应确认和文件化下列内容： a)其它相关方提供和运行的服务； b)其它相关方提供和运行的服务组件； c)其它相关方运行的服务管理体系范围内的流程或部分流程。 组织应集成组织自身或其它相关方提供和运行的服务管理体系范围内的服务、服务组件和流程，以满足服务要求。组织应进行协调包括服务生命周期中，策划、设计、转换、交付和改进活动的其它相关方。
          • 1.评估准则：应考虑其他各方对服务的影响，影响的决定性因素包括其他各方在服务生命周期中的职责、参与频率、组织付出的成本/费用、对服务收益和风险的作用等，应基于这些因素建立评估模型。 2.选择准则：应基于影响大小确定其选择他各方的优先级。 组织应确定并记录的内容，是在确定其他各方及其职责的基础上，对每一个其他各方建立其三种交付成果（即服务、服务组件、服务过程）清单，并将其与组织所承担的职责进行整合，以满足客户需求，并实现服务管理目标。其目标是提高服务效率，降低成本和风险，整合的方法和结果应通过配置管理实现。
        • 8.2.3.2组织应对其它相关方定义和应用下列控制措施： a)测量和评估过程绩效； b)测量和评估服务、服务组件满足服务要求的有效性。 注：1S0/1EC20000-3提供了服务生命周期中控制其它相关方的指南。
          • 1.服务和服务组件有效性的测量、评估应关注如下要点：服务满足需求的有效性指标包括对客户业务价值的满足程度，应以客户业务运营绩效指标为基础，确定服务对这些指标的作用，然后将其转换为服务可用性、信息安全、服务连续性等方面的有效性指标，服务可用性与容量、服务性能等密切相关；服务组件有效性指标（如可用性、信息安全等)是服务有效性测量的基础，需建立服务有效性指标与服务组件有效性指标之间的对应关系，采用完成服务所经过的组件路径，可建立对应关系。 2.客户业务、服务、服务组件之间的关系，可通过配置管理系统予以实现，并依此建立测量和评估模型。
      • 8.2.4服务目录管理
        • 组织应创建和维护一个或多个服务目录。服务目录应包括描述服务的组织、客户、用户和其它相关方的信息、它们预期的结果和服务间的依赖关系。 组织应对客户、用户和其它相关方提供合适的访问（部分）服务目录的渠道。
          • 1.服务目录中的服务包括业务服务和技术服务，业务服务由客户业务系统直接所需的计算能力构成，而技术服务由组织对客户业务系统提供的技术活动构成。 2.常见技术服务以信息资产类型为第一个维度，如服务器、网络设备、机房空调等；然后增加技术活动维度，形成一个个技术服务，如服务器安装与部署服务、服务器检查服务等；技术活动如下：安装与部署包括初始安装与部署、升级和补丁、改造、配置与测试、资产识别与监测、日常巡检与检查、故障处理、迁移、备份与恢复、审计与评估、废弃（卸载、断网、清除、入库、销毁）等； 3.发生服务转移、服务下线，新增服务等，组织应及时更新维护服务目录。
      • 8.2.5资产管理
        • 组织应确保管理用于交付服务的资产以满足服务要求和条款6.3c)规定的义务。 注：1S055001和1S0/IEC19770-1确定了支持实施、运营资产和IT资产管理的要求。 注：另外，资产作为配置项时，参考配置管理。
          • 1.资产指用于提供服务的资产，可能包括组织、客户、供方及其他方的资产，只要这些资产是交付服务不可或缺的。 2.信息资产分类：物理资产，如，计算机硬件、通信设施、物理支撑设施；信息/数据，如，文档和数据库；软件，如，应用软件、系统软件、开发工具与程序等；产生产品或提供服务的能力；人；无形资产，如，意愿、声誉等。 3.对资产应进行全生命周期管理，组织仅能对属于自身的资产进行完整的全生命周期管理，对其他方的资产，组织可以提出要求和建议，责任和管理工作归属于其他方。 4.组织应形成资产台账，并定期维护台账。资产台账属性通常包括资产大类、中类、小类、名称、编码、状态、责任人、位置、供方等，组织应根据实际情况，增加属性，如信息安全8.7.3中，资产应增加安全赋值属性。
      • 8.2.6配置管理
        • 配置项的类型应定义，服务应分类为配置项。 配置信息应记录到适合服务关键性和类型的详细程度，访问配置信息应受控。每个配置项的配置信息应包括： a)唯一性标识； b)配置项类型； c)配置项描述； d)与其它配置项的关系： e)状态。 配置项应受控，配置项的变更应可追溯和可审计的，以维护配置信息的完整性。配置项的变更发布后，配置项应更新。 组织应按计划的时间间隔，验证配置信息的准确性。如果发现偏差，组织应采取必要的行动。 适用时，配置信息应对其它服务管理活动可用。
          • 1.根据服务过程，可定义客户/用户、服务组织、服务目录与SLA及相关文档、服务、IT系统和资产等CI类型。 2.CI属性一般包括： 2.1标识类：配置项名称；配置项标识/标签（如可自动识别的条码）；配置项编号；版本号/型号/许可证号/拷贝号； 2.2定义类：配置项分类；配置项定义；配置项描述； 2.3关系类：配置项间的关系：父子关系、构成关系、集成关系、关联关系等；配置项和IT组件之间的对应关系；安装环境；供应商； 2.4管理类：状态；所在位置；责任部门/责任人（配置项所有者、维护管理者或保管者等)；配置管理员/批准机构（批准配置项的组织）；批准日期（配置项被组织批准的日期)；访问权限；成本；提供日期；维护服务期限； 2.5效用类：可用性指标；容量指标；安全性指标；连续性指标； 2.6构成类：在无需进一步细化构成的情况下，IT组件的构成（含特定属性）可作为配置项属性，如CPU利用率； 3.CI状态包括：已通过批准，但尚未上线（指部署于生产环境中）的配置项（尚未导入配置库中)，其状态包括：开发中/采购中、已测试、已验收； 在线配置项（处于配置库中）的状态包括：在用、停用、维护中（待变更等）； 下线、移除的配置项状态包括：已删除/已移除；租期已满（云服务）；已损坏。 4.CI应受控制，本条款的意图是组织应对CI的变更进行跟踪与审计，确保CI是受控的，CI信息与部署在系统中物理CI一致。 5.CI审计开展要求示例如下： 定期审查配置项，确保配置管理数据库中的信息完整、准确且更新及时，审计时应：重大变更实施后；灾难恢复后；其他检查或管理要求每年至少执行一次。 定期查看配置管理系统中的日志信息、审核操作记录，发现可疑情况立即报告，确保配置库的运安全性；定期组织对配置管理数据库的信息进行抽样检查，抽样应覆盖所有配置项分类。抽样比例遵循：总数少于10项的配置项，样比例为50%；总数在10~50项之间的配置项，抽样比例为20%；总数在50项以上的配置项，样比例为10%等。
    • 8.3关系和协议
      • 8.3.1总则
        • 组织可以使用供方： a)提供或运营服务； b)提供或运营服务组件； c)运行组织SMS中的流程或流程的一部分。
        • 1.组织与外部供方签署服务合同（其中界定服务要求)，与内部供方和客户（作为供方）签署满足服务要求的文档化协议。 2.对同一客户，不管有多少供方，所有供方的合同或文档化协议，最终都应与该客户的SLA保持一致。对特定客户SLA中的目标指标进行分解，得到供方的合同或协议中的目标指标。 3.注意：供方管理存在一个完整的生命周期过程，即供方初评、供方准入、采购（选择）、使用、监视、复评、退出等，采购之前的过程不在本标准范围内。
      • 8.3.2业务关系管理
        • 应识别和记录服务的客户用户和其他相关方。组织应指定专人（一个或多个）负责管理客户关系和维护客户满意度。 组织应建立与客户和其他相关方沟通的渠道。沟通应促进对服务运行的不断变化的业务环境的理解，并使组织能够响应新的或变更的服务要求。 组织应按计划的时间间隔，评审服务的绩效趋势和服务的结果。 组织应按计划的时间间隔，根据客户的代表性样本衡量对服务的满意度。应对结果进行分析、评审，以确定改进的机会并报告。 应记录、管理关闭和报告服务投诉。如果服务投诉未能通过正常渠道解决，则应提供升级方式。
          • 1.客户关系管理的核心是价值，即在客户识别、保存和发展的生命周期过程中，对客户价值的识别、保留和发展进行长期、持续的动态管理，实现双赢。价值判断包括：组织对客户提供的价值；客户对组织价值的贡献。 客户关系管理包括三个阶段：收集客户信息，建立客户资料库；对客户进行分类，开展大客户管理；满足客户需求，正确对待客户抱怨，培养忠诚客户。 2.业务环境指客户业务环境，包括政策、经济、技术、社会文化、客户、竞争对手等外部环境因素，以及组织愿景、战略目标、内部组织结构、人员职责、产品/服务、生产线运营、供应链管理、客户关系管理、应用系统和I基础设施等内部环境因素。 3.建立服务绩效指标的依据是服务管理目标6.2、服务交付8.2.1、服务级别协议中的目标指标8.3.3； 4.服务投诉是满意度评价的一部分，应有专人对服务投诉全过程进行管理，全过程包括投诉提起、接待和记录、处理、确认、关闭、报告等活动。投诉的渠道应该属于组织沟通渠道的一部分，应建立多种投诉渠道，正常渠道未能解决的，组织应提供其他渠道，以升级方式解决，如管理层热线等。
      • 8.3.3服务级别管理
        • 组织和客户应对所提供的服务达成一致。 对于每一交付的服务，组织应根据文件化的服务要求建立一个或多个SLA。 SLA应包括服务级别目标、工作量限制和例外。 组织应按计划的时间间隔，监督，评审和报告： a)与服务级别目标相对应的绩效； b)SLA中工作量限制与工作量实际状况和周期性变化对比说明。 如未能满足服务级别目标，组织应识别改进的机会。 注：组织与其客户之间提供服务的协议可以采取多利种形式，例如书面协议、会议中的口头协议记录、电子邮件指示协议或服务条款协议。
          • 1.对服务和SLA的监控要求如下：应根据SLA和服务目录明确需要监控的服务项；明确每个服务项的实施过程与关键活动（服务支撑的客户业务活动）。 对实施过程应获取实施操作的记录信息，包括：服务记录单，如事件单；工作日志；服务报告，如周报、月报等；客户满意度。 对关键活动，应获取信息系统状态信息，包括：负载情况、包括平均值、波峰与波谷值、周期性变化情况；物理状态；可用性、性能与安全状态；系统配置参数。 2.评价指标的目标值：服务/系统可用性指标；服务/系统性能指标；服务/系统安全性指标；服务/系统容量指标；服务/系统连续性指标，如RTO、RPO;服务执行指标，如每项任务的完成率、准确率和及时率等。 组织应根据采集的监控信息，估算评价指标实际值，与目标指对比，开展SLA评审、关于评审的要点包括：应明确评价方式，包括度量、统计方式；根据服务监控结果，逐项评价服务级别指标满足程度；给出SLA满足与否及满足程度的结论；根据SLA评价结论，确定SLA保持或变更要求。 3.应汇总评审结果，形成服务级别报告，报告主要内容包括：服务SA满足程度；客户满意度情况。 对不满足SLA的，识别不足原因，提出改进措施，包括：服务目录和服务级别优化；服务组织优化包括：岗位、人员；服务能力优化包括：技能、培训；服务流程优化；服务资源优化；服务时间安排优化；其他改进。
      • 8.3.4供方管理
        • 8.3.4.1外部供方的管理 组织应指定专人（一名或多名）负责管理外部供方的关系、合同和绩效。 对于每一外部供方，组织应有文件化的合同。合同应包括或包含对以下内容的引用： a)外部供方提供或运营的服务、服务组件、流程或流程部分的范围； b)外部供方应满足的要求； c)服务级别目标或其他合同义务； d)组织和外部供方的权力和责任。 组织应评估外部供方的服务级别目标或其他合同义务与客户SLA的一致性，并管理已识别的风险。组织应定义和管理与外部供方的接口。 组织应按计划的时间间隔，监视外部供方的绩效。如果未达到服务级别目标或其他合同义务，组织应确保改进机会得到识别。 组织应按计划的时间间隔，对照当前服务要求评审合同。在合同变更批准之前，应评估变更对SMS和服务的影响。 组织与外部供方之间的争议应予以记录并管理至关闭。
          • 1.供方绩效应根据其提供的成果建立绩效指标，并进行日常跟踪、监测和评价，以作为定期复评、持续选择或退出的依据。应以与客户签署的SLA(即整个服务绩效指标)为依据，考虑供方的职责及交付成果，结合配置管理8.2.6所建立的服务、服务组件、CI等之间的依赖关系，明确供方及交付成果在整个服务中的作用，最终确定绩效指标。 2.对外部供方的风险识别应以绩效偏离（与客户SLA偏离）为基准，具体包括：绩效直接偏离的风险；支持外部供方交付成果的人员、工具、资产、信息等缺失、不足或变更可能导致的风险，该风险最终还需通过绩效直接偏离的风险体现；外部供方管控的风险，如外部供方经营状况、倒闭情况、合规情况等。 3.与外部供方的接口包括人员之间的沟通接口、双方管理系统之间的接口（如客户关系管理系统、项目管理工具等）、运维管理工具(如双方使用的管理工具)之间的接口等。 4.定期评审外部供方对合同满足程度，以解决双方的争议、变更合同等间题。合同评审应有专职部门或人员定期组织开展，并由此明确双方是保持合同还是变更合同，对合同要求偏离大的外部供方，应采取退出措施。评估合同变更对SMS和服务的影响，应参见8.5.1.1的影响基准，影响大的应采取合适的应对措施，如对要退出的外部供方，应预先做好备用方案，重新设计和转换服务(8.5)。对于双方之间的争议，应按合同规定执行，直接解决和关闭问题。
        • 8.3.4.2内部供方和作为供方的客户的管理 组织应对于作为供方的每一内部供方或客户编制、商定和维护文件化协议，以定义各方之间的服务级别目标、其他承诺、活动和接口。 组织应按计划的时间间隔，监视内部供方或作为供方的客户的绩效。如果未达到服务级别目标或其他商定承诺，组织应确保改进机会得到识别。
          • 组织应与内部供方或客户签订协议，协议中应包括服务级别目标、其他承诺、活动和接口等内容。内部供方或作为供方的客户管理过程可参照8.3.4.1中的外部供方管理过程。 服务级别目标和绩效指标设立可参照外部供方服务级别目标、绩效指标等相关内容(8.3.4.1)。 协议的内容组织可参照外部供方合同相关内容(8.3.4.1)。接口的定义与管理可参照与外部供方接口相关内容(8.3.4.1)。 组织应定期监视、评价内部供方或客户的绩效，以判断是否达到服务级别目标或其他商定承诺，并要求外部供方改进。
    • 8.4供需
      • 8.4.1服务的预算和核算
        • 组织应根据其财务管理策略和流程对服务或服务组进行预算和核算。 成本应编入预算，以实现有效的财务控制和服务决策。 组织应按计划的时间间隔，对照预算监测和报告实际成本，评审财务预测并管理成本。 注：虽然很多组织对其服务收费，但不是全部。本标准中服务的预算和核算不包括收费，以确保适用于所有组织。
          • 组织应明确服务成本对象和成本分类，成本对象包括组织支持服务的工具和资产（软硬件）、人员、IT基础设施、场所等，成本分类包括直接成本、间接成本以及可分摊的间接成本，如：成本对象是否纳入成本估算中，取次于对象是否归属于组织，双方共享共建的部分属于可分摊的成本。 组织应定期监视、评价、报告实际成本，评审预算的有效性。
            • 
      • 8.4.2需求管理
        • 按照策划的时间间隔，组织应： a)确定服务当前需求和预测未来需求； b)监测和报告需求和服务使用情况 注：需求管理负责理解客户当前和未来的需求。能力管理与需求管理配合，策划和提供充足能力以满足需求。
          • 1.对服务需求进行管理，确保组织及时获取服务需求，尽可能将其转换为可签署SLA的服务，提高服务收益。 2.服务需求源于客户业务变化，需求获取是服务生命周期过程的起点。需求管理的关键是建立需求分析模型，对特定客户，模型主要包括以下内容： 输人：包括客户业务，客户IT系统和服务，如下： —一客户业务：区分客户的核心业务和支持业务，重点关注核心业务现状与发展趋势，尤其是业务容量变化趋势，应特别重视业务容量的时间敏感性，即业务容量的高峰期和特殊日期的业务容量（如互联网业务的双十一等日期）； 一一客户IT系统：升级改造、报废、资源容量情况（如有效使用率）、新技术采纳、新系统上线、应用迁移到云计算上等； 一一服务：已运行服务（客户服务目录中的服务）状况（包括服务有效使用率或消耗情况、服务对SLA满足程度、客户对服务定价的评价情况)、服务变更请求、客户对服务方评价与变更等。 输出：包括客户业务，客户IT系统和服务，如下： 一一客户业务：新增业务容量（含高峰期和特殊日期业务容量情况）及对计算能力或业务服务的需求； 客户IT系统：功能、性能、容量等新增和变更情况，以及对应的技术服务需求； 一一服务：退出的客户服务供方，客户核心业务运营绩效情况，对客户SLA满足情况、客户对服务性价比评价情况，以及新增服务需求、变更的服务需求； 新的服务需求或变更的服务雷求可能通过8.2.2得到确定和记录。 3.需求管理与容量管理密切相关，客户系统的资源容量变更可以产生业务服务(计算能力)需求和技术服务（如巡检、故障处理等）需求，这里的业务容量到资源容量的预测也适用于容量管理。 需求管理应与财务管理关联，将需求用财务数据量化，便于组织管理层预测和管理需求对财务的影响。 组织应部署或采用客户现有测工具.获取需求分析模型的输入数据，定期开展需求分析，形成需求分析报告，重点介绍客户现有服务消耗情况和新增的服务需求。 4.适当时，组织可将需求转化率（转换为正式SI,A)作为SMS的绩效指标。
      • 8.4.3容量管理（或能力管理）
        • 考虑服务和性能要求，人员、技术、信息和财务资源的能力要求应予以确定、保留成文信息和维护。组织应对能力进行策划，包括： a)基于服务需求，当前和预测的能力； b)对约定的服务等级目标、服务可用性、服务连续性要求的预期影响； c)能力变更的时间跨度和阀值。 组织应提供充分的容量满足商定的容量和性能要求。组织应监视能力的使用，分析能力和性能数据和识别改进机会。 注：能力又称容量，英文：capacity
          • 1.明确容量需求的来源，确定、记录和维护资源容量需求。容量需求的来源是服务和性能要求、而资源包括人力、技术、信息和财务四种资源。 2.考虑客户业务运营，组织应关注三个层级的容量，即业务容量、服务容量和资源容量，组织的成本最终体现在人力、技术、信息和财务四种资源的消耗上。 3.进行容量规划包括容量预测、所预测容量的预期影响、容量变化的时间尺度和阈值。 4.时间尺度(time scale)指完成某一利种物理过程所花费时间的平均度量。一般来讲，物理过程的演变越慢，其时间尺度越长。物理过程涉及的空间范围越大，其时间尺度也越长。服务容量变化的时间度可以当作服务容量变化的快慢程度，若服务容量变化平稳，其时间尺度长，则资源容量变化小，预测模型简单，反之，则预测模型复杂：且预测精确程度相对较低。总之，时间尺度小，意味着服务容量变化剧烈。服务容量变化的时间度的决定性因素包括： 1）客户业务容量线的震荡程度，如波峰、波谷交替频率及曲率； 2）客户业务容量的波峰值、波谷值、常态值及各自对应的时间段（如上午9~11时是波峰时段)； 3）服务组件的负载均衡情况。 5.当根据容量规划完成服务部署工作之后，应采取监测和分析措施，以验证容量是否满足服务容量与性能要求，对存在偏差的，应提出改进措施。 容量监控内容包括：计算资源、传输资源和存储资源，例如： 1.计算资源：内存、CPU等的有效利用率及响应及时率等性能指标； 2.传输资源：带宽有效利用率及QoS、时延等性能指标； 3.存储资源：存储空间有效利用率及响应及时率等性能指标。 对监控数据进行分析，并产生报警（如容量不足导致的性能故障等），这需要设定容量阀值，作为报警的基准。
    • 8.5服务设计，构建和转换
      • 8.5.1变更管理
        • 8.5.1.1变更管理策略 应建立变更管理策略并形成文件，以确定： a)受变更管理控制下的服务组件和其他事项； b)变更类别，包括紧急变更，以及如何进行管理； c)确定可能对客户或服务产生重大潜在影响的变更的标准。
          • 1.组织应明确变更管理方针，并形成正式文档。变更管理方针包括：属于变更管理范围内的资产(或CI)及其他因素（如SLA);变更类型及处置流程；变更影响的评估基准。 受变更管理控制的服务组件应包含所有支持服务的资产及其他因素，说明如下： ——支撑客户业务运营的资产：主要指信息系统、机房物理设施等。 ——组织支持客户业务运营的资产：若组织仅提供技术服务，则资产指服务监测与管理工具，若组织还提供支撑客户业务运营的资产（参见上一条），则这部分资产应受变更管理控制； ——供方资产：视供方提供的服务、服务组件情况及其作用而论、可能是提供服务监测与管理工具，也可能是提供服务组件给组织，再由组织部署到支撑客户业务运营的信息系统中，这些资产应受变更管理控制。 ——变更类型：通常基于信息资产类型和技术活动两个维度进行变更分类，技术活动如安装与部署、升级、补丁、改造、迁移、报废等。 2.变更级别是一种更严格的变更分类，通常基于变更的影响程度进行分类：评定变更级别的基本因素是紧追性（时间为基准）和影响程度，影响程度分析应综合考虑如下因素： ——系统或服务事件：如效率降低、中断与泄密等事件； ——涉及国家、社会的系统或服务，应优先关注泄密事件，以人身安全与无形影响为主； ——实时性强的系统或服务，应优先关注中断事件，以财务、客户、生产能力及声誉、品牌等影响为主； ——对仅用于内部的系统或服务，应优先关注效率降低事件、以生产能力影响为主； ——用于客户的系统或服务，应优先关注中断事件，以客户、生产能力等影响为主。 3.根据变更评定规则，设定变更级别，至少应该包括： 标准变更：操作成熟、可重复性高、影响极小的变更； 一般变更：对系统造成一定的影响，需要IT和业务主管参与审核的变更； 重要变更：需要最高领导层参与审核的变更； 紧急变更：变更时间要求紧迫，重点关注变更成功率及完成的时效性。 4.对变更执行过程进行跟踪，应明确变更状态，如：新建、已复核、计划中、审核中、已审核、己排程、实施中、等待、修改中、已完成、关闭等。
        • 8.5.1.2变更管理发起 变更请求，包括增加、删除或转移服务的提议，应予以记录和分类。 对以下情形，组织应采用8.5.2中的服务设计和转换： a)根据变更管理策略，可能对客户或其他服务产生重大影响的新服务； b)根据变更管理策略，可能对客户或其他服务产生重大影响的服务变更； c)根据变更管理策略，应由服务设计和转换管理的变更类别； d)服务的下线； e)将现有服务从组织转移到客户或其他各方； f)将现有服务从客户或其他各方转移到组织。 应通过8.5.1.3中的变更管理活动对8.5.2范围内的新服务或变更服务进行评估、批准、排程和评审等管理。 对不通过8.5.2管理的变更请求应通过8.5.1.3中的变更管理活动进行管理。
          • 1.服务的增加请求可能产生新服务，删除或转移服务对客户服务目录、SLA产生较大影响，需要变更客户服务目录和SLA，这几种情况都可能要重新设计和转换服务。 2.增加、删除或转移服务的来源是服务需求管理8.4.2，并形成服务变更请求，满足一定条件，且属于组织职责或合同范围内的，需要签署SLA并执行服务设计与转换过程，最终部署、实现于客户业务系统中。 3.资产或CI及其他因素变更包括： a.客户业务运营变更引起服务变更，需要开展服务设计和转换； b.客户IT基设施变更引起服务变更，需要开展服务设计和转换； c.客户业务环境（参见4.1、8.3.2）变化，导致客户业务运营变更和客户IT基础设施变更，并由此需要开展服务设计和转换。
        • 8.5.1.3变更管理活动 组织和相关方应就变更请求的批准和优先级做出决策。决策应考虑风险、商业利益、可行性和财务影响。决策还应考虑变更对以下要素带来的潜在影响： a)现有服务； b)客户、用户和其他相关方； c)本标准要求的方针和计划； d)容量、服务可用性、服务连续性和信息安全； e)其他变更请求、发布和部署计划。 得到批准的变更应进行准备，验证，并在可能的情况下进行测试。得到批准的变更的建议部署日期和其他部署详细信息应通知相关方。 应对变更失败的回退或补救措施进行规划，应在可行时，进行测试。应对失败的变更进行调查并采取达成一致的措施。 组织应对变更有效性进行评审，并采取与有关各方达成一致的措施。 应按计划的时间间隔，分析对变更请求记录以发现趋势性现象。应记录和评审从分析中得出的结果和结论，并识别改进的机会。
          • 1.变更请求应通过批准，并给优先级排序，批准和优先级的决定性包括风险、商业收益、可行性和财务影响。 2.对变更请求应形成规范的文档（如RFC表），其内容包括：变更发起人基本信息，变更对象与范围，变更提出时间，变更内容，变更原因，变更风险，变更类型，变更级别，变更状态，变更方案，变更失败处理方案（回退、恢复、应急等方案），成本预算等和其他必要因素。 3.变更批准组织可能包括：变更管理员：对变更请求做初步筛选，变更经理：批准一般变更，变更管理委员会：批准紧急或重大变更，以上组织通常需要服务方、客户、供方及其他必需人员组成。 批准变更（尤其是重大变更）所需的输入包括：变更请求表，初步审核和接受意见，变更实施方案，变更失败处理方案（回退方案、应急补救措施等），人员组织架构、职责介绍，技术可行性说明，解决的问题或收益、成本预算说明，风险、业务影响和处置措施说明。 4.变更测试要求如下列说明： 应对如下内容进行测试：所构建的变更、实施方案、回退方案、备份方案、应急预案。 应根据测试内容和人员、时间安排等编制变更测试计划，主要内容包括：测试类型，如单元测试、集成测试或回归测试等；测试目标和测试内容；测试用例设计；测试环境搭建；测试方法与工具；测试记录模板；测试问题跟踪模板；测试报告模板；测试人员组织与职责；测试时间安排。 应搭建专门的测试环境（如准生产环境），禁止在生产环境中实施变更测试； 测试执行过程中应进行如下工作：测试记录；测试问题发现与跟踪；问题处理；测试结论。 5.对验证后得到批准的变更，应制定实施计划，并将该计划通知客户、供方等相关方。实施计划包括的主要内容如下：实施内容和范围；构建的变更及回退或补救方案、应急预案等；生产环境准备检查；实施任务及分配；人员组织与职责；部署时间安排；其他必需因素。 6.应定期搜集、整理变更相关记录和报告，统计变更实施情况，识别发展趋势，主要内容包括： ——数量：总的变更请求、过滤的变更请求、批准的变更请求，实施成功/失败的变更、紧急变更，以及各类/各级变更数量（含标准变更数量）； ——时间：变更从请求到关闭的平均处理时间及各环节的平均时间（如审批平均时间)； ——分布：在资产/CI上的数量分布、在成本区间的数量分布。
      • 8.5.2服务设计和转换
        • 8.5.2.1规划新的或变更的服务 规划应根据8.2.2中确定的新服务或变更服务的服务要求，并应包括或包含对以下内容的引用： a)设计、构建和转换活动的权力和责任； b)组织或其他各方按时间表进行的活动； c)人力，技术，信息和财政资源； d)对其他服务的依赖； e)新服务或变更服务所需的测试； f)服务验收标准； g)交付新服务或变更服务的预期结果的可测量性描述； h)对SMS、其他服务、计划变更、客户、用户和其他相关方的影响。 对于要下线的服务，规划还应包括下线服务的口期以及数据、服务组件、文档的归档，处理或传输等活动内容。 对于要转移的服务，规划还应包括服务转移的日期和数据、文档、知识、服务组件的传递和交接。 受新服务或已变更服务影响的CI应通过配置管理进行管理。
          • 1.规划工作应形成规划报告，报告内容除包括背景、原则、目标、实施计划和路径之外、还应包括： a)要求建立整个服务实现过程中的组织和职责，组织中的岗位或人员包括从事服务规划的人员、服务设计人员、服务构建人员、服务转换人员等，以及相应管理层，对于这些人员应区分是属于组织、客户或供方的人员，对于客户或供方人员，应遵循8.2.3和8.3.4要求予以管控； b)要求明确组织和其他相关方的任务和工作流程，制定工作计划，既需要整体工作计划，把握服务实现的总体进展，也需要针对组织、客户或供方分别制定各自的工作计划，最终协调一致的完成服务实现； c)明确服务实现所需资源，也是组织的成本构成，应遵循8.4.1量化资源成本，控制成本消耗。这些成本包括采购供方成果（服务、服务组件、服务过程）的成本，以及客户参与服务实现所耗费的成本； d)决定了存在依赖关系的其他服务可能会发生变更，这将产生关联任务和成本，关联任务应纳人工作计划中，关联成本应纳入服务成本中； e)工作计划应包括所需测试的安排，测试所耗费成本应纳入服务成本中； f)服务实现后是否满足客户要求所必需的，验收标准内容包括： ——满足双方（组织和客户）签订的SLA要求； ——符合双方的成本财务管理要求8.4.1； ——符合法律法规及其他必需的合规要求； g)强调服务目标或预期结果是可测量的，以确保验收标准的可操作性； h)服务实践中的风险管控，根据8.5.1.1和8.5.1.3要求，可以评估对SMS、其他服务、计划变更、客户、用户和其他相关方的影响，影响不能接受的，应采取风险处置措施。 2.对受新服务或已变更服务影响的，对新的或变更服务所影响的Ci应按配置管理8.2.6进行管理。它的落实需要建立变更管理与配置管理之间的衔接关系，具体包括： ——识别和标识变更管理中的或受影响CI,核实其余配置库中的CI一致； ——跟踪变更或影响的CI,完成变更实施后，将最终CI信息传递给配置管理人员； ——根据所传递的CI信息，变更配置库中的对应的CI信息，核实、比对无误后，完成CI更新。
        • 8.5.2.2设计 应对新的或变更的服务进行设计并形成文件，以满足8.2.2中确定的服务要求。设计应包括以下相关要素： a)参与提供新服务或变更服务的各方的权力和责任； b)对人力，技术，信息和财政资源的变更请求； c)相应的教育、培训和经验要求； d)支持服务的新的或变更的SLA,合同和其他文件化协议； e)SMS的变更，包括新的或变更的方针、计划、流程、程序、措施和知识； f)对其他服务的影响； g)服务目录的更新。
          • 1.组织应在服务规划的基础上开展服务设计工作，确保服务规划成果是切实可行的、可落地的。 服务规划重在对建设任务给出框架性要求，是面向管理层的、蓝图式的方案，而服务设计面向开发工程师的设计方案，应根据所实现服务的重要性、规模等，明确是否需要初步设计或详细设计，以及涉及物理部署（如涉及机房设施的建设）的施工图设计。 2.条款的d)要求对设计方案进行评审，满足新的或变更的SLA、合同和其他文件化协议要求，这是更具体的验收标准； 条款的e)强调SMS变更的风险，涉及建立新的或变更SMS中的方针、计划、流程、程序、措施和知识，对此应给出妥善应对措施； 服务设计完毕，在构建和转换前，应更新客户服务目录。
        • 8.5.2.3构建和转换 应建立新的或变更的服务并进行测试，以验证是否符合服务要求，是否符合文件化设计以及符合达成一致的服务验收标准。如果不符合服务验收标准，组织和相关方应对必要的行动和部署做出决定。 应使用发布和部署管理将已批准的新服务或变更的服务部署到运行环境中。完成转换活动后，组织应对照预期成果向有关各方报告转换的结果。
          • 1.组织应构建新的或变更的服务，并完成测试工作，以确认是否满足相关标准(包括服务要求（如SA)、设计方案、服务验收标准）。 2.服务构建所形成的成果呈现为如下几种型态： a)支持客户业务运行的软件包； b)支持客户业务运行的、集成的设备设施； c)包含前两项的软硬件集成组合； ——云服务，如Iaas、PaaS、SaaS等； ——支持客户业务运行的数据服务，如数据存储、数据分析等； ——对客户业务系统的安装、部署、升级、加固/打补丁、安全事件或故障处理、配置操作、巡检和检查、评估与测评、审计等技术活动/技术服务； ——其他，如视频和音频服务等。 3.所构建的服务还应包括与服务成果型态协调一致的业务环境因素，具体如下： ——物理环境：包括机房空调、电力、机柜、综合布线等设备设施、空间布局、物理连接等； ——网络环境：网络架构和核心设备、网络物理拓扑和逻辑拓扑（如网络协议和端口）； ——计算环境：物理或虚拟的服务器、存储等的配置与连接； ——安全环境：网络边界、安全设备等的配置与连接； ——管理环境：人员和组织要求、技术活动、服务过程等的衔接。 即仅仅提供一个软件包并不是客户所需的"服务"，还需考虑软件包的运营环境因素，融入服务设计中。 4.测试是部署上线前的测试，其测试环境应该是非生产环境，应尽可能搭建与生产环境相似的测试环境，如很多金融机构搭建与生产环境近似的"准生产环境"。搭建测试环境应考虑上一项巾的业务环境因素，技术选型与部署、配置应考虑服务要求（如SLA)、设计方案、服务验收标准等。 5.发布与部署成果后，组织应建立预期成果（规划中的目标、蓝图，设计方案中的成果，服务构建中的成果型态等)与实际服务部署与运行情况间的对应关系，给出匹配度判断，并提交给客户、供方、监管方等。
      • 8.5.3发布和部署管理
        • 组织应定义发布类型，包括紧急发布、频率以及如何管理。 组织应对新的或变更的服务和服务组件部署到运行环境中进行规划。规划应与变更管理协调，并包括对相关变更请求，已知错误或通过发布关闭的问题的引用。规划应包括每个版本的部署日期，可交付成果和部署方法。 发布应根据文件化的验收标准进行验证，并在部署前获得批准。如果不符合验收标准，组织和相关方应对必要的行动和部署做出决定。 在将版本部署到运行环境之前，应建立受影响的CI的基线。版本部署到运行环境中时，应维护服务和服务组件的完整性。 应监测和分析发布的成功或失败。测量应包括与部署发布以后与发布相关的事件。应记录和评审从分析中得出的结果和结论，以确定改进的机会。 有关发布成功或失败以及将来发布日期的信息在适当时，应提供给其他服务管理活动。
          • 1.根据层次的不同，它可分为以下三类： 1)重大发布：新的硬件和软件的大型首运行(Rollout),通常是伴随着重大的功能增强。这种发布通常可以消除多个已知错误，包括临时性的应急措施和临时性修复。实践中，很多组织将重大发布当作紧急发布。 2)小型软件发布和硬件升级：这种发布通常是指对已知错误进行的一些小的改进和修复。有些可能已经作为紧急修复在早些时候实施了，但现在统一纳入发布中。这种发布还可以确保"前可信任状态"(Previous Trusted State),即所有测试的起点，得到更新。 3)紧急修复：通常用来对某个问题或已知错误进行临时性修复。 2.按规模发布可分为： 1)紧急发布(Emergency Fix):少量对已知错误的更正和快速实施的解决方案； 2)小规模发布：一定数量的改进和对已知错误的更正 3)大规模发布：一般是新的软硬件的首次发布或者是对现有构架的功能做出重大改进。 3.按发布包的完整程度发布可分为： 1)全发布：指发布一套完整的程序，包括那些没有变更的部分； 2)Delta发布：发布仅含少量变更时，使用Delta发布； 3)包发布：一组软件的发布，相互有依赖和关联的发布。 4.发布失败或成功的判断基准包括： 1)发布满足客户服务目标或服务要求，如功能、性能、安全等； 2)发布与客户业务系统的IT架构一致； 3)发布及其他组件（支撑客户业务运营的）的状态正常，功能/性能/安全参数在预期的值范围内； 4)发布与所需连接或关联的服务组件（关系参见8.2.5配置管理）相匹配； 5)发布及其他组件的有效运行时间符合合同要求。 5.监测内容包括： 1)服务与业务系统的安全指标（如数据完整性检查、加密等）、可用性（如服务可用性99.9%)、连续性（如服务RPO、RTO); 2)发布及其他组件（支撑客户业务运营的）的状态、功能/性能/安全参数、CPU/内存/存储/带宽等的有效利用率； 3)系统故障、安全事件、巾断事件等； 4)其他必需的参数。 6.部署实施完毕，应开展有效性评审，并采取改进措施，具体包括： 1)汇总发布与部署实施过程（含失败处理）中的文档、对信息系统的监测数据，依此对发布进行分析，最终得到发布成功或失败的结果，并编制发布与部署报告，提交给相关方； 2)对失败或成功的发布进行评审，分析、判断、确认成功或失败的原，对失败的发布明确改进责任，提出改进要求，直至满足需求。
    • 8.6解决和履行
      • 8.6.1事件管理 事件应： a)得到记录和分类； b)基于影响和紧急程度进行优先级分级； c)基于需要进行升级； d)解决； e)关闭。 事件记录应根据所采取的行动及时更新。 组织应确定识别重大事件的标准。重大事件应按照文件化的程序进行分类和管理。应向最高管理层通报重大事件。组织应为每个重大事件指定管理责任人。事件解决后，应报告和评审重大事件，以确定改进的机会。
        • 1.对事件处理过程进行管理，包括事件提取、记录、分析与委派、处理、升级、解决和关闭等。 2.内部事件原因或机理： 1)故障：软硬件、设备设施等的功能失效； 2)误操作：人员有意或无意的操作影响系统运行； 3)供应商：指供应商产品和服务提供中断等； 4)信息安全事件：包括有害程序、网络攻击、信息破坏、信息内容危害等； 5)物理事件：指设备设施的结构破损、老化等； 6)配置失误，如服务器IP配置错误等。 外部事件主要包括发生后对信息系统运行产生较大影响的事件，包括： 1)社会公共事件：传染病、恐饰袭击； 2)自然灾害：地震、水灾、火灾等。 3.事件级别判断要求如下： 1)评定事件级别的基本因素是紧迫性（时间为基准）和影响程度，影响程度分析应综合考虑如下因素： 系统或服务事件：效率降低、中断与泄密等事件； 事件的有形影响：对国家、社会、组织在财务、市场、客户、生产能力、人身安全等的影响； 事件的无形影响：社会秩序及组织的声誉、品牌等。 2)应根据影响程度区分需要应急响应的事件和按日常流程按部就班执行的一般事件，对前者需要制定专门的应急预案、按响应级别开展处理工作； 3)一般事件中因处理时间紧迫，属于紧急事件，但紧急事件未必需要应急响应处理； 4)根据影响程度，将事件级别分为4个级： 特别重大事件(I级)；重大事件（Ⅱ级）；较大事件（Ⅲ级）；一般事件（Ⅳ级）。 4.应根据实际处理过程设定事件状态，如已提交、待分配、已分配、待处理、正处理、挂起、已解决、事件关闭等； 5.事件升级包括技术/功能升级和结构/管理升级，具体如下， 1)面对如下事件处理场景应实行管理升级： 超过管理职责范围，如授权不足； 在现有资源和能力情况下，超出时限要求； 分属多个组织的系统的结合部分； 所需资源和成本超过预期范围； 超出SLA范围； 因管理层级不足导致事件处理失败。 2)面对如下事件处理场景应实行技术升级： 不具备解决事件的技能，如任务分配不当，所分配人员不具备解决事件的技能； 在预期时间内，无法解决事件，如技能不足，导致效率不高； 因技能不足导致事件处理失败。 3)应对每个事件的处理过程进行完整记录，并及时更新记录。事件记录的主要内容包括： 事件请求/发起者基本信息，如姓名、职位及联络信息等；事件对应的资产和可能影响的资产；事件现象或请求内容；事件类型；事件级别；事件发现与上报时间；事件期望处理完成时间；事件状态；事件原因；事件处理方案；事件处理升级；事作处理结果。 6.对重大事件处理提出更严格的要求，包括评定标准、分类和管理、报告、管理责任人等。 特别重大事件：是指能够导致特别严重影响或破坏的事件，包括会使特别重要信息系统遭受特别严重的系统损失，产生特别重大的社会影响。 重大事件：重大事件是指能够导致严重影响或破坏的事件，包括会使特别重要信息系统遭受严重的系统损失、或使重要信息系统遭受特别严重的系统损失；产生的重大的社会影响。 较大事件：是指能够导致较严重影响或破坏的信息安全事件，包括以下情况：会使特别重要信息系统遭受较大的系统损失、或使重要信息系统遭受严重的系统损失、一般信息信息系统遭受特别严重的系统损失，产生较大的社会影响。 一般事件：是指不满足以上条件的信息安全事件。 对重大事件的发生和处理应向最高管理层通报，通报内容包括事件级别、影响程度、处理结果、原因分析、处理结果、系统恢复情况、调查和追责情况、经验总结和改进等。
      • 8.6.2服务请求管理 服务请求应： a)得到记录和分类； b)优先级分级； c)履行； d)关闭。 服务请求记录应根据所采取的行动及时更新。 应向参与服务请求履行的人员提供履行服务请求的说明。
        • ——对服务请求处理过程进行管理，包括请求提取、记录、分析与委派、处理、解决和关闭等。服务请求指对T系统实施小的变更，这些变更具有低风险、频发、低成本等特征，如请求更改终端用户密码、安装office软件等。 ——组织应根据实际情况，将服务请求当作一类事件，融入事件管理过程中，可以参照事件管理过程，建立独立的服务请求解决流程。 ——组织可通过自助服务台、培训、网络义件其享、推送（如邮件发送）等方式向服务请求实现相关人员提供操作指南。
      • 8.6.3 问题管理 组织应分析事件数据和趋势，以识别问题。组织应进行根本原因分析,并识别可防止事件发生或再次发生的潜在措施。 问题应该： a)得到记录和分类； b)优先分级； c)基于需要进行升级； d)尽可能解决； e)关闭。 问题记录应根据所采取的行动及时更新。解决问题所需的变更应根据变更管理策略进行管理。 如果根本原因得到识别，但问题尚未得到永久解决，则组织应识别减少或消除问题对服务影响的措施。应记录已知错误。在适当时，应为其他服务管理活动提供有关已知错误和问题解决方案的最新信息。 应按计划的时间间隔，监测、评审和报告问题解决的有效性。
        • 1.未找到根源称为问题；找到根源称为己知错误; 2.若事件存在快速恢复系统运行的根本性解决方案，则可直接采纳该方案、即事件处理变成已知错误处理。 3.对问题处理过程进行管理，包括识别和提起问题、诊断和解决方案、处理、关闭，以及问题分类、优先级、升级等。 4.明确间题来源，有助于识别和确定问题，通常包括： 1)重复发生事件； 2)重大事件深层次解决； 3)事件无法与现有问题和已知错误关联； 4)根据数据进行趋势分析而发现并提出的问题； 5)通过对用户IT基础设施监控和巡检所发现的潜在的需要讨论和根源分析的隐患。 5.对问题管理的效果进行监测、评审和报告。跟踪、监测问题处理过程，采集如下数据： 1)提起问题总数量、已知错误数量； 2)已解决的问题数量，包括临时性解决和永久性解决； 3)未解决问题数，包括问题和已知错误； 4)问题分类情况及解决或末解决数量； 5)分析问题解决及时率和未解决所造成的影响及范用。 对问题处理进行评审，分析未解决问题原因，提出改进意见，并汇总以上内容，形成问题报告。
    • 8.7服务保证
      • 8.7.1服务可用性管理 应按计划的时间间隔，评估服务可用性的风险，并形成文件。组织应确定服务可用性要求和目标。达成一致的要求应考虑相关的业务要求，服务要求，SLA和风险。 应记录和维护服务可用性要求和目标。 应监控服务可用性，记录结果并与目标进行比较。应对计划外的不可用进行调查并采取必要的措施。 注：6.1中确定的风险可以为服务可用性，服务连续性和信息安全提供风险输人。
        • 1.可用性管理：可用性管理报告、可用性计划、可用性设计标准、可用性测试程安排；定期开展服务可用性风险评估，形成风险评估报告，作为风险处置措施的依据。 可用性通常用一定时间段内正常运行时间表示，也可以表示为相对值，即"可用性=正常运行时间/约定的时间段"，如一年内可用性为99.9%。 ——开展服务可用性风险评话，需要对服务、服务组件进行监测、分析、评估。 ——服务可用性风险评估需要从支持服务的服务组件（即资产或CI)人手，具体方法为：选定需要评估的服务，对业务服务直接选择评估对象，对技术服务，需要将其对应到相应的资产或CI.然后明确资产或CI支持的业务服务、即技术服务风险需要通过业务服务风险体现； ——监测、识别访问路径中每个资产或CI的隐患、威胁，即可识别、评估每个资产或CI的服务可用性风险，按资产或CI之间的串并关系，即可评估整个服务可用性风险； 2.网络安全设备、路由和交换设备指标：①连通性；②质量和时延；③访问控制； 通信链路-设施指标：①连通性；②质量和时延； 计算和存储设备指标：①连通性；②质量和时延；③业务计算；4存储响应； 专门存储设指标：①连通推；②质过和时延；③存储响应； 冗余/部署架构（虚拟化、热备、集群、云计算等）指标：①连通性；②质量和时延；③切换响应。 ——新的或变更的服务(8.5.2)的实现需要建立可用性设计标准，包括服务或服务组件的可用性目标指标、冗余方式、检测与恢复措施等。 ——应根据可用性设计标准、建立测试指标，制定测试计划，开展测试工作，包括可用性或不可用指标、中断时间、故障频率和数量等。 3.可用性监测、分析与对比要求应根据服务所覆盖的组件（资产或CI)及关联关系(8.2.6),选择监测对象，部署监视与分析工具，监测可用性指标，及时发现隐患、及时改进；应定期汇总、整理所有监视记录、隐患与改进措施，形成可用性分析报告，包括： ——组件可用性指标值（实际值）及与目标指的偏离； ——关键业务功能可用性指标值及与目标指的偏离； ——服务可用性指标及与目标指的偏离； ——计划内或计划外的不可用情况； ——对SLA的满足程度； ——改进建议。 对计划外的不可用性采取针对性措施（通常需要应急响应处置），计划外的不可用性情况示例如下： ——因未预计到的紧急性能问题导致的中断； ——公共事件（如大面积停电）或自然灾害导致的中断； ——因可用性技术发展过快，应对不及导致的业务中断； ——因业务非预期增长导致的中断。
      • 8.7.2服务连续性管理 应按计划的时间间隔，评估和记录服务连续性的风险。组织应确定服务连续性要求。达成一致的要求应考虑相关的业务要求、服务要求、SLA和风险。 组织应创建，实施和维护一个或多个服务连续性计划。服务连续性计划应包括或包含对以下内容的引用： a)启动服务连续性的标准和责任； b)在服务严重丧失的情况下实施的程序； c)调用服务连续性计划时的服务可用性目标； d)服务恢复的要求； e)恢复正常工作条件的程序。 当不能访问正常服务区域时，应确保能够访问服务连续性计划和联系人列表。应按计划的时间间隔，按照服务连续性要求对服务连续性计划进行测试。服务连续性计划应在服务环境发生重大变化后重新测试。应记求测试结果。应在每次测试后和服务连续性计划调用后进行审核。如果发现不足，组织应采取必要的措施。 组织应在启动服务连续性计划时报告原因、影响和恢复情况。
        • 1.要定期开展服务连续性风险评估，形成风险评估报告，作为风险处置措施的依据。 2.服务连续性目标是确定服务恢复优先级，服务恢复优先级由恢复目标指标RTO、RPO决定。当然，服务恢复优先级和恢复目标取决于客户业务恢复优先级与恢复目标。即；恢复时间目标(RTO)指灾难发生后，服务或业务功能从停顿到必须恢复的时间要求；恢复点目标(RPO)灾难发生后，系统和数据必须恢复到的时间点要求。RTO由MSB：可容忍的最大业务损失值，可以是财务损失、业务量损失，还可以是偏离行业监管要求、信誉损失等；MAO：最大业务可容忍中断时间； 3.一个服务连续性计划内容框架示例如下： ——目的和范用； ——服务连续性目标； ——启动的准则和程序； ——响应程序； ——组织结构与职责； ——沟通方式和人员列表； ——组织内部和外部的依赖关系和相互作用，如与国家应急响应中心的关系； ——资源建设，包括资源类型和数量、获取与使用方式等； ——相关记录文档。 4.当因各种原因不能达到正常服务区域时，应建立合适的访问途径，以便于事件处置相关人员获得服务连续性计划和沟通人列表。（事件处置相关人员不能达到正常服务区域的原很多，包括，事件现场的障碍，如火灾等；时间或交通原内，如晚上发生事件，来不及达到现场；位置原因，如在外地出差等） 5.定期开展服务连续性计划测试，测试要求包括如下内容： 1)业务或服务的对应的服务连续性计划测试次序； 2)业务或服务的对应的服务连续性计划测试频率（即多长时间测试一次）； 3)事件场景，应含具体事件、事件级别。 6.应制定测试计划，按计划测试，测试计划的主要内容包括： 1)测试目标及满足目标的评价指标；2)测试方式和事件场景，如桌面推演、现场测试；3)测试对象范围；4)测试流程；5)测试组织；6)测试所需资源；7)时间安排；8)演练的风险及应对措施；9)测试记录。 7.对测试和所调用的服务连续性计划的评审内容包括： 1)服务连续性计划是否合适； 2)响应人员技能是否足以胜任现场处置工作； 3)处置过程中的资源获取和使用是否可行，满足应急处置工作需求； 4)应急操作所花费的时间是否符合RTO要求； 5)应急场景设定中，考虑非理想情况是不充分； 6)应急预案文档质量是否满足工作要求。
      • 8.7.3信息安全管理
        • 8.7.3.1信息安全策略 应由具有适当权限的管理层批准与组织相关的信息安全策略。信息安全策略应形成文件，并考虑服务要求和6.3c)中的义务。 在需要时，应能够获得信息安全策略。组织应对以下人员传达遵守信息安全策略及其对SMS和服务的适用性的重要性： a)组织； b)客户和用户； c)外部供方，内部供方和其他相关方。
          • 组织应通过适当方式让相关人员获得信息安全策略，明确遵循安全策略的重要性，以及安全策略对SMS和服务的适用性。 组织应根据相关人员在服务生命周期中承担的职责所涉及的组织和客户服务组件、数据，识别可能存在的风险，根据风险选择适用的信息安全策略，然后通过文档访问、培训等方式向相关人员传达信息安全策略。合适人员包括：组织内部人员；客户和用户；外部供方、内部供方和其他相关方。
        • 8.7.3.2信息安全控制措施 应按计划的时间间隔内，评估和记录SMS和服务的信息安全风险。应确定、实施和运行信息安全控制，以支持信息安全策略并处置已识别的信息安全风险。有关信息安全控制的决定应形成文件。 组织应批准并实施信息安全控制措施，以处置与外部组织相关的信息安全风险。 组织应监督和评审信息安全控制措施的有效性并采取必要的措施。
          •  
          • 1.建立环境主要包括明确风险评估范围、目标和评估准则，评估准则包括：风险级别规则；风险可接受程度、风险偏好；资产、脆弱性、威胁等赋值规则；风险计算模型等。 风险识别包括资产识别、威胁识别、脆弱性识别。 风险分析包括建立资产、威胁、脆弱性之间的关系，计算风险的可能性和影响程度（参见8.5.1.1的变更影响程度分析方法）。 风险评价指根据风险级别规则为风险排序。 风险处置指根据风险可接受级别、风险偏好确定可接受和不可接受风险，对不可接受风险选择安全措施，并考虑成本、收益、紧迫性等，设定处置优先级。 2.风险处置计划是选择安全措施后的工作安排，包括待处置的风险、控制策略、应对措施、责任人、处置时间、残余风险等内容； 3.部署安全控制措施后，应预先根据服务的配置关系(8.2.6)，建立服务与信息资产（含数据）之间的对应关系，形成与服务可用性(8.7.1)类似的访问路径，对访问路径上所有资产开展如下监控、测评和评审工作。 1.网络安全架构与设计的一致，如网络安全区域划分、安全设备部署、边界安全措施部署等； 2.安全功能配置与安全策略要求保持一致； 3.资产上应处置的脆弱性得到修补； 4.已知威胁得到遏制； 5.对新识别或为修补的脆弱性，通过渗透测试方法验证其被威胁利用的难度超过可容忍的程度； 6.整个服务或客户业务系统满足国家或行业监管要求，如符合网络安全等级保护要求等。
        • 8.7.3.3信息安全事件 信息安全事件应： a)得到记录和分类； b)基于信息安全风险考虑的处置优先级； c)根据需要进行升级； d)解决； e)关闭。 组织应按SMS,服务和相关方的类型，数量和影响分析信息安全事件。应报告信息安全事件，并进行评审以确定改进的机会。 注：ISO/IEC27000系列规定了相关要求并提供了指导，以支持信息安全管理体系的实施和运行。ISO/IEC27013为ISO/IEC27001和ISO/IEC20000-1(本标准)的整合提供了指导。
          • 1.对信息安全事件处理过程进行管理，包括事件提取、记录、分析与委派、处理、升级、解决和关闭等，这些内容可参照事件管理8.6.1相关内容执行。 2.根据信息安全风险确定信息安全策略，根据风险与策略选择、实施、运行信息安全控制，并形成信息安全风险处置计划。 3.定期形成信息安全事件报告，并提交给相关方。信息安全事件报告的主要内容包括： 1)事件发现时间、资产、影响； 2)事件发生的原因分析，即脆弱性与威胁情况； 3)事件的处理过程和结果； 4)事件引发的变更； 5)原因总结与改进，如为降低事件发生频率，减轻损害和避免再次发生的改进措施； 6)必要时，追责与处罚；
  • 9绩效评估
    • 9.1监测，测量，分析和评估 组织应确定： a)需要监视和测量SMS和服务的内容； b)适用的监视、测量、分析和评估方法，以确保有效的结果； c)进行监视和测量； d)应分析和评估监视和测量的结果。 组织应保留适当的文件化信息作为结果的证据。 组织应根据服务管理目标评估SMS绩效以及有效性。组织应根据服务要求评估服务的有效性。
      • 服务提供方应采用适宜的方法来监视、测量服务管理体系(SMS)和服务。这些方法应包括内部审核和管理评审。内部审核和管理评审的目标应形成文件。内部审核和管理评审应证实服务管理体系(SMS)和服务具有达到服务管理日标和满足服务需求的能力。 违反ISO/IEC20000-1的要求、服务提供方识别的服务管理体系要求或服务需求的不合格应予以识别。 应记录内部审核和管理评审的结果，包括不合格、相关事宜和识别的措施。结果和措施应通报给相关方。 监视和测量内容至少包括：各个流程的服务绩效；服务目标完成情况；风险；人员能力；资源；内外部审核；管理评审和相关方满意度。
    • 9.2内部审计/审核
      • 9.2.1组织应按计划的时间间隔进行内部审核，以提供有关SMS的信息： a)符合： 1)组织自己对SMS的要求； 2)本标准的要求； b)有效实施和维护。
      • 9.2.2组织应： a)计划、建立、实施和维护审核计划，包括频率、方法、责任、计划要求和报告，其中应考虑： 1)有关过程的重要性； 2)影响组织的变化； 3)上次的审核结果； b)确定每一审核的审计标准和范围； c)选择审核员并进行审核，以确保审核过程的客观性和公正性； d)确保将审核结果报告给相关管理层； e)保留文件化信息，作为实施审核计划和审计结果的证据。 注：1SO19011提供了审核管理体系的指南。
        • 应编制形成文件的程序，以规定审核的策划、实施以及报告结果和保持记录的职责和权限。 应对审核方案进行策划；应考虑拟审核的过程和区域的状况和重要性以及以往审核的结果；审核的准则、范围、频次和方法应形成文件。 审核员的选择和审核的实施应确保审核过程的客观性和公正性。审核员不应该审核自己的工作。不合格应通报、排定优先顺序并分配措施职责。负责受审区域的管理者应确保及时采取必要的纠正和纠正措施，以消除所发现的不合格及其原内。跟踪活动应包括对采取措施的验证和验证结果的报告。
    • 9.3管理评审
      • 最高管理层应按计划的时间间隔评审组织的SM和服务，以确保其持续的适用性，充分性和有效性。 管理评审应包括： a)以往管理评审所确定措施的实施状况； b)与SMS相关的外部和内部事项的变化； c)有关SMS的绩效和有效性的信息，包括以下要素及其趋势： 1)不符合和纠正措施； 2)监视和测量结果； 3)审核结果； d)持续改进的机会； e)来自客户和其他相关方的反馈； f)遵守和适用本标准要求的服务管理方针和其他方针； g)服务管理目标的实现； h)服务的绩效； i)参与提供服务的其他各方的表现； j)当前和预测人力，技术，信息和财政资源水平以及人力和技术资源能力； k)风险评估结果以及为应对风险和机会而采取的行动的有效性； l)可能影响SMS和服务的更改。 管理评审的输出应包括与持续改进机会相关的决策以及SMS和服务变更的任何需求。
    • 9.4服务报告
      • 组织应确定报告要求及其目的。 应使用SMS活动和提供服务的信息制作关于SMS和服务的绩效和有效性的报告。服务报告应包括趋势。 组织应根据服务报告中的结果做出决策并采取行动。达成一致的行动应通知有关各方。 注意：所需的报告在本标准的相关条款中指定。还可以生成其他报告。
        • 1.服务提供方与相关方应协商并记录每个服务报告的描述，包含标识、目的、读者、频率和数据源的详情。 应采用来自服务交付和包括服务管理过程的服务管理体系(SMS)活动的信息，生成服务报告。服务报告至少包括： ——与服务级别目标相对应的绩效； ——相关重大事件信息，至少包括重大事件、新服务或变更的服务的部署和被触发的服务连续性计划； ——工作量特征，包括工作量和周期性变化； ——依据ISO/IEC20000-1本部分要求、服务管理体系(SMS)要求或服务需求检查出的不合格以及识别的原因； ——趋势信息； ——客户满意度测量、服务投诉以及满意度测量和投诉的分析。 服务提供方应基于服务报告的发现做出决策并采取措施。协调一致的措施应通报相关方。 2.服务报告是服务提供商对服务质量数据采集和监控的工具，一般指的是按和客户达成的服务协议约定的级别每月或每季度呈现的SLA达成情况的报表。 3.服务报告内容示例： 1)报告目的： ——对服务现状的客观反映，与服务级别协议对比，帮助管理者、IT服务提供方利业务部门了解服务提供情况； ——产生及时、可靠、精简并足够正确的报告作为決策的信息依据和有效沟通手段，服务陈述要能够帮助报告接收者理解报告内容； ——为服务管理人员进行决策提供证据，保证服务提供过程处于可控状态； ——为服务管理改进和变更活动提供决策、计划和执行参考，有利于服务的不断改进和资源利用率不断改善。 2)目标读者：公司领导层、客户、其他相关方等。 3.报告概述：报告主题、服务提供者介绍、服务报告周期、服务报告提交时间 4.本周期服务总体汇总：服务质量、重大故障公布、重大变更公布 5.服务绩效，记录服务绩效和服务级别协议之间对比，包括趋势等。 6.重大事件/问题回顾。 7.重大变更回顾。 8.IT服务趋势分析。 9.客户满意度分析。 10.报告的数据来源。