运维的未来！

云头条 · 公众号 · 科技媒体 · 2017-05-06 22:28

正文

传统运维不会消失，它只是在改组。就传统意义而言，从本地转移到云端意味着运维（Ops）基本上外包给了云服务提供商。这是当下蔚然成风的NoOps潮流，许多人称NoOps是开发运维（DevOps）的“后续者”，不过这年头这个词已淡化了许多。这留下的是亚马逊和开发团队构建的产品之间一块很薄又很重要的部分，涵盖基础设施自动化、部署自动化、配置管理、日志管理以及监控和检测。

从许多方面来看，运营的未来酷似质量保证（QA）的未来。传统的质量保证角色正由注重测试转向注重工具。工程师编写代码、单元测试和集成测试。测试在持续集成（CI）中运行，代码通过持续交付（CD）管道和金丝雀部署（canaryrollout）进入到生产环境。质量保证团队在日渐式微，而构建工具的团队日益壮大起来，这些工具包括测试框架、持续集成环境和持续交付管道。质量保证能力现在已嵌入到开发团队中。软件开发测试工程师（SDET）模式是往这个方向迈出的第一步，微软和亚马逊之类的公司推广了这种模式。2014年，微软改用组合工程（Combined Engineering）模式，将SDET和SDE（软件开发工程师）合并为一种角色：软件工程师，软件工程师负责编写产品代码、测试代码和工具代码。

对于运维而言，情况变得一模一样。我在Workiva的基础设施及可靠性小组工作期间，我们将运营团队和基础设施工程团队合并为一个团队，这个团队实际上由网站可靠性工程师（SRE）组成。该团队负责构建和维护基础设施服务、配置管理、日志管理、容器管理以及监控等。

我是通过愿景来领导的忠实拥趸。令人信服的愿景能够让诸团队保持一致，尽量减小职能孤岛和组织孤岛带来的影响，并且从源头上激励和动员人们。它带来了高度一致、松散耦合的团队，有助于做出决策。对于作为一种组织竞争力的运维的未来，我认为组合工程是合乎逻辑的结果。就像质量保证一样，运维能力应该嵌入到开发团队中。事实上，要是没有运维技能，你在现代组织不可能成为高效的软件工程师。运维团队应该重新定义愿景。

运维的未来是，让开发人员能够借助工具、自动化和流程，并且让他们能够在运维干预极少的情况下部署和运营服务，从而实现自助服务。每个角色都应该努力使工作实现自动化。

如果你让一个老派的运维人员画出从裸机到客户的整个架构，并把他们关心的方面圈出来，他们就会围绕整个架构画一个圆圈。然后，他们会抱怨开发团队交付的拙劣产品害得自己在三更半夜接到反映故障的传呼。这种过时而破碎的思维方式导致了自我厌恶、不断抽烟的运维人员这个刻板的形象。这是一种缺乏同情心引起的苦恼。如果某个服务在凌晨2点出现内存不足异常，提醒缺乏洞察力或权力来解决问题的运维人员，那有意义吗？或者说，我们应该提醒非常熟悉该系统的开发人员吗？后者似乎显而易见，但关键是，他们需要获得授权，可以了解情况，进行调试，并独立解决。

NewOps模式而是应该实际上将运维当作其产品是基础设施的产品团队。酷似开发人员为服务提供API的方式，运维人员为基础设施提供API，具体表现为工具、用户界面、自动化、基础设施即代码、可观察性和警报等。

在许多方面，开发运维旨在让开发人员对运维表示同情。NewOps恰好相反。过于自以为是的运维团队在授权方面做得根本就不够，将责任推到开发团队的头上。有了这种新的组合工程方法，我们迫使开发人员以整体的方式来运用系统思维。常言道：工程师要构建真正可靠的系统，唯一的方式就是他们直接对系统负责――这意味着他们随叫随到，而不是另外某个运维人员。

由于这一举动，原始落后的老派运维需要消亡。运维人员通常是把关人，他们认为自己扮演这种角色。老派运维在构建尽可能多的流程，减慢了开发速度，以至于等到进入到生产环境，开发人员拥有了近乎完全可靠的系统。

老派运维人员往往是伪君子。他们主张奉行严格的软件开发生命周期（SDLC），然后等到维护基础设施时，却绕过同样的SDLC。NewOps意味着基础设施是代码。配置更改是代码。这两个都受到开发人员要遵守的同一SDLC的制约。我们整理变更请求，我们使用不可变的基础设施和AMI。要是变更没有经过这个流程，我们不会将变更推送到工作环境。与之相仿，我们需要将开发人员不会感同身受的合规及其他SDLC需求编码成工具和流程。

老派运维老是与精益理念相冲突。它纯粹是中断驱动的（interrupt-driven）――到处灭火，解决一个又一个问题。与此同时，做到兼顾很重要。让开发团队能够通过SSH连接到设备，或者在集成环境下将调试人员与容器连接起来，这是否会打消他们以适当的方式检测应用程序的积极性？这会不会促进疼痛移位（http://bravenewgeek.com/pain-driven-development-why-greedy-algorithms-are-bad-for-engineering-orgs/）？兼顾运维理念和开发理念至关重要。

开发团队常常让运维团队对创新或交付瓶颈负责。双方都要有同情心。很容易贬低运维人员，但他们常常只是想努力跟上步伐。你可以创新，不必采用登上Hacker News的每一项最先进技术。另一方面，现代运维组织需要意识到，几乎总是无法满足对自己提出来的要求。可持续的方法（即灌输同情心的方法）就是拆除孤岛，分担责任。这就是运维的未来。由于向云转移，运维团队需要通过授权和委托开发团队来重塑自我，而不是试图通过划清界限来保全自己。

运维已死，运维不朽！