背景：更被重視的「資料備份」、「復原機制」
如果你有關注ASPICE標準的更新(從v3.1到v4.0)，你會發現「資料管理」這個議題變得越來越被重視了！ 為什麼這麼說呢？ 在舊版的ASPICE v3.1版本中，SUP.8的建構管理流程針對「資料管理」的描述，出現在BP9中。標準提到，需要通過適當地規劃，對正在使用的CM系統執行資料儲存、歸檔（長期儲存）和備份操作，目的是保障建構項目和基準的完整性及可用性。 簡單來說，標準要求專案團隊定期備份CM系統和相關建構項目、基準，以防資料遺失。 而到了新版的ASPICE v4.0，對於「資料管理」的規範進一步明確。新版要求: 確保建構管理流程（包括受控制的建構項目）中備份和復原機制的可用性。如果這些機制不足，則需採取措施。 與舊版相比，新版標準不僅強調要保持資料的完整性和可用性，還具體指出需要通過「備份」和「復原」來保護開發過程中所有受管控的建構項目。而且，當這些「備份」和「復原」失效時，亦要預先準備措施，進一步確保資料遺失。
問題：資料備份、復原機制有什麼注意事項？
根據上述背景，我們明白了「資料備份」與「復原機制」對於遵循ASPICE SUP.8標準的重要性。
如果專案團隊想要順利通過評鑑（從CL1到CL3），就必須妥善處理資料管理問題，並留下相關的證據。然而，當涉及到落地執行時，我們會發現團隊成員常常忙於處理專案產出，對於這些瑣碎的資料管理，卻顯得有心無力，那麼，要如何有效執行資料備份和恢復工作呢？
讓我們把這個大問題，細分為幾個小問題來逐一討論。
- 首先，要確定誰來負責「資料備份」和「復原機制」
- 其次，要確認哪些系統和建構項目需要被備份和復原。
- 由於ASPICE要求專案團隊需具備「系統性」方法，那是否已經定義了哪些系統和建構項目需要進行這些操作，並有相關的證據呢？
- 關於資料備份，需要準備什麼證據？
- 關於復原機制，應該多久進行一次？
- 承上提，該如何規劃復原機制的範圍？
參考回答
針對上述關於「資料備份」與「復原機制」的相關問題，回覆如下。
Q1：誰來負責「資料備份」和「復原機制」？
這項任務可以指派給建構管理工程師(CME)，交由他們負責監督資料備份」和「復原機制」的工作。
但是，他們不直接操作，而是會請求公司內的其他部門，比如MIS和IT部門，來幫忙完成這些工作。CME只需確認這些工作是否已經正確完成。
大家可以參考ASPICE 標準 SUP.8 中的一段有趣備註：
NOTE 11: Backup and recovery mechanisms may be defined and implemented by organizational units outside the project team. This may include references to corresponding procedures or regulations. 備註11: 備份和復原機制可以由專案團隊以外的組織單位定義和實施。這可能包括對相應程序或法規的參考。
不過，有時候專案團隊會遇到無法將這些任務交給其他部門的特殊情況。
例如，軟體部門可能部門內的一台主機，安裝了GIT工具來管理程式碼。因為這台主機不在IT或MIS部門的管理範圍，所以在進行日常備份時，可能會被忽略，變成備份的盲點。
在這種特殊狀況下，專案團隊就需要指派專人來負責。
Q2：哪些系統和建構項目需要被備份和復原？
簡而言之，專案中所使用的系統，及其包含的建構項目，都應納入備份和恢復的範圍內。
在這裡談到的「系統」，指的是用來存儲「建構項目」的系統或工具。 舉例來說： 用於存放管理計畫、會議記錄的Microsoft Teams 用於存放與管理程式碼的Git 用於儲存需求、架構資料的ALM工具 至於其他用於開發或進行測試的工具則不包括在內。
Q3：哪裡定義了需要進行資料管理的系統和建構項目？
根據ASPICE評鑑標準，直接開始工作而不遵循任何計畫或規則的話，評分將只能達到「P」。
若想獲得「L」或「F」，就必須採用一套系統化的方法或遵循規則，並留下相關的執行證據。
專案中所會用到的「建構系統」應該在建構管理計畫中明確定義。如果ASPICE 評鑑目標僅為CL1，則可以將其定義在建構項目清單(CI List)中。
這些定義需清晰說明使用了哪些「系統」以及這些系統中的資料夾或儲存庫如何規劃。
舉例來說： * 在Microsoft Teams系統中，事先劃分好多個資料夾，並指定各資料夾存放的資料類型 * 在Git工具中，提前設定好幾個分支和資料夾，並解釋各分支和資料夾的管理方式
此外，如果可以的話，建議可以明確指出各「系統」和它們的主機之間的關係。
這種關係可以通過製作網路拓撲圖來展示。
舉例來說： * Microsoft Teams系統運行於IT機房的主機上，IP地址為192.168.1.12 * Git工具安裝在軟件部門的主機上，IP地址為10.12.0.23
Q4：關於資料備份，需要準備什麼證據？
通常來說，資料備份是一個每天或每週自動進行的常規工作，這個過程由設定好的備份系統完成。
作為專案的建構管理工程師，你不需要天天檢查資料是否已經備份。但是，你仍然需要定期進行檢查。這個定期檢查的時間點，可以安排在每個專案的重要階段。
有時候，資料備份可能不是由我們專案團隊完成的，如果是交給外部單位負責，那麼我們應該要求他們提供備份證明。這些證明可能包括：已備份的資料、備份日誌、螢幕截圖等。
最重要的是，要確保所有專案使用的系統都被備份了。
額外問題：如果專案結束後，還需要確認備份嗎？ 當然需要！ 但專案結束後，保管資料就不再是專案團隊的職責。專案團隊應該將這項任務，交給公司的IT或MIS部門，確保資料能夠長期保存。 以汽車產業為例，這些資料需保留15年。
Q5：關於復原機制，應該多久進行一次？
有了資料備份，但這還不夠！
在台灣，筆者就見過好幾次資料丟失後，復原失敗的案例。這導致團隊失去了數月的工作成果。因此，除了備份外，還需要一個「資料復原機制」。
根據評估，定期進行資料復原是必要的。
通常，每年至少進行一次復原演練是一個常見的好作法。但考慮到專案進行期間資料的積累，建議在每個關鍵階段進行一次復原演練，以避免在遇到災難時資料無法復原，造成更大的損失。
值得一提的是，如果專案團隊委由公司其他部門來執行資料備份，則資料復原應由專案團隊與委外部門溝通，協調復原的頻率。
資料無法復原的原因 如果讀者的公司所採用的是時常更新的特定系統，由於系統的頻繁調整與更新，極有可能過去備份的專案資料，無法有效地被還原。
Q6：承上，如何規劃復原機制的範圍？
在制定資料復原計劃時，目標是包含所有專案團隊使用的「系統」與「工具」。
但在實際操作中，將所有系統全部包含進去往往不太可行，原因包括系統範圍廣泛、複雜，以及高頻率執行，可能導致工作量過大。
一個較為實際的方法是，依據「風險評估」來確定復原計劃的範圍。
舉個例子，對於存放在普通資料夾中的檔案類型資料，因為這類資料恢復失敗的風險較低，所以可以考慮每年進行一次復原。
相對地，對於儲存在ALM系統中、與特定工具高度相依的資料(例如: 系統需求)，由於這些工具在公司中不是經常使用，或者只有特定的專案團隊會用到，其資料備份和恢復的風險相對較高。因此，建議在每一個專案階段或每次工具更新時，都規劃執行一次復原演練，以確保機制的有效性。
額外參考
- (v4.0)ASPICE標準: SUP.8: 建構管理 (Configuration Management)
