維基百科

組態管理

組態管理（Configuration management、CM）也稱為配置管理，是系統工程的一部分，應用在專案的完整生命週期中，使產品的效能、功能以及實體屬性和其需求、設計、操作資訊可以保持一致[1][2]。 組態管理已普遍使用在軍事工程組織中，在複雜系統（例如武器系統、軍用車輛及資訊系統）的系統發展生命周期中管理其變更。在軍事以外的應用中，組態管理也用在IT服務管理中，像是資訊科技基礎架構庫、土木工程的領域模型，或是其他像是道路、橋梁、運河、水壩及建築物的專案中[3][4][5]。

頂層組態管理模型

簡介

編輯

組態管理可以應用在系統的整個生命週期中，可以得到有關效能、功能及實體屬性的資訊，並且可以管理。組態管理目的是要驗證系統的行為符合預期，在專案的生命週期中識別這些特性，並且在檔案中有詳細的描述，以支援驗證的結果。組態管理有助於系統資訊及系統變更的有序管理，目的是為了以下的好處：提昇效能、可靠度或是可維護性（英語：maintainability）、延長產品壽命、降低成本、減少風險及責任、修正缺陷。實施組態管理有些成本，不過此成本小於後續因可能發生意故而產生的成本。

組態管理強調元件、子系統及系統之間機能的關係，目的是為有效的控管系統的變更。組態管理有助於驗證所提出的變更已用系統性的方式進行考慮，以減少其負面影響。可以用標準化、系統化的方式來提出變更，並且進行評估及實現，以確保其一致性，而提出的變更會以預期對整個系統的影響來進行評估。組態管理會驗證變更是依規定的方式進行修改，而且零件及系統的檔案可以反應其實際的組態。完整的組態計劃可以提供在零件、子系統及系統的基礎上，儲存、追蹤及更新所有資料的所有規定[6]。

結構化的組態管理計劃可以確保檔案（例如需求、設計、測試及允收檔案）準確，和實際的實體設計一致。若沒有組態管理，在在許多情形下，檔案存在，但和對應的實體不一致。員工及承包商常常為了要進行變更，反而要修改檔案以符合實際的實體。這種逆向工程過程在人力以及資源上都是浪費，若使用組態管理，可以減少甚至消除這類的成本。

歷史

編輯

組態管理是在1950年代起源於美國國防部，是針對硬體裝置的技術管理規則，目前已幾乎是所有產業中的標準作法。1960年代時美國國防部發展一系列的美國軍用標準，稱為480系列（例如MIL-STD-480, MIL-STD-481 and MIL-STD-483，這些標準在1970年代陸續的發行），此時組態管理也有了的技術規則。480系列在1991年合併為單一的標準，稱為MIL–STD–973，後來為了減少軍用標準的數量，被MIL–HDBK–61取代[7]。之後，組態管理也漸漸演變為廣為使用，受到各領域的認可的標準ANSI–EIA–649（英語：ANSI–EIA–649）–1998[8]。目前組態管理已使用在許多的組織及機構中，組態管理的概念包括系統工程（SE）、綜合後勤支援（英語：Integrated Logistics Support）（ILS）、能力成熟度模型整合（CMMI）、ISO 9000、PRINCE2專案管理方法、資訊及相關技術控制目標（COBIT）、資訊科技基礎架構庫（ITIL）、產品生命周期（PLM）及軟體生命週期管理（ALM）。其中許多的機能和模式已重新定義了組態管理，從傳統的整體分析變成技術管理。有些則將組態管理視為類似圖書館活動的事務，將變更控制及變更管理視為一個獨立或是個別的學科。

簡介

編輯

組態管理是用系統化的方式管理變更的實務，目的是讓系統在不同時間都可以維持一致性（英語：system integrity）。在組態管理中包括了政策、程式、技巧以及工具，在系統變化的過程中，可以管理變更、評估要進行的變更、追蹤變更狀態、維持系統資產及支援檔案。組態管理方案以及計劃會提供技術以及管理的方向，實現要成功開發及維護複雜系統需要的相關程式、功能、服務、工具、流程以及資源。組態管理中可以進行計劃管理（英語：program management），在包括運作及維護在內的整個生命週期中，追蹤各項的需求。不可避免的，在過程中會有需求以及設計的變化，這些變化需要核可，也需要記錄，以針對系統狀態有準確的紀錄。理想上，組態管理會在整個系統發展生命周期中使用。有時會將組態管理和資產管理混淆，資產管理是盤點手上的資產。組態管理和資產管理的差異是前者不會由財務的角度來進行管理，而是以系統要提供的服務才進行管理。

在MIL–HDBK–61A中提到，針對硬體及軟體的組態管理包括五項不同的知識領域（discipline）[9] ，在ANSI/EIA-649中，這些知識領域是建立形態基準及進行標準應變管理時的政策及程式。IEEE 12207（英語：IEEE 12207）程式IEEE 12207.2中也有這些活動，另外再加上「發布管理及交貨」（Release management and delivery）。 五個知識領域如下：

  1. 組態管理計劃及管理：組態管理專案的正式檔案及計劃，包括有以下項目：
    • 人員
    • 權責及資源
    • 訓練要求
    • 管理會議的指南，其中包括流程及工具的定義
    • 基準流程
    • 組態控制及組態狀態統計（Configuration Status Accounting）
    • 命名規範
    • 審核和審查
    • 分包商/供應商的組態管理需求
  2. 組態識別（Configuration Identification、CI）：包括設定基準以及維持基準，基準是定義系統及子系統架構、組件，以及在任何時間點的開發。這是識別、紀錄以及追蹤系統中變更項目的基礎，應用在設計、開發、測試及交付階段。組態識別會漸進式的建立系統以及其組態項目（CI）的組態狀態統計（Configuration Status Accounting）的目前狀態，並且在系統生命週期中（開發、生產、布署以及運行維護）持續的維護，一直到系統停用為止。
  3. 組態控制（Configuration Control）：包括變更請求以及變更提案的評估，後續是否核可等。此程式包括系統設計、硬體、軟體、韌體、檔案任何修改的控制程式。
  4. 組態狀態統計（Configuration Status Accounting）：包括紀錄組態項目說明（例如硬體、軟體、韌體），、產出報告、並且紀錄在設計或製造階段，所有不符合基準的部分。若懷疑有問題，透過基準組態驗證以及核可修改的驗證即可縮小確認範圍。
  5. 組態驗證及審核：硬體和軟體的獨立驗證，目的是要針對效能需求、商業或軍事標準、效能基準、產品基準，評估是否符合。在核可架構進入架構基線之前，會先進行基礎組態審核（Configuration audits），會驗證系統及子系統的組態檔案是否符合機能以及實體的效能特點。

軟體

編輯
主條目：軟體組態管理

軟體組態管理（SCM）是在開發軟體專案時，處理變更的方式。此作法會在專案的不同階段落識別軟體的機能屬性及實體屬性，用系統化的方式來控制變更，目的是為了是在開發週期中維持軟體完整並且可追蹤。

軟體組態管理流程會定義需要追蹤變更的項目，並且可以確認最後發布的軟體是否有原先預期發布時應該有的更新內容。若要實施軟體組態管理流程，需在軟體專案中識別出以下四個流程：

  1. 組態識別（Configuration Identification）
  2. 組態控制（Configuration Control）
  3. 組態狀態統計（Configuration status accounting）
  4. 組態審核（Configuration audits）

其名詞及定義會隨標準而不同，不過在本質上是一様的。

  • 組態識別（Configuration identification）是識別組態項目每一個層面的屬性。組態項目（configuration item）是一個終端客戶會使用的產品（硬體或／及軟體）。屬性會紀錄在組態檔案中，並且設定形態基準。設定形態基準的好處是當屬性變更時，要透過正式的控制管理流程才能變動。
  • 組態變更控制（Configuration change control）是要修改組態項目屬性，或是重新訂形態基準時需要進行的流程以及核可。
  • 組態狀態統計（Configuration status accounting）是指可以紀錄每一個組態項目的形態基準，並且提供任何時間時的對應形態基準。
  • 組態審核（Configuration audits）會分為機能組態審核（function configuration audit）及實體組態審核（physical configuration audit）。可以在交付時進行，也可以在任何變更要實施時進行。機能組態審核確保組態項目可以達到其機能屬性以及效能屬性，實體組態審核則確認組態項目的安裝方式符合細節設計檔案中的需求。

組態管理資料庫

編輯

資訊技術基礎架構資料庫（ITIL）有規範用組態管理系統（Configuration management system、CMS）或組態管理資料庫（CMDB）作為產業上組態管理的最佳實務。組態管理資料庫用來追蹤組態項目，並且追蹤彼此之間的相關性，此處的組態項目是指在企業內值得追蹤並且管理的項目，包括電腦、軟體授權、電腦機架、網路裝置、儲存裝置，甚至是這些裝置的零件等。

組態管理系統／組態管理資料庫的好處是可以進行像是根本原因分析、影響分析、變更管理等機能，也可以評估目前狀態，作為未來策略開發的根據。這類系統（多半會分類為資訊科技服務管理系統）的例子有FreshService、ServiceNow及Samanage。

資訊保障

編輯

在資訊保障領域中，組態管理是在資訊系統的生命週期中，透過硬體、軟體、韌體、檔案、測試、測試治具、測試檔案的變更管理，來管理系統的資料安全特性及保障。[10]。資訊保障的組態管理，有時也會簡稱SCM（Secure Configuration Management），, 需要配合IT平台及產品的效能、功能及實體屬性，以及其環境，來決定系統需要的適當安全特點以及保障。例如，同樣是防火牆，在組織網際網路邊界上的防火牆，其組態需求就和在公司內部的防火牆不同。

維護系統

編輯

組態管理也可以用在維護系統上，可以瞭解複雜資產的情形，以最低的成本達到最高程度的可用性，其目的是要確保不會因資產（或資產的零件）運作超過計劃壽命或是運作在品質水準以下，造成運作的中斷。

在軍事上，這類活動稱為任務準備（mission readiness），要定義可用資產以及要執行的任務。例如航空母艦上的飛機是否配備了用於地面支援的炸彈或防禦用的導彈。

作業系統組態管理

編輯

組態管理可以用來維護作業系統的組態檔案[11]。這類的系統中包括Ansible（英語：Ansible (software)）、Bcfg2（英語：Bcfg2）、CFEngine（英語：CFEngine）、Chef、Otter（英語：Otter (software)）、Puppet、Quattor（英語：Quattor）、SaltStack（英語：SaltStack）、Terraform（英語：Terraform (software)）、Pulumi（英語：Pulumi (software)）及Vagrant。許多這類的系統用基礎架構即代碼（英語：Infrastructure as Code）（IaC）來定義組態以及維護組態[12]

組態管理的承諾理論（英語：Promise theory）（Promise theory）是由Mark Burgess開發的[13][14][15]，實際的實現是在現今CFEngine（英語：CFEngine）軟體，可以做實時的修復，也可以做預防性的保養。

預防性維護

編輯
主條目：預防性維護

預防性維護常用在企業資產維護、維修及企業資產管理系統系統中，其核心元素是瞭解資產及其重要組成當前的狀態。

像飛機、船舶、工業裝置等複雜的資料，要在其中的各種零件是可服務的狀態下才能正常運作。可用性（serviceability）會用許多的資訊定義，包括零件購置後、安裝後、維修後的使用情形，以及其他的限制因素。需要瞭解這些元件還可用多久，以往這類的工作需要大量的人力，一直到有對應的軟體後才改善此一問題。

預測性維護

編輯
主條目：預測性維護

許多裝置都會有電子感測器蒐集資料在運行過程進行狀態監測。資料會在裝置上或遠端的電腦上分析，評估目前的可用性，並且設法預測未來的可用性，會使用預測未來潛在失效的演算法，依以往現場的失效案例，以及建模的結果來分析，並且提供提前維護的建議，這稱為預測性維護。

可以有準確且及時的可用性資訊，對組態管理可以提供運營價值至關重要，少了這些資訊可能就會造成一些限制。擷取操作資訊，並且分發給各支援組織，本身就形成一個產業。

隨著原始裝置製造商（OEM）提供的軟體越來越多，這些數據的使用也越來越多。這些的目的是讓運營商可以保證其可用性，也讓資產管理的內容更加複雜，但原始裝置製造商仍有責任確保其產品的可用性。

標準

編輯

有許多標準支援（或是包括）組態管理[16]，例如以下的這些標準：

  • ANSI/EIA-649-1998 National Consensus Standard for Configuration Management
  • EIA-649-A 2004 National Consensus Standard for Configuration Management
  • ANSI EIA-649-C 2019 Configuration Management Standard
  • ISO 10007（英語：ISO 10007） Quality management systems – Guidelines for configuration management
  • 美國聯邦標準1037C
  • GEIA Standard 836–2002 Configuration Management Data Exchange and Interoperability
  • IEEE 829 Standard for Software Test Documentation
  • 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering. 2012. ISBN 978-0-7381-7232-3. doi:10.1109/IEEESTD.2012.6170935. 
  • {{le|STANAG 4427 on CM|STANAG 4427 on CM|NATO STANAG 4427 Configuration Management in Systems Life Cycle Management]] including
  • NATO ACMP 2000 Policy on Configuration Management
  • NATO ACMP 2009 Guidance on Configuration Management[17]
  • NATO ACMP 2100 Configuration Management Contractual Requirements
  • CMMI CMMI for Development, Version 1.2 Configuration Management
  • CMII-100E[18] CMII Standard for Enterprise Configuration Management
  • Extended List of Configuration Management & Related Standards[19]
  • ITIL Service Asset and Configuration Management
  • ISO 20000:1 2011& 2018 Service Management System.
  • ECSS-M-ST-40C Rev.1[20] Configuration and information management

指南

編輯
  • IEEE 828-2012 Standard for Configuration Management in Systems and Software Engineering[21]，2013年3月16日發布。
  • ISO 10007:2017 Quality management – Guidelines for configuration management[22]
  • NATO ACMP-2009 – Guidance on configuration management[23]
  • ANSI/EIA-632-1998 Processes for Engineering a System
  • ANSI/EIA-649-1998 National Consensus Standard for Configuration Management
  • GEIA-HB-649 – Implementation Guide for Configuration Management
  • EIA-836 Consensus Standard for Configuration Management Data Exchange and Interoperability
  • MIL-HDBK-61B Configuration Management Guidance[24]
  • MIL-STD-3046 Configuration Management[25]
  • Defense Acquisition Guidebook[26], elements of CM at 4.3.7 SE Processes, attributes of CM at 5.1.7 Lifecycle support
  • Systems Engineering Fundamentals[27], Chapter 10 Configuration Management
  • Configuration Management Plan[28] United States Dept. of Defense Acquisition document

建築

編輯

近來已經將組態管理用在大型的建築計劃中，多半是非常複雜，有許多的細節及變更需要記錄的建築。像聯邦公路管理局（Federal Highway Administration）等建築機構已將組態管理用於其基礎設施項目中[29]。有建築相關的組態管理工具，可以管理變更通知和工程釋疑單（RFI），目的是確保專案不會超過時程以及預算。在建築完成後，這些軟體也可以儲存一些維護及修改時需要的資料。在一個美國聯邦運輸管理局（FTA）贊助的計劃中，利用比較洛杉磯縣大都會運輸局（LACMTA）紅線第一階段及第二階段，53億美元的鐵路建設案，來評估組態管理的效果。研究的結果是，使用組態管理對專案有正面效果[30]。

相關條目

編輯
 
維基共享資源上的相關多媒體資源：組態管理

參考資料

編輯
  1. ^ MIL-HDBK-61A, ""Military Handbook: Configuration Management Guidance. Department of Defense. 2001-02-07 [2012-03-24]. （原始內容存檔於2012-03-20）. 
  2. ^ ANSI/EIA-649B, ""National Consensus Standard for Configuration Management. TechAmerica. 2011-04-01 [2012-03-24]. （原始內容存檔於2012-08-01）. 
  3. ^ History and Heritage of Civil Engineering. American Society of Civil Engineers. [2007-08-08]. （原始內容存檔於2007-02-16）. 
  4. ^ Institution of Civil Engineers What is Civil Engineering (PDF). Institution of Civil Engineers. [2007-09-22]. （原始內容 (PDF)存檔於2006-09-23）. 
  5. ^ Configuration Management and the Federal Transportation Administration (FTA) National Lessons Learned Program. Federal Transportation Administration. [2007-09-22]. （原始內容存檔於2012-09-07）. 
  6. ^ Systems Engineering Fundamentals (PDF). Defense Acquisition University Press. January 2001 [2012-03-25]. （原始內容 (PDF)存檔於2006-02-11）. 
  7. ^ Memorandum, Specifications and Standards – A New Way of Doing Business. Secretary of Defense. 1994-06-29 [2012-03-23]. （原始內容存檔於2013-10-21）. 
  8. ^ Configuration Management Compliance Validation: Critical Review and Technology Assessment(CR/TA)Report (PDF). Defense Technical Information Center. [2001-05-14]. （原始內容存檔 (PDF)於2021-02-07）. 
  9. ^ Compare: Military Handbook: Configuration Management Guidance (PDF). Department of Defense: United States of America: iii–iv. [2016-07-21]. （原始內容存檔 (PDF)於2020-10-30）. 4. CM LIFE CYCLE MANAGEMENT AND PLANNING [...] 5. CONFIGURATION IDENTIFICATION [...] 6. CONFIGURATION CONTROL [...] 7. CONFIGURATION STATUS ACCOUNTING [...] 8. CONFIGURATION VERIFICATION AND AUDIT [...] 9. DATA MANAGEMENT [...] 
  10. ^ National Information Systems Security Glossary
  11. ^ C. Lueninghoener. Getting Started with Configuration Management. ;login: issue: April 2011, Volume 36, Number 2 (PDF). [2012-11-23]. （原始內容存檔 (PDF)於2016-03-04）. 
  12. ^ Loschwitz, Martin. Choosing between the leading open source configuration managers. Admin Network & Security (Lawrence, KS USA: Linux New Media USA LLC). 14 November 2014 [2021-02-09]. （原始內容存檔於2019-05-10）. 
  13. ^ M. Burgess, Cfengine: a site configuration engine, USENIX Computing systems, Vol8, No. 3 1995 [1] （頁面存檔備份，存於網際網路檔案館）
  14. ^ M. Burgess, On the theory of system administration, Science of Computer Programming 49, 2003. p1-46 pdf 網際網路檔案館的存檔，存檔日期24 July 2011.
  15. ^ M. Burgess, Configurable immunity for evolving human-computer systems, Science of Computer Programming 51 2004, p197-213 pdf 網際網路檔案館的存檔，存檔日期3 March 2012.
  16. ^ NISTIR 7339 Analysis of Standards for Lifecycle Management of Systems for US Army (PDF). National Institute of Standards and Technology. August 2006 [2021-02-15]. （原始內容存檔 (PDF)於2016-12-21）. 
  17. ^ ACMP 2009 Guidance on Configuration Management[失效連結]
  18. ^ CMII-100E
  19. ^ Extended List of Configuration Management & Related Standards. [2021-02-15]. （原始內容存檔於2011-06-09）. 
  20. ^ ECSS-M-ST-40C Rev.1. [2021-02-15]. （原始內容存檔於2021-01-17）. 
  21. ^ IEEE 828-2012 Standard for Configuration Management in Systems and Software Engineering. [2021-02-09]. （原始內容存檔於2018-05-16）. 
  22. ^ ISO 10007:2017 Quality management – Guidelines for configuration management. [2021-02-09]. （原始內容存檔於2019-05-18）. 
  23. ^ NATO ACMP-2009 – Guidance on configuration management[失效連結]
  24. ^ MIL-HDBK-61B Configuration Management Guidance. [2021-02-09]. （原始內容存檔於2021-02-11）. 
  25. ^ MIL-STD-3046 Configuration Management （頁面存檔備份，存於網際網路檔案館）, 6 March 2013 and canceled on June 1st, 2015
  26. ^ Defense Acquisition Guidebook
  27. ^ Systems Engineering Fundamentals
  28. ^ Configuration Management Plan. [2021-02-09]. （原始內容存檔於2021-02-28）. 
  29. ^ Configuration Management for Transportation Management Systems Handbook. Federal Highway Administration. [2012-03-28]. （原始內容存檔於2020-10-30）. 
  30. ^ Configuration Management Case Study. PACO Technologies, Inc. [2012-03-28]. （原始內容存檔於2016-08-26）. 
取自「https://zh.wikipedia.org/w/index.php?title=配置管理&oldid=85291386」