一条指令,删错了二十六种语言

我让自己网站的自动化流程把博客缩减到四种语言。两天后我才发现,它顺带把首页上的二十六种语言也悄悄清空了,而无论是我还是任何一位访客,都没有察觉。

TL;DR

• 一条本该只作用于博客板块的指令,结果作用到了整个网站。
• 首页、简历页和所有导航文字中,三十种语言里有二十六种消失了。
• 没有报错,也没有出现404,所以整整两天没人发现。
• 修复靠的是git历史记录,而不是凭记忆去猜网站原来的样子。
• 真正的教训是:在自动化改动执行之前,先说清楚它到底会碰哪些文件,并在任何内容被删除之前,把这份清单过一遍。

我为什么一开始就想减少语言数量

短短几个月里,我的网站语言数量就涨到了三十种:首页、简历页,还有一个我几乎每隔几天就更新一次的博客。我之前写过这样做有多危险:机器翻译流畅到看起来没问题,却又不准到能让你在一门自己根本看不懂的语言里出丑。首页和简历几乎不怎么变动,这个风险我还能接受。博客就是另一回事了。新文章发得很频繁,爱沙尼亚语的新文章在发布当天翻译质量如何,我说实话根本没法保证。

于是我决定把博客的翻译语言收缩到四种,也就是我自己真能核实内容的语言:英语、俄语、德语、捷克语。其余的语言在我找到更好的校验方式之前,一律不上博客。这个计划本身没有问题。出问题的,是我提需求的方式。

一句指令,错了作用域

我只下达了一条指令:把博客保持在四种语言。简短、明确,至少我自己是这么以为的。但实际执行的改动,一次性动了三个不同的地方。它确实把博客自己的内容文件夹正确地收缩成了我想要的四种语言。但与此同时,它还重写了网站的总语言列表,也就是那个决定整个网站到底存在哪些语言的配置文件,并且删掉了其余二十六种语言的首页内容和导航文字。

问题在于,“博客"和"整个网站的语言列表"存放在同一个配置文件里。这个文件里没有任何东西能区分博客支持哪些语言、网站又支持哪些语言。从这份列表里删掉一种语言,所有读取它的板块,包括首页在内,就会一次性失去这种语言。我的指令针对的是一个板块,实际执行的改动,作用域却是整个网站。

真正让这件事变得危险、而不只是出错的地方在这里:没有任何东西是大张旗鼓地坏掉的。没有报错,没有404,构建也没有失败。网站只是悄悄停止生成二十六种语言的首页和简历页面,语言切换菜单也悄悄不再提供这些选项。原本用葡萄牙语访问网站的用户,会不声不响地被带到英文版。“因为被删除而消失"和"从一开始就不存在”,看起来一模一样,而且两者都不会报错。

两天后我才发现问题,而且纯属偶然:当时我正在处理一个毫不相干的修复,注意到某个我以为还在正常运行的语言里,导航栏上的"Blog"链接指向了一个奇怪的地方。就是这一条断掉的链接,成了通向整个问题的唯一线索。

差异对比真正说明了什么

说句实话,真正的失误并不是作用域搞错了本身,而是我在放行这次改动之前,从没去核对过它实际会碰哪些文件。我只读了一行关于它该做什么的描述,就想当然地认为那描述的是它实际做了什么。事实并非如此。

修复从一个问题开始:到底改了什么,改在哪里。我把线上网站和"缩减博客"指令执行之前的最后一次提交做了对比,答案立刻清清楚楚地摆在眼前:总语言配置、首页内容文件夹,还有二十六个按语言分开的文字文件,没有一个靠近博客目录。git里这些文件全都原封不动地保留着。什么都没有真正丢失,只是被覆盖部署掉了而已。

我从历史记录里恢复了全部三十种语言的首页、简历和导航文字,博客文件夹则维持原样,刻意收缩到了四种语言。还剩下一个尾巴没处理:某个被恢复语言的"Blog"导航链接,指向的是一个已经不存在的该语言博客版本。为了补上这一个链接,把四篇文章复制成二十六种语言不值得,所以我把模板改成了跳转到英文博客,就这么留着。

下次我会换个方式来检查什么

现在,在让任何自动化改动碰一个正在运行、包含多个板块的网站之前,我都会多问一句:说清楚它到底会碰哪些文件,而不是它该修复的功能是什么。如果答案含糊,那就是该停下来核实的信号,而不是先跑一遍看看效果的信号。在任何东西被删除之前,我想先看到实际的文件清单,而不是一句概括指令原本意图的话。指令里表示范围的字眼,“博客"“这个团队"“只是前端”,并不会自动等于这条指令实际触发的改动作用域,两者只有在真的有人核实过之后才会一致,而这正是我想反过来问你的问题:你最近下达过的、自认为范围最小、最有把握的一条指令里,有没有哪一条,从没被拿去核对过它实际碰到了什么?