可擴展的藝術——現代企業的Web架構、流程及組織( 簡體 字) | |
作者:[美] Martin L.Abbott Michael | 類別:1. -> 程式設計 -> 綜合 |
出版社:人民郵電出版社 | 3dWoo書號: 34691 詢問書籍請說出此書號! 有庫存 NT售價: 395 元 |
出版日:1/1/2013 | |
頁數:387 | |
光碟數:0 | |
站長推薦: | |
印刷:黑白印刷 | 語系: ( 簡體 字 ) |
ISBN:9787115301727 | 加入購物車 │加到我的最愛 (請先登入會員) |
(簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證, 繁體書的下載亦請直接連絡出版社) | |
導言 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 CEO 18 2.3.2 CFO 19 2.3.3 業務單元責任人和P&L責任人 19 2.3.4 CTO/CIO 19 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章 領導力101 44 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章 管理101 63 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 任何持續發展的公司,最終都需要考慮如何擴展它的系統、組織和流程。這不僅僅是技術問題,還涉及組織、流程、架構等方方面面。擴展組織、流程和系統使之相互支持,達到良性循環,也不僅僅是門科學,還是一門藝術。《可擴展的藝術——現代企業的Web架構、流程及組織》正是對此提供了全面的、實踐證明確實有效的解決思路和實用技巧。
對于負責非技術類業務的執行主管或產品經理來說,《可擴展的藝術——現代企業的Web架構、流程及組織》會幫助你明確地提出正確的可擴展性問題,分析并做出正確的決策。而對于技術主管和工程師來說,《可擴展的藝術——現代企業的Web架構、流程及組織》會幫助你解決對擴展造成負面影響的組織和流程方面的問題,并為構建具有更高可擴展性的平臺提供了技術模型和建議。 |