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