运维是每个人的职责

运维

将运维人员培养成开发人员的呼声越来越高，这样下去运维岗位将会消失吗？

“运维岗位就要完了。”
“系统管理员？这是多少年前的事了。”
“好的工程团队都已经在使用自动化运维了。”

关于运维经常会出现类似的言论，许多人都在说运维将会消失。的确，从DevOps概念的提出到运维自动化的大规模实施，许多传统运维工程师在向开发工程师转型。但是，虽然如此，传统运维工作依然存在。

过去

20年前，运维工程师的头衔还是“系统管理员”，主要工作是维护那些“珍贵”的服务器。

10-15年前，分布式系统开始引入，运维自动化逐步开始应用。此时运维工程师和开发工程师的职责边界在于应用发布。运维工程师负责应用线上所有变更和维护。随着DevOps概念的兴起，它对于各个岗位都提出了更高的要求，工作职责和工作范围都在不断扩大。对于运维工程师来说只关注服务器和操作系统已经远远不够了，这意味着意味着：“运维工程师，该去学写代码啦”。

当下

到了最近基础设施开始变得复杂：“容器”、“调度器”、“服务编排器”、“微服务”等都成了热门话题。同时，运行在这些基础设施之上的组件也在不断的进行着扩缩容等变化。从这个角度看，我们都是“分布式系统工程师”。

相比于传统单块应用（monoliths），分布式系统有许多区别：

• 分布式系统随时可能存在节点故障，但是需要通过恰当的设计，确保能够容错并具有弹性扩缩容能力。
• 系统复杂度高，系统间的关联和依赖需要通过自动化工具进行探测和展示。
• 除了业务逻辑，分布式系统还依赖服务发现、负载均衡等组件，将系统各个部件组合起来。
• 系统需要有灰度能力。由于依赖过于复杂，测试环境可能无法完整模拟测试环境，因此部分功能需要在生产环境进行验证。

此时运维工程师和开发工程师的职责边界变得模糊起来，开发工程师也需要具备这些运维技能。换句话说：“开发工程师，该去学习运维了”。

运维是每个人的职责

DevOps所带来的第一次运维转型，是运维团队开始编写代码。第二波则反过来了。作为开发工程师，除了实现业务逻辑之外，还需要考虑系统的稳定性、可维护性、可调试性等运维相关特性。也正是这样的转型，让开发工程师更加关注自己开发的应用在生产环境的部署、运行情况，甚至开始进行轮班咨询。

事实上，运维工作本身并没有消失。这些变化的目的，是为了适应当前快速变化的需求、快速迭代上线，最终提供给用户一个更好的软件系统。