> 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/20220506-zai-nan-hui-fu/we-get-letters.md).

# 读者来信

* 原文：[We Get Letters](https://freebsdfoundation.org/wp-content/uploads/2022/05/letters.pdf)
* 作者：**Michael W Lucas**

亲爱的科技界最诚实建议专栏作家：

我被指派必须写公司的灾难恢复计划。说真的，这整件事就是糊弄人。我们没有资源去做真正的灾难恢复，我为之工作的那帮吝啬鬼也不会为任何准备工作付钱。但我又得拿出点东西。有什么最快、最简单的办法甩掉这个问题，好让我回去干正事？

——Doom WAD 玩不完的人

亲爱的资深系统管理员：

IT 专业人士的愤世嫉俗，主要问题在于还不够。我们以为愤世嫉俗就能为这个行业带给我们的最坏情况做好准备，但愤世嫉俗不是布尔值。一个人不是“愤世嫉俗”或“天真”。愤世嫉俗是邪恶君主的地下城。你探索得越深，越发现还能更深，但你永远探不到最坏的那一层。愤世嫉俗总能再深、再锐利。

你的反对并不源于需要一个灾难恢复计划。任何与计算机打交道的人都知道所有硬件和软件天生不可靠。你真正的问题是被分配了永远不会派上用场的工作。你的组织没有为灾难恢复投入任何资源。它只是合规主管清单上的一项复选框。公司认为他们需要勾选这个框，而不是真的为灾难做计划。你的问题只暴露了你令人遗憾的愤世嫉俗不足——而解决方案显而易见：

成为你想在世界中看到的灾难。

坏事总会发生。每个人在理智上都知道这一点。但人们要亲身经历一次短暂猛烈的毁灭冲击，才会真正内化自己有多脆弱。通过提供无缝、稳健的计算体验，你剥夺了组织必要的恐慌与绝望的接种。人们在经历过灾难之前，不会相信灾难恢复的必要。

在 Wi-Fi 出现之前的年代，我负责一家咨询公司的内部技术。我的职责之一是“安全”。如果你要假装运行安全的环境，每台设备都应要求某种认证才能配置。我们有许多没有密码的打印机，还有一大批不愿为打印机设置密码的人。我本可以花上几个月或几年争论密码的重要性，也可以接受共识然后等待。某天，公司老板在办公室里接待了一群访客，开关键会议。其中几人接入了办公网络以访问互联网。演示开始十分钟后，某个恶作剧者连上了一台过分好客的打印机，把它的 IP 地址和默认网关给换了。片刻之后，有人告诉我整个公司网络都瘫痪了。多亏我精通数据包嗅探器，几分钟内就识别并修复了问题。遗憾的是，我无法确定是谁在这样不便的时刻搞了这起恶毒恶作剧，但 CTO 在三十分钟后就强制推行了我偏好的密码策略。我建议在大会议室设置隔离访客网络，这一建议也立即被采纳，这使未来搞灾难更难，但并非不可能。毕竟，系统管理员应始终迎接挑战。

灾难恢复政策不必繁重。审视你的组织职能。哪些是关键的，哪些是多年前就该停止的？最关键的职能当然是薪资发放。被指派为灾难恢复规划者给了你打探的权力。深入你的组织，核实无论发生什么你都能拿到工资。在所有灾难恢复任务中，这一项总是最容易获得配合。毕竟所有人都是为了钱而来。即便是那些声称完全“使命驱动”的人，在钱不到位时也会变得暴躁。你的薪资管理员已尽力而为，但我从未见过哪个会计真正理解技术对背信弃义的渴望。你会发现问题。针对这一最关键任务，把你的建议写下来。这会给你带来可信度，因为你已经证明自己理解组织在人们生活中最重要的角色。

没有计划能被视为完成，直到它被测试过。

从那里扩展。每完成一部分计划就展示出来。如果有人反对，告诉他们“没关系”，然后把计划改为：在灾难中，此职能将不被恢复。嘿，这是个计划。它写下来了。它甚至很诚实。还能要求什么呢？一段时间后——不要太快，你不会希望人们注意到任何模式或趋势——一场小灾难或许会让他们改变主意，而你已经准备好了计划。

没有计划能被视为完成，直到它被测试过。理想情况下，每写一部分就测试一部分。没必要让任何人知道你计划第一稿里的所有缺陷。那只会让他们担心。在报废服务器上通过垃圾交换机验证你能否恢复备份。确保废料堆里有足够的机械硬盘，足以容纳重要的数据库，还有那些因为十五年前那次个人心理创伤事件，CEO 坚持要保持在线的愚蠢数据库。一旦你成功测试了一切，就安排一场你告知大家的灾难恢复测试。它当然还会有问题，但如果一切运行完美，没人会相信这是一次真正的测试。

灾难恢复计划的妙处在于它们总会被用到。即便你公司的总部在你下次绩效评估前不会被喷火河马焚毁，某天你那华丽的纯 SSD 存储阵列也会坍缩成一个裸奇点，你不得不从废料堆里捞出那台废弃的机械硬盘阵列，让它在负载下蹒跚前行。DBA 不会高兴，但 DBA 从来都不高兴，所以别理他们的抱怨。网络设备会意外故障，因为即使你把一切都配置为把错误吐到 syslog，没人会读日志。幸运的是，HP 仍然履行其著名的 10/100 交换机终身保修，所以如果你提前确认它们仍能工作，你就有现成的替换品。

对于最大的灾难——人——你无能为力。虽然你可以在计划里列出解决方案，但实施其中任何一项都会违法。你也许会照样执行，但请记住，文件会被视为预谋的证据。

是的，DOOM 很好玩，但真正的灾难可以更有趣。灾难恢复计划不必是浪费时间的无谓之举。磨砺你的愤世嫉俗，掌控不可避免之事，用灾难改善你的生活。

有问题想问 Michael？请发送至 <letters@freebsdjournal.org>

许多人把 **MICHAEL W LUCAS** 视作灾难专家，但这只是因为他常常出现在灾难的中心。他是《Absolute FreeBSD》、《FreeBSD Mastery》系列的作者，也写过记录 PAM、SNMP、TLS、DNSSEC 等灾难的书籍。完整书目见 <https://mwl.io>。他最近的新书是《Letters to **Ed(1)**》，收录了本专栏前三年的内容。把你辛苦赚来的钱花在其中任何一本上，将是另一场灾难。

***

《PAM Mastery》 by Michael W Lucas

可插拔认证模块（PAM）：威胁还是福音？

PAM 是系统管理中最容易被误解的部分之一。许多系统管理员宁愿忍受认证问题，也不愿冒险把事情弄得更糟。PAM 的本质使它不同于任何其他 Unix 访问控制系统。如果你有 PAM 苦恼或 PAM 谜团，你需要《PAM Mastery》！

“Michael W Lucas 又一次精准命中。”——nixCraft


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://freebsd-journal-cn.bsdcn.org/20220506-zai-nan-hui-fu/we-get-letters.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
