读者来信
作者：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
最后更新于