一本 Linux 开发人员的必备书籍

核心提示：不只适用于管理员在本专栏中向您推荐 Practice 有两个理由，首先，一本 Linux 开发人员的必备书籍，本书隐含着一些我打算详细说明的好处：也就是说，它不仅适用于管理，您会在自己的网络中发现许多弱点和“压力点”，如果您想探究更多细节，而且适用于开发，其次

　　不只适用于管理员
　　在本专栏中向您推荐 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 的另一个好习惯）下受维护。这样做，结果肯定会令您吃惊。您会在自己的网络中发现许多弱点和“压力点”。如果您想探究更多细节，我邀请您参加本专栏的论坛（单击本文顶部或底部的讨论是另一种访问论坛的方法）。