公共信息服务软件质量问题层出不穷，到底为什么？应该怎么办？
背景
2021年末，西安爆发出了严重的疫情。然而半个月内，西安“一码通”两次崩溃，导致应当发挥重要作用的信息系统没有起到应有的作用，延误了抗疫工作的正常运行。群众调侃：非必要，不亮码；必要时，码不亮。事实上，仅在2021年八月，山东的电子健康码、福建的闽政通也出现过长时间的故障。而类似的其他类型的公共信息化服务出现问题，给人民群众生活造成不便的新闻也屡见不鲜。
“健康码”不健康、“一码通”通不了，表面看是技术问题，实则提醒我们反思可能存在的信息系统短板。随着信息化系统在社会治理中起到的作用越来越大，整个社会对于信息系统的可靠性要求也越来越高。越是重要的环节，系统如果不可靠，造成的危害则越大。 更重要的是，随着各类公共服务信息设备越来越多，智能设施的功能越来越复杂，服务人群越来越多，系统的需求分析、功能性和可靠性设计、以及长期运维不仅是技术问题，更是管理问题。这些管理不仅仅需要科学的公共管理方法，还需要对信息系统的技术和发展有整体的把控才能做好，这就给执政者提出了新的要求。
此外，当下信息技术发展速度很快，系统升级换代的速度也远超传统的公共服务设备的更新换代速度。在信息系统中，大数据的存储形式和使用往往只有原设计单位的部分人员才比较清楚，在进行系统升级改造时，如果缺少原设计的支持，新系统很难弄清楚保存在原系统中的绝大部分的结构化数据的存储形式，这可能就会造成巨大的数据浪费，甚至会导致一些由于关键数据遗失造成的公共问题甚至危机。
公共服务信息系统的设计、建设，以及后续的升级维护，有其自身的特点，不论是高可靠性要求的军工或航天的管理方法，还是当下普遍流行的普通民用软件和互联网公司的管理方法，都并不适用于当下公共服务信息系统。建立一套适合公共服务信息系统的管理方法，让政府，专家团队，以及设计、建设和维护单位在其中各司其职，妥善的发挥各自的作用，从而让公共服务信息系统能够可靠、高效的发挥作用，已经是迫在眉睫的事情。
故障复盘与技术分析
通过对“西安健康码不亮”事件的复盘，大致可以发现系统在设计和管理中存在如下的问题： 1） 系统规划和分解界面不清，存在大量空白地带和扯皮现象 根据官方公布的公示信息统计，在应用层服务中，阿里云提供政务云和短信服务；西安东软系统集成有限公司（以下简称“西安东软”）提供“一码通”软件开发和运营维护服务；安恒信息技术股份有限公司（下称“安恒信息”, 688023.SH）提供“一码通”部分安全项目服务；美林数据股份有限公司（以下简称“美林数据”，831546.NQ）提供引擎软件产品及相关服务；中译语通科技（陕西）有限公司（以下简称“中译语通”）提供大数据可视化服务。而在政务云平台中，北京启明星辰信息安全技术有限公司（以下简称“启明星辰”，002439.SZ）提供部分网络安全服务；阿里云也担纲了政务云平台的私有云建设。在多类服务商纠葛下，问题也变得愈发复杂，这也导致西安“一码通”故障调查和排除的繁琐，相关方对事故认定的说法不一。 2）系统顶层架构设计不合理 西安一码通第一次故障以后，有项目人士向媒体透漏，一码通问题可能在于连接“一码通”和西安政务云的安全防护机制过载，让“一码通”平台无法调用政务云上的数据。据悉，东软负责西安“一码通”信息技术平台软件产品级相关平台功能定制化开发服务，但是，该平台最初设计并不是为了支撑西安全员的核酸检测（核酸检测需要亮码），所以平台并没有设计与之对应的并发指标。即使是12月20日故障后，西安已经对一码通进行了扩容，并且完善了代码，但是依然不足以支撑西安全城1200万人的集中检测并发，这也就导致了半个月后的第二次故障。 3）系统的测试与验收不充分 信息系统的验收测试是确认系统功能和质量的最后一环，也是最重要的一环。系统的验收测试，不仅需要考虑系统在功能上的适用性，而且需要模拟系统在运行过程中和用户在使用过程中的各种极端情况，验证系统在各种非常规情况下的可靠性和容错性。西安“一码通”系统如果认真且全面的进行验收测试，则应该考虑到城市进行全员核酸负载下的系统容量并进行相应的压力测试，及时的发展设计问题。 不仅如此，验收测试一般会由专业的测试机构对产品的代码进行检查和分析，这样做一方面可以分析出代码中的设计错误和安全隐患，另一方面也可以分析出代码是否含有有害的信息收集和其他后门程序。西安“一码通”事件发生后，相关技术人员对该平台的服务模块进行了追踪，最终发现很多模块居然还是测试版本的，可见不论是施工单位、监理单位还是政府职能部门在最终产品代码检查上都是缺失的。
信息建设管理的组织问题
我们通过前期调研，发现我国大部分信息化建设和管理部门存在一些组织层面的问题，大致列举如下： 1） 信息烟囱、数据孤岛大量存在，且难以整合 一是信息化工作主要根据本行业本系统业务需求规划建设。重业务实现、轻全局统筹，项目分散建设现象严重，部分单位信息系统建设由各处室独自推进，系统建设不考虑互联互通和数据资源共享共用问题，专网运行情况严重，甚至有些单位一共建了多少系统都底单不清。二是系统独立运行、技术路线五花八门、数据接口标准各异等现实情况依然是制约着“技术通、数据通、业务通”的根本性问题。三是存量业务系统互通难，业务数据离散沉淀、分头管控、数据共享应难，严重制约着整体型数字政府向市场主体提供“一门、一窗、一次”的协同服务和社会治理效果，以及数据资源在数字化转型中要素性创新引擎作用。 2） 重复建设现象严重，且使用效果差 一方面，项目分散建设，缺乏总体统筹，导致项目建设内容上重复建设现象严重。业务需求不同，技术支撑团队不同，技术方案设计不同，单位或部门各自为政、分头建设，产生了大量“大而全、小而全”的系统，除了建设差异化业务系统，还都建设了各自的中枢和底层支撑。不但造成跨部门的重复建设，还造成跨系统、跨业务的重复建设。另一方面，信息化系统重建设、轻应用现象严重，部分已建信息系统使用意愿低、可用性不强，使用效果差。 3） 项目建设资金缺乏有效统筹，助推信息烟囱、数据孤岛持续形成 首先，项目建设资金分散，缺乏有效统筹，难以保障顶层规划“一体规划、集约节约、突出重点、分期分批、有序有效”建设推进。投资分散、缺乏统筹，该重点推进的工作经费不足，可以缓建的项目在加速推进，信息化建设“散、乱、软”问题不仅突出，还在持续加剧信息烟囱、数据孤岛问题。其次，信息化项目建设资金未统筹，进一步助推助推信息烟囱、数据孤岛持续形成。再次，急难险重任务缺少资金保障，处突工作举步维艰。比如新冠疫情防控工作，疫情发展不可预测，突发任务十分紧急，需要紧急开展的技术建设及服务工作难以开展。 4） 专业技术力量薄弱，工作被动 部门信息化专业技术力量薄弱是信息烟囱、数据孤岛形成，以及项目重复建设、使用效果差的重要因素。一方面，项目理解能力十分有限，难以衔接业务需求与技术实现间的关系，几乎不能保证“问题导向、需求导向、目标导向、效果导向”的基本建设原则。另一方面，项目主动管控能力弱。项目谋划阶段，弄不清项目是否必要建设，方案是否合理，技术路线是否可行；项目建设阶段，规范管控工作异常艰难；项目应用阶段，跨部门协同工作十分被动，搞不清系统能否打通，搞不清怎样打通，搞不清业务数据能否共享，搞不清协同开发工作量有多大，到底需要多少经费，在“三融五跨”的工作中始终处于被动的茫然困境中。
问题的解决思路
不论是项目质量管理还是软件质量管理，重要的不是不犯错误，但是不应该重复犯相同的错误。我们应该对已经发生的错误进行分析，找出其具体原因，并采用针对性的解决办法，并举一反三。
1）加强信息系统的顶层规划
我国前期的公共服务信息系统，是由各个部门独立上报，并按照一般的工程项目的申报流程进行审批，其方案和建设主要由各单位独立负责。这种形式在传统的公共服务工程上已经运行了几十年，其过程和管理非常成熟。但是信息系统建设和传统的工程项目建设有着很大的不同。相比传统的公共服务项目建设，信息系统在软硬件平台上，如云服务系统，服务器硬件平台等，有很强的可重复使用性，一套标准的软件平台和硬件服务器可以同时给很多信息系统提供基础软硬件服务；另外，公共服务系统的运行一般会需要和其他信息系统进行数据交互，而这些交互需求的落实，不仅需要全面翔实的顶层规划，还要在后续的设计和实施中，与系统的相关方，特别是外单位进行不断的沟通、协调，并在必要的时候进行设计改进。
值得肯定的是，我们国家的高层领导也看到了这些问题。各地区也都成立了诸如大数据局等专门的机构来负责信息系统的顶层规划和工程实施。但是任何改革都不是一蹴而就的事情，公共服务信息系统的规划和实施也还存在很多问题没有解决。但是大的方向是好的，这些年的进步也是明显的。
2）加强项目过程监督
当下公共服务信息系统的建设，大部分的地区和单位是以传统的项目监理的形式进行过程监控的，虽然地区的大数据管理部门作为行政管理机构也会以一定形式的参与。但是由于缺乏统一的标准引导，不同的项目实施情况良莠不齐。从软件工程的实践角度来看，信息系统的过程监督是十分有必要的，缺乏过程监督所带来后果主要体现在，最终的产品交付物根本无法满足用户的要求，而在交付期前后的反复改动，会带来很高的质量隐患。加强公共信息服务系统在建设过程中的监督，可以在项目的前期发现研制过程中存在的问题，从而以较低的成本进行改进。而在如何做好过程监督方面，军工领域的一些优秀实践可以作为参考。比如在监控时机方面，军工领域很多单位就在项目需求分析阶段和项目交付阶段设立了两个里程碑，这两个里程碑作为项目监控的主要节点，在进度和过程产出物方面进行外部多方评审，从而保证项目的正常运行。
3）加强最终交付的项目验收
当下公共服务信息系统的交付验收往往等同于传统的项目验收形式，按照项目合同的条目进行验收。然而，不同于传统的基建项目，信息系统项目的合同往往比较粗略，并不能体现项目的细节，即使项目满足合同要求，但是在实际使用中，可能并不能很好的满足使用场景要求。不仅如此，信息系统中的很多关键因素，并不是通过功能性检查就能得到验证的，比如代码质量、软件设计可靠性、并发能力等。这些质量相关的关键要素，不仅在项目前期需要专业技术人员的测算，后期也需要专业的软件测试部门和团队的验证。