现在 DevOps 的话题是炒作。 持续集成和交付管道 每个人都在实施它。 但大多数人并不总是适当注意确保 CI/CD 管道各个阶段的信息系统的可靠性。 在这篇文章中，我想谈谈我在自动化软件质量检查和实现其“自我修复”的可能场景方面的经验。
我在某公司IT服务管理部门担任工程师 。 我的核心专业领域是各种应用程序性能和可用性监控系统的实施。 我经常与来自不同细分市场的 IT 客户就监控其 IT 服务质量的当前问题进行沟通。 主要目标是最小化发布周期时间并增加发布频率。 当然，这都是好事：更多版本 - 更多新功能 - 更满意的用户 - 更多利润。 但事实上，事情并不总是一帆风顺。 由于部署率非常高，我们的版本质量立即受到质疑。 即使拥有完全自动化的管道，最大的挑战之一是将服务从测试转移到生产而不影响应用程序的正常运行时间和用户体验。
根据与客户多次交谈的结果，我可以说发布质量控制、应用程序可靠性问题及其在 CI 各个阶段“自我修复”（例如回滚到稳定版本）的可能性/CD 管道是最令人兴奋和最相关的主题之一。
最近，我自己在客户端工作——网上银行应用软件支持服务。 我们应用的架构使用了大量自写的微服务。 最可悲的是，并不是所有的开发人员都能应对高速的开发；一些微服务的质量受到影响，这给他们和他们的创建者带来了有趣的绰号。 有一些关于这些产品是由什么材料制成的故事。
“问题的表述”
高频率的发布和大量的微服务使得无论是在测试阶段还是在运营阶段都很难理解应用程序的整体运行情况。 变化不断发生，如果没有良好的监控工具，很难控制它们。 通常，在早上发布一晚的版本后，开发人员就像坐在火药桶上一样等待没有任何问题发生，尽管所有检查在测试阶段都是成功的。
还有一点。 在测试阶段，检查软件的功能：应用程序主要功能的实现以及不存在错误。 定性性能评估要么缺失，要么没有考虑应用程序和集成层的所有方面。 有些指标可能根本不会被检查。 因此，当生产环境出现故障时，技术支持部门只有在真正的用户开始抱怨时才发现问题。 我希望尽量减少低质量软件对最终用户的影响。
解决方案之一是在 CI/CD Pipeline 的各个阶段实施软件质量检查流程，并添加各种场景以在紧急情况下恢复系统。 我们还记得我们有 DevOps。 企业希望尽快收到新产品。 因此，我们所有的检查和脚本都必须自动化。
该任务分为两个部分：
- 在测试阶段对组件进行质量控制（以自动化捕获低质量组件的过程）；
- 生产环境中的软件质量控制（自动检测问题的机制及其自我修复的可能场景）。
用于监控和收集指标的工具
为了实现既定目标，需要一个监控系统来检测问题并将其传输到 CI/CD 管道各个阶段的自动化系统。 如果该系统为各个团队（开发、测试、运营）提供有用的指标，这也将是一件积极的事情。 如果也用于商业用途，那就太棒了。
要收集指标，您可以使用一组不同的系统（Prometheus、ELK Stack、Zabbix 等），但在我看来，APM 级解决方案最适合这些任务（），这可以大大简化您的生活。
作为支持服务工作的一部分，我开始使用 Dynatrace 的 APM 类解决方案做一个类似的项目。 现在，我在集成商工作，对监控系统市场非常了解。 我的主观意见：Dynatrace 最适合解决此类问题。
Dynatrace 提供每个用户操作的水平视图，粒度级别一直到代码执行级别。 您可以跟踪各种信息服务之间的整个交互链：从 Web 和移动应用程序的前端级别、后端应用程序服务器、集成总线到对数据库的特定调用。
。 自动构建系统组件之间的所有依赖关系
。 服务运行路径自动检测与构建
我们还记得我们需要与各种自动化工具集成。 这里的解决方案有一个方便的 API，允许您发送和接收各种指标和事件。
接下来，让我们更详细地了解如何使用 Dynatrace 系统解决这些问题。
任务 1. 测试阶段组件质量控制的自动化
第一个挑战是尽早发现应用程序交付管道中的问题。 只有“好的”代码构建才能投入生产。 为此，测试阶段的管道应包含额外的监视器来检查服务质量。
让我们逐步了解如何实现此过程并自动化此过程：
下图显示了自动化软件质量测试步骤的流程：
- 部署监控系统（安装代理）；
- 识别用于评估软件质量的事件（指标和阈值）并将其传输到监控系统；
- 生成负载和性能测试；
- 收集监控系统中的性能和可用性数据；
- 基于软件质量评估事件的测试数据从监控系统传输到 CI/CD 系统。 装配体的自动分析。
步骤一、监控系统部署
首先，您需要在测试环境中安装代理。 同时，Dynatrace 解决方案有一个很好的功能 - 它使用安装在操作系统实例（Windows、Linux、AIX）上的通用代理 OneAgent，自动检测您的服务并开始收集它们的监控数据。 您不需要为每个进程配置单独的代理。 云平台和容器平台的情况类似。 同时，您还可以自动化代理安装过程。 Dynatrace 完美契合“基础设施即代码”概念（)：有适用于所有流行平台的现成脚本和说明。 您将代理嵌入到服务的配置中，当您部署它时，您会立即收到具有已工作代理的新服务。
第 2 步：定义软件质量事件
现在您需要决定服务和业务运营的列表。 准确考虑那些对您的服务至关重要的用户操作非常重要。 在这里我建议咨询业务和系统分析师。
接下来，您需要确定要在每个级别的审核中包含哪些指标。 例如，这可以是执行时间（分为平均值、中位数、百分位数等）、错误（逻辑、服务、基础设施等）和各种基础设施指标（内存堆、垃圾收集器、线程计数等）。
为了 DevOps 团队的自动化和易用性，出现了“Monitoring as Code”的概念。 我的意思是，开发人员/测试人员可以编写一个简单的 JSON 文件来定义软件质量保证指标。
让我们看一下此类 JSON 文件的示例。 Dynatrace API 中的对象用作键/值对（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 – 正在检查的指标，例如响应时间、错误计数、使用的内存等；
- 聚合 - 指标聚合的级别，在我们的例子中为 avg，但您可以使用您需要的任何一个（avg、min、max、sum、count、percentile）；
- Tags – 监控系统中的对象标签，也可以指定特定的对象标识符；
- 严重和警告——这些指标调节我们指标的阈值；如果测试值超过严重阈值，那么我们的构建被标记为不成功。
下图显示了使用此类阈值的示例。
第 3 步：负载生成
一旦我们确定了服务的质量水平，我们就需要生成测试负载。 您可以使用任何您熟悉的测试工具，例如 Jmeter、Selenium、Neotys、Gadling 等。
Dynatrace 的监控系统允许您从测试中捕获各种元数据，并识别哪些测试属于哪个发布周期和哪个服务。 建议向 HTTP 测试请求添加额外的标头。
下图显示了一个示例，其中使用附加标头 X-Dynatrace-Test，我们表明此测试与测试将商品添加到购物车的操作相关。
当您运行每个负载测试时，您可以使用 CI/CD 服务器中的事件 API 将其他上下文信息发送到 Dynatrace。 这样，系统就可以区分不同的测试。
。 监控系统中有关负载测试开始的事件
步骤 4-5。 收集性能数据并将数据传输到 CI/CD 系统
与生成的测试一起，将需要收集有关检查服务质量指标的数据的事件传输到监控系统。 它还指定了我们的 JSON 文件，该文件定义了关键指标。
关于需要检查 CI/CD 服务器上生成的软件质量以发送到监控系统的事件
在我们的示例中，质量检查事件称为 perfSigDynatrace报告 （性能_签名) - 这是准备好了 用于与 Jenkins 集成，Jenkins 是由 T-Systems Multimedia Solutions 的人员开发的。 每个测试启动事件都包含有关服务、版本号和测试时间的信息。 该插件在构建时收集性能值，对其进行评估，并将结果与之前的构建和非功能需求进行比较。
监控系统中有关构建质量检查开始的事件。
测试完成后，所有评估软件质量的指标都会传输回持续集成系统，例如Jenkins，生成结果报告。
CI/CD服务器上程序集的统计结果。
对于每个单独的构建，我们都会看到在整个测试过程中设置的每个指标的统计数据。 我们还查看是否存在违反某些阈值（警告和严重阈值）的情况。 根据聚合指标，整个构建被标记为稳定、不稳定或失败。 此外，为了方便起见，您可以将指标添加到报告中，将当前版本与前一版本进行比较。
查看 CI/CD 服务器上程序集的详细统计信息。
两个组件的详细比较
如有必要，您可以转到 Dynatrace 界面，在那里您可以更详细地查看每个构建的统计信息并将它们相互比较。
Dynatrace 中构建统计数据的比较。
发现
因此，我们获得了“监控即服务”服务，在持续集成管道中实现自动化。 开发人员或测试人员只需在 JSON 文件中定义指标列表，其他一切都会自动发生。 我们收到透明的版本质量控制：有关性能、资源消耗或架构回归的所有通知。
任务 2. 生产环境中软件质量控制的自动化
这样，我们就解决了如何在Pipeline中自动化测试阶段的监控过程的问题。 通过这种方式，我们可以最大限度地减少进入生产环境的低质量组件的百分比。
但是，如果不良软件最终被出售，或者某些东西坏了，该怎么办？ 对于乌托邦，我们希望有自动检测问题的机制，如果可能的话，系统本身可以恢复其功能，至少在晚上。
为此，类比上一节，我们需要在生产环境中提供自动的软件质量检查，并基于场景进行系统自愈。
自动更正为代码
大多数公司已经积累了各类常见问题的知识库以及解决这些问题的操作列表，例如重新启动进程、清理资源、回滚版本、恢复无效的配置更改、增加或减少组件的数量。集群，切换蓝色或绿色轮廓等。
虽然与我交谈过的许多团队多年来都知道这些用例，但很少有人考虑或投资于自动化它们。
如果您考虑一下，实现自我修复应用程序性能的流程并没有什么太复杂的；您需要以代码脚本的形式呈现管理员已知的工作场景（“自动修复为代码”概念） ，您针对每个具体案例提前编写了该内容。 自动修复脚本的目的应该是消除问题的根本原因。 您自己决定应对事件的正确行动。
监控系统中的任何指标都可以作为启动脚本的触发器，最主要的是这些指标可以准确地确定一切都不好，因为您不希望在生产环境中出现误报。
您可以使用任何系统或系统集：Prometheus、ELK Stack、Zabbix 等。 但我将给出一些基于 APM 解决方案的示例（Dynatrace 将再次作为示例），这也将有助于让您的生活更轻松。
首先，就应用程序操作而言，一切都与性能相关。 该解决方案提供了数百个不同级别的指标，您可以将其用作触发器：
- 用户级别（浏览器、移动应用程序、物联网设备、用户行为、转化等）；
- 服务和操作水平（性能、可用性、错误等）；
- 应用程序基础设施级别（主机操作系统指标、JMX、MQ、Web 服务器等）；
- 平台级别（虚拟化、云、容器等）。
Dynatrace 中的监控级别。
其次，正如我之前所说，Dynatrace拥有开放的API，这使得它非常容易与各种第三方系统集成。 例如，当超出控制参数时向自动化系统发送通知。
下面是与 Ansible 交互的示例。
下面我将举几个例子来说明可以进行什么样的自动化。 这只是案例的一部分；您环境中的案例列表仅受您的想象力和监控工具功能的限制。
1. 错误部署 – 版本回滚
即使我们在测试环境中对所有内容进行了很好的测试，新版本仍然有可能在生产环境中杀死您的应用程序。 同样的人为因素并没有被取消。
在下图中我们看到服务上的操作的执行时间出现了急剧的跳跃。 此跳转的开始时间与部署到应用程序的时间一致。 我们将所有这些信息作为事件传输到自动化系统。 如果在我们设置的时间之后服务的性能没有恢复正常，则会自动调用一个脚本将版本回滚到旧版本。
部署后操作性能下降。
2.资源加载100%——添加节点到路由
在以下示例中，监控系统确定其中一个组件正在经历 100% CPU 负载。
CPU负载100%
此事件可能有几种不同的场景。 例如，监控系统另外检查资源缺乏是否与服务负载的增加相关。 如果是这样，则执行一个脚本，自动将节点添加到路由中，从而恢复整个系统的功能。
事件发生后扩展
3.硬盘空间不足——磁盘清理
我认为很多人已经自动化了这些过程。 使用 APM，您还可以监视磁盘子系统上的可用空间。 如果没有空间或者磁盘运行缓慢，我们调用脚本来清理它或者添加空间。
光盘负载 100%
4. 用户活跃度低或转化率低——在蓝色和绿色分支之间切换
我经常看到客户在生产环境中对应用程序使用两个循环（蓝绿部署）。 这使您可以在交付新版本时在分支之间快速切换。 通常，部署后，可能会发生无法立即注意到的巨大变化。 在这种情况下，可能不会观察到性能和可用性的下降。 为了快速响应此类变化，最好使用反映用户行为的各种指标（会话和用户操作数、转化率、跳出率）。 下图显示了一个示例，其中当转换率下降时，会发生软件分支之间的切换。
在软件分支之间切换后，转换率会下降。
自动问题检测机制
最后，我再举一个例子来说明为什么我最喜欢 Dynatrace。
在我的故事中关于在测试环境中自动进行组件质量检查的部分中，我们手动确定了所有阈值。 这对于测试环境来说是正常的；测试人员在每次测试前根据负载自行确定指标。 在生产环境中，希望能够自动检测问题，同时考虑各种基线机制。
Dynatrace 具有有趣的内置人工智能工具，这些工具基于确定异常指标（基线）和构建所有组件之间的交互图、相互比较和关联事件的机制，确定服务运行中的异常情况并提供详细信息有关每个问题和根本原因的信息。
通过自动分析组件之间的依赖关系，Dynatrace 不仅可以确定有问题的服务是否是根本原因，还可以确定其对其他服务的依赖关系。 在下面的示例中，Dynatrace 自动监控和评估事务执行中每个服务的运行状况，将 Golang 服务识别为根本原因。
确定故障根本原因的示例。
下图显示了从事件开始时监控应用程序问题的过程。
通过显示所有组件和事件来可视化新出现的问题
监控系统收集了与所出现问题相关的完整事件年表。 在时间线下方的窗口中，我们可以看到每个组件上的所有关键事件。 根据这些事件，您可以以代码脚本的形式设置自动更正的过程。
此外，我建议您将监控系统与服务台或错误跟踪器集成。 当问题发生时，开发人员可以快速收到完整的信息，以便在生产环境中进行代码级别的分析。
结论
结果，我们最终得到了一个 CI/CD 管道，在 Pipeline 中内置了自动化软件质量检查。 我们最大限度地减少低质量组件的数量，提高整个系统的可靠性，如果我们的系统仍然出现故障，我们会启动恢复机制。
自动化软件质量监控绝对值得投入精力；这并不总是一个快速的过程，但随着时间的推移，它会取得成果。 我建议在生产环境中解决新事件后，您立即考虑在测试环境中添加哪些监视器进行检查，以避免错误的构建进入生产环境，并创建一个脚本来自动纠正这些问题。
我希望我的例子对您的努力有所帮助。 我也有兴趣查看您用于实现自我修复系统的指标示例。
来源： habr.com