2. 升级前环境资产盘点
Teamcenter 升级迁移项目失败，十有八九不是败在安装介质或升级脚本上，而是败在“不知道自己有什么”。升级前环境资产盘点的目标，是把一套运行多年的 Teamcenter 环境从“口口相传的隐性知识”变成“可核对、可交接、可回滚的显性清单”。盘点的产出不是一份好看的文档，而是一组能直接支撑升级方案设计、停机窗口估算、回滚预案和许可证续期的结构化数据。
一、盘点对象的七个维度
Teamcenter 环境资产可以按七个维度切分，每个维度都有独立的采集方式和核对要点：
- 服务器与操作系统：物理机、虚拟机、容器节点的主机名、IP、OS 版本、CPU/内存/磁盘、时区、主机名解析关系。升级常因 OS 版本过低（如仍为 RHEL 6/CentOS 6）而被迫先做 OS 升级。
- 数据库：Oracle/SQL Server 的版本、补丁号、字符集、实例名、表空间、归档模式、RAC 或单实例、DB Link。Teamcenter 各版本对数据库版本有硬性矩阵要求。
- 应用服务器（TC Server）：TC 版本与补丁、J2EE 容器（WebLogic/WebSphere）、部署的 TEM 模板、Pool Manager 配置、FMS 配置、TC_DATA 与 TC_ROOT 路径。
- 卷（Volume）：每个 Volume 的 ID、类型（Native/Managed）、物理路径、容量、当前使用率、是否跨挂载点、是否与 FSC 共享存储。
- FSC（File Server Cache）：FSC 服务数量、每台 FSC 的缓存目录、缓存大小、与 Volume 的映射关系、传输协议（HTTP/HTTPS）、FSC 与 TC Server 的连通性。
- Web 层：Web 服务器类型（IIS/Apache/WebLogic 代理）、端口、SSL 证书、负载均衡策略、AJP/反向代理配置、单点登录（SSO）集成方式。
- 集成接口与许可证：与 ERP/MES/CAD 的集成方式（SOA、T4S、Active Workspace、自定义 Web Service）、接口清单、调用频率；许可证服务器（License Server）地址、许可证文件、已用/可用席位、到期时间。
二、清单化方法：从采集到核对
盘点不是“打开管理界面抄一遍”，而是要有可复现的采集路径。推荐采用“自动采集为主、人工核对为辅”的方式：
- 自动采集：通过 TC 自带的
install_config_info、fmsadmin、volume_info等工具导出配置；数据库侧用SELECT * FROM V$VERSION、sp_helpdb等语句获取版本与实例信息；OS 侧用uname -a、hostnamectl、df -h采集主机与磁盘信息。 - 人工核对：自动采集容易遗漏“非标准配置”，例如手工添加的 FSC、临时挂载的 Volume、未登记的集成接口。需要与运维、开发、业务三方交叉确认。
- 建立唯一标识：每台服务器、每个 Volume、每个 FSC 都要有唯一 ID，并与 CMDB 或资产台账对齐，避免升级时“同名不同机”或“同机不同名”。
- 标注依赖关系：明确“谁依赖谁”，例如 Web 层依赖 TC Server，TC Server 依赖数据库和 FSC，FSC 依赖 Volume。依赖关系是停机顺序和回滚顺序的依据。
盘点时建议同步记录“当前状态”与“目标状态”两列。例如当前数据库为 Oracle 11.2.0.4，目标为 19c；当前 TC 为 11.6，目标为 14.1。两列之间的差距就是升级工作量。
三、关键参数与判断依据
盘点过程中，以下参数直接决定升级方案是否可行：
| 对象 | 关键参数 | 判断依据 |
|---|---|---|
| 数据库 | 版本、补丁、字符集、归档模式 | 是否满足目标 TC 版本的数据库矩阵；归档模式是否开启以支持回滚 |
| 应用服务器 | TC 版本、J2EE 容器版本、JDK 版本 | 目标 TC 版本是否支持当前容器与 JDK；是否需要先升级中间件 |
| 卷 | 使用率、剩余空间、挂载点 | 升级过程中需要额外空间存放备份与临时文件，建议预留 30% 以上 |
| FSC | 缓存大小、命中率、网络带宽 | 升级后文件访问量可能变化，需评估 FSC 是否扩容或迁移 |
| Web 层 | SSL 证书有效期、端口、代理配置 | 证书过期会导致升级后无法访问；端口冲突需提前规划 |
| 许可证 | 到期时间、席位数量、License Server 地址 | 升级后 TC 版本变化可能导致许可证不兼容，需提前续期或更换 |
四、盘点结果的可视化与交接
盘点结果最终要形成一张“环境资产拓扑图”，让升级团队一眼看清各组件的位置、连接和依赖。下图展示了一个典型 Teamcenter 环境的资产拓扑与依赖关系，包含服务器、数据库、TC Server、Volume、FSC、Web 层、集成接口和许可证服务器：
这张拓扑图的价值在于：升级前可以按图核对每个节点是否已纳入清单；升级中可以按依赖关系确定停机顺序（先停 Web 层，再停 TC Server，最后停数据库）；升级后可以按图逐项验证连通性。建议将拓扑图与资产清单表格配套使用，表格记录详细参数，拓扑图记录关系与位置。
五、盘点交付物示例
盘点完成后，至少应交付以下三份材料：
- 资产清单表：每行一个资产对象，字段包括唯一 ID、类型、主机名/IP、版本/型号、责任人、当前状态、目标状态、备注。
- 依赖关系图：即上文拓扑图，标注所有调用、部署、读写关系。
- 风险与差距清单：列出不满足目标版本要求的项，例如“数据库 11.2.0.4 需升级至 19c”“SSL 证书 2025-06 到期需更换”“FSC 缓存剩余空间不足 20%”。
盘点最容易遗漏的是“非标准配置”：手工添加的 FSC、临时挂载的 Volume、未登记的集成接口、测试用的 License Server。这些往往在升级后才暴露，导致升级中断或功能异常。建议盘点时专门安排一轮“异常项排查”，与运维和开发人员逐项确认。
盘点的粒度要适中：过粗会遗漏关键依赖，过细会消耗大量时间。建议以“升级方案设计所需的最小信息集”为边界，即：凡是会影响升级顺序、停机窗口、回滚策略、许可证续期的信息，都必须采集；其余信息可以后续补充。盘点完成后，应组织一次跨团队评审，确保运维、DBA、开发、业务方对清单内容达成一致，避免升级执行阶段出现“这个我不知道”的情况。