运营和维护工程师的未来

在未来，运营和维护工程师的角色将更接近软件开发人员的作用，但他们的职责仍然存在一些差异。以前，作为开发人员，O＆M工程师不需要精通源代码控制系统，持续集成系统，调试和测试方法的处理和自动化。它们涉及的领域主要与操作系统，网络，数据层和系统架构有关。除了构建新的基础架构或Web应用程序环境之外，它们通常不需要与软件开发团队同步。然而，这一天永远消失了。可能有一些专家正在处理特定领域，如操作系统，网络，数据库或数据存储，但现在所有利益相关者都必须掌握这一部分

在未来，运营和维护工程师的角色将更接近软件开发人员的作用，但他们的职责仍然存在一些差异。以前，作为开发人员，O＆M工程师不需要精通源代码控制系统，持续集成系统，调试和测试方法的处理和自动化。它们涉及的领域主要与操作系统，网络，数据层和系统架构有关。除了构建新的基础架构或Web应用程序环境之外，它们通常不需要与软件开发团队同步。然而，这一天永远消失了。现在可能有一些专家处理特定领域，如操作系统，网络，数据库或数据存储，但现在所有利益相关者都必须拥有这部分专业知识。有了这部分知识，每个团队都可以在瞬息万变的环境中理解彼此的角色。未来开发运维的发展趋势是，在一定程度上，每个人都是软件开发，但运维工程师会更加关注操作系统，系统基础设施和网络。为了实现最佳的工作效率，相互理解和完善彼此角色的关键是更多地了解该领域以外的知识，如配置管理，源代码控制，发布管理和应用程序架构，等等。但是，模糊化的作用可能会增加运维工程师和软件开发人员的难度。系统自动化后，双方必须熟悉彼此的责任。例如，如果开发人员正在他的本地工作站上调试生产Web应用程序，他应该能够在测试环境中部署修复程序，然后请求O＆M工程师批准它以部署到生产环境。跟着去吧。这正是Facebook每天所做的。在从测试环境到生产环境的过渡中伴随源代码的不同级别的许可过程伴随着不同的许可策略。 在整个过程中，不同的组织可能采用不同的方法，但一般来说它们几乎是:操作和维护工程师应该知道代码的含义。 网站建设开发人员还应该能够将更改结果独立地推送到测试环境。操作和维护人员应该可以独立确定是否要批准此更改。开发人员不再需要向运营团队解释整个流程，这在以前非常耗时，并且对快速创新和开发产生了重大影响。现在，操作和维护工程师有责任掌握代码，应用程序架构和软件开发循环的知识，这样他就可以成为集成变更结果的桥梁，而不会成为绊脚石。但是，在今天的软件开发团队中，运营和维护团队经常扮演这样一个角色。