疫情常態化下高職院校信息化建設的實踐與思考

□房曉陽 肖長水

新冠疫情席卷全球，在疫情防控形勢下，對高職院校的信息化建設提出了較高的要求。一方面，需要響應上級部門的監管要求，對疫情的信息進行采集和管理；另一方面，需要在科學防控疫情的前提下，保障學校正常的教學秩序、學生工作和學校其他業務的順利開展。在這種突發情況之下，信息系統或相關應用的需求體現了融合性、精確性、敏捷性等諸多特點。事實上，以往高職院校的信息化建設由于本身業務較為固定，往往會采購一定市面上成熟的產品，對于定制的需求不是很強烈，系統一經建成投產，后期的更新迭代較少，長期的建設模式慣性使得面對頻繁的業務需求時，高校缺乏解決方案進行應對。基于此，結合疫情下高職院校信息化需求特點，提出幾種可行的解決思路。

一、疫情下高職院校信息化需求特點

(一)融合性。疫情期間的信息化需求體現了很高的融合性要求，建設新應用所依賴的數據分布在不同的業務系統中，而快速地將這些分散在一卡通、教務、學工、保衛、后勤中的數據快速匯聚融合到一起，成為了新需求能否按時完成的關鍵，在這個前提之下，使用以往的系統間離線導出導入方式的數據明顯存在很大問題，一是數據的實時性不能保證，二是人工處理或者是數據庫底層之間的數據集成，對數據的標準性、完整性和質量都無法把控。如果高職院校對自身數據無法做到全面融合，則所建設的信息化系統很難達到預期的效果。

(二)準確性。由于上級部門監管和高職院校的自身管理要求，這些信息化需求的數據準確性要求極高，信息的準確性要求確認數據源頭的唯一和準確，因為基于不準確信息源頭的任何數據的加工、分析都是錯誤的，更遑論疫情期間的數據上報和輔助決策了。對于具有特性的業務數據，一般容易確定數據的來源，也就能夠較為準確地把握數據的準確性，例如學生的門禁刷卡數據，僅來源于一卡通系統。而一些共性的數據，由于各個業務系統建設存在先后，早期的數據共享缺乏規范等歷史原因，會存在各個系統內的共性數據存在多個來源，甚至數據流向混亂的情況。

(三)敏捷性。與互聯網行業不同，高職院校的信息化建設往往是采用先規劃后建設的方式，通常在整體的方案確定之后，才會進行采購和項目建設，這種建設方式是比較適合軟件工程中的瀑布模型的，因為整個建設的過程中成本、范圍和需求一般不會出現大的變更。疫情期間的信息化建設需求呈現任務緊急、需求變化快的特點，往往系統的需求是一天一個變化，這就要求不論是軟件的開發還是項目的管理，都要采用非常敏捷的方式來應對這種頻繁的版本迭代。

二、疫情下高職院校信息化建設解決思路

(一)搭建主數據平臺，構建數據管理體系。為獲得準確的業務數據，基于數據中臺架構建設高職院校新一代主數據平臺，利用數據中臺將各個業務部門的數據匯聚起來，形成數據貼源層，經過清洗和加工后的數據，可以按照主題歸入到數據倉庫中，作為學校數據資產形式沉淀下來。數據倉庫根據不同的業務細分可以形成數據集市，有信息化建設需求之時，建設方可以瀏覽數據集市，通過數據中臺提供的各種標準化的接入方式，獲取數據。為充分發揮主數據平臺的作用，配套數據管理體系也十分重要，對全校的數據通用數據制定編碼規范，通過主數據平臺處理后的數據以標準的編碼值輸出，制定數據管理規范和質量標準，確定數據產生部門對數據準確性的責任。

(二)服務微化轉型。為了能夠應對快速的需求開發和應對頻繁的需求變更，可以使用微服務的設計思想進行系統的開發，以往高職院校建設的信息化應用往往是單一部署、各個組件之間的耦合度很高，這種系統有比較高的維護成本，不適應頻繁的需求變化。利用微服務的思想，可以將一些復雜度不是很高的信息化需求建設成為微服務應用，結合虛擬化技術和分布式技術，此類微服務應用可以適應非常頻繁的業務變化，而且可拓展性比較強，針對不同的需求，可以拓展網絡、計算和存儲資源，兼顧了靈活性和魯棒性。

按照現在通常的定義，微服務是面向服務體系SOA的一種改進，即把應用程序設計為一組松耦合的服務，以便于后期的復用。微服務的建設思路要求的是對高校目前所建的服務進行治理，梳理并且對所有的服務進行劃分，與傳統的單體開發完成所有模塊后整體編譯部署上線不同，由于每個服務都是獨立運轉的，所以使得系統整體的穩定性和可拓展性都得到了很大的提升。

(三)項目管理敏捷化。高職院校的信息化建設往往嚴格按照招標要求進行建設，但從實際的項目建設情況來看，需求往往是逐漸明晰的，外部環境的變化，更會造成大量的需求變更，傳統方式會盡量回避這種變更，保證項目范圍的可控從而能夠順利在預計的時間內完成招標的功能。面對如今越來越多的需求變更的情況，筆者認為建設過程中應該引入敏捷的思想，敏捷思想主張擁抱變化，重視甲乙雙方之間的溝通交流，對于高職院校建設一些小型的應用非常適用。

敏捷開發是以用戶的需求為項目推進的核心要素的，需要項目建設的各方尤其是需求方(業務方)深度地參與到開發迭代中，這樣對于信息化主管部門來說，整體需求的準確度和項目的推進會具有更高的效率，開發方交付的軟件產品也會更加覆蓋需求。敏捷開發通常會將一個復雜的項目分解為一些小項目，保證了每一個段的項目階段都會有一定的產出，如果產出出現了偏差，可以快速反饋及時糾正，這樣可以有效避免傳統方式開發的“閉門造車”模式，經過長時間開發后的結果卻與需求出現偏差，導致重復返工，并且可能錯過了業務期。

三、案例分析

(一)綜合疫情管理。根據綜合疫情防控的需要，蘇州市職業大學也基于微服務的架構，新建了一系列的應用，涵蓋了每日體溫填報、每日健康打卡、出入校門的、宿舍門的黑白名單機制、特殊時期輿情監控，上述這些應用都會產生數據，一個綜合的分析應用可以為校方的管理人員提供決策，比如對體溫異常的學生進行重點監控；對不符合入校規則的人員直接在校門刷卡入校環節就進行告警；對學校封閉期間的重點輿情關鍵詞進行密切關注，必要時可以對特定的人員進行干預。

(二)浴室預約。疫情期間需要對校內的公共場所進行人員的限流，如何對浴室這類生活必須的場所進行有效管理成為難點。蘇州市職業大學的做法是采用線上提前預約+一卡通刷卡作為進入浴室的身份證明。線上開放浴室預約微應用，采用分時段的預約制，每個時段只有有限的資源，約完即止。上線使用以來，效果良好，但是部分學生反映浴室很難預約到，通過實際的一卡通刷卡數據又發現，很多學生存在失約。為解決此問題，在后續的迭代版本中加入了失約的灰名單機制，對出現失約行為的學生，自動加入灰名單，限制其一段時間內再次預約。經過多次版本迭代改進，貼近業務需求，此應用使得疫情期間的浴室資源利用率大大提高，在學生群體內也收獲了不錯的評價。

(三)啟示。對于開發應用，數據是基礎，數據的價值也是只有在被使用的時候才會被發現，基于數據中臺來獲取人員、一卡通等基礎數據，減少了溝通的成本，同時，數據中臺以標準化的接口來對外提供服務，這些服務一經開發是可以多次使用的，避免了重復制造“車輪子”的問題，必然減少了開發周期，服務需要接入的應用“先授權，后使用”，這些服務都是通過平臺本身進行監管的，可以有效減少不規范的數據使用情況，提升數據共享的安全性。另外，數據的使用也會暴露一些問題，例如在上述浴室預約的應用開發過程中，曾經計劃使用人臉識別進行身份認證，后來因為人臉數據的缺失，在可行性分析階段否決了這種方案，造成數據出現問題的原因可能是源頭業務系統的設計不規范，也可能是管理和操作上存在漏洞，這時候就需要制度來保障對數據源頭進行整改，從這個意義上來說，主數據平臺能夠反過來對原有業務的改進提出指導意見。

引入微服務和敏捷開發的思想的優勢是可以使得廠商、信息化主管部門、業務部門可以更加專注于業務，更加高效溝通，以最快的速度不斷迭代出符合需要的、高拓展性軟件應用。以每日健康打卡為例，在疫情高峰期，此應用的需求幾乎每天皆有變化，快速的版本迭代對于廠商和校方來說都有較大的壓力，隨著師生參與度不斷提升，對應用的并發要求也逐漸提高，這可能都是應用投入使用之處未曾考慮到的。得益于選型階段采用微服務架構，每日健康打卡應用可以很快速地響應需求的變更，同時對于不斷增加的系統吞吐量要求，也具備水平和垂直拓展的能力，滿足了整體要求。不過從客觀上來說，系統架構之爭從未停止，微服務架構會增加系統的復雜度，是會增加維護成本的，所以到底使用何種架構開發應用，還需根據實際情況進行考量。

四、結語

本輪疫情是對高職院校的信息化建設情況的一次測驗，考驗了各個業務域的信息化情況、數據的融合共享情況、項目的管理能力等，可以說，有不足之處，也有經驗收獲。隨著智慧校園發展的不斷深入，整合業務和數據也成為發展趨勢，借助引入互聯網行業的數據中臺、微服務、敏捷開發思想，有助于在實踐中對技術架構和思維方式進行創新，為未來的建設指明方向。