網站運維：保持數據實時的秘技（簡體書）

《網站運維:保持數據實時的秘技》的各位合作者以自己的親身經歷，從不同的側面講述了一個正在發展中的新興技術領域——網站運維：職業特點、技術架構、測量與監控、開發與部署、用戶體驗、後端存儲，以及如何應對流量激增、如何優雅地失敗，特別是如何將軟件開發領域中的敏捷方法應用于網站運維。閱讀《網站運維:保持數據實時的秘技》，讀者不僅能夠學到一些具體的技術，還能夠開闊眼界，因為書中不僅有具體方法的討論，更有基于十多年運維經驗的哲理思考。
《網站運維:保持數據實時的秘技》適合網站架構師、開發人員、運維人員（包括但不限于數據庫管理員、系統管理員、網絡管理員、發布管理員等）閱讀，同時也適合項目經理等管理人員閱讀。

作者：(美國)約翰?阿爾斯帕瓦 (John Allspaw) (美國)杰西?羅賓斯 (Jesse Robbins) 譯者：楊建華

《網站運維:保持數據實時的秘技》：“Web正在改變我們的生活方式，并且觸及到了每一個人。隨著越來越多的人依賴于Web，他們最終將依賴于我們。網站運維就是這樣的工作。”
Web應用涉及到很多專業人士，但只有網站運維人員才能確保在應用程序的生命周期中，一切運行正常。剛起步的網站，突遇流量高峰，或由于引入了一項新特性，而導致穩定的應用程序運行失敗，這時，你就需要網站運維人員來幫助你解決這些問題，他們正是這方面的專家。在《網站運維:保持數據實時的秘技》的文章和訪談中，Theo Schlossnagle、Baron Schwartz以及Alistaiir Croll等Web方面的高手，為這個尚處于發展中的技術領域貢獻了他們的深刻見解。關于如何才能讓網站火起來，你會聽到來自戰壕的真實故事——來自一些最大的網站的建設者的親身經歷。
學習網站運維中所需要的技能，以及為什么這些技能是通過經驗而不是學校教育獲得的。理解從應用程序和基礎架構中獲取測量數據的重要性。考慮數據庫架構的常用方式，以及伴隨規模增長而來的陷阱。了解如何處理宕機及降級運行的人的因素。找出一家公司在巨大的流量洶涌而來之時是如何避免災難的。發生問題時，發現問題出在哪兒，以及如何避免再次發生。

目錄
序 xi
前言 xiii
第1章 作為職業的Web運維 1
Theo Schlossnagle
為什么Web運維如此艱難？ 1
從學徒到師傅 4
結語 9

第2章 Picnik如何應用云計算：所學到的教訓 10
Justin Huff
什么地方適合云計算（以及為什么！） 11
什么地方不適合云計算（對Picnik而言） 17
結語 18

第3章 基礎架構與應用程序測量 19
John Allspaw, Matt Massie
時間分辨率和存留時間的考慮 20
測量數據采集與存儲的地點 21
測量數據的層次 22
為異常檢測和報警提供環境 25
日志記錄也是測量數據 26
將變化管理和事件的時間線建立關聯 27
給測量數據加入報警機制 28
使用測量數據建立加載-反饋機制 29
展示一個測量數據采集系統：Ganglia 32
結語 43

第4章 連續部署 44
Eric Ries
小批量意味著更快的反饋 44
小批量意味著問題即刻被本地化 44
小批量能夠減少風險 45
小批量可以降低總開銷 45
質量衛士的挽歌 47
讓我們開始吧 50
連續部署用于關鍵任務應用 54
結語 57

第5章 作為代碼的基礎架構 58
Adam Jacob
面向服務體系結構 60
結語 71

第6章 監控 72
Patrick Debois
故事：“旅程的開端” 72
步驟1：理解你在監控什么 76
步驟2：理解正常行為 84
步驟3：有備而學 90
結語 93

第7章 復雜系統是如何失敗的 94
John Allspaw和Richard Cook
復雜系統是如何失效的 94
進一步的讀物 101

第8章 社區管理與Web運維 103
Heather Champ和John Allspaw

第9章 處理非預期的訪問量激增 112
Brian Moon
一切是如何開始的 112
警報連連 113
撲滅烈火 114
周末逃生 115
未雨綢繆 116
救命稻草CDN 116
代理服務器 116
圍剿踩踏 117
將代碼基流水化 118
我們怎么知道它能否工作？ 119
真實測試 120
學到的教訓 120
自那以來的改進 121

第10章 開發者與運維者的協調與合作 122
Paul Hammond
部署 123
共享、開放的基礎架構 126
信任 128
隨叫隨到的開發人員 131
避免指責 135
結語 137

第11章 你的訪問者感覺怎么樣：面向用戶的測量 139
Alistair Croll和Sean Power
為什么要采集面向用戶的測量數據？ 140
是什么使網站變得很慢？ 144
測量延遲 147
編寫SLA 153
訪客結果：分析 155
市場營銷關心的其他測量數據 160
用戶體驗如何影響Web運維 161
Web監控的未來 162
結語 167

第12章 將關系數據庫用于Web的戰略戰術 169
Baron Schwartz
Web數據庫需求 170
典型的Web數據庫是如何增長的 175
對集群的渴望 181
數據庫戰略 186
數據庫戰術 193
結語 198

第13章 如何優雅地失敗：事後處理的藝術與科學 200
Jake Loomis
最糟的事後分析 200
什么是事後分析？ 201
什么時候引入事後分析 203
邀請誰參加事後分析 204
進行事後分析 204
事後分析的後續工作 205
結語 207

第14章 存儲 208
Anoop Nagwani
數據資產的庫存 208
數據保護 211
容量規劃 218
存儲大小的變化 219
運維 221
結語 223

第15章 非關系數據庫 224
Eric Florenzano
NoSQL數據庫概覽 225
某些系統細節 228
結語 238

第16章 敏捷基礎架構 239
Andrew Clay Shafer
敏捷基礎架構 241
那么，問題是什么？ 244
興趣與實踐的社區 253
貿易區和道歉 253
結語 256

第17章 夜間鬼魅（以及如何高枕無憂） 257
Mike Christina
術語 258
多少個9？ 259
影響持續時間對事件持續時間 260
數據中心數量（footprint） 261
逐漸失效 262
不信賴任何人 263
故障轉移測試 264
監控和歷史模式 264
高枕無憂 265
合作者 267
索引 271

首先，連續部署區分了發布的兩種不同的定義，一個是工程師使用的，指的是將代碼完全集成到生產環境中的過程；另一個是市場部門使用的，指的是客戶看到的東西。在傳統的批處理-排隊開發方式下，這兩個概念是連在一起的，代碼一旦部署，所有客戶都將看到新的軟件。這就要求所有的測試必須在部署之前進行，測試在特殊的預演或測試環境中進行。這種做法使得發布變得很脆弱，即在這段時間（代碼寫完之後，在生產環境運行之前）內可能會出現預想不到的問題。這種將市場發布和技術發布合并在一起的做法，在總的開銷之上，又增加了協調的開銷。使用連續部署，代碼一旦寫完，就在去往生產環境的路上了。
這意味著我們經常會在一項功能只完成了1％時就進行部署——遠在客戶能夠看到之前。事實上，涉及到一項新功能的大部分工作都是用戶不可見的，而是大量的與其他已有功能進行集成的瑣碎的接觸點。只要想想那些API的微小改動就明白了，為了傳送新值，必須要對API進行修改，這些修改通常都假定“不會引起副作用”，意思是不會影響系統行為——注意是假定。事實上，很多缺陷都是由這些修改產生的非同尋常或沒有引起注意的副作用造成的。同樣的事實也存在于生產環境中的配置參數的小小改動而引發的沖突中。這種情況下，反饋越快越好，而這．正是連續部署提供的。