[轉載]系統運維祕訣大分享專題

系統運維祕訣大分享專題

本專題整合收錄了有關係統運維 / 系統管理員工做和我的成長方面的各類心得分享、經驗總結、以及必須牢記的一些準則，適合全部在運維領域有追求的技術人閱讀。有些分享的層次比較深，有些則是運維的基礎課，但經過翻看他人的心得，相信你總能有所收穫。

1 Dormando 的系統運維祕訣三部曲 ... 4

1.1 技術篇 ... 4

1.1.1 爲變化而設計 .... 4

1.1.2 使用自動的，可重複的構建過程 .... 4

1.1.3 使用冗餘 .... 4

1.1.4 使用備份 .... 5

1.1.5 監控正確的東西 .... 5

1.1.6 有關數據圖形化，歷史數據 .... 5

1.1.7 日誌記錄，使用多個數據流 .... 5

1.1.8 數據存儲方式，數據庫 .... 5

1.1.9 多一些橫向擴展，少一些縱向擴展 .... 6

1.1.10 緩存 .... 6

1.1.11 讓工做異步化 .... 6

1.1.12 安全和巡查 .... 6

1.2 交流篇 ... 7

1.2.1 經過多種方式來學習 .... 7

1.2.2 嘗試各類事情 .... 8

1.2.3 真正地搞清楚冗餘是怎麼一回事 .... 8

1.2.4 真正地理 解可擴展性 .... 8

1.2.5 成爲一個可以解決問題的超級明星 .... 8

1.2.6 和 IT 人員一塊兒工做 .... 8

1.2.7 和開發人員一塊兒工做 .... 8

1.2.8 和其餘領域的運維一塊兒工做 .... 9

1.3 實踐篇 ... 9

1.3.1 如今就修復它，而不是之後再修復它 .... 9

1.3.2 讓每一件事情都自 動化 .... 9

1.3.3 只進行必要的變動 .... 9

1.3.4 Design for change . 9

1.3.5 儘快地把更新的內容投入實踐 .... 9

1.3.6 規範化，堅持按照規範來行事 .... 10

1.3.7 文檔化 .... 10

1.3.8 使用源代碼控制工具 .... 10

1.3.9 招聘 .... 10

1.3.10 避免提供商鎖入，同時和你的提供商保持良好的關係 .... 10

1.3.11 給開源一個機會 .... 11

2 系統管理員必須遵照的鐵律 ... 11

2.1 優秀的Windows 管理員應該具備的 9 大品質 ... 11

2.1.1 無編輯器操做 .... 11

2.1.2 高權限的覺醒 .... 11

2.1.3 工做站比服 務器更重要 .... 11

2.1.4 Google 搜索，而不是編碼 .... 11

2.1.5 咱們更喜歡測試過的解決方案 .... 11

2.1.6 「屍檢」是顧問們的事情 .... 12

2.1.7 咱們知道咱們不知道什麼 .... 12

2.1.8 不管這個問題是誰提出的，咱們都假設這個問題是咱們本身的問題 .... 12

2.1.9 網絡安全也是咱們的工做 .... 12

2.1.10 經驗分享：搞清楚什麼時候應該跟注，什麼時候應該棄牌（重啓） .... 12

2.2 優秀的Unix 管理員應具備的 9 大品質 ... 12

2.2.1 咱們不使用 sudo . 12

2.2.2 咱們使用 vi ，而不是 emacs ，更不多是 pico 或 nano . 12

2.2.3 咱們把正則表達式當成咱們的利器 .... 13

2.2.4 咱們天生就比較懶惰 .... 13

2.2.5 咱們更喜歡優雅的解決方案 .... 13

2.2.6 咱們通常對事不對人 .... 13

2.2.7 咱們研究問題的時候，比醫生的 檢查還要細緻 .... 13

2.2.8 關於 Windows ，咱們知道的也不少（過去咱們只是裝做不知道而已） .... 13

2.2.9 幾乎歷來都不選擇重啓 .... 13

2.3 系統管理員必須瞭解的六大鐵律 ... 14

2.3.1 永遠不要修改服務器或網絡設備的鏈接接口 .... 14

2.3.2 保證老是有辦法回到原點 .... 14

2.3.3 文檔，文檔，仍是文檔 .... 14

2.3.4 在 IT 領域，不存在魔法，可是卻存在幸運 .... 14

2.3.5 在你修改每一個配置文件之前，要對它們進行備份 .... 14

2.3.6 監控，監控，仍是監控 .... 15

2.4 Linux 系統管理入門必須經歷的三步 ... 15

2.4.1 熟悉 Linux 以及發行版 .... 15

2.4.2 熟悉相 關的應用程序 / 服務 .... 15

2.4.3 編寫代碼 .... 16

2.5 系統管理員應該按期完成的九件事 ... 16

2.5.1 配置管理 .... 16

2.5.2 備份 .... 16

2.5.3 測試你的備份 .... 17

2.5.4 日誌輪換 .... 17

2.5.5 資源監視 .... 17

2.5.6 進程監視 .... 17

2.5.7 安全加固（ Hardening ） .... 17

2.5.8 安全更新 .... 17

2.5.9 日誌監視 / 安全掃描 / 入侵檢測 .... 18

2.6 運維人員應該時刻謹記的十條安全法則 ... 18

2.6.1 網站用戶的身份認證 .... 18

2.6.2 網站數據的加密傳輸 .... 18

2.6.3 用戶帳號使用行爲的日誌記錄及其審計 .... 19

2.6.4 惡意用戶流量的檢測、過濾及阻斷 .... 19

2.6.5 對非正常應用請求的過濾和處理 .... 19

2.6.6 合理的子網劃分及流量分割 .... 19

2.6.7 負載均衡及負載保護機制 .... 19

2.6.8 災難備份及恢復 .... 19

2.6.9 管理規範化 .... 19

2.6.10 網站漏洞自我挖掘及防禦 .... 20

3 系統管理員軟硬技能 ... 20

3.1 漫談運維：半神半仙亦民工 ... 20

3.1.1 架構設計 ... 22

3.1.2 IDC 選擇 ... 22

3.1.3 服務器上架 ... 23

3.1.4 安裝系統和佈線 ... 24

3.1.5 資產統計 ... 25

3.1.6 監 控架構 ... 26

3.1.7 企業實際面對的一些問題 ... 27

3.2 系統管理員須要掌握哪些軟技能？ ... 28

3.2.1 軟技能之一：自動化 ... 29

3.2.2 軟技能之二：時間管理 ... 29

3.2.3 軟技能之三：組織結構 ... 30

3.3 系統管理員易犯錯誤及解決方法彙總 ... 31

3.3.1 安裝FreeBSD 後沒法重啓 ... 31

3.3.2 更改 Admin 密碼致使計劃任務沒法執行 ... 32

3.3.3 root 密碼更改後沒法遠程登陸 ... 32

3.3.4 鎖定了SSH 會話 ... 32

3.3.5 移走硬盤形成Emergency 模式 ... 33

3.3.6 sudoer 文件損壞形成沒法進入 root 模式 ... 33

3.3.7 root 密碼被更改 ... 33

3.3.8 依賴的庫文件丟失致使root 沒法登錄 ... 33

3.3.9 忘記以su 模式進入編輯器 ... 34

3.4 系統管理員應該怎樣高效的書寫文檔 ... 34

3.4.1 爲何系統管理員應該學習編寫文檔 .... 34

3.4.2 如何編寫文檔 .... 34

3.4.3 其餘注意事項 .... 35

3.5 系統管理員之企業生存守則 ... 35

4 系統管理員的軟硬件維護清單 ... 38

5 門戶網站運維經驗談 ... 47

5.1 什麼是門戶網站運維? . 47

5.2 運維工做師須要什麼樣的技能及素質 ... 48

5.3 運維工程師的職責 ... 49

5.4 維職業的迷惘、現狀與發展前景 ... 49

5.5 運維關鍵技術點解剖 ... 50

 

 

 

1   Dormando 的系統運維祕訣三部曲

本文是 SixApart 的 MySQL DBA ， Dormando 在 2008 年總結的一套運維祕訣。編者前日看到 Google 系統管理員 TomLimoncelli 在 EverythingSysadmin 上推薦這篇文章，並表示這篇文章的內容在今天仍然適用。閱讀之下，發現的確是篇可貴的好文章，有大量的經驗分享總結。如今 51CTO 系統頻道特將本文全文翻譯過來，看成給各位運維讀者們的 2011 新年禮物。

如下爲正文。

在運維管理的過程當中，我發現了不少有價值的祕訣，本文是這些祕訣的一個總結。雖然這些祕訣可能比較「惟心」，可是我仍是把它們總結出來了，相信它們會對你有幫助的。

Dormando 的運維祕訣分紅如下三大篇：

技術篇

交流篇

實踐篇

下面先從技術篇開始。交流篇和實踐篇會陸續整理放出。

1.1   技術篇

1.1.1   爲變化而設計

Google 的祕訣是正確的——「爲變化而設計」。「變化」就是不得不部署新的軟件，升級現有的軟件，進行擴展，設備損壞，以及人員流動等。

每一件事情都是在尋找平衡點。你也許會認爲把你的系統和某個操做系統或某個 Linux 發行版緊緊地綁定在一塊兒是一個好主意，但事實上這跟把它們徹底隔離同樣糟。若是實在有必要，你能夠進行分層，並使用一點間接性。

這並不意味着你的系統必須是平臺無關的。其實咱們的目的很簡單：一變二，二變二十，一個系統必須能夠應對各類突發事件。也就是說，若是一個系統管理員被公共汽車撞了，你有應對的方案！若是掛載的硬盤出現故障了，你有應對的方案！若是某些人運行了 rm -rf / ，你也有應對的方案！增量的進行變動。記得安全更新，以及保持內容更新。

1.1.2   使用自動的，可重複的構建過程

不要手動構建任何東西。若是你必定須要手動構建，那麼就作兩遍，在作第二遍的時候把用到全部的命令都提取出來。

下面這一點十分重要：將新硬件上線到生產環境的過程不該該超過 15 分鐘，並且這個過程必須足夠簡單。不然，當一個服務器出現故障，而沒有人知道如何更換它的時候，你就該倒黴了。

下面這一條是普世真理：這個世界上不存在「一次性」的服務器構建。即便你的服務器只須要構建一次，但只要你構建過一次，就必定會有第二次。好比，當它損壞的時候，或者你必須進行一次重大的升級才能讓它在在接下來的兩年時間裏更加穩定的時候。

測試，檢查新構建好的服務器。這應該是比較容易的，由於你的構建過程都是自動化的，對吧！

腳本化的構建，意味着從某個 Linux 發行版的 V3 升級到 V4 應該是很快的。安裝
V4 ，對腳本進行測試。若是有問題，參考文檔並修復它，直到它能夠再次正常工做。這最多應該是一個星期的工做，而不是一個長達一年的浩大工程（由於那時，剛剛完成的 V5 已經發布了！）

1.1.3   使用冗餘

容易從新構建，並不意味着你能夠忽視冗餘。跳轉盒，郵件服務器，計費網關，等等。若是其中的一半掛掉了卻並不形成客戶的宕機，生活將會變得更加簡單。

按照以上方針來作的話，當某個設備在凌晨 3 點出現故障的時候，你能夠「之後再處理那個出現故障的設備！」，把冗餘的機器先替換上去。

下面這一條是個聊勝於無的解決方案： Rsync 。 DRBD 也許也不是一個完美的解決方案，可是它能夠提供使人稱奇的服務。（參考閱讀： DRBD 筆記 ， DRBD 實例 1 ， DRBD 實例 2 ）

1.1.4   使用備份

備份是個嚴肅的話題。使用硬盤，燒錄磁帶。壓縮它們，移動它們，並行地運行。對每同樣東西進行備份！

若是你的構建過程是自動的，整個過程均可以被備份。若是到目前爲止的幾條你都作到了，那麼一個真正的「災難恢復」計劃也許並非那麼高不可攀的。

1.1.5   監控正確的東西

監控你能監控的全部東西，並且要用正確的方法來進行監控。若是你的 NFS 服務器掛掉了，不要讓你的監控工具發送 1000 條警報。若是對你的系統來講，超時的警報沒有什麼實際意義，那就別讓它發。要針對各類具體的狀況進行成功性測試：是的，這個服務能夠進行一個新的 TCP 鏈接，它甚至能夠響應，可是它還記得它要作什麼工做嗎？

若是你有 500 個 Web 服務器，其中一個掛掉了，你可能沒必要立刻知道這個狀況。可是，若是負載均衡器沒有把這臺機子踢出去，致使錯誤報告出如今了用戶的屏幕上，那麼你必須知道這個狀況！

1.1.6   有關數據圖形化，歷史數據

圖形的做用是讓趨勢可視化。歷史數據的做用是讓你對數據進行精確的分析。不要把這二者混爲一談！對圖形進行目測，很容易得到錯誤的數值。許多站點都使用 rrd 類型的系統或其餘的數據聚合系統，此類系統按照時間對數據進行平均化處理，而後保存在存儲空間中。這不只僅是難以閱讀的問題：這根本是錯誤的！

若是你要瀏覽數百張圖才能精確地對一個問題進行定位，那真是糟透了。想要找出極值？請使用腳本提取數據。

若是你必須使用圖形來解決問題，儘可能把各類高級的概念整合到一個單一的頁面中，而後讓這個頁面連接到擁有具體信息的子頁面中。若是你在數據庫負載中能夠看到一個峯值，你能夠點擊這個頁面對那些數據庫進行概覽，而後找到那一兩臺可疑的機器。基本的理念是儘快地縮小範圍，儘量的減小猜想。

1.1.7   日誌記錄，使用多個數據流

不管是獨立工做仍是與開發部門合做，都要把儘量多的有用的信息記錄到日誌中。不管是分析以後再保存，仍是直接扔進數據庫中生成報告，這些都無所謂。信息終歸是有用的。

有用的例子：頁面呈現時間（哪一個頁面？哪一個設備？），面向用戶的錯誤，數據庫和內部服務錯誤，帶寬使用率等。

創建圖表，報告，並對產生的歷史數據進行比較。

報告是十分重要的。每週或天天對你的基礎設施變動進行彙總。

1.1.8   數據存儲方式，數據庫

誠然，數據庫運維是一套完整而獨立的知識體系。可是有時，你不能把一切都丟給你的 DBA 。

擁有多個冗餘的數據庫會給你帶來不少好處。對於一個龐大的 Oracle 實例來講，從前，不少運維工做須要好幾個小時的關機維護時間；而如今，徹底能夠在服務運行的同時進行。 MySQL 和數據庫複製功能是一件奇妙的事情。

和 DBA 們一塊兒努力，儘可能爲可能會發生問題的數據庫爭取到最好的硬件。 RAID 10 ，大量的 RAM ，高速硬盤，乃至於強悍的 RAM 磁盤和 SSD 。運維人員對提供商要貨比三家，這樣能夠減輕 DBA 對硬件的恐懼。從長遠來看，找出哪一個品牌的硬件更加優秀會節省大量的資金。

數據庫配置一直在改變。如今出現了 HiveDB ， MySQL Proxy ， DPM 這些軟件。咱們絕對應該對巨大的數據集進行分割。咱們也能夠考慮一下像 starling 和 Gearman 這樣具備必定創新性的軟件。瞭解一下這些軟件的用途，同時，瞭解一下並非一切東西都要保存在一個數據庫中的。

善用你的過濾器！若是這些數據很重要，應該對它們進行備份！單片的 NFS 服務器的快照很奇妙，它並非一個備份！

能夠慮一下替代的解決方案。 MogileFS 如今變得愈來愈好了（參考閱讀： 分佈式文件系統試用比較 ）。實際上，還有其餘相似的項目能夠免費（或廉價）地維護大量的存儲文件。相似的系統基本上都是是爲 youtube.com 、 archive.org 等站點而開發的。咱們最終會讓廉價的 NFS 過濾器成爲標準！

1.1.9   多一些橫向擴展，少一些縱向擴展

橫向擴展是咱們應該走的路。應該使用常規的（即：可用的，價格適中的，標準的。而不是特便宜的！）硬件，而後和你們一塊兒努力，確保各方面均可以進行橫向擴展。

橫向擴展從兩臺機子開始。另外，進行冗餘的時候也會涉及到橫向擴展。

儘量的橫向擴展，可是不要傻乎乎的擴展。在 MySQL 複製中有一個經典的白癡擴展的例子：使用一個 master 對不少個 slave 。全部的 slave 必須完成所有的寫入，而寫入次數是與讀取次數成比例增長的（大多數應用都是這樣）。也就是說，你添加的 slave 越多，經過添加 slave 擴展的資源就越少。

留意一下替代的解決方案。按照用戶或區域對多個數據庫進行劃分，同時避免增長過多的 slave 。實際上，有許多種方法能夠達到這個目的。

一切均可能擴展！路由器，交換機，負載均衡器， Web 服務器，數據庫，等等。

記得縱向擴展嗎？之前那些邪惡的大型機們有不少核，不少 IO 板，配備了很是昂貴的存儲設備。而如今，多核這個概念開始蔓延了。

RAM 是廉價的。

將以上兩點合併起來，這意味着你只須要再次合併服務就能夠了。這兒有一個負載均衡器，那兒有一個 Web 服務器……若是一個應用程序能夠使用許多個 CPU （好比 apache ），那麼這是完美的。若是它不能（好比 memcached ），那麼你最終可能會因爲離散的服務太多而浪費掉大量的可用資源。

做業系統（ job systems ）也許能夠填補這個鴻溝。哪裏的核心的越多，哪裏的工做線程就越多。

1.1.10   緩存

對於開發者和系統運維人員來講，緩存但是個好東西，值得大力發展！的確，它是難以想象的。它是不同凡響的。有時你可能必需要爲它作一個權衡。有效地使用緩存能夠讓系統的總體性能提高 10 倍之多。對於你當前的系統來講，這是一個巨大的「放大鏡」，而且，它的成本在總成本中只佔很小的一部分。

Memcached 。它能夠爲服務提供緩存，讓數據庫結構非標準化（這能夠提高性能！），對 squid 緩存進行優化，甚至能夠提升操做系統緩存的利用率。

測試它，玩弄它，並打破它。使用緩存會帶來新的問題。要作好準備。

1.1.11   讓工做異步化

能夠使用 Starling, Gearman, The Schwartz 等工具。做業系統能夠給應用程序提供更多的靈活性。工做線程能夠一次性地產生出來，也能夠是持久的（載入緩存數據，準備數據等）。它們能夠在不一樣的硬件上，它們的地理位置也能夠不一樣。它們既能夠是同步的，也能夠是異步的。

維護這些東西是一個運維人員的問題。使用它們既是開發者的問題也是運維人員的問題。

當用戶點擊「給我全部的朋友發送郵件」的時候，把這個工做列入計劃，而後立刻說：「 OK ，已經完成了！你的朋友立刻會收到你的郵件！」——經過異步化的方式來處理這個工做。

做業系統是銜接各個服務的一個場所。博客投遞 - 〉 IM 通知，按期計費 - 〉收費服務，網關認證等。

容易擴展。在請求進入的地方會有一些瓶頸，全部的工做線程必需要作的事情就是「拉」。這個是相對於 HTTP 中大量推 / 拉的狀態而言的。

1.1.12   安全和巡查

必定要安裝安全更新！這十分重要！有不少瘋狂的網絡專家致力於在儘量短的時間內給你提供這些更新。不要由於你懼怕改變而讓他們白白地付出勞動。

安全性也是分層的。明白你能確保什麼，以及不能作什麼。 MySQL 有密碼訪問機制，並不意味着能夠容許直接經過互聯網來訪問它。

在 SSH 上禁用密碼。使用通過加密的 passphrase 密鑰來進行身份驗證。遠程的用戶沒法猜出你的私有密鑰。他們必須從你這裏才能獲得它。把它保管好。作好這點，就不必在防火牆中關閉你的 SSH 端口了。

搞清楚你的應用程序是如何工做的，它具體須要作些什麼，並相應的進行調整。好比說，若是你的應用當中，只有付費頁面和 Twitter 投遞服務是須要鏈接外部互聯網的，那麼就把它們作成工做線程。將這部分工做線程放在特定的設備中，讓它們只能訪問特定的主機。這能夠神不知鬼不覺地把你的網絡的其他部分保護起來。

對於 PHP 站點來講，以上這些建議尤爲重要，可是在其餘地方，它們也能夠發揮做用。若是有人要入侵，那麼多半是經過你的應用。即便有人從前門入侵了系統，也要讓他們花費很大精力才能進入保險箱。你須要確保的是他們沒法將數據帶走或上傳至別的什麼服務器上。

除了這些具體的建議以外，你還應該多讀一些資料。本身判斷，本身動手測試。若是你不知道一個安全模型是如何工做的，一時半會兒可能問題不大，可是這就會致使你不知道它的限制在哪裏，甚至於沒法判斷它是否在工做。

基於測試，理論，攻擊樹的安全機制是不會在背後給你一刀的。當人們構想出模糊的安全模型的時候我也很喜歡它，可是像我這樣的普通人均可以把它弄的支離破碎。

儘量地進行巡查！登陸，退出，以及使用的命令都要進行審查。對面向外部服務的全部訪問，包括全部在請求中指定的參數，都要進行審查。對於你的應用程序來講，找出極值，而後完全禁止輸入超出範圍的值。作你能作的全部事情，讓數據以可追溯的方式工做。

若是你懷疑某些東西可能會被破壞，應該採起適當的預防措施，最好懂得一點計算機取證方面的知識（或者聘請一個專門從事這項業務的公司）。經過移除可疑的網絡訪問來作出響應，經過一系列的控制檯或直接經過終端來檢查整個系統。在已經被破壞的機器上，避免使用任何的服務，配置文件，或數據。不少人都是「清除了一個木馬」，可是不知道它是怎麼進來的——這樣並不算真正地清除了這個木馬。

若是你有安全團隊，取證專家，或其餘人手，那麼你儘可能不要接觸那臺機器，把它隔離起來。這意味着不要從新啓動它來「清除一些奇怪的進程」。他們須要這些證據。若是你必須這麼作，就去作吧，可是要記得把系統完全地清理乾淨，打上全部的安全更新，儘可能搞清楚他們是否已經破壞了重要的數據。作你能作的全部事情。

安全其實是一種權衡。若是你作錯了，開發者和用戶們都會「揭竿而起」：他們會找到一些方法來繞過安全機制。若是他們能夠繞過它，那說明你的工做並無作好。若是他們不能繞過它，那麼他們也許會放棄，而後離開。

緊抓訪問控制。這意味着運維人員必需要爲已經鎖上門的「房間」提供一些窗戶。不讓開發人員進入生產環境，意味着他們必須抹黑解決難題。你的確不能讓開發者們直接對服務進行修改，可是你能夠提供日誌工具和調試工具等等。對於各類產品來講，這些都是成功的祕訣。

【 51CTO.com 譯稿，轉載請註明原文做譯者和出處。】

原文： Dormando's [crappy] Operations Mantras

1.2   交流篇

在以前咱們已經介紹過了 技術篇 的內容，講述了有關變化、自動化、冗餘、備份、監控、日誌、數據庫、可擴展性、緩存、以及安全方面的祕訣。今天介紹的第二篇是交流篇，講述的是有關運維的知識積累、經驗積累、協同合做、我的成長方面的內容。其中有些內容不只是站在運維自己的角度來考慮，同時也對運維的管理者提出了建議。

交流篇

1.2.1   經過多種方式來學習

訂閱一些 RSS feed ，每星期至少閱讀幾篇好文章。 LWN ， kerneltrap ， undeadly.org 。凡是相關的，或是僅僅是有點擦邊的內容都應該關注。

閱讀「達人」的博文。有時他們會投遞一些有趣的主題，而且咱們還能夠經過評論直接和博主進行交流。

閱讀幾篇非「達人」的博文。經過他們遇到的問題，或者他們作了但沒有作好的工做，咱們能夠找到一些感受。（譯註：這一點我我的深有體會。閱讀一些新手的博文，咱們經常能夠獲得啓發，由於咱們的一些作法雖然不會出問題，可是太程式化了，天天都重複一樣的事情，咱們沒法進步，而新手因爲缺少經驗，他們會不斷地嘗試各類作法，他們遇到的問題極可能是咱們沒有遇到過的，這對咱們來講是一筆財富。）

想盡辦法認識一些能夠「痛扁」你的人。注意，必定要謙虛。

經過多種來源學習。經過多種方式吸取知識有助於找到最適合你的方式。

仔細研讀其餘公司成功或失敗方面的故事。能夠嘗試打電話給他們的 CTO ，經過免費的午飯從他們那裏獲取一些有價值的建議。

1.2.2   嘗試各類事情

若是你不斷地進行嘗試，你會發現你能作的事情遠遠超出了你的想象。之前歷來沒有見到過？那就試試看。

儘可能不作一隻危險的「菜鳥」。在你有把握不會把整個房間都燒掉之前，應該在「沙箱」中進行嘗試。

1.2.3   真正地搞清楚冗餘是怎麼一回事

真正地搞清楚冗餘會對哪些事情形成怎樣的影響。在什麼狀況下它能夠發揮做用，在什麼狀況下它沒法發揮做用。

嘗試破壞你的系統。你能夠在測試實驗室中嘗試，有時也能夠在生產系統中這樣作。瞭解一下當你處於受限狀態中的時候能夠作什麼。好比，拔掉電源，抽出網卡，殺死進程，拔掉幾根內存，抽掉硬盤，拔掉網線。

在冗餘存在的狀況下嘗試替換和升級系統。

1.2.4   真正地理解可擴展性

關於如何開發出可擴展的系統，有不少的資料能夠參考。雖然你不用本身編寫一個這樣的系統，可是你要儘可能搞清楚這方面的理論知識。

學習虛擬化。建立幾個虛擬機，而後嘗試着擺弄一下針對多臺機器的應用程序。在本地的不一樣的端口上運行多個實例。

一般，運維人員要作一些系統承載量方面的計劃。若是你不清楚應該把什麼資源應該添加到哪裏，你就不會知道應該添加些什麼。

1.2.5   成爲一個可以解決問題的超級明星

問題突然發生，而時間是寶貴的。你必需要有本身的知識儲備，並高效的使用它們。

常常練習着解決問題。挑選出一個能夠正常工做的完美頁面，而後試着跟蹤一下它是如何工做的。

strace, ltrace, lsof,logs

搞清楚 load != load （編者注：此處理解爲 load 參數不等同於真正的系統負載狀況）。主機運行狀況的全部信息都須要查看。

熟悉 IO 系統相關的工具。「難以想象」的性能問題一般都是因爲你的 RAID 或 SAN 配置出了什麼問題。

記錄文檔。 Checklist ，解決問題的技巧，構建工具等。

構建更多的工具。不僅是爲了你本身，也是爲了其餘人。你也能夠給現有的工具添加一些功能。

1.2.6   和 IT 人員一塊兒工做

信不信由你，運維人員和 IT 人員之間存在交集。

運維人員必需要爲服務器維護高帶寬的網絡訪問。 IT 人員必需要作一樣的事情，只是他們的服務對象是人。 IT 人員也每每是運維人員進入數據中心的「橋樑」。在這一點上，你們在一塊兒工做是頗有實際意義的。

彼此的分工要明確。 IT 人員應該負責管理郵件，而運維人員應該負責管理開發環境的服務器。不要插手職責以外的事情，盡最大的努力把你本身的事情作好。

不要疏遠他人。 Mac 是流行的， Linux 也（慢慢地）得到了一些市場份額。信不信由你，強迫你們都使用微軟的生產軟件可能會對你形成很差的影響。實際上有許多替代品，你能夠試試看。在你的公司中，極可能熟悉 Google 應用的人比熟悉 Outlook 的人要多。

儘量的讓你們以爲 Unix 並不難用，畢竟這是他們要支持的系統，你確定但願他們對 Unix 更加熟悉一些。固然，除非你家裏是賣 Windows 的。

1.2.7   和開發人員一塊兒工做

大家都爲同一個產品工做，大家的目的也是一致的。試着多配合一下。

一塊兒開策略會議並不等於在一塊兒工做。

開發人員更瞭解代碼資源，運維人員更瞭解硬件和部署。把這一切都記在內心，你能夠讓一些事情變得更高效。

交叉培訓。傳播雙方使用和設計工具的心得，這能夠提升工具的可管理性和靈活性。

注意不要過多地要求對方。這不是「咱們」 VS 「他們」。每個人都是有人權的。每個人都應該儘量地爲公司多作貢獻，而不是爲了他們本身。

若是你們相處的很融洽，就能夠從容地應對各類緊急事件了。

1.2.8   和其餘領域的運維一塊兒工做

每一個領域的運維都有他們本身的專長。網絡，數據庫， OS 。不要忘記彼此多交流！

一味地墨守陳規是消極的，使人厭煩的。讓你的運維們重複的作相同的工做能夠很快的增長他們的流失率。要尊重系統運維們在網絡運維們的背後觀察學習的機會。

時刻記得給人們嘗試，學習和成長的機會。

注意別給你最優秀的運維安排了太多的活兒。你想要用的運維是那種有能力給本身找出空閒時間的人。

渾水摸魚者（編者注：原文爲 bad eggs ，直譯爲壞蛋）。對待他們要足夠強硬。大多數人在幫助之下是能夠完成任務的，可是他們必需要學會獨立。

【 51CTO.com 譯稿，轉載請註明原文做譯者和出處。】

原文： Dormando's [crappy] Operations Mantras

1.3   實踐篇

1.3.1   如今就修復它，而不是之後再修復它

若是一個 Web 服務器處於脫機狀態，不要擔憂，由於你應該有 10 個備用的！

在一週中，專門挑出一天來「清理門戶」。更換掉全部存在故障的硬件。在歡度週末以前，確保一切都是完整無缺的。

若是使人討厭的小問題忽然發生了，在早上要作的第一件事情就是永久性的修復它們。日誌塞滿磁盤的狀況在上週發生了兩次？明天再說吧！若是老是這樣，這些問題會堆積起來……

若是你的構建過程是自動化的，充分利用這個優點來修復一些你能夠立刻修復的問題，或許也能夠批量進行修復。

1.3.2   讓每一件事情都自動化

人們沒法（輕易地）搞亂腳本化的任務。

從第二次開始自動化。若是第一次你必須手工來作一件事情，那麼把你作的事情寫入一個腳本。

帶註釋的腳本是絕佳的文檔。與其把如何安裝一些東西的方法詳細地寫到長達 20 頁文檔中，還不如編寫一個能夠自解釋的腳本。

腳本能夠被放到自動化的構建過程當中。若是要更接近這個目標，應該把一些常常作的事情都應該變成「零時間」的任務。

1.3.3   只進行必要的變動

只作小規模的，獨立的變動。

若是不是必須改變，那麼就保持原樣。

這也意味着你必須搞清楚何時才應該進行變動。找出什麼東西是必需要進行變動的，而後對它進行升級，把它拿出來，讓它標準化。

1.3.4   Design for change

這裏的 Design for change （編輯注： 技術篇 的第一條也是 Design for change ）針對我的的成長。朝快速解決問題大師的方向努力吧。

若是快速解決問題比較困難，那麼你能夠學習一些基礎知識，作出一張清晰的升級路線圖。雖然你的新郵件系統也許並非你夢想中的、帶有強大反垃圾郵件功能的巨大系統；可是架設兩臺配置乾淨的 postfix 郵件服務器會比你想象中的效果還要好。

你們都傾向於把未完成的項目放在那裏置之不理。這是你要避免的。

1.3.5   儘快地把更新的內容投入實踐

通常來講，運維工做就是要讓代碼更好地運行。並行化，創建起回滾重啓機制。

運行內容包括軟件更新，安全補丁，配置變動。

使用 puppet ， cfengine 以及你須要的任何工具對配置進行控制。讓它乾淨，簡潔，而且容易操做。

文件數量越少越好。若是隻是爲了推出一個新的數據庫就要在 20 個文件中分別添加一行，那麼你的方法必定是錯誤的。建立簡單的模板，不要重複編輯須要手工編輯的數據。

1.3.6   規範化，堅持按照規範來行事

OS 的規範， httpd 的規範，數據庫的規範，打包系統的規範。

堅持按照這些規範來行事。對一些方法進行調整和改進，讓它變得更有意義。

永遠沒關係抓着主版本不放。若是你的產品功能尚未永久性地凍結，你就必需要按照規範繼續向前推動，把過去的一些事情都拋在腦後。

按照規範來作的事情越多，你的工具能夠發揮做用的場合就會越多。用於支持其餘運維領域的軟件包越多，能夠適應的場景也越多。

1.3.7   文檔化

把流程文檔化

把產品文檔化

Deep Trees 和ShallowTrees

不要讓文檔出現冗餘。若是一個腳本的幫助文檔很長，能夠進行引用。好的文檔是一個持續改進的過程，它要一直保持準確。

把文檔和代碼， perldoc ， pydoc 等聯繫起來。

過時的文檔是有害的。留出一些時間來更新它們。當新的員工遇到問題的時候，和新的員工坐下來一塊兒更新文檔。

適當地使用問題跟蹤系統（ issue tracking ）。爲操做歷史保留文檔是十分重要的，以免爲了某個 DNS 故障的重現去騷擾他人。

1.3.8   使用源代碼控制工具

使用 git 或者 mercurial 。避免使用 SVN 。

把配置文件、腳本等各類東西都放到源代碼控制工具中管理起來。

爲代碼遷出提供各類入口。

保持遷出的嚴謹性，精準性和可控制性。禁止提交沒法進行審覈的變動。應該提交的變動應該是不用源代碼控制工具也能容易地進行測試的（在虛擬機環境下，能夠直接在一個單獨的測試機器上進行測試）。

1.3.9   招聘

區分出執拗的人和精明的人

不要避免聘請「老前輩」。某個領域的「老前輩」可能已經跟不上技術變革的腳步，以致於你可能不想聘請他們。可是，老是要有幾個「超級巨星」來壓住陣腳的。

不要避免聘請新手。我認識的不少人都是從一個真正的新手開始的（包括我本身！實際上，我認爲我本身一直是一個新手）。通過這個階段之後，他們會迅速地成長起來。如今正是確立職業生涯的時候。我相信咱們中的絕大多數人都是這樣的。固然，不包括那些不學習的人，沒有積極性的人，或者入錯行的人。

1.3.10   避免提供商鎖入，同時和你的提供商保持良好的關係

購買專有硬件的主要劣勢是提供商鎖入，你不得不老是使用這個提供商的產品。這多是一個特殊的 SAN ， NAS ，也多是特殊用途的隨設備存儲，備份系統等等（ 51CTO 推薦閱讀： 別把雞蛋放在一個籃子裏 ）。儘可能避免發生這種事情。若是你徹底按照上面的設計建議來行事，那麼應該能夠很快地在不一樣的平臺上搭建起測試環境。而後，你能夠進行硬件評估，自由地進行選擇。

若是全部東西都很深奧，都很不明朗，都尚未通過文檔化，而且直接依賴於專有的負載均衡器……那麼最好別用，由於用了你就不自由。

對你最終選擇的提供商好一點。若是你每一次採購都在價格方面把他們逼到牆角，那麼你只能獲得一些垃圾硬件了。

有時候數據中心有不少潛在的可用資源。儘可能把一些免費的遠程協助服務寫到合同裏，好比就更換硬盤驅動器，提供商的出貨 /RMA 條款，以及一些基礎硬件的安裝等方面的細則進行談判。我有一個機架的設備，其安裝上架的過程咱們的人徹底沒有操心……真的很不錯。

1.3.11   給開源一個機會

nginx ， mongrel ， lighttpd ， apache ， perlbal ， mogilefs ， memcached ， squid ， OpenBGPD ， PF ， IPTables ， LVS ， MySQL ， Postgres ，等等。在你選擇可信、可靠、昂貴的專有安裝程序之前，給開源一個機會。你會發現使用開源軟件意味着能夠本身添加插件，擴展，代碼修復補丁，或者你能夠把一些本身沒法實現的功能外包出去。在我看來，開源軟件是很可靠的，它們一般比巨大負載之下的大型的，昂貴的硬件更可靠。

「一分錢一分貨」這種思想是一個完全的謊話。若是你沒法讓開源軟件爲你工做，須要協助，你能夠找一個提供商。若是你的團隊既睿智又積極主動，這些小夥子們想要搞清楚他們的基礎設施是如何工做的，那麼你必定沒法抵擋來自於 GPL 或 BSD 系統的誘惑。

MySQL 和 Postgres 都不錯。若是你要使用它們，能夠權衡一下利弊。沒有什麼東西會在晚上從你的衣櫥裏爬出來「吃」掉你的數據。與通過測試的、穩定的冗餘 master<->slave MySQL 集羣實例相比，其實龐大的、處於脫機狀態的 Oracle 實例更容易把事情搞的一團糟。

關於 LAMP 架構的文章數不勝數。無數知名網站、 ISP 、甚至企業如今都在使用開源軟件。給開源一個機會。最糟糕的結果也不過是浪費一些時間，而最後從你那些心驚膽戰的提供商們那裏得到一些不錯的報價。

【 51CTO.com 譯稿，轉載請註明原文做譯者和出處。】

原文： http://dormando.livejournal.com/484577.html

2   系統管理員必須遵照的鐵律

2.1   優秀的 Windows 管理員應該具備的 9 大品質

最近一篇關於優秀的 Unix 管理員應該具備的 9 大品質的文章使 Mark Underwood 深受啓發，他認爲優秀的 Windows 管理員也應該具備 9 大品質。若是你願意的話，你也能夠添加一些你本身的品質。

《 優秀的Unix 管理員應該具備的9 大品質 》 的做者彷佛聽到了不少種不一樣的聲音。這是來自於 Windows 陣營的迴應。

2.1.1   無編輯器操做

咱們不須要臭名昭著的編輯器。腳本就很好，咱們欽佩那些精通 vi 和 emacs 的人，可是咱們不會對它們「頂禮膜拜」的。若是咱們必須要編寫腳本，咱們有 Powershell ，並且，咱們中的大多數人都忙於提高其餘 8 種品質，根本就沒有時間學習它們。

推薦專題： Windows 中的腳本技術-Windows Powershell

2.1.2   高權限的覺醒

Vista 那糟糕的公衆形象使咱們清楚地認識到了「低權限」和「高權限」的優缺點。套用一句丘吉爾的話，有些人歷來都沒有遭受過這麼多的苦難。在咱們的工做中，咱們清楚地認識到了這一點，並且，咱們的用戶社區也已經清楚地認識到了，對這個問題的漠視會形成怎樣的後果。

2.1.3   工做站比服務器更重要

服務器技術頗有魅力，並且回報也很大，可是，工做站上的管理服務水平真的很重要。當 CFO 的 Outlook 客戶端掛掉的時候，咱們要對整個供應鏈負責，從他 / 她的筆記本的 F9 鍵，全部的交換機和路由器，一直到他的 Exchange 郵箱，咱們都要檢查一遍。不管潛在的問題是什麼， Windows 管理員都會勇敢地接受現實，把它看成「 Outlook 問題」來處理的。

2.1.4   Google 搜索，而不是編碼

相對於其餘系統的管理員來講，咱們不會爲了編寫特定得腳本而給咱們的系統增長潛在的安全漏洞，即便這會影響重複性的，手工任務，咱們也在所不惜。取而代之的是，咱們會假設某些人在某些地方遇到了一樣的問題。咱們會跳到最近的瀏覽器會話上，而後搜索一個通過全面測試的解決方案（其餘人已經使用過這個解決方案了）。

2.1.5   咱們更喜歡測試過的解決方案

咱們儘可能不去當「炮灰」。咱們依賴於世界上最大的軟件公司來檢查咱們部署的產品，通過時間驗證的解決方案一般會賽過那些最新的，最偉大的解決方案。當一個用戶有一些很酷的東西要嘗試的時候，咱們會把他們轉到一個獨立的子網或 DMZ 上的一臺全新的虛擬機中的。

2.1.6   「屍檢」是顧問們的事情

咱們能夠像下一代極客同樣極客，也能夠像下一代極客同樣創造出比「 Stuxnet 」還要「優雅」的奇蹟，可是最終咱們是有「黨派」的，有組織類別的。當發現一個問題的時候，咱們也像其餘人同樣對問題的成因充滿了好奇——即便研究證實只是咱們犯了一個錯誤而已。可是一般狀況下，咱們都忙於處理下一次發佈，下一次危機，或者下一次升級，根本就沒有時間仔細考慮它們。咱們深知，一個嚴肅，公正，優秀的「屍檢」報告最好由一個公正的第三方來完成，而不是身心疲憊的管理員。

2.1.7   咱們知道咱們不知道什麼

雖然咱們也涉獵過 Red Hat 和 Ubuntu ，並且也曾爲了讓咱們的「 ServerFarm 」中的 Linux 機器能夠正常運行而費勁心力，可是咱們深知，那只是短期的涉獵，短期地接觸到了咱們不知道的東西。咱們寧願讓其餘人維護那些徹底用「 bash 」或「 csh 」編寫的應用程序，尤爲是那些沒有「 man page 」的應用程序。

2.1.8   不管這個問題是誰提出的，咱們都假設這個問題是咱們本身的問題

像其餘人同樣，咱們也能夠憑藉咱們在服務器和網絡產品方面的專業知識而趾高氣揚，可是在專家的世界中，咱們只是一些小角色。若是咱們是 CCNA ，那麼咱們知道的東西就不僅是告訴 Microsoft System Center Configuration Manager 她應該如何把新的虛擬機放到她的系統中，或者告訴她如何經過她的網絡來管理桌面許可證這麼簡單的。相似地，咱們也指望能遇到那些和咱們專業知識水平至關的臨時用戶提出的專業問題，咱們認爲這是一件好事情。當咱們須要幫助的時候，咱們也能夠請教這些用戶。

2.1.9   網絡安全也是咱們的工做

不管咱們是不是 CISSP 證書的持有者，咱們都應該讓咱們的企業儘量多地瞭解已經到位的各方面的安全措施。這幾乎涵蓋了從桌面磁盤加密到應用程序的每一件事情。咱們不會以「 Windows 一般是攻擊的目標」爲藉口來逃避責任的。

2.1.10   經驗分享：搞清楚什麼時候應該跟注，什麼時候應該棄牌（重啓）

這是事實。有時咱們不得不重啓 Windows 。固然，咱們但願咱們沒必要那樣作。咱們寧願和咱們的愛人待在家裏，看比賽，或者和朋友一塊兒喝啤酒。咱們很擔憂最新的補丁會影響穩定性，或者帶來新的漏洞。咱們常常提醒本身，沒有人能夠入侵一臺關閉的服務器。

2.2   優秀的 Unix 管理員應具備的 9 大品質

編者按：優秀的 Unix 系統管理員是怎樣工做的？來自 InfoWorld 的 Paul Venezia 嘗試爲咱們總結優秀 Unix 系統管理員的九大特色。 Paul 是一位資深編輯與諮詢師，關注 Perl ， PHP ， SQL ， FreeBSD ， Linux 和 Windows 等領域。

2.2.1   咱們不使用 sudo

就像「 caps lock 」對於極客來講只是一個無關緊要的控制鍵同樣， sudo 也只是膽小者的柺杖。若是咱們須要對 root 作一些事情，咱們須要 su 到 root ，這個 sudo 廢話毫無心義。

實際上，對於那些強制全部用戶都要使用 sudo 的類 Unix 的操做系統來講，咱們要作的第一件事情就是 sudo su - ，而後改變根口令，以便於之後咱們能夠更加方便地 su - 。使用 sudo 就像在帶有充氣減震器的水槽中打保齡球——的確很安全，可是你也別想一展身手了。

2.2.2   咱們使用 vi ，而不是 emacs ，更不多是pico 或nano

雖然咱們知道，對於許多 Unix 管理員來講， emacs 更貼心一些，可是，實際上它只是 Microsoft Word 的 Unix 翻版而已。 vi （和 vim ）纔是那些真正的 Unix 極客們手中的利器，他們須要在完成任務的同時，不被那些 emacs 自帶的毫無用處的東西把事情搞糟。 Emacs 竟然內置了一款俄羅斯方塊遊戲，簡直是豈有此理！

雖然我只能萬般無奈地認可 vim 中那些花哨的功能（例如：代碼摺疊和語法高亮）可能只是一時失誤，可是，在一天的工做即將結束之際，真正的 Unix 工做能夠和 vi 的模型編輯概念很好地融合在一塊兒倒是不爭的事實。除此以外，它那苗條的身材和通用的可移植性能夠讓它成爲一個真正的編輯器。感謝 Bill ！感謝 Bram ！（編輯注： Bill Joy 是 vim 編輯器的開發者，後來 Bram Moolenaar 對其進行了改進）。

編輯推薦： 有關vim 編輯器使用心得的十個分享

2.2.3   咱們把正則表達式當成咱們的利器

對於正則表達式的排斥，甚至是漠視彷佛都是「邪惡」的鍵盤形成的惡果。可是，對於咱們來講，它是如詩般優雅的。它的強大表如今，任何其餘的著名工具都沒法和 pcre (Perl Compatible Regular Expressions) 的複雜性相匹敵。若是你須要在 100000 行文件中替換掉每一行的第三個字符（除了那些後面是數字 4 的字符以外），那麼正則表達式不僅是完成這個任務的一個工具而已——它仍是完成這個任務的惟一工具。那些可憐的人時常會在他們的 email 中接收到一些字符串片斷和一些痛哭流涕的請求（尋求一個解析這些字符串的正則表達式），通常還會承諾請你喝一杯（可是歷來沒有兌現過）。

編輯推薦： 正則表達式徹底學習手冊：菜鳥入門指導

2.2.4   咱們天生就比較懶惰

當遇到一個看起來須要不少手工的，重複性的工做才能解決的問題的時候，咱們這些守舊派的 Unix 表明必定會選擇編寫一些代碼來搞定它的。這一般會比手工操做更加節省時間，雖然有時候事實也並不是如此。不管如何，咱們寧願把時間花費在能夠之後被引用或者使用的工做上面，也不肯意簡單地修復眼前這個問題。一般，當幾年之後咱們遇到了相似的問題，而後能夠從咱們的起始目錄（ home directory ）中的一個文件 yank 幾百行 Perl 代碼，在短短的幾分鐘以內解決掉了這個問題，而後回過頭去分析那些能夠提升工做效率的其餘代碼的時候，咱們就能夠得到回報了。或者，咱們也能夠去玩一下憤怒的小鳥。

編輯推薦： 怎樣作一個優秀而懶惰的系統管理員

2.2.5   咱們更喜歡優雅的解決方案

若是有好幾種方法能夠修復一個問題或者實現一個目標，那麼咱們會選擇花費更多的時間來開發一個既能夠解決當前的問題又能防止未來發生相似的問題的解決方案，而不是簡單地貼上一塊邦迪牌創可貼。這是由於咱們討厭再次遇到那些在咱們的印象中已經解決過的問題。咱們認爲，若是咱們能夠提早多考慮幾步，防止未來發生相似的問題，那麼在未來，咱們能夠節省更多的精力。一般咱們都是對的。

2.2.6   咱們通常對事不對人

enlightenment 有足夠的把握能夠讓你的 Unix 基礎知識達到必定的水平。這意味着咱們從不認爲一個問題會一直存到咱們發現它爲止。告訴一個優秀的 Unix 管理員，一個文件「 vanished 」了，他只會輕蔑地嘲笑你。證實給她看，這真的發生了，他就會不知疲倦地研究這個問題了，直到能夠找到一個合理的緣由和解決方案爲止。許多人都認爲這是傲慢和自負的表現。的確是——可是咱們有這個資本。

2.2.7   咱們研究問題的時候，比醫生的檢查還要細緻

當處理一個大問題的時候，咱們在「屍檢」上花費的時間要比咱們解決這個問題所花費的時間多得多。若是不是工做壓力太大，讓咱們無暇分身去研究這個問題，那麼咱們必定會搞清楚這個問題的確切緣由的。 在一個強悍的 Unix 管理員的工做中，不存在難以想象的現象。 每一種狀況必需要有邏輯起點，並且能夠按照合適的路徑來追本溯源。簡而言之，每一件事情都有緣由，在找到這個緣由之前，咱們毫不放棄！

對於咱們來講，經過 HUPping 一個進程，或者改變一個文件或 777 目錄的權限來「止血」是一件很容易的事情，可是這連成功的通常都算不上。爲何這個進程必需要重啓？這並非必須的，咱們須要知道爲何。

編輯推薦： 系統管理員須要掌握哪些軟技能？

2.2.8   關於 Windows ，咱們知道的也不少（過去咱們只是裝做不知道而已）

雖然在咱們本身的機器上，咱們可能並不運行 Windows ，並且，對於 Windows 服務器，咱們彷佛也不屑一顧，可是在診斷和修復 Windows 問題方面，咱們倒是行家裏手。這是由於，當它們的「鮮血」流到咱們的「版圖」上的時候，咱們必需要處理這些問題。可是，咱們不喜歡認可這個事實，由於大多數狀況下 Windows 都沒有 Unix 那樣深厚的邏輯基礎，這讓咱們很困擾。參見上面的品質五和品質六。

2.2.9   幾乎歷來都不選擇重啓

Unix 設備不須要重啓。若是並不是絕對沒有其餘選擇，咱們會花費數個小時在系統運行的狀態下修復這個問題，而不是重啓。咱們的想法是除了內核或硬件改動，其餘狀況下都沒有理由去重啓，重啓只是修復這個問題的臨時辦法而已。若是這個問題發生了一次，而且經過重啓被「修復」了，那麼它還會再次發生的。咱們寧願修復這個問題，而不是簡單地拔掉電源，等着它再次發生。

從「謊話」的角度來看，這些品質中的某些品質看起來會有點另類或者難以理解，那是由於他們原本就是如此的。其餘人只能看到棘手和困難的時候，咱們卻看到啓示，學習，經驗，更重要的是，咱們看到了邏輯。

【 51CTO.com 譯文，轉載請註明原文做譯者和出處。】

原文： http://www.infoworld.com/t/unix/nine-traits-the-veteran-unix-admin-276

2.3   系統管理員必須瞭解的六大鐵律

系統管理員們踏上崗位，都已經具有了一些有關係統和服務的知識，如如何搭建生產環境，如何備份，如何監控系統等等，這些知識可能來自學校，可能來自自學。然而在工做了數年以後，系統管理員們對生產環境中的操做又會有了不少新的瞭解。下面，資深運維專家 Paul Venezia 爲咱們總結了他認爲系統管理員在生產環境中必須遵照的六大鐵律。這是一些學校裏不會教的知識。遵照這些規則，你幾乎能夠解決任何一個問題。

在複雜的數據中心基礎設施中，這種能力能夠讓你經過豐富的經驗和自身的知識快速而準確地發現問題之所在。這種能力只可意會，不可言傳。沒有人會提供和「超天然故障排除」有關的認證的。

可是，那些重量級的問題解決專家都會遵照一些通用的，不成文的規則。這是我本身使用的六個規則。注意，它們適用於大多數狀況，可是並非全部狀況。

2.3.1   永遠不要修改服務器或網絡設備的鏈接接口

雖然這聽上去很簡單，可是，使人吃驚的是，人們常常會修改他們用於鏈接到某個設備的網絡接口的屬性，這種行爲的失敗率很高。有時，這條規則多是可選的，可是，若是有一種方法能夠排除潛在的隱患，何樂而不爲呢？若是你不得不修改這個接口，能夠在這個接口上配置一個輔助 IP （ secondary IP ）——經過另一個設備或子網，串行控制檯， KVM 等來鏈接。若是設備放在遠程的辦公室裏（那裏沒有 IT 職員），那麼這絕對是一條真理。

2.3.2   保證老是有辦法回到原點

不管什麼時候，只要有可能的話，都要提供一種能夠把問題恢復到原始狀態的方法。這意味着，在對故障磁盤作任何修改之前，應該爲這個故障磁盤作一個映像，備份整個目錄結構（你不可能知道你之後須要哪些文件，這樣能夠以防萬一），或者，在你胡亂擺弄一個已經出現故障的操做系統之前，應該在物理服務器上抽取出這塊磁盤的 RAID1 陣列。固然，在虛擬機環境下，這會更加容易一些，由於你能夠簡單地作一個快照。

2.3.3   文檔，文檔，仍是文檔

在全部這些規則中，這條規則也許是你們最少遵照的規則了。毫無疑問，應該把一個問題和解決方法文檔化。當你處在混亂狀態之中的時候，你的解決方法也許並不明智。這就是說，當一個問題塵埃落定之後，要保留一份「屍檢報告」，經過這份報告，你能夠從新檢查當時那個解決方案採起的步驟和途徑。把它寫下來，而後把它保存在安全的地方，最好是放到公司內部的 wiki 上；而且，應該備份到幾個不一樣的地方。

推薦閱讀： 系統管理員應該怎樣高效的書寫文檔

2.3.4   在 IT 領域，不存在魔法，可是卻存在幸運

就像 Thomas Jefferson 說的那樣：「我發現我工做的越努力，我就越幸運。」在 IT 領域，也是這樣的。你花費越多的時間來研究你的基礎設施，關注路由器，交換機，服務器和其餘設備的特定的工做條件，你的基礎設施就會運行的越流暢。這些平常工做能夠讓你在問題的早期階段就發現這些問題，當問題真的發生的時候，你能夠更加快速地做出反應。另外，在 IT 領域，有不少種方法能夠「製造」幸運。例如，使用一些工具，讓網絡設備配置的備份自動化；若是使用這種方法的話，當你的交換機發瘋的時候，你能夠在幾分鐘內恢復它，而不是幾個小時。

推薦閱讀： 系統管理員最須要自動化的十大任務

2.3.5   在你修改每一個配置文件之前，要對它們進行備份

這條規則只適用於 Unix 服務器和幾乎各方面的配置都提供了配置文件的網絡設備。在你弄壞敏感的配置之前，首先對交換機和 TFTP （ Trivial FileTransfer Protocol ）主機的配置文件進行備份。在 Unix 系統上，能夠簡單地把 something.confcp 到 something.conf.orig 。

在必要的時候，若是想恢復到過去那個良好的狀態，只須要簡單地把文件拷貝回去，而後重啓那個服務就能夠了。由於註冊表的存在和 Windows 喜歡把簡單的概念複雜化，因此，在 Windows 系統上，這一般是不可能的。即使如此，你仍是能夠在胡亂擺弄註冊表之前，對註冊表進行備份，這樣的話，若是天下大亂了。你能夠從新導入備份的註冊表文件。 記住：當你對 Windows 註冊表進行修改的時候，服務器的生命就掌握在你的手中。

2.3.6   監控，監控，仍是監控

一點點預防工做就能夠省去一個月的週末加班時間。你應該對你的數據中心的方方面面進行監控，從房間的溫度，機架，和服務器，到服務器進程檢查，正常運行時間檢查 ...... 你還應該爲全部網絡設備構建一個集中式的日誌系統，除此以外，你還應該安裝一些趨勢分析工具來監控帶寬利用率，溫度，磁盤空間的使用率，和其餘的參數。當這些參數超過正常的閥值的時候，那些監控工具應該經過必要的手段來通知你。

若是在一個數據庫因爲分區過滿而被破壞的一個小時之前，能收到一個 email 或短信，那麼能夠省去無數的工做時間和宕機時間。對你的數據中心進行監控刻不容緩。

推薦專題： Linux 監控工具的展覽館

這些規則不只僅是須要遵照的規則——在你平常的工做中，這些規則應該是貫徹始終的。在 IT 領域中，對於許多人來講，它們是核心理念，可是對於其餘人來講，它們是神祕的——有點像忍者。

【 51CTO.com 譯稿，轉載請註明原文做譯者和出處。】

原文： The six immutable laws for troubleshooting IT   做者： Paul Venezia

2.4   Linux 系統管理入門必須經歷的三步

Linux 系統管理員如何入門？這是不少 Linux 新手們關心的問題。一位 CentOS 的開發者，在英國倫敦工做的系統管理員 Karanbir Singh 近日撰寫了一篇博文，對 Linux 新人如何進入 Linux sysadmin 的世界進行了闡述。如下爲全文譯文：

51CTO推薦專題： SA ，神仙與裝機男：運維的工做到底啥樣兒？

咱們經常會看到這樣的問題：面對 Linux 系統管理這個龐大的世界，應該從哪裏開始？說實話，我以爲這個問題不存在一個清晰明確的答案。 Linux 認證並不是最理想的選擇。你能夠去參加一些培訓課程，好比 RHCE 。可是，若是沒有任何背景信息而去參加培訓，你可能沒法享受到培訓帶來的好處，由於全部課程都有一個前提假設：你已經掌握了一些基本知識。

2.4.1   熟悉 Linux 以及發行版

一個開始系統管理員學習的方法是抓起一本相關主題的書來看（編輯推薦： 51CTO 讀書頻道的 Linux 版塊 有不少相關圖書的樣章）。而後安裝幾個 Linux 版本（參考： 幾個比較知名的發行版 ），而後在你喜歡的版本上搞一些 VM 設置（參考： Linux 下三大免費桌面虛擬機評測 ）。從一個版本開始，而後繼續使用這個版本，至少用上幾個月。可是， 一旦熟悉了那些基礎知識，你就要轉向其餘發行版本，看看其餘版本是如何工做的 ，這一點也很是重要。不管使用哪一個版本，不一樣之處僅僅在於一些設計和平臺常見通信。最根本的操做系統仍是 Linux ，這一點不會改變。

使用一個新的平臺時，有一點很是重要：你必須真正地投入進去。對此，有一個簡單的方法：看看你如今正在作的事情，不管使用哪一個平臺，試着在這臺 Linux 計算機上使用相同的方式去作系統的事情。掌握了那些基礎的知識和操做以後，之後你就應該將這個 Linux 版本做爲經常使用的工做平臺。從低等級管理能力方面來看，這種方式並不會讓你學到太多；不過，它能夠讓你學會從用戶的角度來思考問題。

我一直都認爲， 最優秀的管理員必定是從用戶的角度，從開發者的角度，而後從平臺（和管理員）的角度，對問題進行思考 。最後咱們還要記住，計算機是用來工做的，而管理員的角色就是確保計算機可以充分發揮能力來完成工做。不要迷失了方向：目標仍然是作某件工做。

2.4.2   熟悉相關的應用程序 / 服務

我最初接觸 Linux 的那段時間，經常會感受很難與其餘人的應用程序創建一種關聯，很難弄清楚他們如何使用他們的計算機和網絡。之因此很困難，由於我沒有處於他們所在的位置，甚至連跟上最新的狀況都很困難。在尋找那種親身體驗的機會時，我認識到，和一個應用程序創建關聯的最好方式就是加入他們的郵件列表。這樣，你就能夠看到其餘人遇到的問題，你也能夠提出本身的問題，好比爲何那個事情要用那種特別的方式來解決，你還能夠查看其餘人貼出的 bug 報告。這些信息都清楚了展現了在「真實世界」中人們是如何使用這個應用程序的，這將爲提供一個很好的根基。大約 14 年以後，我仍然認爲特定程序的用戶小組是學習一個應用程序的最好場所，你能夠了解到如何對它進行管理，最好的部署方式，還有開發者 / 用戶如何看待這個應用程序的角度。

2.4.3   編寫代碼

最後，編程和實際寫代碼的能力也是有益的。不要相信那種處處流傳的說法：管理員無需寫代碼。和周圍優秀的系統管理員聊聊（有不少這樣的人）， 你會發現，幾乎每一個人都會告訴你，他們 40-60% 時間用於編寫腳本 ，處理應用程序，而腳本的開發知識是有幫助的。我不是說你須要搞一個 Java 認證，可是你要對 bash 的基本編程有很好理解，至少可以使用 python 、 perl 和 ruby 中的一門語言（必要）。須要瞭解 unix/c 的傳統想法仍然存在，不過如今，並非有不少系統管理員須要深刻到驅動程序開發那個層次，他們須要瞭解的大多數函數代碼能夠利用 bash 、 ruby 、 perl 或 python 進行很好的處理。

原文： http://www.karan.org/blog/index.php/2010/09/28/getting-started-with-linux-and-sysadmin

其餘相關推薦：

資深系統管理員給 Linux/Unix 新人們的建議

Linux 系統管理員都應該熟悉的工具

系統管理員不可不知的三條黃金法則

2.5   系統管理員應該按期完成的九件事

Linux 系統管理員天天都應該作一些什麼工做？事實上，基於 Linux 搭建服務如今已經很是簡單，可是若是你忽略了一些事情，你的系統極可能將在流量高峯期或是黑客入侵時掛掉。國外一位專業的系統管理員將系統管理員的平常工做總結爲九件事，這九件事你都按期作了麼？

今天， Linux 的發行版很是地容易安裝也很是容易入門。就算是一個缺少經驗的系統管理員，創建必須的服務並完成可運行的程序一般也能夠在幾小時內完成。

很不幸，容易入門反而掩蓋了須要作的維護工做，這些工做是保持系統穩定和使系統長期處於一個良好的工做次序中所必需的。一個單一的服務器一般能夠在沒有人工干預的狀況下運行很長時間。可是前提是全部其餘的位和塊必需被提早配置。

關於這個列表，最糟糕的事情是你可能已經幾個月或幾年沒有作這些事情了。你忽略這些事情中的任何一件，它們都會在最糟糕的時候回來做祟：好比流量高峯期，硬盤驅動器崩潰，或黑客攻擊的時候。 Linux 系統管理員天天都應該作一些什麼工做？咱們這就爲您來總結一下。

2.5.1   配置管理

我用配置管理來開始，是由於它和這個列表中的其他項有很大的不一樣。這一項對單一的服務器並不重要，可是若是你有許多系統，這一項就相當重要了。 Puppet 或 Chef 這樣的配置管理工具容許你編寫‘ recipes ’來定義服務器應該如何的被放置在一塊兒。那些‘ recipes ’能夠在每一個服務器上運行產生一個一致的、容易複製的安裝程序。這能夠讓你當即啓動一個系統的新拷貝，能夠給你的安裝提供極大的自由度。

配置管理是作了，可是，卻給服務器安裝程序添加了必定的初始化複雜性，因此若是你膽子小，不用也罷。不過，即便只有兩個或三個服務器，好處也是至關巨大的。

2.5.2   備份

這一項是顯而易見的，大多數的系統管理員都會在這方面作點工做的。若是你沒有一個可靠的備份策略，你如今須要立刻調整它。哪怕只等一天，後果極可能就是是災難性的。同時請確保你正確的作了備份，由於備份很容易作錯。 Mozy ， Carbonite ， Backblaze 等工具的 At-home 備份已經取得了很大的進展，可是相似的 Linux 解決方案還遠沒有成熟。 Rsync ， tar ，和相似的腳本工具一直很受歡迎，而且也是可行的替代方案，可是必需要當心，以適應像 MySQL 數據庫那樣的特殊狀況。每一個人的備份需求是不一樣的，因此不管你選擇什麼解決方案也要仔細研究它潛在的不足。你選擇的解決方案應該：

◆按期運行

◆保持多輪的備份

◆自動的刪除舊的備份

◆在你的如今的操做系統之外存儲備份

◆保持和你的原始數據同樣的安全性

◆合併全部的關鍵數據，關鍵的配置文件（更換服務器之後啓動和運行系統可能會須要的任何東西），和最近的日誌

2.5.3   測試你的備份

緊跟着備份計劃的是測試它。這意味着按期檢查備份是否一直在作，產生的文件是不是有效的而且是否沒有被損壞，以及他們是否包括你須要的全部數據。一個好的經驗法則是若是你的備份每 30 天一輪換，那麼你應該常常的從新檢查他們。這裏自動化工具能夠幫一些忙（自動地檢查備份文件是不是最新的，是不是合理的大小而且是否有效）。儘管如此，沒有任何東西能夠替代人的眼睛……不然，當你發現你並無備份那些你認爲你已經備份的數據時，就只有哭的份了。

51CTO推薦專題： Linux 系統備份——操做實踐與工具介紹

2.5.4   日誌輪換

在最近幾年， Ubuntu ， RedHat 和其餘主要的發行版針對他們提供的軟件包的 logrotate 的運行和配置有了很大的改善。因此你的 apache 和 mysql 日誌也能夠被合適的輪換（默認設置是至關合理的，雖然可能並非你但願的方式）。可是你添加的「額外」的東西，例如 Rails 應用程序，須要創建它本身的 logrotate 條目。缺乏這個步驟會在最不合適的時刻引起無數的「硬盤驅動器已滿」的服務器錯誤。固然，一般你甚至不知道你的日誌引起了這個問題。針對這種狀況，資源監視纔是關鍵。

51CTO推薦閱讀： 明明白白你的Linux 服務器——日誌篇

2.5.5   資源監視

跟蹤 CPU ，內存的使用狀況，硬盤空間，帶寬，等能夠讓你更好的洞察你的系統狀態。當流量增長的時候，你能夠比較你的增長的內存或 IO 使用狀況，來提早規劃你的「 scaling 」。 RRDTool/ Munin ， ServerDensity 和 Cloudkick 是觀察這些隨着時間的推移而變化的數據的很好的選擇。若是你選擇的工具包括對意外的變化（失控的進程，驅動器已滿等）的警報功能，你將會領先任何潛在的問題一步。

2.5.6   進程監視

對你的網站來講，讓你的 Apache ， MySQL 和相似的進程一直處於運行狀態相當重要。有幾個很好的工具，例如 Monit 和 God ，能夠幫助你確保你的進程一直處於運行狀態。經過檢查進程的響應性，打開的端口，或進程 id 那些工具能夠從新啓動一個已死的服務或在一個失控的進程使你的整個系統崩潰前終止它。配置這件事的規則是個老大難問題，可是當一切都作好的時候，能夠節省大量的凌晨 3 點鐘的宕機時間。

51CTO推薦專題： Linux 監控工具的展覽館

2.5.7   安全加固（ Hardening ）

Hardening 包含了許多不一樣的操做，這些操做能夠使你的 stock 系統更安全。許多簡單的操做常常會被遺漏。你真的知道那些正在運行的進程中的每個都作了什麼嗎？在你的系統上，哪些額外的端口和服務被打開了？有合適的 PAM 模塊載入來進行安全認證嗎？又一次， RedHat 和 Ubuntu 走在了時代的前列，他們提供了安全 stock 系統，並確保最多見的軟件包遵照正確的安全協議。可是，這並不意味着你能夠跳過這個步驟。

2.5.8   安全更新

在一個基於 apt 或 RPM 的系統上，安全更新是很容易執行的。這個過程的陷阱是很難知道升級包是否會在你的棧裏引起某些類型的錯誤。爲了確切知道升級包將對你的系統產生怎樣的影響，擁有一臺一樣配置的模擬服務器是惟一的好辦法。幸運的是，由安全更新引起的麻煩是十分罕見的。修復一個更新的兼容性問題，須要花費一些停機時間，這個風險要比你的系統上的一個已知安全漏洞被利用的風險小不少。因此，不要讓「 not knowing 」阻止你進行正確的升級。最後，不是每個安全漏洞都能立刻得到一個安裝補丁。查看 CVE 字典上的可用警報，能夠讓你在補丁可用前，在保持你的系統安全性方面爭取主動。爲了確保一切都平滑的運行並保持最新，在這方面真的沒有什麼能夠代替人的肉眼。

2.5.9   日誌監視 / 安全掃描 / 入侵檢測

這個列表中的全部項都是最低限度須要完成的。它們很容易被忘記，直到你的系統已經被入侵爲止，你可能都不會想起它們。對異常活動，黑客攻擊和其餘惡意行爲的持續掃描，對於幫助阻止或減輕攻擊來講，是十分重要的。

51CTO推薦閱讀： 曹江華訪談實錄：Linux 服務器安全策略詳解

總結

這固然不是一個完整的列表，可是它也是十分普遍的，許多開發者和系統管理員只是沒有時間、興趣或知識來處理它們。更糟糕的是，許多開發項目被移交給了客戶，而一旦技術團隊遷移到另外一個項目上，這些客戶就沒有能處理這些事情的職員了。

原文： http://www.roundhousesupport.com/blog/9-things-you-should-be-doing-with-your-server-but-probably-arent

（ 51CTO 編輯注： RoundHouse 是一家國外的 IT 運維外包服務提供商。）

【 51CTO.com 譯稿，合做站點轉載請註明原文譯者和出處。】

【編輯推薦】

系統管理員必須熟記的幾個 Linux 命令

我討厭電腦！ -- 一個系統管理員的自白

系統管理員的苦惱與現狀

2.6   運維人員應該時刻謹記的十條安全法則

網站安全問題能夠說是如今最引人關注的問題。本文介紹了十條措施維護網站安全最低限度須要作到的事情，主要是給你們提供思路，爲廣大運維人員提供參考。這十條措施涉及到用戶身份驗證、數據加密傳輸、子網劃分、災難備份等多個方面的內容。

網站安全問題能夠說是如今最引人關注的問題，有關服務器安全、用戶隱私安全、企業數據安全的文章和爭論歷來沒有停息過。系統管理員做爲網站安全的第一道哨崗，既要確保網站服務器系統的安全，也要考慮到網站應用的一些基本安全防禦。

在以前《 明明白白你的 Linux 服務器——安全篇 》中，撫琴煮酒列舉了一些 Linux/Unix 服務器系統最基本的一些安全防禦措施，這篇總結對於服務器端的安全防禦思路介紹的至關詳細。可是要保護網站的安全運做，僅僅針對服務器系統自己的防禦是不夠的，還須要有一個更全局的視角和防範思路。本文中介紹的十條措施雖然涉及到用戶身份驗證、數據加密傳輸、子網劃分、災難備份等多個方面的內容，但全部這些其實都是維護網站安全 最低限度 須要作到的事情。文章並無深刻的介紹每個方面應如何實施，主要是給你們提供思路，爲廣大運維人員提供參考。

做者簡介： 李洋 ，博士畢業於中科院計算所。 10 多年來一直從事計算機網絡信息安全研發工做，曾主持和參與多項國家重點項目以及信息安全系統和企業信息安全系統的研發工做。具備 Linux 系統應用、管理、安全及內核的研發經驗，擅長網絡安全技術、協議分析、 Linux 系統安全技術、 Linux 系統及網絡管理、 Linux 內核開發等。

網站前端防禦

2.6.1   網站用戶的身份認證

通常能夠採用用戶名 + 密碼驗證，確認用戶登陸身份，並根據數據庫中預設的權限，向用戶展現相應的界面。

對於重要的網站應用，須要根據 PKI 機制，驗證用戶提供的證書，從而對用戶身份認證（服務器對客戶端認證），並確保交易的不可抵賴性。證書的提供能夠採用兩種方式：文件證書或是 USB 設備存儲的證書。文件證書保存在用戶磁盤和文件系統上，有必定的安全風險，可是能夠免費； USB 證書安全性高，可是通常須要向用戶收費。

有關身份認證的具體操做，編輯推薦讀者們關注 51CTO 安全頻道的 身份認證技術專題 。

2.6.2   網站數據的加密傳輸

對於使用 Web 瀏覽器的網上系統應用，採用 SSL+ 數字證書結合的方式（即 HTTPS 協議），保證通訊數據的加密傳輸，同時也保證了用戶端對服務器端的認證，避免用戶被冒充合法網站的「釣魚網站」欺騙，從而泄露機密信息（用戶名和密碼等），形成不可挽回的經濟損失。

如何創建 SSL （ HTTPS ）網站？ 鳥哥的私房菜 裏面有一章進行了 簡單的介紹 。

2.6.3   用戶帳號使用行爲的日誌記錄及其審計

系統服務器側應根據帳號，對用戶的使用行爲進行詳細的日誌記錄和審計，經過上述因素的日誌記錄，進行階段性的審計（時間間隔應該比較小），從而作到發現用戶帳號的盜用、惡意使用等問題，儘早進行處理。

2.6.4   惡意用戶流量的檢測、過濾及阻斷

系統服務器側應部署 IDS 入侵檢測系統、 IPS 入侵防禦系統、防火牆等設備，或者部署目前高效、流行的 UTM （統一威脅管理）設備，對惡意用戶採用的各類攻擊手段進行檢測和防禦，重點過濾惡意流量、突發流量等。

相關閱讀：

51CTO 安全頻道的 IDS入侵檢測專題

入侵防禦系統 (IPS) 初探

瞭解統一威脅管理 (UTM) 技術

2.6.5   對非正常應用請求的過濾和處理

系統的服務器端，尤爲是數據庫服務器端，應該經過配置和增長對用戶很是長應用請求的過濾和處理模塊，以免因爲數據庫的自身漏洞未及時打上補丁而遭受目前流行的 SQL 注入攻擊 等。

網站服務器側

2.6.6   合理的子網劃分及流量分割

系統服務器側包括大量的服務器類型，包括數據庫服務器、 Web 服務器、 FTP 服務器、郵件服務器等，爲了不因爲惡意流量形成的某種服務器崩潰，而引發的攻擊後果擴散，並最終致使其餘服務器也發生「雪崩效應」，則須要經過子網隔離（好比 VLAN 劃分）、 DMZ 區域 的設定等方式來將這些服務器放置在不一樣的安全域當中，作到流量和數據的安全隔離，從而將服務器端在遭受攻擊後對整個業務系統及其餘內網資源和數據形成的影響儘可能控制在最低的範圍內。

參考閱讀： VLAN 的劃分方法

2.6.7   負載均衡及負載保護機制

系統面臨着巨大的服務量，服務器端的設備基本上都須要有多臺服務器進行業務分擔，這樣才能提升性能，避免處理瓶頸的出現，所以，須要採用合理的負載均衡和負載保護機制：

◆對各服務器的業務流量進行有效地分擔，可按照 Round Robin 、 LRU 等方式來進行負載均衡

◆負載保護機制須要實時地對每臺服務器的 CPU 資源、內存資源等進行評估，若是一旦超過設定的閾值（ 80% 或者以上），將立刻進行過載保護，從而保證服務器自身的安全

負載均衡相關推薦閱讀：

負載均衡技術全攻略

揭祕企業級 web 負載均衡完美架構（圖）

負載均衡實例：如何解 放晝夜不眠的網管？

2.6.8   災難備份及恢復

任何系統都不能說 100% 的安全，都須要考慮在遭受攻擊或者是經受天然災害後的備份恢復工做，須要着重考慮以下幾點：

選擇合適的備份策略，作好提早備份，包括全備份、差分備份、增量備份等等

選擇合適的備份介質，包括磁帶、光盤、 RAID 磁盤陣列等

選擇合適的備份地點，包括本地備份、遠程備份等等

選擇合適的備份技術，包括 NAS 、 SAN 、 DAS 等等

做好備份的後期維護和安全審計跟蹤

Linux 系統的備份手段和工具能夠參考 51CTO 系統頻道的 Linux 系統備份——操做實踐與工具介紹 專題。更多有關災難備份和恢復的信息能夠在 51CTO 的存儲子站 WatchStor.com 獲取。

2.6.9   管理規範化

系統功能複雜，業務數據敏感，保密級別比較高，而且對不一樣管理人員的權限、角色要求都不盡相同，爲了保證安全管理，避免內部管理中出現安全問題，建議做以下要求：

嚴格劃分管理人員的角色及其對應的權限，避免一權獨攬，引發安全隱患；

做好服務器機房的物理條件管理，避免電子泄露、避免因爲靜電等引發的故障；

應做好服務器管理員的賬號 / 口令管理，要求使用強口令，避免內部人員盜用；

做好服務器的端口最小化管理，避免內部人員掃描得出服務器的沒必要要的開放端口及其漏洞，實行內部攻擊；

做好服務器系統軟件、應用軟件的日誌管理和補丁管理工做，便於審計和避免因爲安全漏洞而遭受到內部人員的攻擊；

根據業務和數據的機密等級需求，嚴格劃分服務器的安全域，避免信息泄露。

2.6.10   網站漏洞自我挖掘及防禦

採用漏洞掃描和挖掘設備，對內網各服務器進行階段性的掃描，並根據掃描所得的風險和漏洞進行及時地修補，以實現該漏洞爲黑客使用以前進行自行修復的目的。

這方面的工具服務不少，好比 五大著名的免費 SQL 注入漏洞掃描工具 ， 十大 Web 服務器漏洞掃描程序 等等。

上面這十條，並非作了就可以保證網站安全，而是要「作好」，必須作好。正在閱讀這篇文章的運維人員們，上面這些，你都作到了嗎？

【編輯推薦】

資深系統管理員給 Linux/Unix 新人們的建議

給系統管理員們的節日禮物

系統管理員應該按期完成的九件事

系統管理員不可不知的三條黃金法則

3   系統管理員軟硬技能

3.1   漫談運維：半神半仙亦民工

運維工程師到底都在作什麼？要回答這個問題，固然是有經驗的運維本身來講最爲真實。運維到底須要作哪些工做？網絡，系統，安全，存儲，測試，研發……全都要會！說運維是神仙都不過度。本文做者在撰寫此文時已經有了 6 年的運維經驗，讓咱們看看這羣半神半仙的民工們究竟是怎樣工做的。

做者前言：看到 chinaunix 最近出的門戶網站運維板塊 veyron 大俠寫的文章《門戶網站運維 abc 》（ 51CTO 編輯注：這篇文章目前還沒有完成， 部分整理版能夠在這 裏閱讀 ）深有感觸，特寫如下文章：

《談網站或其餘服務器運維》，這裏只談運維工程師所要作的細節工做， 讓人們知道運維工程師到底都在作些什麼 ，至於上級所要作的，只是提一下，不作參考。

如下是我的觀點，我說的只是我本身的想法，也是我發展的目標。你能夠有異議，咱們是來交流的。你對的我確定會向你學習。由於我也在摸索。運維工程師至少要能作如下的工做：

1，網絡工程師的工做

你至少要能配置 CISCO 6509 如下的設備，熟悉各類網絡協議，不然網絡出問題的時候你會傻掉。

2，系統工程師的工做

你至少要理解各類系統服務，在出問題的狀況下要迅速解決問題，而不是等系統工程師來解決。

3，安全工程師的工做

我不要求你必定要會各類網絡編程，可是在服務器收攻擊的狀況下，沒有防火牆的狀況下，作一些簡單的處理工做。

4，存儲工程師的工做

至少要熟悉各個廠商的設備，各類備份和還原的辦法

5，測試工程師的工做

在新版本上線以前，你至少要協同測試工程師作測試工做，由於你是運維人員，不瞭解程序架構致使沒法解決故障，你也有一份責任。

6，研發人員的工做 

運維工具都須要自已開發，熟悉開發語言，須要有過實際開發經驗，不然工做會很是痛苦，我深有體會。

7，英語

不想說了，個人最大痛苦就在這裏

8，好的溝通者

不出問題時候你能夠打遊戲睡覺，出問題的時候要能和項目人員溝通，快速解決問題，而不是推；我知道有不少人能推責任，你能夠作替死鬼，可是離開這個工做你還能找到更好的；把責任推到別人身上的人，下次出問題的時候，絕對沒人幫你。你要能和各個兄弟部門關係很是的密切，出了問題有兄弟幫你擔責任；也要能很是扯皮，沒事在會議上把別人都搞定。

9，庫房管理員

數萬臺服務器讓你來管理，任何丟失或者損壞都是不負責任和失職的表現。

10，運動員

不要回家就睡覺，有空仍是運動下吧；在服務器 down 機的時候，機房恰巧就你一我的，機櫃沒有空間，你須要更換一臺 HP 585 4U 的服務器，滿配約 80 公斤的服務器，你怎麼作？

11，責任心

這個我不想說什麼，這是你的職業精神。

12，組織者

給你 2 個啥都不會的民工，再給你 2000 臺服務器，要求你 2 天把服務器裝完，你咋辦？

13，1 － 7 條中，你必須有一條很是精通 ，是這個行業的專家。不然過了 32 歲，沒有公司要你。

你們看了確定以爲這我的是神仙，可是這必須是你慢慢能作到的，至少是我 6 年來運維經驗的一點總結。

由於如今的公司都在用招聘民工的錢招聘神仙，其次我也是想讓各位看看，運維工程師要擔負多少責任。

我去面試過的一些公司都說，你什麼都會，什麼都不精。我說對，正是須要咱們這些什麼都會的人領導什麼都精的人。

我這句話沒有貶低大牛的任何意思，只是當時一個臨場的發揮。雖說完就知道這個面試白來了，可是我仍是想爲廣大的運維工程師出口氣。

不怕千招會，就怕一招精。這仍舊是我給你們的建議。

最後給你們最後最大最重要的建議，作什麼工做均可以，千萬別作 SA 。

我把 SA 的定義成： speedinessanswer 而不是 system admin 。爲何？你能夠想象一下哪些工做須要快速響應。網絡工程師須要，機房網絡骨幹交換機故障，整個機房全部服務器沒法鏈接，須要快速響應不？系統工程師須要，系統出問題了，要快速響應不？安全工程師須要，服務器被攻擊了，要快速響應不？存儲工程師須要，公司核心存儲有問題了，要快速響應不？

你能夠作研發，出了問題能夠測試，能夠想辦法慢慢解決；你能夠作 DBA ，出了問題能夠推到網絡工程師或者系統工程師身上，說不是 DB 鏈接問題；你能夠作測試工程師，你說有問題這個東西就能夠不上線……在出問題的時候，倒黴的就是 SA ，因此不要再爭論 SA 包含哪些工做， SA 就是一個倒黴的快速響應者，你想，哪一個 SA 24 小時不開手機？哪一個 SA 晚上能夠舒服的睡覺或者安心的出去度假？走在路上一聽到和本身手機短信鈴聲同樣的，利馬下意識的抓出本身的手機看看是否是服務器報警；晚上和老婆 XXOO00 ，一個電話過來，立馬停下，抓出手機看流量圖；包裏放着筆記本，可是由於還要開機，太慢，拿着手機上 putty ping 或者 telnet 機器……

這就是你們羨慕的 SA ，你也不要抱怨本身作了 SA ，生活就是這樣。因此不要再爭論哪些 xxx 員應該歸屬於 SA ，系統管理員或是運維工程師，若是想作這行，就安生的當一個「快速響應者」，這是你的職業，也是你須要作到的。做爲一個 SA ，你確定經歷過通宵好幾天加班作事，你確定經歷過飯買來已經忘記了吃，你確定經歷過幾天加班沒睡覺，着個沙發坐下就失去知覺睡倒……沒有經歷過不能說你很差，只能說你管理的機器太少。

我公司是每個月發 21 天工資，某兩月我一月發了 44 天工資一月發了 47 天工資，創全公司建司 7 年來加班記錄……項目作完天然也就落了個部門通告表揚，而後的結果就是健康狀況急劇下滑，而後就是某天晚上在機房內加班一通宵，穿着短褲進機房，而後一個通宵被機櫃下面的冷風吹了個關節炎……這就是作 SA 的代價。

如下是一些實際經驗，發給你們作參考，有任何問題能夠 mail 我 answer3ai@gmail.com

有的東西是企業機密，我不能透露也不能給你相關文檔。

3.1.1   架構設計

如今你要作的，就是設計你的服務器架構和網絡架構。

(1)       服務器架構

這要先看你的網站是作什麼的，每日有多少的人數訪問，

例如，我打算站點初期每日有 20000 左右的訪問量，和 1000 人左右的併發量。我能夠用個人人數併發量 1000 ×站點中每一個頁面的平均大小 200k ×每一個訪問用戶可能要打開 4 個網頁＝ 800000k=800M 的網絡流量（固然這個數字確定是很是的過度，至於爲啥，本身能夠想下）

而後能夠用測試環境用軟件檢測在你的真實環境下的服務器壓力，好比在 2000 人在線的狀況下，服務器的 cpu 佔用多少，內存佔用多少。

那麼你能夠獲得你大體配置，其實市面上的標準服務器配置都足夠你用了，好比如今的 DELL 1950,HP DL360G5,IBM X ？？？（忘記了）

等服務器，足夠我跑一個這樣簡單的網站。其實說白了，雙奔 3 都夠，真的。固然你網站的流量比我要大的多，那你能夠買的更好一點的服務器。或者負載均衡器。

(2)       網絡架構

站點如今是一臺獨立服務器，將來採用的是分佈式架構，好比 bbs.hilinux.com 是一臺服務器， man.hilinux.com 是一臺服務器……

mysql 是一臺服務器。這樣你要算服務器要多少臺，交換機要多少口，防火牆要買什麼級別的。

哪些服務器能夠放在一個防火牆下，哪些服務器不用防火牆保護，哪些服務器是內網服務器，

須要什麼樣的網絡鏈接，最好是畫出大體拓撲，方便你預算設備花費。

(3)       服務器交換機等設備選型和購買

說的簡單點就是買什麼機器，你能夠和 google 同樣開始，買幾臺 pc 做爲你的網站服務器，也能夠本身組裝一臺服務器

或者也能夠和我同樣，去挑選品牌服務器固然，如今你要看你服務器作什麼的，

你能夠親自去電腦城看組裝服務器，也能夠打電話到 IBM,HP,DELL 的各地銷售商讓他們送服務器來測試，

固然你不要告訴他們你只買一臺，那你就別期望測試了。我告訴供貨商 hilinux.com 須要 200 臺服務器，一個 F5 ， 10 臺 CISCO 2960 交換機， 3 個 NETSREEN206 防火牆，一個 EMC CX500+ 滿硬盤

那麼不到 3 天， hilinux.com 所須要的 4 臺測試服務器，就送來了……固然，不要牛了這麼多最後只買 1 臺，那麼你晚上走夜路會被人打的。

最後就是價錢問題了，這個你本身看着辦吧。讓你公司的財務或者採購出馬砍價付錢就是了。固然，除了服務器的服務，你最好仍是想一想有利於本身的服務，好比人家公司能夠幫你拆箱子了什麼的。我作的最弱智的一件事情就是，來了 400 臺服務器， 50 個交換機， 8 臺 EMC ，我一我的花了一星期把箱子才所有拆完……

機器選型的時候你也要爲本身考慮，好比 HP 的 ILO 功能，能夠讓你遠程 BIOS 級操做服務器，好比浪潮的自動資產管理等等，爲本身管理服務器提供便利，不然機器 10 來臺還好， 100 臺還通常，我這裏 3 萬來臺，我不死幾百遍了。丟失一臺服務器，幾個月工錢就沒了……

3.1.2   IDC 選擇

首先要看你服務的地區是哪裏，而後再去找當地的電信機房。畢竟，雖然說全國已經互聯了，可是各地的網速仍是有差別的。

或者說有的 IDC 機房利用率高，雖然出口帶寬大，可是利用率高的結果是致使你網速慢的緣由之一。

個人作法是在全國各個機房的服務器用 pingplus 這個軟件進行一週的的流量測試。能夠看到平均丟包，最大延時等等。

固然，你也能夠到你目標服務的地方，找個能夠上網的地方進行網絡測試，好比說網吧包個機器……

好了，網絡測試完了。那麼你已經決定去哪一個 IDC 了吧。

而後你就能夠電話或者本身提着禮品登門拜訪一下 IDC 服務商的老大了

固然，你也能夠找代理服務商，由於他們拿到的價錢有時候比電信或者網通給你的價錢低，可是，關鍵仍是一個服務，由於你畢竟服務器放在那，晚上關鍵着急沒人給你重啓，機器出了問題其實按個 F1 就能夠解決的問題，服務商的值班人員不懂。你就只能打晚上的打飛機去機房維護吧。

提着東西拜訪一下服務商老大是禮節性的東西，東西不在多而在精，這樣你將來談事情人家也給你綠色通道，作事情要好作不少。固然，我也不反對你空手去，你一次租個 100 個機櫃＋ 10G 帶寬，人家仍是很優惠的。哈哈。你們都是混口飯吃，也不至於難爲你什麼。

最後你要知道如今的中國仍是賣方市場，你給人家牛，那你買的產品只能是……蒙牛

而後是開始去參觀機房

細心的檢查一下空調數量，空調出廠和最後維護日期，網絡佈線類型和架構，是否可擴展，主備從電力等。

基本都是很是關鍵的東西，出問題了，人家能夠給你更換一個新的，服務很好，可是你服務器掛一天的損失是多少，你能夠本身掂量。

還有機櫃電力，如今的機櫃放置 16 臺 1U 的服務器是正好，多了過於熱，少了資源浪費；可是你發現人家只讓你用 10 安培電力，過了要交錢買電；

或者不限制你用電，可是插線板只有 10 個，你還真買個託線板去轉接？你要想一想你一個託線板掛了，你服務器要掛幾個？

最後，個人一個機房包間裏 140 個機櫃， 2 個空調，結果某天掛了一個空調，雖然 6 小時人家 IDC 商就給更換了一個空調機（這速度已經很是快了），

結果我機器至少被熱死了 100 臺以上，機器是 HP 的，機器過熱， HP 會自動關機，並且會不讓你啓動。你崩潰不？注：不是給 hp 作廣告哈。

3.1.3   服務器上架

好了，要是你買的服務器到了，你會發現你接到電話後，樓下一個 N 大的「擎天柱」集裝箱車給你送服務器來……（某次我收 2000 臺服務器就是這樣的陣勢）；在這裏有個重大的提示，大家財務給廠商下單的時候，收貨地址必定要寫對。好比 XX 路 XX 號 XX 大廈 XX 樓 XX 室，你寫到 xx 號，送快遞的會給你堆到院子裏，你寫到 xx 樓，送快遞的會給你送到電梯口，你寫到 xx 室，他們纔會給你搬到室內。由於送貨的都是服務器廠商找的，你由於這個事情去聯繫廠商修改送貨地址，至少要多等 N 小時。並且他們視你的單子的數量和樓層，判斷來多少搬運人員。並且，必定要把服務器搬到你指定的地方再簽字收貨，不然……嘿嘿……

我最黴氣的是：來了 20 臺機器（還好很少），下着大雨人家給我往院子裏一丟，讓我本身搬上 19 樓，我沒推車沒啥的……

你能夠說，找電信的幫忙撒，廢話，這個我還不知道。那我告訴你，我在某電信大樓工做時，從 CCIE 到機房主管到機房工做人員，所有是美女……

雖然我在這個地方只幹了 5 天活，個人同事們口水都有 3 尺長……你還叫人家給你搬機器不？

你能夠說，僱民工撒，我又不是沒僱過，錢得你本身支付，公司不給你報銷的話，爽不？

下面是拆箱子，面對着堆積如山的 2000 臺服務器，我是連擡手的力氣都拿不出來……當時機房只有咱們公司 3 我的＋電信值班 2 我的……

這時候，個人辦法是……我打電話找來了 2 隊收廢品的：

這麼多箱子，除了機器和電源線留下，裏頭的導軌光盤等等你所有拿走，誰拆的多誰拿的多……

最後按照個人要求幫忙搬到機櫃上……因而咱們 5 我的是監工……看人家拆箱子搬機器。

因而人家 2 隊人找來了 30 多號人，一早上把 2000 臺機器所有拆箱子完畢放到機櫃上。

要是咱們幾我的拆，估計…………

最後再說個行價，服務器箱子一個價值 5 塊錢甚至更多。你服務器到了，賣賣箱子請你們吃飯吧。別讓掃地的阿姨拿走，幾個無所謂， 10 來個箱子，夠大夥兒吃頓烤肉了……還有 EMC 的木箱子……拿去養個小雞小鴨的……

42U 機櫃 1U 的服務器最好是 16 臺。你就看着上吧。呵呵

3.1.4   安裝系統和佈線

好了，面對幾千臺服務器開始裝系統，我不知道你會怎麼想……

所有是 1U 服務器有什麼辦法安裝系統？（咱們公司窮，買不起刀片；並且電信不配合，要是上刀片，電路大家本身拉線，價錢仍是原來的價錢；最重要的……咱們公司以人爲本，寧願多養我的也不肯意買個好服務器讓人失業），並且不容許 GHOST ，由於你這是服務器，不是網吧…… GHOST 出來的系統，我不知道誰用過，爽不。我本身是鬱悶鬱悶到了，莫名問題的時候，你就知道 GHOST 仍是靠不住的。

其次，咱們公司安所有要求：必須得一臺一臺安裝，先安裝光板的系統（好比沒有 SP 的 WIn2000 ），而後手工打 SP4 補丁，不能網絡打補丁。因而咱們就光盤堆成山。最扯淡的，爲了快，我作了一個補丁共享的服務器，全部的補丁 CP 的本地來打。結果忘記拔網線，致使人家說咱們是插了網線打補丁，有中毒的危險，須要重裝。我直接崩潰……

辦法1 ，你能夠 1 臺 1 臺慢慢裝，反正這麼多機器，你能夠管公司要更多的時間。可是咱們公司通常是機器到了，最多 2 － 3 天就要要，一貫是那種計劃不如變化快的沒有計劃沒有進度管理的「小」公司，項目組拿着雞毛當令箭，牛 x 哄哄的公司。鬱悶！

這個時候前期的準備就比較重要了（我公司多用 windows2003 ），由於首先我要裝一個光系統，再打驅動，再打補丁，再安裝遠程控制軟件。一臺機器裝完大約要 1 小時多點。那麼機器多了怎麼辦？光盤不夠怎麼辦？等等問題就來了。

個人辦法是，我一看 TMD 所有是 DVD ， IBM 的機器直接佩 combo ，公司給咱們發的所有是 CD ，孃的，典型的沒有最慢只有更慢，出了問題閒你慢的領導班子。因而只好本身出錢買了 DVD ，用軟件把 RAID, 網卡，顯卡其餘驅動作到光盤裏，須要安裝的軟件也直接作成自動安裝的方式，補丁也刻錄到光盤裏（咱們要求補丁必須單打，不能安裝集成補丁的 ISO ， shit ），這樣弄，你只用把光盤往光驅裏一丟，分區一分，就能夠下一臺機器了。而後等你在去關注這個機器的時候，已經能夠設置 IP 插網線了。靈感來自番茄花園。吼吼。

固然這時候你最好是買個 KVM,16 口的 KVM ，一次準備 16 張光盤就能夠用一套鍵盤鼠標操做 16 臺機器。固然啦， KVM 是能夠級聯的，我最牛一次一次一套鍵盤安裝 166 臺機器。鬱悶的是，塞光盤塞死，插 KVM 線插死，配置 IP 配死，有時候還會弄錯……

辦法2 ，你能夠用 NETKVM 去遠程安裝，可是你插那些 NETKVM 的線路， 2000 個插下來，爽不？而後你繼續扎 KVM 和網線的時候，看着和瀑布同樣的網線和 KVM 線交錯在一塊兒。估計直接崩潰。遠程 KVM 有的牛 x 的是能夠分發 ISO 的，就是傳說中的遠程分發安裝。能夠本身買一個研究研究了，咱們公司以人爲本，歷來不買這類高科技。

辦法3 ，我犯賤時候發明的：咱們的機器所有是 RAID1 ，因而我安裝一臺 raid1 的機器，系統所有安裝好，而後拔掉一個硬盤，插上一個新硬盤自動恢復鏡像，基本 10 來分鐘恢復好一個硬盤，插到機器上去。這樣，仍是比裝系統來的快。固然啦，型號是如出一轍的……

辦法4 ， HP 的 ILO2 功能，實現遠程分發。前提你得一臺一臺配置好 BIOS 裏的 ILO2 。也是蠻痛苦的。 IBM 和 DELL 如今也都有這個功能，可是你在分發之前，仍是得一臺一臺機器插上網線，配置好 BIOS 的 IP ，痛苦。而後把操做系統和機器的驅動程序和後續的軟件所有作到一張 DVD 裏，讓他自動運行。而後全部的服務器遠程運營這一個 ISO, 最好多弄幾臺，不然一臺機器弄的慢死。

辦法5 ，絕對最簡單的辦法 !!! 就是買機器前，讓廠家給你在硬盤裏灌好系統，和你買筆記本同樣，打開是個安裝完成須要你輸入序列號的系統。可是弱點是後續的軟件須要本身裝。由於服務器廠商是不會幫你安裝別的軟件的。

還有更多的辦法，只是暫時沒想到，你們也能夠談論本身的辦法。互相交流嘛。（ 51CTO 編輯注：其實如今已經有不少無人值守安裝系統的管理軟件，好比 KickStart 和如今流行的 Cobbler ，都是不錯的 批量安裝工具 ，並且都是開源的。如今都追求自動化，但願愈來愈多的運維們將沒必要面對一臺一臺裝機的困擾）

因此我喜歡 linux ，能夠用 N 種辦法安裝系統。

windows 就是個讓 IT 人當裝機男，挨踢人當民工。

好了系統裝好了，電源線和網線鏈接完，和瀑布同樣的。這時候仍是儘可能把他扎一下吧。

不然機器通風不順暢，會致使熱死。

簡單辦法就是電源線扎一邊，網線扎一邊。有錢的公司能夠買個網線序號標，沒錢就本身拿膠布標。

你能夠隨便扎，或者和給你老婆梳頭同樣，好好扎。哈哈

插交換機的時候，從上往下，從 1 － 24 日後，這樣網絡異常，數一下就知道了。

想來想去這裏也沒啥值得關注的地方。因此就幾行帶過。

3.1.5   資產統計

假如你的機器只有 2000 臺反而好容易管理了，可是如今我要管理的全國 IDC 有 31 個，平均每一個機房有不一樣品牌服務器 1500 臺。

一共大約有 45000 臺的樣子（個人資產管理系統裏的數字，不包含交換機，防火牆等）

這時候怎麼辦？

每季度和財務小 MM 一塊兒出去旅遊盤點 IDC 資產，幸福啊…… ( 咱們財務小 mm 很 PL 的哦 )

到了機房就是我一我的幹活點資產，小 mm 帶着大口罩，披着雙層的放輻射服……

可憐咱們這些幹活的，短褲背心， IDC 裏一呆就是好幾個月（ IDC 辦公室就在機房邊上……），不知道精子被輻射殺死多少……

1，必須有資產管理系統，雖然這個實際上是個很簡單的數據庫，可是你能夠把每一臺機器的品牌，硬件信息，操做系統信息，購買年限，質保年限等，你很是關注的東西作一個詳細記錄，並配發同一的資產編號。

好比咱們的資產號， FWQ-123456

服務器－ 123456 ，這是一個總的資產號，這個服務器哪怕搬到美國，也是這 1 個資產，直到丟失，或者拋棄，都是這一個資產，永遠不會變。

好比我如今的板凳就是一個資產號是：服務器－ 000010 的一個 4U 服務器，配置是 P2 300*2  256M 內存 16G 硬盤× 4

購買時間是 1999 年 10 月，從中維修過 1 次，升級過 1 次，在哈爾濱機房－廣州機房－河南機房－北京網通機房－上海公司內部測試機房－上海庫房服役過。

有歷史吧…… .

2，送到機房

看過我這個服務器去過的地方，羨慕不？見證咱們公司的發展史。 9 年過去了，終於成了個人板凳……

服務器在購買合同肯定之後，就應該按照配置記錄資產，而且在財務備案，資產編號必定和財務記錄相同。這樣這個服務器走到哪裏，都有備案和記錄。如今要把這個服務器送到某個機房去，搬着走吧……汗

送到機房，咱們要給服務器按照財務給的表格粘貼資產編號，選個順眼的地方，不會磨損的地方。

通常是機器正面某個地方，而後是機器屁股後面某個地方，而後機器側面把手的地方，粘貼 3 個，以防掉了就煩了。

而後在粘貼這個機器的應用資產號和 IP 標籤：

應用資產號舉例： FWQ-SH-XX-B31-WEBSERVER  意思是：服務器－上海－ xx 機房－ B 列 31 號機櫃 -web 服務器

IP 標籤舉例：外 123.234.123.234 內 10.0.0.1 。這 2 個標籤你能夠分開也能夠在一張標籤上寫清楚。

而且在安裝服務器的時候。把 FWQ-SH-XX-B31-WEBSERVER-123-234  把這個做爲你的 HOSTS 信息， windows 裏叫作計算機名

這樣遠程上來都很是清晰本身在哪一個服務器上，出問題時候也很是容易找到這個機器，不要閒麻煩，一切的麻煩都是爲了之後快速的解決 down 機問題而作的。

固然啦，甚至在密碼管理上你也能夠用這個規則來設置密碼，可是最好規則別讓別人知道了……

3，把這些信息所有錄入你的資產管理系統

系統無非服務器名， IP 信息，用途，機架位置，或者是否在使用一類的，我就很少講了

4，資產系統軟件交互，也能夠說是監控系統。

企業能夠開發一個軟件，在裝機的時候安裝到服務器上。而後資產管理系統定時去取服務器上的信息，好比網絡流量， CPU 內存硬盤負載一類的東西，這樣你的資產管理系統又變成了一個監控系統；

固然啦，你也能夠在資產系統裏集成一個遠程桌面管理系統，自動載入用戶名和密碼，還有隨機碼，就能夠登陸系統。省的還得管理服務器密碼。

而後用戶的訪問權限不一樣，看到的節面權限就不一樣。

好比說，監控人員沒有登陸權限，或者 IDC 人員沒有登陸權限一類。權限分配你本身研究好了。

5，仍是IDC 的工做。

話題繼續回到我和財務小 mm 去盤點（你公司比較大的話，你能夠多派幾我的分開去各個地方……）

小 mm 一看咱們機房服務器黑壓壓的一片，鋪天蓋地的，直接無語。爲啥，由於要拿着資產表一個一個核對，面對幾千個機器，直接暈倒。

雖然按照資產管理系統裏導出的信息，機櫃號， IP 號，機器從上到下的順序都很是精確，可是你一個一個核對，仍是慢。

怎麼辦？

庫房管理的工做用上了，哈哈。你買服務器或者買筆記本電腦的時候有沒有注意到箱子上的條碼？

那個條碼很是清楚的記錄了這個機器的詳細信息。因此黑莓手機或者 NOKIA 手機（別的我沒用過）都有掃描條碼的功能……好像與主題無關……

那麼剩下的就簡單了。

去買個這種條碼標籤的打印機，編輯成本身須要的條碼，一個一個貼好，上面有你全部須要盤點的信息……

好比咱們是從資產到機櫃號到服務器名字到內外網 IP 都要盤點……小崩潰

打印出來貼上去。而後買個掃描槍，和超市那種同樣，不過你要買有存儲功能的，不然你要端着筆記本去掃描， SB 了。

而後我和財務 mm 原本須要一我的念號碼一我的核對（你要直到在機房裏大喊資產號，喊一天的結果是啥，本身想），如今一我的拿一個掃描槍，按照規則一個一個掃描。完成後把數據導出後從新整理分析。直接和數據庫覈對（固然這個也須要你本身開發），覈對完成生成一張表。

表上寫的很是清楚你哪一個機架沒有哪一個機器，哪一個機器不在特定的位置上，哪一個機器缺乏……等等

這樣好比說，機器位置不對扣 5 塊錢工資，機器 IP 不對扣 2 塊錢工資，或者……反正扣到最後……這月不給發工資了，還得倒貼點……哈哈哈

3.1.6   監控架構

監控架構其實每一個地方都有本身的作法，我也知道個人辦法不是很先進，可是仍然拿出來和你們一塊兒討論

首先談談監控軟件，一提及這個經常使用的東西 MRTG,cacti 一類的就均可以用了。只要稍微歸類一下，流量展現看的仍是很清楚的。

要是要監控服務一類的，那就只好啓用大名鼎鼎的 nagios, 和一些牛 x 人基於這個作的一些別的商業軟件。

或者就是本身作個腳本去定時探一下，不通了給你發郵件了啥的，你 vim 一下 nagios 的 chack_xxx ，學習一下里頭人家探測的辦法，本身也能搞出來個啥東西，都仍是很不錯的了。

做爲 IDC 工程師，咱們所要關注的東西就是個流量了，咱們要很清楚某臺 65 下的某臺 35 上每一個口的應用，當遭受攻擊或者流量異常的時候，一眼就能知道是怎麼回事。我不相信你每天看着 10M 的流量，某天忽然一下給你來個 80M ，你說這是正常事件吧。哪怕正常，你也找相關的人確認一下吧，一個 100m 口跑 80M, 估計電信的人都來找你了。

天天看着這些流量圖是很枯燥的事情，那麼咱們沒事只能想辦法讓他自動報警給咱們了，因而 EMAIL 報警，而後把他發送到一個有手機提示新郵件的郵箱，你手機就有了。 MSN 報警，仍是不錯的吧，手機報警一類的辦法都是不錯的。這樣你你能夠和我同樣放心的去打網遊了。

這裏只談經驗，不談詳細的技術，由於我一說個人系統架構地球人都知道我是哪一個公司的了，雖然已經離職，可是咱也有個職業道德，謝謝。

固然了，有些公司是有網絡監控部門的。可是我就一直在想這個問題，全部的數值均可以用短信報警，你隨時均可以收到信息。用這個部門幹啥，讓一羣可憐的傢伙 8 小時一動不動盯着屏幕，公司又在他們電腦上安裝了抓屏軟件，上班事件聊天上網就扣錢……我估計他們天天最指望的事情也莫過於服務器掛了，能夠給咱們打個電話重啓個服務器或者連到服務器上檢查一下啥問題，重啓個服務了啥的。固然了，這些兄弟最後的職業方向也只能是進入運維部門了，至少公司服務器宕機維護的流程性東西掌握的很是熟練了。可是這是用好幾年時間換來的經驗，太……因此我是奉勸兄弟們有發現監控部門招聘人，就別去了吧。面前 8 臺顯示器，猛一看還覺得是黑客帝國吶，結果仔細一看全 tmd 是流量圖。常年對着 8 個顯示器，那個輻射……

我就不清楚設置個節點，出現問題告訴人，人去操做會死啊，非要讓人和機器同樣一動不動的盯着顯示器， TMD ，官僚。雖然我沒經歷過，可是想也能想到。作 SA ，最大的要點是懶，把一些須要人作的事情都自動化……可是話說回來，我公司以人爲本，人海戰術嘛，能夠理解。

上面的帖子位子已經滿了，下來的帖子在這裏寫。

3.1.7   企業實際面對的一些問題

我大概通讀了 veyron 大俠的文章，認爲系統架構方面的我絕對不如他。我就不在這裏賣藝了，那麼我賣企業都會實際面對的一些問題。

1，自動化，流程化你的信息管理

爲何要自動化，這年頭流行辦公自動化，你丫沒事還拿着工單四處簽字，老土了吧。

爲何要流程化，這念頭流行流程管理，假如你公司沒有一個固定的流程管理，出了事情，你們都不知道怎麼作，各個部門的電話亂打，你們都一鍋粥沒有效率。因此，未雨綢繆，在沒有出問題的時候，模擬出問題，多多準備，創建規範的流程，公司的每一個人都要遵照，這樣，流程化的管理 + 辦公自動化，你們只用在電腦上翹翹鍵盤，點擊肯定，流程就發出去，一路審批， OK, 流程發送到作事的人地方，也許這個作事的人在美國，也同樣方便。

上面說的是一個原理和意思，用這樣的理念去管理你的服務器應該如何去作？固然了，你假如只有 10 來臺服務器，就不用考慮這個了…… .

首先服務器採購錄入資產管理系統（詳細見上面有寫），服務器的去向和調度都在管理系統裏有提現。

這裏說的是：如何去上架，維修，下架等流程控制

先說上架下架：服務器到機房之後，別人要用服務器怎麼辦？先能夠到你的資產管理系統裏，看你機房還有什麼配置的機器多少臺，而後讓他們選擇本身項目服務器的配置，數量。在流程管理系統中，把這些機器選中，生成一個表單，表單名字爲 xx 項目上架需求，寫清楚誰用，作什麼，數量，哪一個機房等。而後提交給他們部門領導，他們部門領導贊成後，轉給須要審批的領導，一層層下來，流轉到咱們部門領導，咱們部門領導流轉給部門機房員工，員工收到流程，檢查上架下架服務器；如要上架，安裝完系統後填寫 IP ，機器名，機架等相關信息。如要下架，刪除相關信息，提交給流程控制的人員，流程控制人員確認後，這個流程完成。屆時，全部的人審批過的數據，經手人，數據庫裏都有，出現什麼問題找相關責任人，一下就找到了，省的和某些 XX 部門 JJYY 。

維修也同樣了，機器壞了，或者須要重裝系統，按照上面的流程，一步步走一遍，就能夠了。年末統計機房一天要幹多少活，省的某些領導認爲機房人 TMD 都在閒着。機房的人呢？沒有流程不幹活，不然白乾。

在流程系統裏重啓服務器，重啓服務器要是要流程，就太慢了，那麼你能夠作一個綠色通道，寫清楚緣由，重啓哪一個機器，直接提交給相關機房人員，在你的流程系統裏綁定一個短信網關，機房人員能夠收到須要重啓服務器的短信。準確無誤。

這樣代替了無紙化辦公，既有本身作的事情的每個記錄，又有相關人員管理，能夠量化本身的工做，省得年終獎的時候 xx 人有說你乾的少，發的少。你把記錄拉出來對比對比就知道誰多誰少了。

2，如何升級你的服務器

服務器老了，或者須要加內存加硬盤，怎麼升級。

雖說是很簡單換個 CPU ，加個內存，加個硬盤很簡單。

可是，如何控制你的配件不丟失，肯定的安裝到機器上利用了呢？

簡單，在服務器上作一個探測服務器配置的客戶端，天天探測一次硬件配置發送到資產管理服務器上。

與資產管理系統的硬件配置作對比，出了問題就報錯發一封郵件到機房工做人員，抄送流程控制人員一封就能夠了。

至於的加內存的時候注意型號啥的問題就不說了，你們應該都沒問題了

要說的是，假如你一個機櫃上放的機器比較多，好比 4 個 6 個機器一摞，恰巧壞了，恰巧一我的在機房，非得解決，怎麼辦？

簡單，一個辦法，可是仍是須要你有力氣，雖然有力學原理

好比有 4 臺服務器，最下面的壞了，

你能夠拽住最下面的把 4 臺一塊兒往出拉，拉出來一點，把上面 3 臺日後推，這樣一點一點的拉出來，

下面最關鍵：

拉到最後，前面要留出來一點，輕輕的把上面 3 臺的尾巴着地，而後一隻手擡住上面 3 臺機器，一隻手拉出下面一臺機器。

上面 3 臺必定要留出來一點，不然放下的時候，機器和機櫃託板會壓住你的手，你一鬆手，機器震一下，硬盤就掛了……

因此在推動去的最後仍舊要留一點在外面，最後放下來了再推動去這最後一點。

而後就能夠換或者加內存了。相對比較省勁，不危險，不會壓倒本身，不會砸壞服務器的辦法就是這樣了。

【編輯推薦】

大型網站運維之道漫談

Linux 批量安裝 五大開源軟件挨個看

資深系統管理員給 Linux/Unix 新人們的建議

3.2   系統管理員須要掌握哪些軟技能？

大多數系統管理員小組時間緊、資金少。這種狀況下，要作的頭一件事就是，藉助自動化、時間管理和組織結構，最充分地利用現有資源。系統管理員須要掌握哪些軟技能？系統管理員怎樣才能減小工做場所中的壓力和衝突？本文將爲你提供一些指導。文章做者 Christina Lear 是具備十多年系統管理員經驗的老運維。

系統管理員和系統運維的工做內容好理解，就是在技術上確保企業的 IT 架構和服務正常運行，爲此須要學習如何架設測試和生產環境，如何備份，如何監控，如何選擇最合適的技術來實現對業務的支持，如何預防潛在會出現的問題形成服務不穩或中斷等。可是，你知道系統管理員須要掌握哪些軟技能嗎？系統管理員怎樣才能減小工做場所中的壓力和衝突？下面這篇文章將爲你提供一些指導。文章做者 Christina Lear 是具備十多年系統管理員經驗的老運維，她是 SAGE 的一員，也是 Usenix LISA 的活躍貢獻者。她與 ThomasLimoncelli 合做撰寫了 The Practice of System and NetworkAdministration 。

大多數系統管理員小組時間緊、資金少。這種狀況下，要作的頭一件事就是，藉助自動化、時間管理和組織結構，最充分地利用現有資源。一旦作到了這一點，小組經理就能夠改善系統管理員小組在別人心目中的見解和形象，從而爭取更多的資源。

3.2.1   軟技能之一：自動化

應對資源缺少問題的一個好辦法是，使那些最耗費時間的任務實現自動化，從而爲系統管理員擠出更多的時間。自動化節省時間的途徑有兩個：一是讓任務更迅速地完成，二是確保一致性，從而減小支持電話。

推薦閱讀： 優秀DBA 應該讓數據庫的每一件事情都自動化

不妨先編寫一段腳本，讓輸出的命令可自動執行任務。系統管理員只須要審閱命令以確保正確，編輯命令以用於特殊狀況，而後把它們粘貼到命令行中。編寫這樣的腳本，一般比整個過程實現自動化更容易作到，有望爲流程實現進一步的自動化打下基礎。

與儘量實現任務的每一個方面都自動化的一套龐大系統相比，有助於處理普通狀況的一段簡單腳本可能更有用。使 80% 的容易部分實現自動化，把特殊狀況留給下一版本的腳本。記下哪些狀況須要手動處理、須要作什麼事情。

尋找廠商提供的可以使操做系統安裝等任務實現自動化的工具，並積極使用它們。還要弄清楚如何使針對你環境所做的定製工做實現自動化。若是可能的話，使客戶常常請求的那些任務實現自動化，並創建一個網頁，讓這些請求成爲自助服務式請求。這個方法不但爲系統管理員和客戶都節省了時間，並且提升了客戶滿意度。

3.2.2   軟技能之二：時間管理

想最充分地利用可用資源，另外一個辦法就是運用各類衆所周知的時間管理方法。時間管理意味着明智地運用時間——更聰明地工做，而不是更賣力地工做。系統管理員如何更有效地管理時間，這個話題自己就能夠出一本書了。時間管理對系統管理員來講可能特別困難，緣由是他們的工做經常受到打擾。爲了提升工做效率，重要的是打破這個怪圈。你能夠把請求寫入到本身的我的待辦事項清單，告訴對方你稍後會處理請求，這樣能夠避免工做受到打擾。要是你無法把請求寫下來，那麼禮貌地請對方給你發送電子郵件或故障單請求。注意選用對你來講最恰當的措辭，讓對方以爲更容易接受。

一天當中工做效率最高、最不會受打擾的時間一般是早上，因此不要把這段寶貴時間浪費在收閱郵件上。迅速檢查一下監控系統，看看有沒有問題；瀏覽一下郵件，找出標記爲「緊急」的郵件。而後編輯你當天的待辦事項清單，肯定工做事項的輕重緩急；要是事項太多，從新安排一下，把一些不過重要的事項留到下一天。天天的事項儘可能排得細化點（好比半小時、一小時、兩小時或半天），前提是要適合本身。爲當天的待辦事項肯定輕重緩急，就更容易、更迅速地決定「下一步該怎麼作？」把這頭一個小時的其他時間用來處理優先級最高的事項。一天結束後，把待辦事項清單上仍沒有完成的事項從新挪到下一天的待辦事項清單上。

每次處理一個文件或電子郵件。要是你根本沒時間去處理，那看也不要看。每一個文件或郵件第一次就要徹底處理好，而不是擠成一堆，以後非得從新閱讀。你在處理每一個文件或郵件時，先看一下，決定是不讀就扔掉、讀後就扔掉、處理好後扔掉，仍是回覆後再扔掉？有時候，處理一個文件或郵件意味着要把它記入到待辦事項清單中。而有時候，你能夠立刻回覆郵件，或者把回覆意見寫到紙張文檔的空白處，而後交還給發送方。文件或郵件儘可能少歸檔。如有懷疑，就扔掉。

使盡量多的電子郵件處理工做實現自動化。好比說，自動將電子郵件歸類到不一樣文件夾，可按電子郵件列表或論壇、社交網站發來的通知、博客帖子、非垃圾郵件優惠券、最新資訊和廠商的特惠廣告來歸類。而後肯定你想多久掃描那些文件夾，收閱感興趣的內容，甚至能夠設置在某幾天後就自動刪除。讓文件夾將信息保存一段指定的時間（好比保存一週、一個月、兩個月、六個月或一年），而後自動刪除超過指定時間的郵件。要不斷完善和更新你的自動化機制。

保持注意力集中。乾淨的辦公桌、乾淨的電腦桌面、每一個任務的虛擬屏幕以及乾淨的電子郵件信箱，能夠減小分心、幫助你集中注意力。禁用電子郵件到達提醒功能也有幫助。安排好收閱電子郵件的時間，而不是當即收閱到達的每封郵件。《 清空收件箱 》一書做者 Merlin Mann 給出了清空收件箱、保持收件箱乾淨的幾個祕訣。

千方百計減小每項任務所花的時間。自動化是能夠作到這點的一個方法。另外一個方法是預先想好決定，好比決定：始終在編輯文件以前先備好一份，隨身帶着我的數字助理（ PDA ），記下全部請求，更早而不是更晚作小任務，或者什麼時候給打印機添紙。有時候，解決辦法很簡單，就像在打印機旁邊放些備用的墨粉盒，那樣不至於爲了安裝墨粉盒，而將大部分時間耗在跑到遠處的庫房上。

3.2.3   軟技能之三：組織結構

讓系統管理員提升工做效率、少受到干擾，那樣能夠最充分地利用手頭的有限資源。從一項工做換到另外一項工做要花時間。系統管理員換着處理的工做越多，浪費的時間就越多，工做效率也就越低下。控制系統管理員在一天當中受到的干擾次數，恐怕是減少壓力、提升工做效率的最有效方法。

經過改變系統管理員小組的結構，就能作到控制干擾。對系統管理員小組進行劃分，以便一線支持人員處理客戶要求迅速予以處理的請求。處理起來比較費時間的請求則能夠交給二級工做人員。高級系統管理員則負責大型項目，好比建立服務。這樣的分工能夠確保：你的優先事項與你同事的預期要求相一致，保護正在處理長期項目的人員不會總是受到干擾。聽起來像是隻有龐大的系統管理員小組才能夠這麼作，但其實連只有兩名系統管理員的小組一樣能得益於這個方法。一名系統管理員能夠在早上保護另外一人不受干擾，而在下午對方反過來能夠保護他不受干擾。這個方法就是所謂的彼此保護不受干擾。

改善見解和形象

系統管理員面臨的許多壓力因素（包括缺少資源）可能來自於見解和形象方面的問題。

◆見解是指別人怎麼看待你；這是衡量質量的一種指標。

◆形象是指別人有多看重你；它是衡量數量的一種指標。

別人對你見解好的重要性很明顯；而形象好的重要性也許不大明顯。當系統管理員不引人注目時，同事可能以爲他們沒有在做貢獻、沒有忙於工做、人浮於事或資金過多，或者純屬多餘。這可能致使資金和人手不足，進而致使更壞的見解和更差的形象。

這裏討論的方法大多數側重於如何改善別人對系統管理員的見解。要注意：要是別人對你的見解很壞，須要大量時間和精力才能改變別人對你的見解。系統管理員能夠經過許多辦法來改善其工做在別人心目中的形象，但只有在真正把工做作好的時候，才應該竭力提高形象。換句話說，不要拿搞砸的產品大吹大擂。

好比說，要提高你的形象，能夠製做一個系統狀態網頁，以便你天天都出如今客戶眼前。製做的這個網頁還要有其餘實用信息和連接，以便它能夠成爲一個主頁。按期會見經理，既幫助他們瞭解你所作的工做，又幫助你在經理心目中有重要地位。

注意你的辦公場地。與客戶打交道的人應該選擇比較顯眼的辦公場地。能夠在市政廳舉行用戶組會議，那樣每一個想法、每一個請求或每一個批評均可以客觀公正地記錄下來。要弄清楚：記錄下來是爲了代表會認真考慮問題，未必是要落實什麼。

內部通信經常由系統管理員小組編制，但客戶不多去閱讀。編制內部通信要花大量工做，但是太容易被忽視。與客戶一塊兒吃午餐、參加社交活動是保持良好關係的一個簡單方法，並且一般比內部通信來得更有效、更省時間。

想爲你和你小組的正面形象負責任？那就要改善系統管理員小組在別人心目中的見解和形象。而系統管理員經理到時能夠利用小組的正面形象，爭取更多的資源。

將來須要怎樣的軟技能

因爲新技術的出現以及客戶要求愈來愈高，系統管理員的工做在不斷變化。那麼這些變化在如何改變所須要的哪些軟技能呢？

當我母親開始從事系統管理員（實際上是「操做員」）時，只有系統管理員才能使用機器；他們把同事的程序輸入到讀卡器，而後等程序處理完畢後，將結果返回給同事。她的同事對於多快完成完成的要求與咱們如今司空見慣的要求大不相同。她的客戶羣小得多，比較精通技術，但不像如今凡事都依賴電腦。她的工做也不像如今這樣常常受干擾；她沒有電子郵件要處理，她的一天主要是處理項目工做，而不是爲許多不一樣的人處理許多小的任務。所需的軟技能天生就與本文討論的那些軟技能不同。

在過去的四十年，系統管理員須要的軟性能發生了很大的變化；我預計，在接下來的四十年，會出現更大的變化，而這主要將歸因於技術方面的變化；可問題是，咱們不可能事先很早地預測到這些技術變化。不過咱們能夠預料：在接下來的幾十年，本文中討論的軟技能對系統管理員來講會變得愈來愈重要。

網絡一族的人數在繼續增長，而保持鏈接、與別人進行聯繫的方式也在繼續增長，於是使得溝通愈來愈以電子方式爲主。人們愈來愈要求「始終聯通」：若是你在線（爲何你不在線呢？），就能當即回覆任何消息。電子溝通不免會帶來干擾。時間管理和控制電子溝通，而不是讓電子溝通來控制咱們，將對每一個人來講會變得愈來愈重要，對常常受干擾的系統管理員來講尤其重要。

考慮到咱們你們收到的電子溝通數量勢必會繼續增長，咱們就要關注本身發送的信息的質量和數據。系統管理員必須學會簡潔扼要，態度又不能粗魯。這既節省了本身寫東西的時間，又節省了同事讀東西的時間。

系統管理員的客戶羣會變得越來地遙遠、愈來愈移動。對更多的人來講，遠程辦公將變得切實可行，在上下班途中辦公也會變得切實可行。外包和國際化辦公會繼續成爲兩大因素，讓系統管理員處在遠離客戶的地方。當系統管理員與同事沒有捱得很近時，他們須要確保處理好本文提到的見解和形象問題。另外值得一提的是，打電話經常比經過電子郵件或即時通信來聯繫遠地的同事更有效。這樣更有人情味，能夠更迅速地處理問題，並減少引發誤解的可能性。這還讓你有機會運用以前提到的溝通技能。

移動計算設備只會變得愈來愈廣泛——它們是每一個人確保工做效率的一個重要部分，儘管它們也隨之帶來了技術挑戰。不要排斥移動計算設備，而是要看到它們的好處，並積極迎接挑戰，而後知足你同事的支持要求。對於未來的技術，也要這麼作。要及早採用技術。關注最新技術如何有助於每一個人、爲此須要做什麼樣的變化。

隨着計算設備繼續變得更無所不在，以前獨立的系統會日益融入到系統管理員支持的計算機和網絡中。因爲愈來愈要求系統「正常工做」，一旦某部分中止運行，面臨的壓力也會愈來愈大。你的一些同事會提出一些更高的要求，而一些要求比較低的同事會依賴於你所支持的系統。你須要培養這種能力：與同事積極有效地溝通，並支持技術水平各異的客戶。

結論

系統管理員是一份充滿壓力的工做。可是一旦意識到形成壓力的某些因素，就能夠解決大部分的壓力，同時可以明白這份工做的確是值得的。有衆多方法能夠減小與同事的衝突、處理資源缺少問題和常受干擾的環境、解決優先事項相互衝突的矛盾，以及積極接受這個現實：系統管理員要對每個失敗負責。

【 51CTO.com 譯稿，轉載請註明原文做譯者和出處。】

原文： http://queue.acm.org/detail.cfm?id=1922541

3.3   系統管理員易犯錯誤及解決方法彙總

本文分享的都是系統管理員在工做的時候容易犯的錯誤，好比安裝 FreeBSD 以後形成沒法重啓，更改 WindowsAdmininstrator 密碼致使計劃任務沒法執行等等。經撫琴煮酒整理並提供解決方法，但願能夠給你們一些指導，避免在工做中出現此類問題。

本文分享的都是系統管理員在工做的時候容易犯的錯誤，經撫琴煮酒整理並提供解決方法，但願能夠給你們一些指導，避免在工做中出現此類問題。

做者簡介：餘洪春（ 博客 ），網名撫琴煮酒，英文名 Andrew.Yu，武漢某外企高級 Linux/Unix系統管理員、項目實施工程師，紅帽 RHCE講師，擅長負載均衡高可用和中小型證券類和商務網站架構，目前關注網站架構研究及網絡安全。

3.3.1   安裝 FreeBSD 後沒法重啓

問題描述：

裝慣了 Linux 的人確定知道通常會有個 boot 分區，但是在 bsd 就不那麼容易了。在安裝 FreeBSD 8.1 的時候遇到了問題，查閱了 chinaunix 上面，正好也有相關問題整理，特摘錄以下：

我要求 FreeBSD 分區：

2G For /

4G For swap

10G For /root

256M For /boot

其他 for /usr

安裝正常，結果安裝重啓後便出現杯具了：

>> FreeBSD/i386 BOOT

Default: 0:da(0,a)/boot/kernel/kernel

boot:

緣由：

經過網上查資料，瞭解到手動引導的全過程，發現了問題所在：

因爲獨立分區 /boot 形成了 FreeBSD 引導過程當中沒法正確找到內核引導的位置。

解決方法：

經過

boot: 0:da(0,e)/loader

能夠解決引導問題，而後進入 loader 界面

* 這個引導盤符根據 da0s1x 的 x 得來，所以你安裝系統的時候 /boot 所在分區區號，纔是真正的 x 字母，若是不知道就從日後試試

一樣因爲默認 kernel 位置是 /boot/kernel 因此依然須要手動加載

ok load kernel/kernel

得到 kernel 信息後

ok boot

這樣就能夠正常引導了。

可是這樣尚未完全解決問題，隨後還須要在磁盤掛載的時候輸入

mount root>ufs:/dev/da0s1a

才能進入系統，並且每次重啓都手動一次。因此其實問題沒有完全解決。

因此，爲了不以上的 /boot 問題，目前我裝機通常規範化操做，通常只分三個區，避免獨立分區 /boot ，也但願玩 Linux 的朋友們重視下這個問題。

2048M For /

4096M For swap

其他的均For /usr

3.3.2   更改 Admin 密碼致使計劃任務沒法執行

問題描述：

公司有系統管理員離職了，有很多 Windows 2003 服務器，此時負責安全的部門要求接手的系統管理員更改 Administrator 密碼，粗心的系統管理員急急忙忙更改 windows 密碼後，卻發現 windows 的計劃任務全都執行不了，由於 windows 的計劃任務都要求輸入正確的 Administrator 密碼。

解決辦法：

你們養成好習慣，每次更改完 windows 密碼必定要檢查一下計劃任務，不然很容易致使公司的重要業務執行不了進而影響中整個網站的運維及業務，但願此問題能引發你們的注意。

3.3.3   root 密碼更改後沒法遠程登陸

問題描述：

系統總監嫌託管的新 Linux 服務器 root 密碼過於簡單，吩咐公司的系統管理員將密碼改複雜些，急躁的系統管理員用 passwd root 密碼改掉後趕車回公司，杯具的發現密碼設置得過於複雜，密碼給忘了。因爲機器是新裝，沒有配置具備 sudo 權限的用戶，本身遠程都進不了 root 了。這種問題就只有百分百靠系統管理員負責了。

解決方法：

這個問題只要養成良好的習慣就能夠預防，就是你們更改完 root 密碼後，別急着退出，能夠用 ctrl+shift+F2 或 F3-F8 嘗試用另外一個終端進去下，若是當時就忘了，立刻切換到 F1 更換。撫琴煮酒常常犯這種錯誤，呵呵，但願此法對你們有效。

3.3.4   鎖定了 SSH 會話

問題描述：

我在配置某機房 Linux 服務器的 iptables 時，不當心設置了某一項錯誤參數，結果鎖定了 SSH 會話，致使咱們經理及另外一技術員連不上服務器。

解決方法：

下面介紹的這個方法及其有用，強烈推薦給你們：爲了預防此類問題出現，能夠配置一計劃任務 crontab ，每 5 分鐘運行一次，即

*/5 * * * *  root /bin/sh/root/firestop.sh

firestop.sh 內容爲 :

service iptables stop

這樣即便你的腳本存在錯誤設置（或丟失的）規則時，也不至於將你鎖在計算機外而沒法返回與計算機的鏈接。這樣你就能夠放心大膽的調試你的腳本啦。這都是生產環境下逼出來的，呵呵。

3.3.5   移走硬盤形成 Emergency 模式

問題描述：

同事在處理 Linux 服務器時，移走了一塊硬盤，而後就直接啓動紅帽 RHEL5 ，發現進了 Emergency 模式，焦急中他連忙跑過來找我；我第一句就是問他：你改動了硬件沒，他說他移走了硬盤後就直接啓動了，不是跟 windows 2003 同樣嘛，有什麼問題？我都無語了……

解決辦法：

耐心跟他講解了 Linux 下 /etc/fatab 的做用及語法，告訴他能夠在 Emergency 模式下輸入 root 密碼進入此模式，而後用

mount –o remount,rw /

將 / 分區設置成可讀寫，編輯 /etc/fatab ，將移除的硬盤用 # 號屏蔽掉後重啓服務器，故障解除。

3.3.6   sudoer 文件損壞形成沒法進入 root 模式

問題描述：

同事遠程處理一臺機房的 FreeBSD 8.1 機器，想加一個具備 sudo 用戶的特殊用戶，因此編輯了 /etc/sudoer 文件，卻不當心多加了一個 . ，而後直接保存退出了。結果杯具發生了：因爲 sudoer 文件損壞，全部具備 sudo 權限的用戶均不能切換到 root 模式下工做，而 FreeBSD8.1 與 Linux 不一樣，它默認是不容許 root 遠程鏈接的。

解決方法：

這時只有請專人到機房去處理問題了……

3.3.7   root 密碼被更改

問題描述：

一個開發小組都是用內部機房的 Linux/FreeBSD 機器，你們都知道 root 的密碼；不知哪一個兄弟是搞着好玩仍是怎麼的，偷偷的改了 root 密碼卻不通知你們，結果你們都用不了 root 密碼，杯具了。

解決辦法：

此時處理辦法有 2 種，一種就是你們都知道的單用戶模式修改 root ，其實另外一個辦法也蠻簡單的，系統管理員應該多配置一個具備 sudo 權限的用戶，遇到此種狀況時能夠用 sudo 權限來修改 root 的密碼，至少省得跑到機房去。畢竟有時候，機房未必在市內或在國內的。

3.3.8   依賴的庫文件丟失致使 root 沒法登錄

問題描述：

咱們的 jail 母機 192.168.21.36 ，由於 root 的 shell 設置成的 bash ，而其依賴的庫文件 libintl.so.8 發生丟失，致使了 root 不能登錄。具體報障以下：

/libexec/ld-elf.so.1: Shared object "libintl.so.8" notfound, required by "bash"

Connection to 192.168.21.36 closed.

解決方法：

①用單用戶模式進入系統；

②掃描磁盤 ( 此步非作不可，並且是安全的 )

fsck -y

③將文件系統從新掛載

mount -a

④將 root 的默認 shell 切換到 sh

chsh -s sh

重啓後一切正常。

3.3.9   忘記以 su 模式進入編輯器

問題描述：

普通用戶用 vi 編輯 nginx.conf 等配置文件，保存的時候會提示：沒有 Root Permission

解決辦法：

其實只要保存時加上：

:w !sudo tee %

就能夠了。

「 :w !sudo tee % 」這條命令的含義是把當前編輯的文件的內容當作標準輸入輸入到命令 sudo tee 文件名裏去。也就是 sudo 保存爲當前文件名，至關管用的命令，尤爲適用於 FreeBSD 和 Debian 系統 ( 我常常忘了本身原來不是 root 了 ) ，至關 very nice.

系統管理員容易犯的錯誤和解決方法暫時就總結到這裏，但願對你們有幫助！若是你們有什麼問題，也歡迎在評論中溝通。

【 51CTO.com 獨家特稿，轉載請註明原文做者和出處。】

【編輯推薦】

系統管理員搬家也要專業——域控制器遷移

系統管理員指南：如何給系統打補丁？ ( 知識篇 )

FreeBSD 系統管理員都應該知道的那點祕密

3.4   系統管理員應該怎樣高效的書寫文檔

系統管理員在面對書寫文檔的要求時，總會拿「系統應該自我記錄」或「我沒有時間寫文檔」爲擋箭牌而拒絕編寫文檔，甚至還有人認爲「缺少文檔使他的工做更安全」。但事實上，這些理由都是荒謬的。一個優秀的系統管理員應該將適當經歷投入到良好文檔的編寫當中去。

本文是上週在美國召開的 LISA 大會的一個課程總結，課程內容爲「針對系統管理員的文檔技巧」，講師是 Coffee Bean Software Pty Ltd 軟件工程師 Mike Ciavarella ，他曾經是 Sun 的 Unix 系統管理員，編寫過 UNIX 防火牆。 Mike 如今也是麥克米蘭的技術編輯和墨爾本大學的軟件工程課的講師。 LISA 會議全稱 Large Installation System Administration ，意爲大規模服務器環境的系統管理，由 USENIX 和 SAGE 這兩個組織協辦。今年的第 24 屆 LISA 大會剛剛在上週落幕。本文做者 Ben Cotton 是來自 Purdue 大學研究系統團隊的系統研究工程師。如下爲全文：

3.4.1   爲何系統管理員應該學習編寫文檔

系統管理員在面對書寫文檔的要求時，總會拿「系統應該自我記錄」或「我沒有時間寫文檔」爲擋箭牌而拒絕編寫文檔，甚至還有人認爲「缺少文檔使他的工做更安全」。 Mike Ciavarella 認爲這些觀點對系統管理員和組織都沒有任何好處，他在週二的「系統管理員須要知道的文檔化技巧」課堂上，不只反駁了這些荒誕的理由，並且就如何更有效地書寫文檔從技術方面分享了他掌握的一些經驗。

我對這個課程特別感興趣，由於我是 Fedora 項目文檔小組的成員，事實上我已經成爲咱們小組的文檔工做傳道士。我必須掌握更多的文檔編寫技巧，幫助整個團隊寫出高質量的文檔。我經歷過因缺少有用的文檔而形成不良後果的事故，我相信許多系統管理員應該有相似的經歷，所以改進文檔工做對減小這類事故是相當重要的。不要把什麼事情都裝在腦殼裏，關鍵時候也許你人不在，也許你被糟糕的情況嚇蒙而記不起了。正所謂好記心不如爛筆頭，若是你認爲寫文檔是一件枯燥的事情，那是由於你尚未愛上它。當你認真寫完一篇文檔後，你會發現本身的思路更有條理，也會學到許多新知識。由於寫文檔的過程就好像你站在講臺上給學生上課同樣，不能忽悠，你會發現原來本身是多麼淺薄。所以寫文檔不只是一件快樂的事，也是學習提升的捷徑，更不會所以而丟掉工做。

3.4.2   如何編寫文檔

編寫文檔時首先應該考慮的是誰是目標讀者。若是目標讀者是管理員，客戶或管理層，那麼文檔的風格和內容將有所不一樣。弄明白目標讀者後，寫起文檔來思路也會更清晰，最終的文檔用途也更大。

高效編寫文檔的關鍵是在讀者已經知道的須要知道的內容之間創建起鏈接，列舉讀者已知的一些內容能夠幫助他們理解文檔和減小文檔被駁回的可能性。試問若是你寫的文檔目標讀者都已經所有了解了，那你這個文檔還有存在的必要嗎？一樣，若是你寫的文檔讓目標讀者丈二和尚摸不着頭腦，那麼他們會有興趣讀下去嗎？

重要的信息在文檔中可能會出現屢次，但要注意措辭適當，不要一味使用重複的字眼，那樣會讓讀者以爲你在反覆炒剩飯。

編寫文檔時還須要注意語態。若是是技術文檔，經常使用被動語態，若是是教學用文檔，使用主動語態更好（編者注：這個比較適用於英文的狀況）。此外還須要注意詞性，不要表錯了情，會錯了意。象對待卷宗同樣對待文檔是個好主意，舉證責任在撰稿者，前面沒有介紹過的東西在後面就不能提，不然在接受盤問時你會被問的四分五裂。

文檔寫完後，編輯和校對很重要。編輯最好由理解材料的人進行，他們能夠幫助從新排列文檔章節以提升可讀性；校對則須要敏銳的眼光審查拼寫和語法，校對人員不必定要徹底瞭解文檔中的技術術語。通過編輯和校對的文檔應該拿給既不是目標讀者，又不熟悉該主題的人閱讀。若是他讀完後不能根據文檔的內容肯定目標讀者，那說明文檔還存在嚴重的問題。原本你是寫給同爲系統管理員的人看的，但卻不見一條命令或操做步驟，這就比如是牛頭不對馬嘴，這樣的文檔只能被扔進垃圾桶。

3.4.3   其餘注意事項

系統管理員必須展現文檔對本身的工做和整個組織都是有益的，不然就沒有存在的必要。 Mike 建議文檔工做應該做爲一個按期評估的績效組件，促使系統管理員保持文檔更新。在文檔編寫工做中，無論是部門經理，仍是剛剛入職的新手，均可以參與到其中。例如，初級管理員能夠幫助高級管理員寫一些局部內容，如一個安裝步驟，一條命令的參數解釋等。重要的是每一個人都要參與。

有多人蔘與編寫相同的文檔時，就涉及到使用協做工具了。沒有哪個協做工具是最好的，重要的是肯定需求，選擇最適合的工具。通常來講，任何工具都可以處理多種格式的文檔（如數字和印刷）。

文檔寫完後事情並無就此結束，還應該按期評估和保持更新。確保文檔的準確性很是重要，若是不這樣作，文檔就會漸漸失去其價值，這種狀況在現實工做中是很常見的。一開始你們都興致勃勃地編寫文檔，當寫完後就放在硬盤的某個角落，無論文檔記錄的事情如何變化，都無人再問津，長此以往，文檔就成了擺設，等到須要使用的時候才發現文檔已經失效了。所以文檔應常常更新，養成良好的文檔維護習慣是成爲優秀系統管理員的必備素質。

原文： http://blogs.usenix.org/2010/11/10/documentation-techniques-for-sysadmins/

【編輯推薦】

網站運維之道 之知識管理與積累

門戶網站運維經驗談

3.5   系統管理員之企業生存守則

本文是一位資深系統管理員所寫的職場經驗。對於剛剛入職的系統管理員來講，這些都是十分寶貴的意見和建議。本文做者告訴你們如何處理好在企業內同事與領導之間的關係。相信剛剛走進系統管理員的你會對本身的工做明朗不少。

編者按：本文是一位資深的系統管理員對本身工做經歷的描述，而且告訴你們在職場中須要注意的事情。這些寶貴的經驗對於一個剛剛入職的系統管理員來講無疑是一份無價的財富。

1、良好的人際關係比什麼都重要。

俗話說得好：先作人，再作事，良好的人際關係是你成功的關鍵條件之一和愉悅工做的基本條件之一，千萬不要覺得技術第一，其實技術人成功的條件之中，技術未畢是排在第一位的。其實在公司的人事架構中，技術類崗位每每是排在中下位的，因此我以爲僅僅只跟本部門的技術類同事打交道是不夠的；你應該多跟其它部門的同事，如行政部、人事部等部門的同事多接觸下，多瞭解下公司的企業文化和內部規定及人事架構，這樣對本身的成長也是有幫助的；撫琴煮酒之前在公司上班時，每每三個月都不知道本身公司的董事長和總經理長什麼樣，其實這樣很差，萬一哪裏在他們內心留下一個目空一切的印象，很影響仕途的噢。儘可能在不影響公司的內部規定的前提下，幫助能幫助的人，多跟其它部門的同事多聊聊，多溝通，這樣就算你是在一個新公司裏，也可以很快溶進去，很快進入本身的角色。

2、正確處理跟本部門同事的關係。

有句老話：不要跟同事作朋友。很不幸，這句話並不能適用在系統管理員身上。若是是一個大型公司，好比超過 500 的某分公司， IT 部門一部分爲開發部、系統組、網絡組 ( 包括網絡安全 ) ，有許多工工做要求協同工做，而並不只僅是憑一人之力就能完成工做的。因此這時候你須要花大量時間，跟你的同事，如 PHP 開發或網工們溝通，讓他們明白或瞭解你的需求；特別是一些開發環境的佈署，由於最後的測試使用者正是你的 Devoleper 同事。打比方說，我在某公司做系統管理時，咱們的測試環境是 Nginx+FastCGI ，而 PHP 們當時正使用的 Zend Framwork ，他們對 nginx 的要求就是要有統一入口，這個就須要在 nginx 寫相關匹配的正則了；我我的以爲，若是同事們在私底也能聊得來的話，不妨也能夠做爲朋友交往；若是確實在工做上利益衝突，其實能夠徹底以商量的口氣來協調工做。

切忌的二件事：第1、不要以技術壓人，這個沒意思，我歷來不做；2、也不要以老員工的身份欺負技術新人，這個更不推薦了，這隻能說明你的無知。系統管理的工做其實就是搭積木，只要願意花時間的話基本沒什麼難度。而網絡及網絡安全這塊，我跟他們溝通得就更多了，好比要將內網的某臺服務器做 DMZ 映射，新網站若是要推行了，還要跟負責網絡安全的同事們協同工做，看有哪些安全漏洞，或防火牆的安全性能及服務器的最大壓力承載等。個人作法通常是：平時也能夠學習些系統以外的知識，而後閒時能夠跟同事們多聊些技術外的私話，好比手機啊、遊戲或別的，週末方便的話，儘可能參加公司或同事們的聚會。

不要冷冰冰的作人，一張笑臉比什麼都重要。在本部門同事的處理關係上，個人作法是：能作同事就作同事，能作朋友就儘可能作朋友，畢竟多一個朋友多一條路；因此，之前公司的同事們，只能可以聊得來的，我基本都保持聯繫；平時或週末都會跟他們聚下餐，你們輪流聊會天，既減輕壓力，又相互瞭解對方公司的一些趣事，何樂不爲 ? 正好，下段文字正是描述這段情景的，不知你們看了可否體會個人心情與意境。

關於飲酒·聚餐

週末，同事聚餐。咱們選擇是平時總在一塊兒吃飯的地點「三顧茅蘆」，點了六個菜，連我在內四我的，我作東；由於前面幾回都是同事們請了，此次算我回請，咱們實行輪詢制 (RR) 。因爲平時都不是貪杯之人，咱們點的是「雪花清爽」啤酒。席間除了一猥瑣以茶代酒，咱們仨飲酒都是隨意，淺嘗輒止，這也是我最喜歡的一種飲酒方式。撫琴煮酒雖然名字帶一酒字，但酒量甚淺。。此次參加飯局的三個同事，都是平時工做中很聊得來的夥伴，平時工做遇到了問題就一塊兒交流，相互之間都很熟了，能夠說是無話不說了，因此我很享受這個過程。俗語說得好：飯仍是那個飯，但人未必是那我的了，因此，吃飯，飲酒也是看心情的。

3、碰見領導要服軟。

二個原則：1、在原則性的問題要服從上級領導的管理；2、千萬不要越級報告，不管是國營仍是外企，這二個心得體會贈予給剛剛上班的小憤青們，若是確實體會不了，建議仔細閱讀《杜拉拉昇職記》三部文章，裏面許多故事都是挺真實的，特別是越級報告這個問題，短時間來看，你可能會取得局部的勝利，但從長遠來看，你絕對是最大的輸家，由於沒有領導會喜歡一個越級報告的下級，哪怕你的能力再高也是同樣。撫琴煮酒第一工做是在某大型國營企業作企業網管，主要是負責 windows2K 服務器及 DB 數據庫，當時覺得本身技術牛 B( 在公司裏技術確實也算是第一吧 ) ，再加上很快就提了 IT 部門的 Leader ，頗有些飄飄然的，在領導面前就是不尊敬，結果很快發現仕途不順，一直都只能是 Leader ；其他當時若是明白這一真理的話，我如今估計也是朝技術 + 管理這一目標一直走下去了，也沒有後來轉售前和實施工程師的必要了。

我當時就很迷惑：爲何許多沒有能力的人都當了 Manager 了，而我還只是一個 Leader? 其實當時就沒正確處理好與領導的關係，多是太年輕和性格比較外向的緣故了。這一點慘痛的經歷告訴你們，但願你們引覺得戒，特別是但願作管理的小夥更要注意這點了。有時候，你的上級能力可能沒你強，也有可能不懂系統這塊，這時候你更要耐力向他解釋，爲何不能這樣作，這樣作會帶會什麼樣的惡果，千萬不要消極對抗，尤爲不要發生正面衝突。其實這個狀況，你們到了必定年齡層次就會明白；不過，我以爲提早明白仍是有好處的，這樣能夠少走許多彎路，至少杜拉拉明白這點。

4、明確你的發展定位也是很重要的。

做爲一個系統管理員，即 System Admin ，你要明白你的發展定位，究竟是作技術 + 技術，仍是技術 + 管理，另外仍是作技術 + 銷售呢 ? 這決定了你在相關方向的投入和精力，技術 + 管理這個你們都應該明白，技術 + 技術是一個怎麼樣的定位呢 ? 許多公司都應該有這樣的崗位，即高級開發工程師，此崗位的薪資跟 manager 持平，但不汲及人事管理；比較大的公司，也有高級系統管理員一職，我在北京的崗位也跟這個相似，系統總監不屬於此崗位，它屬於系統 + 管理；技術 + 銷售就比較好理解了，即售前工程師和售後工程師，它們的技術含量跟系統管理 ( 系統集成 ) 比較起來，就比較低了，特別是售前，這個是我比較喜歡的職位之一，若是是作過項目實施工程工做的小夥更能夠考慮下，特別是大公司的售前，福利待遇至關不錯，在某種程序及時間範圍內能夠解決很多生活上面的困難，衆所周知，技術員都是比較窮的吧。每一個系統管理員都應該明確本身的發展定位，作到有的放矢，合理的分配本身的精力和時間。

另外，這裏說個題外話，英語對系統管理員很重要，由於許多新產品和新技術，基本上都是從國外引進的；要想熟練的掌握及應用，英文是必不可少的基本功之一；而外企是不用說了，咱們向國外的上級 Leader 報告，其正式文檔均要求是英文。搞技術的人都容易忽略的另外一條就是口才，其實這個也是很重要的；尤爲是做爲售前，你總不可能向你的客戶推銷你公司的產品方案時就直接讓客戶閱讀吧，或者就直接告訴他們，這個好，這個確實好吧。不說別的，你們面試時，成功的關鍵之一也是要說明面試你的人，這個也要求你在平時注意鍛鍊下，若是隻是打算單純的作技術的，這個稍爲注意下便可。但我以爲一個技術人有一個好口才，其發展方向也能夠是多方面的，至少你還能夠做爲講師，讓更多的人學到你在工做中掌握的心得和技巧。你也不想你做爲一個技術人，竹筒倒豆倒不出，那就是一個杯具了。

5、系統管理員必定要明確本身的企業定位。

老闆們如今愈來愈喜歡 Linux/unix 的緣由之一，未必就是你想象中的那樣， Linux/unix 有多麼的有效率，據我所知，就是由於 Linux/unix 免費，並且下面許多軟件都是免費開源的，其中不乏強大的，好比 Apache 、 LVS 、 Nginx 、 Squid 及 bind ，還有一個 iptables ，我就任的公司，至少有 50% 是用 iptables 做爲 NAT 路由哭，並且其效果也是不錯的。

做爲系統管理員，並非你的做用有多大，而是你將技術轉爲生產力有多高而矣，因此千萬不要覺得公司缺了你就不轉，必定要抱着日常心的態度去工做和生活，我如今認識的大牛們，基本上都是謙虛和平民化的，這個也值得咱們學習。平時仍是要注意學習的，畢竟新技術是層出不窮的，能力不是天生的，這個須要後天培養。你還能夠經過博客等形式發佈本身的工做或者學習心得，或是率先掌握一門新技術，並率先向社會推廣這門新技術。分享是一門藝術。在分享的同時，必定會伴隨着理解、應用、總結、提升、表達甚至推廣方面的提升，這對我的的技術提升和社會影響力的創建有着很是的意義的，這個目前我也是努力的方向和目標之一。

6、必定要有效率和簡單的工做。

其實做爲系統管理員，許多工做都是重複性的，特別是一些維護和備份工做，這個時候你徹底能夠編寫一段 shell 腳本，加進 crontab 計劃任務裏，代替你在某時間段執行這些操做。 windows 下的批處理也是至關不錯的，許多用圖標的操做也能夠用其簡化。當你將工做都理順後，你會發現你的工做原來就是如此簡單。你徹底能夠將你的時間用於其它方面的學習，好比數據庫和程序開發等，就就是我一直強調腳本重要性並特意爲此設了專題的緣由之一。作一個優秀而懶惰的系統管理員，我徹底同意這個觀點，優秀的管理員絕對是一個懶惰的傢伙，呵呵，若是你做爲系統管理員，天天都要加班加點的工做，這個時候不妨反思下。

7、系統管理員要明白本身在公司的做用。

做爲系統管理員，通常都會職守公司的 Exchange 郵件服務器，固然還有許多機密的文件，這時候必定要做爲保密工做，不應說的話和不應作的事都要注意，尤爲是涉及到薪水方面這些敏感的話題，在公司內部，透露和打探公司的薪資都是職場大忌。

另外，隨便透露公司的資料及敏感信息、上班時間接私活，這些事情儘可能都不要作，都是些犯忌諱的事情；另一件事就比較頭疼的事情就是，每一個公司，不管大小，都會有一些政治鬥爭，這個時候該怎麼辦了 ? 我通常的作法，毫不拉幫結派，儘可能保持中立，作事要對得起本身的良心。若是確實作不到，那就考慮離職吧。畢竟作人是一生，作事是一時。

下次工做時，記得找一個工做環境比較單純點，這些事情其實碰見一次是好事 ，下次至少不會驚惶失措了。我在公司裏儘可能會作到如下二點：注意保密，保持中立，通常的話，政治鬥爭不會影響到系統管理員，畢竟公司的網站或開發服務器都須要專人維護，總不可能連作事的人都隨便開了吧。

8、其它方面就是身體相關了。

有時候，服務器遷徙的活仍是比較重的， 1U 、 2U 的服務器還好說， 4U 的比較重了，我之前的同事，也是作系統的， 90 多 KG ，他來了之後咱們都很高興，至少來了個半民工；撫琴煮酒長得比較單薄，單獨一人勉強能應付 1U 的服務器，其它就不行了。

另一個就是夜班值守的問題，這個就比較頭疼了。我通常就是白天注意多休息下，晚班的時候會將手機郵開通，音量調到最大，下半夜時能睡會是一會。別的網站崩潰了沒關係，若是是電子商務型和廣告類型的，那就是錢了。因此係統管理員也要注意鍛鍊身體，平時能夠辦一張健身卡，週末去鍛鍊下身體，平時能走路的話就不要打車了。

另外，要注意內心方面的壓力，由於咱們的平均故障處理時間不能超過 5 分鐘，因此上班時的壓力仍是很大的，有段時間還掉毛 ! 因此，我如今平時喜歡講笑話，跟 MM 聊天，有時候還自我吹噓，自我讚美一番，保持自我良好感受 ( 即吹牛是必須的 ) 。週末還去養生堂作下保健，由於有時坐多了，有些頸椎之類的小毛病。身體是革命的本錢，若是你的工做直接影響到你的健康的話，我建議，仍是換一份工做吧。沒有什麼理由和緣由，比健康更重要。有健康，纔有未來。

做者博客： http://hi.baidu.com/yuhongchun027/home

【編輯推薦】

系統管理員最須要自動化的十大任務

系統管理員的雙系統生活 Windows 2003 與 FreeBSD8

Linux 系統管理員都應該熟悉的工具

系統管理員都應該是瞎子？從 Google 用戶隱私談起

系統管理員大拿們的訪談系列（一）： Tom Limoncelli 談交流

4   系統管理員的軟硬件維護清單

春節長假將至，有些系統管理員們被老闆要求寫一份公司的軟硬件維護清單，對於沒寫過此類文檔的運維朋友們而言會感到很苦惱。本文整理收集了一些軟硬件系統維護清單，有些來自微軟、 IBM 等廠商，有些由系統管理員同行們分享，但願能對你們有所幫助。

春節長假將至，有些系統管理員們被老闆要求寫一份公司的軟硬件維護清單，對於沒寫過此類文檔的運維朋友們而言會感到很苦惱。

系統維護清單該怎麼寫？

其實不光是在長假先後，系統管理員平時也應該養成按時（好比天天、每週、每個月）按照維護清單進行軟硬件維護的習慣。

簡單而言，系統維護主要包括以下幾個方面：

保持軟件和系統的更新。軟件更新一般包含 bug 修復和安全漏洞修復，這是爲了你的安全着想。

殺毒軟件的更新和按期查殺病毒。

檢查你的系統監控數據是否無缺的保存。各類監控。

檢查系統的備份是否無缺的保存。備份的重要性相信不用再強調了！

檢查機房的物理環境，如溫度、溼度等。

檢查硬盤 /RAID 的狀況，磁盤佔用狀況，是否有壞道。

……

從某種角度而言，系統維護清單都應該是系統管理員們必須遵照的鐵律。 51CTO 編輯在此  

具體的系統維護清單，其實很多廠商（尤爲是微軟和 IBM ）都提供了軟硬件維護清單的參考文檔。惋惜的是，大部分都尚未翻譯成中文（這也是爲何技術人學好英文很重要，由於太多資料手冊都是 English Only ）。下面摘錄部分相關文檔，以供你們參考。

微軟BizTalk Server 維護清單參考文檔

每日檢查清單

Steps	Reference
Check for failed disks in the hardware RAID (reliability check).	"View Disk Properties" in the Windows Server 2003 product Help at http://go.microsoft.com/fwlink/?linkid=104161
Check for messages requiring manual intervention such as suspended messages (reliability check).	For information about manually checking for suspended messages see "Investigating Orchestration, Port, and Message Failures" in BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?linkid=104169 For information about performing automated monitoring using Microsoft Operations Manager 2005 see "Suspended Message Alerts" at http://go.microsoft.com/fwlink/?linkid=105059
Check the event logs for errors and warnings (administration check).	BizTalk Server 2006 R2 errors and warning events are saved in the application log. The event source is "BizTalk Server 2006". We recommend that you monitor the event log using an automated solution such as Microsoft System Center Operations Manager. For more information, see Monitoring with MOM 2005 or Operations Manager 2007.

每週檢查清單

Steps	Reference
Ensure that each host has an instance running on at least two physical BizTalk servers (reliability check).	High Availability for BizTalk Hosts
Ensure that each receive location is redundant (reliability check).	Scaling Out Receiving Hosts
Ensure that the SQL Server Agent service is running on the SQL server (administration check).	Monitoring SQL Server Agent Jobs  How to Start the SQL Server Agent  Monitoring SQL Server Agent Jobs and Databases  "SQL Server Agent" in SQL Server 2005 Books Online athttp://go.microsoft.com/fwlink/?LinkId=106728
Ensure that all SQL Server jobs related to BizTalk Server are working properly (administration check).	Monitoring SQL Server Agent Jobs and Databases  Monitoring SQL Server Agent Jobs
Ensure that the SQL Server jobs responsible for backing up BizTalk Server databases are running normally (administration check).	How to Schedule a Backup BizTalk Server Job  How to Configure a Backup BizTalk Server Job
Ensure that the latest security updates are installed (security check).	Microsoft Update site at http://update.microsoft.com/microsoftupdate/v6/default.aspx
Analyze weekly performance monitoring logs against baseline and thresholds (performance check).	Monitoring Throttling Using Performance Threshold Rules  Using the Performance Analysis of Logs (PAL) Tool  Identifying and Mitigating Performance Issues  Troubleshooting Performance Issues
Ensure that the system is not experiencing frequent auto-growth of BizTalk Server databases (performance check).	Defining Auto-Growth Settings for Databases  Guidelines for Sizing the Tracking Database  Identifying Bottlenecks in the Database Tier  "Database File Initialization" in the SQL Server 2005 Books Online athttp://go.microsoft.com/fwlink/?LinkID=101579.  "SQL Server Maintenance" in Best Practices for Configuring SQL Server
Run SQL Server Profiler during high load to check for long response times and high resource usage (performance check).	"Using SQL Server Profiler" in the SQL Server 2005 Books Online athttp://go.microsoft.com/fwlink/?LinkID=106720
Ensure that message batching for all adapters is appropriate for resource consumption or latency (performance check).	Configuring Batching to Improve Adapter Performance  "How to Design a Performant Adapter" in the BizTalk Server 2006 R2 Help athttp://go.microsoft.com/fwlink/?LinkId=106720
Ensure that the large message threshold is appropriate for resource consumption (performance check).	How to Adjust the Message Size Threshold  "How BizTalk Server Processes Large Messages" in the BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?LinkId=82351

每個月檢查清單

Steps	Reference
Ensure the master secret key is backed up and readily available on offline storage (reliability check).	How to Back Up the Master Secret
Ensure that failover for all clustered services has been tested (reliability check).	How to Test Group Failover
Ensure that the Enterprise SSO service is clustered (reliability check).	Clustering the Master Secret Server
Ensure that the BizTalk Server databases are clustered under SQL Server services (reliability check).	Clustering the BizTalk Server Databases
Ensure that at least two physical BizTalk servers are part of the BizTalk group (reliability check).	How to Ensure Multiple Servers Are Part of a BizTalk Group
Determine whether any unstable code is being used, and if so, use separate hosts (reliability check).	High Availability for BizTalk Hosts
Perform functional testing of all new BizTalk applications (reliability check).	Testing an Application  "Staging Tasks for BizTalk Application Deployment" in BizTalk Server 2006 R2 Help athttp://go.microsoft.com/fwlink/?LinkID=103092.
Determine whether there are any unnecessary BizTalk applications, artifacts, and configurations (administration check).	Remove all unnecessary BizTalk applications, artifacts, and configurations.  For more information about removing a BizTalk application or artifact using the BTSTask command-line tool see "RemoveApp Command" in BizTalk Server 2006 R2 Help athttp://go.microsoft.com/fwlink/?LinkID=106721.  For more information about removing an artifact from an application using either the BizTalk Server Administration console or the BTSTask command-line tool, see "How to Remove an Artifact from an Application" in BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?LinkId=106722.
Check the BizTalk Server Administration console for any non-approved changes (administration check).	"Using the BizTalk Server Administration Console" in BizTalk Server 2006 R2 Help athttp://go.microsoft.com/fwlink/?LinkId=106723.
Check BTSNTSvc.exe.config for any non-approved modifications (administration check).	"BTSNTSvc.exe.config File" in BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?LinkId=106724.
Check the BizTalk Server-related registry keys for any non-approved modifications (administration check).	"Windows registry information for advanced users" article at http://support.microsoft.com/kb/256986
Run the Best Practices Analyzer for BizTalk Server (administration check).	"BizTalk Server 2006 Best Practices Analyzer" article at http://go.microsoft.com/fwlink/?LinkId=83317
Ensure that the latest service packs and updates are installed (administration and security check).	Microsoft Update site at http://update.microsoft.com/microsoftupdate/v6/default.aspx
Ensure that the artifacts for different trading partners are not installed on the same host (security check).	Configuring Hosts and Host Instances
Ensure that BizTalk Server is using only domain-level users and groups (security check).	"Domain Groups" in BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?LinkId=106725.
Ensure that the MSDTC Security Configuration is enabled (security check).	"Set the appropriate MSDTC Security Configuration options on Windows Server 2003 SP1 and Windows XP SP2" entry in "Troubleshooting Problems with MSDTC" in BizTalk Server 2006 R2 Help athttp://go.microsoft.com/fwlink/?LinkID=101609.
Determine whether the BizTalk Server cache refresh interval needs to be increased (performance check).	How to Adjust the Cache Refresh Interval
Determine whether the throttling options of each host need to be adjusted (performance check).	Inbound Host Throttling Outbound Host Throttling
Determine whether unnecessary tracking is enabled, such as orchestration, shape, and Business Rule Engine (BRE) event tracking (performance check).	How to Disable Tracking.  Planning for Tracking  Best Practices for Maintaining Performance (under "Monthly Performance Checks")  "Best Practices for Health and Activity Tracking" in BizTalk Server 2006 R2 Help athttp://go.microsoft.com/fwlink/?LinkId=106726.
Determine whether you are using a dedicated host for tracking maintenance (performance check).	How to Use a Dedicated Host for Tracking Maintenance
Determine whether the default XML send pipeline is being used instead of the PassThrough send pipeline (performance check).	"Managing Send Ports Using BizTalk Explorer" in BizTalk Server 2006 R2 Help athttp://go.microsoft.com/fwlink/?LinkId=106727.
Check the BizTalk Server database sizes for an increasing trend (performance check).	For more information about sizing the tracking database, see Guidelines for Sizing the Tracking Database.  For more information about sizing the MessageBox, BizTalkDTADb, and BAMPrimaryImport databases, see Identifying Bottlenecks in the Database Tier.
Determine whether the system is encountering database contention (performance check).	For more information about avoiding contention in the MessageBox database, see Avoiding Disk Contention.

IBM Lotus Domino 服務器維護 清單

Task	Frequency
Back up the server	Daily, weekly, monthly
Monitor mail routing	Daily
Run Fixup to fix any corrupted databases *	At server startup and as needed
Monitor Administration Requests database (ADMIN4.NSF)	Weekly
Monitor databases that need maintenance	Weekly
Monitor replication	Daily
Monitor modem communications	Daily
Monitor memory	Monthly
Monitor disk space	Daily, weekly, monthly
Monitor server load	Monthly
Monitor server performance	Monthly
Monitor Web server requests	Monthly
Monitor server first domino servers	Daily

另外也有非官方文檔，其餘系統管理員的經驗分享：

SQL Server 硬件檢查清單

The Basics
Hardware Manufacturer:
Model Number:
Serial Number:
Tower/Rack/Blade
Physical Location of Server:
Purchase Date:
Warranty/Service Contract Number:
Warranty/Service Telephone Number:
Date Warranty Expires:
CPU
Number of CPU Sockets:
Number of Installed CPUs:
CPU Model:
CPU Ghz Speed:
Number of Cores per CPU:
Type of Hyperthreading:
Is Hyperthreading on or off:
CPU L2 Cache Size:
CPU Bus Speed:
Motherboard BIOS Version:
Is BIOS Version Current:
Memory
Current Amount of RAM:
Additional RAM Capacity Available:
Number of Memory Slots Used:
Number of Memory Slots Available:
ECC Memory:
Network Adapter
Hardware Manufacturer:
Model Number:
Speed:
Number of Ports per Card:
Number of Cards:
BIOS Version Number:
Is BIOS Version Current:
NIC Speed/Duplex Setting:
Is the NIC Power Saving Feature Off:
Storage
Type: Local, DAS, SAN, Combo:
Local/Integrated RAID Controller
Number of Local RAID Controllers:
Type: SCSI, SAS, etc.
Controller Hardware Manufacturer:
Number of Ports:
Controller Model Number:
Controller Cache Size:
Is There a Cache Battery:
Is Write Back Caching On:
Controller BIOS Version Number:
Is Controller BIOS Version Current:
External RAID Controllers
Number of External RAID Controllers:
Type: SCSI, SAS, etc.
Controller Hardware Manufacturer:
Controller Model Number:
Number of External Ports:
Controller Cache Size:
Is There a Cache Battery:
Is Write Back Caching On:
Controller BIOS Version Number:
Is Controller BIOS Version Current:
Local Disk Configuration
RAID Configuration:
Number of Physical Drives:
Physical Dimension of Drives:
Drive Capacity:
Drive Speed/RPM:
Total Available Disk Space:
HBAs for External Storage
Number of HBAs:
Type: iSCSI, Fibre Channel, etc:
Type of Connectors:
HBA Hardware Manufacturer:
HBA Model Number:
HBA BIOS Version Number:
Is HBA BIOS Version Current:
DAS Disk Configuration
RAID Configuration:
Number of Drives:
Physical Dimension of Drives: