上线后：运行服务

服务请求和目录、事件以及 P1 中的操作、SLA、支持渠道、版本发布、治理节奏、监控、扩展、扩展和稳定状态检查清单。

服务请求

请求 → 执行 → 客户验收 → 目录维护。只有客户才能提出并批准请求；TRANXACT 负责接收、评估、安排和报告完成情况 (SM_1.2.02)。生产请求全天候 (24×7) 处理，非生产请求仅在工作日处理。

环境刷新，分阶段进行

1. 请求（客户）——在服务门户中，指定目标环境、日期和掩码选择。
2. 质量检查（TRANXACT）——范围、类别、配额和批准已验证；进度已确认。
3. 执行（TRANXACT）—快照、复制、掩码、禁用出站集成、重新指向端点（TO_4.7.03、4.7.04）。
4. 后期处理（TRANXACT）— 健康检查、重新申请访问权限、附带证据的完成通知。
5. 验收（客户）— 验证并关闭或拒绝（TO_4.7.06）；决定重新启用哪些集成（TO_4.7.07）。

事件

客户创建事件，并填写优先级、业务影响、错误详情以及 24x7 全天候联系方式 (TO_4.2.01)。TRANXACT 运营团队验证优先级并确认，进行调查并提供 ASK 摘要，然后提供解决方案或临时方案；产品缺陷将提交给工程团队进行修复 (TO_4.2.06)。最终由客户确认解决方案并关闭事件 (TO_4.2.05)。

反应时间是指从创建工单到熟悉环境的工程师采取首次行动的时间。

P1，分四步进行

1. 在服务门户中提交一个非常严重的事件报告，并提供 24 小时联系人姓名和电话、业务影响以及错误消息或屏幕截图。
2. 致电 24×7 服务台，提供事件编号；询问状态或要求回电；如果影响扩大，请提高优先级。
3. 当业务停滞、系统上线面临风险、或者月底结算、工资发放或文件提交停止时，值班经理就会介入——引入账簿架构师和工程师。
4. 4小时内制定完整的行动计划，指定单一联系人，并对生产环境进行根本原因分析。事件记录将保留在系统中。

支持渠道

发布

1. 发布说明和时间表已提前发布（TO_4.8.01）。
2. 首先部署到非生产环境（TO_4.8.02）。
3. 客户对其自身流程在非生产环境中进行回归测试——这是客户的任务，除非已签订 T1 回归测试包合同 (TO_4.8.03)。
4. 冷静期。
5. 三个节点上的滚动生产更新。

• 默认情况下，月末结算、工资运行和法定申报日期均已从生产发布日历中排除（TO_4.8.04）。
• 架构变更向后兼容，并在生产规模的副本（TO_4.8.05）上进行了测试。
• 客户可以请求在允许的窗口期内推迟生产更新（TO_4.8.06），并将维护窗口移离月底、工资结算日或报税日（TO_4.4.03）。
• TRANXACT 不会因第三方扩展兼容性而延迟平台更新 (EXT_9.2.03)。

治理

从云端外部针对客户的完全限定域名 (FQDN) 运行合成检查 (TO_4.3.03)。业务流程监控（例如审批卡住、未过账的文档）由客户负责，除非客户已购买 M1 集成监控包 (TO_4.3.05)。

规模化

• 在合同层级内，TRANXACT 自行重新调度和扩展工作负载（INFRA_2.4.04，标准版）。
• 除此之外，更多或更大的工作节点（INFRA_2.4.05）、更大的数据库（DB_3.1.06）或更多存储（INFRA_2.5.03）都是可选的，可通过变更请求进行配置——在Live DR区域中进行镜像。
• 为应对人口迁移或年末高峰而进行的临时性增加属于附加（INFRA_2.4.06）。
• 产能每月审核一次，并在每个月末、工资发放高峰或入学高峰之前进行审核（SM_1.1.02、1.1.03、TO_4.12.04）。

扩展程序和第三方软件

请求会根据扩展框架进行评估——首先是配置，然后是 API，最后是集群内代码（EXT_9.1.01，标准）。集群内代码或代理需要进行安全性和工程审查（EXT_9.1.02，附加）。如果获得批准：

• 客户持有有效许可证，并在整个期限内获得供应商支持（EXT_9.1.03）。
• TRANXACT 通过其管道（EXT_9.2.01，附加）部署已批准的映像；客户安装、配置、修补并升级到供应商（EXT_9.2.02）。
• 客户在每次发布之前都会验证兼容性（EXT_9.2.03）。
• TRANXACT 可能会在收到通知后将其隔离或移除，或者在紧急情况下立即隔离或移除（EXT_9.2.04）。
• 由其引起的事件属于客户的责任，并且不包含在可用性 SLA (EXT_9.2.05) 中。

在概览文档和非标准日志中记录每个已批准的扩展；每次重大版本发布和续订时都会重新审核。

检查清单：稳态

参加这门课程，课程包含图表和检查。