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使用什麼技術非常感興趣，我們來列舉下我們使用的技術：
1) 開發語言使用Python
2) 數據庫MySQL
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]與作者聯繫。