it运维是干什么的？

it运维可能存在着好几层意思，比如it运维包括代运维工程师、it运维团队，还有整个运维服务体系等。我们可以看出这三层是从狭义到广义的递进，我相信绝大部分的人只了解运维工程师，只有极少数人能意识到有运维服务体系这一层含义。

我们经常会听到一些“云服务普及了，it运维工程师就要失业了！”、“等 DevOps 或者 SRE 落地了，it运维工程师也要失业了”等等的言论，不知道it运维工程师即将面临失业被说了多少遍，然而我认为就算it运维工程师被取代了，it运维服务也不会消亡，Ta将伴随并支撑着业务发展的整个生命周期！

为何这样说？

我们还是用业务的诞生过程来分析。一个站点或者App，大致经历着这样的诞生过程：

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

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

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

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

而传统的it运维需要谋求技术转型，从原来只关注操作系统层面的技术已经不够了，还要增加对程序代码的性能调优、持续交付、容器化等软件基础架构方面的技能提升，也需要持续关注整个业务、应用、服务的生命周期管理。简单来说，就是把过去传统的黑盒运维的思维方式抛弃，进入白盒运维的时代，我们必须更加深入代码、深入业务运营，让整个线上服务运行于更优质高效的状态。

至于it运维是否会被取代，取决于你属于哪种it运维。it运维开发是一个深度不算太深的职业分支，而现在之所以对it运维开发需求量热起来了，主要由于老一辈的资深it运维普遍研发能力有限（比如我 T_T），这是有历史原因的。所以it运维永远不会被取代。