运维 / 平台工程师 / SRE · 任务逐条

写配置

这是「结果可被机器判定」的代码 —— 要么干净地应用上去,要么报错 —— 而这条性质正是让模型可以在无人监督下反复试错的那条。它同时以冗长重复著称,所以被起草的量很大,而复核很快。

配置写得更快意味着配得更多,不是活更少:每创建一份资源,就是一份日后要有人维护、加固、并最终删掉的资源 —— 工时从「写」挪到「拆」。而拆在路线图上是看不见的,这正是为什么这项任务最可能「看起来像节省、表现得像负债」。

被呼叫叫醒

自动修复是存在的,它处理的是「有人预想过」的故障;而一次事故按定义就是「没有人预想过」的那一个。这个决定关于的是可接受的损害,不是正确答案 —— 哪一种对客户可见的降级可以忍二十分钟 —— 那是一个业务判断,由一个事后会被追问的人承担。

决定留在人手里,完全没有说明待命表上有几个人。常见的设计是「更少的工程师、靠更好的自动化覆盖更多服务」—— 它保留了每一项任务,同时让待命变得更糟;而这件事可不可持续是一个人力配置问题,任何自动化指标都捕捉不到它。

它花多少钱,以及为什么

找出异常是分析,工具做得很好;而决定拿它怎么办,是一个在工程时间、风险和钱之间的取舍 —— 取决于这家公司这个季度想做成什么。前一半变便宜了很多,后一半没有。

分析变便宜抬高的是预期,不是降低工作量:一旦一块看板能点出最浪费的十项资源,就得有人为每一项「它为什么还在」给说法。任务从「调查」挪到「解释」,而解释是一场会。

决定它该怎么搭

在整个职业里,这是唯一一项没有自动裁判的任务:一个设计对不对,要十八个月之后才知道 —— 而那时做选择的人通常已经离开了。它取决于知道这个团队的能力上限和这家公司的容忍度,而这两样都不在任何代码库里。

最安全的那项任务同时也是最小的那项:在多数团队里,设计决策一个季度只占几天,而一周里其余的时间是那些正在被替你起草的工作。一个岗位完全可以在它最资深的任务上很稳,同时失去它大部分的工时。