书评：《云系统管理：大规模分布式系统设计与运营》

• 原文：Book Review

• 作者：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》。