标准操作程序 [模板］{ #upgrade_sop_templates }¶
1.升级前评估{ #1-pre-upgrade-assessment }¶
目的：
在计划升级之前，清楚地了解当前的系统环境、可用资源和团队准备情况。
该文件还证明了升级的必要性。
输入：
- 目前的 DHIS2 系统和基础设施详情
- 团队名单和可用性
输出：
- 基线系统文件
- 资源和团队清单
检查表：
- 当前系统分析
- DHIS2 版本：____
- 数据库版本：____
- 操作系统版本：____
- Java 版本：____
- 可用存储：____
- 可用内存：____
资源库存
| 资源类型 | 当前 | 需要 | 差距 |
|---|---|---|---|
| 存储 | |||
| 内存 | |||
| 中央处理器 | |||
| 网络 |
团队可用性矩阵
| 角色 | 主要联系人 | 备份联系人 | 可用日期 |
|---|---|---|---|
| 系统管理员 | |||
| 数据库管理员 | |||
| 网络工程师 | |||
| DHIS2 专家 |
2.评估变化{ #2-evaluating-changes }¶
目的：
系统地审查升级带来的所有变化，评估其影响，并记录成功过渡所需的行动。
输入：
- 所有相关 DHIS2 版本的发布说明
- 升级说明（技术要求）
- 功能和废止列表
输出：
- 相关变更的文件清单
- 分类影响评估
- 管理变革的行动计划
变化影响表：
| 更改说明 | 类别（用户/API/配置） | 影响概述 | 需要采取的行动 | 业主 | 到期日 |
|---|---|---|---|---|---|
检查表：
- 审查通过以下途径升级的所有版本的发布说明
- [审查升级说明中的技术要求（Java、PostgreSQL 等）
- 确定新功能和废弃功能
- 将更改归类：
- 最终用户的影响
- 应用程序接口/数据库模式
- 配置更改
- 记录实施过程中的相关变化
3.预算编制和升级日历{ #3-budgeting-upgrade-calendar }¶
目的：
估算和分配资源，制定明确的时间表，评估升级过程中的风险，确保所有利益相关者了解情况并做好准备。
输入：
- 所需活动和资源清单
- 历史成本数据（如有）
- 利益攸关方的可用性
输出：
- 预算概算
- 具有里程碑意义的升级日历
- 风险评估
- 利益攸关方沟通计划
预算表：
| 费用构成 | 估计费用 | 笔记 |
|---|---|---|
里程碑日历：*
| 活动 | 开始日期 | 结束日期 | 依赖关系 | 业主 |
|---|---|---|---|---|
| 系统评估 | ||||
| 创建备份 | ||||
| 测试环境 | ||||
| 生产升级 | ||||
| 验证 |
风险评估矩阵：*
| 风险描述 | 概率 | 影响 | 缓解战略 | 业主 |
|---|---|---|---|---|
| 高/中/低 | ||||
检查表：
- 估计培训、文件、技术更新、测试、基础设施和支持的费用
- 分配资源和分配责任
- 制定包含关键里程碑的升级日历
- 向所有利益攸关方通报日历
- 完成风险评估
4.备份实施{ #4-backup-implementation }¶
目的：
确保所有关键数据、配置和自定义设置都已安全备份并可验证，然后再进行升级。
输入：
- 当前系统和应用程序状态
- 备份工具和存储
输出：
- 所有关键组件的经过验证的可恢复备份
备份清单：
- 数据库备份
- 创建了完整的 PostgreSQL 数据库
- 已核实的备份
- 复制到安全位置的备份
- 地点____
- 大小____
-
校验和：____
-
配置文件
- 已备份的 dhis.conf
- Apache/nginx 配置
- 自定义脚本
-
地点____
-
定制应用程序
- 列出并备份的自定义应用程序
- 自定义报告
- 自定义脚本
- 地点____
5.元数据清理（可选）{ #5-metadata-cleaning-optional }¶
目的：
确保所有 DHIS2 元数据不存在可能中断升级过程的完整性问题。这一步骤可降低升级失败的风险，并确保为后续阶段奠定稳定的基础。
输入：
- 当前的 DHIS2 元数据配置
- 访问 DHIS2 元数据完整性检查工具
输出：
- 已确定的元数据问题（关键、严重、警告）清单
- 已解决的问题日志
- 签核元数据就绪情况
负责：
| 名称 | 角色 | 签名 | 日期 |
|---|---|---|---|
关键问题日志：*
| 问题描述 | Category option combos, can be specified multiple times. | 已采取的行动 | 负责任 | 日期 |
|---|---|---|---|---|
检查表：
- 审查当前元数据是否存在完整性问题
- 运行 DHIS2 元数据完整性检查
- 解决所有*关键*和*严重*问题
- 将任何警告记录在案，供今后审查
- 确认元数据已为升级做好准备
6.测试{ #6-testing }¶
目的：
验证升级后的 DHIS2 系统是否按预期运行，并在受控环境中测试所有关键工作流、定制和集成。
输入：
- 使用类似生产数据的测试环境
- 升级测试清单
- 用户角色、自定义应用程序和集成列表
输出：
- 完成的测试结果日志
- 发现和解决的问题清单
- 签字确认升级准备就绪
测试计划模板
| 测试案例 | 描述 | 预期结果 | 实际结果 | 状态 |
|---|---|---|---|---|
性能基准
| 公制 | 升级前 | 升级后 | 可接受范围 |
|---|---|---|---|
| 响应时间 | |||
| CPU 使用率 | |||
| 内存使用情况 | |||
| 数据库性能 |
测试结果日志：
| 测试场景 | 用户角色 | 成绩（及格/不及格） | 发现的问题 | 已采取的行动 | 测试仪 | 日期 |
|---|---|---|---|---|---|---|
检查表：
- 准备一个与生产数据类似的测试环境
- 使用[升级测试清单]（链接至清单）作为基线
- 使用所有相关用户角色（数据录入、管理员、查看器等）进行测试
- 测试所有自定义应用程序、脚本和集成
- 验证计划作业和后台进程
- 评估性能（响应时间、分析等）
- 如果可能，进行测试版测试
- 记录所有问题和解决方案
7.实施（升级执行）{ #7-implementation-upgrade-execution }¶
目的：
以可控方式执行升级，尽量减少停机时间，确保顺利过渡到新版本。
输入：
- 最终确定升级计划
- 系统备份
- 技术升级指南
输出：
- 升级后的 DHIS2 系统
- 升级执行日志
- 初步验证结果
执行前核对表：
- 已验证的所有备份
- 已批准的测试环境结果
- 可用的团队成员
- 已通知的用户
- 已确认维护窗口
执行步骤
| 步骤 | 命令/行动 | 时间戳 | 结果 | 通过验证 |
|---|---|---|---|---|
| 停止服务 | ||||
| 备份数据库 | ||||
| 更新依赖关系 | ||||
| 部署新 WAR | ||||
| 启动服务 | ||||
| 验证启动 |
恢复计划
| 步骤 | 行动 | 命令/流程 | 验证 |
|---|---|---|---|
| 1 | |||
| 2 |
8.验证{ #8-verification }¶
目的：
确认升级后的系统功能齐全，性能符合预期，所有关键工作流程均可正常运行。
输入：
- 升级后的系统状态
- 测试结果
输出：
- 核查报告
- 批准开展升级后活动
系统验证清单：
- 核心功能
- 用户登录
- 数据录入
- 分析
- 报告
- 自定义功能
性能验证
| 测试案例 | 升级前 | 升级后 | 状态 |
|---|---|---|---|
9.升级后的活动{ #9-post-upgrade-activities }¶
目的：
监测升级后的系统，更新文件，确保所有变更都得到妥善记录和传达。
输入：
- 系统监控工具
- 文件资源
输出：
- 更新系统和用户文档
- 监控和支持日志
监测计划
| 公制 | 工具 | 频率 | 阈值 | 超标时采取的行动 |
|---|---|---|---|---|
文件更新核对表：
- 记录的系统配置
- 已记录的更改
- 记录的新功能
- 已记录的已知问题
- 用户指南已更新
10.最终审查{ #10-final-review }¶
目的：
总结经验教训，审查整体升级流程，并获得主要利益相关方的正式批准。
输入：
- 所有升级阶段的反馈
- 记录问题和解决方案
输出：
- 经验教训文件
- 正式签字和批准
经验教训模板
| 类别 | 成功之处 | 失败之处 | 改进 |
|---|---|---|---|
| 规划 | |||
| 执行 | |||
| 测验 |
签收文件
- 升级详情
- 以前的版本：____ 新版本____ 完成日期____ 执行者____
- 批准
- 系统管理员：____ 日期____ 技术负责人____ 日期：____ 项目经理____ 日期：____