Evolven“发布验证”服务，为IT部署的成功保驾护航

时间：2024-07-28

特约通讯员梁晓欢

特约通讯员梁晓欢

挑战：任何微小的错误配置都会危及一项发布的成功

在IT运营领域中，许多原因都会导致部署的错误和不准确，实际运营中常见的变更出现情境包括以下四类：

●变更未能在生产阶段得到实现

●灾备失败后的恢复工作

●部署过程中的变更遗漏

●自动部署脚本中的一个错误参数，造成的配置错误

在一个高节奏的环境中，会有大量的参数发生变化，这使得对错误的检测和确定工作变得非常繁重。即使我们可以列出所有的变更，要找出到底是哪一个变更，或哪一些变更导致了部署的失败，也是非常困难的，需要花费大量的时间和精力，效率非常低。因此，要确保部署的成功，就必须进行发布验证。发布是IT日常运营的一部分，尤其是随着越来越多的企业开始采用敏捷的管理方法和持续交付的经营模式，发布的完整性变得愈加重要。有许多问题都会影响到发布的完整性，例如，失败的变更部署，不同环境之间固有的差异，缺乏对系统变更的整体视图等。

为了处理属性配置，应用程序文件，数据库架构以及其它环境资源中所可能产生的各种变更，IT运营必须确保发布可以得到智能的验证。这意味着在发布的整个生命周期中，从测试到生产,我们都能可以捕捉到所有的变更，并对这些变更进行分析，以确保发布的准确、完整和合法。

解决方案：自动验证，以实现精确部署

在IT运营中，贯穿应用程序整个生命周期的发布验证，可以帮助我们提高发布的完整性。发布验证过程应解决以下两类问题：

●环境之间固有的内在差异

●预期的部署结果与实际部署之间的偏差

然而，借助于Evolven公司的“发布验证”服务，就可以成功地避免这两类问题。在具体实践中，需要将Evolven平台系统集成到以下的操作步骤中：

(1)比较基线环境；

(2)修复有害的差异；

(3)部署；

(4)检查目标环境中类似服务器部署的一致性，以及目标环境和先前的环境之间的连续性，例如，生产时的环境vs验证时的环境；

(5)分析结果，以确定有待修复的不一致性；

(6)回顾发布中针对风险性变更而准备的物料清单。

尽管步骤2和步骤3是在部署之前就进行的，扮演着事先检查的角色，但还是需要对环境之间的一致性进行持续的评估，将其作为一项定期的健康检查，以确保生产之前的环境能够充分地代表生产时的环境。

比较基线环境

存在时间很长的环境，会发生自然的漂移。通过对基线环境进行比较，IT工作人员可以提高其识别由环境漂移所引致的风险的能力。这一步骤可以清楚地显示环境一致性确认的过程中哪一阶段容易失控。

安装了Evolven代理之后，IT运营可以捕获当前运行环境配置的准确情况。然后，IT运营商就可以对不同集合的环境进行比较，从而能够主动地防止漂移：

●生产服务器相互比较

●验收服务器相互比较

●验收和生产之间的比较

●使用相同的方法，对生产前的环境和测试时的环境进行比较

修复有害的差异

生产服务器与测试服务器比较图

检查系统发生的更改示例图

完成了上述的比较工作之后，就可以为IT运营提供所有的差异情况。这些结果可以传递给不同的运营专家，以便审阅。针对环境类别，将差异情况进行细分，从而让IT管理者可以为各个不同专家团队（数据库管理员，系统管理员，应用程序服务器管理员等），创建单独的差异情况集。然后，他们就可以设定哪些差异是预期会发生的，哪些差异是需要修复的。通过这一设定工作，就产生了三组数据差异集：有待修复的差异、预期的差异、可忽略的差异。

需要强调的是，针对出现的差异，所进行的第一次分析是最为重要的。一旦建立了初步的评估之后，后续的工作，就只要对新出现的差异进行审查，然后将审查结果添加到已有的差异分析结果中。

部署

随着环境校准的完成，环境就做好了部署的准备。由于Evolven代理已经实现了部署，因此它们可以自动收集所有的差异情况。

在使用自动部署工具时，可以将Evolven集成到部署脚本中。要完成这一工作，需要增加一项Evolven扫描和报告操作，以作为部署的最后一步。在不使用自动化部署工具时，可以根据部署时间，让Evolven运行部署报告。

检查一致性

作为部署的一部分，一致性检查报告会跟踪所有的变化情况，从而帮助IT确定所有的变化都是一致的。

对于运营专家来说，审查跟踪是非常有用的。他们每个人都可以查看他们负责的组件中（应用服务器，数据库，应用程序）所发生的一切变化，从而确保在每一阶段，都只发生了所需要的更改。由于Evolven代理对所有的变化都进行了跟踪，因此报告首先将显示的信息就是所有发生更改的参数，这些参数的过去值和当前值。

此外，发布经理也可以进行一致性检查。一致性检查工作包含两类内容：两个环境之间的一致性,一个环境内部的一致性。针对不同的环境，应分别建立分析方案。分析方案中创建的指令，可以确定哪些环境会进入一致性检查。

一致性检查按实现方式可以分为两类，一类是通过自动部署实现的一致性检查，另一类是通过手动部署实现的一致性检查。自动部署的方式，就是将部署脚本添加到初始的一致性检查结果中，从而创建一个完全自动化的，能够自我验证的部署过程。通过一个应用程序接口，部署脚本就可以启动一致性检查，扫描服务器发生的所有的更改内容，将检查报告邮件发送至相关人员，或储存至本地文件系统。而在以手动部署实现的一致性检查中，进行实际部署的工程师必须清楚地认识到，部署的最后一个阶段是运行一致性检查。他们在登陆应用程序之后，对当前的配置进行扫描和刷新，然后运行一致性检查，以确定哪些变更是一致的，哪些不是。检查结果可以显示在Evolven的用户界面中，或将其导出形成报告。

修复

一致性检查的结果可以被划分为：

●一致的变更：这一类更改都以同样的方式被部署到所有的服务器上。

●不一致的变更：这一类更改，在不同的服务器上有不同的值。

不一致的变更应由部署经理进行审查。一致性检查报告应显示同一环境中以及不同环境之间的一致性更改。正如在基线环境比较这一步骤中所描述的，检查结果应该被划分为待修复的差异，预期的差异和可忽略的差异这三部分。

分析结果

要对一组结果进行分析，并不是一项简单的任务。在这里，可以通过运用一些重要的经验法则，减少列表浏览时间，并放大关键性的差异。

●关键参数

借助于Evolven的内置知识库，参数被分别归类，因此，搜索可以通过审查那些被标为关键性的参数开始。

●自动分组

自动分组是一个非常强大的工具，它可以帮助工作人员同时对多个对象进行快速地浏览和审查，并且根据相似性将一整列的更改和差异划分为不同的小组。搜索工作的重点是那些较小的组，因为它们的参数非常的显著，具有最大的危害性。自动分组工具可以循环使用，将大的分组划分为较小的，特别侧重于那些具有更多异常参数、以及没有相似更改的小组。

●不断更新的预期差异列表

在审查结果时，遇到不一致之处，则应将其标记为预期的差异。预期差异是指那些包含本地IP地址、计算机名称、域名等信息的差异。之所以将这些差异称为可预期的差异，是因为这些值的不同是由设计本身所造成的。每进行一次一致性检查，就会产生一个更清楚的报告。

●处理重写配置

在将参数标记为预期参数后，将会产生一个警告，是否溢出相同的值。一旦所有的预期差异都按这样标记，那就只剩下有待修复的差异。在理想的情况下，管理员希望可以修复所有余下的差异，但在实践中，有些差异可以忽略，因此，差异可以按类别得到不同的处理。