Wiki替换爆炸事件

一次偶然的错误，一个鲁莽的行为

开端

2022.11.28日，早晨

由于新版共鸣制度中不再明确出现鸟居的字眼，鲈鱼意识到鸟居的分类也需要迁移和改名。在发现迁移分类页面并不能影响子页面内的分类后，鲈鱼在wiki群内开始求助。

Au找到了一个可以批量替换的插件十分适合这个场景，决定呼叫鱼头来给wiki装上这个插件。这段消息被必应看到并叫来了星星，最终由星星装载了此插件君主离线制实锤

为了节省工作量，Au决定使用正则表达式来进行替换，但也是由于对新插件的不熟悉，正则表达式中“$1”的含义与预想中出现差异，直接导致替换结果的错误。但当时的大家都不知道这一点

发展

鲈鱼在看到Au的正则表达式后惊叹一声，并直接在未先进行小范围测试的情况下直接对全站的198个鸟居页面进行了替换操作。然后在发现这样可能遗漏分类页面后又重新操作了一次，这次的对象达到了250个页面之多。

也就是说，现在有448个更改操作积压在服务器，而罪魁祸首鲈鱼对此一无所知。

直到他自信地打开了最近更改，发现了替换后的分类变成了诡异的“Category:Category共鸣地标”才惊觉大事不好，可为时已晚。

鲈鱼提出尝试把自己封禁，但测试后发现此举无异于扬汤止沸，只能暂时停止后续的更改。

在反复查找批量回退方法无果后，鲈鱼和Au终于认命，开始手动一个个重新回退页面，殊不知，还有更大的惊喜等在后面。

高潮

还记得替换操作被下达了两次吗，问题就出在这里。

中午11点，本以为胜利在望的两人突然意识到还有替换操作在被执行。这一恐怖的事实无疑对二人是一次沉痛的打击，更严峻的是，对于同一页面的多次操作会被合并，这对回退工作又是一个很大的干扰。

目前的“最近更改”页面里，有只更改过一次的，更改过一次被重新回退的，回退后又被更改的和两次回退完成的四种页面交织在一起，组成了一幅地狱绘图。

所以深思熟虑之后，Au决定先去吃午饭。鲈鱼觉得这很对，决定吃完午饭再趴一会。

落幕

替换开始三小时四十分钟之后，所有积压的请求终于被清理完毕。

等候多时的250鲈鱼终于回退完了这250个页面。事件至此告一段落。

当时晚间，Au写出了正确的正则表达式，并完成了分类的替换工作。

反思

• 在进行大范围操作前，应先想好后路（回退方案）并做小范围测试

• 出现状况后应及时通知社群的其他人，防止扩大损失

• 当发现似乎出现问题时，应尽快停止操作并询问/讨论，而非鲁莽的重复操作

liziluyu写于2022.12.28晚