扫码获取 VIP 码
添加管理员微信获取 VIP 码
可用性管理在软考高级科目系统规划与管理师中占据重要分值，是信息技术服务管理体系中的关键过程域。在信息技术基础架构库的定义体系中，可用性被精确描述为配置项或信息技术服务在需要时执行其约定功能的能力。这个定义有三层关键含义：第一，对象是配置项或信息技术服务，配置项是信息技术服务管理的基本管理单元，小到一台服务器上的一个数据库实例，大到一个端到端的完整业务服务；第二，约定功能而非全部功能，文件服务器的打印服务不可用但文件共享正常，从文件共享服务的约定视角它依然是可用的；第三，时机条件是在需要时，周末凌晨的故障若不发生在约定服务时段内，从服务级别的维度不计入可用性违约。
在信息技术服务管理全生命周期中，可用性管理属于服务设计阶段的核心流程。其上游输入来自服务级别管理，服务级别协议中约定了可用性目标与测量周期；其下游输出流入容量管理、信息安全管理与信息技术服务连续性管理等关联流程。可用性目标的达成需要充足容量支撑、安全控制措施保障以及灾难恢复能力兜底，决定了可用性管理不是一个独立指标统计过程而是系统工程。
国际标准将信息技术服务的可用性分解为可靠性、可维护性及可服务性三个维度。可靠性是指配置项在规定条件下和规定时间内无故障运行的能力，度量为平均无故障时间，主要受制于硬件元器件质量、软件代码缺陷密度和运行环境的稳定性；可维护性是指故障发生后恢复到正常状态的能力，度量为平均修复时间，取决于故障诊断工具的完备度、备件供应链的响应速度和技术人员的技能水平；可服务性则是外部供应商或第三方在合同框架内提供维护支持的能力，反映外包维护服务的响应效率和质量保障。可用性本质上是可靠性与可维护性加可服务性三者的函数，高可靠性配上差可维护性依然会导致低可用性，而中等可靠性配上极好的可维护性反而可能让用户感知不到中断。这个三角关系是解答软考概念辨析题的关键钥匙，尤其在区分可用性管理与单纯可靠性工程的考查点上反复出现。
可用性管理的量化特性使数学计算成为软考命题的重要阵地。可用性基本公式为服务可用时间除以约定服务时间的比值，用符号表达即平均无故障时间除以平均无故障时间与平均修复时间之和再乘百分之百。从数学上看这个公式揭示了提高可用性的两条基本路径：分子增大也就是延长无故障运行时间，或分母减小也就是缩短修复时间。在实际工程决策中增大分子和减小分母的成本函数完全不同，硬件冗余是典型的增大分子手段而自动化故障转移是典型的减小分母手段，两者结合才能以最小成本达到既定可用性目标。分母中的约定服务时间是服务级别协议中规定的服务时段，不是二十四小时乘以三百六十五天。一个只在工作日早九点到晚六点提供服务的系统，周末故障不计入不可用时间。计划停机时间如数据库升级、补丁安装经提前通知批准后通常也不计入，考生必须精准审题确认题目给定的约定服务时间边界。
平均无故障时间计算为系统累计正常运行总时间除以故障次数。这里正常运行总时间必须扣除计划停机和外部因素导致的非系统故障中断；故障的定义边界指的是导致服务中断或降级的事件，未影响业务的瞬态告警不算。平均修复时间为从故障发生到服务恢复的总修复时间除以故障次数，计时从故障被检测或报告起算到服务恢复正常可用为止，包含故障定位、备件更换、系统重启和功能验证等全链条时间。运维实践中故障检测时间往往是修复总时间中的最大组分，这也是高可用架构强调自动化监控和自动故障转移的根本原因。
第三个关键指标平均系统事故间隔时间等于平均无故障时间加上平均修复时间，表征两次故障事件之间的平均时间跨度。两套系统可能有相同可用性百分比但平均系统事故间隔时间截然不同。平均无故障时间一千小时配合平均修复时间一小时的系统，与平均无故障时间一百小时配合平均修复时间零点一小时的系统，可用性都是约百分之九十九点九，但前者故障间隔长次数少，后者故障频繁但恢复极快。第一种模式适合运维人员编制精简但技能深度强的团队，每次故障都是硬仗但间隔充裕可以做复盘和经验沉淀；第二种模式适合自动化平台建设成熟的团队，人工几乎不介入单次恢复过程全靠自愈机制兜底。两种模式对运维团队的应对策略要求完全不同，软考案例分析中可以从团队配置和自动化投资的角度展开论述。
可用性百分比与年度停机时间的精确对应关系是高频计算考点。百分之九十九可用性年度约停机八十七点六小时，百分之九十九点九约八点七六小时，百分之九十九点九九约五十二点六分钟，百分之九十九点九九九约五点二六分钟。每提升一个九年度停机时间缩水约十倍而实现成本指数级增长。考生必须熟练掌握九个级数与停机时间的快速换算，在选择题中看到多个九个级数相关的选项时统一换算成年停机小时数再进行大小比较是最可靠的解题策略。
平均无故障时间衡量可靠性水平，只关心两次故障之间系统正常工作了多久，与修复速度无关。提升手段包括选用高质量元器件、降额设计、冗余热备消除单点故障、建立预防性维护制度定期更换老化部件。平均修复时间衡量可维护性水平，核心在于缩短故障检测时间、故障定位时间和故障修复时间三个分量。检测时间靠完善监控告警缩短，定位时间靠知识库积累与日志聚合平台缩短，修复时间靠自动化脚本、预置备件与标准化应急处置手册缩短。平均系统事故间隔时间将两个指标打包，用于估算给定时间窗口内的预期故障次数以合理安排运维资源。
单看任何一个指标都会导致对可用性的系统误判。第一个硬件平台平均无故障时间一万小时平均修复时间十小时，第二个平台平均无故障时间五千小时平均修复时间两小时。若只看平均无故障时间前者明显更优，但计算可用性前者约百分之九十九点九而后者约百分之九十九点九六，反而更胜一筹。原因在于后者虽然故障频率翻倍但每次修复只需五分之一时间，总不可用时间更少。这表明两个指标必须捆绑才能获得完整可用性图景。
从运维体验看，两个指标组合决定了不同的故障应对模式。高平均无故障时间高平均修复时间是一种偶发但耗时长的故障模式，考验运维人员的技能深度；低平均无故障时间极低平均修复时间是高频但瞬回的模式，适合自动化自愈架构。两种模式对应不同的人员配置和自动化投资方向。从服务级别协议视角，甲方只关心可用性百分比是否达标，至于通过提高可靠性还是提高可维护性来实现，属于乙方的技术决策。系统规划与管理师在制定可用性计划时必须综合权衡两个指标，综合考虑技术可行性、成本约束和运维组织能力三者之后做出最优路径选择。
可用性百分比是高度浓缩的数字，浓缩意味着信息丢失，软考命题人由此设计多种陷阱。第一个陷阱是计划停机时间的归属。若题目未明确排除计划停机，默认计算公式中已经包含计划内中断，但实际服务级别协议中往往约定计划停机经批准后不计入违约，考生必须仔细审题确认设定条件。第二个陷阱是感知偏差，百分之九十九与百分之九十九点九之间只差零点九个百分点看似微不足道，换算成年度停机却是八十七点六小时与八点七六小时之间差了整整十倍。解决方法是统一换算为停机时间后再比较。第三个陷阱是串联系统可用性的误判。三个可用性百分之九十九的组件串联后整体可用性为百分之九十七，年度停机超过十一天，每增加一个单点风险翻倍，绝不能取最差或最好的组件可用性代表全局。第四个陷阱是测量颗粒度问题，百分之九十九点九的年度停机若集中在一次八小时大故障中的影响远比分十二次每次十分钟严重，但两者在单一指标下完全不可区分。案例分析中考生需指出仅凭可用性百分比不足以全面评价服务质量，还需结合最大单次中断时长和故障
本篇完！