书名：微服务成功启示录
书号：978-7-5239-0156-4
定价：148元
作者：[英]萨拉·威尔斯（Sarah Wells）
出版时间：2025-09-22
出版社：中国电力出版社
页码： 500    字数(千字)：515
开本：16开    版次：1    印次：1

品牌介绍

中国电力出版社成立于 1951 年，作为中国成立最早的中央科技出版社之一，曾隶属于水利电力部、能源部、电力工业部、国家电力公司，现为国家电网公司所属的科技出版社，在电气技术专业出版领域享有极高的声誉。该社作为以图书出版为主体，音像、电子出版物、期刊、网络出版共同发展的大型出版企业，以强大的出版资源和高素质的专业队伍，致力于向读者提供包括电力工程、电气工程、建筑工程、电子技术、信息技术、外语、大中专教材、家教等学科门类齐全的权威出版物，也竭力为广大师生提供精品教材，是教育部和北京市教委规划教材的出版基地之一。

编辑推荐

一句话推荐 直面技术、组织与文化的挑战。 编辑推荐 微服务是一种极具效能的架构模式，可以为组织和客户创造价值。如果使用得当，微服务可以让你每天都对系统的不同部分进行数百次变更，从而加速交付。但如果处理不当，微服务只会让整个系统变得更加复杂。 在本书中，资深技术领导者Sarah Wells提供了实用且深入的建议，帮助组织顺利迁移到微服务架构。早在2013年，她便在《金融时报》率先构建了微服务架构，并在此过程中积累了丰富的实践经验。她将在书中分享从零开始构建微服务时需要采取的方法，并揭示可能会让你陷入困境的常见问题。此外，你还将学习如何在系统逐步成熟的过程中维护架构，同时尽量减少维护和支持的成本。 专家推荐 “这是一本出色的参考书，能够帮助你了解在小型且被充分授权的团队中，实现‘快速工作流’模式时会遇到的情况。对于任何具有前瞻性的组织来说，这都是必读之作。” ——Matthew Skelton 《团队拓扑学》联合作者， Conflux CEO

产品特色

直面技术、组织与文化的挑战。

作者介绍

Sarah Wells是一位技术领导者、顾问及大会演讲者，专注于微服务、工程赋能、可观测性和DevOps。她拥有20多年的开发经验，曾担任高级工程师和技术总监，领导过产品、平台、SRE和DevOps团队。

内容介绍

微服务是一种极具效能的架构模式，可以为组织和客户创造价值。如果使用得当，微服务可以让你每天都对系统的不同部分进行数百次变更，从而加速交付。但如果处理不当，微服务只会让整个系统变得更加复杂。通过本书，你将学到：微服务对软件开发模式和实践的影响。成功构建和运行微服务架构所需的组织变革。在迁移到微服务之前必须完成的关键步骤。设计微服务架构时需要避免的陷阱，以及如何从错误中恢复。
本书适用于正在向微服务转型的资深工程师、架构师和技术负责人，需要了解转型对现有技术栈和流程的影响。已采用微服务但面临复杂性挑战，希望学习他人成功经验的实践者。关注架构可持续性，寻求长期治理方法的技术决策者。

前言

前言 微服务架构能有效加速组织与客户的价值交付，前提是实施得当。若实施不当，我们可能会陷入复杂混乱的系统，运营维护变得异常困难，小型团队不得不维护大量服务，其中有些甚至从未接触过其代码。 采用微服务架构不仅仅是选择一种技术方案。要成功实施微服务，我们需要进行文化和组织层面的变革。这要求组织必须向自主权更高、赋能更充分的新型团队结构转型。 这意味着传统由专项团队承担的职责正转移至工程团队。开发者不能局限在系统设计、架构和实现层面，还需要考虑如何构建可投入生产的系统，以及如何进行长期维护管理。开发者必须理解分布式系统架构，并在部分基础设施环节具备实操能力。 本书将帮助解决上述所有问题。它提供实践指导，涵盖如何采用微服务架构，以及如何确保在多年维护成熟系统过程中，架构仍能持续有效。 创作缘由 本书聚焦如何长期受益于微服务架构。我们希望帮助读者避免经历数年后陷入意外复杂性，开发人员花费大量时间处理无法创造业务价值的问题。如果已处在这种困境中，本书将提供应对方案。 2013 年我构建了第一个微服务系统，八年后仍在同一组织持续开发和运维着这些系统。这意味着我既看到问题产生，也参与解决过程，并有足够时间验证解决方案的实际效果。 在此期间，我先后从事产品开发、运维与事件管理、工程效能提升等工作。这些经历让我对微服务实施形成了多维视角。本书旨在帮助读者建立可持续成功的微服务架构体系。 目标读者 本书适合以下三类技术从业者： • 正在向微服务转型的资深工程师、架构师和技术负责人，需要了解转型对现有技术栈和流程的影响。 • 已采用微服务但面临复杂性挑战，希望学习他人成功经验的实践者。 • 关注架构可持续性，寻求长期治理方法的技术决策者。 我们默认读者们均已具备软件开发与架构设计的基础知识，但不要求有微服务实践经验。 本书不深入特定技术的实现细节，也不提供一站式的操作指南，这些领域已有专门著作涵盖，我们会在相应章节推荐参考书籍。本书侧重实用建议，但不会限定在某一特定技术，而是聚焦决策原则，帮助读者选择适合的工具。对于微服务架构的新手，第 1 章将介绍基本概念、优缺点以及推动其普及的关键技术。若已具备这些基础知识，可直接从第 2 章开始阅读。 阅读指南 本书各章节独立成篇。可直接阅读特定章节满足当前需求，但顺序通读能发现章节间的知识递进关系。 本书分为三大部分：背景认知、组织架构与文化、构建与运维。下面简要介绍各部分内容。 第一部分：背景认知 本部分构建认知基础：明确微服务的定义、成功要素及其适用场景。第 1 章系统解析微服务架构模式，涵盖核心优势与实施挑战。 第 1 章，理解微服务 我们将从明确定义微服务架构风格开始。这对刚接触微服务的读者是必要的知识基础，对有经验的实践者也值得回顾核心概念，包括采用该架构的初衷。 第 2 章，高效软件交付 有效软件交付的标准是什么？本章讨论保持快速交付节奏、聚焦高价值功能开发、构建稳定可靠系统、有效控制风险、避免重复工作以及创建专注核心任务的工作环境这六个关键要素。作为全书指南，本章将建立各核心概念的关联框架，后续章节将详细解析每个要素。 第 3 章，微服务是否适合 微服务架构可能非常高效，但它并不是唯一选择。那么，它是否适合我们呢？本章将帮助我们进行评估决策，讨论成功迁移到微服务架构需要做好的必要准备。 第二部分：组织架构与文化 要在微服务领域取得成功，仅仅采纳架构模式是不够的。组织和文化层面的考量同样重要，且应优先关注：若处理不当将导致复杂度激增而收益有限。本部分重点解析相关组织与文化挑战。 第 4 章，康威定律与寻找合适的边界 康威定律指出，组织架构决定系统设计：两个独立团队必然产出两个系统。本章将探讨这一定律的影响，并说明如何合理规划团队边界。 第 5 章，构建高效团队 成功实施微服务需要特定的组织文化：开放包容、持续学习、适应变革。本章将阐述高效团队必备的文化特质，自主决策的跨职能团队需具备设计、构建、部署等全流程技能。 第 6 章，打造自主团队 团队需要能够自主掌控工作节奏，无需依赖外部支持即可完成工作。本章将探讨如何支持团队的自主性、明确团队应承担的职责，以及跨团队协作机制。 第 7 章，工程赋能与预设路径 我们无法在每个开发团队中都配备所有技能。需要明确区分通用平台 / 基础设施服务（所有团队都需要的基础能力）和具体的业务产品。平台团队负责构建和运维基础平台，开发团队则专注于构建和运营业务服务。两者间的协作需要尽可能减少阻碍，同时确保达到企业要求的安全标准、质量水平和成本控制。本章将讨论如何构建预设路径，通过提供统一的工具和服务，让所有产品开发团队都能轻松开展工作。 第 8 章，确保“谁构建，谁运行” 如果每个服务都要交给其他团队运维，我们就无法快速推进。服务在生产环境中的运维责任必须由编写代码的团队自行承担。这会带来双重影响：当你知道自己可能就是凌晨两点被叫醒处理问题的人，就会以不同视角看待系统；但这也意味着许多从未参与过 on-call 轮值的开发者需要开始承担责任。此外，部分团队可能规模太小，难以安排非工作时间值班。本章将探讨如何应对这些新要求，让 on-call 轮值不再成为负担。 第三部分：构建和运维 第三部分将深入探讨微服务的构建与运维实践。每一章均包含最大化发挥微服务价值的技术实践，说明其需要采用不同于单体架构的方法，并基于近十年的实战经验总结而成。 本部分各章不仅讲解如何预防问题发生，还会提供当系统真正出现故障时的应急预案，帮助团队摆脱运维困境。 第 9 章，活跃的服务所有权 服务必须由团队积极地且强有力地拥有，而非依赖个人。这种积极所有权意味着：及时升级依赖项、持续监控告警、定期审查代码、快速修复安全漏洞。本章将详细阐述积极所有权的具体内涵及实施路径。 第 10 章，得测试之利 本章聚焦微服务测试实践。自动化单元测试能快速提供高价值反馈，但相比预发环境的端到端测试（可能陷入测试用例维护泥潭），生产环境的实时测试结合有效监控往往更具实效性。必须严格控制手动测试：当发布频率从每周一次提升到每日多次时，传统人工测试的时间成本将无法承受。 第 11 章，治理与标准化：找准平衡点 微服务的核心优势在于根据场景选择最佳工具。但这种在编程语言或数据存储层的灵活选择会带来三重影响：提升系统架构复杂度、削弱团队快速响应重要需求的能力、同时带来成本与风险的双重提升。本章将通过三个关键措施探讨如何实现平衡，建立技术约束框架、采用经过验证的技术方案、实施轻量化治理机制。 第 12 章，内化弹性设计 微服务本质上是分布式系统，其构建方式需要特别考量。本章将系统阐述韧性服务的构建方法及其系统级整合策略，涵盖五大关键技术要素：服务水平目标（SLO）、错误预算机制、智能缓存策略、超时重试模式，以及混沌工程实践。 第 13 章，生产环境中的系统实践 你是否经历过 Slack 频道被海量告警淹没而无法使用？或是存在大量无人理会的无效告警？这两种情形都意味着运维体系的重大缺陷。本章将剖析微服务系统的运维挑战，详解如何构建可观测性体系，并确保在真实故障发生时能够精准识别。 第 14 章，保持系统演进 面对庞杂的技术栈与海量服务，我们可能耗费大量时间进行依赖升级和版本迁移。当紧急安全补丁需要同时作用于数百个服务时，问题将更加严峻。本章将探讨如何最大限度地减少这些变更的影响，以及如何有效地管理您确实需要进行的变更。 附录 最后，在本书的结尾，我将所有内容综合起来。我阐述了为何在许多情况下微服务是正确的选择，并为您提供了评估指导。这些指导将帮助您判断微服务是否适合您，以及您是否在结构、文化、工具和流程等方面具备了成功采纳微服务所需的条件。最后，我列出了一个简短的推荐阅读清单：这些书籍是我写作时触手可及的案头之物，那些帖子则是我网页浏览器标签页中打开的文章。 案例研究 尽管我在全书中借鉴了现实生活中的例子，但也包含了一些深入的案例研究。 这些案例来自《金融时报》及其他机构： • 案例研究：Shopify 的模块化单体架构，第 3 章。 • 案例研究：在金融时报界定我们的边界，第 4 章。 • 案例研究：《金融时报》组织架构的演变，第 5 章。 • 案例研究：《金融时报》支持自主团队，第 6 章。 • 案例研究：《金融时报》的工程赋能，第 7 章。 • 案例研究：《金融时报》的突发事件管理，第 8 章。 • Monzo 的治理研究，第 11 章。 • Skyscanner 的治理研究，第 11 章。 O’Reilly 在线学习平台（O’Reilly Online Learning） 近 40 年来，O’Reilly Media 致力于提供技术和商业培训、知识和卓越见解，来帮助众多公司取得成功。 我们拥有独一无二的专家和革新者组成的庞大网络，他们通过图书、文章、会议和我们的在线学习平台分享他们的知识和经验。O’Reilly 的在线学习平台允许你按需访问现场培训课程、深入的学习路径、交互式编程环境，以及O’Reilly 和 200 多家其他出版商提供的大量文本和视频资源。有关的更多信息，请访问 http://oreilly.com。 联系我们 任何有关本书的意见或疑问，请按照以下地址联系出版社。 美国： O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 中国： 北京市西城区西直门南大街2号成铭大厦C座807室（100035） 奥莱利技术咨询（北京）有限公司 勘误、示例和其他信息可访问 https://oreill.y/enabling-microservice-success获取。 对本书的评论或技术疑问，可以发电子邮件到 errata@oreilly.com.cn。 欲了解本社图书和课程的新闻和信息，请访问我们的网站 http://oreilly.com。 我们的 LinkedIn: https://linkedin.com/company/oreilly-media。 我们的 YouTube：http://youtube.com/oreillymedia。 致谢 首先，我要感谢在《金融时报》共事的众多同事。在《金融时报》的时光里，我学到了很多，也获得了许多机会。 我在那里度过了十多年，能列举出数百位影响我的人，因此让我特别提出几位。Cait O'Riordan 和 John Kundert 带领部门经历了重大变革，并鼓励我挺身而出，成为领导者。Rob Shilston 激励我在 2015 年为 Velocity 大会提交提案，为我成为出版作者铺平了道路。我内容计划、运营与可靠性以及工程支持部门的同事们：感谢你们一直以来分享想法、提供反馈，以及总体上的卓越表现。 感谢大家！ 感谢以下人士：Daniel Bryant 和 Sam Newman 对提案的反馈，以及自始至终的帮助；Benji Weber、Abby Rangser、Tanya Reilly、Nicky Wrightson 和Anna Shipman 对本书早期大纲及第 1 章初稿提供了宝贵的反馈。他们的建议极大地修正了我的方向，使得本书质量大幅提升。 Sam、Daniel、Anna、Nicky、Abby 和 Suhail Patel 对整本书进行了审阅，非常感谢！你们付出时间上的慷慨付出以及全面细致的反馈，极大地提升了本书的质量并使之更加紧凑。当然，任何遗留的错误均由我个人负责。 感谢 Philip Muller 就 Shopify 和模块化单体架构的运作方式进行了引人入胜的讨论；感谢 Matt Clarke 提供了关于 Spotify 平台工程实践的信息；感谢Charles Humble 邀请我参与他的播客《Hacking the Org》，其中关于工程赋能的讨论大地帮助了我撰写关于铺路的初稿；感谢 Matthew Skelton 对第 4 章和第 5 章的反馈，这两章大量借鉴了他的《团队拓扑》一书，并感谢他分享了他与 Manuel Pais 关于团队类型思考的最新进展；同时感谢 Simon Brown允许我重用他在 2018 年 GOTO 大会上关于“模块化单体”演讲的内容。 我深感惊叹能有如此多的人为我解答疑问，分享他们的工作细节，确认我理解了他们的文字，或给予我一般的帮助和鼓励。在此，我要感谢 Liz FongJones、Charity Majors、Susanne Kaiser、Joe Wardell、Stuart Davidson、Matt Chadburn、Alice Bartlett、Luke Blaney、Rhys Evans、Rob Godfrey、Liz Saling，以及 Victoria Morgan-Smith，他们的支持无分先后，均令我感激不尽。感谢 O’Reilly 的每一位成员：策划编辑 Louise Corrigan；出色的开发编辑 Jill Leonard；还有 Melissa Duffield，这位责任编辑让我确信在离开 FT 后的“失业期”写这本书正是我应该做的事。与你们三位的定期会议，为写作过程增添了许多愉快的亮点。同时，也感谢所有引导我书稿生产流程的同仁：ClareLaylock、Kim Cofer、Kate Dullea、Johnna VanHoose Dinse、Tonya Trybula、Karen Montgomery、David Futato、Kristen Brown，以及其他工作人员。 最后，感谢我的丈夫 Steve。从我作为演讲者的第一步，到历经数月的写作、思考、重写和编辑，没有你的支持，我无法完成这一切。

目录

目录
序 1
前言 3
第一部分 背景认知
第 1 章 理解微服务 15
11 微服务架构风格 16
111 服务集合 17
112 独立进程运行 17
113 轻量级通信机制 17
114 围绕业务能力构建 18
115 可独立部署 18
116 “Small”小型化 19
117 最小化集中管理 19
118 技术异构性 20
12 前驱方案与替代选项 20
121 单体架构 20
122 模块化单体架构 22
123 面向服务的架构 23
13 微服务生态系统 24
131 基础设施即代码 25
132 持续交付 27
133 公有云 28
134 新型部署模式 30
135 开发运维一体化（DevOps） 35
136 可观测性 36
14 微服务优势 36
141 独立可扩展 37
142 健壮性 37
143 小步快频，轻松发布 38
144 灵活的技术选型 39
15 微服务架构的挑战 39
151 网络延迟 40
152 技术资产复杂性 40
153 运维复杂性 41
154 数据一致性 42
155 安全 43
156 服务粒度的把控 44
157 变更管理 46
158 需要组织层面的调整 48
159 改变开发者体验 48
16 小结 50
第 2 章 高效软件交付 51
21 定期交付业务价值 52
211 高部署频率 54
212 缩短交付周期 55
213 进行实验 57
214 代码部署与功能发布分离 58
215 跨团队协作的架构管理 59
22 适应需求优先级变化 62
23 维持适当的服务水平 64
231 当发布出现问题时 65
232 及时感知核心服务故障 66
233 实现服务能力的快速局部恢复 69
234 避免故障连锁反应 70
24 专注于核心价值工作 72
25 避免从头再来 74
26 风险管理：维持在可控范围内 77
27 微服务架构适用性评估 78
28 小结 79
第 3 章 微服务是否合适 80
31 选择微服务的原因 81
311 应用组织规模扩张 81
312 开发者体验 84
313 隔离合规安全敏感业务模块 85
314 负载扩展 86
315 提高鲁棒性 86
316 提高灵活性 87
32 成功前提 88
321 领域认知 88
322 产品而非项目 88
323 领导层支持 89
324 追求自主权的团队 90
325 实现自主性的流程 90
326 技术成熟度 91
33 变革管理 92
34 坚持采用单体架构 93
341 实现零停机部署 93
342 构建模块化单体架构 94
35 分布式架构已成常态 99
351 云原生的崛起 100
352 意义重大 100
36 建议 101
361 从零开始 101
362 替换现有单体 102
363 衡量成功 105
37 小结 105
第二部分 组织架构与文化
第 4 章 康威定律与寻找合适的边界 111
41 康威定律 112
42 逆向康威策略 115
43 潜在边界划分方案 116
431 业务领域 117
432 地点 118
433 技术 119
434 合规性 120
435 失败容忍度 120
436 变更频率 121
437 建议 122
44 识别边界划分错误 123
45 小结 126
第 5 章 建立高效团队 127
51 组织文化 127
511 开放 128
512 学习 129
513 授权 130
514 面向变化的优化 131
515 韦斯特鲁姆模型 131
52 高效团队 133
521 通过自主性、精通度和目标感来激励 134
522 与业务领域对齐 135
523 合理的规模 136
524 跨职能和 T 型 137
525 强所有权 139
526 持久性 140
527 可持续认知负荷 141
528 高信任度和高心理安全感 142
529 团队构成 143
53 优化流程 143
531 流对齐团队 145
532 赋能团队 146
533 复杂子系统团队 146
534 平台团队 147
54 小结 150
第 6 章 打造自主团队 152
61 什么是自主性 153
611 自主性为什么重要 153
612 自主性的限制 154
62 适度沟通 155
63 互动类型 156
631 协作型 157
632 服务型 158
633 促进型 159
64 支持自主性的工作方式 160
641 对齐目标 161
642 轻量化治理 162
643 信任但要验证 163
644 在技术上达成一致 164
645 个人贡献者角色 166
646 最小可行能力 167
647 创造学习空间 168
65 自主团队的责任 169
651 积极所有权 169
652 沟通与合作 170
653 遵守标准 171
654 维护一个团队页面 171
66 小结 173
第 7 章 工程赋能和预设路径 175
71 名称的含义 177
72 搭建平台 178
721 平台服务 180
722 组织层面的考量 181
723 构建最精简可行平台 183
724 专注于大多数人的需求 185
725 平台产品化 186
73 超越平台 188
731 供应商工程 189
732 API, 模板，标准库和示例 190
733 服务目录 191
734 洞察力 192
74 设置预设路径 193
741 包含的能力 196
742 可选的意义 198
743 保持小规模 200
744 如何偏离预设路径 200
745 将宝藏带回平台 202
746 内部开发者门户 202
75 打造实用平台 203
751 确保需求被满足 204
752 营销我们的产品 205
753 留意问题的出现迹象 207
76 构建预设路径的核心原则 207
761 可选的 209
762 有价值的 209
763 自助的 211
764 被支持的 212
765 易用的 213
766 具有指导性的 215
767 可组合扩展的 215
77 衡量影响 216
78 工程赋能的正确时机 218
79 小结 223
第 8 章 确保“谁构建，谁运行” 225
81 为什么微服务意味着 DevOps 226
811 按需发布 227
812 处理运维功能 228
82 以不同的方式进行构建 229
821 良好的运维手册 229
822 运行在其他人的服务器中 232
823 适应生产环境 232
83 在生产环境支持团队 233
831 专职的工作时间内运维支持 233
832 优化告警和文档 235
833 识别出幽灵森林 235
834 练习 236
84 非工作时间支持 238
841 允许人们选择退出 239
842 正式轮班制度 vs 全力以赴制度 240
843 确保呼叫很少 242
844 只针对关键系统 242
845 提供支持和指导 243
85 事故管理 244
851 无责备文化 245
852 上报事故 247
853 分配角色 248
854 事故期间 248
855 事故之后 250
856 从事故中学习 250
86 小结 253
第三部分 构建和运维
第 9 章 活跃的服务所有权 257
91 响应 Log4Shell 漏洞 258
92 一个反面教材：Equifax 和 Struts 漏洞 260
93 开发过程中的所有权 261
931 强所有权 262
932 弱所有权 262
933 共享所有权 263
94 一旦服务功能完备了 265
941 空所有权 266
942 名义所有权 266
943 积极所有权 266
95 积极所有权的含义 267
951 代码管理 268
952 升级和修补 268
953 迁移 269
954 生产支持 270
955 文档管理 270
96 了解服务资产 271
961 自研软件 272
962 依赖 272
963 第三方软件 273
97 服务目录中需要什么 275
971 基于图的模型 276
972 API 驱动 277
973 可扩展的 278
974 灵活的数据结构 278
975 提供整个资产的不同视图 280
98 所有权转让 281
981 成功的转让是什么样的 282
982 满足质量要求 282
983 运营方面的移交 283
984 替代 283
99 当我们陷入困境时 284
991 提供业务支持案例 284
992 从关键系统开始 285
993 尽力推测系统的所有者 286
994 从数据中交付价值 287
995 目标是持续优化 287
996 识别出负担过重的团队 288
997 服务不应永存 289
910 小结 290
第 10 章 得测试之利 291
101 为何测试 292
1011 正确地实现功能 295
1012 实现正确的功能 296
1013 捕捉回归缺陷 298
1014 满足服务质量要求 298
102 测试左移 299
103 什么才是好的测试 301
1031 尽快尽早发现问题 301
1032 易于修改 302
1033 直指问题 302
104 测试的种类 303
1041 测试金字塔 304
1042 单元测试 304
1043 服务测试 305
1044 端到端测试 307
1045 契约测试 309
1046 连贯性测试 310
1047 探索性测试 310
1048 跨功能测试 311
105 生产环境测试 312
1051 这安全吗 313
1052 预生产环境不是模拟生产环境 314
1053 总有别出心裁的用户 315
1054 总有变化测试不到 316
1055 不必把变更推给所有人 316
1056 监控即测试 319
106 基础设施测试 322
1061 混沌工程 323
1062 测试故障切换和数据恢复 324
107 质量不只源于测试 324
108 当你陷入困境 325
1081 自动化测试不足 325
1082 无效的测试 326
109 小结 327
第 11 章 治理与标准化：找准平衡点 328
111 为什么要治理 329
112 了解技术资产 329
113 记录何种信息 330
114 指导原则与政策 331
1141 指导原则自动化 333
1142 指导原则的内容 334
1143 金融时报的指导原则 334
115 共创指导原则 345
1151 技术治理小组（TGG） 346
1152 TGG 的价值 350
116 技术选型 351
1161 技术的生命周期 352
1162 为商业价值而创新 356
1163 用些无聊的技术 359
1164 精简选择 361
1165 哪些可以重复 362
1166 改变总会发生 363
117 先洞察再行动 363
118 其他组织的治理故事 364
1181 Monzo 的治理 364
1182 Skyscanner 的治理 366
119 当你陷入困境 368
1110 小结 369
第 12 章 内化弹性设计 371
121 什么是弹性 371
1211 分布式系统的弹性 373
1212 微服务的弹性 378
122 理解服务等级要求 379
1221 服务等级目标（SLO） 380
1222 错误预算 382
123 构建弹性服务 382
1231 冗余 383
1232 快速启动与优雅关闭 384
1233 合理的超时时长 384
1234 退避与重试 385
1235 幂等化请求 386
1236 保护自己 387
1237 验证服务弹性 387
1238 简化服务弹性设计 387
124 构建弹性系统 388
1241 缓存 388
1242 应对级联故障 389
1243 降级行为 390
1244 避免无效工作 391
1245 异步调用 392
1246 故障切换 393
1247 备份与恢复 393
1248 灾难恢复 394
125 构建弹性平台 394
1251 外部弹性 395
1252 内部工具 396
126 验证系统弹性 398
1261 混沌工程 399
1262 测试备份和重置 401
1263 熟能生巧 401
1264 负载测试 401
1265 从事故中学习 402
1266 一次只做一件事 402
127 当你陷入困境 403
128 小结 404
第 13 章 生产环境中的系统实践 406
131 微服务的运维挑战 407
1311 技术多样性的支持难题 409
1312 基础设施的短暂性 410
1313 快速变更 411
1314 警报过载 411
1315 弹性机制掩盖系统降级 412
132 内置可观测性 412
1321 日志 413
1322 监控和度量 415
1323 日志聚合 416
1324 OpenTelemetry 420
1325 关注事件 420
1326 分布式追踪 421
1327 归档观测数据 421
133 打造工具 422
134 聚焦问题 424
1341 正确告警 425
1342 健康检查 426
1343 监控业务成效 431
1344 了解系统常态 432
135 故障应急指南 433
136 故障排查 433
1361 维护核心文档 434
1362 洞察变更轨迹 436
1363 外源性故障隐患 436
1364 工具特性分析 437
137 从事故中学习 438
138 当你陷入困境 438
139 小结 439
第 14 章 保持系统演进 440
141 挑战源自何处 441
142 减轻变更冲击 442
1421 做长久打算 442
1422 规范路径的价值 442
1423 选择托管服务和 SaaS 方案 443
1424 提供 API 接口 444
1425 不可变的一次性基础设施 445
1426 退役和弃用 445
143 变更的分类 445
1431 紧急变更 446
1432 计划内的次要变更 446
1433 计划内的重大变更 446
144 应对变更 447
1441 技术资产的全景管理 448
1442 制定指导性政策 449
145 做出决策 450
1451 决策权归属 450
1452 工作排期权衡 450
146 管理变更 451
1461 保持清晰 452
1462 保持沟通 454
1463 保持同理心 457
1464 执行 462
147 当你陷入困境 463
148 总结 463
后记 465
附录 A 微服务评估 469
附录 B 推荐阅读 475