2007 年，時任虛拟世界遊戲公司 Vivaty 運維副總裁的 Jon Prall 在他的個人部落格上發表過一篇《運維的85條規則》。2010 年他跳槽到視訊電話公司 Tango 之初，做了兩處更新，茲翻譯如下：
- 容量第一，優化第二——這條規則在故障發生時生效。在當機的時候别研究什麼優化，先恢複裝置。
- 保留所有可以捕獲的記錄——以 PostgresQL 為例，包括有 WAL 檔案，Slony 複制，快照技術，基于硬碟的 DB 版本(快照附帶的)
- 不要因為優化引入更多問題。通常我們解決問題時做出來的東西都會轉變成之後運維工作的負擔。請确認為運維工作開發的那些工具已經完全傳遞使用。這些東西經常無法正常運作結果要傳回開發組重來。更重要的，這種變更請求通常會打破團隊原本安排好的工作計劃。
- 保持簡單，不要讓事情變得太複雜，聰明的你一定可以做到的。
- 謹慎使用緩存以保護那些難以水準擴充的資源。當然，如果你可以水準擴充它，那麼給他加緩存層就不用考慮太多。一旦用上了緩存層，它的目的應該是提高最終使用者的通路性能，而不是增加網站的容量。否則，你不過是給自己加上了一個新的非常不可靠的瓶頸。他們潛在的負面影響可能危及整個系統。事實上緩存層失效帶來的，經常是雪崩式的級聯故障。
- 不要什麼都自己寫代碼實作，也不要什麼都從廠家買——要在适當的時候采用适當的工具。
- 談判——和真正有實力的廠家談判的唯一辦法就是提前做好功課，準備好一切可行項。這樣一旦有必要，你可以從你的首選廠家裡選擇離開。不用搞虛張聲勢那套了。
- 永遠要準備好 N+1 的伺服器。如果 N 等于 1，那麼不管什麼情況都不要動用這個 +1 的裝置，專職等待 N 失效後的接管。當你使用備援的伺服器來均衡負載的時候，就隻有49%或者更少的容量可管理了。通常我們會獲得 N+2 的機會——一定要好好利用起來。
- 資料丢失是任何一家公司都不敢冒的風險——這是一條普遍真理。丢失資料造成的損耗遠遠超過用于保證資料不丢失的花費。
- 随時随地的并行化——這是一種很重要的思維方式。比如，如果 MogileFS 設定為位置感覺的方式并且需要實時複制，那麼每個 MogileFS 伺服器都必須可以複制自己的資料到負載均衡器指定的另一端。隻要有可能，盡量實作這種多對多的方式。
- RTFM——就在今天我還要閱讀一對 RAID 卡的說明書來比較他們微妙的差異。魔鬼在于細節。像做家庭作業一樣讀文檔吧！
- 了解每一層上的瓶頸以及如何發現瓶頸。必須要知道你是在磁盤，記憶體，還是 CPU 上受限制了，搞清楚這個其實挺簡單的。
- 要有一個固定的容量管理流程——而且是主動式的，不是被動式的。要知道系統的弱點在哪裡，讓實際負荷曲線跑到容量曲線之上是極度危險的。
- 不促成失敗，也不懼怕改變。
- 不要吸進你自己的廢氣。别以為你現在的工作結果會變成未來你如何工作的動力。
- 運維人員要寫的代碼是運維工具，而不是應用軟體。
- 不要低估運維團隊中項目經理、技術作者、金融分析師的價值。這些人通常比你給的工資值錢多了。
- 監控所有的東西——報警隻用在異動的時候，其他的都記錄下來供趨勢分析。
- 要有一個固定的流程來檢視每個地方的趨勢資料。
- 不要讓監控太吵鬧，那樣很快就變得沒作用了。
- 確定你的監控系統簡單易用到公司裡每個人都能上手。監控資料名額轉換成為業務名額、市場名額和銷售名額等等的頻率可能高的讓你吃驚。
- 隻在可以做出相應改變的地方做總結，否則就是白白浪費時間。
- 總結要公開，同時附上事件相關的資料。這樣大家可以很容易的找到總結的關鍵點并且跳轉到對應資料。
- 要讓技術的每一個點都有人員在負責。
- 同時為這些負責人準備好備份人員。
- 不斷發招聘——哪怕沒有名額了。
- 做自己最嚴厲的批評者。不管自己或者自認多聰明，總有可以提高的地方。
- 多往外看，拿自身的水準和盡量多的公司的職位需求做對比。
- 每年參加一個技術交流大會。如果一年有好幾個，那選最好的那一個去就夠了。
- 買你需要的而不是你想要的。絕不摘下你公司的帽子換上那個寫着“對我來說什麼最簡單最安全”的。
- 隻做對業務最好的事情，哪怕這件事是讓你滾蛋……
- 問責制度正規化——記錄承諾，事後追究沒有完成者。
- 不允許重複失敗。聽起來有些過于苛責了。不過要區分不可挽回的失誤和失誤的差别。
- 無情——因為對手都是無情的。
- 工作是你要在完成的時候親自署名的東西。署名同時也意味着完成任務。
- 保持對外的可用聯絡。
- 創業的夥伴——告訴他們你的專長和能力範圍。你會得到免費的産品回報，有時候是生活中的。
- 容量是一個業務/産品問題。也就是說每個頁面、上傳或者登入等請求的網絡消耗，都必須是可見的，以協助完成正确的業務/産品決策。
- 一定要打敗預算！運維團隊總是預算金額最大的揮霍者。公司的收入目标經常達不到，運維團隊應該有很多辦法來推遲自己的花費。
- 過去的經驗不一定适用于現在乃至将來——多嘗試沒錯，而且要有恰當的測試工具來做這件事。
- 文檔——所有事情都應該好好記錄成文檔。避免團隊的新成員繞着圈的找遍全團隊逐一了解工作内容。
- 畫一張超大尺寸的網絡拓撲圖，描繪你的資料中心。
- 為你的每個産品都畫一個邏輯流程圖。
- 維基——讓大家可以很容易的釋出“如何修複這個問題”的文檔并且容易查找。這是技術作者發揮作用的地方，不過維基可以讓哪怕非正式的文檔或者增增改改的小段落也更好檢視。
- 確定團隊的每個成員，對，是每一個，都是可以替換的。
- 有些人在家裡幹活比在公司的時候還好，但有些人卻不行。
- 訂單打包簽訂——把硬體需求打包成大訂單後再去咨詢最大的折扣合同，記得訂單裡要包括所有一切，比如備件包，租賃條件等等。
- 和供應商保持長期聯系，哪怕你換到下一份工作的時候也能聯系上他們。
- 給運維團隊每個人都配上一切他們可以遠端操控的東西——掌上電腦， 3G 網卡，24 寸 LCD 螢幕……你為有才華的人付出得到的回報，遠超過在遠端雇傭的現場工程師。記住，運維工程師都是電力狂人，他們知道并且能充分利用螢幕上每個像素。
- 除非 Mac 可以運作 office 2007 和 outlook，否則團隊裡總需要幾個 windows。這事很破壞團隊的會議安排，聯系人管理和郵件清單等等。
- 要有一個簡化的采購流程——前提是你要了解自己的預算，并且能夠管理好。我們可以從财務報告中得到實際。技術驅動的報告和财務驅動的報告之間通常存在差距。一個好的運維經理可以建立一些模型，将這些差别計入銷售總成本中。而了解這些的 CFO 才可以幫助推動業務決策。
- 周會一定要持續舉行，對上周的事件逐一總結和問責。
- 建立一個獨立的更新系統，來管理那些對運維産生負面影響的代碼開發工程。這個想法的來源是：一個同時涉及運維和開發的問題，在運維或者開發的跟蹤系統裡大多被湮沒無視，最後沒人理睬，是以給這些問題單獨建立一個跟蹤系統反而更加簡單清楚。
- 産品開發從設計開始的每個階段都要和運維技術相結合。這樣，擴充性，監控和可靠性都融入到産品裡。這樣同時也可以確定運維負責的硬體采購、監控系統按時到位，運作手冊即時更新，最後産品按照預計時間上線運作并且都符合運維标準。
- 像一個真正的公司一樣運作——薩班斯法案，WebTrust 安全審計認證，SAS 70 審計标準，Visa 組織和銀行等等。如果你真的成功了，這些都是你不得不打交道的。早點開始這些準備其實很簡單，不需要太多的知識。不過就是開發一個工單/任務跟蹤工具，然後好好使用。把變更控制和管理放進同樣的系統裡，好好使用。其他資訊也放進來。系統就可以幫助我們找出像“上周變更了什麼”這類資訊。
- 給備援留白間。一開始或許很難，但是一個沒有真正的擴充性和可靠性的系統，才會真正耽誤你獲得成功的時間。
- 買個 Oracle 标準版(或者微軟 SQL Server 标準版)是值得的。如果你可以限制住自己不超過标準版的需求，那就絕對值得買，哪怕你剛剛開始創業。
- Postgres 和 MySQL 的免費不錯。如果你不是特别在意事務完整性，MySQL 其實挺好的。
- 容量設計應該按照每日峰值再上抛 20% 到 30% 的備援。除非你是個 vmotion(譯注：VMWare 的熱遷移技術)達人。
- 盡量多讀一些貿易雜志。它們通常是免費的，隻要你填寫一些調查問卷就好了。新聞的價值是巨大的。對了，記得讓他們投遞到你家裡，工作的時候讀雜志的機會趨近于零。
- 注意安全。開發人員不應該有生産線的權限，而應該去做代碼複核。這是和運維之間的職責分離。然後運維中應該有人控制設定其他運維人員權限的權限。建立一個員工手冊，警告大家違反安全條例會有很嚴重的後果。從一開始就要記住從實體的、邏輯的、功能的各個方面來保護客戶的資料安全和隐私。萬一有客戶要和你對簿公堂，你回憶起來發現自己隻是靠勇氣和勤奮來保護客戶資料，這感覺可不怎麼好。
- 控制好通路入口。首先要保證大家可以正常完成工作；其次要確定你知道他們是從哪裡進來的。快去實作雙因素身份驗證方法吧。
- 對于人們通路生産環境必經之路的堡壘機和網關，鍵盤記錄是至關重要的。對于 Windows 可能稍微有點難度，不過有些網關可以提供自動截屏功能。
- 確定有多種辦法登入生産環境。不要期望公司的 VPN 在網絡中斷的時候還能起作用。直接把 VPN 架設在生産環境裡。
- 使用 LDAP 做認證，哪怕你隻有 10 台機器，通過複制 passwd 和 shadow 檔案的方式來管理，你也要 LDAP 認證。
- 不要低估在 UNIX 環境中一台 Windows Server 2008 裝置是多麼有用。如果隻是因為不懂 Windows，那麼去學，而不是貶低它。
- 不要用那些無效的無線方案浪費大家的時間。公司裡所有人都在移動，沙發上，會議室裡，門口，到處都要上網。千萬維護好你的無線路由。
- 總有些人把額外的精力和時間都投入到工作上——直接通過他們的請假單好了。而另一些人恰恰相反隻把注意力放在怎麼通過自己的請假單。在個人時間安排上，運維人員總是做出巨大的犧牲，他們随時準備淩晨3點爬起床快速響應排障需求。
- 通過集中式的 RDBMS 管理你所有的裝置資産。然後複制資産，人員，網絡，合同等所有資料到異地。沒錯，要的是一個線上的實時可用的複制，而不是每天晚上備份到錄音帶。
- 自動使用多程序以确認安全，包括作業系統或者産品的上線，檔案的推送，日志的分析等。
- 自動化操作必須和運維的 RDBMS 資料相關聯。
- 裝置通常有三種狀态——離線，服務中，預備。預備狀态就是說正在通過 cfengine、rsync 或者其他你在使用的工具完成配置。服務中就是已經運作着流量了。同時還需要一個狀态，這個狀态下的裝置可以在不提供生産服務的情況下收集或者測試資料。
- 尊重日志資料。在裝置下線或者重建之前，一定要先導出日志。
- 如果業務飛速發展讓你沒有太多時間來做優化，那就盡力鎖定一切——程序還能工作，就不要改變它，直到後來有了絕對必要的理由。總之，鎖定預設值，等待成長到必要時再審視。
- 你永遠無法避免運維工程師在你基礎設施最關鍵的地方犯點啥錯——比如在哪台機器上不小心執行
rm -rf/
- 為團隊保持好玩和有趣的氣氛——如果他們不再享受他們的工作，他們就會找别的事情來消遣。要讓團隊有主人翁意識，運維不是哪個經理的個人任務。
- 提供 99.999% 可用性的真正價值在于讓我們有能力保持靈活。這意味着當你需要的時候可以充分利用系統備援。實體變更、裝置遷移、代碼修改和回退等等都遊刃有餘。這個對于公司本身價值巨大，甚至比對客戶還大。
- 如果你能做到 99.999%，那就給客戶一個 100% 的SLA承諾。
- 不要湮沒軟體熱更新的能力。應該被湮沒的是你自己復原或者轉移到舊版本代碼的能力。壓根就不應該“處理”這種徒勞的失敗轉移。當事情變得不如人意的時候，你更應該做的是找個大玩意兒來擋住你的肥屁股。CYA（譯注：Cover Your Ass，就是前面說的蓋屁股） = 保持靈活 = 成功的公司。
- 記住你為客戶建構産品的思路裡每一步的原因和目的——不管你部署給最終使用者的是什麼，把這些放在最先考慮，即你所有（基礎設施、流程和人員）的設計都是為了提供最好的服務和産品。
- 第一次就要成功。很少有機會讓你回去重新開始的。重做是對公司資源的巨大浪費。
- 多聯系業内的合作夥伴、盟友和類似的企業，看看他們的運維是怎麼做的。很可能他們碰到了跟你一樣的挑戰，而解決的更為巧妙。不要害怕分享自己的經驗和處理過程，因為别人也會回饋的。
- 招人就要招那些足以讓自己擔心會被擠掉目前工作的，招那些你欣賞和可以學習的榜樣，招那些你願意和他一起工作的。這感覺甚至超過你招聘一個工作考評為A的員工。
- IT 和運維是完全不同的兩個概念。一個不錯的運維經理應該可以管理好企業 IT，但是一個傳統的 IT 工程師很難有能力處理網際網路運維任務。
- 當你開始一份新工作或者在每年的起始，都應該去争取預算。這不是說滾着那個滋滋響的輪子往前走(應該是指循規蹈矩照本宣科)，而是要一個基于曆史資料做出的優秀的文案。如果你正在評估一份新工作，請确認你完完全全的知道預算以及預算的來源。同時，還應該有的是改善這份預算的權利。
![Shell程式設計——sort排序、uniq忽略重複、tr替換壓縮删除、cut指定删除字段、正規表達式元字元sort 指令uniq 指令tr 指令cut 指令正規表達式[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)