不只適用於管理員 在本專欄中向您推薦 Practice 有兩個理由。首先，本書隱含著一些我打算詳細說明的好處：也就是說，它不僅適用於管理，而且適用於 開發 。 其次，本專欄的未來部分將引用本部分中提到的幾個參考資料。Expect 是上一個專欄的主題，它和 Pract
不只適用於管理員 在本專欄中向您推薦 Practice 有兩個理由。首先，本書隱含著一些我打算詳細說明的好處：也就是說，它不僅適用於管理，而且適用於
開發。
其次，本專欄的未來部分將引用本部分中提到的幾個參考資料。Expect 是上一個專欄的主題，它和 Practice 都會在未來部分中出現，並且，在開始閱讀未來部分之前，最好先透徹地理解它們。
Practice 與同類書籍有什麼不同 最近十年的大部分時間裡，UNIX 系統管理員的兩本標准參考書籍是 Nemeth 等人編寫的 UNIX System Administration Handbook 以及緊隨其後由 Aeleen Frisch 編寫的 Essential System Administration。假設打印機隊列出現了錯誤狀態，那麼您可以明智地希望選擇這兩本中的任何一本，並從中找到解決問題的命令。最近還出現了幾本良莠不齊的書籍，它們專門討論 Linux 系統管理。
Practice 不象這些書籍。它不僅對這些書籍進行了補充，而且在某種程度上取代了它們。大多數管理書籍中充斥著代碼；它們有 sendmail.cf 示例、大量 shell 腳本、top 的命令行參數說明等等。Practice 所針對的
知識主體要略微更抽象些，和 Mark Burgess 編寫的 Principles of Network and System Administration 大體相同。 Practice 的要點是將作為日常瑣碎工作的“如何”管理的問題提升為專業實踐的“為什麼”問題。
Practice 這樣做時基本上不引用特定程序或產品。實際上，它甚至不把自己綁死在某一操作系統系列上；其思想都能很好地應用於 MacOS、UNIX、
Windows 或其它企業操作系統。
一本關於管理的書籍卻沒有任何管理示例，對於您來說，這是否看上去很極端？對 Practice 的評價也很極端；大多數讀者得出的結論是他們要麼對它愛不釋手，要麼不喜歡它，甚至不願意把它作為贈品來接受。我顯然是前一個陣營中的。根本上，Practice 的所有理論都很實用。
例如，第 19 章是關於電子郵件的，當出現郵件循環、隊列分裂，或者需要過濾垃圾郵件、限制收件箱大小、歸檔流量或使樣板文件負責聲明時，它不會給您任何直接幫助。但是，它用簡單的語言展示了
可靠性、可伸縮性、可管理性等思想，必須保留它們使任何特殊任務有價值。
作者（還有我）怎能將一本沒有為解決任何特定問題提供處方的書叫做“實用的”呢？要點在於，如果您所知道的都是處方，那麼一旦離開處方起作用的小領域，您就束手無策了。Practice 假設您有找到處方的方法。它所承擔的任務是，用更深刻的理解補充這些處方，這樣您就能應付更一般或前所未知的新情況。並且，Practice 總是在每一章中強調自動化、忠實於標准、良好的文檔和清晰的溝通，作為搞好管理的基礎。
這個側重點導致了 Practice 與關於系統管理的早期書籍的又一個差異。關於管理的傳統書籍已經變成了“參考大全”，多少有點百科全書的味道：當您想得到一個有關 IP 分配問題的
解決方案時，就查找討論該主題的章節。相比之下，Practice 的許多讀者所做的是直接通讀本書 — 這本書是故事體的，“類似於小說”。他們學習本書以獲得對所有管理原則的連貫理解，然後轉到本書的網站（請參閱下面參考資料中的“EverythingSysadmin”）獲取到特定“如何做（how-to）”的鏈接。
這或許是趨勢的一部分。我覺得將來對充斥了代碼和“手冊”的“紫皮書”（Nemeth 的書的“戲稱”）的
需求會越來越少。越來越多的人希望在線得到此類信息。但是，我們仍然需要書面表述的信息是 Practice 中所包含的基於實際經驗的說明、分析和建議。
對於服務器編程的暗示 那麼，對於開發服務器端應用程序的讀者而言，“服務器診所”的意義何在呢？首先，Practice 是一本好書。它具有的概括信息正適合您的工作需要（服務器有什麼不同？如何使策略制度化？部署涉及什麼？如何管理您自己的事業）。還有，如果理解了管理員是如何思考的（或應該如何思考），則您可以更好地完成工作。
此外，Limoncelli 和 Hogan 用來管理的特定方法還強調了有利於
程序員的主題。他們顯式地標注了管理的設計和支持的六個要素：簡單、清晰、通用、自動化、溝通和“基礎優先”。程序員至少和管理員一樣需要這些要素。
Limoncelli 看來要在 make 文件上傾注他畢生的精力。他將
版本控制用於書籍本身的文本，或者更確切地說，是用於他和 Hogan 用來生成文本的“宏”。關鍵不在於 make 是一種偉大的語言；它不是。然而，它是一種用於管理更改和確保再現性的已證實的技術。作為程序員，很多挑戰是要應付不斷的更改：新的協議、應用程序編程接口（API）、客戶需求、硬件約束等。通過自動化和通用化使您自己掌握所有這些可變性。關於這一點，Practice 有正確的態度，並足以來教您。
在回答我向他們的提問時，Limoncelli 和 Hogan 提供了本書以外的關於考慮服務器的幾個技巧。前者強調：“服務器編程之所以不同，是因為更改管理成為了需求”。他還喜歡將服務和服務器區分開來：“任何有支票簿的白癡都可以買服務器，但運行成功的服務卻需要高度智慧”。
那些口號激發了本月家庭作業的靈感。許多商店監控著服務器，當服務器出問題時，使用連接到尋呼服務系統和其它通報器的警報。但您真正想要的，是一系列服務；服務器只是實現該目的一個手段。在學習 Practice 之後，自然會得出的結論是要構建服務監視器。盡管已出現了幾種商業監視器，並且許多組織使用“自產”版本，但是還沒遇到過令我滿意的。
讓我們概述一下它的工作原理：給定一個 /etc/service 風格的分配表（100.1.2.3 和 100.1.2.5 應該提供 HTTP 服務，而 100.1.2.6 提供 SMTP），監視器檢查受監控的主機上的所有端口。如果沒有打開其它端口，則它確保提供已定義的服務。結果被記錄到日志（Practice 展現了對日志記錄價值的良好理解），並且分配表在修訂控制（版本控制是 Hogan 和 Limoncelli 的另一個好習慣）下受維護。這樣做，結果肯定會令您吃驚。您會在自己的
網絡中發現許多弱點和“壓力點”。如果您想探究更多細節，我邀請您參加本專欄的
論壇（單擊本文頂部或底部的討論是另一種訪問論壇的方法）。
