绿灯一直亮着 电路是断的

我给自己的网站打了 4.4 分 满分 10 打完我把结果贴在了自己的工作区里 没有藏着 因为这份审计首先是给我自己看的。

起因很简单 这个站我做了好几年 平时一切正常 页面打得开 文章发得出 测试全绿。 有天夜里我盯着那排绿灯 突然想到一个问题 这些测试 我有多久没看过它们到底测了什么了。

答案很不体面 不是很久没看 是从来没认真看过。 测试是当年搭站的时候顺手写的 写完之后我就再没动过它们 绿灯亮 我就放心 一亮我继续干别的。

我心里咯噔了一下 一个天天跟自动化打交道的人 居然把自己的安全带交给了几行几年没读过的代码 这事儿搁在别人身上我都得说两句。

于是我决定做一次正经的审计。 不是粗看 是把整个站按模块拆开 一个模块一个模块过 每一项都问三个问题。 这个功能真的有人用吗 它坏了我会第一时间知道吗 我的证据是什么。

问完我给了 4.4 分 分数不好看 但每个扣分我都说得出理由。

最扎心的一条不是功能缺失 是一批假绿灯。 有几个测试 跑起来是绿的 但它们测的是 mock 出来的固定数据 真实的请求路径 一个都没碰到。 换句话说 测试通过 和功能正常 是两件事。

打个比方 楼道里的应急灯一直亮着 你拔掉它的电源线 它还是亮的 因为那是接的另一路电。 你以为它在应急 它只是在装饰。

我在文件里把发现的问题分了级。 P0 是现在就危险 立刻修 P1 是一周内修 P2 挂进待办 P3 记下来就行。 分级的标准只有一条 这东西坏了 会不会在毫不知情的时候伤害用户。

P0 里有一条我记得最清楚。 有一个检查脚本 我一直以为它每天在跑 审计的时候我翻它的执行记录 最近一次成功的记录是几个星期前的。 中间它失败过 退成了后台的一个静默状态 没有任何东西提醒我。

一个监控系统 自己先悄悄死了 这是我这种做自动化的人最不该犯的错。 但它偏偏就发生了 因为我从没监控过我的监控。

顺着这条我又扫了一遍所有定时任务 做法不复杂 每个任务查最近一次成功时间 凡是超过预期间隔的 全部标记出来。 一晚上扫下来 名单比我想的长 有些任务我以为在守夜 其实早就下班了。

还有一次失败让我印象很深 我顺手修完 P0 就去改代码 改到一半才想起来 清单里最该先动的那个告警 还没补。 先修看得见的毛病 再补看不见的防线 这个顺序我老是搞反 报告写在纸上 顺序错在脑子里。

审计完我干了三件事。 第一 把所有 mock 测试标出来 一条条确认它们到底挡住了什么 挡不住任何真实风险的 直接删掉 删的时候手有点疼 毕竟是自己当年写的。 第二 给关键检查加了死亡检测 检查本身也要被检查 它没跑 我必须收到消息。 第三 定了一条规矩 以后每次想给系统加绿灯 先问一句 这个绿灯坏了 谁会发现。

我把这三条也推荐给任何自己维护产品的人 不用做多大的工程 就三个动作 列出你的绿灯 逐条问它测的是什么 给每个定时任务查一次最近成功的时间 给关键链路补一个失败告警。 一晚上就能做完 做完你可能会得到一个很难看的分数。

4.4 分我接受 低分不可怕 可怕的是满手绿灯 心里没底。 审计是给自己照镜子 镜子越诚实越好。

有人可能会问 4.4 分是不是太苛刻了 我觉得不苛刻 因为分数低只丢面子 分数虚高会丢半夜的觉 这两种损失 我选前者。

审计最值钱的产出 不是那个分数 是清单本身 分数过两个月就忘了 清单会一直盯着你

任何时候做任何事情 一定全心全意 一定全力以赴 这句老话 我在这次审计里又验证了一遍。 糊弄过去的部分 迟早会在你最没防备的时候 还给你。