凌晨两点四十手机在枕头边上震。不是闹钟是告警。我摸黑看了三秒屏幕——某核心服务的健康检查连续失败曲线正在往下掉。那一刻的清醒程度比我早上九点坐在工位上要高得多。这种日子过了几年之后我开始认真思考一个问题到底是我在运维这套系统还是这套系统在运维我。干运维是条不归路这句话我在饭桌上、群里、深夜的值班室里听过无数遍。说这话的人大部分并不是真的恨这份工作而是被某种说不清的东西耗着——活儿干得好没人知道出一次事全公司都知道。这种投入产出的极端不对称才是不归路这个说法真正的来源。运维、SRE、系统管理员、值班工程师叫法一直在变但那种随时待命、随时背锅的体感十年没怎么变过。这篇东西不打算劝你留也不打算劝你走。我想做的是把一个运维从业者在考虑跑路这件事时真正需要想清楚的几件事摊开你的时间到底被什么吃掉了、你的能力到底值多少钱、真要转的话有哪几条路能走、以及如果决定不走怎么让这活儿变得能长期干下去。适合正在值班表里挣扎的一线运维也适合刚入行一两年、还没想明白要不要继续的同学。1. 凌晨三点的告警才是这份工作的真面目很多人对运维的印象还停留在装装系统、重启服务、改改配置。真干过的人都知道这行的核心产品其实是不出事而不出事这件事本身是无法被看见的。你连着三个月零故障老板会觉得系统本来就该这样你一个月出两次P2所有人都会记住你的名字。这种价值认定的结构性缺陷是不归路体感的第一层来源。我在带人的时候经常让新人先做一件事把自己一周的时间按半小时粒度记下来连续记两周。结果基本都一样——真正在敲命令、写脚本的时间不到三成剩下的全是会议、工单、找人确认、翻旧文档、以及被临时插入的帮我看看这个。1.1 时间账一天到底被切成了多少段运维这活儿最大的问题不是累是碎。软件工程师可以连续四个小时进入心流写一个模块运维很难——你的工作日是被切成一格一格的每一格都可能被一通电话打断。而一次上下文切换的恢复成本心理学上比较公认的数字是十五到二十五分钟。也就是说上午被插三次这个上午基本就废了。我把典型的运维一天拆成了下面这几块你可以对照自己的情况看看比例对不对时间段典型事项是否可预期对能力的增值09:00-09:30交接班、看夜间告警、过一遍值班记录可预期低09:30-11:00处理工单、开通权限、配置变更部分可预期中低11:00-12:00被临时插入的排查请求不可预期中14:00-16:00项目性工作自动化、监控建设可预期但常被打断高16:00-18:00变更窗口准备、发布支持可预期中22:00-次日值班响应完全不可预期低到中看这张表你会发现一个问题真正能提升你能力的那一格下午的项目性工作恰恰是最容易被入侵的一格。因为临时排查永远比建设更紧急而紧急的事情永远会挤占重要的事情。这就是很多运维干了五年技能栈却和干了两年的差不多——不是不努力是时间结构不给你积累的机会。我的做法是把建设时间当成会议来对待写进日历标成忙碌不接受临时插入除非真的是P1。刚开始会被同事抱怨坚持一个月之后大家就习惯了——因为你会发现那些所谓紧急的排查请求里大概有一半其实可以等到下午。1.2 那些没人看见的隐形工作量运维工作里最容易让人心态崩的不是加班是做了但不算数。下面这些事你肯定干过但在季度总结里你根本写不进去花了两个小时翻遍半年内的变更记录最后定位到是三个月前某个业务方改了一行配置没通知任何人半夜三点爬起来处理告警结果是上游一个定时任务跑重复了五分钟自己恢复但你彻底睡不着了为了一个就改一下的需求评估了三套方案、写了两页风险说明、约了三个人评审最后对方说算了不做了反复跟业务方解释这个不是网络问题最后还是你去协调了研发、DBA、中间件三方问题解决功劳记在别人头上。这些工作在绩效体系里是隐形的。更麻烦的是故障少从来不是一个能被写成亮点的成绩——你没法证明因为我的存在所以这季度没出事这在逻辑上就是个不可证伪的命题。而出了三次故障是实打实的减分项。这种只罚不奖的评价结构时间长了必然消耗人。我在某个团队里推过一个小机制每次复盘后把这次没出大问题是因为哪个预案起了作用单独列一条。半年下来攒了十几条成了团队最硬的述职材料。这东西比任何总结都管用。2. 跑之前先算账你在运维这条链上到底站在第几环我要跑路这个念头很多时候是在一次特别糟心的故障之后冒出来的。但我见过太多人凭着这股情绪裸辞三个月后发现自己除了换个地方继续值班什么都没改变。原因很简单——他们把环境问题和能力问题混为一谈了。所以在动手之前先做一次诚实的自我盘点。这一步比刷任何面试题都重要因为它决定了你跑的方向对不应对。2.1 会操作和会设计之间隔着一条河运维能力有一个很明显的分水岭就是你在面对一个需求时第一反应是怎么把这个操作做出来还是这个系统应该长什么样。前者是执行后者是设计两者的市场定价差得远。举个具体的例子。业务说数据库扛不住了要扩容。执行层反应查文档加一个从库改连接串验证读写分离生效完事。设计层反应先看慢查询日志和连接池指标确认是读压力还是写压力如果是读压力评估加从库能撑多久业务侧有没有缓存改造空间如果是从库延迟导致的读抖动加从库反而会更糟然后算一下当前数据量下的容量拐点给一个三个月内必须做分库的结论和方案。同样叫处理了一个扩容需求前者在简历上只能写负责数据库扩容后者能写主导了一次容量评估识别出读放大瓶颈通过缓存层改造把扩容需求推迟了六个月。这两种描述在面试官眼里的分量完全不一样。我不太喜欢用层次这种词容易让人觉得被冒犯。但事实是市场上对运维的需求确实是分层的而且金字塔底部非常拥挤。2.2 一张四维自测表别靠感觉评估自己下面这张表是我自己用的你可以照着给自己打个分。每一维按 1 到 4 打分1 是知道概念2 是能独立操作3 是能设计方案并对结果负责4 是能带着别人做并且能判断方案在什么情况下会失效。维度具体能力项你的分数系统底座Linux内核参数、文件系统、进程模型、性能分析top/iostat/perf1-4网络与流量TCP状态机、DNS、负载均衡、抓包分析、超时与重试设计1-4工程化脚本、配置管理、CI/CD、容器与编排、IaC1-4业务与架构链路梳理、容量规划、SLO定义、成本核算1-4打完分你会发现一个规律绝大多数干了三年左右的运维前两维能到 3第三维到 2第四维基本是 1。而市场上溢价最高的恰恰是第三、第四维。我给的建议很直接如果前两维还没到 3先别急着跑把这个补上因为这两维是所有方向的公共地基换到哪个岗位都得用如果前两维已经稳了那就集中火力攻第三维和第四维这是决定你薪资天花板的两个维度。顺便说一句抓包分析这个能力被严重低估了。我面过不少人简历上写着精通网络问一句一个请求偶发超时你怎么判断是客户端问题、网络问题还是服务端问题能完整说出排查路径的不到三成。而这一类问题在真实工作里几乎每周都会遇到。3. 三条主路线的门槛差异SRE、平台工程、垂直专精运维转岗不是一个方向而是一组方向。我把市面上比较现实的三条路摊开讲重点不是告诉你哪条好而是告诉你每条路到底要补什么、门槛在哪里、以及什么样的人走起来会比较顺。3.1 往SRE走从修东西的人变成定义可靠性的人SRE这个词现在被用得很泛很多公司招SRE其实就是招运维只是换了名字。但真正的SRE岗核心工作方式的差别在于它是用工程手段去量化和管理可靠性而不是靠人肉响应。这条路的核心工具是 SLO 和错误预算。举个具体的写法假设你负责一个订单提交接口service: order-submit slo: - name: availability objective: 99.9% window: 30d indicator: good: http_status 500 total: all_requests - name: latency objective: 99% window: 30d indicator: good: duration_ms 300 total: all_requests按 99.9% 算30 天的错误预算是 43 分 12 秒。这个数字的意义在于它把要不要冒险上线从拍脑袋变成了算账预算还剩 40 分钟这个高风险变更可以做预算只剩 3 分钟这个月就别折腾了先稳住。要走这条路你需要补的东西大概有这些指标建模知道 REDRate、Errors、Duration和 USEUtilization、Saturation、Errors两套方法论各自适合什么场景能针对一个服务写出有价值的指标体系而不是把默认模板全勾上可观测性三件套指标、日志、链路追踪的取舍与成本控制。这里最容易踩的坑是无脑全量采集一个月账单翻三倍容量与压测能设计一次有意义的压测知道压测结果里哪些数字是假的故障演练能设计一个不会把生产打挂的混沌实验。门槛在哪门槛在于沟通。SRE 要让研发接受这次上线要延后靠的不是职位是数据和逻辑。如果你不习惯跟人争论这条路会走得很痛苦。3.2 往平台工程走把重复劳动变成产品和工具如果你发现自己每次值班都在做同样的几件事那说明你身边有一堆可以被产品化的需求。平台工程就是干这个的把运维的重复动作抽象成自助服务让别人不用来找你。这条路对工程能力的要求最高但也是最解气的一条路——因为你做出来的东西会实打实地减少你自己的工作量。具体要补的东西一门像样的语言Go 或 Python选一个深下去。我建议运维背景的人从 Python 起步做工具再补 Go 做服务因为 Python 的上手曲线更平缓能比较快地产出正反馈容器与编排不是会敲kubectl就算会而是要理解控制器模式、声明式 API、Operator 的工作原理。能自己写一个简单的 Operator这条路的门就开了IaC基础设施即代码Terraform 或者云厂商的等价工具。这块的价值在于让环境可复现也是很多团队最缺的能力CI/CD 流水线设计知道怎么把一个发布流程拆成构建、测试、灰度、验证、回滚几个阶段。我见过最快的一个转型案例是某公司的运维同学花了三个月把团队里申请一台虚拟机这个流程从填表找人审批改成了一套自助页面加自动化开通平均耗时从两天降到二十分钟。这件事本身技术难度不高但它同时证明了三件事你懂业务痛点、你能写代码、你能把东西交付上线。这三件事凑齐简历就已经很有说服力了。3.3 往垂直专精走数据库、安全、云架构这些香饽饽如果你不太想写大量代码但又想摆脱什么都管一点、什么都不精的状态垂直专精是另一条很实际的路。运维背景转这些方向有天然优势因为你本来就在生产环境里泡着见过的真实故障比纯做理论的人多。方向转型难度需要补的核心能力市场供需情况数据库中高执行计划分析、锁与事务、备份恢复演练、分库分表设计供给偏紧尤其是能做故障恢复的安全中漏洞原理、权限模型、日志审计、应急响应流程需求稳定合规驱动的岗位多云架构中网络规划、成本优化、多云/混合云设计需求大但要求综合能力强可观测性中低采集链路、存储选型、告警治理方法论岗位数量在增长我个人比较看好数据库和可观测性这两个方向。数据库是因为它的门槛在敢不敢在生产上动手这个门槛只能靠真实故障积累纯看书补不出来可观测性是因为大部分团队都处在一个尴尬状态——监控装了一堆真出事还是靠人肉翻日志这块的改造需求非常大。提醒一句垂直专精不等于只懂一个东西。我见过一些转做数据库的同学SQL 优化确实厉害但一涉及应用层的连接池配置、读写分离的流量分配就说不清楚了。真正值钱的是懂上下文的专家不是只懂自己那一块的专家。4. 决定不跑的话怎么把这活儿改成能长期干的样子说完跑的方向也得说说不跑的选择。其实很多人的问题不是岗位本身而是所在团队的运维方式太原始——纯人肉、纯响应、纯背锅。这种方式确实不归路但它是可以被改造的而且改造的收益会直接体现在你的工作体验上。下面这四件事是我这些年反复做、也确实见效的。4.1 告警治理先砍掉一半噪音再谈别的如果一个团队的告警每天几百条那这个团队的运维基本处于集体麻木状态。告警太多和没有告警一样危险因为人会本能地忽略。治理告警我一般按这个顺序做第一步统计。拉出过去三十天的告警数据按告警名称分组统计每条告警的触发次数和处理结果。通常你会发现一个经典的长尾分布排名前十的告警占了七成以上的量而这十条里大概有六条是自愈的或者没人处理的。第二步给每条告警定性。我用下面这个分类比较粗暴但有效类型特征处理方式actionable收到必须做事保留优化描述附上处理手册链接自愈型几分钟自己恢复改成聚合告警连续N次才发无人处理型收到了但没人管直接删掉或者降级为看板重复型同一个根因发很多条做抑制规则只发根因那条第三步改告警规则。举个实际的例子一条典型的磁盘使用率超过 80%告警写得好的版本大概长这样alert: DiskUsageHigh expr: | (1 - node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay}) 0.8 for: 15m labels: severity: warning team: infra annotations: summary: 节点 {{ $labels.instance }} 分区 {{ $labels.mountpoint }} 使用率 {{ $value | humanizePercentage }} runbook: https://内部手册/disk-cleanup impact: 该分区为日志盘预计按当前写入速度还有 6 小时写满关键点是三个for让瞬时抖动不触发、runbook让人收到告警知道该干什么、impact让人知道这事有多急。缺了后两个告警就变成了通知而不是行动指令。我在某个团队做过一轮治理告警量从日均八百多条降到七十条左右值班同学第一次能睡整觉。副作用是那七十条里的处理率接近百分之百——因为每条都值得看。4.2 变更管理让手抖变成可回滚的动作运维事故里我个人观察大部分都跟变更有关而其中很大一部分并不是技术多难而是改之前没想到会这样。变更管理的目标不是不让改而是让改错了好收场。我坚持的三板斧很朴素可灰度、可监控、可回滚。这三件事缺一件这个变更就不该上。可灰度能先影响 1% 的流量观察十分钟再扩大。做不到灰度的大变更拆成小变更也要做到可监控变更期间必须有一个明确的指标能反映这次改动是否生效、是否变坏。没有指标的变更等于蒙眼开车可回滚回滚必须是执行一个动作而不是再反向改一遍。这两者的差别在凌晨三点会体现得非常明显。下面这个回滚脚本我基本每个项目都会准备一份逻辑很简单但救命#!/usr/bin/env bash set -euo pipefail APPorder-api PREV_VERSION$1 # 上一版本号由发布记录提供 NAMESPACEprod echo [$(date %F %T)] 开始回滚 ${APP} 至 ${PREV_VERSION} # 1. 先摘掉流量避免回滚过程中请求打到半启动的实例 kubectl -n ${NAMESPACE} patch svc ${APP} \ -p {spec:{selector:{version:rolling}}} # 2. 回滚工作负载 kubectl -n ${NAMESPACE} set image deployment/${APP} \ ${APP}registry.internal/${APP}:${PREV_VERSION} # 3. 等待滚动完成超时则强制中断并告警 if ! kubectl -n ${NAMESPACE} rollout status deployment/${APP} --timeout180s; then echo 回滚超时请人工介入 exit 1 fi # 4. 恢复流量 kubectl -n ${NAMESPACE} patch svc ${APP} \ -p {\spec\:{\selector\:{\version\:\${PREV_VERSION}\}}} echo [$(date %F %T)] 回滚完成这段脚本没什么高深的东西关键在于它把回滚变成了一条命令而不是一次临场发挥。演练过三次以上真出事的时候手不会抖。一个血泪教训回滚脚本一定要定期演练。我见过一份写得非常漂亮的回滚脚本出事的时候执行报错因为里面引用的镜像标签半年前就被清理了。没演练过的回滚方案等于没有。4.3 把重复操作沉淀成剧本和代码运维的时间黑洞之一是同样的操作做一百遍。判断标准很简单如果同一件事你这个月做了三次以上它就值得被自动化。自动化是分层次的不要一上来就想着做大平台层次形态适用场景成本第一层脚本单点重复操作半天第二层剧本化多步骤、需要判断的流程一到两天第三层自助化别人也要用需要界面和权限一周以上第四层平台化跨团队、需要治理和审计按月计绝大多数人应该先老老实实把第一层做好。我见过太多团队想直接跳到第四层结果做了一年还是个半成品最后大家还是手工操作。一个具体的例子日常巡检这种活儿完全可以脚本化#!/usr/bin/env bash # 每日巡检把结果直接推送到群里人工只看异常项 set -uo pipefail REPORT/tmp/daily-check-$(date %F).log exec (tee -a $REPORT) 21 echo 巡检开始 $(date %F %T) # 1. 文件系统 echo --- 磁盘使用率超过 75% 的挂载点 df -hP | awk NR1 int($5)75 {print $6, $5} # 2. 系统负载与 CPU 核数的比值 echo --- 负载检查 LOAD$(awk {print $1} /proc/loadavg) CORES$(nproc) echo load${LOAD} cores${CORES} ratio$(awk -v l$LOAD -v c$CORES BEGIN{printf %.2f, l/c}) # 3. 关键服务端口 echo --- 端口监听检查 for p in 80 443 3306 6379; do ss -lnt | grep -q :${p} echo port ${p} OK || echo port ${p} DOWN done # 4. 近 24 小时错误日志量 echo --- 应用错误日志统计 grep -c ERROR /var/log/app/app.log 2/dev/null || echo 日志文件不存在 echo 巡检结束 这个脚本不到三十行但每天能省下十几分钟的机械劳动而且比人眼可靠。真正有价值的不是脚本本身而是把检查项固化下来这个动作——它会逼你去想清楚到底哪些东西是每天必须确认的。4.4 复盘会从谁的责任换到哪个环节失效这一条可能是四件事里最重要的也是最难推的。很多团队的复盘会开成了批斗会最后的结果是大家学会了在事故里保护自己而不是改进系统。有效的复盘有几个特征一是时间线必须精确到分钟。不是大约十点左右发现问题而是10:03 告警触发10:07 值班同学确认10:15 定位到数据库连接数打满。精确的时间线会自动暴露流程上的空白——你会发现从告警触发到有人响应平均要花十分钟那这十分钟就是可以优化的空间。二是根因要问到机制层。用连续追问的方式往下挖。为什么数据库连接数打满因为某个接口的连接没有正确释放。为什么没有正确释放因为连接池配置和代码里的超时时间不匹配。为什么这个不匹配没有被发现因为代码评审清单里没有这一项测试环境也压不出这个量级。到这里改进项就出来了补一条评审检查项加一个连接池指标的监控。三是改进项必须有主责人和时间。没有主责人和截止时间的改进项等于没写。我习惯在复盘文档里放一张表改进项类型主责人截止时间状态补充连接池使用率监控可观测性值班组本月底进行中代码评审清单增加资源释放项流程研发组下月初未开始压测场景覆盖长连接测试测试组下月中未开始四是明确无责原则但保留技术追责的边界。无责不等于不追究而是区分人的恶意/疏忽和系统设计缺陷。同一个人同一个错误犯了三次那是态度问题不是系统问题这个边界要讲清楚否则无责就变成了纵容。5. 简历和面试关运维转岗最容易被问穿的地方前面讲的是想清楚这一节讲怎么说清楚。我发现很多运维同学的简历写得很冤枉——干的活儿不少写出来却像流水账招聘方扫一眼都不知道你到底解决过什么问题。5.1 把维护过改写成改变过什么运维简历最大的毛病是全部用名词堆砌没有动词没有结果。举个例子原文负责 MySQL 集群的日常维护包括备份、监控、故障处理。这句话的问题在于它只说明了你的岗位职责没有说明你的能力水平。同样一件事换一种写法改写接手后重建了备份恢复流程把恢复演练从每季度一次改为每月一次恢复时间从平均四小时压缩到四十分钟期间发现并修复了两处备份文件损坏未被发现的问题。差别在哪前者是我在这个位置上后者是我改变了什么改变前后的数字是多少。招聘方看的从来不是你在什么位置上而是你让什么东西变好了。我建议每条经历都套这个结构背景一句话 你做的动作 可量化的结果。如果实在没有数字那就写清楚影响范围比如覆盖了三个机房、两百多台机器。下面这张表是我帮人改简历时常用的对照你可以拿去比照自己的条目常见写法问题改写方向精通 Linux无法验证人人是精通写具体场景某次内核参数调优把连接建立耗时降低多少负责监控系统建设太泛写清楚从多少条告警治理到多少条误报率降低多少参与自动化平台开发参与是模糊词写清楚你负责哪个模块上线后替代了多少人工操作处理各类线上故障等于没说挑一两个有代表性的写排查路径和最终根因5.2 面试官验证的三件事提前准备好答案转岗面试里技术问题其实不是最难的难的是那些看起来在聊天、实际上在验证的问题。根据我的经验面试官基本在验证三件事第一你的技术判断力是不是自己的。典型问法是你做过最难的一次排查是什么。这个问题真正的考点不是故障有多复杂而是你的排查路径有没有逻辑。好的回答会呈现一条清晰的收敛过程先看什么指标排除了什么可能再看什么排除了什么每一步都有一个如果这样说明什么的判断。差的回答是一堆操作罗列最后说重启就好了。准备这类问题时我建议挑一个真正有转折的案例。比如一开始所有人都以为是网络抖动你通过抓包发现请求根本没发出去最后定位到是应用层的线程池配置。这种推翻初始假设的案例说服力远大于我重启了服务就好了。第二你的能力边界是不是清晰的。典型问法是这个你没做过你会怎么入手。这个问题在验证你会不会装懂。诚实的回答是我没做过但我会先做这三件事查文档确认关键概念、找一个最小可运行的例子跑通、再看生产环境的实际配置。装懂的人会开始胡扯一问细节就崩。第三你能不能跟研发平等对话。转岗到 SRE 或平台工程你的合作对象主要是研发。如果面试里你表现出研发改的代码都是错的这种态度基本就废了。比较合适的表述是我会先搞明白他们为什么这么改很多时候是因为需求催得急那我要做的是把防护做在流程里而不是在事后指责。5.3 谈薪与选团队别从一口锅跳进另一口锅拿到 offer 之后的选择比面试本身更容易让人后悔。我见过太多人只看薪资涨幅结果跳过去发现值班强度翻倍、技术栈更老、团队只有两个人。谈之前有几个问题一定要问清楚而且要问到具体数字值班频率和补偿机制一周值几次有没有调休夜间响应算不算工时这个问题的答案直接决定你的生活质量团队规模和分工几个人负责多少台机器、多少个服务如果人均负责的服务数量超过某个阈值说明这个团队在靠人力硬扛变更和发布的现状有没有灰度能力回滚是手动还是自动发布频率是多少这能反映团队的真实工程化水平技术栈的演进方向现在用的是什么未来一年打算往哪走如果对方说我们很稳定不打算变那你要考虑三年后自己的技能是否还值钱这个岗位为什么招人是业务扩张还是前任走了如果是前任走了委婉地问一下原因往往能听出很多信息。我自己的经验是同样是涨薪百分之二十去一个每晚被叫醒两次的团队和去一个每月值班一次的团队一年后的状态完全是两回事。钱能补睡眠补不回来。6. 决定走了之后的九十天一份能照着做的过渡清单如果你已经想清楚要动那就别拖成想了两年还在想。我把自己和身边人验证过的节奏整理成了一份九十天清单重点在于它是可执行的而不是每天学习八小时这种正确但没用的话。6.1 第一个月清点资产建立作品第一个月不要急着投简历。这个月做两件事盘点你手里有什么以及造一个能拿得出手的东西。盘点的方式是把你过去两三年的工作全部列出来包括那些你觉得不值一提的事。列完之后按有没有可量化的结果分两栏有结果的直接改写成简历条目没结果的想一下能不能补上数据——很多数据其实能从监控系统、工单系统、变更记录里翻出来。同时开始做一个作品。运维背景的人最合适的作品是一个能跑起来的小工具而不是一个只有 README 的空仓库。比如一个能把某个日常手工流程自动化的脚本附带使用说明和效果对比一个基于开源组件搭的监控看板能体现你对指标体系的理解一个简单的 Operator 或者控制器能体现你对声明式 API 的理解。作品的价值不在于多复杂而在于它能被讲清楚。面试的时候我做了个东西把某个流程从两小时压到五分钟代码在这里这句话比任何形容词都有力。时间安排上第一个月我建议每天投入两小时左右周末各半天。不要辞职备考除非你有充足的储备——经济压力会严重影响判断力这一点我见得太多了。6.2 第二个月做真实的小项目别只刷题第二个月的重点是把知识变成能用的东西。这个阶段最容易走的弯路是沉迷于看教程和刷题看完感觉都懂了一动手就卡住。我的建议是找真实场景练手。如果你还在职就把工作里的一个真实痛点拿来练——比如把某个审批流程做成自动化的、把某个排查过程做成手册加脚本。真实场景的好处是它有各种意外情况这些意外才是能力的来源。如果实在没有场景可以用开源项目模拟。比如搭一套完整的服务包含负载均衡、应用、数据库、缓存然后自己给自己出题制造一次数据库连接泄漏、制造一次 DNS 解析失败、制造一次磁盘写满然后完整地走一遍发现、定位、恢复、复盘的流程把整个过程写成文档。这个练习的价值在于它会逼你把我知道应该看什么变成我实际操作过。面试里问到细节时做过和没做过的人回答的颗粒度完全不同。这个阶段还要开始整理问答。不是背题库而是把你自己经历过的、有代表性的问题整理成结构化的答案问题的背景是什么、初始假设是什么、怎么验证的、最后根因是什么、改进项是什么。准备五到八个这样的案例覆盖性能问题、可用性问题、容量问题、配置问题几个大类大部分面试题都能套进去。6.3 第三个月投递节奏和谈offer的细节第三个月开始正式投。这里有几个节奏上的建议不要一次投十家。先投三到五家你不太在意的公司用来练手和校准。面试是会进步的前两场一定比你想象中差把最想去的公司放在后面。每次面试后立刻复盘。当天晚上把被问到但答不好的问题记下来补上。三轮面试下来你的答案库就基本完整了。准备好一个反向提问的清单。面试最后你有什么想问的环节很多人浪费掉了。这其实是获取信息的最好机会前面 5.3 里列的那些问题都可以在这个环节问出来。关于薪资谈判。我的经验是转岗的时候不要只看总包数字要看结构。有些 offer 总包好看但把值班补贴、加班费都算进去了实际到手的工作体验很差。谈的时候把基本工资、绩效比例、值班补偿分开问清楚心里才有数。还有一个容易被忽略的点入职后的前三个月才是真正的考验。转岗意味着你要在一个新环境里重新证明自己这段时间的压力往往比面试还大。提前做好心理准备别把拿到 offer当成终点。我个人在实际操作中的体会是转岗这件事最难的不是技术是心态上的断舍离——你要接受自己在某些方面重新变成新人接受可能一段时间内做得不如原来的岗位顺手。这个过程大概需要半年到一年熬过去之后回头看那点不适应其实很值。最后再分享一个小技巧。如果你还在犹豫要不要走可以给自己设一个观察期三个月内不做任何决定但每周记录一次这周让我最想辞职的瞬间和这周让我觉得还行的事情。三个月后翻一遍如果负面记录几乎全是团队管理方式造成的那换个环境确实能解决如果全是我对这套系统的原理始终没搞明白那换环境只是把问题带过去而已。这个判断比任何人的建议都准。
凌晨两点四十手机在枕头边上震。不是闹钟是告警。我摸黑看了三秒屏幕——某核心服务的健康检查连续失败曲线正在往下掉。那一刻的清醒程度比我早上九点坐在工位上要高得多。这种日子过了几年之后我开始认真思考一个问题到底是我在运维这套系统还是这套系统在运维我。干运维是条不归路这句话我在饭桌上、群里、深夜的值班室里听过无数遍。说这话的人大部分并不是真的恨这份工作而是被某种说不清的东西耗着——活儿干得好没人知道出一次事全公司都知道。这种投入产出的极端不对称才是不归路这个说法真正的来源。运维、SRE、系统管理员、值班工程师叫法一直在变但那种随时待命、随时背锅的体感十年没怎么变过。这篇东西不打算劝你留也不打算劝你走。我想做的是把一个运维从业者在考虑跑路这件事时真正需要想清楚的几件事摊开你的时间到底被什么吃掉了、你的能力到底值多少钱、真要转的话有哪几条路能走、以及如果决定不走怎么让这活儿变得能长期干下去。适合正在值班表里挣扎的一线运维也适合刚入行一两年、还没想明白要不要继续的同学。1. 凌晨三点的告警才是这份工作的真面目很多人对运维的印象还停留在装装系统、重启服务、改改配置。真干过的人都知道这行的核心产品其实是不出事而不出事这件事本身是无法被看见的。你连着三个月零故障老板会觉得系统本来就该这样你一个月出两次P2所有人都会记住你的名字。这种价值认定的结构性缺陷是不归路体感的第一层来源。我在带人的时候经常让新人先做一件事把自己一周的时间按半小时粒度记下来连续记两周。结果基本都一样——真正在敲命令、写脚本的时间不到三成剩下的全是会议、工单、找人确认、翻旧文档、以及被临时插入的帮我看看这个。1.1 时间账一天到底被切成了多少段运维这活儿最大的问题不是累是碎。软件工程师可以连续四个小时进入心流写一个模块运维很难——你的工作日是被切成一格一格的每一格都可能被一通电话打断。而一次上下文切换的恢复成本心理学上比较公认的数字是十五到二十五分钟。也就是说上午被插三次这个上午基本就废了。我把典型的运维一天拆成了下面这几块你可以对照自己的情况看看比例对不对时间段典型事项是否可预期对能力的增值09:00-09:30交接班、看夜间告警、过一遍值班记录可预期低09:30-11:00处理工单、开通权限、配置变更部分可预期中低11:00-12:00被临时插入的排查请求不可预期中14:00-16:00项目性工作自动化、监控建设可预期但常被打断高16:00-18:00变更窗口准备、发布支持可预期中22:00-次日值班响应完全不可预期低到中看这张表你会发现一个问题真正能提升你能力的那一格下午的项目性工作恰恰是最容易被入侵的一格。因为临时排查永远比建设更紧急而紧急的事情永远会挤占重要的事情。这就是很多运维干了五年技能栈却和干了两年的差不多——不是不努力是时间结构不给你积累的机会。我的做法是把建设时间当成会议来对待写进日历标成忙碌不接受临时插入除非真的是P1。刚开始会被同事抱怨坚持一个月之后大家就习惯了——因为你会发现那些所谓紧急的排查请求里大概有一半其实可以等到下午。1.2 那些没人看见的隐形工作量运维工作里最容易让人心态崩的不是加班是做了但不算数。下面这些事你肯定干过但在季度总结里你根本写不进去花了两个小时翻遍半年内的变更记录最后定位到是三个月前某个业务方改了一行配置没通知任何人半夜三点爬起来处理告警结果是上游一个定时任务跑重复了五分钟自己恢复但你彻底睡不着了为了一个就改一下的需求评估了三套方案、写了两页风险说明、约了三个人评审最后对方说算了不做了反复跟业务方解释这个不是网络问题最后还是你去协调了研发、DBA、中间件三方问题解决功劳记在别人头上。这些工作在绩效体系里是隐形的。更麻烦的是故障少从来不是一个能被写成亮点的成绩——你没法证明因为我的存在所以这季度没出事这在逻辑上就是个不可证伪的命题。而出了三次故障是实打实的减分项。这种只罚不奖的评价结构时间长了必然消耗人。我在某个团队里推过一个小机制每次复盘后把这次没出大问题是因为哪个预案起了作用单独列一条。半年下来攒了十几条成了团队最硬的述职材料。这东西比任何总结都管用。2. 跑之前先算账你在运维这条链上到底站在第几环我要跑路这个念头很多时候是在一次特别糟心的故障之后冒出来的。但我见过太多人凭着这股情绪裸辞三个月后发现自己除了换个地方继续值班什么都没改变。原因很简单——他们把环境问题和能力问题混为一谈了。所以在动手之前先做一次诚实的自我盘点。这一步比刷任何面试题都重要因为它决定了你跑的方向对不应对。2.1 会操作和会设计之间隔着一条河运维能力有一个很明显的分水岭就是你在面对一个需求时第一反应是怎么把这个操作做出来还是这个系统应该长什么样。前者是执行后者是设计两者的市场定价差得远。举个具体的例子。业务说数据库扛不住了要扩容。执行层反应查文档加一个从库改连接串验证读写分离生效完事。设计层反应先看慢查询日志和连接池指标确认是读压力还是写压力如果是读压力评估加从库能撑多久业务侧有没有缓存改造空间如果是从库延迟导致的读抖动加从库反而会更糟然后算一下当前数据量下的容量拐点给一个三个月内必须做分库的结论和方案。同样叫处理了一个扩容需求前者在简历上只能写负责数据库扩容后者能写主导了一次容量评估识别出读放大瓶颈通过缓存层改造把扩容需求推迟了六个月。这两种描述在面试官眼里的分量完全不一样。我不太喜欢用层次这种词容易让人觉得被冒犯。但事实是市场上对运维的需求确实是分层的而且金字塔底部非常拥挤。2.2 一张四维自测表别靠感觉评估自己下面这张表是我自己用的你可以照着给自己打个分。每一维按 1 到 4 打分1 是知道概念2 是能独立操作3 是能设计方案并对结果负责4 是能带着别人做并且能判断方案在什么情况下会失效。维度具体能力项你的分数系统底座Linux内核参数、文件系统、进程模型、性能分析top/iostat/perf1-4网络与流量TCP状态机、DNS、负载均衡、抓包分析、超时与重试设计1-4工程化脚本、配置管理、CI/CD、容器与编排、IaC1-4业务与架构链路梳理、容量规划、SLO定义、成本核算1-4打完分你会发现一个规律绝大多数干了三年左右的运维前两维能到 3第三维到 2第四维基本是 1。而市场上溢价最高的恰恰是第三、第四维。我给的建议很直接如果前两维还没到 3先别急着跑把这个补上因为这两维是所有方向的公共地基换到哪个岗位都得用如果前两维已经稳了那就集中火力攻第三维和第四维这是决定你薪资天花板的两个维度。顺便说一句抓包分析这个能力被严重低估了。我面过不少人简历上写着精通网络问一句一个请求偶发超时你怎么判断是客户端问题、网络问题还是服务端问题能完整说出排查路径的不到三成。而这一类问题在真实工作里几乎每周都会遇到。3. 三条主路线的门槛差异SRE、平台工程、垂直专精运维转岗不是一个方向而是一组方向。我把市面上比较现实的三条路摊开讲重点不是告诉你哪条好而是告诉你每条路到底要补什么、门槛在哪里、以及什么样的人走起来会比较顺。3.1 往SRE走从修东西的人变成定义可靠性的人SRE这个词现在被用得很泛很多公司招SRE其实就是招运维只是换了名字。但真正的SRE岗核心工作方式的差别在于它是用工程手段去量化和管理可靠性而不是靠人肉响应。这条路的核心工具是 SLO 和错误预算。举个具体的写法假设你负责一个订单提交接口service: order-submit slo: - name: availability objective: 99.9% window: 30d indicator: good: http_status 500 total: all_requests - name: latency objective: 99% window: 30d indicator: good: duration_ms 300 total: all_requests按 99.9% 算30 天的错误预算是 43 分 12 秒。这个数字的意义在于它把要不要冒险上线从拍脑袋变成了算账预算还剩 40 分钟这个高风险变更可以做预算只剩 3 分钟这个月就别折腾了先稳住。要走这条路你需要补的东西大概有这些指标建模知道 REDRate、Errors、Duration和 USEUtilization、Saturation、Errors两套方法论各自适合什么场景能针对一个服务写出有价值的指标体系而不是把默认模板全勾上可观测性三件套指标、日志、链路追踪的取舍与成本控制。这里最容易踩的坑是无脑全量采集一个月账单翻三倍容量与压测能设计一次有意义的压测知道压测结果里哪些数字是假的故障演练能设计一个不会把生产打挂的混沌实验。门槛在哪门槛在于沟通。SRE 要让研发接受这次上线要延后靠的不是职位是数据和逻辑。如果你不习惯跟人争论这条路会走得很痛苦。3.2 往平台工程走把重复劳动变成产品和工具如果你发现自己每次值班都在做同样的几件事那说明你身边有一堆可以被产品化的需求。平台工程就是干这个的把运维的重复动作抽象成自助服务让别人不用来找你。这条路对工程能力的要求最高但也是最解气的一条路——因为你做出来的东西会实打实地减少你自己的工作量。具体要补的东西一门像样的语言Go 或 Python选一个深下去。我建议运维背景的人从 Python 起步做工具再补 Go 做服务因为 Python 的上手曲线更平缓能比较快地产出正反馈容器与编排不是会敲kubectl就算会而是要理解控制器模式、声明式 API、Operator 的工作原理。能自己写一个简单的 Operator这条路的门就开了IaC基础设施即代码Terraform 或者云厂商的等价工具。这块的价值在于让环境可复现也是很多团队最缺的能力CI/CD 流水线设计知道怎么把一个发布流程拆成构建、测试、灰度、验证、回滚几个阶段。我见过最快的一个转型案例是某公司的运维同学花了三个月把团队里申请一台虚拟机这个流程从填表找人审批改成了一套自助页面加自动化开通平均耗时从两天降到二十分钟。这件事本身技术难度不高但它同时证明了三件事你懂业务痛点、你能写代码、你能把东西交付上线。这三件事凑齐简历就已经很有说服力了。3.3 往垂直专精走数据库、安全、云架构这些香饽饽如果你不太想写大量代码但又想摆脱什么都管一点、什么都不精的状态垂直专精是另一条很实际的路。运维背景转这些方向有天然优势因为你本来就在生产环境里泡着见过的真实故障比纯做理论的人多。方向转型难度需要补的核心能力市场供需情况数据库中高执行计划分析、锁与事务、备份恢复演练、分库分表设计供给偏紧尤其是能做故障恢复的安全中漏洞原理、权限模型、日志审计、应急响应流程需求稳定合规驱动的岗位多云架构中网络规划、成本优化、多云/混合云设计需求大但要求综合能力强可观测性中低采集链路、存储选型、告警治理方法论岗位数量在增长我个人比较看好数据库和可观测性这两个方向。数据库是因为它的门槛在敢不敢在生产上动手这个门槛只能靠真实故障积累纯看书补不出来可观测性是因为大部分团队都处在一个尴尬状态——监控装了一堆真出事还是靠人肉翻日志这块的改造需求非常大。提醒一句垂直专精不等于只懂一个东西。我见过一些转做数据库的同学SQL 优化确实厉害但一涉及应用层的连接池配置、读写分离的流量分配就说不清楚了。真正值钱的是懂上下文的专家不是只懂自己那一块的专家。4. 决定不跑的话怎么把这活儿改成能长期干的样子说完跑的方向也得说说不跑的选择。其实很多人的问题不是岗位本身而是所在团队的运维方式太原始——纯人肉、纯响应、纯背锅。这种方式确实不归路但它是可以被改造的而且改造的收益会直接体现在你的工作体验上。下面这四件事是我这些年反复做、也确实见效的。4.1 告警治理先砍掉一半噪音再谈别的如果一个团队的告警每天几百条那这个团队的运维基本处于集体麻木状态。告警太多和没有告警一样危险因为人会本能地忽略。治理告警我一般按这个顺序做第一步统计。拉出过去三十天的告警数据按告警名称分组统计每条告警的触发次数和处理结果。通常你会发现一个经典的长尾分布排名前十的告警占了七成以上的量而这十条里大概有六条是自愈的或者没人处理的。第二步给每条告警定性。我用下面这个分类比较粗暴但有效类型特征处理方式actionable收到必须做事保留优化描述附上处理手册链接自愈型几分钟自己恢复改成聚合告警连续N次才发无人处理型收到了但没人管直接删掉或者降级为看板重复型同一个根因发很多条做抑制规则只发根因那条第三步改告警规则。举个实际的例子一条典型的磁盘使用率超过 80%告警写得好的版本大概长这样alert: DiskUsageHigh expr: | (1 - node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay}) 0.8 for: 15m labels: severity: warning team: infra annotations: summary: 节点 {{ $labels.instance }} 分区 {{ $labels.mountpoint }} 使用率 {{ $value | humanizePercentage }} runbook: https://内部手册/disk-cleanup impact: 该分区为日志盘预计按当前写入速度还有 6 小时写满关键点是三个for让瞬时抖动不触发、runbook让人收到告警知道该干什么、impact让人知道这事有多急。缺了后两个告警就变成了通知而不是行动指令。我在某个团队做过一轮治理告警量从日均八百多条降到七十条左右值班同学第一次能睡整觉。副作用是那七十条里的处理率接近百分之百——因为每条都值得看。4.2 变更管理让手抖变成可回滚的动作运维事故里我个人观察大部分都跟变更有关而其中很大一部分并不是技术多难而是改之前没想到会这样。变更管理的目标不是不让改而是让改错了好收场。我坚持的三板斧很朴素可灰度、可监控、可回滚。这三件事缺一件这个变更就不该上。可灰度能先影响 1% 的流量观察十分钟再扩大。做不到灰度的大变更拆成小变更也要做到可监控变更期间必须有一个明确的指标能反映这次改动是否生效、是否变坏。没有指标的变更等于蒙眼开车可回滚回滚必须是执行一个动作而不是再反向改一遍。这两者的差别在凌晨三点会体现得非常明显。下面这个回滚脚本我基本每个项目都会准备一份逻辑很简单但救命#!/usr/bin/env bash set -euo pipefail APPorder-api PREV_VERSION$1 # 上一版本号由发布记录提供 NAMESPACEprod echo [$(date %F %T)] 开始回滚 ${APP} 至 ${PREV_VERSION} # 1. 先摘掉流量避免回滚过程中请求打到半启动的实例 kubectl -n ${NAMESPACE} patch svc ${APP} \ -p {spec:{selector:{version:rolling}}} # 2. 回滚工作负载 kubectl -n ${NAMESPACE} set image deployment/${APP} \ ${APP}registry.internal/${APP}:${PREV_VERSION} # 3. 等待滚动完成超时则强制中断并告警 if ! kubectl -n ${NAMESPACE} rollout status deployment/${APP} --timeout180s; then echo 回滚超时请人工介入 exit 1 fi # 4. 恢复流量 kubectl -n ${NAMESPACE} patch svc ${APP} \ -p {\spec\:{\selector\:{\version\:\${PREV_VERSION}\}}} echo [$(date %F %T)] 回滚完成这段脚本没什么高深的东西关键在于它把回滚变成了一条命令而不是一次临场发挥。演练过三次以上真出事的时候手不会抖。一个血泪教训回滚脚本一定要定期演练。我见过一份写得非常漂亮的回滚脚本出事的时候执行报错因为里面引用的镜像标签半年前就被清理了。没演练过的回滚方案等于没有。4.3 把重复操作沉淀成剧本和代码运维的时间黑洞之一是同样的操作做一百遍。判断标准很简单如果同一件事你这个月做了三次以上它就值得被自动化。自动化是分层次的不要一上来就想着做大平台层次形态适用场景成本第一层脚本单点重复操作半天第二层剧本化多步骤、需要判断的流程一到两天第三层自助化别人也要用需要界面和权限一周以上第四层平台化跨团队、需要治理和审计按月计绝大多数人应该先老老实实把第一层做好。我见过太多团队想直接跳到第四层结果做了一年还是个半成品最后大家还是手工操作。一个具体的例子日常巡检这种活儿完全可以脚本化#!/usr/bin/env bash # 每日巡检把结果直接推送到群里人工只看异常项 set -uo pipefail REPORT/tmp/daily-check-$(date %F).log exec (tee -a $REPORT) 21 echo 巡检开始 $(date %F %T) # 1. 文件系统 echo --- 磁盘使用率超过 75% 的挂载点 df -hP | awk NR1 int($5)75 {print $6, $5} # 2. 系统负载与 CPU 核数的比值 echo --- 负载检查 LOAD$(awk {print $1} /proc/loadavg) CORES$(nproc) echo load${LOAD} cores${CORES} ratio$(awk -v l$LOAD -v c$CORES BEGIN{printf %.2f, l/c}) # 3. 关键服务端口 echo --- 端口监听检查 for p in 80 443 3306 6379; do ss -lnt | grep -q :${p} echo port ${p} OK || echo port ${p} DOWN done # 4. 近 24 小时错误日志量 echo --- 应用错误日志统计 grep -c ERROR /var/log/app/app.log 2/dev/null || echo 日志文件不存在 echo 巡检结束 这个脚本不到三十行但每天能省下十几分钟的机械劳动而且比人眼可靠。真正有价值的不是脚本本身而是把检查项固化下来这个动作——它会逼你去想清楚到底哪些东西是每天必须确认的。4.4 复盘会从谁的责任换到哪个环节失效这一条可能是四件事里最重要的也是最难推的。很多团队的复盘会开成了批斗会最后的结果是大家学会了在事故里保护自己而不是改进系统。有效的复盘有几个特征一是时间线必须精确到分钟。不是大约十点左右发现问题而是10:03 告警触发10:07 值班同学确认10:15 定位到数据库连接数打满。精确的时间线会自动暴露流程上的空白——你会发现从告警触发到有人响应平均要花十分钟那这十分钟就是可以优化的空间。二是根因要问到机制层。用连续追问的方式往下挖。为什么数据库连接数打满因为某个接口的连接没有正确释放。为什么没有正确释放因为连接池配置和代码里的超时时间不匹配。为什么这个不匹配没有被发现因为代码评审清单里没有这一项测试环境也压不出这个量级。到这里改进项就出来了补一条评审检查项加一个连接池指标的监控。三是改进项必须有主责人和时间。没有主责人和截止时间的改进项等于没写。我习惯在复盘文档里放一张表改进项类型主责人截止时间状态补充连接池使用率监控可观测性值班组本月底进行中代码评审清单增加资源释放项流程研发组下月初未开始压测场景覆盖长连接测试测试组下月中未开始四是明确无责原则但保留技术追责的边界。无责不等于不追究而是区分人的恶意/疏忽和系统设计缺陷。同一个人同一个错误犯了三次那是态度问题不是系统问题这个边界要讲清楚否则无责就变成了纵容。5. 简历和面试关运维转岗最容易被问穿的地方前面讲的是想清楚这一节讲怎么说清楚。我发现很多运维同学的简历写得很冤枉——干的活儿不少写出来却像流水账招聘方扫一眼都不知道你到底解决过什么问题。5.1 把维护过改写成改变过什么运维简历最大的毛病是全部用名词堆砌没有动词没有结果。举个例子原文负责 MySQL 集群的日常维护包括备份、监控、故障处理。这句话的问题在于它只说明了你的岗位职责没有说明你的能力水平。同样一件事换一种写法改写接手后重建了备份恢复流程把恢复演练从每季度一次改为每月一次恢复时间从平均四小时压缩到四十分钟期间发现并修复了两处备份文件损坏未被发现的问题。差别在哪前者是我在这个位置上后者是我改变了什么改变前后的数字是多少。招聘方看的从来不是你在什么位置上而是你让什么东西变好了。我建议每条经历都套这个结构背景一句话 你做的动作 可量化的结果。如果实在没有数字那就写清楚影响范围比如覆盖了三个机房、两百多台机器。下面这张表是我帮人改简历时常用的对照你可以拿去比照自己的条目常见写法问题改写方向精通 Linux无法验证人人是精通写具体场景某次内核参数调优把连接建立耗时降低多少负责监控系统建设太泛写清楚从多少条告警治理到多少条误报率降低多少参与自动化平台开发参与是模糊词写清楚你负责哪个模块上线后替代了多少人工操作处理各类线上故障等于没说挑一两个有代表性的写排查路径和最终根因5.2 面试官验证的三件事提前准备好答案转岗面试里技术问题其实不是最难的难的是那些看起来在聊天、实际上在验证的问题。根据我的经验面试官基本在验证三件事第一你的技术判断力是不是自己的。典型问法是你做过最难的一次排查是什么。这个问题真正的考点不是故障有多复杂而是你的排查路径有没有逻辑。好的回答会呈现一条清晰的收敛过程先看什么指标排除了什么可能再看什么排除了什么每一步都有一个如果这样说明什么的判断。差的回答是一堆操作罗列最后说重启就好了。准备这类问题时我建议挑一个真正有转折的案例。比如一开始所有人都以为是网络抖动你通过抓包发现请求根本没发出去最后定位到是应用层的线程池配置。这种推翻初始假设的案例说服力远大于我重启了服务就好了。第二你的能力边界是不是清晰的。典型问法是这个你没做过你会怎么入手。这个问题在验证你会不会装懂。诚实的回答是我没做过但我会先做这三件事查文档确认关键概念、找一个最小可运行的例子跑通、再看生产环境的实际配置。装懂的人会开始胡扯一问细节就崩。第三你能不能跟研发平等对话。转岗到 SRE 或平台工程你的合作对象主要是研发。如果面试里你表现出研发改的代码都是错的这种态度基本就废了。比较合适的表述是我会先搞明白他们为什么这么改很多时候是因为需求催得急那我要做的是把防护做在流程里而不是在事后指责。5.3 谈薪与选团队别从一口锅跳进另一口锅拿到 offer 之后的选择比面试本身更容易让人后悔。我见过太多人只看薪资涨幅结果跳过去发现值班强度翻倍、技术栈更老、团队只有两个人。谈之前有几个问题一定要问清楚而且要问到具体数字值班频率和补偿机制一周值几次有没有调休夜间响应算不算工时这个问题的答案直接决定你的生活质量团队规模和分工几个人负责多少台机器、多少个服务如果人均负责的服务数量超过某个阈值说明这个团队在靠人力硬扛变更和发布的现状有没有灰度能力回滚是手动还是自动发布频率是多少这能反映团队的真实工程化水平技术栈的演进方向现在用的是什么未来一年打算往哪走如果对方说我们很稳定不打算变那你要考虑三年后自己的技能是否还值钱这个岗位为什么招人是业务扩张还是前任走了如果是前任走了委婉地问一下原因往往能听出很多信息。我自己的经验是同样是涨薪百分之二十去一个每晚被叫醒两次的团队和去一个每月值班一次的团队一年后的状态完全是两回事。钱能补睡眠补不回来。6. 决定走了之后的九十天一份能照着做的过渡清单如果你已经想清楚要动那就别拖成想了两年还在想。我把自己和身边人验证过的节奏整理成了一份九十天清单重点在于它是可执行的而不是每天学习八小时这种正确但没用的话。6.1 第一个月清点资产建立作品第一个月不要急着投简历。这个月做两件事盘点你手里有什么以及造一个能拿得出手的东西。盘点的方式是把你过去两三年的工作全部列出来包括那些你觉得不值一提的事。列完之后按有没有可量化的结果分两栏有结果的直接改写成简历条目没结果的想一下能不能补上数据——很多数据其实能从监控系统、工单系统、变更记录里翻出来。同时开始做一个作品。运维背景的人最合适的作品是一个能跑起来的小工具而不是一个只有 README 的空仓库。比如一个能把某个日常手工流程自动化的脚本附带使用说明和效果对比一个基于开源组件搭的监控看板能体现你对指标体系的理解一个简单的 Operator 或者控制器能体现你对声明式 API 的理解。作品的价值不在于多复杂而在于它能被讲清楚。面试的时候我做了个东西把某个流程从两小时压到五分钟代码在这里这句话比任何形容词都有力。时间安排上第一个月我建议每天投入两小时左右周末各半天。不要辞职备考除非你有充足的储备——经济压力会严重影响判断力这一点我见得太多了。6.2 第二个月做真实的小项目别只刷题第二个月的重点是把知识变成能用的东西。这个阶段最容易走的弯路是沉迷于看教程和刷题看完感觉都懂了一动手就卡住。我的建议是找真实场景练手。如果你还在职就把工作里的一个真实痛点拿来练——比如把某个审批流程做成自动化的、把某个排查过程做成手册加脚本。真实场景的好处是它有各种意外情况这些意外才是能力的来源。如果实在没有场景可以用开源项目模拟。比如搭一套完整的服务包含负载均衡、应用、数据库、缓存然后自己给自己出题制造一次数据库连接泄漏、制造一次 DNS 解析失败、制造一次磁盘写满然后完整地走一遍发现、定位、恢复、复盘的流程把整个过程写成文档。这个练习的价值在于它会逼你把我知道应该看什么变成我实际操作过。面试里问到细节时做过和没做过的人回答的颗粒度完全不同。这个阶段还要开始整理问答。不是背题库而是把你自己经历过的、有代表性的问题整理成结构化的答案问题的背景是什么、初始假设是什么、怎么验证的、最后根因是什么、改进项是什么。准备五到八个这样的案例覆盖性能问题、可用性问题、容量问题、配置问题几个大类大部分面试题都能套进去。6.3 第三个月投递节奏和谈offer的细节第三个月开始正式投。这里有几个节奏上的建议不要一次投十家。先投三到五家你不太在意的公司用来练手和校准。面试是会进步的前两场一定比你想象中差把最想去的公司放在后面。每次面试后立刻复盘。当天晚上把被问到但答不好的问题记下来补上。三轮面试下来你的答案库就基本完整了。准备好一个反向提问的清单。面试最后你有什么想问的环节很多人浪费掉了。这其实是获取信息的最好机会前面 5.3 里列的那些问题都可以在这个环节问出来。关于薪资谈判。我的经验是转岗的时候不要只看总包数字要看结构。有些 offer 总包好看但把值班补贴、加班费都算进去了实际到手的工作体验很差。谈的时候把基本工资、绩效比例、值班补偿分开问清楚心里才有数。还有一个容易被忽略的点入职后的前三个月才是真正的考验。转岗意味着你要在一个新环境里重新证明自己这段时间的压力往往比面试还大。提前做好心理准备别把拿到 offer当成终点。我个人在实际操作中的体会是转岗这件事最难的不是技术是心态上的断舍离——你要接受自己在某些方面重新变成新人接受可能一段时间内做得不如原来的岗位顺手。这个过程大概需要半年到一年熬过去之后回头看那点不适应其实很值。最后再分享一个小技巧。如果你还在犹豫要不要走可以给自己设一个观察期三个月内不做任何决定但每周记录一次这周让我最想辞职的瞬间和这周让我觉得还行的事情。三个月后翻一遍如果负面记录几乎全是团队管理方式造成的那换个环境确实能解决如果全是我对这套系统的原理始终没搞明白那换环境只是把问题带过去而已。这个判断比任何人的建议都准。
