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