編輯推薦
Web應用涉及到很多專業人士，但只有網站運維人員才能確保在應用程式的生命週期中，一切執行正常。剛起步的網站，突遇流量高峰，或由於引入了一項新特性，而導致穩定的應用程式執行失敗，這時，你就需要網站運維人員來幫助你解決這些問題，他們正是這方面的專家。在《網站運維:保持資料實時的祕技》的文章和訪談中，Theo Schlossnagle、Baron Schwartz以及Alistaiir Croll等Web方面的高手，為這個尚處於發展中的技術領域貢獻了他們的深刻見解。關於如何才能讓網站火起來，你會聽到來自戰壕的真實故事——來自一些最大的網站的建設者的親身經歷。
學習網站運維中所需要的技能，以及為什麼這些技能是通過經驗而不是學校教育獲得的。理解從應用程式和基礎架構中獲取測量資料的重要性。考慮資料庫架構的常用方式，以及伴隨規模增長而來的陷阱。瞭解如何處理當機及降級執行的人的因素。找出一家公司在巨大的流量洶湧而來之時是如何避免災難的。發生問題時，發現問題出在哪兒，以及如何避免再次發生。
作者簡介
作者：(美國)約翰•阿爾斯帕瓦 (John Allspaw) (美國)傑西•羅賓斯 (Jesse Robbins) 譯者：楊建華
目錄
序 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進行修改，這些修改通常都假定“不會引起副作用”，意思是不會影響系統行為——注意是假定。事實上，很多缺陷都是由這些修改產生的非同尋常或沒有引起注意的副作用造成的。同樣的事實也存在於生產環境中的配置引數的小小改動而引發的衝突中。這種情況下，反饋越快越好，而這．正是連續部署提供的。