可用性管理程序（ISO20000-1：2018）.docxVIP

可用性管理程序 目的 提供符合预定可用性级别且成本合理的IT服务，以帮助企业实现其业务目标；确保已经取得的可用性级别能够得以评价和计量，以及在必要时进行持续改进。 过程定义 范围 本程序适用于系统集成部。 所有新增IT服务以及服务承诺： 公司开发的信息系统集成项目和软件运维项目售后服务工作； 涉及到的服务组件，如服务器、网络设备、硬件设备等。 过程负责人 可用性管理员，可用性负责人，部门经理 主要输入 输入 来源 服务级别需求 服务需求调研。 配置管理 系统的配置项，记录和报告配置。 主要输出 输出 去向 风险评估报告 可用性负责人、部门经理。 可用性计划 可用性负责人、部门经理。 服务报告管理 服务报告过程中的主要步骤。 职责权限 可用性管理员：负责可用性服务的具体实施，计划和报告的编制。 可用性负责人是可用性管理的关键角色，其职责有： 定义、开发并管理可用性管理流程； 确保IT服务在经过设计后，实际的服务重要性（一般、重要、紧急、重要紧急）能够符合约定的服务级别； 制定可用性计划； 撰写可用性报告,归并于IT服务报告中； 提出优化IT基础架构的改进建议。 部门经理： 安排人员对IT服务的风险评估报告和可用性计划的编制； 根据服务承诺，提交IT服务报告给公司主管领导。 过程重要控制点 风险评估报告。 可用性计划。 可用性报告(IT服务报告)。 过程测量指标 故障的次数。 术语 术语 定义 可用性 指一个组件或一种服务在设定的某个时刻或某段时间内发挥其应有功能的能力，因此，高可用性意味着服务对客户是持续可用的，宕机时间少且可迅速恢复。 可用性管理 建立和维护可用性流程的信息系统及为达到此目的而根据特定需求所提供的服务。 流程 过程描述 可用性需求识别和分析 可用性负责人根据服务级别需求识别和分析可用性需求，加入到《服务需求说明书》中，可用性需求分析包括： 对软件系统维护服务的定义； 软件系统对公司的重要性； 软件系统系统所支持的并发用户数量； 系统故障时间或服务不可用状态造成的业务影响； 故障停机时间或服务不可用状态产生的成本代价以及成本代价随时间推移相应变化的方式； 所需服务小时数； 较容易承受停机故障的次要服务时段； 专为计划内维护与升级工作设定的停机时段； 启动应急计划之前所能容许的故障停机时间。 需求识别时间： 在签订合同协议之前进行； 需考虑新的IT服务和需求对现有服务做出的变更的方面； 尽可能早的阶段确定客服部门是否能够实现这些需求以及怎样实现这些需求。 需求识别内容： 关键业务功能； 可量化的可用性需求； 非计划的IT服务中断对业务功能所产生的可量化的影响； 客户的业务正常运作时段； 有关定期维护约定的中断时间。 定义可用性目标 可用性管理负责根据可用性定义的结果确定可用性目标。识别可用性管理的服务对象和组件，并提供可用性目标。 调查服务组件的可用性 可用性负责人调查服务组件的使用年限、性能、已发生故障情况等内容，并把调查的结果写入到《风险评估报告》中。 识别可用性风险和对策 可用性负责人员根据服务组件的调查情况识别组件的薄弱点、威胁及可能存在的风险隐患，编制《风险评估报告》。 可用性设计 可用性负责人员根据《风险评估报告》进行可用性管理的方案设计，设计的原则包括： 确认那些影响系统运行和服务运行的薄弱环节。 基于适当的可用性标准的一个良好的可用性设计可以使得有可能与供应商签订有效的维护合同。设计过程中采用了一些技巧，如确认单点故障的组件故障影响度分析。 如果可用性标准不能够实现，最好的选择是确认设计是否可以进一步改进。 如果可用性需求特别难以达到，则应当考虑使用其它的容错技术、其它的服务流程（事件管理、问题管理和变更管理）或额外的服务管理资源。 可用性计划 为有效地实施有关可用性管理活动以改进IT组件及服务的可用性，必须制定明确的《可用性计划》。 可用性计划包括运行监控、日常维护和故障恢复方案等内容。 可用性计划不仅需要关注技术方面的问题，还应对可用性管理的人员、流程、工具和技术等方面进行考虑。在可用性管理的初始阶段，可用性计划与实施通常是紧密结合进行的，但这两者却又是不同的，不能将它们混淆。 可用性计划的计划周期应当覆盖1至2年，并且对于前6个月的计划应当提供更为详细的信息。 值得注意的是，可用性计划应当和能力计划和财务预算的周期保持一致。 可用性计划一般包括以下部分： 对目前状况可用性的评估； 改善现有服务活动的步骤； 实施新服务与维护的一系列计划。 服务组件设计 服务组件监控设计 所有IT组件都必须按照计划进行有关监控活动。有计划的监控活动可以： 及时发现IT组件的健康状况。 找出系统运行存在的薄弱点和风险隐患。 服务组件维护设计 所有IT组件都必须按照计划进行有关维护活动。有计划的维护活动可以使