阿里云 缓存服务器

SLA（Service Level Agreement）全称为服务等级协议，是服务提供方与客户之间的一份正式协议，也可以称为技术合同。它量化地定义了客户可以期望从服务中获得的服务质量水平， 用以支撑客户的信任和消费。

SLA在公有云厂商提供产品服务时成为必要的合同承诺，是必不可少的。但近年来很多企业在面向企业内部系统或者企业自身的ToC应用时也会制定SLA，但是缺乏系统性的认知导致制定了一些无法落地的目标，成为一纸空文。

对于SLA特别需要注意的是：

• SLA是一个技术合同，不是一个具体几个9数字，SLA包含服务承诺和赔偿标准以及相关细则。

• SLA是在统计周期前提供的承诺，SLA是否达标是在统计周期结束时才进行计算出实际数据。

• SLA趋近100%，成本则会趋近无限大。

文本将对以下内容进行展开描述：

• 如何计算SLA？

• SLA几个九怎么制定？

• 如何提升SLA？

• SLA协议编写注意事项

• SLA协议完整模板

如何计算SLA？

在进行SLA制定与计算时，统计计算周期可以为一周、一个月、三个月、六个月、一年等都可以，但是需要提前协商约定好，并写入SLA合同中。

服务可用性的计算公式为

可得，合同约定的可宕机时间公式：

等保云服务器

以一年为周期进行计算99.9%的年度可宕机时间（由于每年天数不同所以365为近似值）：

总时间（1年）： 365天 × 24小时 × 60分钟 × 60秒 = 31536000 秒

允许的宕机的最长时间：

(1-99.9%)x31536000=0.001×31536000秒=31536.000秒=525.6分钟=8.76小时

基于该计算方法，可以计算出不同九级别的允许宕机时间

服务级别年可用性年宕机时间适用场景基础级99%3.65天内部工具、非核心后台任务、开发测试环境标准级99.9%8.76小时绝大多数对外商业服务、企业应用、网站前台良好级99.95%4.38小时重要的API服务、关键业务功能高级99.99%52.6分钟核心交易系统、支付网关、大型云厂商基础服务极高可用99.999%5.26分钟电信网络、金融核心交换系统、生命攸关系统

从这个表可以直观地看出，从99.9%到99.99%，虽然支持多了1个9，但是允许的年宕机时间从8.76小时锐减到52.6分钟 ，这对系统的架构、运维、故障响应能力提出了极高的要求。

SLA 几个九怎么制定？

SLA制定更高的几个九有优点，但缺点也同样明显：

优点：更少的业务中断损失、更好的用户体验、更强的客户信任。缺点：极高的技术复杂性、更重的运维负担、指数级增长的成本。

作为领导者/决策者要明白制定SLA的几个九不是一个简单的数学问题，而是一个平衡业务需求、技术能力和成本的决策过程。

这里从业务维度、技术维度、成本维度进行三维评估：

业务维度

业务评估核心是评估：这个服务不可用或变慢，会有什么后果？

评估项1: 直接影响营收吗？

对于一些特别核心的业务系统，如交易系统、支付系统、订单系统，这些服务是影响收入核心的服务。

每分钟宕机都意味着直接的金钱损失。这类服务需要高SLA（例如 99.95%）。

评估项2: 间接影响营收吗？

该服务是否影响用户体验？是否影响用户信任？是否影响用户流失？等可能间接导致收益损失。如企业门户、社区系统、媒体信息服务。

虽然用户不能直接付费，但宕机会导致用户流失，间接影响营收。通常需要较高的SLA（例如 99.9%）。

评估项3: 长期异常影响营收吗？

该服务短时间中断不会立即影响核心用户体验，甚至对用户无感。例如报表系统、数据分析系统、推荐系统等。

但是当时间长度拉长，可能会给系统带来一些不稳定的风险，进而影响系统的稳定性。

这些系统虽然对内部可能造成一定困扰，但对用户影响极小，可以接受较低的SLA（例如 99%）。

技术维度

以业务维度评估只能说明业务核心重要程度，但是最终是否能够提供对应的 SLA 还需要结合实际的技术因素。

每个9的提升，对整体的技术的复杂性也会有更高的要求，技术维度主要评估依赖的硬件、依赖的软件、系统质量、人才储备，以及流程规范这几个维度：

依赖的硬件

对于业务系统运行依赖服务器、网络设备、机房、城市、国家主权等，任何一个环节薄弱都会导致基础硬件无法按照预期提供服务，进而影响业务的稳定性。

假设硬件设备提供的稳定性（不故障的概率）如下

设备稳定性服务器99.9%网络设备99.99%机房99.999%城市99.999999999%国家99.999999999...%

那么依赖的硬件的稳定性为约等于 99.889011%= 99.9% x 99.99% x 99.999% x 99.999999999% x 99.999999999...%

依赖的软件

业务系统依赖的软件是指该系统在运行时涉及到相关会影响稳定性的软件服务，如数据库、缓存、消息队列、中间件、网关、负载均衡等等。任何一个依赖服务出现异常，都可能使业务系统产生故障，从而影响业务正常提供服务。

假设软件服务提供的稳定性（不故障的概率）如下

服务稳定性缓存99.5%消息队列99.9%中间件99.95%数据库99.99%网关99.995%负载均衡99.999%

那么该业务系统依赖的软件可用性为约等于 99.334904%= 99.5% x 99.9% x 99.95% x 99.99% x 99.995% x 99.999%

系统质量

业务系统软件自身的质量是稳定性的根基。一个设计粗糙、代码糟糕的软件，无论运维多么强大、基础设施多么稳固，都如同在沙地上建高楼，随时可能崩塌。

没有100%没有Bug的软件系统，企业在评估时可以结合实际的研发经验和人才储备进行评估。

人才储备

技术人才是高SLA保障的基础。上述的几个场景中想要实际落地，就需要有相应的技术人才来进行建设和维护保障。

专业的人才聚焦具体的领域，领域越多需要的人才种类就越多，进而需要储备的人才也就越多。

流程规范

良好的流程和规范可以让人才更好的发挥价值。

软件生命周期过程规范。如代码编写规范、软件发布规范、变更升级规范等。

知识沉淀与传承的流程。如最佳实践的沉淀、人才的培训机制。

SLA可用性估算

这里以极端完美业务系统100%不会出现、拥有全球最顶尖最完善的人才队伍，以及最合理的流程制度为例，该业务系统在单台服务器上运行时对外承诺 SLA 时不应该超过

SLA最大 < 99.22%= 100%（业务自身）x 100%（全球顶尖人才）100%（完美的流程制度）x 99.889011%（硬件依赖）x 99.334904%（软件依赖）

这里的案例中可以看到即使业务、人才、流程都完美，由于依赖的软/硬件限制，最大的 SLA 可用性为 99.22%。业务方在对外承诺 SLA 时，如果可用性大于该值，则会承担极大的风险。

当然，如果有彩票的运气，也可能一年过去了，一次故障也没有发生，那过去一年的SLA为100%。明年还有这么好的运气吗？这是一个概率学问题。

成本维度

越高的 SLA 的成本会更高。成本的主要来源是技术维度中的几种场景带来的

依赖的硬件中想要提升他们的可靠性，需要进行一些保障性建设，这会增加硬件成本。

云服务器挂载光盘

依赖的软件中他们本身也是一个个的系统，有同样的 SLA 考量，这是一个新的评估循环。

系统质量软件系统自身的安全、性能、BUG、架构、容灾等等，每个维度都提升，那就需要更多的研发、测试、运维等人力的投入，即成本的投入。

人才储备高质量的人才往往需要较高的成本才能吸引并持续的合作下去。

流程规范繁多复杂的流程实践则需要更多的人力投入。

综合平衡

经过业务维度、技术维度和成本维度的评估后，可以得出一个结论：100% SLA可用性的成本是无穷大的。

企业应该根据实际需求情况来进行评估，最好能有历史的数据作为参考，然后在结合这里的3个维度的评估结果，进行综合评估。

若确实没有任何有用信息可参考，那就参考行业最佳实践，即如何计算SLA？中《不同九级别的允许宕机时间》表格。

如何提升SLA

在SLA几个九怎么制定？中技术维度已基本涉及影响SLA可用性的因素

依赖的硬件中想要提升他们的可靠性，需要进行一些保障性建设，如

依赖服务器：采购高质量的服务，建设多副本高可用的集群。网络设备：购买高质量网络设备，建设冗余高可用的网络环境。机房质量：机房冗余，同城双活，电力冗余，空调冗余，水火自然灾害防护，人力安全等。城市安全：异地容灾，单元化建设。国家主权：跨国备份。

依赖的软件提升他们的稳定性主要有2个方向：

自建依赖软件服务：依赖的软件自身也是一个系统，同样有各自的SLA，可以作为一个独立的业务系统进行新一轮的评估。采用公有云厂商的云服务：对于一个通用的软件，除了特殊情况外，一般可以理解公有云厂商能够提供的稳定性是最高的。

系统质量软件的质量问题是一个系统工程，它贯穿于设计、开发、测试、部署、运维的整个生命周期。

在架构层面：需要设计解耦的、可扩展的、有弹性的业务系统架构。在代码实现层面：需要编写高效的、健壮的、易于维护的代码。在数据处理层面：需要处理数据的一致性、准确性、安全性等。在运维层面：需要透明、可监控、可诊断的运维观测数据。

人才储备技术人才是高SLA保障的执行主体。需要建立一支具备不同专业技能、并能协同作战的团队。

建立专业且分工明确的人才团队，如架构师团队、测试团队、SRE团队、数据团队、业务团队等等。

推行人才能力持续赋能机制，如系统性的培训、实战演练，以及技术文化建设等等。

流程规范良好的流程规范是将个人能力转化为组织能力、确保各项措施可重复、可持续执行的关键。

研发质量保障流程，建立代码规范与审查流程，设计评审流程流程；发布与变更管控流程，建立变更管理流程，渐进式发布流程；运维与应急响应流程，标准化的应急响应流程，On-Call与告警升级机制；闭环改进流程，强制性的故障复盘制度。

SLA协议编写注意事项

高质量的SLA能够减少沟通成本，体现服务方的信誉与专业性。

1、目标一定是在综合平衡评估后的基础之上制定的，目标不切实际的SLA就是废纸。

2、专业名词描述准确无歧义，一些名词或者缩写可能会导致不同的人理解上的差异，建议对于专有名词添加解释说明。

3、明确SLA判断标准。如什么情况下开始和结束故障时长统计，这里建议添加明确的技术指标。如用户中心系统约定用户在无法正常登录退出时判定为故障，那么后台的统计功能、邮件通知、定时任务等服务即使没有恢复也不算故障时长。

4、明确赔偿标准。在 SLA 承诺的故障时长一般不进行赔偿，超过部分需要进行赔偿时明确赔偿细则。有些产品赔偿金额可能是厂商提供服务百分比，也可能是固定额度，具体根据合同约定。

SLA协议模板

注: 该协议模板参考阿里云文档，引用时间2025年11月17日，引用链接[1]

云服务器ECS服务等级协议

版本生效日期：2019年12月1日

本服务等级协议（Service Level Agreement，简称 SLA）规定了阿里云向客户提供的云服务器 ECS（简称ECS）的服务可用性等级指标及赔偿方案。特别提示您，除非另有约定，本协议不适用于ECS公测、邀测的规格族。

1. 定义

服务周期：一个服务周期为一个自然月。单实例服务周期总分钟数：按照单实例服务周期内的总天数╳24（小时）╳60（分钟）计算。实例不可用：当一台设置了出入允许规则的ECS实例以TCP或者UDP协议与任一IP地址的双向（出/入）都无法联通，且该状态持续一分钟以上，视为该分钟内ECS实例不可用。单实例服务不可用分钟数： 在一个服务周期内单ECS实例不可用分钟数之和。单地域多可用区服务不可用：如用户ECS实例在同一地域部署于至少2个可用区（以下简称：单地域多可用区），若该地域任一可用区发生该用户的全部 ECS 实例不可用，且该用户在该地域其他可用区的ECS实例亦同时发生实例不可用（以下简称：同地域其他可用区不可用ECS实例），则此同地域其他可用区不可用ECS实例被视为单地域多可用区服务不可用。单实例单地域多可用区服务不可用分钟数：在一个服务周期内，单ECS实例的单地域多可用区服务不可用的分钟数之和。月度服务费：为客户在一个服务周期（即自然月）中就单ECS实例所支付的服务费用总额，如客户一次性支付多个月份的服务费，则将按照所购买的月数分摊计算月度服务费。

2. 服务可用性

2.1 服务可用性计算方式

ECS的服务可用性将根据服务周期，按如下两种维度分别统计每台ECS实例的可用性：

（1）单实例维度：

服务可用性=（单实例服务周期总分钟数 - 单实例服务不可用分钟数）/单实例服务周期总分钟数×100%

（2）单地域多可用区维度：

服务可用性=（单实例服务周期总分钟数 - 单实例单地域多可用区服务不可用分钟数）/单实例服务周期总分钟数×100%

2.2 服务可用性承诺

（1）对于单实例维度， 阿里云承诺一个服务周期内ECS的服务可用性不低于99.975%；

（2）对于单地域多可用区维度，阿里云承诺一个服务周期内ECS的服务可用性不低于99.995%。

2.3 如ECS未达到上述可用性承诺，客户可以根据本协议第3条约定获得赔偿。赔偿范围不包括以下原因所导致的服务不可用：

（1）任何阿里云所属设备以外的网络、设备故障或配置调整引起的；

（2）客户的应用程序受到黑客攻击而引起的；

（3）客户维护不当或保密不当致使数据、口令、密码等丢失或泄漏所引起的；

（4）客户的疏忽或由客户授权的操作所引起的；

（5）客户未遵循阿里云产品使用文档或使用建议引起的，如客户在控制台、API或者CLI等控制方式对ECS实例进行停机、重启、卸载云盘等操作引起的不可用；

（6）本地盘实例使用的本地存储有数据丢失风险（如本地磁盘相关设备损坏、实例宕机等），依赖本地盘数据而导致的不可用；

（7）由于客户所安装软件或者其他非阿里云直接运营的第三方软件或者配置引起的ECS实例出现错误；

（8）由于客户违反《云服务器（ECS）服务条款》导致的服务被暂停或终止，包括但竞价实例因为客户的出价低于交割价格而被释放；由于欠费导致ECS实例被暂停服务或被释放等；

（9）《云服务器服务（ECS）服务条款》中所描述的阿里云对ECS正常维护、升级所引起的短时服务中断；

（10）不可抗力引起的。

3. 赔偿方案

3.1赔偿标准

（1）对于单ECS实例，如服务可用性低于99.975%，可按照下表中的标准获得赔偿，赔偿方式仅限于用于购买ECS产品的代金券，且赔偿总额不超过未达到服务可用性承诺当月客户就该ECS实例支付的单实例月度服务费（不含用代金券抵扣的费用）。

服务可用性赔偿代金券金额低于99.975%但等于或高于99%月度服务费的10%低于99%但等于或高于95%月度服务费的25%低于95%月度服务费的100%

（2）对于以单地域多可用区部署的ECS，如服务可用性低于99.995%，可按照下表中的标准获得赔偿，赔偿方式仅限于用于购买ECS产品的代金券，且赔偿总额不超过未达到服务可用性承诺当月，用户就该ECS实例支付的月度服务费（不含用代金券抵扣的费用）。

服务可用性赔偿代金券金额低于99.995%但等于或高于99%月度服务费的10%低于99%但等于或高于95%月度服务费的25%低于95%月度服务费的100%

（3）如某ECS 实例同时满足3.1（1）和（2）的赔偿标准，则以其中赔偿额较高者为准计算赔偿金额。

3.2赔偿申请时限

客户可以在每月第五（5）个工作日后对上个月没有达到可用性的ECS实例提出赔偿申请。赔偿申请必须限于在ECS没有达到服务可用性的相关月份结束后两（2）个月内提出。超出申请时限的赔偿申请将不被受理。

4.其他

本云服务器服务等级协议自2019年12月1日生效，阿里云有权对本SLA条款作出修改。如本SLA条款有任何修改，阿里云将提前30天以网站公示或发送邮件的方式通知您。如您不同意阿里云对SLA所做的修改，您有权停止使用ECS服务，如您继续使用ECS服务，则视为您接受修改后的SLA。

引用链接

[1] 引用链接: https://terms.aliyun.com/legal-agreement/terms/suit_bu1_ali_cloud/suit_bu1_ali_cloud201909241949_62160.html

腾讯云服务器免流教程