可靠性 on Tony老师的博客

《SRE：Google 运维解密》读书笔记：错误预算与事后总结

Wed, 25 Sep 2024 10:00:00 +0800

上一篇（《SRE》读书笔记：SLI 与 SLO）聊了 SLI/SLO 的概念，这篇继续聊 SRE 的另外两个核心实践：错误预算（Error Budget） 和 事后总结（Postmortem）。这两个实践一起，把"故障"从追责对象变成了改进机会。

《SRE：Google 运维解密》读书笔记：SLI 与 SLO

Thu, 30 Nov 2023 10:00:00 +0800

Google 的 SRE 团队在 2016 年公开了《Site Reliability Engineering》（《SRE：Google 运维解密》），这本书影响了过去十年整个互联网行业的运维实践。它的核心思想是用工程化的方法解决可靠性问题，而不是用"运维人员加班"。

这一篇主要聊聊 SLI/SLO 这两个核心概念。

混沌工程实践：从 Chaos Monkey 到 Chaos Mesh 的演进

Fri, 08 Apr 2022 11:00:00 +0800

2021 年双十一凌晨 1 点，我们一个核心订单服务因为 Redis 抖动雪崩了 17 分钟。事后复盘：监控告警是有的，但"Redis 主从切换 + 客户端超时 + 下游线程池打满"这条故障链，从没在生产演练过。次年我们启动了混沌工程专项 —— 不是为了"搞破坏"，而是为了让"故障响应"变成肌肉记忆。

混沌工程不是故障注入工具的堆砌。它是一套围绕"假设 → 实验 → 学习 → 改进"的工程方法论，过去十年从 Netflix 的"野蛮猴子"演化为云原生的精细化平台。本文梳理这条演进线，并给出 K8s 时代落地 Chaos Mesh 的实战经验。

限流四算法：从计数器到令牌桶的工程取舍

Wed, 16 Oct 2019 10:00:00 +0800

凌晨三点，监控系统告警：下单服务的 P99 延迟从 80ms 跳到 4s，CPU 跑满，数据库连接池打满，线程全部阻塞在等锁。重启服务、扩容数据库、加机器,十分钟后雪崩回来。问题根源不是代码 bug，是上游推荐服务在做一次全量重算，把下单接口的 QPS 从 2k 顶到 12k——所有资源都被拖垮，正常的请求也跟着排队超时。

这就是典型的"过载崩":服务不是慢慢变慢,而是像多米诺骨牌一样整体失能。排队论早就告诉我们，当系统利用率接近 100% 时，等待时间会呈指数级上升，客户端等不到响应就会重试，重试又叠加到已经过载的系统上，正反馈循环,雪崩。限流是在过载边缘切一刀,把多余的请求挡在外面,保护自己,也保护共享资源的所有调用方。

这篇文章想回答几个问题:主流的限流算法有哪几种、各自的取舍是什么?从单机限流到分布式限流,真正难的是哪一步?线上落地时应该选 Nginx、OpenResty 还是应用层自己实现?

GFS 论文中英对照全文翻译（The Google File System）

Sat, 12 Apr 2014 10:00:00 +0800

这是 Google File System 论文的完整中英对照翻译。原文 15 页，正文 9 节，参考文献 12 条。

体例：每段先列英文原文（引用块），紧接中文译文。图与表格按原文内容重绘；专业术语保留英文并附中文，原文的引用编号 [n] 对应文末参考文献。