前几天和一位运维老同事聊天，他说：

非常能理解这种焦虑 ——

OpenStack 刚摸熟，K8S 来了； 虚拟机经验还没焐热，云原生又变天； 现在又到处都是AI要淘汰这个淘汰那个的各种言论甚嚣尘上……

运维这行，技术像“快消品”，辛苦多年积累的技术经验过几年可能就没用。 而且还特别容易形成技术路径依赖，拿着锤子，看啥都像钉子一样。

可为什么有人能从一线执行，3 年就做到技术骨干，5 年带团队？

接触过以及自己带过这类优秀的年轻人，发现一个特点：技术这块并不是那么特别拔尖，而是沉淀了一些优秀的能力。

这些优秀的能力，结合他们的技术能力，去形成了自己的综合竞争力，形成了复利的效果。

他们先让自己“升值”，“升职”和“加薪”只是随之而来的必然结果。

接下来我们就来探讨下这些能力的养成。

不拉扯那些神神道道的内容，我们直接用五张“能力卡片”，来看看这五项复利能力是如何进化的：

• 初入职场： 把事说清楚

• 职场进阶： 能成事

• 最终收获： 领导力

• 初入职场： 解决“单类问题”

• 职场进阶： 不让类似问题再发生

• 最终收获： 体系力

• 初入职场： 完成任务

• 职场进阶： 主动破局

• 最终收获： 破局力

• 初入职场： 自己不慌

• 职场进阶： 能控全局

• 最终收获： 控局力

• 初入职场： 学会“套路”

• 职场进阶： 帮团队成长

• 最终收获： 影响力

新手期别追求 “会说话”，先做到 “说明白，不添乱”。

错误示范：

• 汇报故障：“服务挂了！”

   

• 沟通变更：“在吗？我重启下服务哈？”

正确示范 (使用模型)：

1）汇报故障 (结论-原因-案例-重申模型): 

“结论： web 服务宕机 10 分钟，已恢复； 原因： 数据库连接池满了； 案例： 刚才查日志发现连接数超了 500； 重申： 已扩容连接池，后续会加监控。”

2）沟通变更 (讲清事实-影响-方案-确认): 

“Hi，XX测试服务内存快满了，需要重启释放下内存，预计中断3分钟。打扰你测试了，看看方便操作吗？请确认。”

进阶案例：如何推动CDN 2.0 升级？

等你到了进阶期，要学会“用沟通推动成事”。

最近正好在推CDN发布系统2.0的更新迭代，但是1.0当下运行还比较稳定，研发用得还不错。我们要迁移，研发担心投入过多配合时间，影响业务研发进度。

我们没去硬推，而是做了这几个沟通同步工作：

先展示痛点： 把“旧系统存在的痛点问题展示出来，比如应对并发吞吐的局限，项目一多就容易卡顿的问题”；

再介绍收益：“新系统不但解决了这些痛点，而且在使用体验上还进一步改进了以前UI体验”；

最后打消顾虑：“运维来主导，而且整体API和以前1.0完全兼容，不会占用大家太多时间，项目组只需要改下CI/CD的对应地址以及对应的账号和密码即可”。

这样就把事情顺利推动下去了，拿到了结果 ——这就是 “沟通的复利”。

新手别满足于 “解决了这个问题就拉倒了”，要学会下钻多问几个为什么。

案例：GitLab服务器Hang住故障

最近GITLAB服务器连续hang住了两次，别只重启释放资源就完了，用“5 个为什么”查：

1）为什么hang住了？CPU满了；

2）为什么CPU满？有某个用户全量操作多个项目行为导致的；

3）为什么用户这种操作就会搞挂服务？系统资源不够应对这种突发；

4）为什么资源会不够？没有注意最近项目组持续有新人进入，会全量操作项目库；

5）怎么解决？ 走变更流程，扩展资源临时缓解，后续对整体服务进行架构调整搞成分布式的模式，来应对这种突发的操作。

故障后写复盘报告，别只记“过程”，要写“下次怎么改”。

进阶案例：云NAS存储动态扩容

进阶后，你要想“怎么让这类问题再也不发生”。

比如我们碰到一个云NAS存储的容量限制问题，影响了项目CI/CD做热更新。

那我们也不清楚项目对这个容量实际使用的情况，我们是扩100G还是扩200G？ 扩100G怕还会满，扩200G可能也还会满，那怎么办？

我们找云厂商对齐，确认了可以做动态扩容。

那我们就设置一个动态的上限策略，这样来保证类似问题不要再重复出现。同时，我们再专门针对这个NAS的使用量找云提供一个接口，做好使用量监控，使用超过多少给出报警，避免最后占用太大容量，导致成本增加过多。

新手期的“担当”很简单：把分配的活儿干好，再多走一步。

比如领导让你“扩容服务”，别只改完配置就交差：

多做 1 步： 检查扩容后的监控数据，看是否有瓶颈；

再多做 1 步： 更新部署文档，标清 “扩容步骤 + 注意事项”；

最后多做 1 步： 同步给研发 “已扩容，后续有问题找我”。

进阶案例：主动破局，节省云资源

等你成了骨干，要学会 “眼里有活儿，要主动去寻找价值点破局”。

举个最简单的栗子，发现公司云资源每月浪费 20 万，没人管这事。 你主动拉了个小群：

先统计：“各业务线闲置实例占比”；

再出方案：“仿真服务用按量付费，夜间自动关机，早上大家来了再自动开机”；

最后推动落地：半年省了 100 多万。

类似这种 “没人安排但重要” 的事，才是拉开差距的关键。 越主动、就越幸运，越能获得成长机会。

新手遇到故障别慌，“按流程来”。

第一次独立处理告警，先深呼吸，打开 “故障处理 Checklist”：

先看监控，定位影响范围；

再查最近变更，有没有刚上线的代码；

15分钟无头绪或者搞不定，立刻 @上级 说 “现在情况是 XX，需要 XX 帮助”。

哪怕操作错了，别藏着 —— 越早说，损失越小。

进阶案例：故障控局

进阶后，你要成为团队的 “关键先生”。

还是举这个GITLAB服务hang住的故障。服务突然报503错误了，各个项目群都在喊503，访问不了，我们运维内部群大家都在忙着分析找问题原因。

我先在群里发：

“大家分头行事：

小A你先尝试直接重启下服务；

小B你把故障做下通报给各个项目群里面，让大家稍等，正在处理。”

其实大家都着急，但不能慌，越慌越容易错 ——自己保持冷静，团队就能冷静处理问题。

新手期不用贪多，先练习 “快速形成套路技能”。

案例：为新服配置监控SOP

比如你是游戏运维，领导让你为一个新开的游戏服大区（比如 ‘XX一服’）配置监控。 别只在监控系统里点几下，把CPU、内存加上就完事了。

你得多做一步，写个简单的 SOP（标准作业流程） 文档：

“新服开区监控SOP：

基础监控： CPU、内存、磁盘（重点是日志盘）、带宽。

业务监控： ‘XX一服’的同时在线、支付成功率、DAU这3个核心指标怎么配。

常见问题： 如果‘同时在线’指标取不到值，去查xxx配置。”

把这个SOP形成团队知识库文档，这样你就逐步形成了自己的套路打法了。

进阶案例：推动团队游戏云原生建设

进阶后，你的“精进”要帮团队成长。

比如推进游戏云原生的建设，不是乱打一气，要找准突破点：

先做透一个项目： 围绕具体项目，入组展开云原生架构改造，从测试环境先搞，然后逐步过渡到线上。

再提炼最佳实践： 针对做透的项目，提炼出来一个最佳实践的打法。

再组织分享布道： 把云原生游戏建设的内容通过分享传播出去。

然后共创： 继续去跟进有意向的项目团队，一块推动游戏云原生改造共创。

最后复制： 逐步把这套打法复制到团队内部去，让其他运维同学借鉴参考。

你的经验，就变成了团队的“能力资产”。

看到很多年轻同学，把精力全放在“学新技术”上，根本没意识到这些软技能的养成。 像学百科全书一样的学法，什么方向都去学，恨不得把自己搞成全才。

在他们身上，我看到了自己以前的影子—— 盲目追热点技术，花了大量精力和金钱，被无良培训机构割韭菜，却很少深入思考：追的热点技术是不是真正能形成自己的持续竞争力，能不能给自己升值加薪？

我时常会想，要是以前能早点意识到这些软技能的养成就太有意义了。 所以现在在带团队的时候，我总会不厌其烦地去引导大家，帮他们去内化这些软技能。

技术是“武器”，是工具，但能让你走得远的，是“用武器，用工具去解决问题的能力” —— 这5项能力，今天练 1 分，明天就多 1 分底气，持续坚持下去，做时间的朋友，形成复利效应。