疫情常态化下高职院校信息化建设的实践与思考

□房晓阳 肖长水

新冠疫情席卷全球，在疫情防控形势下，对高职院校的信息化建设提出了较高的要求。一方面，需要响应上级部门的监管要求，对疫情的信息进行采集和管理；另一方面，需要在科学防控疫情的前提下，保障学校正常的教学秩序、学生工作和学校其他业务的顺利开展。在这种突发情况之下，信息系统或相关应用的需求体现了融合性、精确性、敏捷性等诸多特点。事实上，以往高职院校的信息化建设由于本身业务较为固定，往往会采购一定市面上成熟的产品，对于定制的需求不是很强烈，系统一经建成投产，后期的更新迭代较少，长期的建设模式惯性使得面对频繁的业务需求时，高校缺乏解决方案进行应对。基于此，结合疫情下高职院校信息化需求特点，提出几种可行的解决思路。

一、疫情下高职院校信息化需求特点

(一)融合性。疫情期间的信息化需求体现了很高的融合性要求，建设新应用所依赖的数据分布在不同的业务系统中，而快速地将这些分散在一卡通、教务、学工、保卫、后勤中的数据快速汇聚融合到一起，成为了新需求能否按时完成的关键，在这个前提之下，使用以往的系统间离线导出导入方式的数据明显存在很大问题，一是数据的实时性不能保证，二是人工处理或者是数据库底层之间的数据集成，对数据的标准性、完整性和质量都无法把控。如果高职院校对自身数据无法做到全面融合，则所建设的信息化系统很难达到预期的效果。

(二)准确性。由于上级部门监管和高职院校的自身管理要求，这些信息化需求的数据准确性要求极高，信息的准确性要求确认数据源头的唯一和准确，因为基于不准确信息源头的任何数据的加工、分析都是错误的，更遑论疫情期间的数据上报和辅助决策了。对于具有特性的业务数据，一般容易确定数据的来源，也就能够较为准确地把握数据的准确性，例如学生的门禁刷卡数据，仅来源于一卡通系统。而一些共性的数据，由于各个业务系统建设存在先后，早期的数据共享缺乏规范等历史原因，会存在各个系统内的共性数据存在多个来源，甚至数据流向混乱的情况。

(三)敏捷性。与互联网行业不同，高职院校的信息化建设往往是采用先规划后建设的方式，通常在整体的方案确定之后，才会进行采购和项目建设，这种建设方式是比较适合软件工程中的瀑布模型的，因为整个建设的过程中成本、范围和需求一般不会出现大的变更。疫情期间的信息化建设需求呈现任务紧急、需求变化快的特点，往往系统的需求是一天一个变化，这就要求不论是软件的开发还是项目的管理，都要采用非常敏捷的方式来应对这种频繁的版本迭代。

二、疫情下高职院校信息化建设解决思路

(一)搭建主数据平台，构建数据管理体系。为获得准确的业务数据，基于数据中台架构建设高职院校新一代主数据平台，利用数据中台将各个业务部门的数据汇聚起来，形成数据贴源层，经过清洗和加工后的数据，可以按照主题归入到数据仓库中，作为学校数据资产形式沉淀下来。数据仓库根据不同的业务细分可以形成数据集市，有信息化建设需求之时，建设方可以浏览数据集市，通过数据中台提供的各种标准化的接入方式，获取数据。为充分发挥主数据平台的作用，配套数据管理体系也十分重要，对全校的数据通用数据制定编码规范，通过主数据平台处理后的数据以标准的编码值输出，制定数据管理规范和质量标准，确定数据产生部门对数据准确性的责任。

(二)服务微化转型。为了能够应对快速的需求开发和应对频繁的需求变更，可以使用微服务的设计思想进行系统的开发，以往高职院校建设的信息化应用往往是单一部署、各个组件之间的耦合度很高，这种系统有比较高的维护成本，不适应频繁的需求变化。利用微服务的思想，可以将一些复杂度不是很高的信息化需求建设成为微服务应用，结合虚拟化技术和分布式技术，此类微服务应用可以适应非常频繁的业务变化，而且可拓展性比较强，针对不同的需求，可以拓展网络、计算和存储资源，兼顾了灵活性和鲁棒性。

按照现在通常的定义，微服务是面向服务体系SOA的一种改进，即把应用程序设计为一组松耦合的服务，以便于后期的复用。微服务的建设思路要求的是对高校目前所建的服务进行治理，梳理并且对所有的服务进行划分，与传统的单体开发完成所有模块后整体编译部署上线不同，由于每个服务都是独立运转的，所以使得系统整体的稳定性和可拓展性都得到了很大的提升。

(三)项目管理敏捷化。高职院校的信息化建设往往严格按照招标要求进行建设，但从实际的项目建设情况来看，需求往往是逐渐明晰的，外部环境的变化，更会造成大量的需求变更，传统方式会尽量回避这种变更，保证项目范围的可控从而能够顺利在预计的时间内完成招标的功能。面对如今越来越多的需求变更的情况，笔者认为建设过程中应该引入敏捷的思想，敏捷思想主张拥抱变化，重视甲乙双方之间的沟通交流，对于高职院校建设一些小型的应用非常适用。

敏捷开发是以用户的需求为项目推进的核心要素的，需要项目建设的各方尤其是需求方(业务方)深度地参与到开发迭代中，这样对于信息化主管部门来说，整体需求的准确度和项目的推进会具有更高的效率，开发方交付的软件产品也会更加覆盖需求。敏捷开发通常会将一个复杂的项目分解为一些小项目，保证了每一个段的项目阶段都会有一定的产出，如果产出出现了偏差，可以快速反馈及时纠正，这样可以有效避免传统方式开发的“闭门造车”模式，经过长时间开发后的结果却与需求出现偏差，导致重复返工，并且可能错过了业务期。

三、案例分析

(一)综合疫情管理。根据综合疫情防控的需要，苏州市职业大学也基于微服务的架构，新建了一系列的应用，涵盖了每日体温填报、每日健康打卡、出入校门的、宿舍门的黑白名单机制、特殊时期舆情监控，上述这些应用都会产生数据，一个综合的分析应用可以为校方的管理人员提供决策，比如对体温异常的学生进行重点监控；对不符合入校规则的人员直接在校门刷卡入校环节就进行告警；对学校封闭期间的重点舆情关键词进行密切关注，必要时可以对特定的人员进行干预。

(二)浴室预约。疫情期间需要对校内的公共场所进行人员的限流，如何对浴室这类生活必须的场所进行有效管理成为难点。苏州市职业大学的做法是采用线上提前预约+一卡通刷卡作为进入浴室的身份证明。线上开放浴室预约微应用，采用分时段的预约制，每个时段只有有限的资源，约完即止。上线使用以来，效果良好，但是部分学生反映浴室很难预约到，通过实际的一卡通刷卡数据又发现，很多学生存在失约。为解决此问题，在后续的迭代版本中加入了失约的灰名单机制，对出现失约行为的学生，自动加入灰名单，限制其一段时间内再次预约。经过多次版本迭代改进，贴近业务需求，此应用使得疫情期间的浴室资源利用率大大提高，在学生群体内也收获了不错的评价。

(三)启示。对于开发应用，数据是基础，数据的价值也是只有在被使用的时候才会被发现，基于数据中台来获取人员、一卡通等基础数据，减少了沟通的成本，同时，数据中台以标准化的接口来对外提供服务，这些服务一经开发是可以多次使用的，避免了重复制造“车轮子”的问题，必然减少了开发周期，服务需要接入的应用“先授权，后使用”，这些服务都是通过平台本身进行监管的，可以有效减少不规范的数据使用情况，提升数据共享的安全性。另外，数据的使用也会暴露一些问题，例如在上述浴室预约的应用开发过程中，曾经计划使用人脸识别进行身份认证，后来因为人脸数据的缺失，在可行性分析阶段否决了这种方案，造成数据出现问题的原因可能是源头业务系统的设计不规范，也可能是管理和操作上存在漏洞，这时候就需要制度来保障对数据源头进行整改，从这个意义上来说，主数据平台能够反过来对原有业务的改进提出指导意见。

引入微服务和敏捷开发的思想的优势是可以使得厂商、信息化主管部门、业务部门可以更加专注于业务，更加高效沟通，以最快的速度不断迭代出符合需要的、高拓展性软件应用。以每日健康打卡为例，在疫情高峰期，此应用的需求几乎每天皆有变化，快速的版本迭代对于厂商和校方来说都有较大的压力，随着师生参与度不断提升，对应用的并发要求也逐渐提高，这可能都是应用投入使用之处未曾考虑到的。得益于选型阶段采用微服务架构，每日健康打卡应用可以很快速地响应需求的变更，同时对于不断增加的系统吞吐量要求，也具备水平和垂直拓展的能力，满足了整体要求。不过从客观上来说，系统架构之争从未停止，微服务架构会增加系统的复杂度，是会增加维护成本的，所以到底使用何种架构开发应用，还需根据实际情况进行考量。

四、结语

本轮疫情是对高职院校的信息化建设情况的一次测验，考验了各个业务域的信息化情况、数据的融合共享情况、项目的管理能力等，可以说，有不足之处，也有经验收获。随着智慧校园发展的不断深入，整合业务和数据也成为发展趋势，借助引入互联网行业的数据中台、微服务、敏捷开发思想，有助于在实践中对技术架构和思维方式进行创新，为未来的建设指明方向。