Owner意识

Owner 意识 = 问题到我为止，哪怕不归我管，我也负责推动到解决。

举个例子，驻场的时候有一次客户反馈系统偶尔卡顿，按分工这属于应用层问题，不是运维的活。但如果我只说'这是开发的 bug，你找开发'，客户的问题还是没解决，驻场运维的价值就没了。所以我做的是：先自己定位——查 ELK 日志发现某个接口响应时间周期性飙高，再查发现是定时任务和业务高峰抢占数据库连接，最后把日志证据、时间点、复现路径整理好交给开发，并且跟进到修复上线，事后还在周报里写了这个案例的排查路径。

所以我认为 Owner 意识不是'什么都自己干'，而是'不归我的事，我也负责推动闭环；归我的事，我负责到底'——客户/业务只关心问题解没解决，不关心这个问题在组织架构上属于谁。"

"另外 Owner 意识还有一个容易被忽略的维度：对线上有敬畏心。Owner 不是'这系统归我管所以我说了算'，而是'这系统归我管，所以任何变更我都要想清楚失败会怎样、能不能回滚'。我在项目里坚持所有发布都有回滚预案、所有操作留文档，就是这个意识落地的体现。"

On-call

On-call = 值班制：非工作时间（晚上、周末、节假日）线上出故障，电话/告警打给你，你要第一时间响应（通常要求 15-30 分钟内上线处理）。这是运维/SRE 岗位的标配，也是这个岗位最真实的代价。

第一是责任边界：告警响了，我是第一响应人，'先看看是不是我的问题'这种犹豫是不能有的——先止血、再定位、再移交，优先级永远是这样。我在上一家公司虽然不是正式 On-call 排班，但项目上线初期我负责保障，半夜处理过客户现场的告警，知道那种'必须马上清醒过来'的感觉，我能接受这种工作节奏。

第二是平时多流汗，战时少流血：我觉得好的 On-call 体验靠的是平时的稳定性建设。值班痛苦程度直接反推日常工作的质量——如果告警 noisy（误报多）、预案缺失，每个班都是噩梦。所以我上项目时很重视告警阈值调优和故障预案文档，这也是我自己的工作习惯：把'救火'变成'按预案操作'。