服务提供者必须对新服务或更新的服务完成后产生的结果与规划实施后会产生的结果进行比较并提出差异报告，比较结果的事后审查必须透过变更管理程序，其结果也必须向相关单位报告。
1 服务交付过程1.1 服务级别管理 实施服务级别管理，应：
1) 定义运维团队的服务目录（Service Catalog），并进行维护，保持更新；
2) 就服务的范围、相关服务级别目标及工作量等与相关方达成协议，并予以记录；
3) 对每个提供的服务定义、协商和文件化成一个或多个服务级别协议（SLAs）；
4) 服务级别协议（SLA）、供应商合同（UC）、OLA继及相关程序等都必须与相关方达成协议，并予以记录；
5) SLA应定期应进行评审，以确保它们被更新与保持有效；
6) 要针对服务级别目标区监控与报告服务级别状况，显示当前与未来的发展趋势信息；
7) 报告和评审不合格项的原因、改进措施，予以记录，并输入服务改进计划。
SLA的改变可通过变更管理进行控制，详细的服务级别管理请参照『ITSM-2-SL-01服务级别管理流程』。
“服务级别协议”应包括下列信息：
1) 服务定义
2) 服务类别及子目录
3) 协议期限
4) 协议范围
5) 服务内容及服务标准
6) 服务团队和负责人
7) 服务报告
1.2 服务报告管理 服务报告策略：
Ÿ 服务报告可能包括给用户和内部管理层的不同报告；
Ÿ 运维团队应与用户和管理层协商，就报告的种类、数量、信息内容、频度达成一致每一份服务报告应清楚定义报告的目的、读者、来源。
Ÿ 服务报告的内容需要与用户和内部管理层协商确定，能够提供趋势分析并在条件成熟时提供绩效考核数据；
服务报告至少应包括：
1) 服务级别流程的运行情况；
2) 不符合项和问题，SLA违反及安全事件；
3) 重大事件报告；
4) 服务资源的使用情况；
5) 满意度分析；
6) 趋势信息；
详细的服务报告管理细节请参阅『ITSM-2-SR-01服务报告管理规范』。
1.3 可用性及持续性管理 可用性与持续性管理是确保在所有情况下，IT运维团队都能达到先前的承诺。鉴于IT运维团队现实情况，在服务管理手册中定义，将可用性与持续性进分离，将可用与能力管理进行合并，持续性管理独立出来。
服务持续性及可用性管理的内容，应遵照：
1) 应开发可用性和服务持续性计划，并且每年需要评审一次；并维护这个计划以确保反映业务需求的改变；
2) 当服务环境发生重大变化时，应重新测可用性和服务持续性计划；
3) 可用性应被测量和记录，未计划的“不可用”应被调查，并采取适当措施；
4) 应根据业务需求对服务持续性计划进行测试并且予记录，如果测试失败需要采取措施；
详细的可用性和持续性管理规范，请参阅『ITSM-2-CN-01_持续性和可用性管理规范』。
1.4 财务管理 财务管理为了提供服务成本的预算及核算。IT运维团队的财务策略是采取利润中心制。IT运维团队会对服务所涉及到的所有成本要素进行核算与预算，同时区分直接成本与间接成本的分配，并对财务进行有效的控制，预算成本就有详细的数据清单，以确保财务的真正控制和决策，在服务周期内IT运维团队应监控和报告预算及成本、评审财务预测和管理成本，服务变更亦需要进计算，通过变更管理流程进行批准。
运维团队实施内部的预算及核算，应：
1) 对服务所涉及到的所有成本要素进行核算与预算，同时区分直接成本与间接成本的分配
2) 计算详细的预算成本，以确保财务的真正控制和决策；
3) 计算服务变更的成本，通过变更管理流程进行批准；
4) 在服务周期内，运维团队应监控、跟踪和报告预算及成本、评审财务预测以及管理成本。
财务管理的细则的进一步说明，请参见『ITSM-2-BA-01 预算与核算管理规范』。
1.5 能力管理 能力管理的目标是确保IT运维团队一直保持有效的能力去满足当前和未来的客户业务需求。由于业务需求与能力直接相关，能力也导致可用性的达成，所以在服务管理手册中定义将能力与可用性合并。
能力管理应制定及维护能力计划，此计划的制定与监测是本流程的核心，内容应包括：
1) 描述业务需求；
2) 目前与预期的能力和性能需求；
3) 识别服务升级的时程、阀值和成本；
4) 评估预定的服务升级的影响，要求变更，对新技术与技巧的能力；
5) 预测外部变更的影响，例如业务环境的变化；
6) 对数据和流程进预先分析。
关于定义监控服务能力、调整性能等的方法、程序、技术请具体参见『ITSM-2-CA-01_能力管理流程手册』。
1.6 信息安全管理 信息安全管理的目的是为了确保服务活动中的信息安全。IT运维团队的信息安全策略是：从流程、技术、人员层面保障信息安全，不让服务活动造成信息价值的流失。
信息安全控制措施需文档化，需要描述相关的控制措施、运行和维护方式，访问信息系统和服务时，应基于正式的协议，正式协议应定义所有必要安全需求。IT运维团队应至少每年一次对信息安全的风险进行评估及分析。
IT服务的信息安全管理要求，参照服务中心信息安全管理体系（ISO 27001）予以规划、执行、监控与改善。当遇到安全事件时，应尽快地依照事件管理流程进行报告和记录，设定适当的程序来确保所有安全事件皆能侦查得到，并且采取管理性行动。组织应安排适当的机制来处理在型式上、数量多寡(volume)上和安全事件上的影响，对功能故障也应进行量化和监控，并将结果列入服务改善计划中。
所有安全事件应被记录，安全事件服从事件管理机制，安全事件的数量的类型、数量及影响需要进行定期分析。
2 关系过程 关系流程包括两个方面：业务关系管理和供应商管理。
从运维团队的角度而言，关系过程包括同用户（服务关系）以及与供应商（被服务关系）两个方面，运维团队应保持与用户和供应商之间的良好关系。
外部供应商关系管理可以采用正式的合同形式来约束，内部供应商关系管理则通过一系列的运营指标（条件成熟时，以运营级别协议形式）来管理。
2.1 业务关系管理 为在理解用户和他们的业务的基础上，与用户之间建立和维护良好的关系。实施用户关系管理：
1) 运维团队应识别所有服务利益相关方，并形成文件。
2) 运维团队需按照计划间隔周期进行用户满意度进行测量，以得到量化后的用户感知数据。
3) 运维团队需要设计投诉流程，并得到用户同意，以保证投诉流程的合理性。所有投诉需要被记录、调查、响应、报告，所有投诉需要得到关闭，如果投诉不能通过正常渠道解决，需要考虑升级措施。
4) 运维团队需建立定期回访机制，收集用户反馈并进行改善。
5) 运维团队需要指定质量一名人员负责管理用户满意和整体用户关系流程。
6) 运维团队与用户至少每年进行一次服务评审，讨论服务范围、SLA、业务需求的变化。另一方面，在服务周期内应举行会议，讨论服务绩效，并形成会议记录。注意：如果合同发生变更，在会议上需要对SLA进行相应的变更讨论，并通过变更管理机制进行控制。
详细的业务关系管理细则请参见『ITSM-2-BR-01 业务关系管理规范』。
2.2 供应商管理 供应商管理的目的是为了管理运维团队与供应商之间的关系，并确保供应商在服务提供过程中能够达到其与运维团队约定的服务质量。运维团队的供应商管理应：
注：不包括供应商的选择。
1) 制定供应商管理程序，并指定人员负责和管理不同的供应商。
2) 供应商提供的服务需求、服务范围、服务级别和沟通流程应明确定义并记录在供应商合同或其他文件中，并获得相关方同意；
3) 供应商应区分直接供应商与分包供应商，直接供应商应确保分包供应商达到合同要求，共中的角色、关系同样需要文件化。
4) 每年至少有一次机会对供应商的合同进行评审，以确保满足新的业务需求。如果合同变更，SLA应相应改变，同时需要走变更管理机制进行评审控制。
5) 有相应的机制处理合同的纠纷；
6) 有相应的机制处理服务的正常终止、服务的提前终止和服务转移；
7) 监控和评审供应商对运维团队提供服务的服务级别目标的执行。对供应商服务级别和服务质量的改善，应作为服务改进计划的一个输入来执行。
详细的供应商管理细则请参见『ITSM-2-SM-01 供应商管理规范』。
1 解决过程 IT运维团队定义的解决过程分为二块：事件、问题，虽然这两部份紧密相连，但作业程序是保持独立的。
1.1 事件管理 事件管理的目标是尽快恢复承诺的服务或响应用户的服务请求。运维团队事件管理流程应该关注： ITSS认证
1) 定义事件的范畴，明确哪些应该作为事件来处理；
2) 记录所有的事件，每一个事件需要记录从受理到关闭全部的生命周期过程。
3) 明确定义事件的分类和优先级，并根据优先级定义不同的处理机制，比如目标时间、升级和通知等原则；
4) 保持通知机制，及时报告给用户事件处理或服务请求的进展；
5) 在事件处理时，如果发现不能达到承诺的服务级别，应提前警告并采取措施；
6) 应定义重大事件、信息安全事件；
7) 所有重大事件处理完毕应进行事后的回顾和分析，并提出改进计划；
8) 所有与事件相关的人员应有权访问相关的信息，如经验手册、历史的事件记录和配置管理数据库；
9) 应对事件的数量、类型、级别进行统计分析，产生月报和周报，作为分析改进的依据。
事件管理的细则请参照『ITSM-2-IM-01 事件管理流程手册』。
1.2 问题管理 问题管理的目的是主动的识别和分析事件的原因，并采取预防措施，减少事件重发、频发的数量，以降低事件和问题对业务的破坏，运维团队问题管理流程应：
1) 应记录所有的问题；
2) 问题应被分类分级，应规定所有问题的记录、优先级、业务影响、分类、调查、诊断、解决方案和正式关闭的全过程；
3) 采取预防措施减少潜在问题；
4) 问题的解决，如需要发起变更，应当通过变更管理进行控制；
5) 应识别和记录已知错误，以确保对事件管理提供支持；
6) 问题的数据、类型、级别需要进行统计分析，以便运维团队了解问题趋势及发展。
详细的问题管理程序请参见『ITSM-2-PM-01 问题管理流程手册』。
2 控制过程 IT运维团队定义的控制过程包括：配置管理、变更管理。在规划过程中，此两者密不可分。
2.1 配置管理 配置管理的目的是定义及控制服务和基础设施的组件，维护准确的配置信息，以对服务活动有效支持。
IT运维团队配置管理必须遵循下列策略：
1) 配置项必须被赋予一个名字和描述，且必须是唯一的，并保证配置项信息的完整；
2) 配置项的变更应被适当的追踪和评审，如生产环境中软件的更新升级和硬件迁移安装；
3) 所有的有关生产环境配置项的变更都需要通过变更管理程序进行控制。变更记录关闭前，必须通知到配置管理并得到批准；
4) 只有得到授权的人员才能对配置管理数据库中的配置项信息进行修改或调整；
5) 定期（每年）对配置项记录和信息进行审计以确保配置管理数据库的正确性和完整性；
6) 相关人员应可以访问配置项的状态、版本、位置、相关变更、问题和文档；
7) 配置项在投放生产环境前需要建立基线。
IT运维团队需要建立一个强有力而有效的配置管理机制，一方面需要把握配置数据维护的正确，同时需要注意对服务活动的影响，在数据正确与服务效率间取得平衡。IT运维团队需采取软件工具建立CMDB，关于配置管理的细则请参见『ITSM-2-CM-01 配置管理流程手册』。
2.2 变更管理 变更管理的目的是为了保证所有变更的行为是合法、受控的，变更管理需要在效率和风险之间取得平衡：
1) 需要清楚定义变更管理的范围；
2) 所有变更请求都应被记录、分类，比如重大变更、紧急变更、一般变更和标准变更；
3) 对于非标准变更需要评估其影响与风险；
4) 变更评审通常应包括业务评审、技术评审、合规性检查和实施后评审等环节；
5) 变更管理还应包括变更失败时的恢复及补救措施；
6) 变更实施的效果应得到验证才能对变更请求进行关闭；
7) 建立策略和程序，以控制紧急变更的授权和实施；
8) 定期分析变更记录，检查变更频繁发生的类型、呈现的趋势和分布等信息，记录变更分析的结果和结论；
9) 变更分析和改进措施，应作为服务改进计划的一个输入。
关于变更管理的细则请参见『ITSM-2-CH-01 变更管理流程手册』。
3 发布过程 发布管理的目的是为了交付、分发和跟踪进入生产环境的一个或多个变更。通常发布管理是集成在变更管理中，作为变更实施这个子环节来进行的。
运维团队发布管理的策略：
1) 所有的发布都需要进行测试、验证及记录；
2) 发布必须得到所有相关方的同意与授权；
3) 确保在发布进行前，需要进行测试、验证及记录，必要时要建立可控的测试环境以支持；
4) 设计并执行发布，保证发布的软/硬件的完整性；
5) 应定义发布失败后的恢复及补救措施；
6) 紧急发布应根据已定义的紧急变更流程管理进行。
7) 要对发布的结果和期间的事件进行测量和分析，发布流程的改善建议要输入服务改进计划。
发布管理细则请参见『ITSM-2-RM-01 发布管理流程手册』。 ITSS考试
4 手册结论 服务管理手册提供了广州地铁运维团队的IT运维服务框架及体系概要，后续一切的程序文件都围绕服务管理手册的精神进行编制，更多的体系细节信息在后续程序文件约定及说明。手册的修订过程也是运维团队的服务体系构建及规划过程，中间历经反复修订，最后成形发布。
手册汇聚了运维团队多年来的经验与知识。在我们理解中，服务体系会伴随着运维团队的成长而不断完善进化，但由于受限于服务体系建设在中国的普遍现状，以及用户对服务的认识和理解还需要一个逐步成熟的过程，所以仍然需要运维团队在将来的工作中逐步地和持续地对服务体系做出改进，不断提高服务管理水平。
本帖关键字：ITSS
转播
分享
淘帖
()