/tags/sre/ Recent content in sre on Hugo -- gohugo.io en Sun, 26 Apr 2026 00:45:00 +0800 /posts/slo-error-budget-multi-burnrate-2026/ Sun, 26 Apr 2026 00:45:00 +0800 /posts/slo-error-budget-multi-burnrate-2026/ 📦 本文基于的完整项目源码：meirongdev/shop 阈值告警（“5xx > 1% 持续 5 分钟”）的两个失败模式工程师都熟悉：阈值定低了一周告警一百条没人看，阈值定高了真出事告警来得太晚。Google SRE Workbook 第 5 章给出的思路是 error budget + multi-window multi-burn-rate——让告警的“敏感度”随事件严重程度变化。本文更像是一次整理：为什么、怎么做、以及落地时绕不开的取舍。 一、SLO 和 error budget 的底层逻辑 Q：SLO 不就是"99.9% 可用"这种数字吗？跟告警有什么关系？ 至少在工程落地里，SLO 一个很重要的用途是把 reliability 变成预算。 SLO 99.9% 意味着每个 30 天窗口允许 0.1% 的请求失败——这就是 error budget。 把整个 30 天窗口的 budget 按时间切片：1 分钟内允许失败的请求量很小（少量异常就把这分钟的 budget 烧光），但 30 天内的累计可以容忍。 如果短窗口内的烧速大于"按比例消耗"的速度，说明这次事件如果不止住，会提前烧完整个月的预算——这就是值得告警的事件。 阈值告警是"超过 X 报警"——只看一个时间点。Burn-rate 告警是"按当前的烧速会在多久烧完月度 budget"——看的是趋势对未来的投影。 Q：burn rate 怎么算？ 定义：burn rate = 观察窗口内的实际错误率 / SLO 允许的错误率。 SLO 99.9% → 允许错误率 0. /posts/cdn-dns-survivability/ Tue, 31 Mar 2026 10:00:00 +0800 /posts/cdn-dns-survivability/ 一场“DNS 挂了”的事故，是怎么把 CDN 一起拖下水的 如果你经历过一次真实的 DNS 故障，就会发现它的表象非常有迷惑性：源站明明还活着，负载均衡也没全部坏，甚至某些地区的用户还能短暂打开页面，但外界感受到的却像是“整个网站突然消失了”。 这里最容易产生的误解是：CDN 在前面，所以只要 CDN 健康，网站就应该继续可用。 但很多情况下并非如此。对绝大多数网站来说，DNS 不是一张静态电话簿，而是把用户请求导向某个 CDN 边缘入口的控制平面。DNS 出问题，用户甚至拿不到“该连哪个边缘节点”的答案，于是 CDN、源站和负载均衡会一起表现成不可达。RFC 1034 和 RFC 1035 对 DNS 的权威数据模型做了最基础的定义，NIST SP 800-81r3 则直接把 DNS 基础设施视为网络架构里的关键依赖。 这篇文章就从这个灾难视角出发：先解释 CDN 和 DNS 到底是怎么配合工作的，再推演几类最常见的失效路径，最后收束到“怎样让网站在 DNS 级事故里争取更强韧性”的设计原则。 CDN 和 DNS 是怎么配合工作的？ 当用户在浏览器里输入一个域名时，请求并不会直接飞到某个 CDN 边缘节点，而是先经过本地 stub resolver，再进入递归解析器，然后由递归解析器去查询权威 DNS。RFC 1034 与 RFC 1035 定义了这条查询链路的基本角色和数据结构。 接入 CDN 的常见做法是：域名所有者把自己的记录通过 CNAME 指向 CDN 提供的入口域，或者直接把 NS 记录委托给 CDN 的权威 DNS。这样会出现两段解析：第一段由域名所有者的权威 DNS 返回 CNAME 或直接委托；第二段由 CDN 的 authoritative DNS 根据实时策略返回当前最合适的边缘入口。Amazon Route 53 的 latency-based routing 和 Cloudflare 的 traffic steering 都在第二段做同一件事：基于延迟、健康状态、地理位置或端点可用性，让不同用户解析到不同答案。