现在是关于炒作主题DevOps的话题。 持续集成和交付CI / CD的传送带由每个愿意的人实施。 但是大多数人并不总是对在CI / CD管道的各个阶段确保信息系统的可靠性给予应有的关注。 在本文中，我想谈谈我在自动化软件质量检查和实现其“自我修复”的可能方案方面的经验。

来源

我在LANIT-Integration的IT服务管理部门担任工程师。 我的核心领域是实施各种系统以监视应用程序的性能和可用性。 我经常与来自不同市场领域的IT客户交流有关监控其IT服务质量的主题问题。 主要任务是最小化发布周期时间并增加其发布频率。 当然，这一切都是好的：更多的发行版-更多的新功能-更满意的用户-更多的利润。 但实际上，并非总是一切都很好。 在非常高的部署速度下，立即出现了有关我们发布版本质量的问题。 即使使用全自动管道，最大的问题之一是服务从测试到生产的转移，这不会影响正常运行时间和用户与应用程序的交互。

根据与客户进行多次对话的结果，我可以说，在CI / CD管道的各个阶段中，发行版的质量控制，应用程序可靠性问题以及其“自我修复”（例如，回滚到稳定版本）的可能性是最令人兴奋和相关的主题。


最近，我本人在客户方面工作-从事在线银行应用程序支持服务。 我们的应用程序的体系结构使用了大量的自写微服务。 最可悲的是，并不是所有的开发人员都能应付如此高的开发速度，某些微服务的质量也因此受损，这给他们及其创造者带来了可笑的绰号。 有关于这些产品用什么材料制成的故事。

“问题陈述”

高发布频率和大量微服务使得在测试阶段和运营阶段都难以理解整个应用程序。 变化不断发生，如果没有良好的监视工具，很难控制它们。 通常，在每天晚上发布之后，开发人员坐在火药桶上，等待一切都不会中断，尽管在测试阶段所有检查都是成功的。

还有一点。 在测试阶段，将检查软件的可操作性：应用程序主要功能的执行情况以及是否存在错误。 缺乏对性能的定性评估，或者没有考虑到应用程序和集成层的所有方面。 某些指标可能根本无法检查。 结果，当在生产环境中发生故障时，技术支持部门只会发现真正的用户何时开始抱怨。 我想最大程度地减少低质量软件对最终用户的影响。

解决方案之一是在CI / CD Pipeline的各个阶段实施软件质量控制流程，添加各种脚本以在发生事故时恢复系统。 还请记住，我们有DevOps。 企业希望尽快收到新产品。 因此，我们所有的检查和脚本都必须是自动化的。

该任务分为两个部分：

• 在测试阶段对组件进行质量控制（以自动化捕获不合格组件的过程）；
• 生产环境中的软件质量控制（自动问题检测机制和可能的自我修复方案）。

监控和收集指标的工具

为了实现任务集，需要一个可以检测问题并将其转移到CI / CD管道各个阶段的自动化系统的监视系统。 同样，如果该系统为各个团队提供有用的指标（开发，测试，运营），将是一个积极的方面。 而且非常好，如果是商务的话。

要收集指标，可以组合使用不同的系统（Prometheus，ELK Stack，Zabbix等），但是我认为APM（ 应用程序性能监视 ）解决方案最适合这些任务，可以大大简化您的工作。

作为护送服务工作的一部分，我开始使用Dynatrace的APM类解决方案进行类似的项目。 现在，作为集成商，我非常了解监视系统的市场。 我的主观意见：Dynatrace最适合此类任务。
Dynatrace解决方案提供了每个用户操作的水平显示，并以深粒度显示了代码执行级别。 您可以跟踪各种信息服务之间的整个交互链：从Web和移动应用程序的前端级别，后端应用程序服务器，集成总线到对数据库的特定调用。

来源 自动构造系统组件之间的所有依赖关系

来源 自动检测和构建服务操作路径

还请记住，我们需要与各种自动化工具集成。 这里的解决方案具有便捷的API，可让您发送和接收各种指标和事件。

接下来，我们将继续更详细的讨论如何使用Dynatrace系统解决任务。

任务1.在测试阶段自动化装配质量控制

第一项任务是在应用程序交付管道的各个阶段尽早发现问题。 只有“良好”的代码构建才能到达产品环境。 为此，在测试阶段应在管道中包含其他监视器，以验证服务质量。



让我们看一下如何实现此步骤并自动执行此过程的步骤：

来源

该图显示了自动化软件质量控制步骤的流程：

1. 部署监控系统（安装代理）；
2. 定义软件质量评估事件（指标和阈值）并将其传输到监视系统；
3. 负载生成和性能测试；
4. 在监视系统中收集性能和可用性数据；
5. 将基于软件质量评估事件的测试数据从监视系统传输到CI / CD系统。 自动装配分析。

步骤1.部署监视系统

您必须首先在测试环境中安装代理。 同时，Dynatrace解决方案具有一个不错的功能-它使用安装在OS实例（Windows，Linux，AIX）上的OneAgent通用代理，自动检测您的服务并开始收集有关它们的监视数据。 您无需为每个进程分别配置代理。 对于云和容器平台，情况将类似。 同时，您也可以自动安装代理。 Dynatrace非常适合“基础架构即代码”（ Infrastructure as code ）（ 基础架构即代码或IaC ）的概念：适用于所有流行平台的现成脚本和说明。 将代理嵌入服务的配置中，然后在部署它时，您将立即使用已经运行的代理获得新服务。

步骤2.确定您的软件质量评估事件

现在，您需要确定服务和业务运营的列表。 重要的是要准确考虑那些对您的服务至关重要的用户操作。 在这里，我建议咨询业务和系统分析师。

接下来，您需要确定要在每个级别的验证中包括哪些指标。 例如，它可以是运行时（按平均数，中位数，百分位等分隔），错误（逻辑，服务，基础结构等）和各种基础结构指标（内存堆，垃圾收集器，线程数等）。

为了实现自动化和易用性，DevOps团队引入了“以代码监视”的概念。 我的意思是，开发人员/测试人员可以编写一个简单的JSON文件，该文件定义了软件质量控制的指标。

让我们看一个这样的JSON文件的示例。 Dynatrace API中的对象用作键/值对（有关API的说明，请参见Dynatrace API ）。

{    "timeseries": [    {      "timeseriesId": "service.ResponseTime",      "aggregation": "avg",      "tags": "Frontend",      "severe": 250000,      "warning": 1000000    },    {      "timeseriesId": "service.ResponseTime ",      "aggregation": "avg",      "tags": "Backend",      "severe": 4000000,      "warning": 8000000    },    {      "timeseriesId": "docker.Container.Cpu",      "aggregation": "avg",      "severe": 50,      "warning": 70    }  ] } 

该文件是时间序列定义的数组：

• timeseriesId-检查的指标，例如，响应时间，错误计数，使用的内存等；
• 聚合-指标的聚​​合级别，在我们的情况下为平均，但您可以使用所需的任何值（平均，最小，最大，总和，计数，百分位数）；
• 标签-监视系统中的对象标签，或者您可以指定特定的对象标识符；
• 严重和警告-这些指标调整了我们指标的阈值，如果测试的值超过了严重阈值，则我们的组装被标记为不成功。

下图显示了使用此类垃圾桶的示例。

来源

步骤3.负载生成

确定服务质量水平后，有必要生成测试负载。 您可以使用任何方便的测试工具，例如Jmeter，Selenium，Neodys，Gatling等。

Dynatrace监视系统使您可以从测试中捕获各种元数据，并识别哪个测试与哪个发布周期和服务有关。 建议您将其他标头添加到测试HTTP请求。

下图显示了一个示例，其中使用可选的X-Dynatrace-Test标头，我们标记该测试是指测试将项目添加到购物篮的操作。

来源

运行每个负载测试时，您将使用CI / CD服务器中的事件API将其他上下文信息发送到Dynatrace。 因此，系统可以在它们之间区分不同的测试。

来源 监视系统中有关启动负载测试的事件

步骤4-5。 收集性能数据并将数据传输到CI / CD系统

与生成的测试一起，将有关需要收集有关检查服务质量指标的数据的事件发送到监视系统。 还指出了我们的JSON文件，其中定义了关键指标。

关于需要验证CI / CD服务器上生成的软件的质量以发送给监视系统的事件

在我们的示例中，质量控制事件称为perfSigDynatraceReport （Performance_Signature ） -这是一个现成的插件，可与Jenkins集成，该插件由T-Systems多媒体解决方案的开发人员开发。 关于测试启动的每个事件都包含有关服务，内部版本号和测试时间的信息。 该插件在组装过程中收集性能值，对其进行评估，并将结果与​​以前的组装和非功能性需求进行比较。

监视系统中有关装配质量控制开始的事件。 来源

测试完成后，所有软件质量评估指标都将传输回持续集成系统，例如Jenkins，该系统会生成结果报告。

CI / CD服务器上的程序集统计结果。 来源

对于每个单独的程序集，我们将看到在整个测试过程中设置的每个指标的统计信息。 我们还查看在某些阈值（警告和严重的颠簸声）下是否存在违规行为。 根据汇总指标，将整个程序集标记为稳定，不稳定或失败。 另外，为方便起见，您可以在报表中添加指标，以比较当前装配体和上一个装配体。

查看CI / CD服务器上的详细程序集统计信息。 来源

两个组件的详细比较

如有必要，您可以转到Dynatrace界面，在其中更详细地查看每个程序集的统计信息并将它们相互比较。

Dynatrace中程序集统计信息的比较。 来源

结论

结果，我们获得了“作为服务监视”的服务，并在持续集成的过程中实现了自动化。 开发人员或测试人员只需确定JSON文件中的指标列表，其他所有操作就会自动发生。 我们对发布进行透明的质量控制：有关性能，资源消耗或体系结构退化的所有通知。

任务2.生产环境中的软件质量控制自动化

因此，我们解决了在管道测试阶段如何自动化监视过程的问题。 因此，我们将到达食品环境的劣质组件的比例降到最低。

但是，如果不良软件仍然可以达到销售点，或者出现故障，该怎么办。 对于乌托邦，我们希望拥有能够自动检测问题的机制，并且，如果可能的话，系统本身至少在晚上可以恢复其工作能力。

为此，与上一节类似，我们在生产环境中提供自动软件质量检查，并编写脚本以在其下自我修复系统。


自动修复为代码

大多数公司已经积累了各种类型的常见问题的知识库，并提供了解决问题的措施列表，例如，重新启动流程，清理资源，回滚版本，还原错误的配置更改，增加或减少集群中的组件数量，切换蓝色或绿色轮廓以及其他

尽管这些用例已经为许多我与之交流的团队所了解，但只有很少的想法并投入了他们的自动化。

如果考虑到这一点，那么在实现用于自我修复应用程序健康的流程的过程中，没有什么超级复杂的，您需要以事先针对每种情况编写的代码脚本（“代码自动更正”的概念）的形式呈现管理员的知名工作场景。 自动修复方案应解决问题的根本原因。 您可以自行设置正确的事件响应操作。

监视系统中的任何度量都可以充当运行脚本的触发器，主要是这些度量可以准确地确定一切都不好，因为我不想在生产性环境中得到误报。

您可以使用任何系统或系统集：Prometheus，ELK Stack，Zabbix等。 但是，我将基于APM解决方案给出一些示例（Dynatrace将再次成为示例），这也将使您的生活更轻松。

首先，在应用程序方面存在与可操作性相关的所有内容。 该解决方案提供了各种级别的数百个指标，您可以将其用作触发器：

• 用户级别（浏览器，移动应用程序，IoT设备，用户行为，转换等）；
• 服务和操作级别（性能，可用性，错误等）；
• 应用程序基础结构级别（主机操作系统指标，JMX，MQ，Web服务器等）；
• 平台级别（虚拟化，云，容器等）。

监控Dynatrace中的级别。 来源

其次，正如我之前所说，Dynatrace具有开放的API，这使得将其与各种第三方系统集成起来非常方便。 例如，当超过控制参数时，向自动化系统发送通知。

以下是与Ansible进行交互的示例。

来源

下面，我将给出一些示例，确切说明可以完成哪些自动化。 这只是部分情况；在您的环境中列出它们只能受到您的想象力和监视工具功能的限制。

1.错误的部署-版本回滚

即使我们都在测试环境中进行了很好的测试，新版本仍然有可能在生产环境中杀死您的应用程序。 相同的人为因素尚未取消。

在下图中，我们看到该服务上的操作的执行时间急剧增加。 该跳转的开始与应用程序的部署时间一致。 我们将所有这些信息作为事件传输到自动化系统。 如果在我们指定的时间到期后服务的可服务性未正常化，则会自动调用一个脚本，该脚本会将版本回滚到旧版本。

部署后性能下降。 来源

2.资源负载为100％-将节点添加到路由

在以下示例中，监视系统确定组件之一具有100％的CPU利用率。

CPU利用率100％

此事件可能有几种不同的情况。 例如，监视系统还检查资源的缺乏是否与服务负载的增加有关。 如果是，则执行一个脚本，该脚本会自动将节点添加到路由中，从而恢复整个系统。

事件发生后扩展节点

3.硬盘空间不足-磁盘清理

我认为其中许多流程已实现自动化。 使用APM，您还可以监视磁盘子系统上的可用空间。 在没有空间或磁盘操作缓慢的情况下，我们调用脚本来清理或添加空间。


磁盘加载100％

4.用户活动少或转化率低-在蓝色和绿色分支之间切换

我经常在生产环境中使用两个电路（蓝绿色部署）与客户见面。 这样，您可以在交付新版本时在分支之间快速切换。 通常，在部署之后，可能会发生根本不明显的基本变化。 但是，可能不会观察到性能和可用性下降。 为了快速响应此类更改，最好使用各种反映用户行为的指标（会话数和用户操作，转换，跳出率）。 下图显示了一个示例，其中当转换下降时，将在软件分支之间进行切换。

在软件分支之间切换后的转换下降。 来源

自动问题确定机制

最后，我将再举一个例子，我最喜欢Dynatrace。

在我关于测试环境中装配质量控制自动化的故事的一部分中，我们确定了手动模式下的所有阈值。 这对于测试环境是正常的，测试人员本人会在每次测试之前根据负载确定指标。 在生产环境中，希望考虑各种基线机制来自动检测问题。

Dynatrace具有有趣的内置人工智能工具，这些工具基于确定异常指标（基准）和在所有组件之间构建交互图，比较和关联事件之间的机制的机制，确定服务工作中的异常并提供有关每个问题和根本原因的详细信息。

通过自动分析组件之间的依赖关系，Dynatrace不仅可以确定问题服务是否是主要原因，还可以确定其对其他服务的依赖关系。 在下面的示例中，Dynatrace作为事务的一部分自动监视和评估每个服务的运行状况，并将Golang服务标识为主要原因。

确定故障根本原因的示例。 来源

下图显示了从事件开始监视应用程序问题的过程。

通过显示所有组件和事件来可视化新出现的问题

监控系统已编制了有关该事件的完整时间表。 在时间轴下方的窗口中，我们可以看到每个组件上的所有关键事件。 基于这些事件，您可以以代码脚本的形式指定自动更正的过程。

另外，我建议您将监视系统与Service Desk或Bug跟踪器集成。 如果发生问题，开发人员可以在生产环境中的代码级别上快速接收完整的信息以进行分析。

结论

结果，我们最终获得了CI / CD管道，并在管道中集成了集成的自动化软件质量检查。 我们将不良组件的数量减少到最低限度，提高了整个系统的可靠性，如果仍然破坏系统的性能，我们将启动恢复它的机制。


自动化软件质量监控绝对值得付出努力，虽然它并不总是一个快速的过程，但是随着时间的流逝，它将会取得成果。 我建议在解决产品环境中的新事件后，立即考虑在测试环境中添加哪些监视器以进行检查，以避免在产品中构建不良，并创建一个脚本来自动解决这些问题。

希望我的例子能对您的工作有所帮助。 我也很高兴看到您的示例，这些示例用于实施自我修复系统。

来源