> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/2015-0910-cloudabi/book-review.md). # 书评：《云系统管理：大规模分布式系统设计与运营》 * 原文：[Book Review](https://freebsdfoundation.org/our-work/journal/browser-based-edition/cloudabi/) * 作者：**Greg Lehey** 《云系统管理实践》 * 作者：Thomas A. Limoncelli、Strata R. Chalup 与 Christina J. Hogan * 出版社：Addison-Wesley Professional * 印刷版定价：US $54.99 * 电子书定价：US $43.99 * ISBN：032194318X * 页数：560 Thomas A. Limoncelli、Strata R. Chalup 与 Christina J. Hogan 合著的《云系统管理：大规模分布式系统设计与运营》带有“第 2 卷”的上标，无疑是在呼应同组作者的《系统管理与网络管理技术实践》，虽然书中并未明说。 我花了不少时间才与这本书产生共鸣。“云”这个流行词多少让我有些反感。直到读毕，才豁然开朗。书中贯穿的三段文字揭示了它的真正主题。 首先是副标题：设计与运营大规模分布式系统。这下我就明白了。为何还要另起书名？在开篇不久，第二段文字就明确指出，“云”是一个“对不同人意味着不同事物的营销术语”。作者更倾向使用“分布式计算”一词。我深以为然。我感觉作者与出版商在此问题上并未达成一致。 第三段文字位于全书末尾，回答了另一个问题：如何通过一本书学习设计与运维大型系统？要让大型系统运转良好，需要大量人员和他们之间复杂的互动。在结语最后，作者写道：“我们希望这本书给了你一些值得思考的内容……这是早期岁月……剩下看你自己的了。” 分布式系统并非新事物。在 Tandem Computers，我们 30 年前就在做了。从许多方面看，始于 20 世纪 90 年代初的 FreeBSD 项目本身也是一个分布式环境。计算机主要集中在硅谷，但开发者遍布全球。但那并非本书所讨论的分布式系统。本书聚焦于类似 Amazon、eBay 或谷歌的大型基于 Web 的系统。无论书多么好，怎能从一本书里学会构建这样的站点？当然不能。但本书总结了当前的最佳实践，确保你的站点平稳运行。某些地方可能略显松散，但这正是现实的写照。本书着眼全局：当人员不在同一地点、可能不在同一时区时，如何管理大型系统。全书分为两部分：“构建系统”与“运行系统”。 “构建系统”以分布式计算的概述开篇，详尽讨论了冗余、负载均衡与分布式数据存储。重新引入了第一卷中的 CAP 原理：“一致性、可用性、分区容忍性：择其二。” 第 2 章《为运营而生》考虑如何确保构建的内容能够实际运作。这里流露出一定的 Unix 偏见：GUI 配置工具？免了。我们更愿意将配置文件保存在版本控制系统中。第一卷中也有这种偏见，但不这么明显。 第 3 章《选择服务平台》很有意思。它描述了三个方面：你提供何种服务（基础设施、平台还是软件）？是在真实机器、虚拟机还是容器（Jail）上提供？能否将私密数据放在他人可以访问的地方？ 第 4 章《应用程序架构》关注如何分发应用，主要基于 Web 服务器。一台机器？多台机器？在一个地点？横跨全球？如何均衡负载？这只是一部分。第 5 章《伸缩性设计模式》审视其余部分：如何确保性能不随增长而下滑？我发现这两章是全书最具启发性的章节。 第 6 章《弹性设计模式》承认硬件与软件会失败。主要失败原因是什么？如何让系统继续运转？本章较有趣的一个话题是，既然硬件反正会失败、必须为此预留，那购买昂贵硬件就毫无意义：可以用廉价硬件，让它更频繁地失败，反而省钱。一个有趣的例子是谷歌曾经购买未通过质检的内存芯片，并绕过其缺陷使用。本章还提到人为错误是最大问题之一，但暂不讨论如何应对。 第二部分（“运行系统”）从第 7 章《分布式世界中的运营》开始，概述运维结构，重点强调团队与定义良好的流程。引入不少新术语，但在我看来流行词过多。 本章给出两条重要教训。其一，手工操作无法扩展。在单台机器上手工安装软件尚可；若是 1,000 台机器，则需尽可能自动化（但不要过度）。其二是服务生命周期：如何以最小破坏引入新服务（答案：悄然引入）。如何分配时间？ 第 8 章描述 DevOps，我视其为一种确保不同人群之间沟通的当代方法。它对“传统方式”做了一些颇为宽泛的假设——似乎指的是开发出盒装软件、扔给用户便走人。它暗示用户反馈很少，且通过一个旨在把用户与开发者隔离开的支持团队进行，产品更新稀疏。我们都知道这种模式（我把它归为“微软范式”），但这不是唯一的方式。FreeBSD 项目并非如此运作，依我的经验这种模式也较为罕见。这显然是视角差异。 本章论述不足的一点是时区对 DevOps 团队的影响。当团队分布在加州、瑞典与澳大利亚，如何安排电话会议？彼此相差约 8 小时，而澳大利亚的夏令时与北半球反相。我经历过这种事，但除了“那就别这么干”也别无良策。 第 9 章和第 10 章讨论服务交付。它们与分布式计算的关联不如本书其他部分明显；许多方面让我想起 FreeBSD 项目：开发并升级软件，同时让一切持续运转。这里又出现不少术语。有些如“Release Candidate”是老朋友，但其他如“Cycle Time”含义全新（一个 Flow 完成的频率）。所述方法与 FreeBSD 项目的做法不同，但提供了一些值得思考的内容。 第 11 章《升级运行中的服务》讨论一个问题：你不会希望系统因升级而宕机。若新功能失败或引入导致系统宕机的 bug，该怎么办？本章给出多种减轻损害的方法。第 7 章已讨论过此话题，但本章侧重点略有不同，还涉及实时数据库模式更新与实时代码改动等问题。 让机器（计算机）做事而非亲力亲为，显然是好主意，且对扩展性至关重要。第 7 章曾触及此点，第 12 章则详细讨论该话题及其风险。它还涉及一些听起来与自动化关系不大的领域，如版本控制系统与风格指南。 让任何大型项目持续运转都需要清晰的文档。第 13 章《设计文档》讨论这些问题，特别强调责任与签字。 事物会随机失败，但多数人上“日班”。第 14 章讨论随时待命的问题、如何尽量减少真正需要叫人的情形。此时时区可以成为朋友：如果你的组织日不落，问题发生时总有人醒着。相关话题是为灾难做准备，第 15 章讨论此点，对谷歌的灾难培训有精彩洞见。 如何判断运行状况？当然是监控。但系统越大，可收集的数据越多。你需要的是即时信息，还是统计数据？二者各有其位。第 16 章讨论不同目的应监控什么，第 17 章给出监控系统的架构。它远超日志文件：根据所收集的信息，可能需要人工介入，若第一人无响应则需第二人。若情况并未那么糟，如何呈现给管理员使其能够理解？任何翻过 Postfix 邮件日志的人都知道，要把握全局多么不易。本章给出多种选项。 需要监控的内容之一是系统是否提供足够的性能。即便现在够用，将来呢？随着流量上升，性能可能下降，需要一种规划未来容量的方法。这是第 18 章的主题。本章包含大量看起来吓人的数学公式，但非数学背景的读者也能学到很多。毕竟，我们可以让计算机做数学。本章还进一步讨论新服务的上线，这次从可扩展性的角度。 最后两章讨论的问题按理说本可以放在前面：我们到底在测量什么？KPI（关键绩效指标）。听起来简单：快速、准确的响应。但事情当然不总是那么简单。如果我承诺的 15 GB 邮箱空间因磁盘不足而无法兑现，怎么办？这显然是一项需求。本章帮助识别重要参数而非显而易见的参数。关键绩效才是目标。第 20 章《卓越运营》讨论达成卓越所需的态度与度量。 最后是若干附录。附录 A 是一份规划检查清单，确保没有遗漏。附录 B 讨论高可用性的历史，视角与我略有不同。附录 C 讨论更多扩展概念，附录 D 是设计文档模板。 若你正在设计下一个谷歌或 eBay，该如何对待这本书？忽视它你便是疯了；完全依赖它你也疯了。把它视为当前最佳实践的呈现，在你设计流程的每个迭代中查阅。你的产品会因此而更优。 **作者简介** **Greg Lehey** 是一名退休的内核黑客。他是 FreeBSD 项目的 committer 与前核心团队成员，曾是 NetBSD 项目的 committer。他是 Vinum 卷管理器的作者。著作包括《Porting UNIX Software》与《The Complete FreeBSD》。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://freebsd-journal-cn.bsdcn.org/2015-0910-cloudabi/book-review.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.