NetOps 是时候接受持续部署了

持续部署并不一定意味着每次都立即进行更改。 但它总得从某个地方开始。

CI/CD（持续集成/持续交付）是开发人员的领域。 这是提高交付速度的总体模型——对于那些习惯于在更活跃、与用户相关的环境中看待它的人来说，这实际上意味着“准备部署”。

但这并不意味着 NetOps 可以忽略 CI/CD。恰恰相反。 但这并不意味着 NetOps 必须保持 1:1 的部署与交付比例。 应用程序“准备好部署”的频率可能会令人难以承受，特别是如果您的应用程序开发人员已经掌握了持续交付的技术，尤其是当 NetOps 尚未掌握持续部署的技术时。  但仍有空间来适应更高的部署频率，在某些情况下，对于开发人员和企业来说，这肯定会像持续部署一样。 

秘密就在于应用程序的“小改动”和“大改动”之间的区别。

NetDevOps 2016 年秋季调查发现，微小变更被推向生产的频率比我们通常认为的要高得多。 近 51% 的受访者每天都会多次将微小变更投入生产。 超过三分之一的人每月进行 1 到 5 次重大变更，另有三分之一的人承认他们每月进行的重大变更不到一次。

不幸的是，“重大”和“次要”变化的定义并没有量化，但通常情况下，这种相对描述往往不仅适用于某个行业或组织，而且适用于每个应用。 尽管如此，似乎有相当多的企业（略多于一半）正在定期部署重大生产变革。

这意味着，从总体上看，我们正在朝着持续部署的方向迈出小步。 问题是，部署一个崭新的应用与部署现有应用的更新并不是一回事。 即使我们添加了新的网络或应用服务，其“中断的可能性”规模与部署全新的应用相比仍然有很大不同。

所以就目前而言，闪亮的新应用程序将需要更多的协调和规划。 我们仍然认为，生产中的大多数应用程序都是持续部署的潜在目标。 我们可以采取的措施之一是，根据“小”变化与“大”变化对生产环境的影响，对其进行说明。

小改动可能仅限于对应用程序内部有影响的改动。 例如逻辑的变化。 它们可能包括应用程序堆栈（Web 服务器、应用服务器等）的补丁或升级，以及其支持应用程序基础设施的补丁或升级。 基本上，微小的更改只会影响应用程序。它们不需要对实际交付和保护应用程序正常使用的网络或应用程序服务进行任何更改。

那么，重大变更将影响网络或支持应用的应用服务中的任何内容。重大变更可能需要调整交付策略（启用压缩，对吗？）或插入新服务，例如 URL 过滤或请求检查，以防止利用最近发现的漏洞。 这些是重大的变化，因为它们影响更广泛的生产系统，而这些系统可能会或可能不会影响其他应用。

您甚至可能会制定出一个更加细致的评分系统，将对外部服务的影响考虑在内。 新服务可能比对现有服务的调整更具破坏性。 与现有的小幅更新政策相比，新政策需要更加注重实施。

一旦您同意要使用的“系统”，同意根据需要启用微小更改就会变得容易得多。 本质上，只要认为发生错误时产生的潜在影响最小，您就可以通过使应用程序交付流入生产环境，从而进入持续部署阶段。 变化很小，风险也很小。 至少这是假设。

这样做的目的是使可能成为重大业务变化的微小技术变化能够更快地传达到用户手中。 因为这些通常被大型、传统的组织所阻碍。 由于日程安排冲突以及变更控制委员会根据项目优先级或政策做出的决定，即使是对用户界面进行的小幅修改也可能会延迟数周甚至更长时间。 尽管这一微小的改变可能意味着更好的用户体验，从而带来更高的转化率或客户保留率。 如果这个小变化只影响应用程序，即它是一个“小”变化，那么 IT 政治真的是阻碍它的理由吗？

持续部署不仅在技术上实现了自动投入生产，而且还要拆除阻碍应用和更新何时投入生产的流程的传统结构（这就是文化）。

通过建立区分“小更新”和“大更新”的通用标准，区分可能影响应用程序外部系统的更新和不会影响应用程序外部系统的更新，组织可以实现某些更改的持续部署，而不会产生额外的风险或破坏生产稳定性。 这可能对业务产生积极影响，意味着每个人都是赢家。