什么是持续验证?
什么是持续验证?
持续验证是在部署后监控应用程序异常的过程。异常是指任何可能影响应用程序用户的正常操作中断，包括:
- 高响应延迟
- 服务器端错误
- 客户端错误
- 任何应用程序组件的停机时间
- 意外的扩展或故障转移事件
持续验证背后的思想是从历史部署中收集数据，通过机器学习进行分析，并创建良好部署的基线。这允许持续验证系统识别出某些地方不正确并采取纠正措施——例如，将应用程序回滚到稳定版本。这应该在客户意识到问题之前尽可能快速和顺利地完成。
这是我们系列文章的一部分GitOps．
在本文中:
为什么持续验证很重要?
当分别编写代码的不同软件工程师有不同的期望时，所产生的代码组合就会产生问题。如果开发团队能够快速识别这些问题，他们就可以在编写的下一个代码中防止类似的漏洞。然而，如果期望差距仍然没有解决，每次代码编写可能会进一步偏离，增加不希望出现的结果的可能性。
持续集成的优势
发现不同开发人员的不同期望的一种方法是组合他们的代码并一起运行。持续集成(CI)等敏捷方法可以帮助实现这一点。团队可以使用集成测试来测试来自不同开发人员的组合代码特性的特定功能。
CI管道需要将所有代码编辑发布到一个公共存储库，在该存储库中，开发团队可以运行集成测试来识别破坏应用程序的更改。CI的快速反馈循环使软件更改更容易可逆—开发人员可以快速应用新更改、测试它们，并在必要时恢复更改。可逆性对于有多个团队在一个联合项目中工作的复杂系统尤其重要。
连续交付的优势
持续交付(CD)将CI的优势引入到开发周期的下一个阶段。CD侧重于自动化，为在生产环境中部署准备代码。软件工程师可以使用CD工具选择已经通过CI阶段的构建，交付它们以促进生产。
CD为开发人员提供了另一个反馈循环，提供了关于在生产环境中运行时代码更改如何执行的见解。这种方法支持频繁部署，可以更容易地解决期望差距。它们不太容易破裂，因为它们更有可能赶上额外的预期差距。CI/CD现在是一个行业规范。
持续验证作为CI/CD的延伸
持续验证(CV)可以看作是CI/CD既定实践的延伸。它是一种新的实践，涉及到主动实验，由验证系统行为的工具支持。验证不同于验证——前者处理业务结果，后者强调软件正确性。
CV与传统的质量保证实践不同，后者倾向于使用软件验证方法来寻找已知属性的反应性测试。其他常见的验证方法包括监控、警报、代码测试和评审以及站点可靠性工程(SRE)。虽然这些实践仍然很有用(并且很常见)，但是CV为解决复杂系统的特定挑战提供了额外的功能。
持续核查的重要优点包括:
- 主动优化系统属性。
- 实验(而不是测试)。
- 灵活性和可伸缩性。
复杂的系统具有开放性和不断的发展，需要一种不同的方法来理解已知的软件属性(即输出约束)。像CI/CD一样，持续验证解决了在复杂计算系统中导航的需求。
持续验证并没有引入新的软件工程范式——它只是集成了类似解决方案的开发实践。雷电竞官网进入主要的区别在于CD改变了组织对应用程序开发和操作的看法。DevOps团队可以验证系统输出，而不是验证系统的内部机制——关注性能而不是结构。这种方法节省了时间和资源，随着系统变得越来越复杂，这一点变雷竞技rabet官网得越来越重要。
云的持续验证
云服务提供商通常提供各种监控和警报服务，以帮助检测错误配置问题和漏洞。然而，大多数监控系统提供回顾性警报，安全团队可能无法及时看到以防止损坏。它们还可能无法提供对安全问题根源的充分可见性。当开发人员应用修复程序时，它们可能无效或影响功能或其他云资产。
当使用多个csp时，不同云系统的不兼容性可能会加剧安全问题。安全性可能难以查看上下文或处理大量误报。持续验证通过从部署开始跟踪资产来帮助解决这些挑战。
CV要求在部署后主动监控云资产，以识别整个生命周期内的安全问题。连接到云资产的代理根据已建立的策略不断检查其性能和配置，以识别异常行为。此策略可减轻云数据泄露，并提供跨云环境对组织资产的全面可见性。
持续验证将安全问题视为相互关联的资产清单的一部分，而不是孤立的事件。一个资产的问题可能会影响其他资产。安全团队应该将CV与基于策略的自动化结合起来，以便对安全问题应用预定的响应。此设置可以在检测到可疑活动时自动撤销用户访问。
CV还可以将安全流程集成到开发管道中，以加速部署。它可以在早期阶段识别漏洞，从而实现更快、更容易的解决方案。
持续验证策略
SRE团队可以对他们的开发管道应用持续验证原则，以阻止在开发和集成阶段显示质量问题的软件交付。他们还可以使用这种方法来评估新部署后的产品健康状况，并确定是要推出还是回滚新软件版本。
下面是一些简历策略的例子:
使用工件存储库
工件存储库充当CI和CD管道之间的技术契约。CI管道提供了用于生成工件的结构化机制，团队可以稍后将其存储在工件存储库中。可以安全地假设应用程序已经为存储在存储库中的任何工件完全构建和打包。存储的工件必须通过使用静态代码分析、单元测试等进行的漏洞检查和测试覆盖率验证。
检查管路
在管道将工件转移到生产环境之前，重要的是要确保传输管道是可靠的，并且能够处理频繁的交付。增加自动化验证任务的总体覆盖率，SRE团队可以加速交付过程，并确保软件按时到达生产环境。
管道中的每个阶段都应该包括验证。例如，发展阶段应包括:
- 功能验证(例如，以组件测试的形式)
- 部署策略验证
- 可靠性验证(即集成环境中的各个方面)
质量检验关
由事件日志和可见性解决方案提供的数据通常提供质量闸门(即，度量标准通知质量执行)。雷电竞官网进入机器学习算法或定义的阈值提供了通过或不通过每个质量门的标准。使用机器学习算法来处理日志事件和可观察性数据，允许分析人员将应用程序的实际状态与定义的状态(即性能、功能等的正常基线)进行比较。
这种类型的验证通常取决于所使用的部署策略。例如，在金丝雀部署中，在新实例中应用质量门来识别质量回归是有用的，而在旧实例中则没有。
在管道的早期阶段，质量检验关可以验证数据库迁移和应用程序启动是否成功。在集成阶段，质量检验关应该关注基于系统应用负载的回归测试——例如，自动化的性能或功能测试。
每个额外的质量闸门都会抑制管道的吞吐量，因为需要更多的人工审批。如果需要快速地将特性发布到生产环境中，那么可能就需要调整或重构管道。为了使这种方法有效，SRE团队必须高度熟练，可观测性工具必须高度成熟。
