云服务的发展看起来让运维人员“丢”了工作，因为从传统意义上说，从本地（on-premise）转移到云平台意味着运维工作在相当大程度上外包给云提供商。这正应了那个流行词—— “无运维运动”（NoOps），许多人称之为 DevOps的“继承者”，虽然这个词最近这些日子已经不是那么响亮了。这使得 Amazon 和开发团队创建的产品——包括基础设施自动化，部署自动化，配置管理，日志管理以及监控和检测——之间出现了隔膜，隔膜虽小，但却至关重要。

事实上，运维的未来从很多方面来说都跟质量保证（QA）的未来走向相似。传统意义上的 QA 正从关注测试转向关注工具。工程师写代码、单元测试和集成测试。测试在 CI 上运行，代码通过 CD pipeline 和 canary 转出（rollout）来生产。QA 团队正在缩小，但是构建工具的团队正在增长——测试框架、CI 环境和 CD pipeline 。QA能力现在已经嵌入发展团队中了。经由 Microsoft 和Amazon 等公司普及的SDET模式是这个方向的第一步。2014年，Microsoft 转向了联合工程（CombinedEngineering）模式，将 SDET 和 SDE（软件开发工程师）合并成一个角色，软件工程师，负责产品代码、测试代码和工具代码。

你们有没有注意到 QA 起的作用似乎在悄然消失？跟我合作的或者是我了解的众多 dev 组织似乎不用 QA 也做得挺好。

同样的状况很快也会发生在运维人员身上。我之前在 Workiva 的基础设施和可靠性小组里工作时，我们将运行和基础建设工程团队并入一个单独的团队，该团队是由网站可靠工程师组成的，负责构建和维护基础设施服务，配置管理，日志管理，集合管理，监控等。

我非常支持通过愿景实现对团队的领导。发展愿景令人信服，可以使团队之间达成共识，减少功能孤岛和组织孤岛的影响，并能够从内部激励员工。它能使团队高度一致又能松散耦合，能够更好地做出决定。我对运维未来作为组织能力的想法本质上是将合成工程看作是合理结论。跟 QA 一样，运维能力也应该被嵌入发展团队中。事实是，没有运维技能，你不可能在现代组织中成为一名合格的软件工程师。现如今的运维团队，应该重新定义他们的愿景。

运维的未来是要使开发者能够通过工具、自动化和流程实现自助服务，并使他们能够通过最小的运维干预来部署并运行服务。每个角色都应该朝着脱离它们的工作实现自动化的方向而努力。

ops提供服务的模式已经穷途末路，并且也过时了。Devs 提出的要求总会超出他们的能力。

正确的模式是要把ops作为力量倍增器：创建自动化，使devs提供自己的集合和基础设施。

Dev：我的集合崩了！ Op：好的，我知道了，现在是我的问题了——等我来解决。 ——错误的模式！

Dev：我的集合崩了！ Op：好的，我知道了。作为领域专家，我来帮你，你来解决，或者是，你可以用工具重配一下。:)

如果你让一个老派的运维人员理解说明整个存储栈，从裸金属到客户，并圈出他们所关心的，他们会把整个存储栈都圈起来，接着就会抱怨，就因为dev团队正在推出的破烂玩应，他们大半夜的得被叫起来。这种思维方式基本上已经过时了，正是思维方式使得人们都觉得干运维这一行的都是深深厌恶自己，一根接一根不停抽烟。这是由于缺乏同理心而产生的避重就轻、刻薄的想法。如果凌晨两点出现内存不足的异常，要不要去警告那些没有远见或者能力的运维人员去解决这个问题呢？还是说我们应该警告那些对系统相当熟悉的开发者呢？后一种做法似乎是明显的，但是关键在于他们需要被授权获悉状况，调试后自动解决。

其实新运维模式本质上应该把运维看作是一个产品团队，其产品就是基础设施。就像开发者把 API 作为他们提供的服务，运维把 API 以工具、UI、自动化、基础设施即代码、可观察性和警戒的形式作为他们提供的基础设施。

@perterbourgon 关于这个话题，我有很多想法，tweet 版本是：我们所知道的 ops 已亡，做基础设施的人有五年的时间转移到产品上。

DevOps 在很多方面正让开发者跟运维人员感同身受。新运维正好相反。殉道者式的运维团队相当自以为是，他们根本没有做好足够的工作将权利和责任转给开发团队。用这种新的合成工程的方式，我们迫使开发人员从整体角度，系统地思考问题。常言道：只有工程师直接对自己所建造的系统负责时，他们才能建造出真正可靠的系统，也就是意味着工程师要随叫随到，而不是指望其他运行人员。

因着这样的转变，老派的、西部狂野式的运维需要消亡。运维一般被看作是守门人，他们也是这么看待自己的。运维正尽可能多地嵌入进程，减缓开发速度，所以当他们开始生产时，开发人员会有近乎完美的可靠系统。一旦该系统历经千辛万苦，经受了严格指责，投入生产之后，老派的运维需负责运行该系统。

老派的运维通常是伪君子。他们主张严苛的 SDLC，然后在维护基础架构时却绕过了同样的 SDLC 。新运维意味着基础架构即代码。配置变化即代码。这两个哪个也没能免于开发人员必须遵守的 SDLC。我们编纂变更请求，使用不可改变的基础架构和 AMI。没经历此进程，我们不会把改变推送到真实环境中。同样地，我们需要对合规性和其他开发人员无法产生共鸣的 SDLC 要求进行编码，编到工具和进程中。进程记录并编纂价值。

老派运维总是同精益思维不一致。它完全是中断驱动——灭火后，一个接一个解决问题。同时，取得平衡非常重要。在集成环境中，使开发者团队能够SSH 登录进 box 中或者将调试器附加到集合上，会阻止他们正确地调试应用程序吗？会促进痛苦移位吗？在运维思维和开发思维间取得平衡是非常必要的。

开发团队通常认为运维团队阻碍了创新或者交付。双方都应该相互理解。贬低运维团队很容易，但是更多情况下，他们只是想跟上步伐。不用非得采用每个登上 Hacker News 头条的最前沿的科技，也能创新。另一方面，现代运维组织需要意识到他们几乎永远不可能满足人们的要求了。可持续的发展道路——也是传播同理心的道路——是打破孤岛，共担责任。这就是运维的未来。随着运维工作转移到云，它需要给予开发团队更多的权利和信任以重塑自身，而不是“闭关锁国”。（Tyler Treat原创）

云服务的发展看起来让运维人员“丢”了工作，因为从传统意义上说，从本地（on-premise）转移到云平台意味着运维工作在相当大程度上外包给云提供商。这正应了那个流行词—— “无运维运动”（NoOps），许多人称之为 DevOps的“继承者”，虽然这个词最近这些日子已经不是那么响亮了。这使得 Amazon 和开发团队创建的产品——包括基础设施自动化，部署自动化，配置管理，日志管理以及监控和检测——之间出现了隔膜，隔膜虽小，但却至关重要。

事实上，运维的未来从很多方面来说都跟质量保证（QA）的未来走向相似。传统意义上的 QA 正从关注测试转向关注工具。工程师写代码、单元测试和集成测试。测试在 CI 上运行，代码通过 CD pipeline 和 canary 转出（rollout）来生产。QA 团队正在缩小，但是构建工具的团队正在增长——测试框架、CI 环境和 CD pipeline 。QA能力现在已经嵌入发展团队中了。经由 Microsoft 和Amazon 等公司普及的SDET模式是这个方向的第一步。2014年，Microsoft 转向了联合工程（CombinedEngineering）模式，将 SDET 和 SDE（软件开发工程师）合并成一个角色，软件工程师，负责产品代码、测试代码和工具代码。

你们有没有注意到 QA 起的作用似乎在悄然消失？跟我合作的或者是我了解的众多 dev 组织似乎不用 QA 也做得挺好。

同样的状况很快也会发生在运维人员身上。我之前在 Workiva 的基础设施和可靠性小组里工作时，我们将运行和基础建设工程团队并入一个单独的团队，该团队是由网站可靠工程师组成的，负责构建和维护基础设施服务，配置管理，日志管理，集合管理，监控等。

我非常支持通过愿景实现对团队的领导。发展愿景令人信服，可以使团队之间达成共识，减少功能孤岛和组织孤岛的影响，并能够从内部激励员工。它能使团队高度一致又能松散耦合，能够更好地做出决定。我对运维未来作为组织能力的想法本质上是将合成工程看作是合理结论。跟 QA 一样，运维能力也应该被嵌入发展团队中。事实是，没有运维技能，你不可能在现代组织中成为一名合格的软件工程师。现如今的运维团队，应该重新定义他们的愿景。

运维的未来是要使开发者能够通过工具、自动化和流程实现自助服务，并使他们能够通过最小的运维干预来部署并运行服务。每个角色都应该朝着脱离它们的工作实现自动化的方向而努力。

ops提供服务的模式已经穷途末路，并且也过时了。Devs 提出的要求总会超出他们的能力。

正确的模式是要把ops作为力量倍增器：创建自动化，使devs提供自己的集合和基础设施。

Dev：我的集合崩了！ Op：好的，我知道了，现在是我的问题了——等我来解决。 ——错误的模式！

Dev：我的集合崩了！ Op：好的，我知道了。作为领域专家，我来帮你，你来解决，或者是，你可以用工具重配一下。:)

如果你让一个老派的运维人员理解说明整个存储栈，从裸金属到客户，并圈出他们所关心的，他们会把整个存储栈都圈起来，接着就会抱怨，就因为dev团队正在推出的破烂玩应，他们大半夜的得被叫起来。这种思维方式基本上已经过时了，正是思维方式使得人们都觉得干运维这一行的都是深深厌恶自己，一根接一根不停抽烟。这是由于缺乏同理心而产生的避重就轻、刻薄的想法。如果凌晨两点出现内存不足的异常，要不要去警告那些没有远见或者能力的运维人员去解决这个问题呢？还是说我们应该警告那些对系统相当熟悉的开发者呢？后一种做法似乎是明显的，但是关键在于他们需要被授权获悉状况，调试后自动解决。

其实新运维模式本质上应该把运维看作是一个产品团队，其产品就是基础设施。就像开发者把 API 作为他们提供的服务，运维把 API 以工具、UI、自动化、基础设施即代码、可观察性和警戒的形式作为他们提供的基础设施。

@perterbourgon 关于这个话题，我有很多想法，tweet 版本是：我们所知道的 ops 已亡，做基础设施的人有五年的时间转移到产品上。

DevOps 在很多方面正让开发者跟运维人员感同身受。新运维正好相反。殉道者式的运维团队相当自以为是，他们根本没有做好足够的工作将权利和责任转给开发团队。用这种新的合成工程的方式，我们迫使开发人员从整体角度，系统地思考问题。常言道：只有工程师直接对自己所建造的系统负责时，他们才能建造出真正可靠的系统，也就是意味着工程师要随叫随到，而不是指望其他运行人员。

因着这样的转变，老派的、西部狂野式的运维需要消亡。运维一般被看作是守门人，他们也是这么看待自己的。运维正尽可能多地嵌入进程，减缓开发速度，所以当他们开始生产时，开发人员会有近乎完美的可靠系统。一旦该系统历经千辛万苦，经受了严格指责，投入生产之后，老派的运维需负责运行该系统。

老派的运维通常是伪君子。他们主张严苛的 SDLC，然后在维护基础架构时却绕过了同样的 SDLC 。新运维意味着基础架构即代码。配置变化即代码。这两个哪个也没能免于开发人员必须遵守的 SDLC。我们编纂变更请求，使用不可改变的基础架构和 AMI。没经历此进程，我们不会把改变推送到真实环境中。同样地，我们需要对合规性和其他开发人员无法产生共鸣的 SDLC 要求进行编码，编到工具和进程中。进程记录并编纂价值。

老派运维总是同精益思维不一致。它完全是中断驱动——灭火后，一个接一个解决问题。同时，取得平衡非常重要。在集成环境中，使开发者团队能够SSH 登录进 box 中或者将调试器附加到集合上，会阻止他们正确地调试应用程序吗？会促进痛苦移位吗？在运维思维和开发思维间取得平衡是非常必要的。

开发团队通常认为运维团队阻碍了创新或者交付。双方都应该相互理解。贬低运维团队很容易，但是更多情况下，他们只是想跟上步伐。不用非得采用每个登上 Hacker News 头条的最前沿的科技，也能创新。另一方面，现代运维组织需要意识到他们几乎永远不可能满足人们的要求了。可持续的发展道路——也是传播同理心的道路——是打破孤岛，共担责任。这就是运维的未来。随着运维工作转移到云，它需要给予开发团队更多的权利和信任以重塑自身，而不是“闭关锁国”。（Tyler Treat原创）