华腾科技是专注做高校智慧校园服务平台软件的厂商，已服务全国过百家高校客户，从年三十开始到今天，我们陆续收到来自多所高校关于“每日健康打卡”、“提前返校登记”、“疫情数据统计分析”等相关业务需求。在应对过程中，我们和高校一起经历了考验，也总结了一些经验。在此对如何选、如何建、建什么，过程中的思考与感悟做个小小的总结，希望对后续建设类似业务的学校提供更多的参考和帮助。
本文主要脉络如下：
1. 这个业务有什么特点？
全员精准填报：需要建立稳定、流畅、全员参与的数据上报通道，保障全体教职工、本专科生、研究生、留学生的每日健康打卡，做到不遗漏、不重复、不出错；
分级管理、快速反应：需要满足学校疫情管理部门、各参与业务处室、二级学院、辅导员、班主任对所辖范围内师生填报数据的多维度查询、统计、分析的要求，建立层层管理、层层负责的应对模式，实时定位高危人群，快速展开应对工作。还需要将每日全员的健康统计汇总后上报上级疫情主管部门；
全员集中访问、历史最高并发访问量：需要应对全校数万用户、在单位时间内同时过万的并发访问量，保证服务正常运行；
2. 自建还是公有云？
公有云平台由于没有学校的基础数据做支撑，没法儿精准定位本校师生，无法规范数据格式，所以也无法做精准的统计分析，所以并不适用于高校普遍存在的要面向几万师生收集相关信息，并在短时间完成管理分析，并在短时间完成管理应对的场景。
通过挂载第三方的调查工具来做简单的数据上报，会导致上报数据混乱，难以统计分析，使用互联网工具进行数据上报。由于无法和学校的数据和平台互联互通，不可避免的带来了数据不完整、催办无手段、业务变化不及时、数据无法积累，后续难以支持更复杂的提前返校登记、返校师生排查等业务。
利用公有云平台还存在敏感信息泄露的风险，所以我们还是建议学校自主建设。
3. 单独开发还是基于平台构建？
这个是一个典型的碎片化业务（轻应用），时间短、任务急、业务链完整，对数据质量要求高，只有依赖大平台的众多信息化基础能力（如流程、审批、消息推送、数据采集、统计分析、数据分享、业务系统互联互通、PC移动多渠道一体化、数据标准融合），在高校信息中心建设的校级平台上通过配置化手段构建，才能在24小时内稳定上线，提供面向师生填报和业务管理的全业务链支撑，并且拥有应对几万师生集中高并发访问的能力。
单独构建一个五脏俱全的小系统并不推荐，因为即便是应急使用的最简化实现也有比较大的工作量，而且短期内对代码质量、系统稳定性、并发性都无法保障。
而且可以预测，在本次疫情期间以及疫情结束后的相当一段时间，人们还是会尽量回避在公开场合聚集，避免过多与人接触，所以我们不仅仅需要一个疫情期间的应急响应平台，还需要一个常态化的敏捷化开发平台，以应对接下来间接不断涌现的网上办事业务需求增长。
4. 移动端渠道怎么选最好？
推荐使用微信企业号加微信小程序的组合方式，微信是移动互联网时代唯一的超级连接器，没有之一。通过微信企业号可以让各类消息、填报要求以微信消息推送方式最快速度直达用户，保证最高的被响应率，借助微信小程序可以帮助学校的各级管理人员、班主任、辅导员，学生干部等把填报入口转发到年级群、班级群、社团群，实现服务的社交化融合，进一步提高效率，减轻管理人员的工作负担。如果没有以上条件，也可以选择学校师生已经广泛接受的渠道，比如自建APP、阿里钉钉、易班等等。
5. 这些学校采集了什么数据？
《某大学疫情防控筛查信息表》采集以下字段：
1.姓名，2.工号，3.所在在单位，4.当前详细位置，5.近期（2020.1.1-至今）是否到过省外，6.今日日期，7.今日是否到过校园，8.今日是否居住/到过家属区？，9.今日本人是否外出，10.今日本人体温测量，11.今日本人或家属是否身体异常，12.近14日本人或家属是否参加群体性活动，13.近14日本人或家属去过湖北地区，14.近14日本人或家属是否同湖北地区返回人员接触，15.近14日本人或家属是否与疑似或确诊患者接触过，16.本人或家属是否有被医学隔离，17.本人或家属是否居家隔离，18.本人或家属是否有确诊病例，19.本人或家属是否有疑似病例，20.是否为本人，21.填写疑似病例人数，22.地点，23.备注
《某大学健康筛查统计表》采集以下字段：
1.学工号，2.填报日期，3.单位学院，4.部门班级，5.身份(教师/学生)，6.联系电话，7.姓名，8.性别，9.所在地省，10.所在地市，11.所在地区，12.具体所在地，13.是否发热，14.是否咳嗽，15.是否胸闷，16.是否与确诊，17.疑似患者有接触,18.近期是否去过（途径）武汉，19.本人或家人是否密切接触从疫区返回人员
6. 数据填报工作面临何种挑战？
对学校的基础数据质量提出考验：最基础的是组织人事数据、辅导员和学生数据等等，本次大规模填报过程中我们也碰到了大量由于数据问题导致的关注不上、提交不了等问题，这也是对实施服务人员耗费精力最多的地方；
对平台的快速响应能力提出考验：比如所在城市的某位出租车司机被确诊，可能需要快速更改填报表单，增加相应字段，迅速统计出这段时间坐过这辆出租车的校内师生名单，需要在基础的每日打卡基础上随着疫情发展增加个性化的上报内容。除了每日上报，我们陆续还收到了“外地返回上报”、“所在小区封闭情况上报”、“疫区人员接触情况上报”等等，受此次疫情影响，相信还有更多与补考、答辩、教学、出访相关的各类审批需要更多非接触式的网上办事通道，这也对服务平台对业务的快速响应能力提出更大的考验；
对平台对全体师生的有效触达能力提出考验：除了通过发通知、公众号推送、发动各级工作人员口口相传的方式告知全校师生上来填报，更需要平台本身能以任务式填报的方式，将填报要求通过微信图文消息的方式推送给全体全校师生，师生直接点击消息即可一键进入填报页面、按要求完成填报。只有实现了“要你办”方式的精准触达，才能全面提高信息获取的效率；
对平台的高并发响应能力提出了挑战：对学校的基础计算环境、服务平台本身都提出考验，本业务执行过程中，所有师生都空前地积极配合，一般在填报要求发出后，马上会迅速会聚集过万的并发请求，下边会专门论述如何应对高并发。
7. 后续的数据管理分析怎么做？
数据采集本身不是目的，对疫情数据的有效利用，快速应对才是核心，要能够在每天几万份的上报数据中快速筛选出是否已经出现了确诊或疑似人员、有哪些人出现了发热等相关症状，居住或途径过武汉的有哪些人，有哪些老师和同学居住的小区发生了疫情，哪些学生已经提前返校等等，并需要通过分级授权的方式，让各相关业务管理部门、二级学院、班主任、辅导员也能参与到整个疫情管理工作中来，在自己的所辖范围内，能够以任意数据字段的任意条件组合，随时对上报上来的数据进行查看和分析，以便做出快速决策和应对。
8. 如何应对高并发？
我们在某拥有五万在校师生的大学，是通过采用了以下多种技术组合，以保证高并发下的应用：
大数据技术运用：平台使用了NOSQL技术，用于处理非结构数据、KV数据的高速存取，不完全依赖关系型数据库，避免性能瓶颈；
动静分离部署：把html,css,js和图片资源等静态文件和动态业务请求分离，通过分担动态和静态负载的模式提高系统并发效率；
多级缓存技术：平台使用了集群缓存、节点缓存、NOSQL缓存、浏览器前端缓存（LocalStorage、SessionStorage、Application Cache）等等，进一步提高系统性能；
集群化部署：包括三个集群：应用服务器集群、数据库集群、NOSQL集群，通过集群化部署，为高并发访问提供弹性的横向扩容能力；
硬件负载均衡器：考虑到高并发业务集群规模大，连接数量高，学校紧急调配了硬件负载均衡器，未来还将增加硬件SSL加速器来提供高性能、高并发的业务访问能力。
9. 写在最后的思考和总结
通过此次疫情紧急上报工作，高校的收获：
提升了信息化领导力：让相关领导，党政办、学工处、人事处等相关部门一同深刻认识到了有一个信息化基础响应平台的重要性，也知道了平台能干啥，疫情过后相信会对信息化工作有更大的支持；
夯实了学校和师生的双向沟通渠道：通过本次疫情填报业务，将过去没有关注到学校智慧校园服务平台的师生用户，一次性成千上万的拉了进来，真正健全和完善了学校和全体师生之间的双向信息传递通道;
拉动了学校基础数据的质量提升：最起码的组织人事数据、辅导员和学生数据通过了业务检验；
促进了各类在线服务的发展：可以预测疫情过后的相当一段时间内，大家都不愿意做太多人与人接触的、需要人员大规模聚集的业务，网络教学、网上办事、网上客服咨询，想必会得到更大的发展；
对传统业务处理模式提出更大挑战：每天数以万计的数据收集与分析，对过去单纯依赖Excel收集数据的模式提出了挑战，逼着学校通过更有效的信息化手段，部分摆脱Excel。
服务平台本身也积累了非常宝贵的经验：
在实战中通过了高并发高压力考验：第一次在五万人规模高校，过万并发的条件下通过了业务考验，积累了非常宝贵的实战经验；
对产品下一步的优化方向提供了参考：特别是对每日健康上报这类需要多级管理、全员参与的“要你办“式业务，为了做到不遗漏、不重复、不出错，对产品本身也提出更高的要求；
对项目间的知识经验共享提出更高的要求：例如本次每日健康上报业务，不同学校需要填写、统计的内容大致相同，需要有更高效的办法来形成不同项目间的复制与共享，全面提升效率，降低人工配置的复杂度。
在全民战疫期间和未来的工作中，我们会继续快速优化产品，满足更多需求，提供更好的用户体验。希望能够在日常工作中真正帮助到各个业务部门和广大师生们，真正减轻日常繁琐工作，让大家腾出时间干更有价值的事情。