从99.999999999%到可执行架构：高可用与混沌演练实践

在内部代号为 4nim0sity 的极限可用性演练里目标被写成 99.999999999%。这个数字看起来像玩笑但拆开之后它对应一串非常具体的工程动作。演练结束那天团队群里出现“宰鱼了”三个字意思不是真正的宰鱼而是所有注入的故障都在预期时间内被处理掉了。如果你正在做高可用架构、混沌演练或 SLO 体系这篇文章会把 99.999999999% 从口号翻译成可执行的技术方案。下面从可用性数学开始逐步讲到如何拆解目标、搭建架构、注入故障、验证数字以及最后如何用一份清单防止演练流于形式。1. 99.999999999% 到底意味着什么1.1 从 99% 到 99.999999999% 的故障时间换算可用性最常被误解的地方是认为“可用性越高系统越不容易出问题”。严格来说可用性是一个时间窗口内的统计结果它描述的是在观测周期内系统满足服务要求的时间占比。公式很简单可用性 正常运行时间 / 总时间如果按一年 365 天计算一年大约有 31536000 秒。不同可用性目标对应的年停机时间差距非常大直接用秒换算更容易建立直觉。可用性年停机时间典型场景99%约 87.6 小时开发环境、内部工具、非关键系统99.9%约 8.76 小时一般 Web 应用、早期业务系统99.99%约 52.56 分钟核心在线业务、交易系统99.999%约 5.26 分钟金融支付、实时通信99.999999%约 0.315 秒基础设施、云服务控制面99.999999999%约 0.00031536 秒即 0.315 毫秒极高可靠性场景0.315 毫秒是什么概念呢一次内存访问大约几十纳秒一次普通网络请求的延迟都在毫秒级别。也就是说99.999999999% 意味着系统在一年内允许的不可用时间比一次正常的 HTTP 请求还要短很多。这个数字放在绝大多数业务里是不现实的它更适合卫星通信、工业控制、高频交易基础设施这类对时间窗口有严格要求的场景。这不是为了劝退而是要先建立判断99.999999999% 不是“努力一下就能达到”的指标它是需要从架构、运维、统计口径三者同时配合才可能接近的目标。1.2 可用性不是单次结果而是长时间窗口的统计行为很多人把可用性等同于“服务没宕机”。实际上一次发布会期间的可用性和一个季度统计的可用性含义完全不同。短时间窗口内即使系统发生过故障如果故障发生在白天流量高峰可能影响 10 分钟如果发生在凌晨低峰影响几乎为零。可用性指标必须绑定观测窗口否则所有讨论都没有意义。常见窗口有当月可用性适合月度复盘。滚动 30 天可用性适合持续监控。滚动 7 天可用性适合告警触发。实时错误预算消耗适合值班响应。在 4nim0sity 演练中我们用的是滚动 7 天窗口加实时错误预算消耗。原因是如果只看月度汇总故障发生到发现之间往往隔着几个小时等复盘出来影响已经产生了。1.3 为什么 11 个 9 在大多数业务里是伪需求关于 99.999999999%最容易踩的坑不是做不到而是根本不该设置这么高的目标。从成本角度看可用性从 99.9% 提升到 99.99%可能需要引入多副本、故障转移、自动扩容从 99.99% 提升到 99.999%大概率要改造数据同步、跨机房容灾和变更发布流程从 99.999% 继续往上提升投入会产生明显的非线性增长。更重要的是统计问题。如果你一天只有 10 万次请求一周大约 70 万次那么 99.999999999% 这个精度已经接近统计噪声。请求样本不够任何数字都是估算不具备可验证性。因此在真实工程里99.999999999% 通常不是应用于“单个用户可见业务”而是应用于服务之间的底层调用、基础设施的某个独立环节或者是整体链路经过冗余设计后的理论结果。普通业务更合理的路径是先把 99.9% 或 99.99% 做稳再做下一步提升。注意不要把高可用目标直接写成一个团队 KPI然后让大家加班“保证”。目标必须落到可观测指标、错误预算和故障演练计划里。2. 目标拆解从 99.999999999% 变成可执行架构2.1 端到端可用性是乘积关系不是平均值用户访问一个系统通常经过 DNS 解析、CDN、负载均衡、网关、业务服务、数据库、消息队列等多个环节。任何一环失败用户都可能感知到故障。假设链路由 3 个独立组件串联每个组件的可用性都是 99.999%那么整体可用性近似为R R1 * R2 * R3 0.99999 * 0.99999 * 0.99999 ≈ 0.9999700001也就是大约 99.997%。看起来每个组件都很高但串联之后已经比单点 99.999% 低了两个数量级。这还是理想情况没有计算网络抖动、配置变更、依赖超时和数据不一致。如果目标是 99.999999999%在串行链路上几乎不可能通过“让每个环节都很高”来实现。更可行的做法是引入并联冗余两个独立副本并联可用性 1 - (1 - R1) * (1 - R2)假设每个副本可用性为 99.9%并联后理论可用性约为1 - (1 - 0.999) * (1 - 0.999) 0.999999也就是 99.9999%。但这里有一个前提两个副本必须真的独立包括进程独立、机器独立、可用区独立甚至数据依赖独立。如果两个副本共用同一个数据库数据库反而成了单点。所以在 4nim0sity 演练里我们第一步不是写代码而是画出完整依赖图把每个依赖标记为串联或并联再用公式计算整体理论可用性。这个动作能快速发现哪些组件不能达到目标。2.2 用可用性预算反推每个依赖的目标可用性预算的目标是让“整体 99.999999999%”变成一个可以分配的指标。假设系统的主要环节拆分如下依赖层级目标可用性关键策略DNS99.999999%多域名、缓存、健康检查CDN99.999%静态资源降级API 网关99.99999%多副本、限流、熔断业务服务99.99999%无状态化、多可用区部署数据库99.9999%主从切换、跨可用区消息队列99.999%集群模式、重试这些数字相乘已经接近 99.99998% 左右依然达不到 11 个 9。要进一步提高必须依赖更多冗余和降级策略而不是把单个服务的可用性数字继续调大。分配预算时有几条经验给基础设施设置略低但容易验证的目标例如 DNS 可用性 99.999%。给核心业务服务设置较高目标但必须配合自动故障转移。给数据层单独做一致性验证因为数据库故障导致的可用性损失通常是分钟级。给外部依赖预留降级方案不能把黑盒依赖当成铁板一块。2.3 一个最小多可用区部署示例为了让目标落地以一个 order-service 为例展示最基本的 Kubernetes 部署形态。下面 YAML 用于说明思路实际项目要结合自己的命名空间、镜像版本和探针路径调整。apiVersion: apps/v1 kind: Deployment metadata: name: order-service namespace: demo spec: replicas: 3 selector: matchLabels: app: order-service template: metadata: labels: app: order-service spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app: order-service topologyKey: topology.kubernetes.io/zone containers: - name: order-service image: registry.example.com/order-service:1.0.0 ports: - containerPort: 8080 resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10这段配置解决三个问题podAntiAffinity让副本尽量分散到不同可用区避免整个可用区故障时服务全挂。readinessProbe让不健康的 Pod 从 Service 后端摘除流量不会继续打过来。resources限制 CPU 和内存防止某个实例引发资源争抢。但多副本只是第一步。真实的 order-service 还需要连接数据库数据库必须做高可用切换请求要支持重试而且要保证重试的幂等性服务之间调用要设置超时和熔断否则一个慢依赖会把所有线程拖垮。3. 4nim0sity 演练把“宰鱼了”变成可验证结果3.1 演练前先定义 SLI 和 SLO没有指标故障演练就没有判定标准。4nim0sity 的演练前团队先把服务级别指标定义为“HTTP 请求成功率”也就是所有非 5xx 请求占总请求的比例。对应的 Prometheus 聚合规则可以这样写groups: - name: slo.rules rules: - record: job:slo_availability:ratio_rate5m expr: | sum(rate(http_requests_total{code~2..|3..}[5m])) / sum(rate(http_requests_total[5m]))这里的http_requests_total是假设的指标名实际项目中要替换成自己的埋点指标。关键在于分母是所有请求分子是可用请求。如果只统计 HTTP 200会把 3xx 重定向和 4xx 客户端错误都算成不可用这通常不符合业务语义。因此 SLI 定义需要花时间讨论场景推荐 SLI普通 Web APIHTTP 成功率页面访问页面可访问率包含静态资源文件上传上传成功次数 / 上传总次数数据库写入写请求成功次数 / 写请求总次数端到端交易交易成功次数 / 交易发起的有效次数SLI 定义错了后面所有监控、告警、复盘都会颠三倒四。3.2 演练中注入一个最小真实故障4nim0sity 演练的第一步不是直接注入 CPU 或网络故障而是从最可控的故障开始缩小 order-service 的副本数。kubectl -n demo scale deployment order-service --replicas2如果原本有 3 个副本缩到 2 个之后流量会继续打到剩余两个 Pod。这个操作不会立刻让服务不可用但它能验证几件事load balancer 是否正确摘除了被删除的 Pod。readinessProbe 是否按预期工作。剩余副本的容量是否足够承接全部流量。服务发现是否快速更新 Endpoint。确认没有异常后再注入更真实的故障kubectl -n demo scale deployment order-service --replicas1此时只有一个实例业务理论上还能处理请求但如果是大流量可能出现性能瓶颈。这个过程就是混沌演练的“渐进式注入”从影响最小的操作开始逐步扩大范围。再往下一步可以注入 CPU 压力。以下命令使用stress-ng前提是镜像中包含该工具。生产环境更推荐用专门的混沌工具例如 ChaosBlade而不是手动进入容器执行命令。kubectl -n demo exec deploy/order-service -- stress-ng --cpu 1 --timeout 30s注入之后观察指标请求成功率是否下降。P99 延迟是否明显升高。是否有 Pod 变成 NotReady。HPA 是否触发扩容。如果 HPA 在几十秒内补充了新副本并且错误率没有超过预设阈值这次故障注入才算真正“被宰掉了”。3.3 演练后用请求日志验证成功率故障注入结束后要回到数据层验证。可以使用一段 SQL 从日志表里统计成功率SELECT COUNT(*) AS total_requests, SUM(CASE WHEN status_code 500 THEN 1 ELSE 0 END) AS success_requests, SUM(CASE WHEN status_code 500 THEN 1 ELSE 0 END) / COUNT(*) AS availability FROM request_log WHERE service order-service AND ts NOW() - INTERVAL 1 hour;如果日志表记录了全部请求这个查询可以直接给出当前小时的成功率。但要注意几个坑日志可能采样导致成功率偏低或偏高。4xx 请求不应该算作系统故障所以status_code 500是一种便捷写法但不是所有场景都正确。如果客户端在网关处超时但后端实际执行成功单看日志又会出现口径偏差。因此 4nim0sity 的做法是同时看三层数据网关访问日志、业务应用日志、数据库慢查询日志。只有三层能对上才认为演练结果是可信的。注意故障演练不能只做“把某台机器删掉”这种动作还要做“故障注入后业务是否持续可用”的验证。验证动作缺失演练就只是删除测试。4. 验证 99.999999999%SLI 口径、SLO 计算和错误预算4.1 选对 SLI不能只看 HTTP 200在追求极高可用性之前先要知道“可用”到底指什么。SLI 类型常用指标容易踩的坑请求成功率2xx/3xx 请求占比把 4xx 也当成系统故障时延P95/P99只看平均值掩盖长尾吞吐量QPS/TPS低峰期数字抖动大数据正确性数据库校验和、对账只关注接口忽略数据损坏发布成功发布批次成功率只看是否启动不看业务是否恢复如果只设置一个 SLI推荐优先做“请求成功率”。如果业务对延迟敏感再加上 P99 延迟目标例如 P99 200ms。这两个指标能覆盖大多数在线系统的高可用问题。4.2 错误预算用时间量化故障容忍度错误预算来自 SLO公式很简单错误预算 1 - SLO以 7 天窗口为例如果 SLO 是 99.99%那么 7 天内允许的不可用时间大约是7 * 86400 * (1 - 0.9999) 60.48 秒如果换成 99.999999999%7 * 86400 * (1 - 0.99999999999) 0.000006048 秒也就是约 6 微秒。这个数字已经无法用普通业务日志验证因为请求时间戳本身就有毫秒级误差。所以严格来说99.999999999% 这个数字在大部分系统里只能作为理论目标不能作为短期告警阈值。实际工程中可以设置一个“多窗口错误预算消耗”告警避免只看瞬时值。用 Python 脚本模拟一个简单校验有助于理解“成功率”的计算逻辑import random import time success 0 total 0 start time.time() duration 60 def simulate_request(): # 模拟 99.999% 的请求成功0.001% 的请求失败 if random.random() 0.99999: return 200 return 500 while time.time() - start duration: total 1 code simulate_request() if code 500: success 1 time.sleep(0.01) availability success / total print(fsuccess{success}, total{total}, availability{availability:.12f})这个脚本不是真实系统验证工具而是用来演示一个关键点样本量不够时可用性的精度完全不可信。只有几十万甚至上百万请求才能比较稳定地估算到 99.99% 这个级别。4.3 火焰图式告警从错误预算消耗倒推问题告警不能只在成功率跌破阈值时触发更要在错误预算消耗过快时触发。常见做法是“多窗口多燃烧率”告警例如 1 小时窗口消耗 14.4 倍预算、5 分钟窗口消耗 14.4 倍预算。Prometheus 告警规则示例groups: - name: slo-alerts rules: - alert: AvailabilitySLOHighBurnRate expr: | ( 1 - ( sum(rate(http_requests_total{code~2..|3..}[1h])) / sum(rate(http_requests_total[1h])) ) ) (1 - 0.99999) * 14.4 for: 10m labels: severity: page annotations: summary: 可用性错误预算消耗过快这里的0.99999是示例 SLO实际按业务调整。14.4 倍燃烧率意味着如果这个状态持续一个月错误预算会被耗尽。告警不是要“每次波动都通知”而是要在预算即将耗尽前提醒值班人员。5. 常见问题可用性目标设了但执行不下去问题出在哪5.1 现象每个组件都做了高可用整体还是故障这是最常见也最迷惑的情况。看某个服务本身副本多、探针正常、资源充足但端到端故障仍然发生。排查顺序如下先确认用户请求实际经过的完整链路不要只看核心服务。检查 DNS 解析、证书有效期、负载均衡配置和 CDN 回源是否正常。查看链路追踪中的 Timeout 和 Retry 次数定位第一个超时环节。检查数据库连接池是否被打满。确认是否在发布窗口期间出现配置变更。问题现象常见原因检查方式处理建议每个服务看起来都正常但整体不可用链路中某个隐藏依赖变慢查看全链路追踪梳理依赖图增加超时和降级故障转移到备用节点后仍失败备用节点没有实际承载过流量定期做切换演练将备用节点纳入日常流量数据库连接池耗尽导致服务假死慢 SQL 占满连接查看连接池监控和慢SQL限时保护设置最大等待时间以上排查顺序来自 4nim0sity 演练复盘。最快的定位方式不是看单个服务日志而是打开一条完整 trace先看整体耗时分布再层层下钻。5.2 现象SLA 达标但用户体验仍然差“可用性”和“体验”是两回事。如果 SLA 只用成功率定义一个接口虽然全部返回 200但 P99 已经超过 3 秒用户依然会觉得系统卡死了。这类问题的排查重点看 P95/P99 延迟不要只看平均耗时。区分服务端耗时长还是客户端等待超时。检查网络链路公网延迟、DNS 解析耗时、TLS 握手时间。检查慢调用对线程池的占用是否间接拖垮了其它请求。推荐做法是增加一个额外的 SLO指标目标判定HTTP 成功率99.99%成功率低于目标告警P99 延迟200msP99 高于目标告警两个指标同时达标才能说系统在“业务可接受”范围内运行。否则即使成功率再高用户仍然会在高峰期感受到明显卡顿。5.3 现象故障演练是走过场没有注入真实故障如果演练前明确告诉所有人“马上要断网了”那么团队自然会提前盯监控、开会讨论故障注入也就失去了突发性。更常见的走过场是只删除一个无关紧要的 Pod然后在成功率没有明显变化时就宣布演练通过。避免走过场的做法故障注入必须出现在随机时间至少不能每次都是固定时间。注入范围要逐步扩大从单实例扩展到整个可用区。演练过程要有“红队”角色负责制造不可预测的故障。演练结束必须输出故障发现时长、恢复时长、错误预算消耗等数据。问题现象常见原因检查方式处理建议演练中没有真实故障效果注入范围太小或提前准备过度查看注入命令和监控时间点随机化注入扩大影响面故障恢复时间比预期慢很多没有应急响应流程查看值班响应时间建立明确的告警升级路径演练后问题仍然出现没有跟踪整改项检查复盘 Action 清单将整改项纳入迭代计划5.4 现象可用性数字达标了但数据层不一致或丢失在线服务成功率只是高可用的一个维度。数据不一致通常不会立刻让成功率下降但会在对账、报表、订单状态等环节暴露出严重问题。排查方向检查主从同步延迟。检查消息队列消费是否出现重复或丢失。检查跨地域读多活时用户是否访问到了旧数据。检查幂等键是否覆盖所有写请求。如果系统依赖数据库那么数据库的可用性策略必须放到最高优先级。单靠连接池和重试无法解决主库数据丢失问题必须有备份、归档和恢复演练。6. 可复用的高可用检查清单和扩展方向6.1 发布前高可用检查清单每次服务发版前建议按下列清单逐项确认[ ] 依赖图是否更新新增依赖是否划入可用性预算。[ ] 服务是否至少有两个副本并分布在至少两个可用区。[ ] readinessProbe 和 livenessProbe 路径是否真实反映业务状态。[ ] 请求是否设置了超时超时时间是否小于网关超时时间。[ ] 写操作是否具备幂等键是否支持失败重试。[ ] 数据库主从状态是否正常慢 SQL 是否已经治理。[ ] 缓存、消息队列等中间件是否具备集群模式。[ ] 错误日志是否包含请求 ID是否能够通过 trace 串起全链路。[ ] 容量评估是否覆盖当前峰值流量的 2 到 3 倍。[ ] 是否能在 10 分钟内完成回滚。6.2 故障演练排错清单在 4nim0sity 演练中我们总结了一套固定排错顺序先看告警确认故障发生的大致时间。再打开链路追踪找到第一个超时或错误节点。检查基础设施CPU、内存、磁盘、网络、连接池。检查依赖服务数据库、缓存、消息队列、外部 API。检查变更记录发布、配置修改、扩容缩容。确认恢复动作记录从开始到恢复的耗时。分析错误预算消耗判断是否需要触发应急响应。演练排错最忌讳一开始就查代码。先确认“哪个环节不可用”再决定是否要看代码。多数高可用故障发生在依赖、网络、配置层面而不是业务逻辑本身。6.3 从 99.999999999% 落地的学习路径如果你正在建设高可用体系不要急着把目标定成 11 个 9。可以参考下面的路径逐步推进第一阶段把现有系统的请求成功率、P99 延迟、错误日志和报警打通至少能回答“系统当前是否可用”。第二阶段为每个核心服务定义 SLI 和 SLO建立错误预算每周/每月复盘。第三阶段从最小故障注入开始例如缩容、重启、网络延迟注入验证自动恢复能力。第四阶段把故障演练纳入发版流程保证每次重大变更后都有一次快速演练。第五阶段只有当数据和流程都稳定后再尝试更高可用性目标否则 99.999999999% 只会变成墙上的口号。回到 4nim0sity 演练最终让人记住“宰鱼了”的并不是那个夸张的数字而是三件事团队能准确定义可用性能用故障注入验证架构能在恢复后复盘出可执行的整改项。对一个正常业务而言做到这些比绑定一个 11 个 9 的指标更有价值。