描述
开 本: 32开纸 张: 胶版纸包 装: 平装是否套装: 否国际标准书号ISBN: 9787111532644
本书凝聚作者多年来在不同的互联网公司工作和咨询过程中积累的丰富经验，从人、过程、技术三个角度深刻而广泛地讨论了技术管理和技术架构的具体实践经验，强调了组织、人员、过程和技术的**配合，深入浅出地分析了在技术管理过程中经常遇到的各种具体问题，既讲解理论，也佐以实例，让读者可以系统地获得关于技术管理和技术架构方面的知识和经验。
任何一个持续成长的公司最终都需要解决系统、组织和流程的扩展性问题。本书汇聚了作者从eBay、VISA、Salesforce.com到Apple超过30年的丰富经验， 全面阐释了经过验证的信息技术扩展方法，对所需要掌握的产品和服务的平滑扩展做了详尽的论述，并在第1版的基础上更新了扩展的策略、技术和案例。
针对技术和非技术的决策者，马丁阿伯特和迈克尔费舍尔详尽地介绍了影响扩展性的各个方面，包括架构、过程、组织和技术。通过阅读本书，你可以学习到以*化敏捷性和扩展性来优化组织机构的新策略，以及对云计算（IaaS/PaaS）、NoSQL、DevOps和业务指标等的新见解。而且利用其中的工具和建议，你可以系统化地清除扩展性道路上的障碍，在技术和业务上取得前所未有的成功。
第二版的更新
用现实世界中成功和失败的真实故事，取代第一版中的AllScale虚拟案例
新增了关键话题：敏捷组织的新型结构，把数据中心转移到云端的决策根据，业务指标对系统整体健康的重要性，云计算技术，以及关于NoSQL解决方案的讨论等。
本书赞誉
中文版序一
中文版序二
中文版序三
中文版序四
译者序
序
前言
作者简介
第一部分 可扩展性组织的人员配置
第1章 人员和领导力对扩展性的影响 …… 2
1.1 案例方法 …… 3
1.2 为什么要讨论人 …… 3
1.3 为什么组织很重要 …… 5
1.4 为什么管理和领导如此重要 …… 12
1.5 结论 …… 15
第2章 可扩展性技术组织的角色 …… 17
2.1 失败的影响 …… 17
2.2 定义角色 …… 19
2.3 执行人员的责任 …… 22
2.4 独立贡献者的责任 …… 28
2.5 RASCI工具 …… 35
2.6 结论 …… 39
第3章 组织的设置 …… 41
3.1 组织对可扩展性的影响 …… 41
3.2 团队规模 …… 45
3.3 组织结构 …… 54
3.4 结论 …… 77
第4章 领导力秘籍 …… 80
4.1 什么是领导力 …… 82
4.2 领导力概念模型 …… 84
4.3 自知之明 …… 86
4.4 身先士卒 …… 89
4.5 谦虚谨慎 …… 91
4.6 以人为本，使命为先 …… 92
4.7 决策英明，以德服人 …… 93
4.8 用人不疑 …… 95
4.9 与股东价值保持一致 …… 96
4.10 变革型领导 …… 97
4.11 愿景 …… 98
4.12 使命 …… 102
4.13 目标 …… 104
4.14 总结 …… 106
4.15 成功的因果路线图 …… 111
4.16 结论 …… 113
第5章 管理秘籍 …… 116
5.1 什么是管理 …… 118
5.2 项目和任务管理 …… 120
5.3 团队建设：球队类比 …… 124
5.4 优化团队：花园类比 …… 126
5.5 度量、指标和目标评估 …… 131
5.6 目标树 …… 135
5.7 为成功铺路 …… 137
5.8 结论 …… 138
第6章 关系、思维和商业案例 …… 141
6.1 业务与技术之间的鸿沟 …… 141
6.2 击败IT思维模式 …… 145
6.3 为扩展性加大投入的业务理由 …… 147
6.4 结论 …… 152
第二部分 构建可扩展的过程
第7章 过程是可扩展的关键 …… 154
7.1 过程的目的 …… 155
7.2 正确的时间和正确的过程 …… 160
7.3 当好的过程变坏的时候 …… 164
7.4 结论 …… 166
第8章 管理故障和问题 …… 169
8.1 什么是故障 …… 170
8.2 什么是问题 …… 171
8.3 事故管理的组成部分 …… 172
8.4 问题管理的组成部分 …… 176
8.5 解决事故和问题管理之间的矛盾 …… 177
8.6 事故和问题的生命周期 …… 178
8.7 施行每日事故例会制 …… 179
8.8 施行季度事故总结制度 …… 181
8.9 事后处理 …… 182
8.10 融会贯通 …… 185
8.11 结论 …… 186
第9章 危机管理和升级 …… 189
9.1 什么是危机 …… 191
9.2 为什么要区分危机和其他的事故 …… 192
9.3 危机如何改变公司 …… 193
9.4 混乱中的秩序 …… 195
9.5 通信与控制 …… 200
9.6 作战室 …… 201
9.7 升级 …… 203
9.8 情况通报 …… 204
9.9 危机事后处理与沟通 …… 205
9.10 结论 …… 207
第10章 生产环境的变更管理 …… 210
10.1 什么是变更 …… 211
10.2 变更识别 …… 212
10.3 变更管理 …… 214
10.4 变更控制会议 …… 228
10.5 过程的持续改进 …… 229
10.6 结论 …… 230
第11章 确定应用发展的预留空间 …… 233
11.1 目的 …… 234
11.2 结构 …… 235
11.3 理想使用率 …… 240
11.4 使用电子表格的快速示例 …… 244
11.5 结论 …… 246
第12章 确立架构原则 …… 248
12.1 目标和原则 …… 248
12.2 架构选择 …… 251
12.3 AKF采用的最普遍的架构原则 …… 255
12.4 结论 …… 266
第13章 联合架构设计和架构审查委员会 …… 267
13.1 修复组织的功能障碍 …… 267
13.2 跨部门的扩展性设计 …… 268
13.3 JAD的准入和退出标准 …… 271
13.4 从JAD到ARB …… 274
13.5 举行会议 …… 276
13.6 ARB的准入和退出标准 …… 278
13.7 结论 …… 281
第14章 敏捷架构设计 …… 284
14.1 敏捷组织中的架构 …… 286
14.2 架构的所有权 …… 287
14.3 有限的资源 …… 288
14.4 标准 …… 290
14.5 敏捷组织中的ARB …… 293
14.6 结论 …… 294
第15章 聚焦核心竞争力：自建与外购 …… 296
15.1 自建与外购及可扩展性 …… 296
15.2 聚焦成本 …… 297
15.3 聚焦策略 …… 298
15.4 一切自建的现象 …… 299
15.5 合并成本与策略方法 …… 300
15.6 该组件是否会形成战略性的差异化竞争优势 …… 301
15.7 我们是这个组件或资产的最佳所有者吗 …… 302
15.8 这个组件的竞争力是什么 …… 303
15.9 我们能有效地构建这个组件吗 …… 303
15.10 最佳的购买决策 …… 304
15.11 自建失败剖析 …… 306
15.12 结论 …… 308
第16章 确定风险 …… 310
16.1 风险管理的重要性 …… 310
16.2 测量风险 …… 313
16.3 管理风险 …… 322
16.4 结论 …… 325
第17章 性能与压力测试 …… 328
17.1 执行性能测试 …… 328
17.2 不要过度强调压力测试 …… 338
17.3 可扩展性的性能和压力测试 …… 346
17.4 结论 …… 348
第18章 障碍条件与回滚 …… 351
18.1 障碍条件 …… 352
18.2 回滚能力 …… 358
18.3 服务降级：设计禁用 …… 362
18.4 结论 …… 364
第三部分 可扩展的架构方案
第19章 构建故障隔离的架构 …… 368
19.1 故障隔离架构 …… 369
19.2 故障隔离的好处 …… 371
19.3 如何进行故障隔离 …… 380
19.4 何时实施故障隔离 …… 383
19.5 如何测试故障隔离 …… 386
19.6 结论 …… 387
第20章 AKF扩展立方体介绍 …… 389
20.1 AKF扩展立方体 …… 389
20.2 扩展立方体的X轴 …… 391
20.3 扩展立方体的Y轴 …… 393
20.4 扩展立方体的Z轴 …… 396
20.5 融会贯通 …… 397
20.6 何时以及何处使用扩展立方体 …… 400
20.7 结论 …… 401
第21章 为扩展分割应用 …… 404
21.1 AKF应用扩展立方体 …… 404
21.2 AKF应用扩展立方体的X轴 …… 406
21.3 AKF应用扩展立方体的Y轴 …… 409
21.4 AKF应用扩展立方体的Z轴 …… 412
21.5 融会贯通 …… 414
21.6 应用立方体实例 …… 418
21.7 结论 …… 423
第22章 为扩展分割数据库 …… 426
22.1 在数据库上应用AKF扩展立方体 …… 426
22.2 AKF数据库扩展立方体的X轴 …… 428
22.3 AKF数据库扩展立方体的Y轴 …… 434
22.4 AKF数据库扩展立方体的Z轴 …… 436
22.5 融会贯通 …… 439
22.6 数据库扩展立方体使用案例 …… 443
22.7 结论 …… 450
第23章 为扩展而缓存 …… 452
23.1 定义缓存 …… 453
23.2 对象缓存 …… 457
23.3 应用缓存 …… 461
23.4 内容传送网络 …… 467
23.5 结论 …… 469
第24章 为扩展而异步 …… 472
24.1 对同步的共识 …… 472
24.2 同步与异步调用 …… 474
24.3 定义状态 …… 482
24.4 结论 …… 488
第四部分 其他的问题和挑战
第25章 海量数据 …… 492
25.1 数据的成本 …… 493
25.2 数据的成本价值困局 …… 496
25.3 数据产生利润 …… 498
25.4 处理大量的数据 …… 502
25.5 结论 …… 514
第26章 云计算的突飞猛进 …… 517
26.1 历史和定义 …… 518
26.2 云的特性与架构 …… 522
26.3 云和网格之间的差异 …… 528
26.4 云计算的优势和劣势 …… 530
26.5 云适用于什么样的公司 …… 540
26.6 决策过程 …… 543
26.7 结论 …… 546
第27章 云计算准备就绪 …… 550
27.1 云端的扩展立方体 …… 550
27.2 克服挑战 …… 553
27.3 Intuit案例研究 …… 559
27.4 结论 …… 561
第28章 应用监控 …… 564
28.1 为什么我们没有及早发现问题 …… 564
28.2 监控框架 …… 566
28.3 衡量监控的价值 …… 575
28.4 监控和过程 …… 576
28.5 结论 …… 578
第29章 规划数据中心 …… 581
29.1 数据中心的成本和约束 …… 581
29.2 位置、位置、位置 …… 584
29.3 数据中心和增量增长 …… 588
29.4 什么时候考虑采用IaaS …… 591
29.5 魔法三规则 …… 595
29.6 多活数据中心的考虑 …… 602
29.7 结论 …… 604
第30章 纵观全局 …… 608
30.1 现在该做什么 …… 610
30.2 可扩展性的其他资源 …… 612
中文版序一
Thank Chuck Chen for translating The Art of Scalability (2nd Edition). Here are
some quotes for the publishing of the Chinese translation:
The Art of Scalability outlines our fundamental business practice at AKF
Partners that has allowed us to help over 400 companies from startups to
Fortune 100.
You can delegate anything you would like, but you can never delegate the
accountability for results.
Management means measurement and a failure to measure is a failure to manage.
In general and at a very high level, you can think of management activities as “pushing” activities and leadership as “pulling” activities. Leadership sets a
destination and “waypoints” toward that destination; management gets you to that destination.
As your resource pool dwindles, the tendency is to favor short-term customer
facing features over longer-term scalability projects. That tendency helps meet
quarterly goals at the expense of long-term platform viability.
（感谢陈斌将《The Art of Scalability》第2版翻译成中文。下面是我送给中国读者们的几句话：
本书概述了AKF公司基本的业务实践，正是这些实践使我们得以帮助从初创公司到财富100强的400多家公司。
你可以对任何事情放权，但是绝对不会把对结果负责的事情放权。
管理意味着度量，失败的度量意味着失败的管理。
宏观地说，你可以把管理看成是“推动”活动，把领导看作是“牵引”活动。领导设定目的地和前进路径上的标记，管理让你到达目的地。
随着资源池的逐渐枯竭，企业更倾向于那些面向客户的短期功能研发，而不是长期的扩展性项目。结果是满足了短期的目标，却牺牲了平台长远的活力。）
马丁L. 阿伯特，AKF公司初始合伙人，eBay前CTO
中文版序二
这是一本难得的好书。尽管最近非常忙，我还是特别腾出了一整天的时间，一口气把本书看完了。掩卷而思，作为一个曾经在京东管理过几千人研发团队的我，收获颇多。
和一般的技术类书籍不同，本书从组织和过程入手进行阐述。这很好理解，没有好的技术团队及团队协作，不可能产生好的架构和扩展性。这也是大多数CTO容易忽略的部分。在组织上，京东研发在人数接近百的时候尝试过职能化，在人数近千的时候尝试过事业部制，最后我们还是实施了研发业务闭环。可见可扩展性组织是建立可扩展性系统的前提。
本书花了很大的篇幅论述技术管理者如何打造领导力。对于技术出身的管理者来说，领导力永远是个挑战。我个人也有一段从专家到领导者的艰难转型经历。有影响力的技术团队，一定出自一个有影响力的技术领导人。如果你想从一个技术专家转型为领导者，那本书非常值得一读。
对于互联网技术团队来说，应对过事故处理的几乎没有。所以我们要考虑如何快速从事故中恢复，以及如何从事故中学习。很多知名的宕机事件都是因为团队没有很好地管理过程，不能快速从事故中恢复，从而造成了巨大的影响和损失。对于如何管理这些人为的过程，本书进行了详细的阐述，非常值得互联网技术团队学习和实践。
可扩展性还来自于对技术架构的选择。本书对架构原则、架构委员会、架构敏捷性等内容进行了深入讨论。这些内容结合了作者多年丰富的经验，非常值得国内互联网技术同仁学习。根据我的观察，中国还缺少架构师，特别是有领导力的架构师。
所以我觉得：任何技术主管阅读此书，都受益无穷。特别是那些想做CTO的技术专家和架构师。现在中国已经实施“互联网 ”行动计划，未来所有的公司都将变成互联网公司。而如何打造可扩展的系统，将是任何平台型互联网企业的必修课。
感谢陈斌兄发现这本好书，并花了大量的精力进行翻译。希望本书能帮助中国出现更多优秀的CTO，希望中国有更多可扩展的互联网平台一起助力中国“互联网 ”！
李大学，磁云科技CEO，中国互联网＋实战团发起人，
京东终身荣誉技术顾问
中文版序三
在“大众创业、万众创新”的年代，许多青年俊才施展抱负，勇敢投入到波涛汹涌的市场竞争大潮中。在此过程中，企业在快速发展的同时会遇到组织发展的瓶颈问题。
当下，许多历史悠久的知名国企正经历扩张、兼并、重组等重大转型。那么如何通过技术手段解决组织扩张、扩展中新兴的快速发展企业及传统的国有企业改组、改造中遇到的各类相关问题？
本书从企业技术人员的角度给我们提供了一个解决方案和工作思路。我多年的工作体验是，企业管理人员与企业技术人员看企业的角度和得出的结论是完全不同的。企业的管理者应该认真倾听技术人员的心声。特别是那些善于跟“机器”和“数据”打交道的工程师，当他们也开始强调“人”的因素时，传统的企业管理者的压力顿时就增加了许多。
我强烈推荐从事企业管理的经理人阅读此书。
唐毅，中国技术进出口总公司总裁
中文版序四
本书是IT界的传奇著作，尤其第2版紧跟时代发展大潮做了关键的更新，很荣幸，本书第2版由我的同事和老朋友，现任易宝集团CTO的陈斌翻译，并由我们的亲密合作伙伴机械工业出版社出版。
12年前，我和陈斌相识于硅谷，也见证了他在技术领域的一路狂飙挺进。他最初在新加坡航空开发过订票系统，1999年到了硅谷，先在CharitableWay开发过互联网捐款系统，后来历任日立（美国）技术集成总监、Abacus首席架构师，是硅谷一等一的技术高手。
那时，唐彬和我已经打算回国创业了，我们三个人在老唐的屋子里一边吃烧烤一边讨论未来公司的构想。2003年“非典”期间，易宝支付在北京创立，创业初期陈斌还在硅谷帮我们张罗面试、找融资。之后易宝支付成为中国行业支付的开创者和领导者，随后以支付为切入，推动了中国航空旅游、快消连锁、游戏、教育、保险基金、互联网金融等行业的电子化进程，如今又在推动各个行业的移动化进程。
刚开始时，陈斌没有加入易宝，但参与了我们早期的创业过程。2005年我们终于把他“挖”到了易宝，由他负责技术和运营，易宝第二代支付系统就是他领导开发的。
因为当时陈斌的孩子还太小，所以2007年他又回到硅谷，出任诺基亚（美国）首席工程师。2008年他加入了eBay集团，成为eBay负责移动的高级架构师。这也成为他和本书作者结缘的奇妙渊源，因为当时马丁和迈克尔恰巧就分别是eBay的CTO与PayPal的架构师。
eBay从一家小公司起步，发展成为一个拥有数万员工举世瞩目的电商巨头，马丁和迈克尔也随同经历了人员、技术、组织、管理的扩展历程，对于可扩展性具有最直接和最宝贵的实战经验。而作者在书中提出的思路、举出的实例，陈斌在eBay都亲身体会过。
央视在2014年推出了大型纪录片《互联网时代》，这是自互联网诞生以来，全球首部反映互联网全貌的大型纪录片，整个拍摄过程历时两年多，作为《互联网时代》的学术顾问，我随拍摄组数次赴美拍摄，每次到硅谷都要找陈斌一聚。我劝他回易宝，投身国内蒸蒸日上的互联网金融行业，当然，也希望他把硅谷的先进技术理念带入易宝。
2014年陈斌终于正式重回易宝，出任CTO，一回来就展现出雄心壮志，开始大刀阔斧地改革。
首先，他主导了原有系统的逐步拆分与迁出，保证交易的安全和稳定，使系统可用性得到极大提升。其次，他提拔了五位年轻有为的架构师，分别负责信息安全、运维、数据、应用、平台研发的架构，极大加强了易宝技术部门的架构意识。最后，他提出“大、平、移、活”战略（大数据、云平台、移动化、双活数据中心），且基于对大数据的重视，推动了征信事业部的成立。他担任CTO的这一年多时间，易宝在技术层面和运维层面都获得了极其健康的发展。
这些技术方面的有力举措，都坚实有力地支持了易宝近两年引领互联网金融和移动互联网大潮的高速发展。
历经诺基亚、eBay、易宝等公司，历任工程师、首席工程师、首席架构师、CTO等职位，陈斌在架构艺术上深有心得，是少有的拥有硅谷经验和中国创业经验的技术大拿。其实撰写一部关于架构思维的书是他的夙愿，因为他发现国内的程序员往往只顾埋头干活，却忽视了高屋建瓴的架构思维，又或者只有直觉性的架构意识，却缺乏科学系统的架构训练。本书作者和陈斌渊源颇深，恰逢第2版做出比较大的关键调整，陈斌不辞辛劳，欣然亲自操刀翻译。
从2015年7月拿到本书开始，他投入了几乎全部的业余精力。不仅在公司、在家里，甚至在高铁上、飞机上、大巴上，他都在字斟句酌地翻译。他牺牲了晚上休憩的时间、周末娱乐的时间，废寝忘食地投入本书的翻译中。要知道，准确翻译传达一本横亘技术和商业的伟大巨著需要有巨大的耐心与深刻的洞察力，只有这样才能用中文传神地把英文原著的精髓传递出来。
最早讨论本书的中文版书名时，我们有同事提出了一个书名—《通向规模化之路》。出于忠于原著的考虑，这个书名最终并未采纳，但传神地道出一个事实，今天的互联网发展进入了深水区，企业想要不被时代大潮淘汰，实现持续增长甚至是指数级增长，就必须越来越重视互联网，重视技术。这在我和宗毅发起“互联网大篷车”公益活动，到全国各地推动传统企业“互联网 ”的转型时已经深刻感受到。企业的高层要越来越重视互联网和商业的深度融合，早早做好IT的大布局，让IT架构可扩展、可升级，先于企业商业战略做好布局，才是未来有竞争力企业规模化成长的正道。
余晨，易宝支付高级副总裁及联合创始人，《看见未来》作者
本书深入浅出地介绍了大型互联网平台的技术架构，并从多个角度详尽地分析了互联网企业的架构理论和实践，是架构师和CTO不可多得的实战手册。
——唐彬，易宝支付CEO及联合创始人
互联网金融千人会轮值主席
互联网技术正急速地扩大着商业边界。其中，软件系统的可扩展性将成为公司是否可以升级涅槃的关键问题。本书的译者敏感地关注到了这个问题，翻译了这本书，相信可激发中国新经济管理者、从业者的思考和讨论。
——涂子沛，*副总裁，互联网 专家
《大数据》、《数据之巅》作者
本书作者拥有丰富的架构、管理和领导经验，成功解决了许多eBay在快速发展过程中遇到的问题和挑战。本书中文译本的出版必将把硅谷的成熟架构设计和技术管理经验传播到中国，为互联网 助力。
——叶亚明，携程集团CTO
本书更具价值的部分是阐述了人才、管理、流程、组织架构对高可用性系统及产品的影响。
——高遵明，唯品会CTO
在中国互联网行业迅速发展的今天，我相信所有快速发展的企业都会面临同样的挑战，那么别犹豫，请打开这本书读一读吧，相信你会和我一样感到惊喜！
——段念，宜信宜人贷CTO
从本书中学习可扩展性，是要从一个个案例中学习如何思考，而不仅仅是学习它的手段。
——祁宁，SegmentFault创始人兼CTO
本书基于两位作者长期的观察和实践，深入讨论了人员能力、组织形态、流程和软件系统架构对业务扩展性的影响，并提出了组织与架构转型的参考模型和路线图。
——赵先明，中兴通讯股份有限公司CTO
每家快速成长的公司都需要不断突破自身系统架构的扩展性约束，本书提供了大量翔实且系统的案例和工具，将帮助你把公司设计得更好。
——吴华鹏，iTech Club理事长
1024学院院长，原凤凰网CTO
本书从过程、人员、性能和技术等多角度出发，创造性地解决扩展性难题，不同阶段的系统及不同规模的公司，都能得到非常到位的指导。
——曹重英，IT高管会负责人
评论
还没有评论。