內容介紹
任何持續發展的公司，最終都需要考慮如何擴展它的系統、組織和流程。這不僅僅是技術問題，還涉及組織、流程、架構等方方面面。擴展組織、流程和系統使之相互支持，達到良性循環，也不僅僅是門科學，還是一門藝術。Martin L.Abbott、Michael T.Fisher編著的《可擴展的藝術(現代企業的Web架構流程及組織)》正是對此提供了全面的、實踐證明確實有效的解決思路和實用技巧。對於負責非技術類業務的執行主管或產品經理來說，《可擴展的藝術(現代企業的Web架構流程及組織)》會幫助你明確地提出正確的可擴展性問題，分析並做出正確的決策。而對於技術主管和工程師來說，本書會幫助你解決對擴展造成負面影響的組織和流程方面的問題，並為構建具有更高可擴展性的平台提供了技術模型和建議。
作者介紹
Martin L.Abbott擴展諮詢公司AKF Partners的創始合伙人之一。在此之前，他是Quigo公司的COO，負責產品戰略、產品管理、技術開發和客戶服務。在Quigo之前，他在eBay工作了將近六年，最後的職位是技術部的SVP、CTO和執行主管團隊成員。更早之前，他在Gateway和摩托羅拉擔任過程式設計師、管理者及執行主管。他現任onForce、LodgeNet Interactive（NASD: LNET）以及Bullhorn的董事會成員。此外，他還在Rearden Commerce、Goldmail和LiveOps擔任諮詢委員會的成員。在西點軍校取得計算機科學的學士學位後，他在佛羅里達大學取得了計算機工程的碩士學位，並參加過哈佛商學院的高級經理培訓課程，現正在美國凱斯西儲大學攻讀管理學的博士學位。
Michael T. Fisher
擴展諮詢公司AKF Partners的創始合伙人之一。他曾在Quigo擔任了兩年的CTO，在Quigo被AOL收購後的過渡期，還擔任過這家公司的總裁。在Quigo之前，他是PayPal公司（eBay旗下公司之一）的開發和架構副總裁，負責建立一個有兩百多位工程師的組織。更早之前，他在通用電氣工作過七年，致力於開發公司的技術戰略和流程。在西點軍校取得了計算機科學的學士學位後，他在夏威夷太平洋大學取得了碩士學位，後在甘迺迪西部大學取得了信息管理系統的博士學位，在美國凱斯西儲大學獲得了MBA。此外，他還是六西格瑪黑帶大師，現正在美國凱斯西儲大學攻讀管理學的博士學位。
作品目錄
目 錄導言1
第一部分 可擴展組織的人員配備
第1章 人員和領導力對可擴展性的影響6
1.1 AllScale簡介6
1.2 為什麼要考慮人員7
1.3 為什麼要考慮組織8
1.4 為什麼要考慮管理和領導力12
1.5 結論14
本章要點14
第2章 可擴展技術組織中的角色15
2.1 失敗的後果15
2.2 角色的定義16
2.3 執行主管的職責17
2.3.1 CEO18
2.3.2 CFO19
2.3.3 業務單元責任人和P&L責任人19
2.3.4 CTO/CIO19
2.4 組織的職責20
2.4.1 架構團隊的職責21
2.4.2 軟體開發團隊的職責21
2.4.3 生產運營團隊的職責21
2.4.4 基礎設施團隊的職責22
2.4.5 質量保證團隊的職責22
2.4.6 產能計畫團隊的職責22
2.5 個人貢獻者的職責和特徵23
2.5.1 架構師23
2.5.2 軟體工程師23
2.5.3 操作員24
2.5.4 基礎設施工程師24
2.5.5 QA工程師/分析師24
2.5.6 產能計畫員25
2.6 一個組織示例25
2.7 定義職責的工具26
2.8 結論28
本章要點29
第3章 設計組織30
3.1 影響可擴展性的組織因素30
3.2 團隊規模32
3.2.1 警示信號35
3.2.2 擴大團隊或拆分團隊36
3.3 組織架構38
3.3.1 職能型組織38
3.3.2 矩陣型組織40
3.4 結論42
本章要點43
第4章 領導力10144
4.1 什麼是領導力45
4.2 領導力的一個概念模型46
4.3 評估你是誰47
4.4 身先士卒49
4.5 保持謙虛的態度49
4.6 使命第一，人員至上50
4.7 做出及時、合理、符合道德的決策51
4.8 給團隊授能和可擴展性51
4.9 一切圍繞股東價值52
4.10 願景53
4.11 使命55
4.12 戰略目標55
4.13 整合願景、使命和戰略目標57
4.14 通向成功的因果圖59
4.15 結論61
本章要點61
第5章 管理10163
5.1 管理是什麼63
5.2 項目和任務管理64
5.3 建設團隊——一個運動比喻65
5.4 提升團隊——一個花園比喻66
5.5 衡量方法、指標和目標評估69
5.6 目標樹71
5.7 為成功鋪路72
5.8 結論72
本章要點73
第6章 進行商業論證74
6.1 理解經驗的鴻溝74
6.1.1 為什麼業務主管可能成為問題所在75
6.1.2 為什麼技術主管可能成為問題所在75
6.2 破除企業思維定式76
6.2.1 建立關係78
6.2.2 樹立榜樣78
6.2.3 培訓其他主管78
6.2.4 利用RASCI模型79
6.2.5 用商業語言交談79
6.2.6 讓他們參與進來79
6.2.7 用事實讓主管團隊感到恐慌80
6.3 為擴展論證80
6.4 結論83
本章要點83
第二部分 制定擴展流程
第7章 理解流程對擴展的重要性86
7.1 流程的目的87
7.2 正確的時間，正確的流程89
7.2.1 需要有多嚴苛90
7.2.2 需要有多複雜91
7.3 好的流程何時會變成壞的93
7.4 結論93
本章要點94
第8章 管理故障和問題95
8.1 什麼是故障96
8.2 什麼是問題96
8.3 故障管理的步驟97
8.4 問題管理的步驟99
8.5 化解故障管理與問題管理之間的衝突100
8.6 故障和問題的生命周期100
8.7 召開每日故障例會101
8.8 召開季度故障回顧會議102
8.9 事後分析流程102
8.10 綜合套用104
8.11 結論106
本章要點106
第9章 管理危機和升級107
9.1 什麼是危機107
9.2 為什麼要把危機與其他故障區分開來108
9.3 危機如何改變一個公司108
9.4 為混亂賦予秩序109
9.4.1“問題經理”的角色110
9.4.2 團隊經理的角色111
9.4.3 首席工程師的角色112
9.4.4 個人貢獻者的角色113
9.5 溝通和控制113
9.6 作戰室114
9.7 升級115
9.8 狀態溝通115
9.9 危機事後分析會議116
9.10 危機後續跟進和溝通117
9.11 結論117
本章要點118
第10章 控制生產環境中的變更119
10.1 什麼是變更120
10.2 變更識別121
10.3 變更管理122
10.3.1 變更建議123
10.3.2 變更批准125
10.3.3 變更日程安排125
10.3.4 變更實施和記錄127
10.3.5 變更驗證127
10.3.6 變更審查127
10.4 變更控制會議128
10.5 持續的流程改善128
10.6 結論129
本章要點129
第11章 確定套用的餘量131
11.1 流程的目的131
11.2 流程的步驟132
11.3 理想的使用比例135
11.4 結論137
本章要點138
第12章 探討架構設計原則139
12.1 原則和目標139
12.2 原則選擇142
12.3 AKF的十二條架構設計原則143
12.3.1 N+1設計143
12.3.2 設計為能夠回退的144
12.3.3 設計為能夠禁用的144
12.3.4 設計為能夠監控的144
12.3.5 設計為多個活動站點144
12.3.6 採用成熟的技術144
12.3.7 設計為異步的145
12.3.8 無狀態系統145
12.3.9 進行橫向擴展而不是縱向擴展145
12.3.10 設計為至少可以在兩條軸上進行擴展145
12.3.11 非核心的組件可以購買145
12.3.12 採用同質化硬體145
12.4 擴展原則深度解析146
12.4.1 設計為能夠監控的146
12.4.2 設計為多個活動站點147
12.4.3 設計為異步的147
12.4.4 無狀態系統148
12.4.5 進行橫向擴展而不是縱向擴展148
12.4.6 設計為至少可以在兩條軸上進行擴展149
12.5 結論150
本章要點150
第13章 聯合架構設計151
13.1 修正組織的功能障礙151
13.2 設計為能夠跨部門擴展153
13.3 開始條件和結束條件155
13.4 結論157
本章要點157
第14章 架構評審委員會159
14.1 通過審查確保可擴展性159
14.2 委員會成員160
14.3 會議實施162
14.4 開始條件和結束條件164
14.5 結論165
本章要點166
第15章 關注核心競爭力：構建還是 採購167
15.1 構建還是採購與可擴展性的關係167
15.2 關注成本168
15.3 關注競爭優勢168
15.4“非我所建”現象169
15.5 結合成本和競爭優勢170
15.5.1 這個組件能夠創造競爭優勢嗎？170
15.5.2 我們是這個組件或資產最好的責任人嗎？171
15.5.3 這個組件上的競爭如何？171
15.5.4 我們能經濟有效地構建這個組件嗎？171
15.6 AllScale公司的構建還是採購難題172
15.7 結論173
本章要點174
第16章 確定風險175
16.1 風險管理對擴展的重要性175
16.2 衡量風險176
16.3 管理風險181
16.4 結論183
本章要點184
第17章 性能測試和壓力測試185
17.1 執行性能測試185
17.1.1 判斷標準186
17.1.2 測試環境186
17.1.3 定義測試187
17.1.4 執行測試188
17.1.5 分析數據188
17.1.6 報告給工程師189
17.1.7 重複測試和分析189
17.2 壓力測試不要有壓力190
17.2.1 確立目標190
17.2.2 識別關鍵服務191
17.2.3 確定負載191
17.2.4 測試環境192
17.2.5 識別監控項192
17.2.6 製造負載192
17.2.7 執行測試193
17.2.8 分析數據193
17.3 可擴展性的性能測試和壓力測試194
17.4 結論195
本章要點196
第18章 屏障條件和回退197
18.1 屏障條件197
18.1.1 屏障條件和敏捷開發198
18.1.2 屏障條件和瀑布開發200
18.1.3 屏障條件和混合模型200
18.2 回退能力201
18.2.1 回退視窗需求201
18.2.2 回退的技術考量202
18.2.3 回退的成本考量203
18.3 功能減負——設計為能夠禁用的203
18.4 結論204
本章要點205
第19章 要快還是要正確206
19.1 業務上的權衡206
19.2 與可擴展性的關係209
19.3 如何做決策210
19.4 結論213
本章要點214
第三部分 構建可擴展的方案
第20章 不受技術限制的設計216
20.1 實現並非架構216
20.2 不受技術限制的設計217
20.2.1 TAD和成本217
20.2.2 TAD和風險218
20.2.3 TAD和可擴展性219
20.2.4 TAD和可用性221
20.3 TAD方法221
20.4 結論222
本章要點222
第21章 創建故障隔離的架構224
21.1 故障隔離的架構的術語224
21.2 故障隔離的好處226
21.2.1 故障隔離和可用性——限制影響226
21.2.2 故障隔離和可用性——故障檢測和解決228
21.2.3 故障隔離和可擴展性228
21.2.4 故障隔離和上市時間229
21.2.5 故障隔離和成本229
21.3 如何進行故障隔離230
21.3.1 原則1：什麼都不能共享230
21.3.2 原則2：什麼都不能跨過泳道邊界231
21.3.3 原則3：在泳道內交易231
21.4 何時實現故障隔離231
21.4.1 方法1：把最賺錢的功能放入泳道232
21.4.2 方法2：把最容易引發故障的功能放入泳道232
21.4.3 方法3：根據自然界限劃分泳道232
21.5 如何測試故障隔離的設計233
21.6 結論233
本章要點234
第22章 AKF擴展立方入門235
22.1 概念，還是規則和工具235
22.2 AKF擴展立方介紹236
22.3 擴展立方的含義237
22.4 擴展立方的X軸238
22.5 擴展立方的Y軸239
22.6 擴展立方的Z軸240
22.7 綜合套用241
22.8 何時何地使用擴展立方243
22.9 結論243
本章要點244
第23章 為擴展劃分套用245
23.1 套用的AKF擴展立方245
23.2 AKF套用擴展立方的X軸246
23.3 AKF套用擴展立方的Y軸248
23.4 AKF套用擴展立方的Z軸249
23.5 綜合套用251
23.6 套用擴展立方的實際套用253
23.6.1 電子商務平台253
23.6.2 人力資源管理系統254
23.6.3 後台辦公IT系統255
23.6.4 經驗之談255
23.7 結論256
本章要點257
第24章 為擴展劃分資料庫258
24.1 資料庫的AKF擴展立方258
24.2 AKF資料庫擴展立方的X軸259
24.3 AKF資料庫擴展立方的Y軸262
24.4 AKF資料庫擴展立方的Z軸264
24.5 綜合套用265
24.6 資料庫擴展立方的實際套用267
24.6.1 電子商務平台267
24.6.2 人力資源管理系統269
24.6.3 後台辦公IT系統269
24.6.4 經驗之談270
24.6.5 時間方面的考量270
24.7 結論271
本章要點271
第25章 為性能和擴展進行快取272
25.1 快取定義272
25.2 對象快取275
25.3 套用快取277
25.3.1 代理快取278
25.3.2 反向代理快取279
25.3.3 快取軟體280
25.4 內容交付網路281
25.5 結論282
本章要點282
第26章 實現擴展的異步設計284
26.1 同步的定義284
26.2 同步調用，還是異步調用285
26.2.1 同步擴展，還是異步擴展286
26.2.2 異步系統示例288
26.3 定義狀態290
26.4 結論293
本章要點294
第四部分 解決其他的問題和挑戰
第27章 數據太多296
27.1 數據的成本296
27.2 數據的價值和成本–價值難題298
27.3 讓數據成為有利可圖的299
27.3.1 期權價值300
27.3.2 競爭優勢300
27.3.3 成本合理的解決方案（分層的存儲方案）301
27.3.4 轉換數據302
27.4 處理大量的數據302
27.5 結論305
本章要點306
第28章 雲和格線307
28.1 歷史和定義307
28.1.1 格線計算309
28.1.2 公共雲和私有雲310
28.2 雲的特徵和架構311
28.2.1 按用量付費311
28.2.2 按需擴展311
28.2.3 多租戶312
28.2.4 虛擬化313
28.3 雲和格線的區別314
28.4 結論315
本章要點316
第29章 在雲上翱翔317
29.1 雲計算的利弊317
29.1.1 雲計算的優點318
29.1.2 雲計算的缺點320
29.2 雲計算的不同用法323
29.2.1 環境323
29.2.2 技能集合325
29.3 決策流程325
29.4 結論327
本章要點328
第30章 接上格線329
30.1 格線的利弊329
30.1.1 格線的優點330
30.1.2 格線的缺點331
30.2 格線計算的不同用法333
30.2.1 生產格線333
30.2.2 編譯格線334
30.2.3 數據倉庫格線335
30.2.4 後台辦公格線335
30.3 決策流程336
30.4 結論338
本章要點338
第31章 監控套用340
31.1 “為什麼我們沒能及早發現它？”340
31.2 實現監控的框架342
31.2.1 用戶體驗和業務指標345
31.2.2 系統監控345
31.2.3 套用監控346
31.3 衡量監控：什麼有價值，什麼無價值347
31.4 監控和流程348
31.5 結論349
本章要點349
第32章 規劃數據中心350
32.1 數據中心的成本和約束350
32.2 位置、位置、還是位置352
32.3 數據中心與增量增長354
32.4 三條三之原則355
32.4.1 第一條三之原則：數據中心的三個成本驅動力355
32.4.2 第二條三之原則：三對伺服器來說是個神奇數字356
32.4.3 第三條三之原則：三對數據中心來說是個神奇數字356
32.5 構建多個活動數據中心要考慮的因素359
32.6 結論360
本章要點361
第33章 綜合套用362
33.1 接下來做什麼363
33.2 案例分析365
33.2.1 eBay：巨大的成功和可擴展性大爆炸365
33.2.2 Quigo：出現可擴展性問題的年輕產品366
33.2.3 ShareThis：一個創業公司的故事367
33.3 參考資料368
附 錄
附錄A 計算可用性372
附錄B 產能規劃計算378
附錄C 負載和性能計算383
