服务可用性是衡量系统或服务正常运行时间比例的关键指标，通常用百分比表示，例如99.9%，高可用性对于业务连续性至关重要，但并非越高越好，需要平衡成本。
服务可用性怎么计算？从SLA到实际可用时间
服务可用性的计算看似简单,但实际中容易踩坑，最基础的公式是：可用性 = (总时间 – 停机时间) / 总时间 × 100%，总时间通常取一个月或一个季度，停机时间从服务不可用开始计算，直到恢复。
举个例子,假设你有一个API服务，一个月内发生了两次故障，每次修复时间30分钟，那么总停机时间1小时，按30天720小时算，可用性就是 (720 – 1) / 720 = 99.86%，这个数字离常见的99.9%还有差距，99.9%的可用性对应每年最多8.76小时的停机，而99.99%则降至52.56分钟，99.999%更是只有5.26分钟。
不少云厂商在SLA中会使用不同的统计口径,比如按月度计算、按服务实例计算，甚至排除计划内维护，你在选择服务时，一定要看清SLA的计量方式，业内专家指出：可用性数字越高，对应的架构复杂度和成本也呈指数级上升。
计划内维护是否计入停机时间,也是常见的争议点，有些SLA明确排除计划内维护，但用户可能认为维护期间服务不可用，现代服务提供商开始采用滚动更新、蓝绿部署等零停机维护技术，尽量缩短用户感知的停机时间，在计算可用性时，你还需要考虑自己对维护窗口的容忍度，以及是否接受维护期间的降级服务。
服务可用性99.9%够吗？不同行业的标准对比
这个问题没有统一答案,关键看你的业务场景，对于中小型展示网站，99.9%的可用性已经足够，每年的8.76小时停机可能发生在非高峰期，影响有限，但对于金融交易系统、电商秒杀活动、在线医疗平台，99.9%就不够看了，往往需要99.99%甚至99.999%的保障。
不同行业对可用性的要求差异很大,我们可以用一个表格来对比：
| 行业类型 | 典型可用性要求 | 年停机时间参考 |
|---|---|---|
| 企业官网、博客 | 5% – 99.9% | 8小时 – 8.76小时 |
| 电商平台、SaaS | 9% – 99.99% | 76小时 – 52.56分钟 |
| 金融交易、支付 | 99% – 99.999% | 56分钟 – 5.26分钟 |
| 电信核心网、工业控制 | 999% 以上 | 少于5.26分钟 |
国内主流云服务商的单实例SLA普遍在99.95%到99.99%之间，但实际可用性受地域、运营商、自身架构影响，如果你需要更高可用性，通常需要采用多可用区部署或跨地域灾备方案，这会将成本推高一个数量级。
据统计,相当一部分企业对于可用性的要求并不高，但往往因为对SLA条款理解不深，导致在故障时无法获得预期的赔偿，评估你的业务对停机时间的敏感度，是选择可用性等级的第一步。
云服务可用性SLA中的常见条款
SLA不仅是数字,更是一份协议，常见的条款包括：不可用定义（如所有请求失败才算？部分失败不算？）、维护窗口（是否计入停机）、赔付标准（是退费还是赠送时长）、例外情况（如运营商故障、攻击等），许多用户只盯着99.9%的数字，却忽略了例外条款，结果真正出问题时得不到赔付，建议你在签订合同前，逐条核对SLA的免责条款和赔付上限。
有些云服务商规定,只有服务整体不可用且持续超过5分钟才计入停机时间，而单次请求失败、网络抖动等都不算，这意味着，即使你的服务短暂中断，也可能达不到赔付标准，理解SLA的细则比看数字更重要。
SLA通常还会约定赔付比例,比如可用性低于承诺值0.1%以内，赔偿月度服务费的10%；低于0.5%以上，赔偿30%等，但具体数值因厂商而异，需要你仔细阅读。
如何提高服务可用性？架构层面的关键举措
提高可用性是一个系统工程,需要从架构、运维、流程多个层面入手，以下是几个核心举措：
- 冗余设计：避免单点故障，关键组件至少部署两个副本，比如采用多可用区部署、主从复制。
- 负载均衡：将流量分散到多个实例，一旦某个实例故障，自动摘除。
- 自动故障转移：通过健康检查、心跳检测，当主节点失效时，自动切换到备用节点。
- 数据备份与恢复：定期备份数据，并定期演练恢复流程，确保备份可用。
- 监控与告警：实时监控各项指标（CPU、内存、错误率、响应时间），设置合理的告警阈值，以便第一时间发现异常。
- 容量规划与弹性伸缩：根据业务增长和流量波动，预留冗余资源，并启用自动伸缩以应对突发流量。
这些措施并不是孤立的,需要组合使用，在配置负载均衡时，健康检查的间隔和超时设置很关键，如果设置不当，可能导致故障转移滞后或误判，以Nginx为例，你可以配置upstream的健康检查，当后端服务器连续返回5xx错误时自动移除，但要注意，检查频率不宜过高，否则可能影响性能。
定期进行故障演练也很有必要,行业共识认为，纸上谈兵式的架构设计无法应对真实故障，只有通过演练才能发现隐藏问题，你可以定期模拟某个实例宕机，观察系统是否自动切换，以及切换时间是否在可接受范围内。
高可用服务价格与成本权衡
高可用不是免费的,从99.9%提升到99.99%，成本可能增加明显，据一些统计，投入可能增加数倍；再提升到99.999%，成本可能更高，你需要根据业务的重要性来决定投入多少。
成本主要包括：更多服务器实例、跨地域带宽、复杂的运维工具、专业人力成本，对于初创企业，建议先以99.9%为目标，随着业务增长再逐步提升，对于关键业务，可以考虑混合云或本地备份方案，但成本会更贵。
国内云服务商提供不同规格的高可用方案,比如单可用区、双可用区、多地域部署，价格差异明显，在选购时，不要只看价格，还要看是否包含必要的运维支持和故障恢复保障，双可用区部署的实例成本通常是单可用区的两倍以上，但可用性可以提升到99.99%级别。
地域选择也会影响成本,华东地区的云资源相对丰富，价格可能更有竞争力，而某些偏远地区可能资源紧张，价格更高，在预算有限的情况下，可以优先选择主流地域，并利用可用区冗余来平衡成本与可用性。
服务可用性常见问题解答
问：服务可用性怎么计算更准确？
答：最准确的计算方式是采用真实的可用时间监控数据，排除计划内维护，以月度或季度为周期，计算所有服务实例的加权平均可用性，注意，不同云服务商的计算口径可能不同，例如有些只计算应用层，有些包含网络层。
问：云服务可用性SLA中的99.99%可靠吗？
答：99.99%是一个很高的承诺，意味着年停机时间不超过52.56分钟，但实际能否达到，取决于你的架构是否满足SLA的前提条件，比如是否部署了多可用区实例，如果只是单实例，云厂商通常只承诺99.95%左右，即使SLA承诺了99.99%，你也可能因为自身配置问题导致不可用，那样不在赔付范围内。
问：如何提高服务可用性而不增加太多成本？
答：确认你的业务真的需要极高可用性，避免过度设计，优先从架构层面解决单点故障，例如使用开源工具实现负载均衡和自动故障转移，而不是直接购买昂贵的商业方案，通过自动化运维和监控告警来减少人工干预，降低运维成本。
服务可用性是一个需要持续投入和优化的过程，没有一劳永逸的解决方案，根据你的业务目标、预算和风险承受能力，选择最适合的可用性等级，并不断通过监控和演练来验证和提升。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/513551.html
