运营维护岗位，运维这个岗位怎么样是不是很无聊

看一个岗位行不行好不好，需要从现在和长远规划来看运营维护岗位。

如果对于普通人来说，前景是指能赚个买房买车钱，那肯定没问题

如果想实现阶级跃升，进入富人阶级，也不是说不可能，但是概率比较小而已

一线、二线互联网公司的运维总监、架构师们，肯定都是富人阶级，有开保时捷911以上的实力

三、四、五线公司的运维总监、经理、技术专家们，解决一线城市房子车子问题，站稳在中产阶级，肯定是不在话下

论一个行业的好坏，是不能以个人视角来定义的，需要整体数据的视角

比如问做销售有前途吗?

做保险有前途吗?

写代码有前途吗?

在这些行业能做到年入百万以上的顶尖水平，或者年入50w以上的中上水平的从业者，肯定是说有前途的

然而行业水平靠后的，很大概率是说没前途的，这取决于说话人的立场在哪，屁股歪在那边，哈哈

我觉得你要问某个行业有没前途，需要问这个行业能做到中上水平以上的人，才有参考价值，这个道理你应该懂的~

再举个例子

你问一个到退休都是小科员水平的人，做公务员有没前途?

他和你说公务员没前途，你会信吗?

「运维是干什么的?」

这「运维」二字可能有几层意思，分别可以指代运维工程师、运维团队或者是整个运维服务体系。

我们可以看出这三层是从狭义到广义的递进，我相信绝大部分知乎的题主问的是运维工程师，只有极少数人能意识到有运维服务体系这一层含义。

我们经常会听到一些言论，比如：

云服务普及了，运维工程师就要失业了

等 DevOps 或者 SRE 落地了，运维工程师也要失业了

容器技术普及了，运维工程师也该失业了

我记不清运维工程师到底被失业了多少遍，然而我认为就算运维工程师被取代了，运维服务也不会消亡，Ta将伴随并支撑着业务发展的整个生命周期。

为何这样说，我们还是用业务的诞生过程来分析。

一个站点或者App，大致经历着这样的诞生过程：

PM 设计出产品原型，交给 Dev 开发实现，QA 测试，最后交付给 Ops 部署到线上运行，最后供用户使用。

在这几个简单步骤中涉及了众多的人、角色、交付过程等对象，这是一个完整、复杂的系统工程，而任意一个环节的失误都可能影响最终呈现给用户的体验以及效果。

我们重点考虑从 Dev 把业务产品完成后交付给 Ops 到线上运行的这个阶段，Dev 同事主要负责业务产品的功能完整、逻辑正确等业务指标，而 Ops 同事主要负责业务产品的运行质量、稳定性、可用性等系统指标。

无论后面的交付步骤是用 DevOps 还是 SRE 的实现方式，都离不开一个广义的运维服务的执行环节，所以说 Dev 还是 Dev，Ops 还是 Ops，没有谁被取代，只是运维服务的执行方式升级为更加软件工程化的手段，减少人肉操作，DevOps 强调自动化、拉动式来提高团队交付效率与质量。

而传统的运维需要谋求技术转型，从原来只关注操作系统层面的技术已经不够了，还要增加对程序代码的性能调优、持续交付、容器化等软件基础架构方面的技能提升，也需要持续关注整个业务、应用、服务的生命周期管理。

简单来说，就是把过去传统的黑盒运维的思维方式抛弃，进入白盒运维的时代，我们必须更加深入代码、深入业务运营，让整个线上服务运行于更优质高效的状态。

至于运维是否有前途，取决于你属于哪种运维。

运维服务体系 与 技能水平量化

先上一张图展示我心中的运维服务体系，其实还有很多可以展开的，但是细节就不方便透露了，这属于个人经验未必能适用其他运维团队。

每个运维工程师心中其实都有自己的想法，不妨用思维导图的形式将其列出来，找出自己感兴趣的点，持续深入，打造自己的核心竞争力。而思维导图也可以继续往横向纵向扩展，形成自己心中的完整的一套运维概念。

由于运维一般讲究广度而忽略了深度，所以容易导致自身的技术栈广而不精的情况，怎样量化自己的技能水平是否足够深入呢?

举一个大家都熟悉的MySQL技能，该怎么量化它呢?

如果把MySQL水平定义成1~10级，下面是我对各种级别水平的理解。

为何要量化技能呢?因为人的时间、专注力毕竟有限，如何把精力分配到不同的技能上，是需要一定的策略。

正常情况下，大家把精力平均分配到各种具体技能，希望可以做到面面俱到，但不会太深入某项技能，所以技能水平达到的级别落在1~3之间。

如路人A的技能水平表是这样的： (当然还有其他技能项，如网络、安全等等，这里只是简化了方便讨论)

运维是一种需要技能面比较广的工种，大家普遍都是处于技术面广但不深的状态，我把2级定义为科普级，意思是达到该级就可以满足各种日常工作要求。

总结

这个我个人对运维以及职业发展的一些浅薄理解，总体来说运维还是比较有意思的职业分支，要干一行爱一行，专一行。