35 岁运维还能不能转 AIOps？关键不是年龄，是能力结构！

本文站在一线运维 / SRE的角度聊聊 35 岁运维转 AIOps 到底有没有机会。凌晨两点半手机又响了。不是闹钟是告警。那种声音很多运维人都懂铃声一响心先沉一下。你还没睁开眼脑子里已经开始过一遍是不是刚才那批发布有问题是不是数据库连接池打满了是不是某个接口又超时是不是业务方又在群里 所有人我之前经历过一次挺典型的故障。晚上十一点多做了一次常规发布发布窗口看起来很平稳。监控大屏没什么异常接口成功率也还行大家在群里说“观察十分钟没问题就收工”。结果凌晨一点多告警开始炸。先是应用层接口 RT 升高接着 Nginx 5xx 增加然后数据库慢查询报警再后来 Redis 连接数也上去了。微信群里一堆机器人通知Prometheus 告警、日志平台告警、APM 告警、业务探活告警全都来了。值班同学第一反应是扩容扩了两台应用实例没用。第二反应是回滚回滚之后指标没有立刻恢复。第三反应是查日志日志量太大关键错误被一堆无关异常淹没。领导在群里问“现在定位到根因了吗”说实话这句话在凌晨听起来杀伤力很大。真正难的不是没有数据而是数据太多。指标、日志、调用链、告警、发布记录、配置变更、数据库慢 SQL、容器事件全都有。但它们分散在不同系统里每个系统都能告诉你“我这里有异常”却很少有系统能告诉你“这些异常之间是什么关系最可能的入口在哪里”。最后我们查出来根因并不复杂某个新版本调整了缓存 Key 的生成逻辑导致缓存命中率突然下降大量请求打到数据库数据库慢查询增加接口 RT 升高线程池排队最终引发连锁告警。这件事如果写成复盘结论很简单发布前压测不足缓存变更风险评估不足监控告警关联能力不足故障定位耗时过长。但如果站在一个 35 岁左右的运维 / SRE 角度看这里面还有另一个问题我们还能不能继续靠“人肉经验”扛下去以前我们觉得经验足就能搞定。看一眼 CPU 曲线大概知道是不是流量突增看一眼 GC 日志大概知道是不是内存问题看一眼慢 SQL大概知道是不是索引没走看一眼调用链大概知道哪个服务在拖后腿。但现在系统越来越复杂。微服务、容器、Kubernetes、Service Mesh、云原生中间件、Serverless、跨云、多 Region、国产化、信创、混合云……链路越来越长组件越来越多告警越来越密。靠一个老运维在凌晨靠直觉判断已经越来越吃力。这也是很多中年运维开始关注 AIOps 的原因。不是因为这个词多时髦而是因为大家真的被告警、变更、故障、巡检、容量、稳定性压得喘不过气。很多人问我“35 岁了还能不能转 AIOps”我的答案比较直接能。但关键不是年龄是你的能力结构有没有重新组合。AIOps 不是让你从头变成算法工程师也不是让你放弃多年运维经验去卷大模型论文。真正适合运维人切入 AIOps 的方向是把你过去积累的故障经验、系统理解、自动化能力、监控体系和稳定性治理方法转化成机器能用、平台能复用、团队能沉淀的能力。这篇文章不讲空概念也不神化 AI。我们就站在一线运维 / SRE的角度聊聊 35 岁运维转 AIOps 到底有没有机会优势在哪里焦虑来自哪里经验怎么变成体系能力以及一条可以执行的转型路线。35 岁运维的优势不是“会修机器”而是知道哪里最容易出事很多人一说 35 岁就先想到劣势精力不如年轻人学习新框架没那么快家庭压力大不能天天熬夜面试还容易被问“年龄偏大能不能适应强度”。这些都是现实。但如果只看这些就把中年运维的价值看低了。35 岁左右的运维如果是真正在生产环境里摸爬滚打过的身上有几个优势是非常适合 AIOps 的。1. 你知道故障不是从一个红点开始的刚入行的时候我们看监控经常是哪里红了看哪里。CPU 高了看 CPU磁盘满了清磁盘接口超时就看接口日志。干久了以后会发现真正的故障很少是单点问题。一个接口超时背后可能是数据库慢查询、缓存雪崩、线程池耗尽、DNS 解析慢、上游依赖抖动、网关限流、配置中心推错参数甚至可能只是某台宿主机网卡有丢包。一个 Pod 重启表面看是 OOMKilled实际可能是流量倾斜、代码内存泄漏、JVM 参数不合理、容器 Limit 设置过小也可能是某个定时任务突然拉了全量数据。AIOps 要做根因分析靠的不是把一堆指标扔进模型里就完事。它需要知道系统之间的依赖关系需要知道什么异常是原因什么异常是结果什么告警可以降噪什么告警不能忽略。这些判断不是算法自己凭空长出来的。它需要运维经验喂进去。老运维的价值就在这里。你知道哪些告警是“狼来了”哪些告警必须半夜爬起来你知道一次发布之后最该盯哪些指标你知道数据库连接数升高时不能只看连接数还要看慢SQL、锁等待、线程池、连接池配置和调用方重试。这些都是 AIOps 落地时最需要的场景知识。2. 你见过足够多的“非标准故障”教科书里的故障都很干净CPU 高、内存泄漏、磁盘满、网络不通。真实生产环境里的故障很脏。比如一次接口超时最后发现是业务方传了一个特别大的分页参数。一次数据库抖动最后发现是 BI 同学在白天跑了一个全表扫描报表。一次 K8s 节点压力升高最后发现是日志采集 Agent 版本升级后 CPU 占用异常。一次消息堆积最后发现是下游消费接口返回码设计不规范导致消费者以为处理成功实际上业务失败后又被人工补偿。一次发布故障最后发现不是代码问题而是配置中心灰度规则没覆盖某个机房。这些问题都不标准。它们很难靠一个通用模型自动解决但非常适合沉淀成知识库、故障模式、规则模板、异常关联逻辑和自动化诊断流程。AIOps 真正落地靠的不是“AI 猜一猜”而是把这些脏活、经验活、重复判断逐步结构化。3. 你知道组织里的真实阻力很多 AIOps 项目失败不是因为模型不够先进而是因为压根没人用。平台做得很漂亮告警聚合页面也有智能根因也有知识问答也有。结果一到故障现场大家还是回到微信群里靠人喊“DBA 看一下”“网络同学看一下”“应用负责人在吗”。为什么因为一线同学不信。他不信这个平台给的结论也不信自动化脚本不会误操作更不信一个 AI 摘要能替代自己翻日志。做过运维的人知道生产环境里最贵的是信任。你要让大家敢用 AIOps必须先让它在小场景里证明自己。比如先做告警降噪先做日志摘要先做故障报告生成先做巡检异常识别先做“建议模式”而不是一上来就搞全自动自愈。中年运维的优势是懂组织懂流程懂变更审批懂值班机制懂事故复盘也懂每个团队最在意什么。这类经验在 AIOps 项目里非常重要。传统运维为什么越来越吃力很多老运维不是不努力也不是不学习而是过去那套工作方式本身已经到了瓶颈。1. 告警太多真正有用的太少以前我们经常遇到一种情况一个故障真正发生时群里不是没有告警而是告警太多。服务 A 响应慢触发接口 RT 告警服务 B 调用 A 失败触发错误率告警网关检测到 5xx触发网关告警数据库连接数升高触发数据库告警业务探活失败触发可用性告警APM 发现调用链异常也触发告警。最后微信群里几十条消息同时刷屏。问题是这些告警里到底哪个是源头很多团队的告警规则是按组件建的应用归应用数据库归数据库网络归网络中间件归中间件。每个团队都说“我这边有异常”但故障现场需要的是“这些异常之间的关系”。没有关联关系告警越多定位越慢。更麻烦的是误报和抖动告警。比如 CPU 瞬间超过 80% 一分钟就报警磁盘 IO 短时间抖一下也报警某个接口 P99 突然高一下也报警。久而久之大家会形成告警疲劳。最可怕的是真正严重的告警被淹没在一堆低价值告警里。2. 日志很多但关键日志不好找日志平台是运维必备工具但很多团队的日志治理其实很差。有的服务日志级别乱打INFO 里塞了大量无用信息ERROR 里却没有关键上下文。有的日志没有 traceId有的 traceId 传着传着就丢了。有的错误堆栈很长但没有业务参数。有的接口返回失败但日志只写一句 “process failed”。故障现场查日志经常是这样的先按时间范围查发现日志量太大再加服务名过滤发现还有很多再加关键词 error结果全是无关异常再去调用链里找 traceId发现链路断了再问研发有没有特殊日志字段研发说“这块当时没打”。这时候你就会发现日志不是越多越好。日志要能被机器理解能被人快速定位能和指标、链路、变更记录关联起来才有价值。AIOps 里的日志摘要、异常聚类、相似错误归并前提也是日志质量得过得去。垃圾日志进来AI 只能帮你更快地生成垃圾结论。3. 监控大屏好看但不能替你判断很多公司都有监控大屏机房里挂着领导参观时也挺有气势。但说实话很多大屏只适合展示不适合排障。一块屏上几十个指标CPU、内存、磁盘、QPS、RT、错误率、连接数、线程池、队列堆积、数据库性能全都在跳。平时看着很安心真出故障时人的注意力根本跟不上。大屏能告诉你“哪里变红了”但不能告诉你“为什么变红”。传统监控体系一般是指标中心化但判断还是人脑中心化。经验强的人能从曲线里看出门道经验弱的人只能一页页点。这就带来一个问题同样一套监控有人十分钟定位有人两个小时还在看图。能力差异无法复用。AIOps 要解决的一个核心问题就是把高手的判断逻辑沉淀下来让系统具备一部分初步判断能力。4. 变更越来越多靠人工记忆不现实现在很多故障都和变更有关。代码发布、配置调整、数据库变更、镜像升级、K8s 参数修改、网络策略调整、证书更新、定时任务变更、依赖服务升级都可能引入问题。但故障发生时我们经常要靠人问“刚才谁发布了” “有没有改配置” “数据库有没有执行脚本” “网关有没有变更路由” “昨天是不是扩过容” “最近有没有升级基础镜像”如果变更信息不统一定位会非常慢。AIOps 做根因分析时变更数据非常关键。很多异常不是凭空出现的它往往和某次变更在时间上高度相关。把变更数据接入诊断流程往往比单纯分析指标更有效。我个人经验是故障定位时先看变更命中率非常高。不是说所有故障都是变更导致的但变更一定是排障第一优先级之一。AIOps 到底能解决什么先别把它想得太玄AIOps 这个词听起来很大但落到一线其实可以拆成几类具体能力。1. 告警聚合先让人少被吵醒很多团队落地 AIOps第一件事应该不是根因定位而是告警治理。因为告警是运维最直接的痛点。告警聚合要解决几个问题同一故障引发的多个告警能不能合并同一个实例的连续告警能不能压缩上下游服务同时告警时能不能识别影响范围低优先级抖动告警能不能延迟通知恢复告警能不能和触发告警绑定值班人能不能只看到需要处理的核心告警举个例子。某个订单服务接口超时导致支付服务调用失败、网关 5xx 升高、业务探活异常。如果没有聚合可能会发出十几条告警。如果做了聚合值班人看到的应该是一条事件“订单服务在 01:23 开始出现接口 RT 升高影响支付服务和网关入口伴随最近一次发布建议优先检查订单服务变更和数据库访问。”这条信息比十几条告警有用得多。注意这里不一定需要很复杂的 AI 模型。很多时候基于时间窗口、拓扑关系、服务依赖、告警标签和规则就能先解决一大半问题。AIOps 不是上来就大模型。先把告警收干净比什么都重要。2. 异常识别不要只靠固定阈值传统告警喜欢设固定阈值。CPU 超过 80% 报警接口 RT 超过 500ms 报警错误率超过 1% 报警。但固定阈值有个问题业务是有周期性的。凌晨 CPU 30% 可能就异常了因为正常只有 5%而大促时 CPU 85% 未必异常因为流量本来就在峰值。接口 RT 也是一样有些接口天生慢有些接口平时很快不能一刀切。异常检测要做的是基线判断。比如和过去 7 天同一时间比QPS 是否异常 和昨天同一小时比错误率是否升高 发布后十分钟核心接口 RT 是否偏离历史波动范围 某个实例的 CPU 是否明显高于同组其他实例 同一个服务的不同 Pod 是否出现流量倾斜这些判断比固定阈值更贴近实际。当然异常检测也不能神化。模型判断“异常”不代表一定有故障。它只是提醒你“这个点和平时不一样”。最终还要结合业务影响、调用链、日志和变更来判断。3. 日志摘要不是替你看日志而是先帮你缩小范围很多人第一次听“AI 看日志”会觉得不靠谱。我也不建议一开始就让 AI 直接给根因结论。更现实的做法是让 AI 做三件事第一把相似错误聚类。比如一万行错误日志里真正不同类型的错误可能只有五类。先聚合出来比人肉翻日志强很多。第二提取关键字段。比如错误码、接口名、traceId、上游服务、SQL 模板、异常堆栈、请求参数范围。第三生成摘要。比如 “01:20 到 01:40 之间订单服务主要错误集中在库存扣减接口异常类型为数据库连接超时影响实例为 pod-xxx 和 pod-yyy”。这类摘要非常有价值。它不一定直接告诉你根因但可以把排查范围从“几十 GB 日志”缩小到“3 类异常、5 个接口、2 个实例”。这就是效率提升。4. 指标分析让系统先给出候选方向指标分析不是简单画图。真正有用的是关联分析。比如接口 RT 升高时系统自动同时拉取同时间段 QPS 有没有升高错误率有没有升高CPU、内存、GC 有没有异常 线程池队列是否堆积 数据库连接池是否打满 慢 SQL 数量是否增加 缓存命中率是否下降 下游依赖 RT 是否升高 是否有发布或配置变更。然后给出一个候选排序第一嫌疑缓存命中率下降数据库慢查询增加第二嫌疑下游库存服务 RT 升高第三嫌疑订单服务发布后错误率上升。这个候选排序不一定百分百准确但对值班同学很有帮助。尤其是半夜脑子不清醒时系统能帮你把排查路径列出来就已经很有用。5. 调用链关联别只看单个服务微服务场景下故障经常沿调用链传播。A 服务慢B 服务超时C 服务重试D 服务线程池打满最后网关 5xx。如果只看单服务监控很容易误判。调用链的价值是把请求路径串起来。AIOps 可以基于调用链做几类分析哪个节点开始变慢慢请求集中在哪条链路错误是否从某个下游服务开始传播某个版本实例是否比其他版本实例更慢某个机房或可用区是否更容易失败重试是否放大了故障影响。我见过不少故障根因不是“服务挂了”而是“某个下游慢了上游重试策略不合理把整个链路拖垮”。这种问题不用调用链很难快速看清楚。6. 运维 Agent辅助判断不要一开始就替你操作现在很多团队开始尝试运维 Agent。简单说就是让 AI 结合监控、日志、知识库、变更记录和自动化工具辅助值班同学分析问题。这个方向有价值但一定要控制边界。我建议初期只做“建议模式”不要直接做“执行模式”。比如 Agent 可以回答这个告警可能和哪些变更有关最近十分钟有哪些异常日志这个服务过去类似故障怎么处理当前是否满足扩容条件是否存在数据库连接池打满迹象建议下一步排查哪些指标但不要一开始就让它自动重启服务、自动回滚、自动删数据、自动改配置。生产环境里自动化越接近写操作风险越大。正确路径应该是先只读诊断 再半自动执行 再有限场景自愈 最后才考虑闭环自动化。而且每一步都要有审计、回滚和人工确认机制。35 岁运维的焦虑很多不是年龄焦虑而是能力结构焦虑很多同行跟我聊过这个问题。“我现在 35 岁了还在值班还在写脚本还在处理发布故障。年轻同事会 K8s会 Go会大模型我是不是没机会了”我觉得这个焦虑要拆开看。1. 怕被工具替代这是最常见的焦虑。以前很多工作需要运维手工做。比如巡检、查日志、写日报、处理磁盘满、重启服务、发布上线、配置变更。现在自动化平台、云厂商控制台、K8s Operator、CI / CD 流水线、AIOps 平台都在做这些事。看起来运维能干的活越来越少。但我一直觉得被替代的不是运维这个角色而是低价值重复动作。如果一个人最大的价值是“每天登录服务器执行固定命令”那确实危险。但如果你能设计巡检规则、治理告警体系、优化发布流程、沉淀故障知识、建设容量模型、推动稳定性改进那 AIOps 反而会放大你的价值。工具会替代动作但很难替代稳定性判断。2. 怕学不动 AI很多运维看到 AIOps 里的算法、模型、向量库、大模型、RAG、Agent就觉得这东西离自己很远。说实话如果你目标是转成算法研究员那确实需要很深的数学和模型能力。但大部分运维转 AIOps不需要先去啃一堆论文。你更应该先掌握这些工程能力知道数据从哪里来知道指标、日志、调用链怎么统一知道告警怎么分类知道故障模式怎么沉淀知道知识库怎么治理知道自动化脚本怎么标准化知道 AI 输出怎么校验知道哪些动作可以自动化哪些必须人工确认。AIOps 是一个交叉领域。算法只是其中一部分。懂生产环境的人在这个领域非常重要。3. 怕没有项目机会有些人说公司没有 AIOps 平台我怎么转我的建议是不要等公司立项。你可以从一个很小的场景开始做。比如把最近三个月的告警导出来做一次告警分类和降噪分析把故障复盘文档整理成结构化知识库写一个脚本自动拉取服务核心指标生成巡检报告把常见日志错误做聚类和摘要用大模型辅助生成故障复盘初稿把发布记录和告警时间线关联起来做一个“接口超时排查助手”的内部小工具。这些都不需要一开始就有大平台。真正的转型往往是从把自己手里的重复工作做成工具开始的。4. 怕从头开始过去经验不值钱这是最不该有的焦虑。AIOps最需要的恰恰是经验。但问题是经验不能只停留在脑子里。你要把经验转成结构化资产。比如你以前知道“发布后 10 分钟内 RT 升高要先看变更和下游依赖”这只是个人经验。把它转成体系能力可以变成一条诊断规则一个排查流程一个知识库条目一个自动化检查脚本一个 Agent 工具调用链一个告警关联策略一个复盘模板。经验只有结构化才能复用。这就是中年运维转 AIOps 的关键。经验如何转化为体系能力这部分很重要。很多运维做了十年经验很丰富但面试或者转型时说不出来。别人问你做过什么你说“负责线上系统稳定性处理故障保障发布”。这听起来太泛了。你要把经验表达成体系能力。1. 从“我知道”变成“规则知道”举个例子。你知道某个服务经常因为线程池打满导致接口超时。以前你可能是故障时手动看线程池指标、队列长度、拒绝次数、接口 RT。转成体系能力可以这样做定义线程池关键指标activeCount、queueSize、rejectCount、taskCompleted、poolSize设置异常判断queueSize 持续超过阈值rejectCount 增长RT 同步上升关联上下游查看调用该服务的入口接口和下游依赖生成诊断建议优先检查是否流量突增、下游变慢、线程池参数不合理输出处理动作临时扩容、限流、降级、调整线程池参数、回滚发布。这就从个人经验变成了诊断规则。AIOps 平台可以调用这个规则年轻同学也可以按这个流程排查。2. 从“我会查日志”变成“日志可理解”很多老运维查日志很厉害但诀窍说不清。比如你知道要搜某些关键词知道哪个异常可以忽略知道哪个错误码代表下游问题知道哪个字段能定位租户或用户。这些经验要沉淀成日志规范和解析规则。具体可以做统一日志字段traceId、spanId、service、instance、env、version、interface、errorCode、cost、status统一错误码含义业务错误、系统错误、依赖错误、限流错误、超时错误统一日志级别哪些打 ERROR哪些打 WARN哪些只能打 INFO建立异常模板把相似堆栈归为一类建立日志摘要规则故障期间按服务、接口、错误码、实例聚合。有了这些AI 做日志摘要才有基础。否则你给它一堆格式混乱的日志它只能根据字面猜。3. 从“我会救火”变成“处置流程可编排”故障处理不是只靠技术还靠流程。一次线上故障通常包括发现问题确认影响拉群协同定位根因执行止血验证恢复通知业务复盘改进。很多老运维对这些流程很熟但没有产品化。AIOps 可以把部分流程编排起来。比如出现 P1 故障时自动做这些事创建故障事件聚合相关告警拉取最近变更生成影响范围推荐相关负责人拉取核心指标生成时间线记录人工操作故障恢复后生成复盘初稿。这不是替代人而是减少人手忙脚乱。半夜故障时最怕流程乱。有人查日志有人回滚有人扩容有人通知业务但没人记录时间线没人确认操作影响没人统一判断是否恢复。AIOps 可以把流程托住让人专注在关键判断上。4. 从“我懂业务”变成“稳定性指标体系”运维做久了会发现技术指标不等于业务稳定。CPU 正常业务可能已经不可用。数据库没挂核心交易可能已经失败。接口成功率 99%但失败的可能都是付费用户。告警没响客户已经在投诉。所以 AIOps 不能只看基础设施指标一定要接业务指标。比如电商系统要看下单成功率支付成功率库存扣减成功率订单创建耗时购物车接口错误率核心链路转化率消息堆积量退款处理延迟。金融系统要看交易成功率核心账务延迟对账差异风控接口 RT渠道成功率批处理完成时间资金流水积压。你过去对业务的理解可以变成稳定性指标体系。这是很多纯算法团队不具备的能力。5. 从“复盘文档”变成“知识资产”不少团队故障复盘写得很认真但写完就存在文档库里很少再被用起来。下一次类似故障发生值班同学未必能搜到。搜到了也未必知道哪段有用。AIOps 要用好知识库复盘文档必须结构化。建议每次复盘至少保留这些字段故障标题发生时间影响范围核心现象触发告警关联变更根因类型排查过程止血动作最终修复关键指标变化相关日志特征类似故障关键词后续改进项责任人和截止时间。这样后续做知识问答、相似故障推荐、故障报告生成效果才会明显。知识库不是把 Word 文档扔进去就完事。知识治理本身就是 AIOps 落地的一部分。最后说几句实在话AIOps 这件事不要神化也不要排斥。它不是一个新瓶装旧酒的概念也不是一个装上大模型就能解决所有故障的神器。它真正的价值是把运维工作里大量重复、分散、依赖个人经验的部分逐步变成可复用的系统能力。告警太多它帮你聚合和降噪。日志太乱它帮你摘要和聚类。指标太多它帮你做关联分析。故障复盘难写它帮你生成时间线和初稿。新人不会排障它给出标准排查路径。重复故障老是发生它帮你把知识沉淀下来。自动化脚本分散它帮你编排成 Runbook。但它不能替你理解业务不能替你设计稳定架构不能替你承担生产责任也不能替你做最终判断。尤其在关键故障现场AI 给的是线索和建议拍板的人还是运维 / SRE。所以35 岁运维还能不能转 AIOps能。而且很多时候真正适合做 AIOps 的恰恰是经历过凌晨告警、发布翻车、数据库打满、缓存雪崩、群里被催进度、复盘被追问根因的一线运维。因为你知道痛点在哪里。接下来要做的不是焦虑年龄而是调整能力结构把经验结构化把脚本平台化把监控体系化把知识资产化把 AI 工具工程化把故障处理流程化。当你能做到这些你就不是“会处理故障的老运维”而是“能建设稳定性体系的 AIOps / SRE 工程师”。这条路不轻松但比继续靠人肉救火更有前途。最后送给还在值班、还在被告警吵醒的同行一句话别急着否定自己。你以前踩过的坑、救过的火、背过的锅都是 AIOps 最需要的原材料。关键是从今天开始把它们沉淀下来让系统也学会你的判断。