编者按：软件工程师TylerTreat认为，运营的未来在许多方面与质量保证(QA)的未来相似。未来，运营将使开发人员能够通过工具、自动化和流程进行自助服务。传统运维(Ops)并没有消失，只是在重组。云服务的发展似乎让运维人员“丢”了工作，因为在传统意义上，从本地迁移到云平台意味着运维工作大部分外包给了云提供商。这与流行语——“无运维”（NoOps）相呼应，许多人称其为DevOps的“继承者”，尽管如今这个词并不那么响亮。这在亚马逊和开发团队创建的产品之间形成了一个小而关键的差距——包括基础设施自动化、部署自动化、配置管理、日志管理以及监控和检测。事实上，运营的未来在许多方面与质量保证(QA)的未来相似。传统意义上的QA正在从关注测试转向关注工具。工程师编写代码、单元测试和集成测试。测试在CI上运行，代码通过CD管道和金丝雀发布到生产。QA团队正在缩小，但构建工具的团队正在增长——测试框架、CI环境和CD管道。QA功能现在嵌入到开发团队中。由Microsoft和Amazon等公司推广的SDET模式是朝着这个方向迈出的第一步。2014年，微软转向组合工程（CombinedEngineering）模式，将SDET和SDE（软件开发工程师）合并为一个角色，软件工程师，负责产品代码、测试代码和工具代码。你有没有注意到QA的作用似乎正在悄然消失？许多与我合作或了解开发组织的开发组织似乎在没有QA的情况下也做得很好。同样的情况很快就会发生在运维人员身上。当我之前在Workiva的基础设施和可靠性小组工作时，我们将运营和基础设施工程团队合并为一个团队，由站点可靠性工程师组成，负责构建和维护基础设施服务、配置管理、日志管理、收集管理、监控、等。我非常喜欢通过远见来领导团队。一个令人信服的发展愿景可以让团队保持一致，减少职能和组织孤岛的影响，并从内部激励员工。它使团队能够高度一致但又松散耦合，从而做出更好的决策。我对未来运营作为一种组织能力的看法基本上将合成工程视为一个合乎逻辑的结论。与QA一样，运营能力也应该嵌入到开发团队中。事实是，如果没有操作技能，您不可能成为现代组织中的称职软件工程师。今天的运维团队应该重新定义他们的愿景。运营的未来是让开发人员能够通过工具、自动化和流程进行自助服务，并使他们能够以最少的运营干预来部署和运行服务。每个角色都应该努力实现工作自动化。提供服务的运营模式已经过时。开发人员的要求总是超出他们的处理能力。正确的模式是将ops视为力量倍增器：创建自动化，让开发人员提供自己的集合和基础设施。开发者：我的收藏坏了！Op：好的，我明白了，现在是我的问题——让我来解决它。-模式错误！开发者：我的收藏坏了！欧普：好的，我明白了。作为领域专家，我来帮你，你可以解决，也可以用工具重新配置。如果你要求一个老派的运维人员解释整个存储堆栈，从裸机到客户，并圈出他们关心的内容，他们会圈出整个存储堆栈，然后抱怨，因为开发团队正在推出由于玩具破旧，他们不得不在半夜被叫醒。这种思维方式基本上已经过时了。正是这样的思维方式，让人觉得运维行业的人深深地恨自己，一根接一根地抽烟。这是回避，意味着缺乏同理心的想法。如果凌晨两点出现了out-of-memory异常，是不是应该警告那些没有眼光、没有能力解决这个问题的运维人员呢？还是应该警告那些对系统相当熟悉的开发者？后一种方式看似Obvious，但关键是需要授权他们才能知道情况，调试后会自动解决。事实上，新的运维模式本质上应该把运维看成是一个产品团队，它的产品就是基础设施。就像开发人员将API视为他们提供的服务一样，运维人员将API视为他们以工具、UI、自动化、基础设施即代码、可观察性和警惕性的形式提供的基础设施。@perterbourgon我对这个话题有很多想法，推文版本是：opsasweknowitisdead,peoplewhodoinfrastructurehavemovetoprod.DevOps在很多方面与开发人员和运维人员产生共鸣。新的运维恰恰相反。Martyrops团队非常自以为是，他们根本没有做足够的工作来将权力和责任转移给开发团队。通过这种新的合成工程方法，我们迫使开发人员进行整体、系统的思考。俗话说：工程师只有对自己构建的系统直接负责，才能构建真正可靠的系统，这意味着工程师是随叫随到的，而不是依赖于其他操作员。有了这样的转变，老式的、狂野的西部行动需要消亡。运营通常被视为守门人，他们也是这样看待自己的。Ops试图尽可能多地嵌入到流程中，从而减慢开发速度，因此当他们投入生产时，开发人员拥有近乎完美的可靠系统。一旦系统经过艰苦严格的批评并投入生产，老派运营负责运行系统。老派的操作往往是伪君子。他们提倡严格的SDLC，然后在维护基础架构时绕过相同的SDLC。NewOps意味着基础架构即代码。配置更改是代码。这些都不能免除开发人员必须遵守的SDLC。我们整理变更请求，使用不可变的基础设施和AMI。如果不经过这个过程，我们就不会将更改推送到实时环境。同样，我们需要将不会引起其他开发人员共鸣的合规性和SDLC要求编入工具和流程。该过程记录并编码该值。老派运营总是与精益思想不一致。它完全是中断驱动的——一次又一次的火灾，一个接一个的问题。同时，取得平衡也很重要。在集成环境中，是否允许开发团队通过SSH连接到一个盒子或将调试器附加到一个集合会阻止他们正确调试应用程序？它会促进疼痛转移吗？平衡是非常必要的。开发团队经常觉得Ops团队阻碍了创新或交付。双方应该相互理解。贬低运营团队很容易，但通常情况下，他们只是想跟上。您不必采用成为HackerNews头条新闻的每一项尖端技术来进行创新。另一方面，现代运营组织需要意识到他们几乎永远无法满足人们的需求。可持续发展的道路——以及传播同理心的道路——是打破孤岛和分担责任。这就是运营的未来。随着运营转移到云端，它需要赋予开发团队更多的权力和信任来重塑自我，而不是“将其锁定”。运维永存！
