出版社: 机械工业出版社
副标题: 现代企业可扩展的 Web 架构、流程和组织
原作名: The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise,Second Edition
译者: 陈斌
出版年: 2016-4
页数: 660
定价: 99.00元
装帧: 平装
丛书: 架构师书库
ISBN: 9787111532644
内容简介 · · · · · ·
任何一个持续成长的公司最终都需要解决系统、组织和流程的扩展性问题。本书汇聚了作者从eBay、VISA、Salesforce.com到Apple超过30年的丰富经验, 全面阐释了经过验证的信息技术扩展方法,对所需要掌握的产品和服务的平滑扩展做了详尽的论述,并在第1版的基础上更新了扩展的策略、技术和案例。
针对技术和非技术的决策者,马丁•阿伯特和迈克尔•费舍尔详尽地介绍了影响扩展性的各个方面,包括架构、过程、组织和技术。通过阅读本书,你可以学习到以最大化敏捷性和扩展性来优化组织机构的新策略,以及对云计算(IaaS/PaaS)、NoSQL、DevOps和业务指标等的新见解。而且利用其中的工具和建议,你可以系统化地清除扩展性道路上的障碍,在技术和业务上取得前所未有的成功。
作者简介 · · · · · ·
作者:
马丁∙阿伯特(Martin L. Abbott) AKF公司的初创合伙人,曾任Quigo(广告技术初创公司,后来被AOL收购)的首席运营官,负责领导产品策略、产品管理、技术研发和客户服务。他在eBay工作了6年,先后担任技术副总裁、首席技术官和公司高管。
迈克∙费舍尔(Michael T. Fisher )AKF公司的初创合伙人,曾任Quigo首席技术官,PayPal负责工程和架构的副总裁。他花了7年时间帮助通用电气公司(GE)形成了技术战略,获得过6西格玛黑带的荣誉,还在美军担任过上尉和飞行员。
译者:
陈斌(Chuck Chen)现任易宝CTO。1989年获得吉林大学硕士学位,1992年任新加坡航空公司高级系统分析师;1999年投身于硅谷互联网技术发展浪潮,曾任日立美国系统集成总监,Abacus首席架构师和Nokia美国首席工程师;200...
作者:
马丁∙阿伯特(Martin L. Abbott) AKF公司的初创合伙人,曾任Quigo(广告技术初创公司,后来被AOL收购)的首席运营官,负责领导产品策略、产品管理、技术研发和客户服务。他在eBay工作了6年,先后担任技术副总裁、首席技术官和公司高管。
迈克∙费舍尔(Michael T. Fisher )AKF公司的初创合伙人,曾任Quigo首席技术官,PayPal负责工程和架构的副总裁。他花了7年时间帮助通用电气公司(GE)形成了技术战略,获得过6西格玛黑带的荣誉,还在美军担任过上尉和飞行员。
译者:
陈斌(Chuck Chen)现任易宝CTO。1989年获得吉林大学硕士学位,1992年任新加坡航空公司高级系统分析师;1999年投身于硅谷互联网技术发展浪潮,曾任日立美国系统集成总监,Abacus首席架构师和Nokia美国首席工程师;2008年任eBay资深架构师,负责移动应用的架构设计。丰富的海外经历,多年的架构经验,深谙移动互联网对传统行业的影响;2014年再次投身易宝,提出大、平、移、商的战略方针,全力推动移动互联网技术,引领行业变革。
目录 · · · · · ·
本书赞誉
中文版序一
中文版序二
中文版序三
中文版序四
译者序
序
前言
作者简介
第一部分 可扩展性组织的人员配置
第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
· · · · · · (收起)
原文摘录 · · · · · · ( 全部 )
-
我们假设经理应负的基本职责包括以下三点:确保给工程师分配了项目,无论是自己分配的,还是根据管理层指示分配的;确保执行了行政工作,如解决了薪资问题或者传达了人事信息等;以及接收项目的状态更新信息,以便报告给高级管理层。考虑到这种基础水平的管理职责,一个新近从工程师升到管理层的初级经理可能会发现,即使只管理 6 个人的团队,行政工作和项目管理的工作都会耗费她一整天的时间。... 比起那些做过一遍又一遍的工作来说,新工作通常需要花费更多时间,而且要求更加专注。在决定一个团队的最佳规模时,经验水平是一个要考虑的关键因素。 一般来说,业务责任人和产品经理都想建立更多更大的面向客户的项目,这样他们才能不停地击败竞争对手,扩大收益来源,拓展客户基础。这时团队规模过小会带来两个主要问题。首先,根据所采用的产品开发生命周期方法不同,较大的项目需要更多的迭代或更长的开发时间。... 其次,如果增加了工程师数量,那么支持人员的数量也随之增加,包括经理的人数。 工程师天生会对自己能够完成的工作保持过分乐观的态度,如果他们推脱过去能够完成的工作量,这会是一个明显的信号,说明他们自觉生产力下降了。 比这个难得多的是在团队规模过大时,拆分团队。如果团队拆分不当,会造成可怕的后果,如代码的所有权不清楚、更难以沟通、重新适应新经理而工作压力增大。... 首先需要关注的是代码或工作,我们将在第三部分详细地讨论故障域这个概念,这些域通过隔离服务,从而限制了故障的影响范围,也许拆分团队是个把代码拆分到故障域的好机会。 (查看原文) —— 引自章节:团队规模 -
现代的云概念在2001年10月被IBM在“自主计算宣言”中得到延伸,这篇论文的实质是说信息技术基础设施变得过于复杂,如果不能实现自动化管理,它可能会被自己的重量所压垮。 (查看原文) —— 引自第520页
> 全部原文摘录
丛书信息
· · · · · ·
喜欢读"架构即未来"的人也喜欢的电子书 · · · · · ·
喜欢读"架构即未来"的人也喜欢 · · · · · ·
架构即未来的书评 · · · · · · ( 全部 7 条 )

xyz适用于我们的工作平时当中

架构即未来:现代企业可扩展的Web架构、流程和组织(原书第2版)
> 更多书评 7篇
论坛 · · · · · ·
为什么书名翻译为架构即未来? | 来自heading | 6 回应 | 2022-07-13 07:21:18 |
这本书的其他版本 · · · · · · ( 全部4 )
-
Addison-Wesley Professional (2009)7.4分 14人读过
-
人民邮电出版社 (2013)7.0分 20人读过
-
Addison-Wesley (2015)暂无评分 3人读过
以下书单推荐 · · · · · · ( 全部 )
- 闲着没事读读书(四) (鹿小羽)
- 豆瓣管理学领域高分书单初筛 (Eisen)
- 后端程序员成长阅读书目 (YigWoo)
- 书单 | 回牛 | 书架所有 (回牛)
- 架构师之路 (仰望星空)
谁读这本书? · · · · · ·
二手市场
· · · · · ·
订阅关于架构即未来的评论:
feed: rss 2.0
0 有用 char 2020-03-25 08:08:07
Day 84 不能接受后几章技术的写法和前面流程、组织的写法一致。冗长 #百日早起学习挑战#
2 有用 Vicking 2016-10-20 23:09:53
对于小白阅读者不知道该如何打分,至少举例还是很生动,不懂技术的产品经理不是好产品,扫一眼,了解个大概
0 有用 常典尔竹箱 2020-05-13 11:06:31
真·高维度看事物,我需要好好再看看
1 有用 Siberiarun 2020-11-13 23:25:03
开头几章还挺不错,后面有些又大又空,领导不等于管理
0 有用 啊花 2023-01-12 11:14:51 浙江
五六年前读过,最近又翻了翻,仍然感觉很不错,书比较泛,但很多内容具有启发性。从组织、领导力、流程、风险管理开始讲架构,这些非技术的东西可能恰恰是架构设计和落地的关键。原书书名「可扩展性的艺术」可能更贴切一点。