DevOps 不会随着交付而结束

如果部署延迟了发布，那么无论你交付得多快都毫无意义。 虽然 NetOps 正在逐渐接受自动化和编排，但他们在加快部署方面仍面临着重大挑战。 DevOps 最适合帮助他们做到这一点。

数字化转型意味着 DEVOPS

数字化转型与 DevOps 之间存在着无可争辩的联系。 由于 DX，48% 的组织正在更频繁地将应用程序投入生产。 62％正在自动化和协调IT系统和流程。 52％的人正在改变他们开发应用程序的方式（想想敏捷）。 42% 正在探索容器和微服务。 从应用s的构建模块一直到将其推向市场的方法，数字化转型意味着 DevOps 可以将“持续交付”扩展到“持续部署”。 请记住，“交付”并不意味着进入市场，而是意味着生产——部署过程开始并使应用进入可接受的状态。

这是因为“可接受使用”不仅仅意味着“应用程序运行正常”。 它包含一组必须以应用服务的形式实现和部署的要求。 规模、安全性、性能、监控——所有这些都必须到位，应用才能被视为“可接受使用”。 这就是今天的“部署管道”的组成部分。

部署需要 DEVOPS 来实现自动化和编排的承诺 

不幸的是，与乔治·杰特森 (George Jetson) 和弗雷德·弗林特斯通 (Fred Flintstone) 一起进行滑雪旅行，这非常准确地描述了交付和部署中的自动化状态。 前者来自未来，骑着喷气式滑雪板，而弗雷德仍然生活在过去，使用手动滑雪板。 如果您猜测乔治·杰特森 (George Jetson) 骑着火箭动力滑雪板就是在进行 DevOps 持续交付，那么您猜对了。 如果您猜测 NetOps 正在尝试采用一种主要为手动的方法进行持续部署，那么您也是对的。 

NetOps 是负责配置、部署和操作当今组织使用的平均 14 个应用服务的人员。 这包括从可扩展性（负载平衡和入口控制）到安全性（Web应用防火墙和机器人防御）的一切，甚至还包括改善支持应用的整个堆栈性能的更模糊的服务。

现在，虽然他们有了滑雪板来帮助他们更快地移动，但他们仍然缺少 DevOps 同行所拥有的火箭辅助滑雪板。

管道自动化方面的差异可能导致令人沮丧的延误 

实现“持续部署”所需的各种应用服务组件的自动化率之间的差异表明需要消除导致大多数组织仍然使用手动方法的“不平衡力量”。 对于已实现自动化零部署组件的组织来说尤其如此。 这就是火箭辅助滑雪和传统滑雪的区别。 即使那些已经成功实现管道部分自动化的企业也没有始终如一地做到这一点——仅有 21% 的企业实现了所有四个关键组件的自动化。 11%的企业仅实现了单个区域的自动化，25%的企业实现了两个区域的自动化。

想象一下，在飞行途中，你滑雪板上的火箭突然消失了。

我们不能再依赖传统的“投入更多人力解决问题”的方法来加快部署。 这只会在交付生产和交付给消费者之间增加更多的沟通层和流程障碍，从而加剧延迟。 

这些延误会让企业不高兴，因为他们不得不等待，更糟糕的是，他们常常为了弥补时间而跳过一些步骤（比如安全检查）。 为了解决这个问题，我们需要找到并解决阻碍持续部署的“不平衡力量”。

这些“不平衡的力量”是什么？DEVOPS 可以做什么来重新平衡它们？

在 NetOps 提到的挑战中可以发现部署中的不平衡力量。 技能、政策、预算和集成是实现持续部署的重大绊脚石。 请不要误会我的意思，NetOps 可以编写脚本，而且他们一直都在这样做。 但是脚本不是自动化，也不能满足跨 14 种不同设备、系统和服务进行集成的需求。 NetOps 需要帮助来识别和实践工具和方法，这些工具和方法不仅能够实现这些不同系统的集成，而且还能够以一致、可预测和可重复的方式推动部署过程。 

这是 DevOps 可以帮助 NetOps 建立成功的持续部署实践的地方。

合作必须跨越 IT 与开发之间的界限

文化不是可有可无的。 它对行为和实践有着非常现实的影响。 仅团队结构就极大地改变了管道自动化，传统的单一功能团队落后于当代的 DevOps 驱动的团队。 推动更具协作性的团队结构。 同样，协作团队应该在关键指标上保持一致。 共享指标使 NetOps 和安全部门能够致力于持续部署而不会受到惩罚。 目前，近四分之三的 NetOps 是根据网络正常运行时间来衡量的。 他们几乎不关注部署的频率。 他们将专注于维护网络正常运行，因为这是他们必须关注的。 共享指标使 NetOps 可以专注于业务需求——更快、更频繁的部署。 

最后，需要同理心。 你们都在同一个团队，而且你可能会惊讶地发现，你们重视同样的事情。 NetOps 可能与 DevOps 一样高度重视管道自动化。 请记住，DevOps 在解决和克服集成、工具和技能方面的障碍方面比 NetOps 领先了十年。 协作团队可以通过促进从交付到部署的工具（如 Jenkins 和 GitHub/GitLab）的标准化来提供帮助。

举办午餐并学习。 主动指导 NetOps 对应人员并分享见解以及教程和社区链接，为 NetOps 提供学习行业技巧的机会。 建立“自动化卓越中心”或社区，帮助建立最佳实践，分享解决方案，并鼓励分享解决这些“不平衡力量”的知识。

DevOps 不应该、也不能以交付而结束。 应用只有到达目标消费者手中后才算真正“完成”。 这意味着部署（以及其公认的复杂的设备和应用服务管道）需要实现自动化，以减少实现所需的时间。 DevOps 拥有技能、工具和经验，可以帮助 NetOps 滑雪板配备火箭，以便他们也能按照业务需要快速移动。