稳住不慌：运维职业成长路线规划

文章目录

零、引子
阶段一、业务运维工程师：提供托管式服务
阶段二、业务运维SRE：提供引导式服务
阶段三、平台运维SRE：提供管理式服务
阶段四、技术运营架构师：提供咨询式服务
阶段五、技术运营PM：提供产品式服务

零、引子

最近有运维小伙伴问我：
一得，运维行业风云变幻，各种上云/容器化趋势，要把运维干掉的样子；
而自己对运维的前程也越来越迷茫，不知何去何从，能否指点迷津呢？

这是个好问题；

毕竟我也曾经遇到过类似的职业迷茫，并为此思考和挣扎过。

阶段一、业务运维工程师：提供托管式服务

这个阶段，业务是野蛮生长的，
为了求发展，快速迭代，
团队往往会奉行 “先上线后优化” 的敏捷原则，
效率有时候甚至比质量的优先级还更高些。
这也导致可能累积一大堆技术债务，遍地是坑，到处冒烟。

因此研发交付的业务应用，可以类比为小宝宝，
而运维作为保姆角色，提供托管服务，
专门照顾小宝宝（业务应用）。

所以业务运维工程师的几乎全部精力，
都会耗在支撑业务敏捷快速发展上，
能尽量做到不拖业务发展后腿就不容易了，
也就无法抽出精力做业务质量建设优化了；
这也就导致这个阶段的运维工程师非常被动，
常常被戏称为“消防员”，随时准备救火。

遥想当年，
自己去任何地方都是随身携带笔记本的，
随时准备开VPN连网救火：
团建的时候带笔记本，
旅游的时候带笔记本，
跟女友出去逛街谈恋爱的时候带笔记本，
甚至连结婚的时候婚车上都放着笔记本…

随着业务发展，
用户量增长到一个较大的数量，
业务质量一定会成为主要矛盾；

这也会推着业务运维进入下一个运维成长阶段。

阶段二、业务运维SRE：提供引导式服务

随着业务发展到质量无法被忽视的用户量级，
效率的优先级不再是最高的了，
质量的优先级得上来了。

这个阶段的运维和业务之间的关系，
不再是小宝宝和保姆那种托管式关系。
而更像是孩子和家庭教师那种培养引导关系。

运维需要输出各种自动化工具，提高业务支撑效率，
从而还能抽出时间来向业务强调质量意识；

通过建立或者优化问题反馈和问题发现的渠道，
以及将事件和故障的处理流程梳理得更加清晰，
从而让质量问题能及时暴露和介入解决。

阶段三、平台运维SRE：提供管理式服务

当业务高速拉升的阶段过去，整体趋于稳定时，
质量和效率，谁才是主要矛盾，这得看实际情况了，
甚至有可能这两个都不是主要矛盾，
而是成本和安全成为主要矛盾。

随着基础设施的逐步完善（自动化/上云等），
运维不再频繁承受业务 “先上线后优化” 之痛，也不用到处被动填坑救火；
被动运维的时代成为历史，
运维需要好好思考，
自己如何才能做好主动运维，从而输出自己的价值。

这个阶段的运维和业务之间的关系，
或者更贴切的说是运维和业务研发之间的关系，
变成了成年人和成年人之间的协同发展关系，
运维为业务研发提供的更像是管理服务，而不再是拖管，也不是引导。

所谓管理式服务，就必然存在交付管理的准入门槛，
运维开始有底气对一切可能存在风险的业务实现“say no”，
运维需要学会拒绝“先上线后优化”，
未经审视的服务，明显存在可用性风险的，
是不能直接上线交付运维管理的。

为了做好这个阶段业务服务的稳定性管理，
运维需要针对业务实际情况，
深挖业务主要矛盾（质量/效率/成本/安全），
然后建设好对应的运营平台；

比如针对 BCP 建设可用性平台，
通过混沌工程持续挖掘可用性风险，
并针对新发现的可用性风险不断补充对应的处理预案；
然后定期对这些沉淀下来的处理预案做保鲜，确保故障预案能按预期生效；
从而为业务可用性保驾护航。

阶段四、技术运营架构师：提供咨询式服务

运维作为技术广度和技术深度的集大成者，尤其在技术广度上会比研发有显著的优势，
对于业务各个阶段的发展情况了如指掌，
对于业务生产环境的各种技术方案烂熟于心，
也踩过和填过业务各种各样的坑，能做到“常在河边走，也能不湿鞋”，
因此这个阶段的运维，将有机会成长为 “技术运营架构师”；

这个阶段，
每个业务的真正的主要矛盾，
其实完全取决于业务团队对于自身发展的定位了；

那么运维作为 “技术运营架构师”，
怎样为业务继续发光发热产生价值呢？

也许不再是：
自己觉得业务的某些事情很重要就默默去做了，
而是：
在已经建设好的运营流程中，
业务团队结合自身团队的发展定位以及业务面临的实际问题
主动咨询技术运营架构师，从而获得最佳实践解决方案。

这个阶段的技术运营架构师团队和业务研发团队的关系，
更像是顾问和客户之间的关系。

阶段五、技术运营PM：提供产品式服务

这个阶段的运维，
我认为应该叫技术运营PM ，或者叫技术运营产品经理；
不过我更喜欢的一个英文代称是 TPM；

这个角色，将是技术、运营和产品经理的最强融合，
在产品生产链条的始端的产品经理和末端的技术运营，
将因为 TPM 这个角色而有望形成产品闭环。

TPM，将不再局限于业务去创造和输出价值，而是跳出业务，
融入产品思维，通过产品思维来做好技术运营。

比如将技术运营服务或者架构师咨询服务，包装为一个产品，
并输出到业务以外的更大的范围（比如业界）；
从而实现技术运营价值泛化和影响力拓宽。

这个阶段的运维和服务对象之间的关系，更像是 PM 和用户之间的关系。