運維85條軍規
1) 承載能力優先 ——隨後再進行優化 —— 不遵守這條規則必定帶來故障停機時間。不要在故障停機時間的壓力下進行優化——要先集中精力提高承載能力。
2) 以Postgres為例，一定要確保你的每一個網路都能匹配得上你的WAL檔案、Slony複製、快照技術以及基於磁碟的DB版本化（快照的衍生品）。
3) 不要把問題‘優化’到你的架構之中。為了解決問題而新加進來的一些東西往往後來都會變成運維沉重的負擔。 要確保在運維工程化中開發出來的工具交接完整。過後再回頭進行進一步的開發往往不靈。更重要的是，變更請求可能會破壞已經安排好的工程計劃。
4） 保持簡單。保持簡單，因為你很聰明別把事搞的太複雜，因為你行的。
5）應該非常謹慎地使用 快取 ，為了保護資源一致性，它很難進行水平縮放。
- 如果你作的是一個可以橫向擴充套件的東西，明智或審慎的做法是不要新增的快取層。
- 如果非要使用，它應該是為終端使用者獲得效能，不是為了贏得一個網站的容量。
6） 不要所有程式碼都自己寫; 不要所有東西都外包; 在合適的時間使用合適的工具,完成你的工作。
7)協商-真正有效的談判唯一方式是先作一些調研,制定一些可行的性方案.這樣你可以挑選你的首席開發商,如果你真的需要. 別虛張聲勢。
8）一直保持N+1。如果N=1，無論任何情況下不要輕易使用+1，這個1只用於當N down機情況下。當使用冗餘伺服器來承載負載時候，不要讓你的系統超過49%的負荷。當有機會能只用N+2的架構時候，使用它。
9）資料丟失不是任何一個公司所能承擔的風險--這是舉世所知的真理。資料丟失造成的損失遠遠大於保持資料不丟失所花的成本。
10）無論何時何地儘可能並行化。這是復路考慮最重要的手段。比如，如果利用MogileFS來做位置感知，並且需要實時的複製資料，一個可行的方法是每一臺MogileFS伺服器可以複製它的資料去MogileFS的負載均衡中心。儘可能多的啟用多的平行。
11）閱讀手冊。至今，我還是堅持要先通讀RAID卡的手冊，以確認是否有什麼細微的差別。惡魔都隱藏在細節裡。做足功課吧！
12）知道瓶頸所在，並知道怎麼去定位它，一層層排查，查詢是不是硬碟、記憶體或者cpu的阻塞了。通常這個很簡單。
13)定期做系統容量管理程式。積極一點。如果沒有容量資料的曲線，你很難知道你係統的薄弱之處。
14）不要促成失敗，不要害怕改變。
15）別挖陷阱給自己跳。不要認為你的工作成果將能作為未來的工作的動力。
16 ）運維人員寫的程式碼應該是運維工具，而不是應用軟體。
17）在運維團隊中，不要低估了專案管理、文件撰寫以及財務分析人員的價值。他們比給予工資更有價值。
18）監控一切。報警異常問題。其他部分記錄資料用來做趨勢分析資訊。
19）定期的流程檢視各個地方的趨勢資料。
20）不要把監控弄的很亂，不然他就沒有啥意義了。
21）要確保監控系統簡單到讓公司的每個人都能上手。你可能會很吃驚監控資料指標轉換成為業務指標、市場指標和銷售等等指標有多頻繁。
22 ） 只在可以做出相應改善的地方做檢查。 否則就不要浪費時間了。
23）公開你的檢查報告，並附上相關資料，以便他人可以容易的閱讀到關鍵點，並能關聯到響應的資料。
24）在每一個技術點都分配人手。
25）要給重要人員配備後備人手。
26）要不斷的招聘。甚至是當你沒有名額，也要一直招聘。
27）要嚴於律己。無論你有多聰明或者你認為你多NB，你也要不斷的提高自己。
28 ）要儘可能多的把自己和其他公司做比較。眼光要往外看。
29) 挑選一個展會或回憶，只有一個，一年一次，去參加。如果展會一年舉辦多次，之參加一次。
30) 購買你需要的，而非你想要的。永遠都不要摘掉企業這頂帽子帶上“什麼對我是最簡單最安全的”這頂帽子。
31)永遠只做最生意有益的事情，即使這意味著你需要離開。
32)正式問責機制——記錄承諾，標記它們，揭示為兌現的承諾。
33) 你不應失敗兩次以上。恐懼感有點好處。但要知道長期犯錯和無意犯錯的區別。
34無情一些——你的對手如此。
35)視工作為在你完成時需要簽上你的名字。這也意味著完成你的工作。
36)變得對別人有用。
37)與初創公司合作——提供你的專業技術和規模，你將獲得免費的產品作為回報，有時甚或一生。
38）容量是一個業務/產品問題。這意外著每個頁面、每個請求、每次登入的網路成本等等在做正確的業務/產品決策時候都必須是都透明。
39)一直打破預算。運維團隊通常是最大的花費者。通常沒有收入沒有達到預算，但是運維團隊可以有很多方法來延期採購。
40）過去能正常的做的事，不見得現在或者未來都會正常。所以做的時候，先用工具測試一下。
41）文件化。把所有東西都寫成文件。要讓新人挨個去問怎麼做事。
42）用一張大尺寸的圖繪製你資料中心的網路拓撲。
43 ）用一張圖描繪出你每一個產品的業務流程圖。
44) Faq-O-Matic, Wiki, 在這裡人們可以很容易的釋出“這是如何修復這個”的文章，並讓它容易被找到的地方。這裡是技術編寫者能派上用場的地方，但是，最重要的是使文件更容易，即使是非正式的。
45) 確保所有人，任何人都可以被替換。
46)多數人在家裡做的比在辦公室裡更多，有些人則不然。
47)捆綁下單——你可以要求更多折扣，更好的條款等等。當你成批購進硬體時。你可以要求一切——最低價格，備件包，租賃期限，只要他們還沒有得到訂單。
48)同你的供貨商保持長期關係——確保你在下份工作時依然能夠聯絡他們。
49）給運維團隊的每一個人配置可以用來遠端工作的超級裝備：掌上電腦、無線上網路卡、24英寸液晶顯示器等等。僱傭大拿得到回報要遠大於遠端僱傭的本地人員。記住運維工程師都是用電達人，能充分的利用螢幕上的每一個畫素點。
50)完全陷入IT標準的泥潭。直到Mac執行office 2007和outlook，你必須執行windows。間斷的。除非全用mac本，否則這會破壞會議日程表、聯絡人或者郵件列表的辦公效率。如果有個員工願意工作的在 xp環境。這是非常少。這條法則，現在是陳舊的/未公認的，陷入泥潭不一定是最好的方法。這個列表非常的07化。
51 ）有個合理的採購流程。知道你的預算，確信能管好它。從財務得到實際的金額。在技術驅動的預算/報告和財務驅動的預算/報告直接往往有一定的差距。作為一個搞的運維管理者要能形成模型把這些差距計入銷售總成本中。一個理解這些事情的CFO有助於推動業務決策。
52）週會一定要持續進行。對上次會議的事件逐一落實結果和追責。
53）建立一個分離的逐級升級系統，用以消除由於開發者程式碼的問題對線上系統的不良影響。這主要是運維問題、程式碼問題都存在的情況下在開發跟蹤系統或者運維跟蹤系統中往往會丟掉，最後無人理睬。建立一個獨立的跟蹤系統來解決這些問題可以使得問題簡單清晰。
54 ）產品開發從設計開始的每個階段都要和運維相結合。這樣，擴充套件性，監控和可靠性都融入到產品裡。這樣同時也可以確保運維負責的硬體採購、監控系統按時到位，運維手冊得到及時更新，最後產品按照預計時間上線執行並且都符合運維標準。
55）在公司真正的實踐——Sarbanes，WebTrust 安全審計認證，SAS 70 審計標準，Visa 和銀行等等。如果你真的成功了，這些都是你不得不打交道的。早點開始這些準備其實很簡單，不需要太多的知識。部署一個工單/任務跟蹤工具，使用它。把變更控制和變更管理納入同樣的系統裡，使用它。其他資訊也可以放進來。系統就可以幫助我們找出像“上週變更了什麼”這類資訊。
56）簡化給冗餘留和多點登入的流程。一開始或許很難，但是一個沒有真正的擴充套件性和可靠性的系統，才會真正耽誤你獲得成功的時間。
57）Oracle 標準版(SQL Server 標準版)是值得購買的。如果你可以限制住自己不超過標準版的需求，那就絕對值得買，哪怕你剛剛開始創業還不需要他。
58）Postgres 和 MySQL 是一個免費的考慮。如果你不是特別在意事務完整性，MySQL 是很好的選擇。直到"真空"和Postgres單詞的強制鏈被打斷，Postgres代表一個不可預知的，通常消極詭異的資料庫。
59）容量設計應該按照每日峰值再上拋 20% ～ 30% 的冗餘。除非你是個遷移技術熱衷者。
60）儘量多讀一些經濟雜誌。它們通常是免費的，只需你填寫一些調查問卷就可以免費獲得。新聞的價值是巨大的。讓他們投遞到你家裡，工作的時候讀雜誌的機會趨近於零。
61）保障安全。開發人員不應該有線上環境的許可權，應該做程式碼複核。這是和運維之間的職責分離。運維團隊中應該有人控制其他運維人員許可權的許可權。制定員工手冊，告知違反安全條例所帶來的嚴重後果。從開始就要從物理的、邏輯的、功能的各個方面來保護客戶的資料安全和隱私。萬一有客戶要和你對峙起來，你發現起來發現自己只是靠勇氣和勤奮來保護客戶資料，那你就傻了。
62） 控制好訪問入口。首先要保證大家可以正常完成工作；其次要確保你知道他們是從哪裡登入的。啟用雙因素身份驗證方法。
63）對於人們訪問生產環境必經之路的壁壘和閘道器宿主，擊鍵記錄很重要。對於 Windows 可能稍微有點難度，不過有些閘道器可以提供自動截圖功能。
64）如果有狀況的情況下，確保有冗餘登入點連線到生產環境。不要期望公司的 VPN 在網路中斷的時候還能連上生產環境。直接把 VPN 架設線上上環境裡。
65）使用 LDAP 認證，哪怕你只有 10 臺機器，通過複製 passwd 和 shadow 檔案的方式來管理，你也需要 LDAP 認證。
66）不要低估在 UNIX 環境中一臺 Windows Server 2003（2008）裝置的作用。如果只是因為不懂 Windows，那麼去學，而不是排斥它。
67）不要在無效的無線方案上浪費大家的時間。人們都機動的，他們希望在沙發上，會議室裡，門口，到處都要上網。一定要保證無線ad的可靠。
68） 總有人把額外的精力和時間都投入到工作上——直接通過他們的請假單好了。而另一些人恰恰相反只把注意力放在怎麼通過自己的請假單。在個人時間安排上，運維人員總是做出巨大的犧牲，他們隨時準備凌晨3點爬起床快速響應排障需求。
69）通過集中式的關聯式資料庫管理你所有的產品成果。然後通過資料複製分發到資產，人員，網路，合同等所有資料到異地。沒錯，要的是一個線上的實時可用的複製，而不是每天晚上備份到磁帶。
70）儘可使用自動化流程以確保安全，包括作業系統或者產品的上線，檔案的分發，日誌的分析等。
71）自動化操作通過運維資料庫獲得配置（真理來源）。
72）伺服器通常有三種狀態——離線，線上，產品態。線上就是說正在通過 cfengine、rsync 或者其他你在使用的工具完成配置。產品態表示已經走流量了。同時還需要一個狀態，這個狀態下的裝置可以在不提供生產服務的情況下收集或者測試資料。
73）注重日誌資料。在裝置下線或者重建之前，一定要先匯出日誌。
74）如果規模發展太快以至於沒有太多時間來做優化，那就盡力鎖定一切——流程還能進行即可，就不要改變它，直到後來有了絕對必要的理由。總之，鎖定預設值，等待成長到必要時再審視。
75）你永遠無法避免運維工程師在你基礎設施最關鍵的地方犯錯——比如在哪臺機器上不小心執行 rm -rf / 命令。
76）為團隊保持好玩和有趣的氣氛——如果他們不再享受他們的工作，他們就會找別的事情來消遣。要讓團隊有主人翁意識，運維不是哪個經理的個人任務。
77）提供 99.999% 可用性的真正價值在於讓我們有能力保持靈活。這意味著當你需要的時候可以充分利用冗餘。這會讓物理變更、裝置登入點變化、程式碼修改和回退等等都遊刃有餘。這個對於公司本身價值巨大，甚至比對客戶還大。
78）如果你能做到 99.999%，給客戶100% 的服務承諾。
79） 不要丟掉按流程釋出軟體的能力。應該丟掉的是你自己回滾或者轉移到舊版本程式碼的能力。壓根就不應該“處理”這種徒勞的失敗轉移。當事情變得不 如人意的時候，你更應該做的是找個大玩意兒來擋住你的肥屁股。CYA = 保持敏捷 = 成功的公司。
80） 在腦子裡要清楚知道為什麼以及這樣做的為了達到的目的，為客戶構建產品每一個具體步驟。不管你部署給終端使用者的是什麼，把這些放在最先考慮，即你所有（基礎設施、流程和人員）的設計都是為了提供最好的服務和產品。
81）第一次就要做對了。很少有機會讓你回去在做一遍的。重做是對公司資源的巨大浪費。要提高命中率，一次就要成功。
82）接觸業內人士、盟友和類似的企業，看看他們的運維是怎麼做的。很可能他們碰到了跟你一樣的挑戰，而解決的方法更好。不要害怕分享自己的經驗和處理過程，因為別人也會回饋的。他山之石，可以攻玉！
83）招人要招那些好到可以讓你擔心位子不保的那樣的人，招你欣賞和可以學習的榜樣，招那些你願意和他一起工作的。這感覺甚至超過你招聘一個工作考評為A的員工。
84） IT 和運維是完全不同的兩個概念。一個不錯的運維經理應該可以管理好企業IT，但是一個傳統的 IT工程師很難有能力處理網際網路運維任務。
85）當你開始一份新工作或者在每年的起始，都應該去爭取預算。這不是說推車那老破車往前走，而應該是基 於歷史資料做出最佳推薦方案。如果你正在評估一份新工作，請確認你完完全全的知道預算以及預算的來源。同時，還應該有完善這份預算的權利。