交付和部署工具链： 仍然受最薄弱环节原理的约束

如今，你几乎随处可见支持 DevOps 的工具链。 每个人都有一个（是的，甚至我们都有），并且所有这些都是由（其他）API 经济实现的。 根据维基百科，DevOps 工具链是：“由使用DevOps实践的组织协调，在整个软件开发生命周期中帮助交付、开发和管理applications的一组或一组工具。”

现在，这主要集中在应用程序上，但也有生产方面——软件通常在其生命周期中花费大量时间（至少人们希望如此）。 相同的定义也适用于此，但需要注意的是，它的重点（基于我的观点）在于“在整个应用程序生命周期内，由使用 DevOps 实践的组织协调，对网络和应用程序服务进行配置和管理”。 在传统 DevOps 的背景下，这一重点扩展了周期中的“发布”阶段，并涵盖了包括软件配置和部署到生产中的“发布相关活动”。 这必然包括（或应该包括）向目标用户安全交付application所需的网络和应用服务。

问题是，没有任何一个供应商或开源项目包含实现持续部署（顺便说一下，这是生产方面）的乌托邦梦想所需的所有工具。 事实上，应用程序开发侧使用的某些工具也用于生产侧。 我们越来越多地看到两个世界之间的交叉，这对于“devops”来说是一个好兆头，因为它表明两个传统的、除了应用程序之外几乎没有共同之处的根深蒂固的组织之间的某种正常化。

因此，您可以将 Puppet 或 Chef 与 VMware 和 Cisco 结合使用，以自动化整个网络和应用服务堆栈，以支持应用程序对安全性、身份和规模的需求。 您已经创建了执行此操作所需的适用模板和脚本，并验证了它们的正确性，也许可以使用 Postman 及其脚本功能在实验室中针对虚拟基础设施进行测试。 您已决定git是作为配置工件的存储库的一个不错选择，因为应用程序开发已经在使用它，并且可以提供指导，甚至可能举办一两次培训课程。 您甚至可以更进一步开始构建应用程序（或建立OpenStack实施）来协调流程并提供单个服务的自助服务。 您实际上是在定义部署工具链。

这就是最薄弱环节公理开始显现其丑恶一面的地方。 您熟悉这个前提：链条的唯一性取决于其最薄弱的环节。 这里强调“强大”，因为我们可以用其他特性如“可靠”或“安全”或“可扩展”来替代它，而公理仍然成立。 这很重要，因为当您开始定义支持持续部署的工具链时，该链中的每个“链接”都可能成为故障点，从而损害安全性、规模或可用性。

正如规划、验证和监控是 DevOps 工具链中的关键环节一样，它们也必须是 NetOps 工具链中的关键环节。 这对于监控尤其重要，因为在生产环境中应用程序和基础设施（网络和应用服务）交叉最多。 通过监控（可视性），可以在发生故障时了解从业务交易到单个请求和响应的所有内容的全面视图。

配置也必须将工具链连接在一起，因为网络和应用服务的配置可以（并且通常是）特定于特定application的。 

虽然包装和发布机制可能利用类似的工具，但它们是不同的关注点，并且在需求方面往往显示出很大的差异。 由于网络和应用服务可能部署在共享基础设施上，因此采用单一系统方法的工具可能不适合 NetOps。 相反，使用模板在生产中快速部署标准化服务越来越普遍，但在applications表现出高度独特性的 DevOps 中很少适用。

无论如何，这两种工具链都有一个共同点——一个环节的薄弱会影响整个链条。 即使您主要依赖于利用脚本的手动驱动部署，仍然有一个代表交付和部署整体过程的工具链。 人们可以并且已经成为当今交付和部署软件的工具链中的环节。 事实是，当一个关键环节缺失时——因为鲍勃患了最新的流感——这个过程就会崩溃。 工具链无法交付（或部署）。

当您继续推进内部数字化转型时，重要的是您要认识到 DevOps 和 NetOps 工具链的重要性，并且不要忽视其中的任何环节。 在我们实现持续部署的目标的过程中，如果忽视了其中一个环节，就会削弱整个链条。 随着企业越来越依赖这些相互关联的链条，一个薄弱的环节不仅会破坏一个流程，也会破坏整个企业。