4. 配置基线建立方法
在AVEVA系统（如AVEVA System Platform、AVEVA Historian、AVEVA InTouch等）的版本变更治理中，配置基线是后续一切变更比对、回滚和审计的参照原点。没有基线，变更就失去了"与什么比较"的基准，版本治理也就无从谈起。本节围绕初始配置基线的建立，讲清基线范围如何界定、版本快照如何生成、文档记录如何组织，以及审批流程如何落地。
一、基线范围：先划清"哪些配置进基线"
AVEVA系统的配置对象分布在不同层级，如果范围不清，基线要么过于庞大难以维护，要么遗漏关键对象导致比对失真。建议按"平台层—应用层—实例层"三层界定范围。
平台层包括：Galaxy（System Platform的全局命名空间）的部署配置、安全模型（用户、角色、权限组）、通信配置（DAServer、DI Object、OPC连接）、系统参数（历史归档周期、报警优先级定义）。应用层包括：Application Object模板（如$UserDefined、$Pump等派生模板）、图形模板（Symbol、Faceplate）、脚本库（QuickScript、Automation Object脚本）。实例层包括：具体部署的Object实例及其属性绑定、区域（Area）划分、部署关系（Deployment）与冗余配置。
一个实用的判断标准是：凡是变更后会影响系统运行行为、数据采集、画面显示或安全控制的配置项，都应纳入基线范围。而临时调试参数、测试用对象、未部署的草稿模板，则明确排除，避免基线被噪声污染。
二、版本快照：如何生成可回溯的配置快照
AVEVA System Platform提供了多种导出机制，基线快照应优先使用官方导出工具，保证可回导、可比对。常用方式包括：
- Galaxy导出（Galaxy Dump / Export）：通过IDE的"Export Galaxy"或命令行工具导出整个Galaxy为.aaPKG或.xml文件，包含对象、模板、脚本、安全配置。适合作为全量基线。
- 对象级导出：对关键Object或模板单独导出，便于局部比对，但需注意依赖关系（如模板依赖的脚本库）是否一并导出。
- 数据库快照：对Historian的配置库、SQL Server中的配置表执行备份，记录备份时间点与数据库版本。
- 文件级快照：对图形文件（.g、.gfx）、脚本文件、配置文件（如DAServer的.cfg）做版本归档。
快照生成后，必须记录快照标识，建议采用"系统名-基线版本-日期-序号"格式，例如 SP_Prod_Base_V1.0_20250612_001。同时记录导出工具版本、导出耗时、文件大小与校验值（如SHA-256），用于验证快照完整性。
# 示例：Galaxy导出命令（示意，实际参数以现场版本为准）
aaGalaxyExport.exe -Galaxy "ProdGalaxy" -Output "D:\Baseline\SP_Prod_Base_V1.0_20250612_001.aaPKG" -IncludeSecurity -IncludeTemplates
# 生成校验值
certutil -hashfile "D:\Baseline\SP_Prod_Base_V1.0_20250612_001.aaPKG" SHA256快照不是"导完就完"，还需要做一次可回导验证：在隔离的测试Galaxy中尝试导入，确认无报错、对象数量与预期一致。这一步能提前暴露依赖缺失或权限问题，避免基线在真正回滚时失效。
三、文档记录：让基线"可读、可查、可追溯"
快照文件本身是二进制或XML，无法直接回答"这次基线包含什么、为什么这样定"。因此必须配套文档记录。建议至少包含以下内容：
- 基线清单：逐项列出纳入基线的对象、模板、脚本、配置文件及其版本号/导出时间。
- 环境说明：Galaxy名称、平台版本、补丁级别、数据库版本、部署拓扑（单机/冗余/多节点）。
- 变更历史：从上一基线到本基线之间的所有变更记录，包括变更单号、变更人、变更内容、验证结果。
- 回滚说明：回滚步骤、依赖条件、预计停机时间、回滚后需执行的验证项。
- 审批记录：审批人、审批时间、审批意见、批准版本号。
文档建议与快照文件存放在同一受控目录，命名与快照标识对应，例如 SP_Prod_Base_V1.0_20250612_001_基线清单.xlsx。这样任何人在拿到快照时，都能立即找到对应的说明文档。
四、审批流程：从"技术完成"到"正式生效"
基线建立不是纯技术动作，必须经过审批才能正式生效。审批流程的核心是职责分离与可追溯。一个可落地的流程如下：
- 编制：由系统工程师完成快照导出、文档编写，提交《基线建立申请》。
- 技术审核：由资深工程师或架构师审核基线范围是否完整、快照是否可回导、文档是否齐全。
- 变更管理审核：由变更管理负责人确认本次基线是否与已批准的变更单一致，是否存在未授权变更。
- 批准：由系统负责人或运维经理批准，基线版本号正式生效。
- 发布与归档：将快照与文档归档至受控库，通知相关团队基线已生效，后续变更均以该基线为比对基准。
五、基线建立的关键检查点
为便于执行，可将上述内容浓缩为一张检查表，在每次建立基线时逐项确认：
| 检查项 | 判断标准 | 记录方式 |
|---|---|---|
| 基线范围 | 平台层、应用层、实例层均已界定，纳入/排除理由明确 | 《基线范围界定表》 |
| 快照完整性 | 导出无报错，文件校验值已记录，可回导验证通过 | 导出日志+校验值+回导记录 |
| 文档齐全 | 清单、环境说明、变更历史、回滚说明、审批记录齐全 | 受控目录文档包 |
| 审批闭环 | 编制、技术审核、变更审核、批准四级签字完整 | 审批单/电子流 |
| 版本标识 | 快照标识唯一，与文档命名一致，已登记至基线台账 | 基线台账 |
完成上述四步后，系统就拥有了一个可回导、可比对、可审计的初始配置基线。后续任何变更，都应先与基线比对，确认差异范围，再走变更流程。基线本身也需要定期复审——当系统经历重大升级、架构调整或累积变更达到一定规模时，应重新建立新版本基线，旧基线保留归档，形成连续的基线演进链。