iThome
9月1日開學,居家線上教學2個月後,中小學終於返校上課,尤其高三生更急著想要回去學校,要趕在9月底前, 製作完自己的學習歷程檔案,將原本7月底就要完成,後來因疫情線上學習未完成的檔案,在截止期限上傳, 因為攸關明年升學。
但是,沒人想得到,就在上傳截止前一周,維運工程師一個設定上的操作不慎,竟然造成2.5萬件學習歷程檔案的資料遺失,影響近8千名學生。消息一出,震驚各界。許多師生、家長更是錯愕。
這次的資料遺失事件,不只是108新課綱上路以來最嚴重的資料遺失事故,甚至可以說是,政府機關史上少見的大規模資料遺失重大事故,造成存放於政府機房的高中生學習歷程的資料遺失。
學習歷程檔案上路是翻轉教育的重要關鍵
學習歷程檔案之所以重要,不單是因為它可以記錄每位學生在高中三年的學習成果和表現,反映出個人在學的學習軌跡,更重要的是,在學習思考與製作檔案、成果的過程中,讓學生有更多思考、反省和探索機會。要改變傳統解題導向、考試機器人訓練般的教學型態,讓學生更有思考力,學習歷程檔案是個關鍵。
大學考招明年甄選申請入學,將正式參採學習歷程檔案,作為備審資料的重要來源,主要包括兩種類型的資料,學習成果、多元表現資料,全程透過數位化作業完成,不少高三生明年申請入學製作備審資料都靠它。
從升學模式來看,學習歷程檔案的正式上路,讓學生除了考試之外,有多一種升學管道做選擇,不再只是一試定終生。尤其,對於一些不擅長考試,但有其他才能的學生,更成了可以申請更多學校的關鍵。
正因為它是高中升學模式的一次重要轉變,再加上是這個模式第一次實施,得面對諸多外界更高度的期待和審視。
就在這種新模式展開之際,卻遇到突如其來的意外。
學習歷程檔案的資料遺失事件,9月25日凌晨先在媒體曝光,迅速引起眾人的關注。到了早上,不只多家媒體、電視臺相繼披露,臉書、PTT版上更是出現許多討論,成了當天民眾最關注的重要社會議題。
事件曝光沒幾小時,教育部國教署就公開證實,發生學生資料遺失的情形,但強調,只有部分,而非全部資料。
因事故遺失的這批資料,不少都是高三生所有,明年馬上就要進行第一次用學習歷程檔案申請入學的作業。流程上,學生得先將學習歷程檔案,上傳到各高中所屬學習歷程學校系統上,再由學校整批提交到教育部建置的學習歷程中央資料庫。明年各大學甄試時,會直接從中央資料庫取得審查資料。事故就是發生在前半段,學生上傳到校內系統的階段。
從系統架構來看,學生檔案上傳主要透過兩套系統,學校端使用的學習歷程學校系統,以及教育部的學習歷程中央資料庫系統。學習歷程學校系統中還有個模組,可用來記錄和追蹤每位學生學習歷程檔案。這次出問題的就是這個學習歷程模組。
兩階段向上集中作業
有一批高中的學習歷程學校系統,使用了教育部國教署委託暨南大學團隊開發的公版模組系統。這套系統原本分散部署在各校,不過,這幾年,政府為了強化教育體系資安,所以逐步將校內系統搬遷到資安管控更嚴謹的機房中集中管理。整個搬遷計畫,也是由開發公版模組的暨大團隊負責。
有395所高中使用公版模組,去年,整批先搬到了臺北機房做集中管理,今年因機房升級更換,所以再度從臺北舊機房,搬到臺中新機房,同樣由原團隊接手處理。在分工上,新機房分為搬遷和維運各自一組,網站維護、維運機房和虛擬主機管理各有不同負責人。
原定在7月底學生完成資料上傳後,在暑假進行系統搬遷工作,但5月突然因疫情停止到校上課,教育部將學習歷程上傳期限,從7月底延長到9月30日,再加上臺中新機房進度,也比原訂時程延宕,直到8月底才啟用,只能將搬機計畫延後到9月進行,導致延期後的學生上傳作業與系統移機作業時程重複。
9月5日,暫停學生上傳作業後,一組約20人組成的搬遷團隊,開始將各校所屬學習歷程學校系統的公版模組,逐步搬到新機房內的虛擬主機VM上。花了2天左右,完成移機作業後,才陸續開放各校學習歷程檔案上傳作業。新上傳的檔案,改為直接儲存到新機房的公版模組VM硬碟上,不再使用臺北機房內的舊系統。
順利運作十多天後,這些主機因系統更新而重新開機後,維運團隊才驚覺異常,其中有3臺VM硬碟因人為設定錯誤,導致部分資料無法連結,造成部分學生資料遺失。
因人為VM設定失誤,2萬多件學習歷程數位檔案消失不見!
9月26日,就在事件曝光隔日上午,教育部在記者會公布了資料遺失災情,初步盤點後,有81所高中學校,在9月5日至9月22日這段期間所上傳的學習歷程檔案,且備份在事故3臺VM硬碟的資料,才會受到影響。記者會上,專案計畫團隊負責人洪政欣強調,此次的資料遺失,是單次性的操作失誤,無關系統設計、程式設計,出錯的是虛擬主機的設定。
受影響學生多達7,854名,資料遺失合計2萬5,210件,這些資料,有些已經教師認證,也有的正在等待驗證的課程學習成果,或無需驗證的多元表現資料。以類別來看,多元表現的資料,就占了1萬5,417件,課程學習成果的資料也有多達9,793件。
記者會上,教育部表示,將協助學生做檔案恢復和重傳,但對於這些遺失的資料,如何從備份找回,或進行資料救援,當時沒有多作說明。事件經過一周後,在截稿前,教育部也沒有透露更多進展。
VM設定出錯關鍵環節首度曝光
雖然,教育部目前沒有揭露更多細節,從記者會上資訊,這起事故,肇因於人為操作失誤,因為VM硬碟設定失誤,導致系統更新重開後,部分檔案無法連結,才造成資料遺失。究竟如何發生?成了IT圈熱烈討論、分析的話題,甚至有資料救援業者嘗試模擬VM出錯情況來推測可能情況。
到底是什麼樣的VM設定失誤,竟然造成資料遺失?這是很多人的第一個疑問。根據iThome記者深入追查,這次VM設定失誤的關鍵原因是,在新機房搬移過程中,一名工程師重新建立各校公版模組使用的虛擬主機VM時,不小心誤用了錯誤的VM設定樣板才釀災。
一般來說,VM建置時有一個快速建立作法,可以透過樣板( template)套用既有VM設定,而不用逐一手動設定。這是VMware虛擬主機管理軟體內建的樣板套用功能,但是,一位工程師建置虛擬主機時,在設定選單中,原本應該要套用「正式環境樣板」的VM設定,卻有3臺VM誤選了「測試環境樣板」的設定。
這種「測試環境樣板」在硬碟設定模式,採取「獨立非持續性」的設定,內建還原機制,只要重開機後就自動還原硬碟,等於會清除所有資料。這就是這次VM設定失誤的原因。
「獨立非持續性」硬碟設定模式,是VMware軟體所支援的功能,一般來說,這個設定模式,用在像大型虛擬機升級更新的測試,或類似學校電腦教室這一類應用場景,這些場景都有一個共通之處,原本就需要透過還原的動作,來清空硬碟中的資料。所以硬碟裡就算有資料,也不是太重要的資料,但這一次,誤設的3臺VM硬碟裡存放的資料,是學生辛辛苦苦準備的課程學習成果或備審資料,攸關其能否升學。
9月22日,因資安要求進行例行性系統更新後,系統重開機,同一位工程師才發現自己套用了錯誤的樣板,但因為VM已經完成還原作業,硬碟上的舊有檔案無法連結,造成部分資料遺失。因為一臺公版模組VM,可供20~30校使用。395校一共部署10~20多臺VM,其中出事的3個VM,支援81校所用。
備份機制未完善下,冒然開放學習歷程檔案上傳作業
令各界更想不透的是,為何資料救不回來,難道之前都完全沒有備份機制嗎?經過我們的追查,其實原本的確有備份機制,沿用已久。在舊機房,暨大維運團隊的確有一套備份計畫,每天進行本地備份和異地備份。
高中9月1日開學,學生馬上就要展開學習歷程檔案上傳作業,為明年考招新制做準備,暨大維運團隊為了趕上線,9月5日展開搬遷,趕著幾天內要搬完並上線,讓各校學生使用。
在9月4日,搬遷到臺中新機房前一天,維運團隊除了原有本地和異地備份之外,對學習歷程檔案公版模組的資料再進行一次完整備份作業。這是為何後來只有9月5日到9月22日期間遺失資料,但9月5日前的資料都還在的緣故。
但問題就出在,新機房啟用太匆促,直到8月底才正式營運,學習歷程公版模組系統趕9月初進駐時,機房備份機制的設定還沒完備,不只沒有留存搬遷期間可用來還原的備份版本和快照,也還沒完成臺北和臺中異地備援架構,讓資料互為備援。
在不能延宕後續升學資料審查作業的時程壓力下,維運團隊為了要趕著上線恢復服務運作,所以,在備份機制沒完善的情況下,就開放了學習歷程檔案上傳作業。系統上線後,學生開始傳檔案,這些資料陸續送到新機房做儲存,但機房備份機制還是處於未啟動的狀態,等於從學校重新開放學生上傳檔案那一天起,這些學生上傳資料都沒有額外的備份。直到9月22日,因資安要求進行例行性系統更新,系統重開機後,發現部分資料已經遺失。
虛擬化平臺原本就可以內建提供VM快照的備份機制,但是,工程師所誤選的樣板因為採取了「獨立非持續性」的設定,這個模式,因為預設還原硬碟來清空資料,因此就不需要啟動快照功能。甚至,在一臺VM內若有多顆虛擬硬碟,其中一顆若設定成獨立非持續性,當用VMware軟體建立VM的快照時,就會繞過這顆硬碟,只對其他硬碟做快照,換句話說,就會沒有可以用來回復這顆硬碟的快照版本。VMware也證實,的確在這種情況下,設定了獨立非持續性的硬碟模式後,VM硬碟就不會被快照。
也就是說,從9月7日前後開放學生上傳,到工程師發現VM異常的這段時間,長達兩周,這段期間並沒有留存可用來還原的備份版本或是快照檔案,再加上還沒完成臺北和臺中兩地機房的異地備援架構,讓資料互為備援,臺北舊機房內的系統就無法同步更新取得新上傳的資料,一直到9月22日為止,才造成了這段期間的資料遺失後,無法從備份或快照恢復,之後也很難復原,甚至救不回來。
學習歷程資料遺失詳細事件表
2020年
各校的學習歷程檔案公版模組系統向上集中,第一階段先搬到臺北hicloud機房。每天進行本地機房備份和異地備份。
2021年6月22日
因疫情學生停止到校,教育部將學習歷程上傳期限,從7月底延長到9月30日,導致學生上傳作業與系統移機作業時程重複。
2021年8月底
臺中IDC新機房完成,但比原訂時程晚。
2021年9月4日
向上集中第2階段準備將學習歷程檔案公版模組系統從臺北hicloud機房,搬遷到臺中IDC新機房。除了原有每天本地和異地備份外,對公版模組的資料再進行一次完整備份作業。
2021年9月5日
暫停學生上傳作業,開始進行移機作業。分工上,暨南大學團隊新機房分為搬遷和維運各自一組, 網站維護、維運機房和虛擬主機管理各有不同負責人。
誤用錯誤VM設定樣版
移機作業展開後幾天,設定工程師有次在新機房執行新VM建置作業時,套用了錯誤的VM設定樣板(誤選了「測試環境設定」樣板)。(下圖為模擬圖,非真實畫面,圖片來源/OSSLab)
關鍵設定差異
「測試環境VM設定」與「正式環境VM設定」最大差異是,測試環境所用的硬碟設定模式,採取「獨立非持續性」的設定,內建還原機制,只要重開機後就自動還原硬碟,等於會清除所有資料。
2021年9月7日左右
完成移機作業,開放學習歷程檔案上傳作業,檔案上傳後,改為直接儲存在新機房的公版模組VM硬碟上。不再使用臺北機房內的舊系統。(各校上線時間仍會視情況調整,主要集中在9月7日這幾天)
2021年9月22日 事故日
VM還原事故
因資安要求進行例行性系統更新,系統重開機後,同一位設定工程師發現樣板套用錯誤,但因為VM已經完成還原作業,硬碟無法連結,造成特定期間內儲存在出事3臺VM硬碟上的學生資料遺失。
資料遺失盤點
9/5到9/22期間上傳且存放在誤設的3臺虛擬主機的學生資料
備份問題調查
因機房啟用太匆促,備份機制的設定還沒完備,所以,沒有留存搬遷期間可用來還原的備份版本和快照,也還沒完成臺北和臺中異地備援架構,讓資料互為備援。最後一版完整資料是9/4在搬遷作業前進行的完整VM備份版本。
2021年9月24日
緊急通知各校
委外維運團隊以電子郵件,逐一通知受影響學校,通知學生登入平臺確認上傳檔案是否正常。
2021年9月25日3:00
學習歷程檔案遺失事件在媒體曝光,引起各界議論。
2021年9月25日
第一次公告
國教署說明學習歷程檔案資料遺失事件及受影響範圍,說明後續補救作業,81校一共7,854名學生,合計2萬5,210件資料遺失。
(上圖為學習歷程檔案的課程學習成果資料上傳的操作示意圖)圖片來源/采威國際資訊
2021年9月26日10:30
教育部召開記者會說明2.5萬筆學習歷程檔案遺失採行因應機制及精進作為,同日也發第二次公告。
未來備份策略
加強虛擬儲存異地備份、定期檢視備份作業及還原演練,另外針對檔案嚴格要求落實異地備份,而且每天本地備份的次數最少6次,VM快照增加到每日6次,以保留完整資料和備份。對於負責維運的廠商每天落實備份的情形,也要建立相關監督機制,甚至一些重要系統要調整、操作時,需要有專家全程在場監督或提供建議。
2021年10月1日
第三次公告
國教署說明事件處理最新進度,包括待處理案件學生人數,以及資料件數。(截至10月1日,仍有3千多人,約6,050件的資料待處理。)
資料來源:iThome整理,2021年10月5日
2021/10/08 更正啟事:內文提及學習歷程檔案公版模組進駐的臺中新機房為hicloud機房有誤,正確為IDC機房。內文已更正。
熱門新聞
2024-10-05
2024-10-07
2024-10-07
2024-10-07
2024-10-07
2024-10-07
2024-10-07