传统运维体系并不会消失，只是在进行重组。

从传统意义上讲，由内部设施到云环境的迁移意味着运维工作在很大程度上被外包至云服务供应商手中。这也正好契合了“NoOps”这一曾经的流行语（如今已经很少被提及）——很多人甚至将其称为 DevOps 的继承者。通过这样的转型，Amazon 与负责构建产品的开发团队之间将只剩下少数但仍非常关键的运维任务，包括基础设施自动化、部署自动化、配置管理、日志管理以及监控与检测等等。

运维工作的前景实际上在很多方面与质量保证（即 QA）颇为相似。传统的质量保证人员正由以测试为重点转向以工具为重点。工程师们编写代码、执行单元测试并整合各类测试。这些测试运行在持续集成（简称 CI）管道当中，而代码则通过持续交付（简称 CD）管道传递并实现产出。质量保证团队的规模正日益缩小，但负责构建工具的团队——包括测试框架、CI 环境、CD 管道等——则不断拓展。事实上，如今质量保证职能已经被并入开发团队之内。在微软与 Amazon 等巨头级企业中已经普及的 SDET（即测试中软件开发工程师）模式正是朝着这个方向迈出的重要一步。2014 年，微软公司转向组合工程模式，将 SDET 与 SDE（即软件开发工程师）合并为同一职能角色，即软件工程师，并由其负责产品代码、测试代码与工具代码。

您是否注意到，质量保证类人员似乎正悄然消失？我所认识或者合作的很多开发团队似乎已经不再设置质量保证职位。

— Gwen (Chen) Shapira (@gwenshap) 2017 年 4 月 6 日

同样的变化也出现在了运维领域。在与 Workiva 基础设施与可靠性团队的合作过程中，我们将运维与基础设施工程团队合并成了一支由现场可靠性工程师们组成的新团队。该团队负责基础设施的构建与维护、配置管理、日志管理、容器管理以及监控等事务。

我个人推荐基于愿景的领导方式。令人信服的愿景能够让各位团队成员之间保持一致，最大程度减少职能与组织性孤岛的存在，从本质上动员和激发大家的积极性。这种方式适合使团队高度一致且松耦合，亦有利于决策制定。对于运维的未来发展前景，我认为其基本作用在于确保组合式工程（Combined Engineering）能够得出合乎逻辑的结果。正如质量保证一样，运维能力同样应被嵌入至开发团队当中。事实上，如果缺少技术运维能力，大家根本无法在现代企业当中成为一名称职的软件工程师。也正因为如此，运维团队现在应当重新定义自身的发展愿景。

运维的未来将保证开发人员能够充分运用工具、自动化与流程方案实现自助服务，同时在为其授权进行服务部署与运行时尽可能减少运维性质的干预。总结而言，每一种职能角色都应最大程度利用自动化机制处理自己的日常工作。

由服务供应者（即集群管理员）负责提供运维支持的模式已经过时。开发团队未来将需要自行提供技术运维能力。

— ✕✕✕✕✕ (@peterbourgon) 2017 年 4 月 5 日

正确的模式在于将运维作为一种放大器：建立自动化机制以实现集群与基础设施的自我配置能力。

— ✕✕✕✕✕ (@peterbourgon) 2017 年 4 月 5 日

开发人员: 我的集群出毛病了！

运维人员: 好的，这是我的工作——待我将其搞定！

—以上为错误模式:(

— ✕✕✕✕✕ (@peterbourgon) 2017 年 4 月 5 日

开发人员：我的集群出毛病了！

运维人员：好的，我是这方面的专家，负责引导您解决这个问题 ; 或者您也可以使用这套工具进行重新配置。

— :)

— ✕✕✕✕✕ (@peterbourgon) 2017 年 4 月 5 日

如果你要求传统运维人员拟定出一份从裸机到客户的完整堆栈，并在其中圈出其认为重要的部分，那么对方肯定会把整套堆栈都圈进来。之后他们就会抱怨开发团队总是深更半夜因为这堆破烂产品出了毛病而惊扰其清梦——这明显是一种过时且零散的思维方式，经常导致无法自洽的链状行动方式。由于对面对问题的开发者未抱有任何同情与理解的态度，因此运维人员总是对问题采取警惕及负面的审视角度。如果某项服务在凌晨 2 点时遭遇内存不足问题，那么叫醒那些并不了解情况或者并无权限解决问题的运维人员到底有何意义？换言之，我们难道不该提醒那些更熟悉相关系统的开发人员？后一种方式明显更为合理，但前提是我们需要赋予开发人员知情权、调试权与自行解决问题的能力。

相比之下，新运维（NewOps）模式要求将技术运维工作视为一种产品——只是与产品团队不同，这里的产品实际上为基础设施。正如开发人员为其服务提供API，运维人员也应以工具、UI、自动化、基础设施即代码乃至可观察性与警报等方式为基础设施提供另一类“API”。

@peterbourgon 我对这个问题抱有很多想法，总结成一条推文就是：技术运维已死，从事基础设施维护工作的朋友们还有 5 年时间转向产品部门。

— Dαve Cheney (@davecheney) 2017 年 4 月 5 日

从各个方面来讲，DevOps 的诉求在于引导开发人员积极参与 Ops。

NewOps 则恰恰相反。

过分刻板且自以为是的 Ops 团队根本无法为开发团队提供充足的授权与责任分担能力。而通过这种新的组合式工程方法，我们将要求开发人员以整体方式运用系统思维。常言道：工程师建立可靠系统的惟一方式就是直接对其负责——这意味着由他们响应故障情况，而非引入其他运维人员。

在这样的背景之下，传统的、独行仔式的运维需求将不复存在。运维人员往往扮演着守门者的角色，而他们也通常抱有这样的自我认知。传统运维人员会尽可能建立更多流程，在生产环境中拖慢开发进度，从而确保为开发人员提供一套尽可能可靠的系统。一旦投产，运维人员将负责维护这套系统，并以笨拙的方式通过艰苦努力维护产品实现。

运维锁定：即运维团体能够或者支持的程度决定企业创新速度的上限。

— Kelsey Hightower (@kelseyhightower) 2017 年 4 月 4 日

传统运维人员的行为往往存在“伪君子”的特性。他们主张采取严格的 SDLC，但却绕过 SDLC 制度进行基础设施维护。NewOps 则意味着基础设施即代码，配置变更即代码。这两种作法在 SDLC 当中皆被视为开发人员需要尽可能避免的行为。我们使用不可变的基础设施与 AMI，我们无法在不经过这一流程的前提下将更新实时推送到环境当中。同样的，我们还需要根据合规性及其它 SDLC 要求进行编码，意味着开发人员永远无法代入既有工具与流程。文书工作将占用大部分时间与精力。

传统运维人员与精益理念始终站在对立面上。传统技术运维始终以中断作为驱动因素——即以灭火的心态处理一个又一个问题。与此同时，保持平衡又非常重要。在集成环境当中，允许开发团队通过 SSH 接入设备或者将调试程序添加至容器当中是否会影响应用程序的正确监测？抑或是引发麻烦甚至影响到正常生产？将运维理念与开发理念平衡起来无疑是实现成功的关键所在。

开发团队往往会主动承担技术运维方面的职责以消除创新或者交付过程中的瓶颈。而这种主动性需开发与运维双方互相理解。否定运维团队的工作成果非常容易，但必须承认，运维方往往也非常愿意跟上开发团队的步伐。经过妥善沟通，开发人员无需使用所谓尖端黑客技术也完全能够实现创新。另一方面，现代企业管理层应当意识到，运维团队几乎不可能切实满足各项需求。惟一具备可持续性且能够实现双方彼此理解的途径，在于破除职能孤岛并共同分担责任。这也正是运维的未来所在。随着云迁移变革的深入，运维团队需要通过对开发团队进行授权及委托以进行自身重塑，而非一味执着于自我保护。

运维已死，但运维亦将永存！

（Tyler Treat原创、译者  运和凭）

  

传统运维体系并不会消失，只是在进行重组。

从传统意义上讲，由内部设施到云环境的迁移意味着运维工作在很大程度上被外包至云服务供应商手中。这也正好契合了“NoOps”这一曾经的流行语（如今已经很少被提及）——很多人甚至将其称为 DevOps 的继承者。通过这样的转型，Amazon 与负责构建产品的开发团队之间将只剩下少数但仍非常关键的运维任务，包括基础设施自动化、部署自动化、配置管理、日志管理以及监控与检测等等。

运维工作的前景实际上在很多方面与质量保证（即 QA）颇为相似。传统的质量保证人员正由以测试为重点转向以工具为重点。工程师们编写代码、执行单元测试并整合各类测试。这些测试运行在持续集成（简称 CI）管道当中，而代码则通过持续交付（简称 CD）管道传递并实现产出。质量保证团队的规模正日益缩小，但负责构建工具的团队——包括测试框架、CI 环境、CD 管道等——则不断拓展。事实上，如今质量保证职能已经被并入开发团队之内。在微软与 Amazon 等巨头级企业中已经普及的 SDET（即测试中软件开发工程师）模式正是朝着这个方向迈出的重要一步。2014 年，微软公司转向组合工程模式，将 SDET 与 SDE（即软件开发工程师）合并为同一职能角色，即软件工程师，并由其负责产品代码、测试代码与工具代码。

您是否注意到，质量保证类人员似乎正悄然消失？我所认识或者合作的很多开发团队似乎已经不再设置质量保证职位。

— Gwen (Chen) Shapira (@gwenshap) 2017 年 4 月 6 日

同样的变化也出现在了运维领域。在与 Workiva 基础设施与可靠性团队的合作过程中，我们将运维与基础设施工程团队合并成了一支由现场可靠性工程师们组成的新团队。该团队负责基础设施的构建与维护、配置管理、日志管理、容器管理以及监控等事务。

我个人推荐基于愿景的领导方式。令人信服的愿景能够让各位团队成员之间保持一致，最大程度减少职能与组织性孤岛的存在，从本质上动员和激发大家的积极性。这种方式适合使团队高度一致且松耦合，亦有利于决策制定。对于运维的未来发展前景，我认为其基本作用在于确保组合式工程（Combined Engineering）能够得出合乎逻辑的结果。正如质量保证一样，运维能力同样应被嵌入至开发团队当中。事实上，如果缺少技术运维能力，大家根本无法在现代企业当中成为一名称职的软件工程师。也正因为如此，运维团队现在应当重新定义自身的发展愿景。

运维的未来将保证开发人员能够充分运用工具、自动化与流程方案实现自助服务，同时在为其授权进行服务部署与运行时尽可能减少运维性质的干预。总结而言，每一种职能角色都应最大程度利用自动化机制处理自己的日常工作。

由服务供应者（即集群管理员）负责提供运维支持的模式已经过时。开发团队未来将需要自行提供技术运维能力。

— ✕✕✕✕✕ (@peterbourgon) 2017 年 4 月 5 日

正确的模式在于将运维作为一种放大器：建立自动化机制以实现集群与基础设施的自我配置能力。

— ✕✕✕✕✕ (@peterbourgon) 2017 年 4 月 5 日

开发人员: 我的集群出毛病了！

运维人员: 好的，这是我的工作——待我将其搞定！

—以上为错误模式:(

— ✕✕✕✕✕ (@peterbourgon) 2017 年 4 月 5 日

开发人员：我的集群出毛病了！

运维人员：好的，我是这方面的专家，负责引导您解决这个问题 ; 或者您也可以使用这套工具进行重新配置。

— :)

— ✕✕✕✕✕ (@peterbourgon) 2017 年 4 月 5 日

如果你要求传统运维人员拟定出一份从裸机到客户的完整堆栈，并在其中圈出其认为重要的部分，那么对方肯定会把整套堆栈都圈进来。之后他们就会抱怨开发团队总是深更半夜因为这堆破烂产品出了毛病而惊扰其清梦——这明显是一种过时且零散的思维方式，经常导致无法自洽的链状行动方式。由于对面对问题的开发者未抱有任何同情与理解的态度，因此运维人员总是对问题采取警惕及负面的审视角度。如果某项服务在凌晨 2 点时遭遇内存不足问题，那么叫醒那些并不了解情况或者并无权限解决问题的运维人员到底有何意义？换言之，我们难道不该提醒那些更熟悉相关系统的开发人员？后一种方式明显更为合理，但前提是我们需要赋予开发人员知情权、调试权与自行解决问题的能力。

相比之下，新运维（NewOps）模式要求将技术运维工作视为一种产品——只是与产品团队不同，这里的产品实际上为基础设施。正如开发人员为其服务提供API，运维人员也应以工具、UI、自动化、基础设施即代码乃至可观察性与警报等方式为基础设施提供另一类“API”。

@peterbourgon 我对这个问题抱有很多想法，总结成一条推文就是：技术运维已死，从事基础设施维护工作的朋友们还有 5 年时间转向产品部门。

— Dαve Cheney (@davecheney) 2017 年 4 月 5 日

从各个方面来讲，DevOps 的诉求在于引导开发人员积极参与 Ops。

NewOps 则恰恰相反。

过分刻板且自以为是的 Ops 团队根本无法为开发团队提供充足的授权与责任分担能力。而通过这种新的组合式工程方法，我们将要求开发人员以整体方式运用系统思维。常言道：工程师建立可靠系统的惟一方式就是直接对其负责——这意味着由他们响应故障情况，而非引入其他运维人员。

在这样的背景之下，传统的、独行仔式的运维需求将不复存在。运维人员往往扮演着守门者的角色，而他们也通常抱有这样的自我认知。传统运维人员会尽可能建立更多流程，在生产环境中拖慢开发进度，从而确保为开发人员提供一套尽可能可靠的系统。一旦投产，运维人员将负责维护这套系统，并以笨拙的方式通过艰苦努力维护产品实现。

运维锁定：即运维团体能够或者支持的程度决定企业创新速度的上限。

— Kelsey Hightower (@kelseyhightower) 2017 年 4 月 4 日

传统运维人员的行为往往存在“伪君子”的特性。他们主张采取严格的 SDLC，但却绕过 SDLC 制度进行基础设施维护。NewOps 则意味着基础设施即代码，配置变更即代码。这两种作法在 SDLC 当中皆被视为开发人员需要尽可能避免的行为。我们使用不可变的基础设施与 AMI，我们无法在不经过这一流程的前提下将更新实时推送到环境当中。同样的，我们还需要根据合规性及其它 SDLC 要求进行编码，意味着开发人员永远无法代入既有工具与流程。文书工作将占用大部分时间与精力。

传统运维人员与精益理念始终站在对立面上。传统技术运维始终以中断作为驱动因素——即以灭火的心态处理一个又一个问题。与此同时，保持平衡又非常重要。在集成环境当中，允许开发团队通过 SSH 接入设备或者将调试程序添加至容器当中是否会影响应用程序的正确监测？抑或是引发麻烦甚至影响到正常生产？将运维理念与开发理念平衡起来无疑是实现成功的关键所在。

开发团队往往会主动承担技术运维方面的职责以消除创新或者交付过程中的瓶颈。而这种主动性需开发与运维双方互相理解。否定运维团队的工作成果非常容易，但必须承认，运维方往往也非常愿意跟上开发团队的步伐。经过妥善沟通，开发人员无需使用所谓尖端黑客技术也完全能够实现创新。另一方面，现代企业管理层应当意识到，运维团队几乎不可能切实满足各项需求。惟一具备可持续性且能够实现双方彼此理解的途径，在于破除职能孤岛并共同分担责任。这也正是运维的未来所在。随着云迁移变革的深入，运维团队需要通过对开发团队进行授权及委托以进行自身重塑，而非一味执着于自我保护。

运维已死，但运维亦将永存！

（Tyler Treat原创、译者  运和凭）