Run with extra load(通過額外載入發現系統故障)

在生產環境最常用的一個技巧就是，人為製造一些額外的資料進行載入。舉個例子，生產環境常常針對快取伺服器進行額外的資料讀取載入(Memcached Read)，如果快取伺服器down機，運維工程師就可以馬上切斷流量進行故障排查。為什麼不能事先計劃好，而是採用一種”通過加流量試錯”的方式發現系統的問題呢？答案是：從長時間積累的運維經驗來看，引起系統故障的原因範圍太大，而且常常是突發性的，無法通過監控實時捕獲。另一點需要注意的是，儘量不要模擬資料寫入載入，這會破壞生產環境的資料一致性以及導致無法控制的鎖競爭。

App-specific metrics(面向具體應用的度量圖表)

針對特定應用，彙總不同類目叢集所定製的資料統計圖表變得越來越重要。一般現有的圖表監控都是針對具體某一類資料(CPU, Mem, IO等)，將各個維度的統計資料彙總到一個圖表的需求很迫切。Dropbox的解決方案是充分利用memcached(快取伺服器)，cron(後臺計劃任務管理)以及ganglia(叢集監控管理)三方的功能：每當有統計資料是我們想要的，會將該資料存到執行緒安全的記憶體塊裡面，每秒鐘記憶體塊裡面的資料都會發送到快取伺服器，以時間戳作為Key儲存。每分鐘，快取伺服器的統計資料會被清除、彙總、傳送到叢集監控伺服器。舉個實際的例子，下面是生產環境中最好用的圖表：

圖1：系統響應時間度量圖表

橫軸是時間段，縱軸是站點伺服器響應時間，響應時間分五段(MySQL Query, MySQL Commit, RPC’s, Memcaced, CPU)，我們很容易看出在1:00左右，有根很長的刺，由MySQL Commit所導致。實際圖表響應時間不僅僅只有五段，很多因素被剔除了，都包含在”CPU”裡面。

Poor man’s analytics with bash(善於利用bash指令碼分析系統問題)

熟練運用bash shell可以很大程度提高工作效率，舉個例子，現有伺服器端的日誌，想從中提取最近某個時間段內流量的波峰是否超過閾值，當然現有的伺服器圖表可以滿足大部分的需求，但很多系統的資料實時性不高(一到五分鐘更新一次資料)。面對ad hoc需求，可以使用如下指令碼：

Apr 8 2012 14:33:59 POST ...
Apr 8 2012 14:34:00 GET ...
Apr 8 2012 14:34:00 GET ...
Apr 8 2012 14:34:01 POST ...

cut -d’ ’ -f1-4 log.txt | xargs -L1 -I_ date +%s -d_ | uniq -c | (echo “plot ‘-’ using 2:1 with lines”; cat) | gnuplot

上述命令會將現在的系統狀況以圖形化的形式表現出來。

Log spam is really helpful(垃圾日誌還是幫得上忙的)

垃圾日誌並不是說一無是處，很多時候，它幫了我們大忙。垃圾日誌其實可以作為跟蹤程式碼的一種方式，舉個例子，一段程式碼邏輯如果在正常情況下會列印”FUUUCCKKKKKasdjkfnff”的字串，那麼在出問題的時候我們可以根據日誌找到問題的源頭。日常的運維工作常常會維護兩份日誌檔案，一份乾淨的日誌檔案，一份填充著垃圾日誌的檔案，它常常會不經意的幫到我們。

Keeping a downtime log(記錄故障日誌)

記錄故障日誌是一個很好的習慣，記錄故障的開始、結束時間以及故障的原因，過後通過分析故障日誌我們可以很客觀的判斷如何最小化故障發生的時間。每個故障發生的原因不盡相同，而每個故障的解決方案也不一樣，將故障詳情記錄下來確實是一個明智之舉。

UTC(使用世界標準時間)

一定要使用世界表尊時間，不管是伺服器時間還是資料庫時間。很多系統對於非UTC時間的處理很不好，這會帶來很多問題，切記在呈現給使用者資料之前做時區轉換。

Technologies we used(我們使用的技術)

很多朋友對於Dropbox使用什麼技術非常感興趣，我們來列舉下我們使用的技術：

2) 資料庫MySQL

4) 亞馬遜雲服務S3/EC2儲存檔案

5) memcached用來減小資料庫的壓力，以及用來處理內部系統的協作

6) ganglia做叢集監視管理以及生成定製化監控報表

7) nginx做前端伺服器

8) haproxy做web伺服器負載均衡

9) nagios做內部伺服器的健康檢查

10) Pingdom做外部服務的監控

11) GeoIP 用來將IP轉化為地理位置

上述選擇的技術是業界標準，沒有什麼新奇，最大的原因是可靠、風險低。即便是memcached這麼通用的技術，都存在一些令人頭痛的bug，選擇太新的技術會讓事情變得複雜。我們對於技術選型的建議是，儘量選擇輕量級的、業界知名公司都在使用的技術，當然也可以花時間成為該專案的”技術先驅”。

The security-convenience tradeoff(系統安全和使用者體驗的權衡)

為了保護使用者檔案資訊，系統安全對於Dropbox非常重要。但增加安全性，不管對於使用者還是程式設計師，都會造成不方便，舉個例子：很多網站在使用者輸入錯誤的使用者名稱或者密碼的時候，提示說您有一項輸入錯誤，但不會告訴你具體是哪個。這種安全性策略，大大減小了破解使用者名稱、密碼的概率，但對於那些在不同網站都使用不同使用者名稱的使用者，會帶來一些麻煩。

在內部伺服器叢集設定防火牆，是一個很棒的想法，但在實踐中，對於互相沒有通訊的伺服器叢集可以省略此步驟。最常用的隔離，一般針對的是搭建在內部網路的第三方論壇，它更容易遭到攻擊。

我們的安全策略可能有些爭議，但系統安全都是對使用者行為的假想和抽象，很多系統甚至是銀行系統，都存在很大的安全隱患，所以在對系統做安全性投入的時候，先想一想這些工作是不是那麼的必要。

對於運維技術感興趣的讀者朋友，可以關注Rajiv的部落格，或者通過郵箱[email protected]與作者聯絡。