运维 / 平台工程师 / SRE

基础设施即代码、流水线定义、各种清单 —— 描述「应该存在什么」的那一大堆结构化文本。

在凌晨三点、有时间压力、信息不全的情况下决定:回滚什么、降级什么,以及在还没修好的时候对外说什么。

解释一张云账单、找出让它翻了三倍的那个东西,并判断哪一处低效值得占用一个工程师一周去修。

选架构、选你愿意承受哪些失效模式,以及决定两年后这个团队还运维得了什么。

过去招初级的那一级台阶 —— 写配置、接管线 —— 正是机制最清楚地对着的那一级,因为它是「结果可被机器判定」的代码。留给新人的于是是待命 —— 而那是最难的一部分,本来是要靠资历换来的。要在上待命表之前很久,就争取进入事故复盘。

你的筹码是设计决策和事故拍板,而两者在一周里都只占一小片。风险不是它们被自动化,而是围着它们的那些工时被削薄,直到一个工程师覆盖的服务多到没有一个人脑子装得下。要像服务员盯「人均桌数」那样,盯「人均服务数」。

保住并强化

往设计那一端走,离接线那一端远一点

设计决策没有自动裁判,而这正是没有工具能在它上面闭环的原因 —— 它也是这份工作里会复利的那部分。

调整职责

去负责「别人搭的东西好不好运维」

被生成的配置变多,意味着更多「没有人负责」的系统 —— 而总得有人守住「什么东西才被允许上生产」这条标准。

配置那一半在动,而且动得快 —— 因为基础设施代码要么干净地应用上去、要么报错,而「结果可被机器判定」正是让模型在无人看管下重试的那条性质。待命没有在动,因为一次事故按定义就是「没有人预想过」的那次故障,而拍板关于的是可接受的损害,不是正确答案。可能的形态不是被拿掉,而是被削薄:更少的工程师覆盖更多的服务 —— 每一项任务都还在,而待命变得更糟。

不给日期。有两个你自己就能算出来的数字,比任何预测都说明问题:你一周里有多大比例花在「应用上去要么成功要么报错」的工作上,以及你们待命表上现在每个工程师负责几个服务。前者是你的任务暴露度;后者才是真正会落到这一行的人身上的那个变化 —— 而它总是在任何工具落地之后一两个季度里悄悄移动。

通常不是。而这是本站最清楚的一个例子:一件「看起来像节省、表现得像负债」的工具。每创建一份资源,就是一份日后要有人维护、加固、并最终删掉的资源 —— 所以配置写得更快产出的是更多配置,不是更少的活;工时从「写」挪到「拆」。而拆在路线图上看不见,这恰恰是它被当成节省记进预算的原因。

它是这个职业里最安全的一项任务,同时也是最小的一项。一个设计对不对,要十八个月之后才知道 —— 也就是说没有自动裁判,因此没有任何工具能在上面闭环;但在多数团队里,设计决策一个季度只占几天。一个岗位完全可以在它最资深的任务上很稳,同时失去它大部分工时 —— 而要围着做规划的,正是这个落差。