【深入剖析學習歷程檔案事故4大原因】不只設定和維運問題，更是時程管理和制度面的考驗

一個VM設定的失誤，竟然造成全臺近8千名高中生，高達2.5萬件升學檔案的遺失，教育部在事件發生後，一連多次發布公告，說明事件原因和影響，不只負責學習歷程專案維運團隊，連教育部部長潘文忠都出面道歉，承諾將檢討改進。

遺失資料無法復原，只能靠學生重傳或重製後再上傳，即使事件過了一周，仍有近半數學生資料未補齊。

但是，如果進一步深入探究，這一起震撼各界的學習歷程檔案的資料遺失事故，不單是人為疏忽那麼簡單，更是一連串因素交錯影響加乘下的後果，主要可從4大面向來看。

1. 技術面問題

之所以發生嚴重資料遺失，第一個問題出在VM設定失誤，這是一個技術問題。據了解，設定工程師是在新機房建立VM時，不小心套用到錯誤的VM設定樣板，誤選了「測試環境設定」樣板，內建還原機制，只要重開機後就自動還原硬碟，也會清除所有資料。此次事件中，有3臺VM套錯樣板，重開機後，VM依照設定自動還原，也刪除了舊資料，因此才造成資料遺失。

工程師原本無意使用這個模式，但卻沒有發現自己設定錯誤，誤將原本應該好好小心保管的學生資料，放進等待還原的VM硬碟中，後來也沒有發現這項錯誤及時修正，這當然是疏失，也確實是個不應該犯的錯誤。

機房維運人員進行VM環境的建立、調整或搬移過程中，都可能發生資料損失的風險，特別是提供給重要系統使用的VM，進行任何異動、調整的流程上，必須訂出相關SOP操作，甚至最好能有一套監督或雙重驗證機制，提供多一層把關，來確保整個操作或設定沒問題。除了增加人力，也能透過一些自動化VM建置工具等，來減少這類錯誤的發生。這次事件更反映出，設定SOP必須搭配監督、驗證機制的重要性和必要性，才能將人為疏失的風險降到最低。

2. 維運面問題

根據我們了解，這套系統過去在臺北機房運作時，也曾發生過類似的設定失誤，但因有完整備份，每日的本地和異地備份，因此當時沒有造成資料損失。

只是這一次失誤發生在新機房，新環境的風險，讓設定失誤的小風險變成了致命問題。

維運團隊自己也知道，系統剛上線這段期間，新機房還來不及做資料備份，但卻沒有意識到，或者忽視了沒有備份的風險有多高，而沒有持續落實原本採行的備份計畫。備份機制沒有確實落實，這是第2層問題，是維運面問題，也是造成學生資料無法復原的關鍵因素。

若維運團隊將「321備份」原則，視為基本要求，也就是IT界或資安圈常聽到的「3份備份、分別存放2種不同的儲存媒體、至少一份在異地保存」。在每一次出現敏感或重要的資料遺失風險前，都徹底執行一次，就不致於出現資料遺失而無法從備份復原的情況。

台灣世曦資訊系統部副理張智欽表示，他們的作法是，只要是重大系統變動或異動作業前，一定會先做一次快照，甚至還額外多一次備份，才開始作業，「畢竟備份原本就是為了要彌補人為可能的疏失，作為最後一道防線。」

3. 時程衝突問題

但，更根本問題，是時程衝突。

時程衝突的導火線，是5月宣布因疫情停止到校上課 ，教育部將學習歷程上傳期限，從7月底延長到9月30日，可是明年1月考招新制就要上路，時間相當急迫。9月1日一開學，學生就得趕快製作與上傳學習歷程檔案，學校端接著也要趕緊在11月陸續提交到中央資料庫，時程是一關卡一關。

為了配合學生及學校端的作業時程的延期調整，暨大團隊原本計畫趁著暑假，在開學前完成新機房的搬遷工作。但新機房建置進度比原定時程晚了，直到8月底才啟用，在後續時程已經排定（而且經過一次延期很難再次延期），沒有其他選擇下，只能被迫選在9月初進行搬遷，導致學生上傳作業與系統移機作業時程重疊。

這樣意外的時程衝突，打亂了團隊的作業時程、搬遷計畫，為了趕上線，很難有充分的時間進行完整的機房演練或相關測試，甚至新機房才剛啟用，在備份還不完備的狀況下，也只能選擇先搬了再說。因為再不搬，系統遲遲不能上線，學生就無法上傳檔案，造成學校提交時程延遲，將可能大大影響到後面考招新制推動的時程。

突如其來的疫情，讓原本可錯開的流程，最後都混在一起，團隊的作業時間因此受到壓縮，大大增加了作業的風險，就是在這樣急迫時間壓力下，一次設定失誤，造成了資料遺失。

時程衝突，也是企業很容易遇到的問題。在時程衝突下，企業必須有所抉擇，也必須考慮到這抉擇後，因兩種作業衝突可能帶來的更大交互作用風險，才能爭取更多資源預作準備，來降低潛在風險。千萬不能小看，時程衝突帶來的隱藏性風險！

4. 制度面問題

除了技術、維運、時程衝突，最後一項是制度面問題，教育部長年以專案計畫委託，透過學校實驗室團隊來開發、維運重要資訊系統，而非尋求外部資訊專業廠商或SI團隊，這個習慣性作法造成了，系統維運團隊體質先天不足的問題。這也是造成這次事故的重要因素。

一來，在這樣學校實驗室編制下，校內團隊很難有充足預算，吸引到頂尖厲害高手加入，提升團隊戰力，只能以校內學生和老師為主，所以在人員專業度上很難有所提升；二來，平時只能接教育部的專案為生，缺少各種產業實戰環境來不斷練兵，來磨練團隊的維運能力，對學生來說，無法累積更多經驗，就不會認真視為長久的職涯發展。找不到外面有能力的人進來，也留不住團隊人才，終究沒辦法鍛練出像Google雲端業者或專業SI的世界級團隊。

這樣一個學校編制下的實驗室團隊，甚至可以說是只有老師、學生、專案人員組成的數十人專案團隊，不論是人力編制和專業能力，可能還是比不上校外專業資料中心或SI團隊，卻要執行這種全國性專案。遇上這種時程變動大，進度又很趕的專案，發生事故風險就容易比專業團隊來得高。這正是根本上的制度性問題。