架构即未来：现代企业可扩展的Web架构、流程和组织(原书第2版) 下载 pdf 百度网盘 epub 免费 2025 电子书 mobi 在线

本书覆盖下述内容：

?为什么扩展性的问题始于组织和人员，而不是技术，为此我们应该做些什么？

?从实践中取得的可以付诸于行动的真实的成功经验和失败教训。

?为敏捷、可扩展的组织配备人员、优化组织和加强领导。

?对处在高速增长环境中的公司，如何使其过程得到有效的扩展？

?扩展的架构设计：包括15个架构原则在内的独门绝技，可以满足扩展的方案实施和决策需求。

?新技术所带来的挑战：数据成本、数据中心规划、云计算的演变和从客户角度出发的监控。

?如何度量可用性、容量、负载及性能。

本书赞誉

中文版序一

中文版序二

中文版序三

中文版序四

译者序

序

前言

作者简介

部分　可扩展性组织的人员配置

第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　我们是这个组件或资

作者：

马丁∙阿伯特（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年再次投身易宝，提出大、平、移、商的战略方针，全力推动移动互联网技术，引领行业变革。

暂无出版社相关信息，正在全力查找中！

暂无相关书籍摘录，正在全力查找中！

在线阅读地址：架构即未来：现代企业可扩展的Web架构、流程和组织(原书第2版)在线阅读

在线听书地址：架构即未来：现代企业可扩展的Web架构、流程和组织(原书第2版)在线收听

在线购买地址：架构即未来：现代企业可扩展的Web架构、流程和组织(原书第2版)在线购买

我们假设经理应负的基本职责包括以下三点：确保给工程师分配了项目，无论是自己分配的，还是根据管理层指示分配的；确保执行了行政工作，如解决了薪资问题或者传达了人事信息等；以及接收项目的状态更新信息，以便报告给高级管理层。考虑到这种基础水平的管理职责，一个新近从工程师升到管理层的初级经理可能会发现，即使只管理 6 个人的团队，行政工作和项目管理的工作都会耗费她一整天的时间。... 比起那些做过一遍又一遍的工作来说，新工作通常需要花费更多时间，而且要求更加专注。在决定一个团队的最佳规模时，经验水平是一个要考虑的关键因素。

一般来说，业务责任人和产品经理都想建立更多更大的面向客户的项目，这样他们才能不停地击败竞争对手，扩大收益来源，拓展客户基础。这时团队规模过小会带来两个主要问题。首先，根据所采用的产品开发生命周期方法不同，较大的项目需要更多的迭代或更长的开发时间。... 其次，如果增加了工程师数量，那么支持人员的数量也随之增加，包括经理的人数。

工程师天生会对自己能够完成的工作保持过分乐观的态度，如果他们推脱过去能够完成的工作量，这会是一个明显的信号，说明他们自觉生产力下降了。

比这个难得多的是在团队规模过大时，拆分团队。如果团队拆分不当，会造成可怕的后果，如代码的所有权不清楚、更难以沟通、重新适应新经理而工作压力增大。... 首先需要关注的是代码或工作，我们将在第三部分详细地讨论故障域这个概念，这些域通过隔离服务，从而限制了故障的影响范围，也许拆分团队是个把代码拆分到故障域的好机会。

现代的云概念在2001年10月被IBM在“自主计算宣言”中得到延伸，这篇论文的实质是说信息技术基础设施变得过于复杂，如果不能实现自动化管理，它可能会被自己的重量所压垮。

组织设计和架构中的另一个要点是，一旦确定了组织或团队的边界，组织或团队的冲突就会随之而来。

JAD （联合架构设计）流程的最后一步是决定是否需要把功能提交给 ARB（架构评审委员会），进行最后的审查和批准。... 如果该功能满足下列任何一项，就应该提交给 ARB。

1) 与架构设计原则不符。

2) 就设计达不成共识。

3) 做过重大的权衡决策。

4) 高风险的功能。

集群（Cluster）和群组（Pools）有时交替使用，特别是当有一个共享的回话或状态概念时，但有时用来指主备配置的高可用性解决方案。群组（Pools）最经常被引用指一组执行类似任务的服务器。

原子性是数据库管理系统的一个特性，它保证执行交易的所有任务，否则回滚整个任务，不会因为硬件或软件的故障而造成交易部分完成。

一致性是保证交易前后数据库状态稳定的特性。如果事务处理成功，数据库将会从一个状态转移到另一个状态，并保持规则一致。

隔离性是当数据正在被一个事务处理的过程中，防止另外的事务同时访问它的属性。大多数的数据库管理系统使用锁来保证隔离。

耐久性是在系统标记记录的状态为成功后，继续维持这个状态而不被回滚的特性。所有的一致性检查必须在事务被认为完成之前通过相应的验证。

编辑推荐

任何一个持续成长的公司 终都需要解决系统、组织和流程的扩展性问题。本书汇聚了作者从eBay、VISA、Salesforce.com到Apple超过30年的丰富经验， 全面阐释了经过验证的信息技术扩展方法，对所需要掌握的产品和服务的平滑扩展做了详尽的论述，并在第1版的基础上更新了扩展的策略、技术和案例。 针对技术和非技术的决策者，马丁?阿伯特和迈克尔?费舍尔详尽地介绍了影响扩展性的各个方面，包括架构、过程、组织和技术。通过阅读本书，你可以学习到以 化敏捷性和扩展性来优化组织机构的新策略，以及对云计算（IaaS/PaaS）、NoSQL、DevOps和业务指标等的新见解。而且利用其中的工具和建议，你可以系统化地清除扩展性道路上的障碍，在技术和业务上取得前所未有的成功。

前言

感谢你阅读本书。本书获得了学术界和专业界的认可，是目前学习系统和组织扩展艺术 好的资源之一。本书在第1版的基础上对部分内容进行了修订和更新，并且增加了新内容。作为数百家快速成长公司的顾问，我们非常幸运有机会站在许多行业变革的 前线，为开发产品引入新技术和新方法。尽管我们希望客户能体会到我们的知识和经验的价值，但并不否认这些价值中的一大部分来自于我们和那些技术公司之间就某个主题而产生的互动。在本书中，我们会更多地分享在顾问实践的过程中学到的经验和吸取的教训。

第2版增加了几个关键话题，我们认为讨论这几个话题对本书十分重要。其中一个 为重要的新话题聚焦在称为敏捷组织的新型结构上。其他值得注意的话题包括把数据中心转移到云端（IaaS/PaaS）的决策根据，为什么NoSQL解决方案不流行，而且不是解决可扩展性问题的灵丹妙药，业务指标对系统整体健康的重要性。

在本书第1版中，我们使用了一个名叫AllScale的虚拟公司，以它为基础，讲解了许多概念。这一虚拟公司实际上集合了现实中的许多客户和他们曾经历的各种挑战。尽管AllScale对第1版讲解关键点起了很大的作用，但是我们相信真实的故事对读者会有更大的影响。因此，我们将在这一版中用现实世界中成功和失败的真实故事取代AllScale。

本书所含信息经过精心设计，适合任何一个负责提供技术解决方案的组织或公司中的所有员工、经理或执行人员阅读。对非技术类的执行人员或产品经理，本书可以帮助你学会使用工具来提出合理的问题，正确聚焦，从而避免扩展性的灾难。对科技人员和工程师，一旦实施本书所提供的模型与方法，将有助于扩展产品、流程和机构。

我们在扩展性方面的经验超越了学术研究的范畴。尽管我们都是受过正式训练的工程师，但是我们不相信学术课程会系统讲解可扩展性的相关知识。相反，30多年来解决系统扩展性问题所积累的经验，让我们有机会学习系统的扩展性。我们曾经在不同的公司做过工程师、经理、高管和顾问，这些公司既包括初创期的小公司，也包括财富500强中的大公司。我们的公司或者曾经工作过的公司包括通用电气、Motorola、Gateway、eBay、Intuit、Salesforce、苹果、戴尔、沃尔玛、威士卡、ServiceNow、DreamWorks Animation、LinkedIn、Carbonite、Shutterfly和PayPal这些耳熟能详的名字。这份名单也包括了数以百计不那么出名但是需要系统能随着业务的增长扩展的初创公司。我们曾经耗费数千小时来定位问题，耗费上千小时来设计那些可以防范问题发生的机制。从这些经历中，我们学到了扩展性，所以想把学到的知识综合起来分享给大家。这一动机促使我们决定开始咨询实践，并在2007年成立了AKF公司，同时也促成我们写了本书第1版，也正是这一卓越的目标引导我们完成了本书第2版。

可扩展性：不仅仅是技术那么简单

飞行员是这样被教导的，统计数字也是这样显示的，许多飞机的事故都是多重失灵，像滚雪球一样叠加发生，从而造成整体系统的失灵和灾难。在航空界，这些称为错误链的多重失灵，经常是人为的失误而非机械故障。事实上，波音公司研究了1995年到2005年所有相关的飞行事故，发现其中55%的事故与人为因素相关。

根据我们的经验，与扩展性相关的事故也遵循着同一规律。首席技术官（CTO）或者负责系统平台扩展性的高管也许把扩展性当成一个纯技术性的计划。这种理解纯粹是人为的失败，也是错误链上的个失败点。因为CTO过于聚焦技术，所以他没能清楚地定义必要的流程，以确定扩展性的瓶颈，这是第二个失败点。因为没有人在架构上寻找和定位瓶颈点与堵塞处，所以当用户数或者交易笔数超过某个限额的时候，整个系统就会出现故障，这是第三个失败点。当团队集合起来想要解决问题时，由于从来没有在事故排查以及问题定位的流程上进入投入，以致团队错误地把问题定位成“数据库调优”，这是第四个失败点。恶性循环一直在持续，由于各自聚焦在不同的技术方面，大家相互指责，从防火墙到应用，再到应用相关的会话保持层。团队的交互退化成叫喊比赛和指责大会，而服务却依然缓慢和迟钝，结果是客户流失、团队沮丧、股东撤资。

尽管危机源于系统无法迅速扩展来满足 终用户的需要，但是问题的根源几乎从来不只是单纯的技术问题。以我们作为高管和客户顾问的经验，扩展性问题始于组织和人员，然后扩散到过程和技术。在系统实施的过程中，如果人收到了错误的信息或者做了错误的选择，有时会进一步显现为失败点，进而影响到系统和平台的可扩展性。人们忽略了制定可以帮助他们从以往的错误中吸取教训的过程，有时候却制定和发布一些拖后腿的过程，其结果不是迫使组织做出错误决策，就是决策做得太迟而效果不彰。缺乏对制订和支持技术决策的过程和人员的关注，往往会导致不良技术决策的恶性循环，图0-1对此作了解释。

图0-1　恶性循环和良性循环

艺术与科学

本书书名中选择“艺术”一词是经过深思熟虑的。“艺术”让人联想到一幅动态的自然画卷，而“科学”却似乎更加结构化和静态。科学和经验告诉我们，对一个平台、组织和流程而言

书籍介绍

任何一个持续成长的公司最终都需要解决系统、组织和流程的扩展性问题。本书汇聚了作者从eBay、VISA、Salesforce.com到Apple超过30年的丰富经验， 全面阐释了经过验证的信息技术扩展方法，对所需要掌握的产品和服务的平滑扩展做了详尽的论述，并在第1版的基础上更新了扩展的策略、技术和案例。

针对技术和非技术的决策者，马丁•阿伯特和迈克尔•费舍尔详尽地介绍了影响扩展性的各个方面，包括架构、过程、组织和技术。通过阅读本书，你可以学习到以最大化敏捷性和扩展性来优化组织机构的新策略，以及对云计算（IaaS/PaaS）、NoSQL、DevOps和业务指标等的新见解。而且利用其中的工具和建议，你可以系统化地清除扩展性道路上的障碍，在技术和业务上取得前所未有的成功。