NetOps是时候拥抱持续部署了

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

持续部署并不意味着每次都必须立即部署每一项变更，但总要从某处开始。

CI/CD（持续集成/持续交付）属于开发人员的工作范畴。它是加快交付速度的总体模式。对于习惯从更主动、更贴近用户的角度理解“交付”的人来说，这里的“交付”实际上是指“可随时部署”。

这并不意味着NetOps可以忽视CI/CD。恰恰相反。但这也不意味着NetOps必须保持1:1的部署与交付比例。应用“准备好部署”的频率可能令人难以应对，尤其是在应用开发人员已经熟练掌握持续交付，而NetOps尚未完全掌握持续部署的情况下。不过，仍有空间提高部署频率；在某些情况下，开发人员和业务部门无疑会感受到近似持续部署的体验。

关键在于区分应用的“小改动”和“大改动”。

The NetDevOps 2016年秋季调查发现，小规模变更推送到生产环境的频率远高于通常认为的水平。近51%的受访者每天会多次将小规模变更推送到生产环境。超过三分之一的受访者每月会推送1至5次重大变更，另有三分之一表示，他们进行重大变更的频率低于每月1次。

遗憾的是，“重大”和“轻微”变更并没有量化定义。但通常情况下，这类相对描述不仅因行业或组织而异，往往还取决于具体应用。尽管如此，似乎仍有相当多的受访者（略多于半数）非常频繁地将重大变更部署到生产环境中。

这意味着，从整体来看，我们正在朝着持续部署的方向逐步迈进。但部署一个全新的应用，与为现有应用部署更新并不是一回事。即使要添加新的网络或应用服务，其“潜在中断影响”也与部署全新应用有很大差别。

因此，目前可以认为，全新应用需要更多协调和规划。不过，生产环境中的绝大多数应用仍有望采用持续部署。为了推动这一进程，我们可以根据变更对生产环境的影响，明确界定“次要”变更与“重大”变更。

次要变更可以仅限于影响应用内部的变更，例如逻辑变更。它们可能包括对应用堆栈（Web服务器、应用服务器等）的补丁或升级，以及对其配套应用基础设施的补丁或升级。简而言之，次要变更仅影响应用。它们不需要更改在常规使用中实际交付和保护该应用的网络或应用服务。

因此，重大变更是指会影响为应用提供支持的网络或应用服务中任何部分的变更。重大变更可能需要调整交付策略（比如启用压缩，可以吗？），或添加新服务，例如URL过滤或请求检查，以防止攻击者利用近期发现的漏洞。之所以将这些变更视为重大变更，是因为它们会影响范围更广的生产系统，进而可能会影响其他应用。

您甚至可以制定一套更细致的评分体系，将对外部服务的影响纳入考量。新增服务可能比调整现有服务带来更大的干扰。与小幅更新现有策略相比，实施新策略需要投入更多精力。

就要采用的“体系”达成一致后，各方会更容易同意按需启用小幅变更。按需。从本质上说，这意味着应用交付可以进入生产环境，从而转向持续部署，前提是即使出现问题，变更也被认为只会造成极小的潜在影响。小幅变更，风险也小。至少这是基本假设。

这样一来，就能让可能带来重大业务变化的微小技术改动更快交付给用户。这类改动在大型传统组织中往往会被拖延。即使只是对用户界面做一处小改动，也可能因排期冲突，或变更控制委员会基于项目优先级或内部博弈作出的决定，而被推迟数周甚至更久。尽管这项小改动可能会改善用户体验，进而提高转化率或客户留存率。如果这项小改动只影响应用，也就是说，它属于“微小”改动，那么IT部门的内部博弈真的应该成为拖延它的理由吗？

持续部署不仅是在技术上实现自动推送至生产环境，还意味着打破阻碍应用和更新上线决策流程的传统机制（这属于文化层面的变革）。

通过建立统一标准，区分“次要”与“重大”更新，并判断更新是否可能影响应用之外的系统，组织便可对部分变更实施持续部署，而不会增加额外风险或破坏生产环境的稳定性。这还可能为业务带来积极影响，实现多方共赢。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章