1. 风向变了从“代码产量”转向“风险兜底”1.1 增量红利退潮存量系统开始主导用人需求前几年大家聊得最多的就是某某算法岗、某某业务开发岗好像不会写模型、不做推荐系统就不好意思说自己是搞技术的。但最近一两年的招聘风向真实地变了我身边不少猎头和HR朋友反馈单纯的业务开发岗位供应量极大候选人多到简历看不过来反而是那些以前被认为“不够性感”的方向比如网络安全、系统稳定性、数据库和遗留系统治理岗位需求明显起来而且薪资给得不低。为什么会出现这种变化我的判断是互联网和传统行业的信息化建设已经过了“先把功能堆出来”的阶段。过去拼的是谁上线快、谁功能多现在拼的是谁的系统跑得久、不出事、出事能快速恢复、数据不出错、安全不出漏洞。这是典型的“存量系统主导”阶段公司不再缺能写业务逻辑的人缺的是能对复杂系统负责、能处理极端情况、能扛住风险的人。这个逻辑一旦扭过来用人标准就完全不一样了。开发岗位可以每两年换一批人因为业务代码有相对明确的边界新人上手就是写接口、调参数。但安全事件、故障、数据不一致这类问题往往半年都不发生一次一旦发生就是大事处理不好就是资损、业务中断、口碑崩塌。这类岗位需要的不是快速编码能力而是经验、判断力、冷静程度和对系统全貌的理解这些东西没办法靠突击三个月学会。1.2 经验型岗位的共同特征责任边界大容错成本高我认真梳理过标题里提到的这类“越老越吃香”的岗位它们有几个共同特征。第一责任边界特别大。一个安全负责人要对整个公司的系统暴露面负责一个数据库负责人要对所有核心数据的一致性和可用性负责一个SRE要对自己负责的链路的所有故障负责。这种“负责”不是写个单元测试就能交差的它意味着要考虑极端场景、要预判未来的变化、要协调多个团队。第二容错成本非常高。开发功能写错了测试能发现改一版就行。但安全策略配错了可能数据已经泄露了数据库参数调错了可能线上已经开始慢查询变更操作没评估好可能整个集群都起不来。这些错误一旦发生损失不是按工时算而是按最高影响金额、按用户信任度来算的。所以公司愿意为“有经验的人”付更高的溢价因为他们本身就是风险对冲。第三经验是可以复利的。开发框架三五年换一轮五年前的经验可能今天就过时了。但安全事件的处置思路、故障排查的路径、数据迁移的节奏感这些方法论层面的东西时间越长越值钱。我见过做了十几年的老工程师可能写代码速度不如年轻人但他看一眼日志就能判断问题方向这种能力恰恰是市场最稀缺的。所以我一直觉得年轻人选方向不能只看当下什么最热要看这个方向的经验是不是可积累、可复用、可形成壁垒。下面的内容我想把这几年需求明显上涨的五个方向逐一拆开聊聊重点说清楚每个方向到底在做什么、经验沉淀在哪里、以及什么样的人适合切入。2. 网络安全这波需求上涨里最典型的方向2.1 网安需求为什么突然变猛网络安全是标题里单独点名的一个方向也是我这两年感受最明显的一个领域。过去很多公司对安全的认知是“装个防火墙、买个杀毒软件就够了”安全岗位在很多研发团队眼里是附属角色甚至大量公司根本没有专职的安全人员。但这几年的情况完全不同了。一方面业务和系统都在线化企业的攻击面比过去大得多。以前一套系统可能只在内网跑现在大量业务要暴露在公网上要跟第三方系统对接要开放API给合作伙伴。系统越开放被攻击的可能性就越大这不是态度问题是现实问题。另一方面攻击的门槛也在降低各种自动化的攻击工具和脚本让一个完全不懂技术的人也能发起批量扫描企业收到的安全告警数量指数级上升。再加上整个行业的合规要求越来越严格甲方公司必须证明自己做了足够的安全投入否则连业务资质、合作门槛都过不去。这种背景下企业突然发现自己需要两类人一类是能看懂全局的安全负责人另一类是能实际干活的运营、分析、评估人员。而这两类人在市场上的供给一直很少因为安全不是写代码写得好就能自动会的它需要懂网络、懂系统、懂业务、懂攻击者的思维方式还需要见过真实的对抗过程。2.2 值得深耕的几个分支与经验积累点网络安全内部的分支其实很多我在和一些做安全的同行聊完后觉得下面几个方向尤其适合作为长期深耕路线。分支方向日常工作大致内容核心经验积累点越老越吃香的原因安全运营与分析监控告警、日志排查、事件确认、响应处置威胁判断能力、攻击链路还原能力见过的攻击类型越多判断越准安全评估与测试对应用、系统做安全评估输出加固建议代码审计能力、业务逻辑理解能力评估经验丰富后能快速定位高价值风险安全架构与治理制定安全规范、推动安全改造、评审架构方案体系化设计能力、跨团队协调能力体系搭建经验很难速成需要踩过大量坑安全合规与审计对接监管要求、梳理资产台账、准备审计材料合规理解、证据链整理能力靠的是对规则和业务结合的长期理解这几个分支里我最推荐有一定开发经验的人关注“安全评估与测试”和“安全运营与分析”这两个方向。前者需要代码功底会写代码的人在理解漏洞成因时有天然优势后者需要系统思维适合那些喜欢抽丝剥茧、看日志能看进去的人。经验在这几个方向上的积累方式也很明确一个是“案例量”你处理过多少安全事件、复盘过多少攻击链路这些都会被转化为直觉另一个是“场景宽度”你是在单一业务系统里做安全还是在复杂的多系统、多数据流环境里做安全接触到的真实问题完全不是一个量级。2.3 转网安前的三点提醒第一不要被影视作品里的“黑客”形象带偏。真实的安全工作有大量枯燥的部分看日志、筛告警、写报告、推动别人修漏洞。能忍受这种枯燥才能积累出真正的敏感度。第二不要变成一个只会用现成工具的“工具人”。工具能帮助你发现已知问题但真正的价值在于你如何判断一个告警是误报还是真实攻击、如何设计一条最合理的验证路径、如何在信息不全的情况下做决策。这些能力工具给不了。第三入门阶段不要急于追求“搞个大事件”。我认识的一些转岗安全的朋友前期花了很多时间研究各种攻击手法但真正让他们拿到高薪offer的反而是他们在实际业务系统里做的那些不起眼的加固建议、告警规则优化和应急响应记录。安全领域特别认实战经验而实战经验就是从一件件小事里攒出来的。从需求趋势看网络安全在未来很长一段时间都会是“卖方市场”尤其是那些既懂业务、又懂系统、还能把安全方案讲清楚的人年龄不仅不是劣势反而是很大的加分项。3. 稳定性与可靠性方向开发之外的第二条技术主线3.1 从“我功能上线了”到“系统一直能跑”我见过太多技术团队是这样的状态新功能上线很快但系统整体稳定性很差。今天内存告警明天数据库连接池满了后天某个接口超时拖垮了整条链路。每次故障发生一群人围在会议室里翻日志最后谁也没有完整答案只能先重启、再扩容、再观察。开发工作的评价标准通常是我做了多少功能、我解决了什么业务需求但稳定性方向的评价标准完全不同系统是不是一直在稳定运行有没有发生未预期的故障故障发生时能不能在最短时间内恢复。它没有那么多“看得见的产出”但它的价值恰恰在于让很多问题“不发生”。过去很多公司把这类工作扔给资深开发兼职觉得没必要养专职的人。但系统规模上来以后兼职根本顾不过来。我接触过不少公司业务量翻倍后第一件事就是成立专职的稳定性小组职责覆盖监控告警体系、容量规划、变更评审、故障应急、性能优化这些方面。3.2 可观测性、容量规划与故障处理的日常这个方向具体做什么我拆成几块来说。第一块是可观测性建设。很多公司的现状是日志散落、监控不全、告警靠人工盯群。可观测性的工作就是把这些打通统一日志采集、梳理指标、建立链路追踪、制定告警规则。听起来不复杂但真正做起来非常琐碎需要处理各种格式不统一的数据、各种采集端的问题、各种告警风暴下的噪音。第二块是容量规划与性能优化。接一个大活动或者新业务之前要评估系统能不能扛住预期流量哪些模块需要扩容哪些瓶颈需要提前处理。流量预测不准、容量评估偏差都会直接导致线上事故。这个很依赖经验因为性能瓶颈往往不是单个环节慢而是多个因素叠加老手能快速判断问题可能出现在哪里。第三块是故障应急与复盘。系统一旦出现故障第一件事是恢复第二件事是定位第三件事是复盘。这里面的经验壁垒最厚。新人面对高并发故障往往会慌不知道先看什么指标老手则会按部就班地确认是不是变更引起的最近有没有发布依赖的下游有没有超时机器负载有没有异常这种处理路径的背后是大量故障案例的积累。3.3 为什么这个方向吃经验稳定性问题有一个特点大部分时间无事发生但一旦发生就是大事件。这意味着年轻工程师很难在短时间内获得足够的实战场景。那些能独自处理过几十次线上故障的人基本都是在行业里摸爬滚打了很多年的。而且稳定性方向对“全局理解”的要求很高。你需要知道业务请求经过哪些链路、依赖哪些组件、每个组件的瓶颈在哪里。这种理解不是看代码就能得到的而是要长期和系统待在一起观察它在各种场景下的表现。时间久了你可能会形成一种直觉看到某个指标的组合就能猜到问题大致出在哪一层。这种直觉就是最值钱的“老”。所以如果你已经在开发岗位对业务代码已经很熟不妨主动承担一些稳定性相关的工作看看监控、接一些告警、参与故障复盘。这是一个不需要完全转岗也能切入的方向而且积累的经验会在任何时候都有效。4. 数据库与数据治理离钱近、离核心资产近4.1 系统越拆越细数据问题越来越难现在很多公司的后端架构都是微服务化的一个业务被拆成十几个服务每个服务都有自己的数据库。这样的拆分带来一个很典型的问题数据的一致性、完整性和关联性变得非常难维护。用户下单时订单库和支付库是分开的库存库又是另一个如果中间某一步失败了账怎么对数据怎么补齐以前大家觉得数据库工作就是写SQL、调索引但实际上面临的问题要复杂得多主从同步延迟、分布式事务、分库分表后的全局查询、数据迁移过程中的校验、线上误操作后的恢复。任何一个问题处理不好造成的后果都是直接的资金损失或者业务数据错乱。这种岗位的压力很大但也正因为压力大经验的价值被体现得很充分。4.2 数据库方向的工作面一个成熟的数据库岗位日常工作远不只是执行SQL它至少包括下面这些内容。核心库表的设计评审表结构合不合理索引能不能支撑业务查询字段类型有没有坑。慢查询治理与性能优化分析执行计划调整索引和SQL写法定位锁等待与连接池问题。高可用建设与备份恢复主从拓扑怎么搭备份策略怎么定恢复流程是否验证过这些都需要长期维护。数据迁移与同步系统重构、机房迁移、表结构变更要做到数据不丢、顺序不乱、结果可校验。故障处理复制中断、数据不一致、误删数据每一类故障的处理方式都不同。这其中的经验沉淀最大的一块是“恢复”和“校验”。一个老手做数据迁移会提前设计好校验方案迁移完先做数据对账再开放流量新人可能只关注迁移脚本本身的正确性忽略了对账、灰度、回滚这些环节。真正决定一个数据库工程师级别的不是SQL写得有多花哨而是你在极端情况下能不能保证数据安全。4.3 数据治理是另一个高墙数据库方向再往上一层就是数据治理。中大型公司建数据仓库、做数据分析很快会发现最痛的其实不是算力不够而是数据质量太差不同部门对同一个指标的定义不一样明细数据和汇总数据对不上上游表结构变了但下游任务不知道导致报表数据时对时错。数据治理要做的事情包括梳理数据字典、统一指标口径、建立数据血缘关系、制定数据质量规则、处理脏数据和重复数据。听起来很管理但实践中非常依赖技术功底因为你要能看懂复杂的数据加工链路定位数据不一致的根因。这个方向还有一个好处它跟业务离得很近。做数据分析、做经营决策的人都依赖可信的数据而你就是那个保证数据可信的人。一个懂业务、懂数据、又懂系统实现的人在这个岗位上积累十年以上几乎就是企业的数据资产“活字典”。这种角色的价值很难用一句“会写代码吗”来衡量。5. 遗留系统与架构治理老系统的钱年轻人赚不了5.1 每家成熟公司都有一堆不敢动的老代码很多年轻工程师向往的是新项目、新框架、从零搭建的绿地系统。但现实是中大型公司里大量业务跑在多年以前的系统上这些系统用的框架可能已经过时代码结构混乱文档严重缺失甚至最初的作者早就离职了。每次业务方提需求开发都要在迷宫一样的代码里反复摸索。这些系统有一个共同特点大家都想重构但没人敢动。因为重构出错就是线上事故而不重构最多是开发效率低一点、出问题慢一点。所以公司需要的不是天天吵着“这代码太烂了重写吧”的人而是能看懂老系统、敢碰老系统、能安全地改造它的人。这类工作往往被统称为遗留系统治理或者架构演进市面上真实的需求非常大。凡是经历过业务快速发展的公司几乎都有一笔这样的“技术债”要还。而能还这笔债的人恰恰不是刚入行的新人而是有多年经验、见过不同系统形态、知道怎么控制风险的老手。5.2 重构、迁移、改造真正值钱的是“风险控制”我参与过几次系统迁移和重构类项目最大的体会是这类项目的技术难点通常不难真正的难点在于“怎么保证切换过程不出事”。要做一次成功的重构迁移至少得想清楚这些环节对现有系统做完整的资产盘点搞清楚有哪些接口、哪些数据表、哪些潜在的隐藏依赖。设计兼容策略新老系统并行灰度放量而不是一次性切换。准备好回滚方案切换前就要知道如果出问题最快怎么回到老系统。数据迁移要有校验机制保证新老系统数据一致。上线前要有一套业务验证方案请业务方参与确认关键路径没有跑偏。这些步骤里每一个背后都可能藏着一堆意想不到的坑某个老系统里硬编码了IP、某个定时任务依赖了旧表、某个下游系统同步的是老接口。没有足够经验的人根本不可能预判到这些问题。5.3 什么样的人在这类岗位里吃香在遗留系统治理方向上吃香的人通常具备三个特质。第一是能静下心啃老代码不抱怨技术旧而是愿意理解当时的技术背景和业务约束。第二是很有耐心愿意做渐进式改造把大重构拆成小步骤每一步都保证可回滚。第三是有很强的沟通意识因为重构往往涉及多个业务方和协作团队不能自己闷头干。年龄在这个方向上基本是绝对优势。做过的系统越多、见过的迁移案例越丰富越能给出靠谱的改造节奏。我见过一些十年以上经验的工程师可能简历上写的都是很老的技术栈但他们在人才市场上非常受青睐因为成熟企业最缺的就是这种能“托底”的人。6. 想转方向怎么把已有的经验平移过去6.1 不同技术背景的推荐平移路径如果你看完上面这些方向觉得自己现在的工作确实太单一了想往经验型方向靠一靠我的建议是不要推倒重来而是把已有的经验平移过去。以常见的几种背景为例。如果你是业务开发出身最顺的是往稳定性方向平移。你本来就懂业务代码、懂调用链只要补上监控、日志、容量相关的能力就能接手稳定性工作。如果你对底层原理感兴趣喜欢研究操作系统、网络、存储可以往数据库内核、存储系统方向走这个方向非常看重深度。如果你有安全方面的兴趣开发背景做安全评估和代码审计是比较自然的入口写代码的经验能帮你更容易理解漏洞是如何产生的。如果你在传统行业做过多年系统对接、数据转换往数据治理和遗留系统治理方向平移会非常顺畅你已有的业务理解就是优势。6.2 我现在会建议新人怎么做我见过太多工作了三五年的人焦虑地问我“现在转XX方向还来得及吗”我一般会反问一句你自己当前负责的系统你真的搞透了吗很多人其实连自己系统的日志怎么查、告警怎么配、数据是怎么流转的都没完全搞清楚。所以我的第一条建议非常朴素先把当前系统的监控、日志、告警、线上问题处理这些基础能力补上不管转不转方向这都是经验型岗位的入场券。第二条建议是多参与那些“没人愿意干”的事。比如处理线上告警、参加故障复盘、写变更方案、接手一个老模块。利益上这些事又苦又累但它们是积累真经验最直接的路径。安全事件、故障、数据问题不是靠看书学会的是需要真实介入的。第三条建议是养成写复盘笔记的习惯。我自己的经验是一个技术人工作十年后能拿得出手的不是项目列表而是你处理过哪些别人处理不了的问题、踩过哪些别人没踩过的坑。把这些案例沉淀下来你的简历和面试都会非常有底气。6.3 最后一个个人体会我自己在职业选择上走过不少弯路早年也喜欢追热点看哪个方向工资高就往哪里凑。后来发现真正让我在市场上越来越从容的反而是那些慢慢沉淀下来的“风险类经验”我处理过哪些疑难问题、我对某个系统的理解有多深、我在关键时刻能不能稳住局面。所以说选方向的时候别只看短期薪资重点问问自己这个职业五年后、十年后我的经验是会贬值还是会增值网络安全、稳定性、数据库、数据治理、遗留系统治理这几个方向都属于经验会持续增值的赛道。它们未必像算法岗那样有过那么高的热度但它们的职业曲线是往上走的而且越往后越稳定。如果你现在正在犹豫不妨试着往这些方向靠一靠从一件小事开始积累属于你自己的“老本钱”。