最近看到的另外一個介紹Twitter技術的視頻[ Slides ] [ Video (GFWed)]，這是Twitter的John Adams在 Velocity 2009 的一個演講，主要介紹了Twitter在系統運維方面一些經驗。 本文大部分整理的觀點都在Twitter(@ xmpp )上發過，這里全部整理出來并補充完整。

Twitter沒有自己的硬件，都是由NTTA來提供，同時NTTA負責硬件相關的網絡、帶寬、負載均衡等業務，Twitter operations team 只關注核心的業務，包括Performance，Availability，Capacity Planning容量規劃，配置管理 等，這個可能跟國內一般的互聯網公司有所區別。

1. 運維經驗

* Metrics

Twitter的監控后臺幾乎都是圖表(critical metrics)，類似駕駛室的轉速表，時速表，讓操作者可以迅速的了解系統當前的運作狀態。聯想到我們做的類似監控后臺，數據很多，但往往還需要瀏覽者 做二次分析判斷，像這樣滿屏都是圖表的方法做得還不夠，可以學習下這方面經驗。 據John介紹可以從圖表上看到系統的瓶頸-系統最弱的環節(web, mq, cache, db?)
根據圖表可以科學的制定系統容量規劃，而不是事后救火。

* 配置管理

每個系統都需要一個自動配置管理系統，越早越好，這條一整理發到Twitter上去之后引起很多回應。

* Darkmode

配置界面可以enable/disable 高計算消耗或高I/O的功能，也相當于優雅降級，系統壓力過大時取消一些非核心但消耗資源大的功能。

* 進程管理

Twitter做了一個”Seppaku” patch, 就是將Daemon在完成了n個requests之后主動kill掉，以保持健康的low memory狀態，這種做法據了解國內也有不少公司是這樣做。

* 硬件

Twitter將CPU由AMD換成Xeon之后，獲得30%性能提升，將CPU由雙核/4核換成8核之后，減少了40%的CPU, 不過John也說，這種升級不適合自己購買硬件的公司。

2. 代碼協同經驗

* Review制度

Twitter有上百個模塊，如果沒有一個好的制度，容易引起代碼修改沖突，并把問題帶給最終用戶。所以Twitter有一強制的source code review制度, 如果提交的代碼的svn comment沒有”reviewed by xxx”, 則pre-commit腳本會讓提交失敗, review過的代碼提交后會通過自動配置管理系統應用到上百臺服務器上。 有@xiaomics同學在Twitter上馬上就問，時間成本能否接受？如果有緊急功能怎么辦？個人認為緊急修改時有兩人在場，一人修改一人 review也不是什么難事。

* 部署管理

從部署圖表可以看到每個發布版本的CPU及latency變化，如果某個新版本latency圖表有明顯的向上跳躍，則說明該發布版本存在問題。另外在監控首頁列出各個模塊最后deploy版本的時間，可以清楚的看到代碼庫的現狀。

* 團隊溝通

Campfire來協同工作，campfire有點像群，但是更適合協同工作。對于Campfire就不做更多介紹，可參考 Campfire 官方說明。

3. cache

• Memcache key hash, 使用FNV hash 代替 MD5 hash，因為FNV更快。
• 開發了Cache Money plugin(Ruby), 給應用程序提供 read-through, write-through cache , 就像一個db訪問的鉤子，當讀寫數據庫的時候會自動更新cache, 避免了繁瑣的cache更新代碼。
• “Evictions make the cache unreliable for important configuration data”，Twitter使用memcache的一條經驗是，不同類型的數據需放在不同的mc,避免eviction，跟作者前文 Memcached數據被踢(evictions>0)現象分析 中的一些經驗一致。
• Memcached SEGVs, Memcached崩潰(cold cache problem)據稱會給這種高度依賴Cache的Web 2.0系統帶來災難，不知道Twitter具體怎么解決。
• 在Web層Twitter使用了Varnish作為反向代理，并對其評價較高。

轉自：http://timyang.net/