> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/2026070809-sheng-chan-bu-shu/we-get-letters.md).

# 读者来信

* 原文：[Choice of Agonies](https://freebsdfoundation.org/our-work/journal/browser-based-edition/production-deployments/choice-of-agonies/)
* 作者：**Michael W Lucas**

**亲爱的建议君：**

我得到机会从零搭建一个全新的洁净室生产环境，操作系统和应用栈都由我来选！这是一生一次的机会，我却发现自己被各种选项淹没了。我知道你开玩笑说生产环境用算盘跑就行，实在不行用手指。可说正经的，我该怎么选？

**——困在分析瘫痪中**

**分析瘫痪君：**

写建议专栏最烦人的部分，并不是想建议。我快 60 岁了。我这辈子的失败经历随时可以为你提供教益——只要它们认为你会听劝。我的经验多到编委会不允许我写出来，那些胆小鬼还明文规定：任何建议里脏话的重量占比不得超过一成。

更不是你以为我在开玩笑这件事。我说的是实话。你的大脑出于可悲的自我保护本能，偏要把实话当成玩笑。

不，这份差事最让人恼火的，是那些明目张胆的假来信。

别误会。我完全清楚你们的来信都是假的。你们有些人连一丝最吝啬的想象力都不肯花，来给骗局遮片无花果叶。看看这个格外幼稚的例子：从零搭建一套新的生产环境？那数据中心大概是 Kongamato 管着，设备是圣诞老人送的吧——因为这种事根本不会发生。一切都建立在别的东西之上、之内、之外。计算这锅炖菜在灶上咕嘟了不知多少年：你父母从祖父母那儿继承，祖父母从曾祖父母那儿继承，曾祖父母当年坐着泰坦尼克号把它从旧大陆带过来。锅里的汤一少，你就往里扔点新鲜货，比如一棵芜菁。或者一个实习生。有时你切一块出来塞进肠衣，或者兑水做成汤，可只有不知羞的人才会管这叫新东西。

你说你有机会做洁净室安装，可洁净室这东西压根是个神话。

可惜啊，分析瘫痪君，你这个假来信是我这个月收到的唯一一封勉强沾边的假货，那就用它吧——但别以为，哪怕经过 NTP 校准的一瞬，你就能蒙混过关。

特里·普拉切特有一句名言：“希望是最好的礼物。”我绝不敢跟这位二十与二十一世纪最伟大的哲学家争辩。不过《系统管理法则》第 20 条提醒我们：“希望会让你做不好本职工作。”从这里入手正合适。

“完美环境”的神话弥漫在这摊乱糟糟的行当里。要是当初架构师选对了方案该多好！等你成了架构师才明白：没有正确答案，只有在各种痛苦之间做选择。挑一种疼法吧。我毫不掩饰把所有数据都放在 ZFS 上，但代价是：我用一个老实把块写到磁盘上的简单文件系统，换来了一个自带内存缓存算法、动态块大小、可调冗余度，以及不可避免、令人叹为观止的各种毛病的存储操作系统。你那台只有 1 TB 磁盘的虚拟机，会不会需要 3 TB 的物理底层存储？用 ZFS 的魔法，完全可能！

不，等等。有好处才叫“魔法”，没好处就叫“愚蠢”。

魔法与愚蠢，是同一件事从相反方向看到的样子。

抱怨生产环境问题，是系统管理员的一项神圣传统。在会议酒吧里泡一会儿，你很快就能认出这种讨论的套路。“新系统部署慢得要命，因为我们用 Ansible！”“用 Chef 更新软件简直是噩梦！”“我们倒是想，可我们用的是 Salt！”Apache 不行，nginx 不肯，lighthttpd 什么都做，唯独不做那些毫无疑问必须做的事，于是在五个不同的 Web 服务器前面塞一个 Caddy 反向代理，管这叫 HTTP/3。从零开始，只允许 Postgres 加 Python？太棒了！可惜每个市场部都要 WordPress，于是整个 PHP/MariaDB 生态被一并拖进来；哪怕你有架构上的全权，只要在会议上说出“污染”之类的词，也会被请去人力资源部。

生产环境能否成功，关键不在操作系统的选择。应用栈本身无关紧要。XMLRPC 还是 SOAP，还是 System V IPC？谁在乎？

生产环境部署成功与否，取决于一条简单的原则。

“把恐惧降到最低。”

就这一条。

如果管理、升级或调试某个工具会让你恐惧，就别用它。

这不是让你抱着熟悉的工具不放的借口。系统管理员必须不断学新东西。干这行的人迟早都会被拖到“白发议会”面前接受粗暴的盘问。如果认定你大致够格，那位充当 root 的人就会敲下法槌，宣布你是真正的系统管理员，并判处你终身强制学习。还好，意识会屏蔽掉这段恐怖经历，只留下一点底层创伤的残余。

你知道得越多，能察觉的糟糕之处就越多。恐惧不断增长，直到压垮你的事业或者你的循环系统。

如果无法把恐惧降到最低，就把它变成无聊。研究你环境里最糟糕的部分，反复练习它们。挑几种恐惧请来吃晚饭，来一场双方自愿但足够彻底的亲昵。没有无缘无故的可怕。人们总爱宣称某个软件或协议之所以可怕，是因为设计者是个白痴，但这种情况基本不存在。许多商业产品之所以可怕，是因为设计者的目的本就是从你口袋里掏钱，而不是解决你面对的任何问题。而在开源世界里，能活下来的糟糕工具，绝大多数是因为缺少不那么糟糕的替代品。那个糟糕的工具填的是一个更丑陋的窟窿，但理解这个窟窿，就能超越恐惧。

如果全都不管用呢？那就靠脚本、检查清单和流程——最好是把绝望外包给某个还没收到议会传票的幼稚青年的流程。把计算行业真正的可憎之处摊开给新手看，是你最负责任的一次帮忙——呃，是“为”新手做的最负责任的事。否则他们最后可能会写些假来信，试图钓鱼某个建议专栏作家。或者更糟：生出希望。

***

**Michael W Lucas**（<https://mwl.io>）写过太多书，包括 [*Absolute FreeBSD*](https://mwl.io/static/books/absolute-freebsd-third-edition.html) 和 [*$ git commit murder*](https://mwl.io/static/books/git-commit-murder.html)。他目前正一边躲着假释官，一边与 Allan Jude 合写 [*OpenZFS Mastery*](https://www.tiltedwindmillpress.com/product/openzfs-sponsor/)。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://freebsd-journal-cn.bsdcn.org/2026070809-sheng-chan-bu-shu/we-get-letters.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.