168_华南某大型企业集团高性能计算调度系统信息系统项目质量管理

ONEPSOFT | 软考学习知识库

---

华南地区某大型企业集团的高性能计算任务调度长期依赖人工排队与线下协调，任务提交、资源分配、作业监控等环节分散在各研究院所与计算中心手中，第三方厂商交付质量参差、集成测试反复返工，终端设备种类繁多、兼容性适配工作量被低估，并发访问峰值集中在业务高峰时段、性能压力大，计算资源利用率低、任务排队久。为把高性能计算调度业务数字化，该集团信息管理部门于 2023 年 11 月发起了高性能计算调度系统信息系统项目，经公开招标由我司承建，合同额 645.12 万元，建设周期 11 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合计算调度全流程数据，实现任务提交在线化、资源分配自动化、作业监控可视化。建设内容包括任务提交、资源分配、作业监控、计费统计、统计分析与报表五个模块，并与各研究院所及集团统一认证系统对接。技术方案上，平台按同城双中心多活容灾架构运行，微服务调用经 Istio 服务网格统一治理并支持灰度发布，业务数据由 GaussDB 承载，热点数据借助分布式缓存加速访问，前端基于 Vue3 组件体系实现，后端以 Java 17 与 Spring Boot 构建，应用部署在集团私有云环境，安全建设按等保三级标准同步实施。团队采用矩阵式组织，全队 15 人，需求、研发、测试、实施运维与数据治理各岗配齐，编制按模块规模与接口数量核定，联调高峰期另调集厂商力量集中攻坚。项目于 2024 年 10 月通过终验，上线后并发承载能力由 800 提升至 5000 用户在线，系统可用率稳定在 99.9% 以上，全年重大故障 0 起。

11 个月的实践让我体会到，质量管理的过程含义、质量报告与质量控制三者是贯通的：过程是方法框架，回答质量管理做什么；报告是记录载体，回答质量做到什么程度；控制是落地动作，回答质量问题怎么解决。三者互为支撑，缺一不可。下面我围绕项目推进中遇到的三道难题，结合这三者的运用说明质量管理是如何落地的。具体来说，三道难题分别是：厂商交付质量参差不齐、终端设备适配繁杂、高峰并发性能承压。

一、难题一：厂商交付质量参差，如何把集成过程管住

项目涉及多家外部厂商，集成测试反复返工，若放任不管，联调进度和质量都会失控。从过程含义上看，质量管理包含规划、管理与控制三个过程：规划质量管理识别质量要求与标准，管理质量把标准转化为执行活动，控制质量核验结果并推动纠正，三个过程构成完整闭环。本项目的集成质量控制，正是按这个闭环推进的：规划阶段先统一接口规范与测试标准，管理阶段靠联合评审与例会把标准落到执行，控制阶段用抽样与核对检验结果。三个过程的输入输出也各有落点：规划过程的输入是需求与合同，输出是质量计划与基线；管理过程的输入是质量计划，输出是质量改进与评审记录；控制过程的输入是交付物与标准，输出是核验结论与整改清单，过程之间的衔接因此清晰有序。针对 " 集成质量不稳 " 这一突出问题，我们用因果图从接口、数据、环境、责任四方面分析根因，定位到部分厂商的接口说明不全、测试口径不一，据此统一了集成测试规范，明确各方的测试标准与责任归属，并组织跨厂商联合评审，集成阶段的返工明显减少。以作业监控接口为例，早期联调时发现部分厂商对任务状态的字段定义不一致，通过联合评审统一了字段规范，作业状态从此实时准确。过程管理还靠日常制度托底：关键模块强制代码评审与双人复核，质量问题逐条登记造册、闭环销号，团队逐渐养成了 " 先想质量、再做事情 " 的习惯。

二、难题二：终端设备种类繁多，如何把适配质量核住

集团各研究院所的计算终端型号繁杂，兼容性适配工作量被低估，若适配不全，部分用户将无法正常使用系统。针对这一点，我们用检查表按终端型号、功能模块、适配状态三个维度逐项核对适配情况，每台设备的适配状态、遗留问题、负责人逐条登记，周例会上逐条过账，适配进度的颗粒度从 " 批次 " 细化到 " 单台 "。检查表的价值在于把 " 适配 " 这个模糊的任务拆成可勾选的清单，哪些设备做了、哪些没做、问题出在哪，一眼可辨，不会再出现 " 以为做了其实漏了 " 的情况。适配不是只做一遍就完，我们把每类终端的适配结果与问题记录沉淀成一份兼容性档案，同类问题在后续设备上提前规避，适配效率逐批提升。针对适配过程中暴露的兼容性问题，我们按终端型号分类记录，高频问题优先处理，逐类建立兼容性基线，后续新设备的适配直接对照基线预判风险，适配覆盖率由 78% 提升到 100%，没有一台在用终端因适配不全而影响使用，各研究院所的日常计算业务因此平稳切换到了新平台上。

三、难题三：高峰并发压力大，如何把性能质量验住

业务高峰时段并发压力大，若性能不达标，任务提交就会排队超时。针对这一点，我们用分层抽样按业务场景与接口类别分层抽取样本，对高峰时段的性能数据逐条核验，发现部分接口在极限并发下响应超时，据此优化了接口与缓存策略，压测全部达标，并发承载能力由 800 提升至 5000 用户在线，系统可用率稳定在 99.9% 以上。抽样不是抽完就完事，我们把每次抽样的结果带回质量例会，按接口类别归类分析，哪类接口反复出现超时，就针对哪类做专项优化，性能核验因此从 " 查问题 " 升级为 " 治源头 "。以任务提交接口为例，抽样发现其在批量提交场景下响应明显变慢，专项优化后该场景的性能提升了近一倍，用户高峰期的排队体验由此改善。性能核验不是只在压测时做，我们建立了性能监控台账，上线后持续记录高峰时段的响应数据，按月与基线对比，性能劣化在萌芽阶段就被发现，全年重大故障 0 起，靠的正是这种持续盯防。

四、质量报告：让质量结论有数据、有记录

按照题目要求，我们把各阶段的质量工作汇总成一份质量报告，随验收材料一并提交。报告分四个部分：一是质量基线，写明功能、数据、性能三类标准的定义与目标值；二是过程质量数据，汇总各里程碑的缺陷分布、整改闭环与评审记录；三是核验结论，给出抽样核验、性能压测、适配检查的结果；四是质量改进建议，列出复盘中发现的问题与后续改进方向。报告不是验收前临时拼凑的，我们从项目启动起就按月更新，每个月的质量数据、每一次评审结论都及时入卷，收尾时只需把既有记录整理成文，结论因此真实可信。报告给各方带来的是一致的信息：管理层看结论、实施团队看问题、验收专家看证据，各取所需，减少了反复解释的成本。质量报告的价值在于把分散的质量活动串成一条完整的证据链，验收时拿出的是数据而不是印象，各方因此对交付质量心服口服。项目最终一次通过验收，各研究院所与集团信息管理部门对系统的认可度明显提升，主管部门认为这套质量管理做法值得在集团内推广。整个 11 个月的实践，让我对 " 质量是设计出来的、管理出来的 " 这句话体会尤深。复盘整个项目，我的体会是：质量控制要落在具体动作上——因果图让集成根因显形，检查表让适配不留死角，分层抽样让性能结论经得起核查，质量报告让整个过程有据可查。回头看，最大的收获是团队对质量的理解从 " 把测试做完 " 提升到了 " 把证据留全 "。这套围绕三道难题展开的质量管理做法，后来被整理成公司在高性能计算类项目的质量管理经验，供后续同类项目复用。