持续响应：DevOps 中被忽视的关键流程

持续响应 (CR) 是 DevOps 流程链中被忽视的一环。另外两个主要环节——持续集成 (CI) 和持续交付 (CD)——已被广泛理解，但 CR 却没有。然而，CR 是使客户满意并实现更快速度和敏捷性承诺所必需的关键要素。DevOps 运动的核心是需要更高的速度和敏捷性，以将企业带入我们新的数字时代。CR 在实现这一目标中发挥着关键作用。

定义 CR

我们需要对 CR 进行清晰的定义，以便继续深入探讨。为了将其置于上下文中，让我们回顾一下持续集成 (CI) 和持续交付 (CD) 的定义。以下是 Gartner 在 2017 年我写下这些定义时的说法：

持续集成是一种在计划好的、可重复的和自动化的基础上集成、构建、测试和交付功能性软件的实践。

持续交付是一种软件工程方法，团队在保持短周期内生产有价值的软件的同时，确保软件可以随时可靠地发布。

我提出以下 CR 的定义：

持续响应是一种实践，开发人员和运维人员对其部署的软件进行检测、测量、观察和管理，以寻找性能、弹性、最终用户行为和安全态势的变化，并采取必要的纠正措施。

我们可以争论这些定义是否 100% 正确。但它们对于我们的目的来说已经足够好了，即在粗略的上下文中构建 CR 的定义，以便我们理解它实际上只是完整周期链条中的最后一环。

你可能会问，这个多色的环是什么？它是著名的 OODA 环。在继续之前，让我们简单介绍一下 OODA 环是什么，以及它为什么与 DevOps 相关。我们将保持简洁，因为 OODA 环和 DevOps 之间已经有很长的历史了。

简短的题外话：OODA 环

核心 DevOps 思想的核心是使用 OODA 环来创建一个主动流程，用于演进和响应不断变化的环境。快速的 网络搜索 可以轻松了解 OODA 环和 DevOps 之间的悠久历史，但如果您想深入了解，我强烈推荐 博伊德之道：如何掌握 OODA 环。

这是约翰·博伊德提出的“演进的 OODA 环”：

理解 OODA 环最重要的事情是，它是一个用于适应和处理不断变化的环境的认知过程。

理解 OODA 环第二重要的事情是，由于它是一个旨在演进的思维过程，因此它依赖于将反馈驱动回周期的早期部分，随着您的迭代。

正如您在上面的图表中看到的，CI、CD 和 CR 都是它们自身独立的 OODA 环，位于整个 DevOps OODA 环之内。这里的关键是，每个 OODA 环都是一个不断演进的思维过程，用于衡量测试、发布和成功的方式。简而言之，那些能够最快执行 OODA 环的人将获胜。

换句话说，DevOps 希望驱动速度（更快地执行 OODA 环）和敏捷性（获取反馈并使用它来不断调整 OODA 环）。这就是为什么 CR 是 DevOps 流程的关键部分。我们必须将生产反馈驱动到 DevOps 成熟过程中。DevOps 的文化、自动化、测量和共享 (Culture, Automation, Measurement, and Sharing - CAMS) 的概念部分但不充分地捕捉到了这一点，而 CR 在我看来，提供了 CI/CD 更清晰的延续。

分解 CR

CR 比 CI 或 CD 具有更深和更广的深度和广度。这是很自然的，因为我们正在分类的是部署后流程，我们的软件通过该流程采取各种操作，从自主响应到客户体验分析。我认为，当它被分解时，CR 组件可以分为三个关键类别。这三个领域中的每一个都形成一个完整的 OODA 环；然而，整个 OODA 环的自动化程度差异很大。

下表将有助于阐明 CR 的三个领域：

实时 CR 可能是三者中理解最透彻的。这种 CR 是我们的软件已针对已知问题进行了检测，并且可以立即做出自动化响应（自主性）。已知问题的示例包括响应高或低需求（例如，弹性自动伸缩）、响应预期的基础设施资源故障（例如，自动修复）以及响应预期的分布式应用程序故障（例如，断路器模式）。未来，我们将看到机器学习 (ML) 和类似技术应用于自动化根本原因分析和事件关联，这将为“无运维”或“零运维”运营模式提供一条道路。

分析型 CR 仍然是 CR 流程中最手动的。这种 CR 主要侧重于观察最终用户体验，并向产品开发周期提供反馈，以添加功能或修复现有功能。这方面的示例包括传统的 A/B 网站测试、测量页面加载时间或服务响应时间、服务故障的事后分析等等。

预测型 CR，由于人工智能和机器学习 (AI 和 ML) 的复兴，是 CR 的创新领域之一。它使用历史数据来预测未来需求。ML 技术正在使该领域变得更加完全自动化。示例包括自动化和预测性容量规划（主要用于基础设施层）、服务交付的自动化成本基础分析以及基础设施资源的实时重新分配，以在容量和硬件故障问题影响最终用户体验之前解决这些问题。

深入探讨 CR

CR 像 CI 或 CD 一样，是一个由一组底层工具支持的 DevOps 流程。CI 和 CD 不仅仅是 Jenkins、单元测试或自动化部署。它们是一个流程流程。同样，CR 也是一个流程流程，它始于通过 CD 交付新代码，开源工具（如 Spinnaker）为我们提供了这种能力。CR 不是监控、机器学习或自动伸缩，而是一组在代码部署后发生的各种流程，并由各种工具支持。CR 在两个特定方面也不同。

首先，它之所以不同，是因为从本质上讲，它更广泛。通用的软件开发生命周期 (SDLC) 流程意味着大多数 CI/CD 流程 都是相似的。然而，在生产环境中运行的代码因应用程序或服务而异。这意味着 CR 也不同。

其次，CR 的不同之处在于它还处于初期阶段。像之前的 CI 和 CD 一样，流程和工具在它们被命名之前就已经存在了。随着时间的推移，CI/CD 变得更加规范化，并且更容易确定范围。CR 是新的，因此有很多空间可以讨论哪些内容应该包含或排除在外。我欢迎您在这方面的评论，并希望您能继续推进这些想法。

CR：闭环 DevOps

DevOps 的出现是因为需要更高的服务交付速度和敏捷性。本质上，DevOps 是敏捷软件开发实践向运营思维模式的扩展。它是对云计算提供的灵活性和自动化可能性的直接响应。然而，迄今为止，关于 DevOps 的大部分思考都集中在将代码部署到生产环境并在那里结束。但是我们的工作并没有在那里结束。作为专业人士，我们还必须确保我们的代码按预期运行，我们在生产环境中运行时不断学习，并将学习成果带回产品开发流程。

这就是 CR 生存和发展的空间。没有 CR 的 DevOps 就像说 DevOps 流程本身周围没有 OODA 环一样。这就像说运维人员和开发人员的工作在代码部署后就结束了。我们都知道这不是真的。客户体验是我们成功的最终衡量标准。人们能否毫无障碍或不必要的摩擦地使用软件或服务？如果不能，我们需要修复它。CR 是 DevOps 链条中的最后一环，它使交付最真实的客户体验成为可能。

如果您没有考虑持续响应，那么您就不是在做 DevOps。分享您对 CR 的想法，并告诉我您对这个概念和定义的看法。 

本文基于 我们忽视的关键 DevOps 流程：持续响应，该文章最初以 CC BY 4.0 许可发布在 Cloudscaling 博客上，并经许可重新发布。