096_浙东某省会城市公共卫生监测直报系统信息系统项目综合管理

ONEPSOFT | 软考学习知识库

---

浙东地区某省会城市的公共卫生监测数据分散在医疗机构、疾控中心与基层卫生站手中，传染病等监测信息靠逐级电话与传真上报，时效差、易漏报，历史数据质量参差，清洗规则难以统一，上报高峰时段系统并发压力大，老系统接口文档缺失，改造边界难以厘清。为把公共卫生监测直报体系建起来，该地区卫生健康主管部门于 2021 年 9 月发起了省会城市公共卫生监测直报系统信息系统项目，经公开招标由我司承建，合同额 285.04 万元，建设周期 16 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是建立统一的公共卫生监测直报通道，实现数据在线填报、自动审核、及时预警。建设内容包括监测数据直报、审核校验、预警与处置、历史数据迁移、统计分析与报表五个模块，并与医疗机构、疾控中心及存量老系统对接。技术方案采用服务网格 Istio 统一治理微服务调用与灰度发布，整体部署为同城双中心多活容灾架构，数据库选用 GaussDB，热点数据由分布式缓存承载；前端采用 Vue3 与 TypeScript，后端基于 Java 17 与 Spring Boot 开发，应用中间件采用东方通 TongWeb，系统运行在市级政务云信创环境，按等级保护三级完成安全建设。项目团队共 18 人，采用矩阵型组织，包括我在内配置系统架构师 1 人、需求分析师 2 人、开发工程师 9 人、测试工程师 3 人、实施与运维工程师 2 人。项目于 2023 年 1 月通过终验，上线后设备在线率提升至 98.5%，数据自动核验比例由 42% 提升至 91%，并发承载能力由 800 提升至 5000 用户在线，直报链条运转稳定。

风险管理要主动识别、分析、应对和监控不确定性，把威胁降到最低、把机会放到最大。这个项目涉及医疗数据安全、历史数据治理、并发压力与老系统对接，不确定因素多，风险管理必须从启动就抓起来。公共卫生数据关系重大，任何一个环节的疏漏都可能带来连锁影响，风险管理的价值在这里体现得格外直接。下面我按风险管理七个过程，结合项目实践说明风险管理是如何开展的。

一、规划风险管理与风险识别

规划风险管理要确定用什么样的策略与方法管理不确定性，产出风险管理计划，让管理方式与项目的不确定性程度相匹配。我组织技术、采购、质量等负责人召开专题会议，确定了主动、持续的应对策略，遵循分级管理原则：高等级隐患由我与建设单位重点关注，中等级隐患由各工作包负责人管理，低等级隐患由执行人员自行监控。我们把隐患归类为技术、管理、外部、组织、采购五个维度，据此建立风险分解结构，定义了发生概率与影响的五级评定标准，并构建了概率影响矩阵，把隐患划分为高、中、低三个区域。资金上按总预算的合理比例预留应急储备，由我直接控制；时间上确定识别工作在启动时进行，每月召开风险例会。计划还明确了风险报告格式与跟踪频率，让风险信息在团队内部透明可见。这些安排写进了风险管理计划，成为后续工作的统一指南。

二、识别风险

识别环节要把项目潜在的单个与整体不确定性收集起来并记录其特征，把不确定性变成可管理的清单。我组织技术负责人、硬件负责人、产品经理等召开识别专题会议，运用头脑风暴收集原始信息，技术负责人提出历史数据清洗规则难统一，硬件负责人提出偏远卫生站网络不稳，产品经理提出上报高峰并发压力大。我们对照标准核对单逐项检查，补充了老系统接口文档缺失与政策调整隐患；通过假设条件分析，把历史数据按时迁移完成等假设的不成立可能性转化为隐患条目；通过文件分析，研读了卫生健康部门的数据标准，预判了直报字段调整的可能。经过系统识别，我们形成了风险台账，共记录 18 项隐患，全部归入既定的五个维度，没有出现类别对不上的情况。识别工作解决了有哪些风险的问题，也为后面的分析与应对铺好了路，登记册从此成为项目风险状态的完整档案。

二、风险定性与定量分析

定性与定量分析先按发生概率与影响给隐患排优先级，把注意力集中在高等级隐患上；定量分析再对高等级隐患做量化测算，用数字支撑应对决策。我们借助概率影响矩阵逐一评定 18 项隐患的等级，得出高等级 6 项、中等级 7 项、低等级 5 项，高等级项全部集中在数据与并发两条线上。对这 6 项，我们用三点估算法做了量化分析：例如历史数据迁移隐患，若清洗规则迟迟定不下来，最坏情况是延误六周，我们据此在进度计划中预留了缓冲；并发压力隐患，我们用数据分析模拟了高峰时段的并发模型，测算出系统需要支撑的峰值规模，据此确定了服务器与缓存节点的配置。量化结论写回风险台账，成为应对方案的基础。

三、风险应对的规划与实施

规划应对要针对每个高等级隐患定出策略与具体措施，把隐患控制在可接受范围；实施应对则把这些措施一一落实到位。我们为高等级隐患逐一制定了应对方案：对历史数据质量隐患采取减轻策略，先抽样摸底、再制定统一清洗规则、分批迁移；对并发压力隐患采取减轻策略，按峰值加冗余配置并启用分布式缓存；对老系统接口文档缺失隐患采取规避与减轻相结合的策略，先做接口普查，文档缺失的按现场抓包反推格式；对政策调整隐患采取接受策略，在需求阶段预留弹性字段。应对措施落实到责任人、完成时间与验证标准，写进风险台账。应对措施不是写进台账就完事，还要在实施后回看效果，效果不佳的及时调整策略，形成小闭环。我还把风险应对的流程画成流程图贴在项目部：风险触发、评估影响、选择应对、实施措施、验证关闭，每个环节的责任人一目了然，应对不再是临时救火。实施阶段，一项原本评估为中等级的网络专线隐患因运营商施工调整升级为高等级，我们依据流程图立即启动应对，追加无线备份通道，未影响直报业务。

四、风险监督与项目收尾

监督环节要持续跟踪已识别隐患与残余隐患，评估管理是否有效，让风险管理始终处于在编状态。我们每月召开风险例会，逐项核对风险台账的状态，中高等级风险每周跟踪，例会纪要发送建设单位备案，让风险状态对双方透明可见。监督风险不是月底才看一眼，而是贯穿执行的日常动作，流程图与登记册一图一表，让应对既有章法又有记录。第五个月，历史数据迁移隐患出现复发苗头，我用五问法追根因：先问为什么清洗进度慢，再问为什么规则反复改，追到第二层发现是字段口径定义不统一，随即组织业务方一次确认口径并冻结规则，问题不再反复。项目收尾时，18 项隐患中已关闭 15 项，3 项作为遗留事项移交运维团队，台账的完整记录也沉淀为经验教训登记册的一部分。

五、心得体会

项目最终按期通过终验，设备在线率达到 98.5%，自动核验比例提升到 91%，并发承载由 800 提升到 5000 用户在线，直报数据从上报到审核的时效明显缩短。回顾整个过程，风险管理的价值在于让不确定性变得可见、可比、可处置：流程图让应对流程清晰可循，五问法让根因不再模糊，数据分析让决策有了数字支撑，风险台账让管理始终在编。风险管理不是消灭不确定性，而是让不确定性在爆发前就被看见、被安排，这正是本项目给我最深的启示。这套以台账为档案、以流程图管应对、以五问法找根因的做法，后来也被复制到公司其他政务项目，成为可复用的组织资产。