運維的 85 條軍規

運維85條軍規

1) 承載能力優先 ——隨後再進行優化 —— 不遵照這條規則一定帶來故障停機時間。不要在故障停機時間的壓力下進行優化——要先集中精力提升承載能力。

2) 以Postgres爲例，必定要確保你的每個網絡都能匹配得上你的WAL文件、Slony複製、快照技術以及基於磁盤的DB版本化（快照的衍生品）

3) 不要把問題‘優化’到你的架構之中。爲了解決問題而新加進來的一些東西每每後來都會變成運維沉重的負擔。 要確保在運維工程化中開發出來的工具交接完整。事後再回頭進行進一步的開發每每不靈。更重要的是，變動請求可能會破壞已經安排好的工程計劃。

4） 保持簡單。保持簡單，由於你很聰明 別把事搞的太複雜 由於你行的。

(譯者:KISS 原則 Keep It Simple, Stupid)

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）若是有情況的狀況下，確保有冗餘登陸點連線到生產環境。不要指望公司的 ××× 在網絡中斷的時候還能連上生產環境。直接把 ××× 架設在線上環境裏。

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）當你開始一份新工做或者在每一年的起始，都應該去爭取預算。這不是說推車那老破車往前走，而應該是基 於歷史數據作出最佳推薦方案。若是你正在評估一份新工做，請確認你完徹底全的知道預算以及預算的來源。同時，還應該有完善這份預算的權利