在可能的情况下，可以通过备用关键组件、故障检测和修正系统来满足高可用性标准。通常，自动反馈系统在故障发生时也会启动。然而，仍然需要采取各种组织措施，这些措施可以通过引入可用性管理来提供。
在可能的情况下，可以通过备用关键组件、故障检测和修正系统来满足高可用性标准。通常，自动反馈系统在故障发生时也会启动。然而，仍然需要采取各种组织措施，这些措施可以通过引入可用性管理来提供。
一旦业务明确地表明服务有可用性管理需求，则可以启动可用性管理。可用性管理是一个日常性运作的流程，它只有当一项服务逐步完成时才能终止。
可用性管理流程的输入（图14-2）包括：• 业务可用性需求；
• 对所有由IT所支持的业务流程进行的影响度评估；
• IT基础架构中的可用性、可靠性和可维护性需求；
• 关于影响服务或组件的故障的数据，其形式通常照事故或问题记录和报告；
• 有关服务和组件的配置和监控数据；
• 已实现的服务级别，相对于在服务级别协议中所包括的所有服务的约定服务级别。
可用性管理流程的输出包括：
• 针对新的或改进后的IT服务的可用性和恢复设计标准；
• 为获取必要的基础架构弹性从而减少或消除基础架构组件出现故障所产生的影响所需的技术；
• IT服务所要求的基础架构组件的可用性、可靠性和可维护性；
• 有关已实现可用性、可靠性和可维护性的报告；
• 可用性、可靠性和可维护性的监控需求；
• 为主动地改进IT基础架构而制定的可用性计划。
可用性管理包括一些关键性活动，这些活动主要涉及规划和监控两个方面。
这些活动是：• 规划
• 确定可用性需求
• 可用性设计
• 恢复能力设计
• 安全问题
• 维护管理
• 制定可用性计划。
• 监控
• 评价和报告
下面分别讨论这些关键性活动。
1、确定可用性需求
确定可用性需求必须在签订服务级别协议之前进行，且需考虑新的IT服务和需要对现有服务作出的变更两个方面。同时还应当在尽可能早的阶段确定IT部门是否能够满足这些需求以及怎样满足这些需求。
这项活动应当确认：
• 关键业务功能；
• 约定的IT服务中断时间；
• 可量化的可用性需求；
• 非计划的IT服务中断对业务功能所产生的可量化的影响；
• 客户的业务运作时段；
• 有关维护窗口期的约定。
在较早的阶段清楚地定义可用性需求对于防止在稍后的阶段里在可用性需求的解释方面产生混乱和差异具有重要作用。
客户的需求必须与实际能够提供的符合一致。如果这两者之间具有差异，则需要确定这种差异对成本所产生的影响。
2、可用性设计
那些影响可用性标准的薄弱环节应当尽早得到确认。这将有助于防止额外的开发成本、计划外的后期支出、单点故障（SPOF）、供应商收取的额外成本以及延迟的发布等情况发生。
基于适当的可用性标准的一个良好的可用性设计可以使得有可能与供应商签订有效的维护合同。设计过程中采用了一些技巧，如确认单点故障的组件故障影响度分析（CFIA）、CRAMM（见“IT服务持续性管理”一章）以及一些模拟技术。
如果可用性标准不能够实现，最好的选择是确认设计是否可以进一步改进。使用额外的技术、其它的方法、不同的发布策略、更好或不同的设计和开发工具有助于实现这些标准。
如果可用性需求特别难以达到，则应当考虑使用其它的容错技术、其它的服务流程（事故管理、问题管理和变更管理）或额外的服务管理资源。可动用的财务资源在很大程度上决定了选择的空间。
3、可维护性设计
完全不间断的可用性是不太可能的，因此，应当考虑服务不可用期这种情况。当一项服务中断以后，快速和恰当地解除故障以确保约定的可用性级别能够实现是非常重要的。针对可恢复性的设计活动还涉及到一个具有恰当的升级、沟通、备份和恢复程序的有效的事故管理流程。
有关可维护性设计活动的任务、职责和权限都必须明确定义。
4、关键的安全性问题
安全性和可靠性是密切相关的。一个较差的信息安全设计会直接影响到服务的可用性。高可用性要靠有效的信息安全来支撑。在规划阶段，应该考虑相关的安全问题，对安全问题可能给服务供应带来的影响也应当加以分析。
与安全问题相关的活动主要有：
• 确定谁将有权访问安全区域；
• 确定需要作出哪项关键授权。
5、维护管理
通常，在服务运作中都安排了服务不可用的窗口期。这些窗口期可用于采取一些预防行动，如软件和硬件的升级。在这些窗口期中还可以实施变更。然而，在24小时经济中，越来越难以确定适当的维护窗口期。维护活动的定义、实施和核实也因而逐渐成为可用性管理中的重大问题。
维护应当在对服务的影响最小时进行。这意味着必须提前知道维护的目标是什么、何时应当实施维护以及应当实施什么样的维护活动（这可以基于CFIA）。有关这几个问题的信息对于变更管理和其它活动是至关重要的。
6、评价和报告
评价和报告是重要的可用性管理活动，因为他们为核实服务协议、解决问题和制定改进建议提供了基础。
每一个事故生命周期包括下列几个步骤：
• 事故发生－用户意识到故障或故障被其它方式（技术的或物理的）识别到的时候；
• 检测－服务提供商得到故障发生的通知。此时的事故状态是“已报告”。该项活动花费的时间被称为检测时间；
• 响应－服务提供商需要时间来作出响应。这被称为响应时间。这段时间被用于进行事故诊断，其后一个步骤就是修复。事故管理流程包括验收和登记、分类、匹配、分析和诊断；
• 修复－服务提供商将导致故障的服务或组件恢复正常；
• 服务恢复－服务被恢复。这包括配置和初始化，以及服务被恢复给用户等活动。
图14-3显示了可以测度的一些期间。
如图所示，IT部门和外部承包商的响应时间是决定宕机时间的一个因素。由于这个因素可以被IT部门控制并且直接影响服务质量，因此，有关该因素的协议可以包括在服务级别协议中。对有关测度数据取平均值可以获取对相关因素的了解。这些平均值可用来确定已实现的服务级别和估计一项服务未来预期的可用性。这些信息还可以用来制定改进计划。
下列指标在可用性管理中经常用到：
• 平均修复时间（MTTR）－故障发生和服务恢复之间的平均时间，也被称之为宕机时间。它是检测时间和解决时间的和。这个指标与服务的可恢复性和可服务性相关；
• 平均无故障时间（MTBF）－从一次事故中恢复过来到下一次事故发生之间的平均间隔时间，也被称为正常运行时间。该指标与服务的可靠性有关；
• 平均系统事故间隔时间（MTBSI）－两次相邻的事故之间的间隔时间。平均系统事故间隔时间（MTBSI）等于平均修复时间（MTTR）和平均无故障时间（MTBF）之和。
平均无故障时间（MTBF）和平均系统事故间隔时间（MTBSI）之比可以表明，服务运作中是存在许多小的故障，或者仅仅是比较少的大故障。
可用性报告可以包括下列指标：
• 以MTTR、 MTBF 和MTBSI表示的可用率（或不可用率）；
• 总体正常运作时间和宕机时间；
• 故障的次数；
• 有关故障可能实际或潜在地导致比约定数更高的不可用率的额外信息。
可用性报告中可能存在的问题是呈报的指标可能与客户的体验并不是一致的。因此，从客户的角度报告可用性是非常重要的。可用性报告首先应当提供有关支持关键业务功能的服务的可用性，以及数据（从业务的角度）的可用性方面的信息，而不是有关技术上的IT组件的可用性方面的信息。报告应当以客户易于理解的语言撰写。
7、制定可用性计划
可用性计划是可用性管理的一项重大成果。它是有关未来几年内的服务可用性的一个长期计划。它不是可用性管理的实施计划。
该计划是一个不断变化的文档。起初，它应当描述当前的情形，随后它可以被扩充为包括对现有的服务和维护指南的改进活动，以及新的服务和维护指南的计划。制定一份全面而准确的计划要求与服务级别管理、IT服务持续性管理、能力管理、IT服务财务管理以及应用管理（直接或通过变更管理）等流程进行沟通。
8、工具
为了获得一定的效率，可用性管理必须在下列活动中使用一些工具：
• 确定宕机时间；
• 记录历史信息；
• 生成报告；
• 统计分析；
• 影响度分析。
可用性管理需要运用来自可用新管理记录、配置管理数据库以及能力数据库的信息。这些信息可能被存储在一个专门的可用性管理数据库（AMDB）中。
9、方法和技巧
现在有很多的可用性管理方法和技巧可用来支持可用性管理的规划、实施和报告。最重要的包括下面讨论的这些。
9.1组件故障影响度分析
这种方法运用一个包括每项服务中的战略性组件及其角色的矩阵。一个定义了服务和产品资源之间的关系的有效的配置管理数据库在制定该矩阵时最有帮助的。
图14-4所示的CFIA矩阵表明，在许多服务项上都被标记“X”的配置项属于IT基础架构中重要的组件（横向分析），而被频繁地标上“X”的服务项则属于复杂且对故障比较敏感的项目（纵向分析）。这种方法还可以应用于依靠第三方供应商提供IT服务的情形（高级CFIA）。
9.2故障树分析（FTA）
故障树分析是一种确认导致IT服务故障的事件链的技巧。针对每一项服务，运用布尔符号可以单独地画一棵树，并且这棵树是倒立着的。故障树分析(FTA)中区分了以下几类事件：
• 基础事件－图（循环）中的起始端，如电力中断和操作错误等。这些事件无需进一步进行调查；
• 结果事件－图中的节点，它是由一些更早的事件的组合所导致的；
• 条件事件－仅在某些条件下才发生的事件，如空调器失灵；
• 触发事件－导致其它事件发生的事件，如由UPS所触发的自动关机。
事件可以通过一些逻辑运算组合起来，如：
• “与”运算－如果所有的输入条件都成立，则结果事件发生；
• “或”运算－如果一项或多项输入条件成立，则结果事件发生；
• “异或”运算－当且仅当一项输入条件成立时，结果事件发生；
• “禁止”运算－如果所有的输入条件都不满足，则结果事件发生。
9.3 CCTA风险分析和管理（CRAMM）
CRAMM描述了一种确认合理的措施来保护IT基础架构的保密性、完整性和可用性的方法。这种方法在“IT服务持续性管理”一章中作了较详细的介绍。
9.4可用性计算
上述讨论这些指标可用来与客户签订服务可用性协议。这些协议最终被包括在服务级别协议中。下面的公式可用于确定已实现的可用性级别是否满足了约定的可用性需求。
实际的正常运作时间等于约定服务时间（AST）和在该约定服务时间内实际的宕机时间（DT）之间的差。例如，如果约定在正常工作日内从上午7点至下午7点之间服务可用率应达到98％，并且在该约定服务时间内发生了2小时的服务中断，则实际的可用性百分比（可用率）是：
1.1.1.1 服务中断分析（SOA）
SOA是一种技巧，它可用来确认故障发生的原因，调查IT部门及其流程的有效性，以及提出并实施改进建议。SOA的特点包括以下几个方面：
• 拥有很宽的范围：其应用不仅限于基础架构，而包括流程、程序和文化方面；
• 从客户的角度考虑问题；
• 由来自客户和IT部门的代表联合实施（SOA团队）。
其优点在于它是一种更为有效的方法、促进了客户和供应商之间的直接沟通，以及为提出改进建议提供了更广泛的基础。
1.1.1.2 技术检查组（TOP）
当使用TOP方法时，一个由IT专家组成的专门小组将集中关注可用性的某一个方面。这种方法适用于常规的工具不能提供足够的支持的时候。通过TOP，还可以结合利用设计人员和系统经理们的专家经验。
这种方法的关键特性在于，它是一种可以快速得出结论的高效、有效和非正式的方法。
京ICP备06004481号 Copyright 2002 - 2006 ITGov.org.cn, All Rights Reserved