解密：SCUTTLE

故事：[[[SCUTTLE]]] 这个故事本身相当简单，但是也包含了几个技术词汇。结构上来说，它基本是一个行动后报告，不过是针对电脑系统的。事情以一点点诡异开始，然后更诡异的事发生了--，Zeta-9（“鼹鼠”）[[footnote]]**译注：**原文如此，但按照下文应是Rho-9（“技术支持”）。[[/footnote]]搞砸了--。故事中也有许多聪明的小细节，但是它们不会影响故事情节。这些会被简单略过，放在附录里。所以，让我们开始吧。 ------ **第1部分：引入** > SCRAMBLE指令已发起，所有技术顾问及RAISA员工前往SITE-01 不管是什么东西坏了，它都重要到足以把所有人叫到一起来。 > 受影响系统：//**SCUTTLE**//。 一个叫//SCUTTLE//的东西出了问题，但//SCUTTLE//的真实本质还是一个谜，这个谜构成了本故事的核心hook。 > 受影响人员：{{RAISA，技术人员}}。 出的问题本质上是技术方面的，它涉及到了RAISA。简而言之，RAISA指“记录与信息安全管理部”，他们负责运行基金会内部网络并保证其安全性。 所以，我们知道，这个问题很可能与基金会内部通讯有关，而不是一个需要他们黑入的杀手机器人之类的什么。 继续下去，看事件的概况。 > **严重程度：**{{危急}} 事情很糟。 > **基金会人员伤亡可能性：**{{高}} 看起来它很可能会杀人。 > **公众传播风险：**{{高}} 它很可能上新闻。 > **事件状态：**{{正在进行}} 我们还没有修好它。 > **受影响站点：**{{输出错误：列表对象超出10,000个字符}} 它很可能影响所有站点，或至少比记录系统原来设计时预计能处理的站点数量要多。 从这里我们知道，我们在处理一件重大、可能导致一次K级情景的事件，而它和//SCUTTLE//有关。 ------ **第2部分：奇怪的事情开始了** > 票据历史 这一节是一系列描述这个事件展开的邮件。 故事从某人无法登录//SCUTTLE//开始，但对于//SCUTTLE//到底是什么依然没有做出解释。这个家伙接着去骚扰技术支持人员来修复登录问题。发起这个票据的人和技术支持有一段简短的意见交换。 另一位用户察觉到了//SCUTTLE//没有与Site-19通信，而这暗示了它本应该及时进行通信。技术支持人员无法远程登录//SCUTTLE//系统，从而确认它确实坏了。 > **用户rsmith04已将严重程度设置为{{中等}}。** 这件事已经从一件“我登不进去”的小问题变成了“没人能登进去”的中等问题，所以有一个人被派去检查物理硬件。 之后，我们发现，这个//SCUTTLE//本应该和许多或所有站点通讯。如果这套系统完全故障、无法通讯，他就要对其进行一项古老的技术支持技巧：[[[http://scpsandboxcn.wdfiles.com/local--files/csharpermantle%3Adrafts/scuttle_scpdec_reboot.mp4 | 重启]]]。 > 我没有从任何站点收到心跳包，所以你准备好了就去吧。[[footnote]]**译注：**这里采用的是本文译者自己的版本，而不是已有翻译[[[SCUTTLE]]]中的版本，因为彼版本的作者没有将原文“I'm not seeing any heartbeat from any of the sites, go ahead when you're ready.”的意思忠实表达出来，遗漏了“heartbeat”心跳包这一重要成分。[[/footnote]] 心跳包是一台电脑告诉另一台电脑它还活着的方法。其他站点没有一个能断定//SCUTTLE//还活着。所以重启吧！ > 尝试了多次重启，不走运。带来了另外一组外围设备，没区别。快照是什么样的？他们说它上周五肯定还能运转。我们有SCUTTLE的快照吗？ 可以预见，这不行。同样，更换硬件的一些外围部件也一样没用。该到从备份还原系统的时候了，一份快照就是整个系统的一份单独备份。 围绕该如何从备份还原引发了更多讨论。同时，那个发现问题的人一直在担心//SCUTTLE//不工作。我们发现了如果//SCUTTLE//连续坏了几个星期，就会有一些不好的事情发生，除非它被修好了。接着，关于实施还原的细节有了更多技术讨论。 然后我们看到了这个： > 我已经从SAN[[footnote]]**原文译注：**Storage Area Networking，存储区域网。[[/footnote]]上下载了旧映像并把它传入SCUTTLE。现在它只完成了POST[[footnote]]**原文译注：**Power-on Self-test，上电自检，接通电源后、启动操作系统之前，BIOS对设备进行的检查步骤。[[/footnote]]然后抛出一个E0x18 CORR_FS。你确定那些快照没问题吗？ 支持人员能够从备份还原，但是它一引导完成就立即崩溃了。接着，他们尝试着在一台另外的电脑上启动备份，来检查这是不是一个硬件问题。 接下来是一个请求，要求把//SCUTTLE//恢复到用备份覆盖之前的状态，但是由于用户操作失误没能完成。 既然备份失败了，是时候叫老大——RAISA主管Maria Jones——介入了。 > **用户tthomp03已将严重程度设置为{{高}}。** 该开始恐慌了。 在这一节里，我们了解到了//SCUTTLE//是一套坏了的计算机系统，如果它不能在情人节前被修好，一些未知的事情就将发生。 ------ **第3部分：有序地恐慌** 下一步我们从RAISA主管Maria Jones地方拿到了一封长邮件。这是对发生事情的简单总结，外加一个小问题。 > 我们可能遭遇了损坏的基础映像。 那些备份损坏了。这里有一份对这个问题的简单解释，它很好地代替我做了我的工作： > 基本上，我们一开始有一个系统里所有东西的列表，然后每周我们会追踪所有的更改然后把它指定为新的快照。这被称作增量映像，在存储上能够允许久得多的版本回复。 这里有几点注释：这对于备份来说是一件经常做的事，因为它能以一些处理时间的代价省下许多磁盘空间。 这里没有直接说明，但是他们认为基础映像在某方面损坏了。当基础映像损坏了，所有增量备份就一样损坏了，所以没有任何一份备份起效了。这里的一个有用类比是，在刚开始解某一道数学题的时候犯了一个错，于是错误就积累了下去。 然后，我们有了另一块证据： > [[span class="ruby"]]用以收容对生命和存在的非持续性威胁的系统[[span class="rt"]]System to Contain Unsustainable Threats To Life and Existence[[/span]][[/span]] 所以这就是//SCUTTLE//所代表的含义，听起来很重要，但不是那么清晰。用另外一种听起来很GOC的方法解释这个缩写就是“收容不可收容之物”。 > [[span class="ruby"]]SCUTTLE死者开关协议[[span class="rt"]]SCUTTLE Dead Man's Switch Protocol[[/span]][[/span]] 死者开关是一种在无响应时触发的开关。所以，很可能，如果与//SCUTTLE//通讯的站点在特定的一段时间之后没有收到信息，就会有些事情发生。 > 基础映像在创建时就已经检查过一致性，所以我还不能确定为什么我们会遇到这些问题。 备份坏了，而我们不知道为什么，这是在电脑圈子里常见的事。然后又有一些笔记，说明了另一些怪异之处，但它们与故事没有重要关系。 这一部分里，我们明白了//SCUTTLE//是基金会的死者开关。我们还知道了它用来收容不可收容之物。我们也知道备份没法用，事情正变得越来越糟。 ------ **第4部分：事情变得更古怪** 当技术团队深挖备份时，他们发现备份看起来很好，并没有损坏。尽管文件系统很奇怪，但所有东西都在该在的地方。 因为技术支持们对于是什么导致了崩溃毫无头绪，他们开始一行行看源代码，试图找出问题在哪里，是什么导致了错误。他们甚至打断了某人的假期来让她一起做这件事。 > 你们真的从来没测试过你们的备份方案吗？ 这是一件经常发生的事情。备份做好了，但从来没测试过；当它们要派上用场时，它们总是坏的。 然后我们发现了一件事，对我们的主角非常不利。//SCUTTLE//极其古老。只要是足够老的事务，都会有一些没人理解的远古系统，而且当它们不工作时后果极其严重。这些系统中的某些很可能正在为你所有的银行业务负责，另一些则很可能负责运行所有的核导弹。 当检查了源码后，他们发现在恢复备份的过程中有一个驱动错误。 一阵充满希望的交换意见后，我们看到： > 不行。多运行了很多，但是还是报错**E0x45 HSHFAIL**。Hash有校验吗？ 更多错误！[[span class="ruby"]]哈希[[span class="rt"]]Hash[[/span]][[/span]]校验是一种电脑用来确认文件是否未被修改的方法。像他们一样对驱动做修改会在哈希校验中导致失败。 > 我们查出那条信息的原因了，它和hash校验有关，但是实现这个校验的人该被拖出去枪毙。[[footnote]]**译注：**这里同样没有采用已翻译作品中的表述。彼版本中的implement被误译为“执行”，这里应该是软件开发术语“实现”，意为“使软件达到某个功能”。[[/footnote]] 当看别人写的代码时，这不是一个罕见的回应。看来写这些代码的人决定设计他们自己的哈希函数。代码就像SCP一样，除非有极好的理由，不要用格式错乱。 在这一部分里，我们继续尝试找出//SCUTTLE//的错误所在。我们唯一了解到的是这个系统很老了。文章里有一些可爱的技术细节和真实的对话，但是核心谜团没有继续展开。 ------ **第5部分：MTF Rho-9（“技术支持”）搞砸了** > **用户mjones06已将严重程度设置为{{危急}}。** 恐慌！ > **用户mjones06已添加情况{{SCRAMBLE}}。** 然后我们收到了解释//SCRAMBLE//具体是什么的邮件。简单来说，现在所有人都要去Site-01，去修复/备战这团乱麻。如果他们没能办到，所有人都要在//SCUTTLE//干出坏事几天前疏散。 这里有一些笔记，关于人们的任务。有一些会继续尝试修复//SCUTTLE//，一些人会尝试构建一个//SCUTTLE//替代品，另一些人会试图将所有基金会数据从站点取回。这意味着//SCUTTLE//干的坏事将对Site-01很不好。然后是更多实现细节。 现在，你的脑海里应该有关于//SCUTTLE//的很好想法了，接着我们读到了仿佛当头一棒的一句话。 > 我们也许是制造出了这个麻烦，但是让我们尽我们所能**拯救基金会**吧。 //SCUTTLE//失去联系会杀死基金会。//SCUTTLE//是凿沉你自己的船舰以防止其落入敌人之手的方法。//SCUTTLE//很可能是一套自毁系统，以防止基金会落入敌人手中。 最后，我们看到了最后的备忘^^TM^^，一封来自Maria Jones的邮件，向所有人说明了到底发生了什么。我们首先看到了我们已经知道的RAISA的概况。然后我们获得了将一切连结在一起的关键信息。 > 我们还容纳有一台机器，叫做//SCUTTLE//，是我们在敌对势力或无法预见的异常入侵时的最终手段。//SCUTTLE//也被称为“死者开关”，凭借此系统，假如你们的站点长期未收到//SCUTTLE//（也即Site-01）的消息，站内的核弹头将被引爆，其威力照预期将能够蒸发你们所在的特定站点。 好吧，听起来很不好...... 在混沌分裂者攻击时，K级情景或大规模收容失效很有希望无效化尽可能多的异常，以防止它们落入敌手或造成更多破坏。所以，它被称为//用以收容对生命和存在的非持续性威胁的系统//。没有了控制系统，所有核弹都会引爆。然后是一些备忘，说明了之后会发生什么。 他们确实对此有预案，但并不是很好。他们计划，如果他们修不好这该死的东西，在//SCUTTLE//最早引爆时间的4天前疏散人员。 同样，记得我说这会上新闻吗？所有核弹同时引爆很可能吹爆你报纸的头版。基金会计划把它掩盖起来，但是那该死地难。我们以这个尾声结束： > 基金会将挺过难关，因为它必须如此。我们全体人员感谢您在此情况下的配合。 所以这就是//SCUTTLE//。这是一个关于基金会如何被击倒的故事，不是因为收容失效，不是因为外星人攻击，也不是因为还没有打的鲨鱼，更不是那些世界终结的有趣方式，而是因为一个小小的电脑故障。它也是对坚持已建立的代码格式、经常检查你的备份是否工作的一份提醒。如果你不检查你的备份，你就等于没有备份。 ------ **附录A**[[footnote]]**译注：**附录部分的原文发表于原解密的评论区内。[[/footnote]] 文章里也还有一大把优秀的技术细节。它们和情节无关，但它们非常酷。 > 10.101.25.███ 所有属于10.XX.XX.XX网段的IP地址都属于私有范围。这个范围在公共网络上不可被路由到，它被内部局域网使用。 > 做好通过从冷存储到物理媒介的方式来做这个的打算吧 这意味着他们需要从实际的硬盘驱动器上恢复信息，而不能够使用内置的恢复功能。 > 现在它只完成了POST然后抛出一个**E0x18 CORR_FS** 这是SCUTTLE抛出的第一个错误，继续阅读可以将其翻译为错误代码24[[footnote]]**译注：**十六进制的0x18等于十进制的24。[[/footnote]]，“找不到核心文件系统”[[footnote]]**译注：**原文如此，属作者笔误。原作者[[*user pxdnbluesoul]]（u/bluesoul）在reddit上评论，指出了解密作者的错误：此处应为“损坏的文件系统”。[[/footnote]]。如果你以一种你的电脑无法从其上启动的方式格式化了你的电脑，你会得到同种类型的错误，因为引导媒体不存在。 > KB10235 这代表了知识库项目10235。这是一种技术人员组织安排文档的常见方式。 > 这些备份试图恢复的方式，它试图在正确的驱动器之前加载一个不兼容的RAID驱动器，系统在其余驱动器加载之前就报错了。那必然导致文件系统错误， 就像我之前说的一样，当它要引导时无法读取硬盘，所以引导失败。 还有，为什么这个故事里有两个以“SC”开头的缩写啊？我不小心把这篇解密发成了SCRAMBLE。