99.9%的保证uptime仍然允许每年约有8.76小时的停机时间，而99.99%只允许52.56分钟。这个承诺只有当您知道测量窗口、停机公式和排除项时才会有意义，因为头条百分比本身并不能告诉您用户将会经历什么。
通常情况下，您是在这种情况下才会看这个东西：某个实时更新没有发布，支持团队开始从每个地区收到相同的抱怨，团队中的某个人会问一下供应商的SLA是否会涵盖停机时间，还是只是在幻灯片中看起来很好。
目录
- 为什么实时更新平台的可用性保证很重要
- 了解可用性等级背后的可用性数学
- 细读服务水平协议（SLA）中的关键组成部分
- 实时更新平台的可实际可用性目标
- 监控和可观察性最佳实践
- Capgo的架构如何支持高可用
为什么可用性保证对于实时更新平台至关重要
周五下午进行安全修复是最糟糕的时间发现更新路径不可用。应用程序仍在用户手中，问题仍然活跃，需要补丁最多的人无法接收它。这就是为什么可用性保证 是实时更新平台的移动团队运营的 一个紧张的IT专业人员在他的笔记本电脑屏幕上面对数据库连接错误时头痛
实践规则：
如果用户需要更新以保持安全、合规或功能正常，那么您的更新通道就是关键路径 __CAPGO_KEEP_0__
这就是为什么这个问题如此重要的原因：一个实时更新平台位于您的发布和用户之间。如果这个桥梁失败，您不仅会失去方便之处，还会失去关闭事件循环的能力。尤其是当一个商店评论延迟已经会拖慢您时，因为实时更新的目的就是减少延迟，而不是用另一个瓶颈来取代它。故障排除手册只有在交付路径保持可达时才有效，这就是为什么团队应该将平台可用性与事件恢复计划联系起来，例如《事件响应指南》。 强大的服务水平协议（SLA）应该回答一个简单的运营问题：平台是否能在您的团队需要它时提供修复，还是在发生故障时承诺的保证会消失？这个区别决定了保证是否支持您的应用程序，还是仅仅装饰了合同。.
了解可用性等级背后的可用性数学
‘九’模型很重要，因为它将模糊的可靠性声明转换为具体的停机时间预算。
99.9%的可用性 允许约 8.76小时 每年允许 约 99.99% 52.56分钟 ,仅允许 99.999% 限制停机时间约为 5.26 分钟 每年，月度预算约为 43.8 分钟, 4.38 分钟4.38 分钟 26 秒 （可用性保证计算）
一个额外的 9 变更了运营模式，而不是仅仅是营销文案。
差异不是线性的 43.8 分钟 99.9% 左右 4.38 分钟 99.99%。这意味着承受的停机时间大约减少了十倍，通常比更好的主机需要更长时间。它需要冗余、更快的检测和在系统已经处于压力状态时仍然有效的故障转移。
同样的模式在数据中心等级benchmark中也出现了。 等级I 与 99.671% 可用性相关，或者大约 28.8 小时 每年停机时间 等级II 与 99.741% 和关于 22 小时, 第三级 与 99.982% 大致 1.6 小时, 和 第四级 与 99.995%, 这仅仅是关于 26.3 分钟 每年 (数据中心等级benchmark从Tier III到Tier IV的跳跃，是一种将停机时间从小时转化为分钟的重大转变。
| 可用性百分比 | 每月停机时间 | 每年停机时间 | 等级水平 |
|---|---|---|---|
| 99.9% | 43.8分钟 | 8.76小时 | 常见基准 |
| 99.99% | 4.38分钟 | 52.56分钟 | 更高的可用性 |
| 99.995% | 26 秒 | 5.26 分钟 | 极端可用性 |
对于实时更新平台来说，这个数学计算很重要，因为发布窗口通常很短且紧迫。服务如果错过了发布窗口10分钟，就可能错过用户需要修复的时刻。团队应该将这些数字与发布健康状况联系起来，使用同样的纪律来监控应用程序健康状况。 阅读细则：SLA的实际重要组成部分.
两个提供商可以发布相同的可用性百分比，但在生产环境中却产生了非常不同的结果。合同才是承诺的来源，而不是主页。为了让一个
可用性保证 具有实际意义，需要三个部分齐头并进：测量窗口、停机公式和排除项。 首先是测量窗口
服务可以在纸上看起来很可靠，如果提供商选择了一个可以掩盖波动期的窗口。一个SLA的例子是在
年平均停机时间 按90天滚动周期 并使用独立的合成监控来评估可用性，这比模糊的营销承诺要准确得多（SLA示例和测量规则如果提供商不说明如何衡量指标，百分比难以信任。
时间窗口很重要，因为停机时间可以按月报告、按月计费或平均到更长的周期。如果您的更新服务在一个月末失败，下一个月初恢复，报告模型可能会改变该事件在SLA中的显示方式。您希望合同去除这种游戏数字的空间。
然后检查什么算作停机时间
可用性数字只有当其停机时间公式是诚实的时才有效。一个被引用SLA将可用性定义为可访问的分钟数除以月份总分钟数，并仅将影响大量请求或核心功能的停机时间计算为服务停机时间（SLA公式示例这种定义避免了将每次微小的暂时性故障计算为全面的停机时间，但这也意味着您需要在签署之前了解什么是“显著”的。
最昂贵的SLA错误是假设提供商的停机时间概念与您的概念相同。
排除可以抹去承诺
预定维护、客户端故障、不可抗力和一些第三方停机时间通常在现实中的合同中被排除（SLA 示例和测量规则SLA 的具体性而非糟糕性。问题在于团队购买 SLA 的数字而不理解被计算的内容，然后在发生他们关心的确切类型的停机时发现保证不适用。
SLA 也应该配对可用性与 MTTR、延迟阈值、丢包率限制或其他运营承诺，因为可用性单独无法描述恢复行为（SLA 指南如果合同没有解释恢复如何被测量，你并不是在购买可靠性。你是在购买标签。
对于移动发布系统，细则也应该反映在故障时的架构行为。具有多区域部署的提供商可能具有非常不同的停机配置文件，而依赖于单个主路径的提供商，因此 SLA 应该与设计保持一致，而不是仅仅是销售页面。见 Capgo 的多区域部署方法 为实践中是否能成立的可用性声明提供了操作细节的类型。
实用性目标
对于实时更新平台，正确的目标取决于您如何频繁发布关键修复以及用户能容忍的中断程度。 三九 对于低风险工作流程可能是可接受的，但是在更新是紧急响应、客户信任或受监管操作时，它会迅速变得不舒服。修复越紧急，平台越不能容忍。
Three nines is often the wrong default
99.9% 和 99.99% 之间的差距，是一个能承受偶尔中断的平台和一个需要刻意增强韧性的平台之间的差异。这种差异在月度停机预算上是明显的，约为 43 分钟 versus 4 分钟 (可用性等级计算如果您的发布流程依赖于狭窄的时间窗口，那么较低的等级可能会过于笨拙。
当事故已经发生时，这种情况尤其如此。仅允许几分钟停机的交付平台仍然可能错过回滚、热修复或配置更改的准确时刻。在这种情况下，SLA 应该反映您的运营耐受度，而不是供应商的最便宜支持等级。
寻找超出头条的承诺
最近的 SLA 草案趋势倾向于滚动窗口、月度月度报告、比例服务积分和责任上限，这表明买家正在要求更具操作性具体的保证（SLA 趋势评论]
严重的合同也为您提供了失败后的路径。信用额度不能恢复破裂的发布，但它可以揭示供应商是否愿意将补偿与可测量的服务行为联系起来。 在企业级别，这通常是区分支持事件的平台和成为事件的一部分的平台的差异。
对于正在评估此决策的团队来说，多区域发布是设计要求，而不是好处。原因很简单，系统越接近冗余设计，局部故障的影响就越小，这与多区域部署背后的逻辑相同。 多区域部署.
决策测试： 如果紧急发布期间的停机将迫使手动工作周转，您的可用性目标可能太低。
监控和可观察性最佳实践
一个 可用性保证 只有当您可以从外部验证它时，才会有所意义。 供应商仪表板有帮助，但您自己的监控需要回答一个更困难的问题：用户是否可以接收更新，发布尝试是否可以完成，恢复是否可以继续前进而不会卡在路径的中间？ 最强大的监控设置显示服务可用性和客户影响一起，因此事件在变成支持问题之前就可以在事件中看到。
从外部验证，而不是仅仅在您的网络内部验证
模拟监控为您提供了一个用户侧的视图，内部健康检查无法提供的视图。内部检查可以确认自己的系统是活跃的，但它不能证明更新路径是从真实设备可达的。这个差距很重要，因为提供商可以报告健康的服务状态，而交付路径在客户端却失败了。
跟踪每个设备的日志、版本历史、采用率和失败指标，以便您可以确定是否仅发布了更新还是接收了更新。通道的保护措施也很重要，尤其是在推送到beta、staging、生产或客户专属流程时。这些控制措施可以更容易地停止一个坏的发布，防止它在预期的组之外传播。
衡量恢复，而不是仅仅衡量失败。
可用性数字掩盖了太多的信息。一个快速恢复的提供商，即使其原始可用性百分比与一个较慢的提供商类似，也可以限制业务影响。因此，MTTR应该与可用性一起在您的仪表板上显示，因为检测速度和修复速度往往比一个精致的百分比更重要。
实践规则： 如果您的监控仅告诉您服务是可用的，那么这对于发布操作来说是不够的。
一个干净的告警设置应该在用户涌入支持之前触发，而不是在之后。要监控交付失败、滞留的发布和采用率的异常下降，而不是仅仅监控全面的服务故障。对于那些想要更紧密的运营模型的团队来说， 应用可观察性 通常比一个通用的可用性徽章更有用。
如何Capgo的架构支持高可用性
架构决定了是否可实现高可用性承诺。Capgo的交付模型使用全球边缘网络，覆盖300+个城市 减少对单个区域的依赖，帮助更新流量更接近用户。其差异更新只发送更改的文件，因此发布移动的数据量比完整包少，自动回滚保护还给团队提供了更安全的恢复方式，避免发布时出现问题实践的好处是操作性的，而不是外观性的。签名的Web包允许团队在不等待商店审查延迟的情况下发布JavaScript、CSS、复制、配置和资产修复，这正是许多故障响应时间浪费的地方。类型化的TypeScript API和CI/CD集成还减少了通常会拖慢发布工作的摩擦
还有监控方面的好处。__CAPGO_KEEP_0__的每设备日志、采用率指标、故障跟踪、版本历史和通道护栏为支持和工程提供了必要的证据，来看是否发布正在工作或卡住。这种可见性可以将模糊的‘更新是否发布了’的问题转化为可以采取行动的东西
恢复的故事也很重要。Capgo的
灾难恢复指南 __CAPGO_KEEP_0__ 与架构本身一起配对是有价值的，因为高可用性只有在部署出错时才有用。下面的视频展示了平台的上下文，并有助于将交付路径连接到它周围的运营控制。
如果您正在谈判SLA，请将供应商的承诺与实际交付路径、恢复工具和您在事件发生时的可见性进行比较。Capgo是为需要实时更新、回滚控制和发布可观察性在一个系统中的团队提供的一种选择，您可以在Capgo中查看产品详细信息。 Capgo 查看是否符合您的更新和事件响应工作流。
如果您的团队实时更新，不要仅仅因为在幻灯片中听起来不错而接受百分比。查看SLA，测试监控，并选择可以在用户需要时携带热修复的交付架构。
