ASPICE 標準解讀

ASPICE問題集:資料備份、復原機制有哪些注意事項?

■ 背景: ASPICE v4.0 更重視資料備份、復原機制

如果你有關注ASPICE標準的更新(從v3.1到v4.0),你會發現「資料管理」這個議題變得越來越被重視了!

為什麼這麼說呢?

在舊版的ASPICE v3.1版本中,SUP.8的建構管理流程針對「資料管理」的描述,出現在BP9中。標準提到,需要通過適當地規劃,對正在使用的CM系統執行資料儲存、歸檔(長期儲存)和備份操作,目的是保障建構項目和基準的完整性及可用性。

簡單來說,標準要求專案團隊定期備份CM系統和相關建構項目、基準,以防資料遺失。

而到了新版的ASPICE v4.0,對於「資料管理」的規範進一步明確。新版要求: 確保建構管理流程(包括受控制的建構項目)中備份和復原機制的可用性。如果這些機制不足,則需採取措施。

與舊版相比,新版標準不僅強調要保持資料的完整性和可用性,還具體指出需要通過「備份」和「復原」來保護開發過程中所有受管控的建構項目。而且,當這些「備份」和「復原」失效時,亦要預先準備措施,進一步確保資料遺失。

■ 問題:資料備份、復原機制有哪些注意事項?

根據上述背景,我們明白了「資料備份」與「復原機制」對於遵循ASPICE SUP.8標準的重要性。

如果專案團隊想要順利通過評鑑(從CL1到CL3),就必須妥善處理資料管理問題,並留下相關的證據。然而,當涉及到落地執行時,我們會發現團隊成員常常忙於處理專案產出,對於這些瑣碎的資料管理,卻顯得有心無力,那麼,要如何有效執行資料備份和恢復工作呢?

讓我們把這個大問題,細分為幾個小問題來逐一討論。

  1. 首先,要確定誰來負責「資料備份」和「復原機制」
  2. 其次,要確認哪些系統和建構項目需要被備份和復原。
  3. 由於ASPICE要求專案團隊需具備「系統性」方法,那是否已經定義了哪些系統和建構項目需要進行這些操作,並有相關的證據呢?
  4. 關於資料備份,需要準備什麼證據?
  5. 關於復原機制,應該多久進行一次?
  6. 承上提,該如何規劃復原機制的範圍?

■ 參考回答:

針對上述關於「資料備份」與「復原機制」的相關問題,回覆如下。

誰來負責「資料備份」和「復原機制」?

這項任務可以指派給建構管理工程師(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部門的管理範圍,所以在進行日常備份時,可能會被忽略,變成備份的盲點。

在這種特殊狀況下,專案團隊就需要指派專人來負責。

哪些系統和建構項目需要被備份和復原?

簡而言之,專案中所使用的系統,及其包含的建構項目,都應納入備份和恢復的範圍內。

在這裡談到的「系統」,指的是用來存儲「建構項目」的系統或工具。

舉例來說:
用於存放管理計畫、會議記錄的Microsoft Teams
用於存放與管理程式碼的Git
用於儲存需求、架構資料的ALM工具

至於其他用於開發或進行測試的工具則不包括在內。

哪裡定義了需要進行資料管理的系統和建構項目?

根據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
網路拓樸圖 – 用以展示系統與它們主機之間的關係,也包含備份主機的關係

關於資料備份,需要準備什麼證據?

通常來說,資料備份是一個每天或每週自動進行的常規工作,這個過程由設定好的備份系統完成。

作為專案的建構管理工程師,你不需要天天檢查資料是否已經備份。但是,你仍然需要定期進行檢查。這個定期檢查的時間點,可以安排在每個專案的重要階段。

有時候,資料備份可能不是由我們專案團隊完成的,如果是交給外部單位負責,那麼我們應該要求他們提供備份證明。這些證明可能包括:已備份的資料、備份日誌、螢幕截圖等。

最重要的是,要確保所有專案使用的系統都被備份了。

額外問題:如果專案結束後,還需要確認備份嗎?

當然需要!

但專案結束後,保管資料就不再是專案團隊的職責。專案團隊應該將這項任務,交給公司的IT或MIS部門,確保資料能夠長期保存。

以汽車產業為例,這些資料需保留15年。

關於復原機制,應該多久進行一次?

有了資料備份,但這還不夠!

在台灣,筆者就見過好幾次資料丟失後,復原失敗的案例。這導致團隊失去了數月的工作成果。因此,除了備份外,還需要一個「資料復原機制」。

根據評估,定期進行資料復原是必要的。

通常,每年至少進行一次復原演練是一個常見的好作法。但考慮到專案進行期間資料的積累,建議在每個關鍵階段進行一次復原演練,以避免在遇到災難時資料無法復原,造成更大的損失。

值得一提的是,如果專案團隊委由公司其他部門來執行資料備份,則資料復原應由專案團隊與委外部門溝通,協調復原的頻率。

資料無法復原的原因

如果讀者的公司所採用的是時常更新的特定系統,由於系統的頻繁調整與更新,極有可能過去備份的專案資料,無法有效地被還原。

承上,如何規劃復原機制的範圍?

在制定資料復原計劃時,目標是包含所有專案團隊使用的「系統」與「工具」。

但在實際操作中,將所有系統全部包含進去往往不太可行,原因包括系統範圍廣泛、複雜,以及高頻率執行,可能導致工作量過大。

一個較為實際的方法是,依據「風險評估」來確定復原計劃的範圍。

舉個例子,對於存放在普通資料夾中的檔案類型資料,因為這類資料恢復失敗的風險較低,所以可以考慮每年進行一次復原。

相對地,對於儲存在ALM系統中、與特定工具高度相依的資料(例如: 系統需求),由於這些工具在公司中不是經常使用,或者只有特定的專案團隊會用到,其資料備份和恢復的風險相對較高。因此,建議在每一個專案階段或每次工具更新時,都規劃執行一次復原演練,以確保機制的有效性。


■ 額外參考:

  • (v4.0)ASPICE標準: SUP.8: 建構管理 (Configuration Management)


【ASPICE問題集】系列文章

是從我顧問、輔導及評鑑的經驗中彙集而來的問題。
這些問題經過精心挑選和整理,最後發表在我的網站上。
我也會分享我的觀點和解答,期待通過閱讀和腦力激盪,一起豐富我們的知識和見解 :)


感謝閱讀本文章!

如果你對文章內容有任何問題,請隨時與我交流聯絡。

歡迎訂閱我的文章,當有最新文章發布時,我將第一時間通知您 :)


WRITTEN BY
David Lin

現任國際標準輔導顧問及評鑑師;
在這個網站,我將分享一些產業新知、趨勢以及標準的解讀與看法。

歡迎與我交流:
Email:
linchewing@gmail.com
LinkedIn:
https://www.linkedin.com/in/linchew/