2. Windchill高可用运维框架
高可用运维不是“多买几台服务器”或“加一个负载均衡”就能完成的事情。对 Windchill 这类承载产品数据、流程审批、文档版本与变更管理的 PLM 平台而言，高可用首先是一个可度量、可分解、可追责的工程目标。本节围绕四个相互咬合的概念展开：可用性如何定义、SLA 如何设计、故障域如何划分、运维组织如何协同。四者缺一，高可用就会退化为“口头承诺”。
一、可用性定义：从“感觉稳定”到“可计算”
可用性最常用的表达是 A = MTBF / (MTBF + MTTR)，其中 MTBF 为平均无故障时间，MTTR 为平均修复时间。这个公式揭示了一个关键事实：提升可用性有两条路——降低故障发生频率，或缩短故障恢复时间。对 Windchill 而言，后者往往更可控，因为数据库、应用服务器、文件仓库、LDAP、CAD 集成等环节的故障难以完全避免，但通过冗余、快速切换和标准化恢复流程，可以显著压缩 MTTR。
需要区分几个容易混淆的指标：
- 计划内停机：如版本升级、补丁安装、数据库维护窗口，通常不计入“非计划不可用”，但必须纳入 SLA 的维护窗口条款。
- 非计划停机：如应用节点崩溃、数据库主库故障、存储链路中断，是 SLA 考核的核心对象。
- 部分降级：例如仅 CAD 可视化服务不可用，但检入检出正常。这类“部分可用”必须单独定义，否则用户会认为“系统挂了”，而运维认为“核心功能还在”。
因此，可用性定义必须落到业务事务上，而不是仅看进程是否存活。例如：用户登录、打开产品结构、检入文档、发起变更请求、审批流程推进，这些事务的成功率与响应时间，才是可用性的真实体现。
二、SLA 设计：把承诺拆成可观测指标
SLA 不是一句“99.9% 可用”。它至少应包含：服务范围、可用性目标、响应与恢复时间、维护窗口、数据恢复点目标（RPO）、数据恢复时间目标（RTO）、例外条款与统计口径。以 Windchill 为例，一个可落地的 SLA 设计如下（示例参数，非实测值）：
| 指标 | 目标值（示例） | 统计口径 |
|---|---|---|
| 核心事务可用性 | ≥ 99.9%（月度） | 登录、检入、检出、审批事务成功率 |
| P1 故障响应 | ≤ 15 分钟 | 从监控告警到运维确认 |
| P1 故障恢复 | ≤ 2 小时 | 从确认到核心事务恢复 |
| RPO | ≤ 15 分钟 | 数据库归档日志与文件仓库同步 |
| RTO | ≤ 4 小时 | 灾难场景下恢复至可服务状态 |
| 计划维护窗口 | 每月 ≤ 4 小时 | 提前 5 个工作日通知 |
SLA 设计的关键是可观测。如果无法从监控、日志或合成拨测中拿到对应数据，这个指标就无法考核。例如“核心事务可用性”需要由 APM 或合成事务探针持续模拟登录、查询、检入操作，而不是仅依赖服务器 CPU 和内存。
三、故障域划分：让故障不扩散
故障域是指一个组件或一组组件发生故障时，影响范围所覆盖的边界。高可用架构的核心思想是：把鸡蛋放在不同的篮子里，并确保篮子不会同时掉。Windchill 典型部署中，故障域可划分为：
- 接入层：负载均衡器、反向代理。若单点，则整个系统不可达。
- 应用层：Windchill 方法服务器、Servlet 引擎、CAD Worker。多节点时应跨物理机或跨可用区。
- 数据层：Oracle 或 SQL Server 数据库。主备、RAC 或 AlwaysOn 决定数据库故障域大小。
- 存储层：文件仓库（vault）、共享存储。需与数据库保持一致性，避免“库恢复了、文件没恢复”。
- 目录与认证：LDAP/AD、SSO。认证不可用会导致全员无法登录。
- 基础设施：机柜、交换机、电源、空调。跨机架、双路供电是基本要求。
划分故障域后，要回答两个问题：单点故障在哪里？故障域之间是否存在隐式耦合？例如应用节点虽然做了双机，但共用同一台 NFS 存储，那么存储就是隐藏的单点。再如数据库主备切换后，应用连接池未刷新，仍指向旧主库，故障域实际上没有隔离。
四、运维组织协同：从“各管一段”到“共担目标”
高可用最终要靠人来执行。Windchill 运维通常涉及应用运维、数据库管理员、系统与存储、网络、安全、CAD 集成支持以及业务关键用户。若组织按技术栈切分，容易出现“应用说数据库慢、数据库说存储抖动、存储说网络丢包”的推诿。有效的协同机制包括：
- 统一事件指挥：P1 故障时指定一名事件经理，负责信息汇总、决策与对外沟通，避免多头指挥。
- 联合值班与升级路径：明确一线、二线、三线支持范围与响应时限，确保 15 分钟内有人接手。
- 变更评审：数据库参数调整、应用补丁、存储扩容等变更需评估对故障域的影响，避免“修一个、坏一片”。
- 演练常态化：每季度至少一次数据库切换、应用节点摘除、文件仓库恢复演练，验证 RTO/RPO 是否真实可达。
- 复盘闭环：故障后输出时间线、根因、改进项与责任人，改进项纳入下一周期跟踪。
五、把四件事串成闭环
可用性定义回答“什么叫可用”，SLA 回答“承诺到什么程度”，故障域划分回答“故障最多影响多大范围”，运维组织协同回答“谁来保障、怎么协作”。四者构成一个闭环：定义驱动 SLA，SLA 驱动架构与故障域设计，故障域设计驱动监控与演练，演练与复盘又反过来修正可用性定义和 SLA。缺少任何一环，高可用都只是纸面方案。
在实际落地时，可以先从一张“服务—故障域—SLA—责任人”对照表开始，把每个核心事务映射到具体组件、故障域边界、指标口径和责任人。这样，当故障发生时，团队能迅速判断影响范围、启动对应预案，并在事后用同一套口径评估是否达标。