当您拨打 800 号码投诉您的麦片中发现死虫，或者询问为什么您的新调制解调器在旧的 486 电脑上无法工作时，您很可能不是直接与产品制造商对话。随着 80 年代和 90 年代的企业不断剥离那些不被认为是核心优势的业务职能，呼叫中心外包的垂直市场迅速增长。位于伊利诺伊州皮奥里亚的 Ruppman Marketing Technologies 是该行业的先驱之一，为客户公司接听电话已有 26 年的历史。随着互联网在主流应用中的扩展变得不可忽视，该公司着眼于将其市场扩展到互联网上的客户服务。

我于 1997 年 4 月被聘用，负责监督这一新领域。Ruppman（“作家规则”）及其许多竞争对手已经含糊和犹豫地采取措施，回复来自网站的电子邮件咨询，并发送通过网络表格请求的小册子，但我们的 CEO 委托我超越这些胆怯的步骤，并将 Ruppman 定位在人们更可能在网站上查找答案而不是拨打 800 号码的必然时代。

我带着业余 Linux 背景加入公司，我立即清楚地意识到开发预算有限，并且在有限的时间内可以部署广泛的技术。Linux 是唯一具有实现我们目标的灵活性和价格的解决方案。

Ruppman 在其传统的电话交换机和路由领域拥有先进的基础设施，但其数据基础设施的演进却相当随意。公司拥有各种各样的互联网接入方式，包括

实际上，在缺乏官方电子邮件客户端标准的情况下，Microsoft Exchange 用户数量不断增长。

首先，我们订购并设置了一台戴尔 Poweredge 2200（奔腾 II，200MHz，64MB 内存），安装了 Caldera OpenLinux，作为我们的电子邮件邮局（使用 Sendmail）和主域名服务器（使用 BIND）。我们最终与 AT&T 达成协议，安装防火墙。现在，我们有了一个统一的互联网网关，可以关闭所有其他昂贵或不安全的通道，从而消除了办公室对调制解调器的需求（见图 1）。这也使我们能够充分利用我们注册的 ruppman.com 域名，将我们的电子邮件地址标准化为 firstname.lastname@ruppman.com 格式。

图 1. Ruppman 的互联网连接，之前（上半部分）和之后（下半部分）。

使用 Sendmail 还允许我们实施一个常见的客户要求。当 Ruppman 处理客户电子邮件时，客户希望它看起来像是他们自己在处理电子邮件。因此，Widget Inc. 将其客户指向 widget@ruppman.com 是不合适的。他们更愿意使用 customerservice@widget.com。对于收件来说这很容易，但我们必须屏蔽来自 Ruppman 代表发送给 Widget 客户的邮件。这是通过在 列表 1 中向 Sendmail 的 mc 配置文件添加规则，然后使用 m4 编译 mc 文件并将其安装为 /etc/sendmail.cf 来完成的。（有关自定义 Sendmail 规则的信息，请参阅 Mail HOWTO。）

客户还希望获得诸如电子邮件查询的自动回复和选定的外发邮件审计副本等功能。此外，许多客户的业务量需要不止一位代表，使用基于主题的路由或共享邮箱。Microsoft Exchange 可以处理其中一些功能，但我们需要更大的灵活性，并且担心标准合规性。客户端邮箱都设置为 Linux 服务器上的 IMAP 邮箱，这为我们带来了以下优势

电子邮件代表使用 Netscape Communicator 作为 IMAP 客户端，但由于其 IMAP 客户端界面存在错误，我们正在评估替代方案。

我们新的互联网架构还具有额外的优势，即我们可以根据使用情况将互联网访问成本分配给各个部门。我们在主 Linux 服务器上实施了一个 Python 脚本，以解析 syslogd 收集的防火墙日志，并生成每个部门使用的字节数的报告。

构建 Intranet 很快成为我们的下一个举措。我们在同一台戴尔 Linux 服务器上安装了 Apache WWW 服务器和 Samba Netbios 服务器。Samba 用于将 Linux 目录导出为主要 Windows 95 用户群的公共共享，或作为我们部门 Internet Services 的密码保护的私有共享。其他部门开始以惊人的速度将数据附加到我们的 Intranet 上。显然，这种简单而强大的技术满足了对信息共享工具的巨大需求。Apache 和 Samba 功能在整个公司都被大量使用，并且运行良好。事实上，虽然我们后来将一些功能卸载到其他服务器上，但在几个月的时间里，一台基于奔腾 Pro 的服务器运行 Linux，为 1000 多名用户运行邮件、DNS、中央日志记录、IMAP、SMB 和 WWW，几乎没有停机时间。

我们还使用了本机 Linux 工具（如 DBM 数据库）和 Python 实用程序（如日历套件）来为 Intranet 添加有用的内容。我们发布了一个电话列表，该列表经常更新，以及 Ruppman 客户列表。我们在 Intranet 上维护 Internet Services 活动和时间表日历，并提供对具有互联网代理访问权限的人员数据库的访问。

这些系统迅速将 Ruppman 带到了具备基本互联网能力的程度，但这还远远不够。为互联网上的客户服务的未来做准备涉及相当多的应用程序开发，因此在我的团队中组建了一个团队来完成此目的。

开发团队开始使用 C、C++ 和 shell 脚本的组合，但我们很快就确定 Python 作为我们的总体开发语言。我们的首席软件工程师和我曾在我们之前的职业生涯中使用 C++ 作为基石，但我们很快就欣赏 Python 的表达能力、全面的库和简洁的语法。我们购买了一台 Compaq ProLiant 2500（奔腾 II，300MHz，64MB 内存）作为开发服务器和故障转移备份。我们预计在其上运行 SCO UNIX，但由于习惯了 Linux 发行版附带的广泛工具集，我们发现 SCO UNIX 相比之下非常不足。编译或安装我们最喜欢的工具的努力被证明非常麻烦，以至于我们很快放弃了 SCO，转而使用 Caldera OpenLinux。不幸的是，我们随后发现 Compaq 服务器不太适合 Linux。Compaq 为其 ManageWise 服务器管理套件添加了许多专有功能，并且没有将这些功能的“代理”移植到 Linux，因此机器的大部分设计必须绕过才能运行 Linux。也许是出于这个原因，这台机器在运行 Linux 时被证明相当慢，我们正在用一台戴尔 Poweredge 4200（双奔腾 II，300MHz，64MB 内存）替换它。

第一个主要的开发任务是创建一个互联网经销商定位器。这个流行的网站功能是一个应用程序，允许客户输入他或她的地址或邮政编码，并接收附近的经销商或服务中心列表。Ruppman 已经有一个在大型机上运行的此类应用程序，供电话代表使用，但 Internet Services 决定从头开始构建一个定位器，使用对象关系数据库和地理匹配（geo-matching）模块。我们选择 PostgresSQL 作为数据库，因为它具有对象关系并且支持空间关系（r 树）。它还具有本机 Python 接口 PyGres。由此产生的应用程序是重度磁盘 I/O 绑定的，我们最终购买了一台 Sun Ultra Enterprise（双 UltraSPARC2，250MHz，128MB 内存），因为它具有高带宽背板和硬件可扩展性。从那时起，我开始更多地了解基于 Alpha 甚至 Sun 机器的可比较的 Linux 设置。

我的团队开发的另一个产品是 Usenet 和网络监控服务，我们代表客户在 Usenet 和 WWW 上搜索消费者对其公司或产品的讨论。首先，我们根据搜索引擎剪辑文章，然后我们的代表检查剪辑的相关性。我们设置了一台 Linux 服务器并在其上安装了 NNTP，以便可以使用 Python 脚本搜索 /var/spool/news，该脚本调用递归的 grep。然后将命中累积在一个文件中，代表使用自定义 Web 界面梳理该文件。

我的 Ruppman 团队以如此快的速度和如此低的成本开发的许多强大的基于 Web 的应用程序很快引起了其他部门的注意。会计部门一直在尝试实施自动跟踪员工工时的技术，并且他们在使用昂贵且不合适的供应商产品的经验中受到了打击。他们问我们是否可以实施一个解决方案。我们快速组装了一个系统，该系统将时间增量和标识 PostgresSql 数据库（在 Linux 服务器上）中任务的代码保存在一起。员工可以通过由 Javascript 和 Python CGI 驱动的 Web 界面输入他们的工时，该界面托管在 Linux Intranet Web 服务器上（见图 2）。他们还可以以熟悉的工时表格式查看结果。然后，主管可以审查和批准条目。每周一次，cron 作业计算加班时间，并将批准记录的报告发送给会计部门，在那里将其导入到 JD Edwards 会计软件中。

图 2. 员工工时记录

管理所有这些项目并将它们从开发服务器转移到生产环境很快成为一项令人困惑的任务。由于我们的大多数项目都是基于 Web 的，因此我们必须将 HTML 文件移动到正确服务器上正确的 HTTPD 文档目录，CGI 可执行文件必须经过特殊处理，并且我们必须维护通用 Python 模块库。我们采用了 CVS 进行版本控制，但我们找不到通用的实用程序来管理我们的大部分需求，因此我们使用 Python 和 Javascript 编写了一个自定义工具（见图 3）。我们称之为开发管理器的工具读取开发服务器上的配置文件，该文件保存项目列表、源文件和发布目标位置。然后，它允许用户查看项目、从项目中发布文件以及连接到版本控制。

图 3. 项目开发管理器

保持生产服务器上的守护程序和应用程序更新是安全和标准合规的重要组成部分。Linux 新闻和资源的广泛可用性在这方面为我们提供了极大的帮助。我们经常在与其他部门合作时发现，基于其他操作系统的服务器往往存在版本滞后问题。一些 NT 服务器没有打补丁来防御猖獗的 teardrop 拒绝服务攻击，我们发现一台关键任务 HP 9000 机器正在运行 1994 年的守护程序，包括 Sendmail，这通常是黑客的目标。大多数时候，造成滞后的原因是更新不易于跟踪，甚至难以应用于 NT 和 HP-UX 等环境。在某种程度上，这取决于系统管理员的警惕性，但 Linux 社区使保持责任变得异常容易。

但是，我们最近决定，跟上 Caldera OpenLinux 1.1 文件的老旧 RPM 集变得过于繁琐。我们的测试表明 GNU glibc 库的功能具有一些优势，因此我们将所有 Linux 机器升级到 Red Hat 5.0。除了 Disk Druid 出现问题以及安装程序没有正确设置 /etc/hosts 和 in.ftpd 文件的奇怪事实之外，我们对新发行版非常满意。缺点是我们失去了 Caldera 的 Novell Directory Services 客户端的好处，而我们组织的其他部门正在迁移到 Novell Intranetware。

总而言之，Ruppman 已经证明了 Linux 在实际商业应用中的适用性的一个引人注目的案例。Linux 出色的健壮性使我们能够在我们的团队内保持高服务水平，其灵活性和广泛的工具集使我们能够快速解决各种问题，而在其他平台上，这些问题将需要漫长的研究和大量投资。IT 人员对 Linux 最常见的保留意见涉及技术支持，但在将近一年的时间里，我们从未给 Caldera 或 Red Hat 打过电话。我们几乎通过在 http://www.dejanews.com/ 上查询解决了我们的每一个问题，这是一个优秀的 Usenet 存档和搜索引擎。虽然我很幸运地在技术选择方面几乎没有受到管理层的干预，但我确信，如果 Linux 倡导者可以将我们最喜欢的操作系统偷偷地引入到一个适度可见的应用程序中，其低成本和高性能将开始打破其被接受的障碍。我希望我在 Ruppman 的经验能为这个方向提供一些启发。