可用性

概述 你公司用了某云厂商的服务，SLA 白纸黑字写着 99.95% 月度可用性。某天凌晨服务挂了 30 分钟，你跑去找云厂商索赔，拿回来的赔偿大概是这么算的：故障时间占月度总分钟数的比例，乘以你当月的服务费。假设你月付 1000 块，30 分钟除以 43200 分钟再乘 1000，赔你 0.7 元。 没看错，七毛钱。你线上炸了半小时，客服电话被打爆，用户退款申请堆了一屏，云厂商赔你七毛。 这不是段子，这是 2025 年某 CSDN 技术博客拆解云厂商 SLA 时用的真实计算逻辑。当然，实际云厂商的赔偿用的是阶梯制（后面会讲），但核心问题不变：SLA 的数字看着唬人，赔偿条款却藏着大量排除项和窄化定义，到了真出事的时候，赔的那点钱远远覆盖不了你的业务损失。 这篇文章不聊怎么"读懂"SLA——那种文章网上一搜一大把。我要聊的是：作为 SRE，你怎么设计自己服务的 SLA，怎么避免云厂商 SLA 的坑，怎么把一个合同条款变成可执行的工程约束。 SLA、SLO、SLI：别再混为一谈 很多团队把这三个词当同义词用。开会时"我们的 SLA 是 99.9%"，实际上说的是 SLO。这三个东西的区别不是文字游戏，搞混了会出真问题。 先上一张对比表，后面逐个展开： 维度 SLI（指标） SLO（目标） SLA（协议） 是什么 对服务质量的量化测量值 基于 SLI 设定的内部目标值 对外承诺的合同条款 面向谁 工程团队 工程团队 + 产品 客户 / 业务方 违约后果 无 冻结发布、投入稳定性修复 赔偿、合同违约 严格程度 客观事实，无严格/宽松之分 必须严于 SLA 比 SLO 宽松，留缓冲 典型例子 P99 延迟 = 120ms P99 延迟 < 200ms，成功率 > 99....

概述 99.5% 的可用性听起来不错——直到你算一笔账。 一年 8760 小时，99.5% 意味着允许停机 43.8 小时。换算到每个月，差不多 3.65 小时的服务中断。如果是核心交易系统，这 3.65 小时可能就是几十万的订单损失。如果赶在大促期间，损失会翻几十倍。 99.9% 呢？年停机 8.77 小时，月均不到 44 分钟。停机时间砍掉 80%。 0.4 个百分点的提升，背后不是加几台服务器那么简单。我在某出行平台推动过一次这样的改造，从立项到稳定运行在 99.9% 以上，花了整整 14 个月。这期间踩的坑、做的权衡、推翻重来的方案，比写代码本身多得多。 这篇文章不讲理论框架，只拆解我们做过的 6 个关键工程决策，以及 3 个让我后背发凉的踩坑时刻。每个决策都附上我们当时的选型对比和最终方案，你拿去就能对照自己的系统查漏补缺。 可用性的数学本质：为什么 0.4% 这么难 先搞清楚一件事：可用性不是加法，是乘法。 假设你的系统由 3 个服务串联组成，每个服务可用性 99.5%。整个链路的可用性是多少？ 0.995 × 0.995 × 0.995 = 0.9851 ≈ 98.51% 三个"还不错"的服务串联起来，整体可用性直接跌破 99%。年停机从单服务的 43.8 小时暴涨到 128 小时——超过 5 天。 反过来想：如果链路有 10 个服务，每个要达到整体 99.9% 的可用性，单个服务的可用性得是多少？ 0.999^(1/10) ≈ 0.99990 → 99.99% 十个服务每个都得做到四个九。这就是为什么微服务架构下可用性提升的难度呈指数级增长。 关键认知：提升可用性不是给单个服务加机器，而是同时做三件事——减少串联依赖数量、提高单个服务可用性、在关键路径上做冗余和降级。 Google SRE 团队在 The Calculus of Service Availability 中提到一个观点：大多数服务的内部目标应该定在 99....

概述 传统的监控方式是"被动式"的——等待用户访问触发系统行为，然后采集指标和日志。这种方式有一个根本缺陷：当监控发现问题时，用户已经受到影响。如果你的首页加载了 10 秒，你的监控告警可能在 5 分钟后才触发，而此时已有上千用户体验了糟糕的性能。 合成监控（Synthetic Monitoring）是"主动式"的监控方式——它通过模拟真实用户行为，定期访问关键路径，在用户感知到问题之前就发现并修复。就像一名"虚拟用户"24 小时不间断地测试你的系统，任何异常都能在第一时间被捕获。详细梳理合成监控的原理、实践和工具选型。 参考来源：Grafana Synthetic Monitoring 文档、Datadog Synthetics 文档 一、合成监控原理 1.1 什么是合成监控 合成监控通过预定义的脚本或配置，模拟用户行为（打开页面、点击按钮、提交表单、调用 API），定期执行并记录结果： ┌──────────────────────────────────────────────────────┐ │ 合成监控工作流程 │ │ │ │ ┌──────────────┐ │ │ │ 探测节点集群 │ ← 全球分布的探测节点 │ │ │ (Beijing/ │ │ │ │ Shanghai/ │ │ │ │ Overseas) │ │ │ └──────┬───────┘ │ │ │ │ │ │ 定时执行探测脚本 │ │ ▼ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ 模拟用户行为 │ ──→ │ 目标系统 │ │ │ │ • 打开页面 │ │ (Web/API) │ │ │ │ • 点击按钮 │ └──────┬───────┘ │ │ │ • 填写表单 │ │ │ │ │ • 调用 API │ │ │ │ └──────┬───────┘ │ │ │ │ │ │ │ ▼ │ │ │ ┌──────────────┐ │ │ │ │ 记录结果 │ ←─────────┘ │ │ │ • 状态码 │ │ │ │ • 响应时间 │ │ │ │ • 页面内容 │ │ │ │ • 截图 │ │ │ │ • Trace │ │ │ └──────┬───────┘ │ │ │ │ │ ▼ │ │ ┌──────────────┐ │ │ │ 告警 + 仪表盘│ │ │ └──────────────┘ │ └──────────────────────────────────────────────────────┘ 1....