配置管理與變更管理精選(九篇)

前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的配置管理與變更管理主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：配置管理與變更管理范文

關鍵詞 軟件配置管理；軟件生命周期；KCFlow

DOI DOI： 10.11907/rjdk.162381

中圖分類號： TP301

文獻標識碼： A 文章編號 文章編號： 16727800（2017）002002603

0 引言

隨著軟件規(guī)模的日益增大，軟件復雜度逐步提高，軟件產(chǎn)品處于不斷更新變化中，為了確保整個軟件項目生命周期內(nèi)產(chǎn)品的完整性、一致性和可追蹤性，必須對軟件進行配置管理。

軟件配置管理（SCM，Software Configuration Management）指標識和確定軟件系統(tǒng)配置項的過程，在軟件系統(tǒng)的整個生命周期內(nèi)控制這些項的投放和更改，記錄并報告配置的狀態(tài)和更改要求，驗證配置項的完整性和正確性[1]，通常包括配置標識、配置控制、配置狀態(tài)記錄、配置審核等活動。軟件配置管理是整個軟件開發(fā)生命周期中一個非常核心的管理過程，貫穿了從需求分析、架構設計、項目管理、開發(fā)、集成及測試的全過程，可以有效管理配置項版本，記錄配置項開發(fā)過程，保證軟件質(zhì)量，提高軟件重用率。

在軟件開發(fā)這個龐大而復雜的過程中，涉及到各方面人員，產(chǎn)生許許多多產(chǎn)品。由于規(guī)程過于繁瑣，手工方法實施軟件配置管理是難以想象也是不可能的，因此，有效的軟件配置管理需要結合工具來實現(xiàn)。使用軟件配置管理工具，可以確保軟件項目中基線和配置項隨時保持條理清晰，迅速找到工作產(chǎn)品，保證工作產(chǎn)品的版本、內(nèi)容不會出錯，提高管理水平。

1 工具介紹

軟件配置管理工具KCFlow采用C/S架構，以軟件配置管理項的版本管理為核心，具有軟件配置策劃管理、變更控制、產(chǎn)品一致性管理、軟件問題追蹤管理、軟件配置審計管理等功能，實現(xiàn)了對配置管理工作的全流程、全方位支持。

KCFlow具有以下特點：C/S軟件架構使項目中的各類人員可以在工具提供的平臺上分布式工作，確保各項工作有序、規(guī)范地實施；具有策劃配置項標識功能；支持獨立的配置項，單獨策劃入庫、出庫和更動審批，能夠自動按照策劃結果實施入庫、出庫和更動控制；支持基線的多版本管理功能；支持用戶自定義軟件問題類別、問題級別、更動類別等，以適應不同的使用需求；支持多個軟件開發(fā)人員在線提交軟件入庫申請、出庫申請、更動申請等。

2 軟件配置管理

軟件配置管理是CMM重要的過程域，本文結合配置管理工具給出配置管理實施方法。

項目啟動后，配置管理組根據(jù)項目情況策劃配置管理活動并建立配置管理系統(tǒng)。首先制定配置管理計劃，根據(jù)計劃建立配置管理系統(tǒng)，通過版本控制、變更控制、基線管理和配置審核等方法，對配置管理系統(tǒng)中的工作產(chǎn)品實施控制和監(jiān)督。軟件配置管理流程如圖1所示。

圖1 軟件配置管理流程

2.1 配置管理計劃

經(jīng)過批準的軟件配置管理計劃是實施軟件配置管理活動的依據(jù)[2]。在進行配置管理前應根據(jù)項目的具體情況制定軟件配置管理計劃，內(nèi)容包括：

（1）確定配置管理機構和人員職責，審批流程。組織機構主要有軟件配置控制委員會、軟件配置管理組。軟件配置控制委員會負責出入庫控制、變更及基線的建立和；軟件配置管理組負責相關制度的建立和維護、工具的推廣、培訓和技術支持、配置管理審核等。

（2）描述具體配置管理活動，包括標識要納入配置管理的配置項，規(guī)定提交時間、確定項目研制各階段的基線、基線建立的時機和配置管理項等。配置項根據(jù)控制力度分為基線配置項和非基線配置項兩類?；€配置項一般包括軟件研制任務書、軟件需求規(guī)格說明、設計說明、設計文檔、測試文檔、代碼、用戶手冊等；非基線配置項包括計劃類文檔、開發(fā)環(huán)境、會議紀要等。標識配置項為每個軟件配置項賦予唯一的標識符。在軟件開發(fā)生存周期中，軟件配置項標識應包括文檔標識、程序標識和數(shù)據(jù)標識等[3]。

（3）確定更動申請流程及更動申請方法。

（4）描述配置管理報告內(nèi)容、報告時機、報告人和通告對象等。

（5）制定配置審核時機、審核內(nèi)容及審核問題的解決方法，軟件配置管理所使用的工具、技術和方法。

使用KCFlow配置管理平臺，制定配置管理計劃，并依據(jù)配置管理計劃實時自動化約束配置管理活動，客觀記錄配置管理活動。KCFlow可對配置管理計劃中的機構組織、基線、基線下包含的配置管理項、工作產(chǎn)品標識、問題類型、問題來源、更動流程、修改類別、項目基本信息等進行配置策劃。一般基線策劃有3條：功能基線、分配基線和產(chǎn)品基線。配置項標識應按照相關的配置項標識規(guī)范進行，一般文檔、程序標識采用以下格式表示：文件名稱英文縮寫 V主版本號.次版本號；問題類型可分為程序、文檔、數(shù)據(jù)庫等；問題來源有計劃、方案、設計、編碼、數(shù)據(jù)庫、測試、使用和維護等。

2.2 配置管理系統(tǒng)

配置管理計劃經(jīng)過評審后，由配置管理員依照配置管理計劃建立開發(fā)庫、受控庫和產(chǎn)品庫，對庫結構進行策劃，明確基線內(nèi)容，定期備份配置管理庫，為相關人員分配權限并發(fā)送用戶帳號信息單給相關人員。

開發(fā)庫、受控庫和產(chǎn)品庫應獨立管理。開發(fā)庫存放開發(fā)過程中需保留的各種信息；受控庫存放已通過評審且作為階段性產(chǎn)品的軟件配置項；產(chǎn)品庫存放已定型（鑒定）供交付生產(chǎn)、檢驗驗收的軟件配置項。在KCFlow中創(chuàng)建受控庫一般包括功能基線、分配基線、產(chǎn)品基線及非基線配置項。功能基線包含軟件研制任務書等文檔；分配基線包含軟件需求規(guī)格說明、接口需求規(guī)格說明等文檔；產(chǎn)品基線包含軟件設計說明、接口設計說明、軟件測試說明、軟件測試報告、固件保障手冊、源代碼、目標碼、軟件版本說明、軟件研制總結報告、軟件配置管理報告、軟件質(zhì)量保證報告等；非基線配置項主要包含計劃類工作產(chǎn)品。

2.3 配置控制

配置控制是配置管理的組成部分，包含評估、協(xié)調(diào)、批準/拒絕、配置項的變更[4]。配置庫建好后，配置管理員按照配置管理計劃進行日常的配置管理活動，主要包括版本控制、變更控制、基線管理等。

2.3.1 基線管理

基線是軟件生命周期中各開發(fā)階段的一個特定點，它的作用是把開發(fā)各階段工作明確劃分，使本來連續(xù)的工作在這些點上斷開，以便于檢查和肯定階段成果[5]，是進一步開發(fā)的基礎。

在軟件生命周期中主要有3種基線：功能基線、分配基線和產(chǎn)品基線。功能基線是開展軟件研制工作的依據(jù)，一般是在軟件研制任務書評審并納入受控管理后建立；分配基線在軟件需求規(guī)格說明評審并納入受控管理后建立；產(chǎn)品基線在產(chǎn)品后建立。

基線包含的配置項全部入庫后才可建立基線，配置管理員提交《基線建立和申請單》，通過軟件配置控制委員會審批通過授權后，方可建立和基線。基線后，配置管理員要把基線的結果通告給相關人員，通告內(nèi)容包括基線名稱和標識、所包含的配置項及配置項版本等信息。

對基線的變更需要通過正式的變更流程來完成。首先提出變更請求，然后進行變更評估，變更批準后再進行變更。變更評估包括：軟件變更分類、技術影響分析、接口影響分析、進度及預算影響分析。

2.3.2 變更控制

對已進入受控庫和產(chǎn)品庫的任一軟件配置管理項的更改，要履行規(guī)定的申請和審批手續(xù)。配置管理工具KCFlow提供了兩種更動流程供選擇，一般采用的更動流程是：填寫問題報告、提出更動申請、更動出庫、實施和驗證更動和更動入庫，具體更動流程如圖2所示。

（1）發(fā)現(xiàn)問題，并填寫《問題報告單》。變更人發(fā)現(xiàn)問題后首先填寫問題報告單，在問題報告單中詳細描述問題，說明問題來源并對問題進行分析，確定問題類型。

（2）提出更動申請，填寫《更動申請單》?！陡鼊由暾垎巍芬敿毺顚憜栴}來源、問題類別、問題級別、更動類型和修改類別等，描述更動方案、影響域分析及驗證辦法，待更動申請批準后方可進行更動。

（3）更動出庫。更動申請通過審批后，更改實施人填寫《更動出庫單》，審批通過后，檢出待更改的配置項準備實施更動。待更改配置項出庫后，處于待更動狀態(tài)，禁止其他人使用。

圖2 更動流程

（4）實施和驗證更動。更動出庫后可由變更實施人對待更動配置項實施更改，并請同行專家驗證變更結果。驗證結果合格后將變更后的配置項更動入庫，如果驗證沒通過，則重新實施更改。

（5）更動入庫。更動完成并通過驗證后，變更實施人填寫《更動入庫申請單》。審批通過后，將更動后的配置項更動入庫。

2.3.3 版本控制

版本控制是全面實施軟件配置管理的基A，其目的是按照一定的規(guī)則保存配置項的所有版本，避免發(fā)生版本丟失或混淆等現(xiàn)象，保證產(chǎn)品的可追溯性[6]。對配置項在初次完成時確定初始版本，在每次更改后確定新的版本。版本號由主版本號和次版本號組成，當發(fā)生更改時，若變動較大，次版本號加0.1，若變動較小，次版本號加0.01。

2.4 配置管理記錄和報告

配置狀態(tài)記錄和報告通常稱為配置狀態(tài)紀實。配置狀態(tài)記錄主要對配置管理活動進行記錄和報告，一般包括以下內(nèi)容：配置項紀錄（名稱、標識和版本）、變更紀錄、基線紀錄、出入庫紀錄、審核紀錄、備份記錄和測量信息等。

配置管理工具KCFlow可以根據(jù)配置庫中的內(nèi)容生成配置狀態(tài)報告，確保配置管理報告和配置管理庫的客觀一致性。在項目每個階段結束時，配置管理員從KCFlow導出該階段的配置狀態(tài)報告，總結該階段的配置管理活動，統(tǒng)計配置管理相關數(shù)據(jù)，并將配置狀態(tài)報告發(fā)送給相關人員。

2.5 配置審核

配置審核是一種軟件驗證方法，其目的是檢查軟件產(chǎn)品和過程是否符合標準和規(guī)程，是變更控制的補充。配置審核包括功能配置審核、物理配置審核和管理配置審核。

功能配置審核一般由項目經(jīng)理審核配置項的實際功能特征是否達到功能基線文檔中所規(guī)定的要求。物理配置審核是通過對配置項的檢測，鑒定文、圖、物的一致性，保證軟件更改的完整性。配置管理組定期（每季度）進行配置管理審核。配置管理審核主要是對配置管理過程進行審核，確認配置管理記錄和配置項是否完整、一致和準確。審核過程中，相關人員按照審核內(nèi)容形成《配置審核檢查單》，對不符合項進行記錄和處理。

KCFlow具有靈活的配置審核功能，能夠策劃適合本單位的軟件配置管理審核準則。每次入庫時，相關人員進行物理審核，在基線建立及變更時進行功能審核。

圖3 配置審核策劃

3 結語

軟件配置管理貫穿整個軟件生命周期，在軟件開發(fā)過程中采用有效的工具進行配置管理，能夠彌補人工管理出現(xiàn)的紕漏，規(guī)范開發(fā)流程，保證軟件產(chǎn)品質(zhì)量，減少軟件缺陷，縮短軟件開發(fā)周期，降低軟件維護成本。本文結合配置管理工具，對軟件配置管理流程及實施方法進行了研究。為提高軟件開發(fā)的效率與質(zhì)量，今后的工作中應結合項目實際情況及本單位的配置管理相關規(guī)定，對配置管理工具的適應性進行研究，以滿足各種軟件開發(fā)要求。

參考文獻：

[1] 石柱.軟件工程標準手冊[M].北京：中國標準出版社，2007.

[2] 何新貴，石柱，王緯，等.GJB5000軍用軟件能力成熟度模型實施指南[M].北京：國防工業(yè)出版社，2004.

[3] 王忠貴，劉姝.航天型號軟件工程方法與技術[M].北京：中國宇航出版社，2015.

[4] 董越.未雨綢繆理解軟件配置管理[M].北京：電子工業(yè)出版社，2012.

第2篇：配置管理與變更管理范文

【關鍵詞】配置項 基線配置 標識配置 控制

隨著軟件技術的發(fā)展，組織提升軟件研制能力顯得越來越重要并且迫切。而軍用軟件，尤其是嵌入式軟件的開發(fā)往往伴隨硬件設備的研制而開展，其研制周期長，需求變更頻繁，參與人員多，可能出現(xiàn)軟件版本丟失、多重S護、開發(fā)過程混亂等問題。GJB5000A-2008《軍用軟件研制能力成熟度模型》中明確配置管理的目的和專用實踐，通過配置管理可以較好的解決以上問題。

1 組織機構、角色和職責

組織應成立項目的配置控制委員會（以下簡稱CCB）。CCB一般由來自不同領域的項目利益相關方的代表組成，而且有能力在管理上作出承諾，對提出的配置項的變更進行評價、批準或不批準。其中，配置管員作為配置管理活動的直接責任人負責制定配置管理計劃、配置狀態(tài)報告、實施配置審核。

2 基于GJB5000A的配置管理活動

2.1 建立基線

2.1.1 標識配置項

配置項作為配置管理的對象，在項目策時進行識別，并對其賦予唯一標識號，形成配置項列表。包括：

（1）識別軟件配置項：軟件配置項主要包括為本項目開發(fā)的軟件配置項以及重用的軟件配置項、訂購方提供的軟件配置項、分承制方開發(fā)的軟件配置項、采購的軟件配置項等。其中，軟件配置項的劃分主要從下列因素進行權衡：軟件功能、規(guī)模、重用計劃、關鍵性、接口考慮等。

（2）識別配置文件：配置文件指定義軟件配置項的功能特性或物理特性的文件，或從這些內(nèi)容發(fā)展而來的關于其驗證、使用、保障要求的技術文件。一般包括：需求文檔、設計文檔、測試文檔、用戶文檔等。

2.1.2 建立一個配置管理系統(tǒng)

要使配置項在軟件生命周期中受控，應建立有統(tǒng)一的存儲介質(zhì)、規(guī)程和訪問方式的配置管理系統(tǒng)：

（1）建立配置庫。

開發(fā)庫：存放配置項文件的集合。是一個動態(tài)的庫，相當于開發(fā)人員的工作區(qū)，存放在該庫中的配置文件只需要開發(fā)者進行版本控制即可。

受控庫：存放已通過測試或評審且作為階段性產(chǎn)品的軟件配置項的集合。配置項的入庫、出庫、更改均需通過訪問及變更控制規(guī)程進行。

產(chǎn)品庫：存放已定型（鑒定）且供交付、生產(chǎn)、檢驗驗收的軟件配置項的集合。在項目通過定型或鑒定后，將受控庫中的產(chǎn)品基線通過流程轉(zhuǎn)入該庫。

（2）訪問控制規(guī)程：對非基線配置文件和基線配置文件可采用以下兩類控制方式：

開發(fā)控制：開發(fā)期間，進行版本管理，若需更改只作簡單跟蹤即可；

正式控制：若需要更改，必須通過正式更改控制規(guī)程才能進行更改，由顧客參與的高層CCB控制。

（3）配置庫的備份：制定正確的備份與恢復策略，并加以實施。

2.1.3 基線

在項目策劃時定義項目需要建立的基線，對其賦予唯一標識號，并文檔化每條基線應包含的配置文件，形成基線列表。

（1）在系統(tǒng)設計與分析階段結束時建立功能基線：包括經(jīng)過評審的定義軟件配置項技術要求的文件，如：軟件研制任務書、接口控制文件、軟件技術協(xié)議等。

（2）在需求分析階段結束時建立分配基線：包括經(jīng)過評審的分配到軟件功能模塊需求的文件，如：軟件需求規(guī)格說明。

（3）在產(chǎn)品定型或鑒定時建立產(chǎn)品基線：包括經(jīng)過確認的作為軟件產(chǎn)品生產(chǎn)、交付、使用、保障活動基礎相關文件，如：安裝包、用戶手冊等。

2.2 跟蹤和控制更改

2.2.1 跟蹤更改申請

（1）提交變更申請：需要變更時，提交變更申請，并填寫建議的更改方案。

（2）變更影響域分析：項目組主要從以下幾方面進行分析。

該軟件更改是否滿足軟件本身功能、性能、軟件質(zhì)量要求；

對項目工作量、進度、成本的影響；

是否引起其他軟件配置項、相關的設計文件/圖樣更改；

對在制品和已交付產(chǎn)品的影響以及處理措施；

對于在多個產(chǎn)品中使用的配置項，其更改可能解決本項目中的問題，而在其他應用中是否有影響；

更改等級分析：按照更改的內(nèi)容及影響范圍，可將更改進行分級控制。

（3）CCB審批：項目組與利益相關方一起評審該變更申請。

（4）跟蹤更改申請的狀態(tài)：更改申請被提交后就應對其進行狀態(tài)跟蹤，直到更改實施完畢并經(jīng)過批準。

2.2.2 控制配置項

變更申請經(jīng)過批準后，對問題配置項進行更改控制：

（1）出庫：經(jīng)過批準的變更申請可以作為出庫依據(jù)，對存在問題的配置項出庫。

（2）更改并驗證：項目組針對新需求或存在的問題進行更改。更改后，應對更改內(nèi)容進行評審或測試，以確保更改不會引入新的問題等。

（3）入庫：通過驗證后，項目組應根據(jù)更改級別提交相應CCB審批后檢入受控庫生成新的版本。

2.3 建立完整性

2.3.1 建立配置管理記錄

（1）收集配置管理相關表單：配置管理員收集、整理配置管理過程中產(chǎn)生的相關表單。

（2）生成配置狀態(tài)報告：在項目配置項狀態(tài)發(fā)生變更后，配置管理員應生成配置狀態(tài)報告，并向項目組和利益相關方配置狀態(tài)信息。

2.3.2 執(zhí)行配置審核

配置審核是指確認所產(chǎn)生的基線和文檔符合指定的標準或需求。配置審核類型包括：

（1）功能配置審核：目的是驗證配置項的所測功能特征是否已達到其功能基線文檔中所規(guī)定的需求，且操作和支持文檔是否完備和滿意。相當于文文相符審查。

（2）物理配置審核：目的是驗證構造的配置項是否符合定義它的技術文檔。相當于文實相符審查。

（3）配置管理審核：目的是確認配置管理記錄和配置項是否完備、一致和準確，配置管理工作開展與配置管理標準和規(guī)程是一致的。

3 結束語

軟件配置管理作為GJB5000A-2008軟件研制能力等級認證中必須開展的活動，也是其他軟件工程化活動的基礎。通過開展軟件配置管理，可使軟件在整個生命周期中狀態(tài)清晰可控、可追溯，是提升軟件產(chǎn)品質(zhì)量的重要保證。

參考文獻

[1]GJB5000A-2008，軍用軟件研制能力成熟度模型[S].

[2]GJB 5716-2006，軍用軟件開發(fā)庫、受控庫和產(chǎn)品庫通用要求[S].

[3]GJB3206A-2010，技術狀態(tài)管理[S].

第3篇：配置管理與變更管理范文

梁 娜 賈志淳 渤海大學信息科學與技術學院 遼寧錦州 121000

【文章摘要】

在軟件整個的生命周期中都伴隨著軟件配置管理。軟件配置管理對于軟件而言有著非常重要的作用，能夠為軟件的研發(fā)提供管理辦法與活動原則。本文對軟件配置管理的地位進行了分析，指出了軟件開發(fā)過程中軟件配置管理的實施與控制。

【關鍵詞】

軟件開發(fā)；軟件配置；量化管理

軟件配置管理的主要內(nèi)容包括軟件及其相關內(nèi)容出現(xiàn)的變化。在軟件整個的生命周期中都伴隨著軟件配置管理，在軟件開發(fā)的過程中發(fā)揮著管理辦法與活動原則的重要作用。軟件配置管理中包括多種管理模式，為軟件的質(zhì)量管理、過程改進與項目管理提供保障。在軟件開發(fā)過程中配置管理實施方法的研究中，具體項目配置管理的實施措施成為了研究的重點問題，通過有效的配置管理實施措施實現(xiàn)配置管理理論與軟件開發(fā)過程的相互結合。

1 軟件配置管理概念

1.1 軟件配置管理的主要內(nèi)容

軟件項目的需求在計算機深入應用的背景之下不斷復雜化、多變化。在軟件整個的生命周期中，配置管理逐漸成為了非常關鍵的控制過程，發(fā)揮著越來越重要的作用。

在軟件整個的生命周期中，軟件配置管理主要的作用包括兩個方面，一方面是對軟件的演化過程進行記錄，另一方面是對軟件產(chǎn)品進行跟蹤與管理。在軟件配置管理過程中，具體的內(nèi)容包括版本控制、軟件配置庫建立、軟件機線記錄、配置追蹤等，這些內(nèi)容是通過對軟件修改及其修改生產(chǎn)的配置項進行控制、記錄與追蹤來實現(xiàn)的，從而確保軟件產(chǎn)品的可控性與完整性。

在軟件開發(fā)的整個過程中，完整的軟件配置管理應該在軟件開發(fā)的整個過程中進行覆蓋，包括軟件的開發(fā)、軟件的測試、軟件的變更及軟件的文化等，同時還要從整體上對軟件的整個開發(fā)過程進行宏觀管理與控制，從而確保軟件開發(fā)過程的可預測性較強。軟件產(chǎn)品具有可重復與可追溯的特性，從而促進軟件開發(fā)效率與質(zhì)量的提高，實現(xiàn)軟件項目產(chǎn)品完整性的建立與維護，對軟件開發(fā)資源進行維護與集成。

1.2 軟件開發(fā)中軟件配置管理的重要性

軟件配置管理方法的發(fā)展主要包括三個階段：第一，以文件為基礎的軟件配置管理，該階段的軟件配置管理特征為以版本控制為主。第二，隨著軟件項目規(guī)模的擴大與復雜程度的提高，實現(xiàn)了以項目為基礎的軟件配置管理，實現(xiàn)了元數(shù)據(jù)與配置項隔離存儲。第三，以文件訪問為基礎的軟件配置管理，在保持了第二代配置管理特征的前提下實現(xiàn)了更多特性的增加。例如，能夠?qū)崿F(xiàn)文件的透明訪問，開發(fā)人員可以在不保留本地副本的情況下對受控制配置項進行訪問。此外，還實現(xiàn)了軟件配置管理與軟件變更管理、軟件分析、軟件測試等軟件開發(fā)各個環(huán)節(jié)結合的強化，從而形成了更加全面的軟件開發(fā)管理法方案。

在軟件開發(fā)的過程中，由于技術不斷發(fā)展與人員流動頻繁等原因，需要對開發(fā)過程中形成的文檔、數(shù)據(jù)及代碼等進行統(tǒng)一的管理與維護，實現(xiàn)知識產(chǎn)權庫的建立，將較為零散的研發(fā)進行積累，進而將其轉(zhuǎn)化為項目所共有的知識產(chǎn)權，從而提高軟件開發(fā)工作的效率，實現(xiàn)軟件研發(fā)周期的縮短，增強軟件產(chǎn)品的核心競爭力。 軟件配置管理與軟件項目開發(fā)之間存在著非常密切的聯(lián)系。實現(xiàn)軟件產(chǎn)品的管理是配置管理的最終目標。隨著用戶需求的變動，軟件也處于不斷的變化過程中，為了能夠有效地對軟件產(chǎn)品進行跟蹤與控制，配置管理需要對靜態(tài)的與動態(tài)的產(chǎn)品都進行管理工作。因此，軟件配置管理與軟件開發(fā)有著緊密的聯(lián)系。在軟件開發(fā)的各個環(huán)節(jié)中都必須貫穿配置管理：對用戶需求進行管理，對其實施進行監(jiān)控， 從而確保用戶的需求能夠在產(chǎn)品的各個版本中都得到最終的落實，同時用戶需求能夠在軟件產(chǎn)品的開發(fā)過程中提供相應的幫助；對用戶出現(xiàn)的新的需求進行及時、有效地相應；實現(xiàn)新的開發(fā)周期的推動等。通過有效的軟件配置管理工作實現(xiàn)了對軟件開發(fā)的控制，用戶對軟件產(chǎn)品的需求遵循嚴格的流程經(jīng)過受控的生產(chǎn)流水線之后形成產(chǎn)品，最后將用戶發(fā)售給用戶。在整個過程中，不同的角色都有著自身非常明確的職責，但是相互之間有能夠互相銜接與協(xié)調(diào)。

在軟件開發(fā)的過程中，軟件配置管理奠定了非常堅實的基礎，提供了協(xié)作開發(fā)的環(huán)境，規(guī)范了軟件開發(fā)的流程，實現(xiàn)軟件開發(fā)流程的規(guī)范化，促進軟件研發(fā)效率的提高。

2 軟件開發(fā)過程中的軟件配置管理實施分析

2.1 軟件開發(fā)中配置管理的實施流程

在軟件開發(fā)的過程中，其主要的流程為：分析需求——設計體系結構——開發(fā)與變更代碼——集成軟件——測試—— 交付等幾個環(huán)節(jié)。軟件配置管理的主要活動階段集中在軟件項目開發(fā)與維護的階段中。在項目計劃階段中，配置管理的主要活動包括配置管理計劃的制定。項目開發(fā)維護階段是軟件項目研發(fā)中非常關鍵的階段，開發(fā)維護階段包括軟件設計、軟件研發(fā)、測試與等。軟件配置管理在整個的項目開發(fā)、維護階段中都實現(xiàn)了覆蓋。

2.2 軟件開發(fā)中配置管理的工作流程

軟件配置管理在項目開發(fā)與維護階段中主要的活動包括以下幾個方面：第一，配置管理人員所承擔的管理與維護工作；第二，開發(fā)人員、集成人員執(zhí)行的配置管理策略；第三，流程的變更。這三個方面的活動之間存在既相互獨立有相互聯(lián)系的關系。

2.3 軟件配置管理實施的關鍵活動

在軟件開發(fā)的整個過程中，軟件配置管理活動的實施內(nèi)容主要包括標識配置、版本控制、狀態(tài)統(tǒng)計、配置審計等幾個方面。配置標識指的是對配置項的名稱進行定義；版本管理指的是在軟件開發(fā)的過程中，對各種變更行為或版本信息進行記錄工作；狀態(tài)統(tǒng)計指的是對軟件的開發(fā)進度實現(xiàn)量化；配置審計指的是檢驗軟件實施過程與軟件信息項的正確性。

3 軟件開發(fā)過程中的軟件配置管理策略

3.1 軟件開發(fā)過程中的版本管理策略

在軟件配置管理中，版本控制是非常關鍵的問題之一。版本的主要功能是對配置項的當前狀態(tài)進行記錄，從而為后續(xù)的開發(fā)提供參考與借鑒，同時還能夠?qū)χ暗陌姹緺顟B(tài)進行追溯。在對版本進行管理的過程中，其主要的功能指的是對軟件生存期中信息項的修改與變化進行管理。除此之外，版本對于并行開發(fā)實現(xiàn)了支持， 從而能夠?qū)Π姹就絾栴}進行有效的解決，還能夠為不同開發(fā)者之間的交流提供便利，降低由于版本不同、溝通不暢等原因造成的編碼錯誤、重復勞動等問題。

在軟件配置管理策略中包括多個方面的內(nèi)容，例如可變粒度策略、并行開發(fā)策略、構件策略等，其中應用最為廣泛的就是并行開發(fā)策略，能夠?qū)Σ煌挠脩粜枨蠹邦l繁的更改要求進行滿足，尤其適用于大型軟件研發(fā)項目。

并行開發(fā)策略在對軟件項目進行管理的過程中，通過團隊模式實現(xiàn)其整體同步的變更，從而確保所有的開發(fā)人員能夠在同一軟件模塊上進行工作，而且能夠在相同的時間針對相同的代碼進行不同的修改，這些修改之間并不會產(chǎn)生干擾情況。通過并行開發(fā)策略一方面實現(xiàn)了軟件開發(fā)人員的協(xié)同工作，另一方面也實現(xiàn)了對軟件開發(fā)過程的整體控制。應用并行開發(fā)策略能夠?qū)崿F(xiàn)資源最大限度的調(diào)動，在相同的時間內(nèi)研發(fā)出更多的軟件功能，降低軟件研發(fā)的周期，促使軟件研發(fā)過程實現(xiàn)了規(guī)?；c規(guī)范化。

3.2 軟件開關過程中的配置項標識策略

在軟件配置管理中，其控制與管理的工作單元就是配置項。在配置項管理中包含有所有的需要記錄變更或者狀態(tài)的元素。例如，開發(fā)環(huán)境中的開發(fā)工具，維護環(huán)境中的項目管理工具、產(chǎn)品設計中的產(chǎn)品規(guī)格說明文檔、編碼過程中的執(zhí)行元素等，這些都能夠成為軟件配置管理中的配置項。

配置項的粒度可大可小，元素可多可少。配置項的粒度越大，其管理成本的就越低，其配置進度也越低。一般情況下，將相同的工作任務之下的一組元素稱之為一個配置項，通過對元素的組合管理來實現(xiàn)管理成本的節(jié)約。

3.3 軟件開發(fā)過程中的策略

在軟件的過程中，系統(tǒng)目標碼版本包括系統(tǒng)執(zhí)行碼、系統(tǒng)參數(shù)等。軟件開發(fā)過程中的策略為軟件的構建了統(tǒng)一的環(huán)境，為軟件的正確集成提供了保障，為開發(fā)人員的后續(xù)研發(fā)工作奠定了非常堅實的基礎。在軟件版本進行的過程中，首先需要項目經(jīng)理對軟件版本的交付進行確定，在其確定交付之后，配置管理人員開始實現(xiàn)軟件版本標簽的建立，對版本的開發(fā)環(huán)境進行標識。首先從之前的軟件版本中對發(fā)行版本進行檢出，之后針對軟件版本進行鏈接編譯工作，在可執(zhí)行代碼完成之后由測試人員進行各項測試工作，測試成功之后將軟件版本交由配置管理委員會進行審核，審核通過之后配置管理人員就能夠進行文件生成工作，同時還要實現(xiàn)開發(fā)權限的解凍工作。

4 總結

與西方發(fā)達國家相比，我國的軟件配置管理發(fā)展還存在較大的差距。在未來的發(fā)展過程中，軟件配置管理將發(fā)揮越來越重要的作用，將逐漸實現(xiàn)自動化、規(guī)?；?。在未來的研究過程中，要將持續(xù)改進與針對性作為管理模式的研究方向。通過過程管理質(zhì)量的提高，實現(xiàn)軟件配置管理的規(guī)范化，提高我國軟件產(chǎn)業(yè)的發(fā)展速度。因此，實現(xiàn)通用、便捷、高效的軟件配置管理模式的設計與開發(fā)成為了未來軟件配置管理研究工作中的重點內(nèi)容。

【參考文獻】

[1] 楊麗紅, 李志蜀, 袁曉玲, 肖靜.CMMI2 級中配置管理過程域的研究和實施[J]. 計算機應用， 2012，S1（53）：404-406+409.

[2] 張曉燕, 孫亮清. 軟件配置管理在船舶監(jiān)控軟件項目中的實施[J]. 上海船舶運輸科學研究所學報， 2013，02（53）：57-61.

[3] 張昭瑜，韓學為，張建偉，吳仲光， 彭君凱. 解析軟件配置管理在軟件開發(fā)平臺中的應用[J]. 知識經(jīng)濟， 2014，10（63）：93.

[4] 鐘林輝, 陳宇, 劉洋, 謝冰, 邵維忠. 軟件配置管理系統(tǒng)XML 數(shù)據(jù)模型及原型研究[J]. 計算機工程與應用，2011，19（64）：82- 84+120.

[5] 鄒祎久. 基于DO-178B 及CMMI 的機載軟件開發(fā)配置管理技術研究[J]. 南京廣播電視大學學報（計算機光盤軟件與應用），2013，11（36）： 230+232.

[6] 張彬. 軟件企業(yè)質(zhì)量管理核心過程——設計開發(fā)過程的控制[J]. 世界標準化與質(zhì)量管理，2012，01 （53）：11-14.

[7] 郭萍, 潘振海. 軟件配置管理系統(tǒng)── CIMS 實驗工程軟件配置管理的計算機輔助工具[J]. 冶金自動化，2014，02（51）：7-10+21+58.

[8] 裴樹軍, 陳德運, 陳曉雪. 軟件配置管理在軟件開發(fā)平臺中的應用[J]. 哈爾濱理工大學學報，2010， 01（54）：28-32.

【作者簡介】

第4篇：配置管理與變更管理范文

關鍵詞：運維體系、服務臺、事件管理、問題管理、變更管理、管理、配置管理

運行維護方案

1.1 方案設計思路

本方案的設計思路是：按照IT服務管理理論、方法和標準，結合用戶實際和建設需要，遵循立足需求、統(tǒng)一規(guī)劃、保障重點、分步實施、務求實效的原則，建立一套融合組織、制度、流程、人員、技術為一體的IT服務管理體系，建立組織機構，制定規(guī)章制度，規(guī)范管理流程，明確職責分工，強化技術支撐，使技術團隊能夠以此為依托，實現(xiàn)對用戶應用的綜合管理監(jiān)控和日常技術支持，快速響應和及時解決信息系統(tǒng)運行過程中出現(xiàn)的各種問題和故障，確保用戶應用的正常、穩(wěn)定、高效運行。

建立一個完善的IT服務管理體系，首先需要切合用戶需求和用戶特點。

本方案運行維護的用戶群可歸納為兩大類：

 內(nèi)部用戶：包括用戶、相關單位等；

 外部用戶：進行用戶業(yè)務辦理、查詢的單位和個人。

在方案實施時，將進行詳細調(diào)研，系統(tǒng)整理和規(guī)劃服務對象類型和數(shù)量，制定針對性的服務設計，滿足不同用戶的服務期望。

維護對象包括機房、網(wǎng)絡、主機和服務器、應用軟件等。

在需求調(diào)研中，需要規(guī)劃配置管理方案，確定配置屬性，梳理配置關系。同時對于不同維護對象，各有技術特點，需要制定針對性的運維技術手冊。

運維團隊由用戶信息中心、（總）集成商、集成商、應用開發(fā)商共同組成，可概括為三個服務團隊體系：服務臺、內(nèi)部運維團隊和外部運維團隊。

1.1.1 本項目運維體系設計重點

在本項目運維服務體系設計中，重點投入在服務支持建設上，服務支持描述了所提供的IT 服務日常支持和維護活動相關的過程，是在實現(xiàn)運維支撐平臺中最常用到的模塊。

服務支持主要功能模塊有：服務臺與事件管理、問題管理、變更管理、管理、配置管理。

1.1.1.1 服務臺與事件管理

服務臺是組織機構內(nèi)為所有IT 用戶所提供的單一、集中的聯(lián)系點，它處理所有事故、查詢和請求。它為所有其它服務支持過程提供了一個接口。

事件管理負責管理所有事故從檢測和記錄到解決和完成的所有內(nèi)容。事故管理的目標是快速有效地響應最終用戶，使它們能夠迅速恢復工作，以減小對最終用戶的影響。

事件管理涉及主要活動如下：

(1) 事件查明和記錄

(2) 分類和初步支持

(3) 調(diào)查和診斷

(4) 解決和恢復

(5) 關閉

1.1.1.2 問題管理

問題管理的目標是最小化事故和問題對業(yè)務的負面影響。為了達到這個目標，問題管理通過管理所有主要事故和問題來輔助事故管理，問題管理盡力記錄所有的工作環(huán)境并對相應已知錯誤進行“快速修補”，并且在可能時產(chǎn)生變更以實施持久的結構性的解決方案。問題管理也對事故和問題進行分析和趨勢分析，以預見性的預防進一步事故和問題的發(fā)生。

問題管理涉及主要活動如下：

(1) 問題識別、記錄和歸類

(2) 問題評審

(3) 調(diào)查和診斷

(4) 解決和關閉

(5) 已知錯誤識別和記錄

(6) 已知錯誤分類和評估

(7) 已知錯誤解決和關閉

1.1.1.3 變更管理

一個單一的集中化的有效和高效地處理變更的變更管理過程，是任何IT 機構成功運營的關鍵。在變更從啟動和記錄到過濾、評估、分類、授權、調(diào)度、建設、測試、實施以及最終的審核和收尾的整個生命周期中，必須謹慎仔細地對其進行管理。此過程的一個關鍵成果是前向變更調(diào)度（FSC-Forward Schedule of Change），它是基于業(yè)務影響和緊急性的所有領域都同意變更的一個中央程序。

變更管理涉及主要活動如下：

(1) 啟動、接受和分類

(2) 評估和審批

(3) 安排和分配

(4) 建設

(5) 實施

(6) 關閉

1.1.1.4 管理

管理過程采用了對IT 服務變更的整體全局視野，它考慮的所有技術和非技術方面。管理負責組織機構內(nèi)所使用的所有硬件和軟件的所有法律和合同義務。為了實現(xiàn)此目標并保護IT 資產(chǎn)，管理為定義硬件庫（DHS-Definitive Hardware Store）中的硬件和定義軟件庫（DSL- Definitive Software Library）中的軟件建立了一個安全的環(huán)境。

管理負責控制版本變更的頻度。這涉及到對變更的整合或?qū)⒆兏植鸪筛〉陌姹灸K。這些舉措基于一系列對業(yè)務需求、員工需求（開發(fā)、測試、實施、運作）和用戶/業(yè)務影響的權衡考慮。

管理涉及主要活動如下：

(1) 啟動、接受請求

(2) 策略制定

(3) 實施計劃制定

(4) 方案審批

(5) 構建測試環(huán)境

(6) 實施

(7) 對實施結果測試

(8) 結束

1.1.1.5 配置管理

配置管理提供了成功的IT 服務管理的基礎，它支持著所有其它過程。其基礎成果是配置管理數(shù)據(jù)庫（CMDB)，在數(shù)據(jù)庫中包含了一個或多個綜合數(shù)據(jù)庫詳細描述了組織機構中的所有IT 基礎設施組件以及其它重要的相關的資產(chǎn)。就是這些資產(chǎn)提供了IT 服務，它們也被稱之為配置項（CIs)。CMDB 同普通的資產(chǎn)注冊所不同之處在于那些關系、或鏈接，它們定義了每個配置項（CI）如何互連以及如何同其鄰居相互依賴。這些關系允許執(zhí)行例如影響分析和“如果..將會…”等的活動。理想情況下，CMDB 也包含了同每個CI 相關的所有事故、問題、已知錯誤和變更的細節(jié)。

配置管理涉及主要活動如下：

(1) 登記組成服務的資產(chǎn)信息；

(2) 登記這些資產(chǎn)之間的關系；

(3) 確保配置管理信息庫中的各類相關信息能夠得以及時更新。

1.2 運維體系設計內(nèi)容

運維體系設計內(nèi)容包括：運維組織架構、角色與職責、運維相關流程、運維工作表單、服務度量指標。

1.2.1 運維組織架構

運維組織架構包括涉及運維管理的所有單位、部門、人員的組織信息，用樹形層次結構記錄，作為運維系統(tǒng)基礎數(shù)據(jù)管理。

為確保整個運維工作的協(xié)調(diào)運轉(zhuǎn)，建議采用分級管理模式規(guī)劃運維組織架構，即組建運維服務臺，三級運維支持部門協(xié)同工作，共同完成運維工作。

建立統(tǒng)一接入的服務臺，實行中央控制，分級授權的集中式加分布式的服務臺設計。當最終用戶提出請求或者需對應用系統(tǒng)進行主動運維時，運維服務臺作為呼叫受理反饋部門接受服務請求，并提供一線幫助。對于無法解決的問題，提交二線也即系統(tǒng)運維組處理，運維服務臺同時進行跟蹤和催辦。

系統(tǒng)運維組包括內(nèi)部運維團隊和外部運維團隊，作為核心團隊負責運行維護和管理工作，針對應用系統(tǒng)進行主動運維，并解決運維服務臺轉(zhuǎn)交的請求，在必要時協(xié)調(diào)供應商、開發(fā)商等外部資源。

供應商、開發(fā)商作為三線支持，對運維中心提供二線不能解決的問題支持。

采用上述分級管理的工作模式，可以按照運維人員的不同技術能力分配到一、二、三線，實現(xiàn)了運維人員的專業(yè)化分工；對于技術要求相對較低的一線可根據(jù)工作量的增長及時增加，確保服務呼叫處理率，對于承擔核心運維工作的二線人員，避免了初級服務請求的直接處理，保證其對關鍵應用和緊急故障的處理，可以大大提高運維服務效率和質(zhì)量；同時，分級管理的工作模式充分發(fā)揮不同人員的技術能力，克服了高能低用情況的發(fā)生，降低了運維服務總體成本。

1.2.2 角色與職責

本方案運維管理的角色與職責設置，將以ITILV3標準為參考，結合總集成商歷年來大量的運維服務實踐，針對本項目用戶進行設計。所涉及的角色及職責的定義，主要包括服務臺、事件管理、問題管理、變更管理、管理、配置管理各個角色和職責。例如，服務臺、一線工程師、二線工程師、事件經(jīng)理、問題經(jīng)理、問題分析工程師、變更經(jīng)理、變更咨詢委員會、配置管理員等角色。

各類角色在運行維護過程中承擔不同的職責，并將在方案實施時根據(jù)用戶特點進行完善。

1.2.3 運維相關流程

運維相關流程的定義和設計，根據(jù)用戶的業(yè)務需求特點進行定義，主要包括服務臺、事件管理、問題管理、變更管理、管理、配置管理、知識管理等流程。

在本方案實施時，將進行運行服務流程設計。主要流程設計工作內(nèi)容包括：

1、服務臺/事件管理流程設計

2、問題管理/知識管理流程設計

3、變更管理流程設計

4、配置管理流程設計

1.2.4 運維文檔體系

建立文檔體系是進行運行維護服務中持續(xù)進行的工作。完善的文檔體系有助于維護團隊工作持續(xù)性，維持穩(wěn)定的客戶服務能力。如運維流程類文檔（事件報障信息表單、發(fā)起問題信息表單、變更申請表單、管理申請表單、配置信息記錄表單等）、服務器、數(shù)據(jù)庫日常維護操作類文檔；日常檢查模板；日常溝通工作模板、應用流程等等，這類標準化文檔的建立，將規(guī)范運維管理，改善運維效率。

文檔體系的建立并非易事，因此需要從思想上重視并不斷更新文檔，嚴格按文檔實施操作，要監(jiān)督文檔質(zhì)量等。

文檔體系的建設包括兩方面內(nèi)容：

1、文檔體系完善

2、規(guī)范梳理和固化

在實際運維中，由于運維活動具有多樣性、復雜性，規(guī)范的制訂往往跟不上運維實際的要求。但結合客戶業(yè)務需要，有選擇地制訂關鍵的運維規(guī)范不失為一種有效方法。

定義：這里的規(guī)范指運維過程中應該遵循的、客戶導向的行為約定。包括操作方法、結果提交方式、運維過程控制點的確認等。以升級為例：故障出現(xiàn)后，故障的等級判斷標準，處理時長與升級的關系，升級的途徑和相關人等，都受升級規(guī)范的約束。

流程的梳理是一個漸進的過程，規(guī)范內(nèi)容也會隨用戶系統(tǒng)生命周期、運維局勢不同而及時調(diào)整。對于規(guī)范梳理，需關注兩方面的內(nèi)容：

 其一是目前運維中影響較大、問題較多急需明確的流程；

 其二是明確確認規(guī)范的主體。

另外和規(guī)范相關的接口有客戶和項目組，需分別進行梳理，并區(qū)分其各自不同的特點。明確責任，合理分工。這部分工作是服務持續(xù)改善計劃的難點所在。

1.2.5 服務度量指標

制定服務度量指標，對運維系統(tǒng)制定內(nèi)部和外部服務管理級別，對員工制定員工績效考核標準。

規(guī)劃的工作內(nèi)容如下：

 配合用戶技術支持部門梳理所有現(xiàn)有SLA相關資料編制服務目錄；

 完善和鞏固服務目錄，同時加強客戶溝通和宣傳，讓更多客戶充分了解服務團隊目前提供的服務內(nèi)容；

 基于ITIL建立標準的服務水平管理流程，規(guī)范定義包括服務水平管理計劃、客戶需求管理、服務水平確定、OLA磋商、UC需求確定、SLA簽署、監(jiān)控和回顧等在內(nèi)的各項服務水平管理活動；

 建議采用需求調(diào)研表和訪談的方式對客戶的IT服務需求進行收集、整理和分析，從而確定服務水平需求；

 由客戶服務部依據(jù)與客戶簽訂的SLAs將相關的具體指標細化為各分相關職能部門的OLA，并與分解相應UC到對應供應商；

 利用工具監(jiān)控和收集實際的服務水平管理數(shù)據(jù)，并通過與SLA的比較發(fā)現(xiàn)差距生成報告，交由OLA和UC支持團隊進行改進；

 建立服務水平協(xié)議回顧和檢查過程；

第5篇：配置管理與變更管理范文

圖2 漸進式實施ITIL流程圖

對企業(yè)IT部門來說，實施ITIL Service Support（服務支持）的意義在于清晰梳理日常IT運維管理過程中遇到的各種各樣的事，使IT運維過程變得有序連貫，從而提高IT服務的能力和水平。

ITIL Service Support能夠形象地描述IT運維的工作內(nèi)容。在ITIL框架下，一項IT服務已經(jīng)像工業(yè)化流水線上的商品一樣，體驗著IT運維流程化帶來的高效率和高質(zhì)量。

當條件不成熟的時候，爆發(fā)式實施ITIL，一鍋端的方式是不合適的，實踐證明效果也很差的。目前較為普遍的方式是漸進式，通過初期、中期和遠期三個階段循序漸進地實施ITIL。

對企業(yè)來說，實施ITIL的最大意義在于把IT與業(yè)務緊密地結合起來，從而讓企業(yè)的IT投資回報達到最大；對IT部門來說，實施ITIL Service Support的意義在于清晰地梳理出日常IT運維管理過程中各種各樣的事，使IT運維過程變得有序連貫，從而提高IT服務的能力和水平。

流程化做事風格

ITIL Service Support的流程（圖1所示）清晰地表達出一個認知：服務因事而起，因事而終。

在ITIL框架下，一項IT服務已經(jīng)像工業(yè)化流水線上的商品一樣，體驗著IT運維流程化帶來的高效率和高質(zhì)量。流水線式的服務引發(fā)了對原有IT服務組織結構的調(diào)整，統(tǒng)一的服務臺配合新的管理制度解除了客戶直接調(diào)用工程師的弊端。不同的事經(jīng)過服務臺識別、分配后，進入事件管理，隨之事的身份變換為事件、事故、問題、已知錯誤、變更、，完成一項服務由事發(fā)到消除的生命周期。

凡事皆有因。對IT運維來說，因自用戶而起，事自服務臺而入。服務臺作為一項管理功能，它每天遇到的事最多，包括報修、投訴、咨詢、商業(yè)機會乃至騷擾等。如果沒有服務臺，這些事都會混雜在一起進入IT運維的各個服務小組。有了服務臺，每一件事都會經(jīng)過梳理、分配，然后站隊、排位，該去哪里去哪里。作為IT運維流程的起點，服務臺做事始終要將“下一個流程”的意識貫穿于工作之中，不能亂排位置、亂指揮。

安排妥當后進入事件管理環(huán)節(jié)。事件管理需要解決的事都是屬于已知的可控服務范疇的，也可以理解為是事件管理根據(jù)與問題管理協(xié)商而定的事件管理范圍，是經(jīng)過識別處理后服務臺轉(zhuǎn)過來的事。事件管理其實就是響應速度的管理。響應時間短、處理速度快是事件管理的要求。只要影響事件響應速度的事一旦發(fā)生，事件管理就需要做一個簡要的分析和診斷，要么提出可行的快速解決方案或應急措施，要么在沒有更好辦法的情況下將其立即升級為事故。

超出事件管理能力范疇并提請升級的事故在ITIL中稱之為“問題”。雖然事的性質(zhì)在升級之后發(fā)生了變化，但事件管理里有關它的所有信息都將作為問題管理的參考依據(jù)，協(xié)助問題管理尋找問題發(fā)生的根源。同樣，問題管理需要想辦法盡快將問題轉(zhuǎn)變?yōu)橐颜业絾栴}根源的“已知錯誤”，提供應急措施或最終的解決方案以幫助事件管理盡快地恢復用戶的業(yè)務運行。

并不是每一個問題都需要走變更管理流程。變更管理的目的是糾正錯誤、解決問題。從這一點看，變更管理是在糾正錯誤的事。一般而言，問題管理分析出已知問題，提交RFC到變更管理，變更管理進行解決?？墒且坏┳兏芾砜刂频貌粐?，沒有對進行充分地測試，那么對事件管理和問題管理而言那又將是新事件、新問題的起源。

管理做什么？管理是對變更做實質(zhì)性執(zhí)行的流程，不僅要忠實地執(zhí)行變更，而且還要考慮將要安裝的配置項、將要停止使用的配置項以及退出使用的配置項。成功與否，需要事件管理提供的錯誤記錄來確認。由于事關重大，有計劃、有步驟地做事是管理過程的重要特征。

配置管理是一項基礎性的管理工作。配置管理做的事不比服務臺少，而且做好了容易被忽視，做得不好又很容易被發(fā)現(xiàn)。吃力不易討好地做事是配置管理工作的真實寫照。有人認為ITIL Service Support中最重要的就是配置管理，因為它是服務臺和5個管理流程穩(wěn)定運行的基礎。一個及時、完整、準確的配置庫將會給IT服務帶來極大的自信：我之所以能夠做到準確地提供IT服務，是因為我有一個非常完備的配置庫和運作良好的配置管理流程。

對于IT部門來說，實施ITIL Service Support最大的改變是做事的方法：從忙亂過渡為井井有條，從過去的跨組協(xié)調(diào)轉(zhuǎn)變?yōu)橐灰载炛牧鞒涕g協(xié)作。這樣，不僅提高了效率，更關鍵的是流程化的工作方式在慢慢改變著員工的工作思路。IT運維強調(diào)的是“服務”二字，與職能化的管理模式相比，流程協(xié)作更能體現(xiàn)出服務意識，從而影響到員工的工作習慣，進而形成工作成習慣、習慣成自然的效果。

漸進式實施

ITIL帶給IT部門的好處讓人心動，但如何實施ITIL是很多人心中的疑惑：是十個流程同時實施，還是一個接一個地實施，抑或是某些流程打包在一起先實施？如何通過實施ITIL最終實現(xiàn)IT運維的可控、在控和能控？雖然沒有具體統(tǒng)一的實施標準，但根據(jù)經(jīng)驗來看，ITIL流程的實施基本上是兩種方式：漸進式和爆發(fā)式。爆發(fā)式實施曾在一些企業(yè)的IT部門使用過，但效果很差。究其原因，最根本的是當條件不成熟的時候，一鍋端的ITIL實施方式是不合適的。目前較為普遍的方式是漸進式實施。

從圖2中我們可以看到，漸進式實施ITIL是一個循序漸進的過程。它有初期、中期和遠期三個階段。初期一般只實現(xiàn)服務臺、事件管理和配置管理。雖然這只是一小部分的流程，但走好這一步不僅可以提高ITIL實施的信心，而且能夠為以后的實施打下牢固的基礎。

第6篇：配置管理與變更管理范文

關鍵詞 ITIL；運維；服務；流程

中圖分類號：TP311 文獻標識碼：A 文章編號：1671-7597（2014）03-0149-03

隨著黃山煙草信息化建設的深入推進，信息系統(tǒng)的規(guī)模不斷擴大，公司各種業(yè)務對信息系統(tǒng)的依賴性越來越大，同時IT系統(tǒng)日趨復雜、系統(tǒng)維護要求越來越高。尤其是專賣管理、卷煙營銷、物流配送等業(yè)務對IT運維管理的要求越來越高。IT硬件和軟件應用的也不斷增漲，其環(huán)境復雜，多系統(tǒng)、多數(shù)據(jù)庫和多應用平臺、多廠商網(wǎng)絡及系統(tǒng)設備的網(wǎng)絡運行環(huán)境，使網(wǎng)絡維護難度成幾何倍數(shù)的增長，系統(tǒng)管理人員的工作壓力越來越大。ITIL作為運維IT管理的新理論、方法和工具，正在發(fā)揮著越來越重要的作用。

1 黃山煙草IT運維的特點及問題

在IT系統(tǒng)生命周期中。系統(tǒng)建設的時間和成本只占相對小的一部分，而系統(tǒng)運行維護階段占了整個時間和成本的主要部分，可以說IT系統(tǒng)是三分建設、七分運維，足見IT運維的重要性。當前，黃山煙草的信息化工作已從IT系統(tǒng)建設為主逐步進入建設和運維并重的新階段。傳統(tǒng)的IT運維管理思路及方法所帶來的弊端逐漸顯現(xiàn)，具體如下。

1）由于實施經(jīng)驗、行業(yè)視角的原因，難免在體系建設的科學性、系統(tǒng)性及完整性等方面存在缺陷，更缺乏從服務運維生命周期全局的角度去審視思考的經(jīng)驗。

2）由于受到信息部門人力資源逐步收縮的限制，如何平衡好、處理好系統(tǒng)建設與服務運維、應急處理與項目管理控制之間的關系，往往成為長期困擾運維人的難題。

3）缺乏對運行維護工作的規(guī)范性管理，信息中心服務運維團隊依然常常扮演應急排障的救火者角色，往往缺乏對信息系統(tǒng)的適用性、主動性運維。

4）缺乏統(tǒng)一的集中監(jiān)控與管理平臺，無法快速定位故障源，更無法發(fā)現(xiàn)潛在故障，都是問題發(fā)生時才想解決辦法，缺乏提前預警機制。

5）缺乏對日常運行維護工作的管理工具，目前的系統(tǒng)管理工具已無法滿足日常管理的需要，值班、運維等工作流程還體現(xiàn)在紙介質(zhì)記錄上。

6）缺乏量化運行質(zhì)量的工具，無法對運維人員進行有效考核，運維人員運維的價值得不到體現(xiàn)

如何盡快建立規(guī)范、高效的IT運維管理運行體系，實現(xiàn)對企業(yè)核心業(yè)務系統(tǒng)的IT 監(jiān)控管理，提高IT 運維管理水平，如何在有限的資源基礎上支撐起龐大而復雜的信息系統(tǒng)服務運維，達到穩(wěn)定、規(guī)范及高效的IT運維的管理目標，已經(jīng)成為黃山煙草信息化管理亟待解決的重要問題。

2 基于ITIL的IT運維平臺的構建與應用

ITIL即IT基礎架構庫，目前已經(jīng)發(fā)展到了第三個版本，該標準旨在于通過對企業(yè)流程進行梳理提升企業(yè)IT資源的利用率和服務質(zhì)量。本文擬提出基于ITIL的服務臺管理系統(tǒng)的總體業(yè)務模型，從流程、服務及管理活動等方面對該系統(tǒng)進行闡述，以期提供較為全面的業(yè)務服務管理解決方案。

ITIL最佳實踐基于IT運維管理的四大核心流程組，即業(yè)務與IT規(guī)劃（Businss-IT Alignment）、IT運營維護（IT Operations Management）、IT運維保障（IT Operations Assurance）、IT服務管理（IT Service Management），并采用IT運維管理質(zhì)量改進循環(huán)（Deming Circle）進行持續(xù)改進。

圖1 PDCA模型

計劃（Plan）階段：IT高層管理者或IT部門經(jīng)理根據(jù)業(yè)務部門的需求制定相應的IT服務策略與目標，在評估實現(xiàn)這些目標所需的服務水平與成本等因素后，產(chǎn)生詳細的實施計劃。

實施（Do）階段：IT服務經(jīng)理執(zhí)行計劃（Plan）階段產(chǎn)生的實施計劃，對流程、表單、報表、KPI等做出修正，使之更加符合實際業(yè)務的需要，同時收集相關運行數(shù)據(jù)以度量它的績效。

檢查（Check）階段：在成功實施了新的計劃后，IT服務經(jīng)理檢查實施的效果，發(fā)現(xiàn)IT運維中出現(xiàn)的新的問題與瓶頸，并通過分析相關運行數(shù)據(jù)找到問題與瓶頸的根本原因，并匯報給IT高層管理者。

改進（Improve）：IT高層管理者或IT部門經(jīng)理根據(jù)檢查（Check）階段的檢查結果決定需要采取的進一步行動，例如，修正流程缺陷、進一步標準化流程等，以提高IT運維管理的效率。

1）系統(tǒng)建設目標。服務臺作為受理用戶服務申請或報障的服務窗口，運維中支持級別：一線支持、二線支持和三線支持。一線人員主要由服務臺人員及桌面服務人員組成，其中桌面服務采取外包方式進行；二線主要由系統(tǒng)及應用維護負責人組成；三線人員主要由信息中心系統(tǒng)研發(fā)人員、外部專家與合約期內(nèi)的外部維護商組成。這三線服務運維服務人員通過運維管理系統(tǒng)內(nèi)的服務運維流程實施運維管理，各個支持級別人員負責各個級別的系統(tǒng)事件或故障，由服務臺統(tǒng)一協(xié)調(diào)服務運維資源，跟蹤督促實事件進度，促進事件高效解決。

圖2 IT服務運維管理體系

2）功能模塊邏輯架構，如圖3。

圖3 功能模塊邏輯架構

從總體上看，可以將IT運維管理的功能模塊分為兩大類：流程模塊和非流程模塊，流程模塊有自助服務臺、有服務臺&事故、問題、變更、、作業(yè)計劃和自定義流程擴展模塊（任務管理），非流程模塊有CMDB，服務水平管理和知識庫管理。

在功能模塊之外，IT運維管理提供2類重要的接口，它們是監(jiān)控系統(tǒng)告警接口和二次開發(fā)接口。這兩個接口主要為IT運維管理的擴展提供重要的支撐。整個IT運維管理系統(tǒng)的最底層是業(yè)務管理流程（BPM）引擎，該引擎支撐IT運維管理的所有流程模塊。

服務臺主要支持IT基礎設施的日常運行和維護管理，包括事件管理、問題管理、變更管理、管理和配置管理等ITIL服務支持流程，如圖4所示。

圖4 ITIL服務支持流程架構圖

①服務臺&事故管理：事故管理的目的主要是支撐ITIL中的事件管理流程，涵蓋事件的整個生命周期。目的是記錄、解決及跟蹤IT服務運作過程中發(fā)生的事故，并使用戶可以盡快恢復自己的正常工作，避免業(yè)務中斷，將事故對業(yè)務運營的影響降至最低。服務臺即連接用戶與IT部門以處理上述事故的連接點。于是，服務臺與事故管理相結合就構成了從事故發(fā)生到得到解決的首要流程，同時，服務臺記錄下事故以及事故解決方案的有效信息，以備其他流程（例如問題管理）參考。由于監(jiān)控系統(tǒng)中發(fā)現(xiàn)的告警是事件的一個重要來源，因此，IT運維管理提供與監(jiān)控系統(tǒng)告警的接口。

②問題管理：問題是指一個或幾個已暫時處理但根本原因尚不明確的事件，許多事件往往是由同一個問題引起的。

問題管理流程查明突發(fā)事件或錯誤產(chǎn)生的根本原因，并制訂解決問題的方案和防止錯誤再次發(fā)生的措施，將由問題和突發(fā)事件對業(yè)務產(chǎn)生的負面影響減少到最低。用戶能夠非常方便地將問題與突發(fā)事件和變更關聯(lián)起來，并且很快地找到相應的解決方案?；蛘咴诙ㄎ粏栴}的根本原因后，產(chǎn)生相應的應急措施以及最終解決方案。對于那些由于成本、技術等原因，暫時不予消除的問題，可以置為已知錯誤，留待日后解決。

③變更與管理：變更管理確保在變更實施過程中使用標準化的方法和流程，盡快和有效地實施變更，從而把由于變更所導致的事件對IT 服務的影響減小到最低，同時改善了公司的日常運作。它包括一套完整的變更管理功能，包括變更的發(fā)起、審批、影響評估、派發(fā)實施等功能，以工單的形式在各部門和責任人之間流轉(zhuǎn)。

通過管理流程能夠有計劃的將軟件和硬件的成功地導入實際應用環(huán)境中。也可以設計一些有效的流程來將變更導入系統(tǒng)中，同時在整個和導入過程中保持IT 部門和客戶之間的信息溝通。

變更與管理、配置管理緊密結合的，當新引起IT基礎架構的變化時，配置管理數(shù)據(jù)庫也需要進行實時的更新，同時的內(nèi)容：如最終軟件版本，硬件規(guī)格說明、裝配指南、升級安裝手冊和網(wǎng)絡配置等都要關聯(lián)到配置管理數(shù)據(jù)庫中。

④配置管理：配置管理的總體目的是提供一個統(tǒng)一、一致的流程來管理IT基礎架構中的各個組成部份，以確保：所有資源被正確識別、資源當前和歷史狀態(tài)得到記錄、資源記錄的完整性得到維護和確認、IT生產(chǎn)環(huán)境的穩(wěn)定性、確保IT設備的有效控制和管理。

配置管理的活動包括：配置規(guī)劃、配置識別、配置項基線控制、配置審計等。配置管理提供系統(tǒng)配置功能，包括報警配置、事件配置、視圖配置、用戶權限、監(jiān)測配置等供配置控制模塊調(diào)用。IT部門可以通過此模塊簡單的進行配置控制，對配置信息進行變更，對系統(tǒng)設置進行管理。

⑤CMDB（Configuration Management Database）：CMDB全稱為Configuration Management Database，即配置管理庫。它是最佳實踐的核心模塊，所有的用戶關注的資源，包括各種軟件、硬件、應用、業(yè)務單位、人員等，均被識別為配置項（Configuration Item ）并存儲在CMDB。默認配置項類型包括主機、網(wǎng)絡設備、無線AP、存儲設備、辦公設備、數(shù)據(jù)庫、郵件服務器、中間件、Web Server、基礎應用、業(yè)務服務、資源等。

CMDB模塊是整個ITOM一個核心，主要支撐ITIL中的配置管理。CMDB模塊是一個非流程模塊，主要是管理各類配置項的屬性信息和關系信息，為其它流程模塊集成配置項信息。

⑥知識庫模塊：知識庫模塊的目的為用戶提供一個IT運維經(jīng)驗和知識積累與共享的平臺。IT運維人員可以將自己的經(jīng)驗總結為知識出來，其它的人員就可以對該知識進行查找和借鑒，這樣就能在IT組織內(nèi)有效的實現(xiàn)知識共享機制，從而提高整個組織的工作效率。在知識庫庫模塊中，可以對知識進行新建、審核、和查詢，還提供對知識的關注和收藏、轉(zhuǎn)發(fā)、評價等功能。

3 實施ITIL的幾點建議

建立任何高可用性的系統(tǒng)，都必然要涉及人員、流程和技術三個方面，實施ITIL也不例外，著名的“木桶理論”告訴我們：一只木桶盛水的多少，并不取決于桶壁上最高的那塊木塊，而恰恰取決于桶壁上最短的那塊。人員、流程和技術三個要素也就像組成一個木桶的三塊木板，任何一個要素的短缺，都會影響到最終提供服務質(zhì)量的高低。

充分了解ITIL體系，全面領會ITIL思想，培養(yǎng)ITIL人才。ITIL不是一種產(chǎn)品，而是一系列最佳實踐經(jīng)驗，充分了解ITIL體系是項目成功實施的基礎。ITIl的實施，大多都是對現(xiàn)行IT服務管理的顛覆，不光要IT部門人員要成為ITIL專家，普通客戶也要了解ITIL體系。ITIL不是可以“包治百病”，ITI項目實施完畢，并不等于服務質(zhì)量和運維風險都得到了控制或改善。

循序漸進的實施ITIL，結合企業(yè)自身實際，建立科學合理的流程。

ITIL是管理科學在信息技術中的應用，它描述了一系列基于過程的IT服務管理最佳實踐經(jīng)驗，并沒有說明具體的日常運營活動，也沒有特別針對任何特殊的平臺或技術，只是理論上的指導，如同質(zhì)量、安全體系一樣，如何結合實際應用進行落地，是整個項目的關鍵所在。哪些流程是必須的？組織內(nèi)所有的流程都要實施嗎？哪些流程需要重組、變革？投入的資源足夠做所有的流程嗎？所有流程都需要結合企業(yè)自身實際，循序漸進的、科學合理的進行設計。

實行嚴格的項目管理制度，重視溝通管理。一方面要建立專門的項目小組，確定項目管理的內(nèi)容，制定項目管理跟蹤、考核機制。根據(jù)項目進度制定項目控制節(jié)點（基線、里程碑）；另外要重視項目的溝通管理，既要注重業(yè)務部門和IT部門的溝通，更要重視與項目實施單位乙方的溝通。

4 結束語

企業(yè)IT服務管理的建設是一個長期的過程，雖然有ITIL理論作為指導，但是要真正形成適應自身企業(yè)發(fā)展的IT服務管理體系，仍需要經(jīng)過不斷探索完善，規(guī)劃好足夠的充裕時間來實施ITIL是非常關鍵的一點，此外，在實施任何新的ITIL流程之前，必須了解組織目前所處的狀態(tài)和想要達到的目標，這是確保實現(xiàn)成功實現(xiàn)ITIL最佳實踐的關鍵成功要素。

參考文獻

[1]曹漢平，王強，賈素玲.現(xiàn)代IT服務管理：基于ITIL的最佳實踐[M]. 北京：清華大學出版社.

[2]朱海林，等.IT服務管理、控制與流程[M]. 北京：機械工業(yè)出版社.

[3]左天祖，劉偉.中國IT服務管理指南[M].北京：北京大學出版社，2005.

第7篇：配置管理與變更管理范文

關鍵詞:管道;生產(chǎn)管理系統(tǒng);運行維護;管理

中圖分類號：C93文獻標識碼： A

1 管道生產(chǎn)管理系統(tǒng)

管道生產(chǎn)管理系統(tǒng)主要包括調(diào)運管理、運銷計量管理、計劃管理、能耗及周轉(zhuǎn)量管理、天然氣用氣需求預測、日指定、輔助功能、統(tǒng)計報表、SCADA數(shù)據(jù)采集、對外接口等10 個模塊。

1.1 調(diào)運管理

實現(xiàn)調(diào)度日報的生成，調(diào)度指令、場站作業(yè)的起草、審批及下達，值班日志的填報，成品油批次計劃的起草及下達、收發(fā)球管理等功能；實現(xiàn)生產(chǎn)調(diào)度過程的監(jiān)管與控制。

1.2 運銷計量管理

從SCADA 系統(tǒng)及相關系統(tǒng)自動獲取計量交接數(shù)據(jù)，并實現(xiàn)管道計量交接數(shù)據(jù)、氣質(zhì)分析數(shù)據(jù)、原油化驗數(shù)據(jù)的審核和上報、統(tǒng)計報表的匯總、運銷臺帳及銷售結算單的自動生成。

1.3 計劃管理

實現(xiàn)原油、成品油、天然氣銷售計劃的制定、審批及下發(fā)及計劃完成情況的跟蹤分析。

1.4 能耗及周轉(zhuǎn)量管理

實現(xiàn)輸油氣周轉(zhuǎn)量的自動計算、能耗統(tǒng)計數(shù)的上報、自動匯總及報表展現(xiàn)，實現(xiàn)能源統(tǒng)計指標和工藝參數(shù)的自動計算。

1.5 天然氣用氣需求預測

根據(jù)歷史用氣量、氣象數(shù)據(jù)、經(jīng)濟模式等因素預測客戶的天然氣用氣需求，為日指定、銷售計劃、管輸計劃等的制定提供支持。

1.6 日指定

根據(jù)合同要點進行客戶用氣日指定管理，實現(xiàn)氣田、終端供應量、儲氣庫吞吐能力及客戶需求量的綜合平衡。

2 運行維護管理體系

管道生產(chǎn)系統(tǒng)以運行維護管理的最佳實踐ITIL（信息技術基礎架構庫）理念為核心，以先進的運行維護管理平臺為手段，開展各項運行維護工作。

2.1 運行維護工作內(nèi)容

運行維護計劃制定：主要包括運行維護工作目錄的確定、運行維護工作進度安排、服務級別管理、服務改進計劃、成本及費用預算。

日常運行維護管理：主要包括用戶支持、系統(tǒng)巡檢、用戶培訓、軟硬件維護及配置及變更管理等。

突發(fā)事件處理：主要包括應急預案的編制及演練、災備系統(tǒng)建設、突發(fā)事件的處理等等。

系統(tǒng)拓展：主要包括新投管道及新建組織機構的系統(tǒng)實施工作。

功能提升：主要包括新功能的開發(fā)建設、軟硬件平臺的升級、系統(tǒng)性能優(yōu)化等等。

2.2 運行維護流程

以ITIL v3 體系為藍圖，結合項目自身特點制定了配置管理、變更管理、事件管理、問題管理、管理、知識管理等6 個操作流程。

配置管理：指識別和確認系統(tǒng)的配置項，記錄和報告配置項狀態(tài)，根據(jù)用戶的請求完成變更及檢驗配置項的服務管理流程。變更管理：在規(guī)定時間內(nèi)完成基礎架構或服務的變更而對其進行控制的服務管理流程。事件管理：指對引起或有可能引起服務中斷或服務質(zhì)量下降的事件進行處理的管理流程。問題管理：指通過調(diào)查分析查明事件發(fā)生的潛在原因，并制定解決方案和防止再次發(fā)生的措施，將問題對業(yè)務產(chǎn)生的負面影響降到最低的服務管理流程。管理：是負責計劃與實施IT 服務變更的管理流程，通過規(guī)范的流程控制服務及測試的過程，確保應用系統(tǒng)的質(zhì)量。知識管理：是進行知識庫內(nèi)容收集、更新、檢索以及知識應用、知識關聯(lián)的服務管理流程。

2.3 運行維護理論

ITIL 是CCTA（英國國家計算機和電信局）于20 世紀80 年代末開發(fā)的一套IT 服務管理標準庫，其將英國各個行業(yè)在IT 管理方面的最佳實踐歸納起來變成規(guī)范，旨在提高IT 資源的利用率和服務質(zhì)量。

管道生產(chǎn)管理系統(tǒng)的運行維護工作在借鑒ITIL理念的基礎上，制定了配置管理、變更管理、管理、事件管理和問題管理的具體操作流程，并在服務規(guī)劃、成本控制、年度總結等工作中充分吸收了ITIL 的服務級別管理、能力管理、IT 財務管理、IT 服務持續(xù)性管理、可用性管理的理念和方法論，實現(xiàn)了服務成本、服務能力與服務目標（用戶需求）的平衡與統(tǒng)籌規(guī)劃。

2.4 運行維護平臺

系統(tǒng)運行維護平臺主要包括事件報警平臺和運行維護流程管理平臺。事件報警平臺為HPOpenView 平臺中的OVO 和OVIS 軟件套件，能夠?qū)崿F(xiàn)系統(tǒng)狀態(tài)的監(jiān)控和自動化報警。運行維護流程管理平臺主要實現(xiàn)日常運行維護工作的流程化管理。事件報警平臺和運行維護流程管理平臺通過報表平臺進行數(shù)據(jù)展現(xiàn)，并為幫助臺的日常工作提供支持。

2.5 運行維護的實施

以ITIL v3 體系為基礎，對配置管理、變更管理、事件管理、問題管理、管理等進行了深入的梳理與研究，在借鑒最佳實踐的基礎上摸索出了符合項目實際的運行維護方法論，對運行維護工作起到了很大的支持作用。

在處理系統(tǒng)變更請求的過程中，項目組根據(jù)工作類型的不同對變更管理流程進行了細分，針對新建天然氣客戶這一類操作的規(guī)律性和重復性，制定了新增天然氣客戶的操作流程，作為變更管理的子流程專門用于新增客戶所需完成的基礎信息、權限、報表、工作流、數(shù)據(jù)流等一系列的操作。同時在運行過程中根據(jù)業(yè)務發(fā)展變化更新完善業(yè)務流程，使其運轉(zhuǎn)更加流暢。

通過運用可用性管理、服務級別管理、成本管理與持續(xù)性管理，對自身的服務提供能力進行了深入的分析與研究，進而明確了針對不同的服務所能達到的不同級別，同時將各種服務級別與對應的成本關聯(lián)起來，進一步量化了運行維護工作，也為運行維護工作的考核提供了科學的依據(jù)。

參考文獻：

[1] 趙宏振. FLUKE744在天然氣管道控制系統(tǒng)測試中的應用[J]. 自動化儀表. 2009(07)

[2] 周中.天然氣管道防腐問題的探討[J]. 煤氣與熱力. 2001(03)

第8篇：配置管理與變更管理范文

關鍵詞：IT運維；BSM；云網(wǎng)絡

航空服務管理是復雜的，并且是高度動態(tài)的，數(shù)千名乘客和行李在數(shù)以千計的飛機中轉(zhuǎn)移，在保持對所有細節(jié)監(jiān)控的同時確?？蛻臬@得最佳體驗對于管理是一個挑戰(zhàn)。同樣，云的運營環(huán)境是復雜和不斷變化的。數(shù)以千計的工作量在實體服務器之間傳輸，對各項數(shù)據(jù)細節(jié)進行持續(xù)監(jiān)測并確保最佳的終端用戶體驗也很難。

要積極主動地管理云環(huán)境，需要解決四大難題:

(1) 了解環(huán)境：收集、整合、分析和更新來自內(nèi)外部的各種不同數(shù)據(jù)來源；

(2) 掌控高度動態(tài)的環(huán)境；

(3) 應對“多米諾骨牌效應”――運營環(huán)境中的一個變化或問題可能會影響到數(shù)百個服務；

(4) 將服務請求管理自動化，使您可以對至少數(shù)百位用戶的服務請求進行快速響應。

業(yè)務服務管理(BSM)解決方案可以幫助您解決以上四個方面的挑戰(zhàn)。BSM以一個綜合性的方法和統(tǒng)一的平臺來幫助IT機構削減成本、降低風險，并提高業(yè)務利潤。BSM解決方案提供了多種自動化、管理和分析服務，使您能夠主動地管理云環(huán)境。

本文以下的四個戰(zhàn)略，可有助于您在云環(huán)境中實現(xiàn)主動運維：

一、了解環(huán)境：收集、整理、分析數(shù)據(jù)

如果您想有效地管理日新月異的混合數(shù)據(jù)中心，那么必須先了解您現(xiàn)有的實體的、虛擬的和云的環(huán)境，以及它們?nèi)绾谓M合在一起來提供商業(yè)服務。因為管理虛擬和云環(huán)境的復雜性在不斷增加，所以獲得實時數(shù)據(jù)會是一個挑戰(zhàn)。您可以利用很多不同的內(nèi)部資源――內(nèi)部服務器、主機、網(wǎng)絡設備、應用、存儲設備來收集詳細的數(shù)據(jù)。

挑戰(zhàn)來自于如何通過鞏固、規(guī)范和分析數(shù)據(jù)得到一個整體的IT服務狀態(tài)的概覽，BSM解決方案可以幫助您滿足這些要求。首先，BSM的自動探索和依賴映射解決方案，從不同來源收集數(shù)據(jù)，協(xié)調(diào)、規(guī)范并合并成一個可以供不同的服務管理工具共享的單一并統(tǒng)一的數(shù)據(jù)資源庫(即配置管理數(shù)據(jù)庫CMDB)。與此同時，BSM系統(tǒng)管理解決方案實時監(jiān)控系統(tǒng)性能和不同資源的情況，可以與實時服務框架以及CMDB同步，以確保服務框架不變的情況下仍然可以作出準確和及時的IT決策。該解決方案跨多種不同的平臺、供應商和數(shù)據(jù)來源，并規(guī)范、鞏固和分析性能數(shù)據(jù)以確定系統(tǒng)性能問題的根源。

二、保持對動態(tài)環(huán)境的控制

虛擬化為云計算提供了基礎，也大大增加了數(shù)據(jù)中心的動態(tài)性。在虛擬和云的環(huán)境中，包括服務器、網(wǎng)絡、應用和存儲在內(nèi)的資源都是虛擬化的。隨著工作量和業(yè)務需求的變化，這些虛擬化的資源正在被不斷配置和重新配置。因此，您要面對不斷變化并擁有大容量資源的環(huán)境。

1.探索

自動探索和依賴映射解決方案可以幫助您通過不斷掃描環(huán)境，持續(xù)維護當前的應用程序和基礎設施數(shù)據(jù)并相應更新服務模式。此外，一些績效管理解決方案能夠通過實時監(jiān)測環(huán)境的變化，通知CMDB數(shù)據(jù)庫來協(xié)調(diào)這些變化，確保服務模式的實時準確性。

2.變更和配置管理

影響動態(tài)數(shù)據(jù)中心的另一個要素是變更和配置管理。無論變化多么迅速，您都需要確保所有的變化遵守內(nèi)部政策和外部法規(guī)。您還需要確保變更管理流程不妨礙敏感的虛擬和云環(huán)境。在這里，BSM變更和配置管理解決方案可以助您解決該問題，BSM將一個包括變更審批、調(diào)度、執(zhí)行、驗證和跟蹤的閉環(huán)過程實現(xiàn)自動化。

3.操作

動態(tài)的云環(huán)境使操作也變得復雜。虛擬和云環(huán)境的根本就是一個高容量的變化體，這就要求您迅速適應不斷變化的容量需求。因此，您還需要了解和跟蹤容量變化的正常節(jié)奏，以及通過行為學習以支持未來的變化走向。只有這樣，您才能區(qū)分正常和非正常的波動，并消除虛假的警報。

BSM的系統(tǒng)管理解決方案集成了性能和配置管理解決方案，因此，就更容易確定近期配置的變化是否會造成性能問題，還可以自動學習和跟蹤虛擬和云環(huán)境的變化。如果沒有這項技術，那么，在動態(tài)的虛擬和云環(huán)境中，當變化對服務水平產(chǎn)生影響的時候，依靠手動的分析是無法確認的。

三、有效應對“多米諾骨牌效應”

虛擬化和云計算的主要目標是最大限度地提高資源利用率，同時確保最佳的性能。這意味著在同一個共享的資源上放置多項服務。然而，共享資源越多，發(fā)生問題時的影響越大。而且由于很多服務是共享的，一種服務的出現(xiàn)可能是與其他服務結合的結果。所以，任何一個服務產(chǎn)生問題都會對其他服務造成“多米諾骨牌效應”，這個骨牌效應特別會對公共云產(chǎn)生影響，因為公共云有廣泛的客戶基礎，而且會擴大商業(yè)影響。

BSM系統(tǒng)管理解決方案可以主動監(jiān)測物理、虛擬和云資源，并為潛在問題提供預警，然后自動評估并面向業(yè)務優(yōu)先解決關鍵問題，自動生成故障單，并附加根源和影響信息，加快生成問題的優(yōu)先順序和診斷。

您還需要注意容量管理，從而做到在保持服務質(zhì)量的前提下實現(xiàn)資源的高利用率。BSM解決方案可以對業(yè)務、應用、基礎設施和工作量的數(shù)據(jù)進行分析，以確保為業(yè)務服務提供更準確的容量。BSM解決方案還可以執(zhí)行“假設”分析來幫助您確定和規(guī)劃未來的容量需求。有了這些解決方案，無論現(xiàn)在還是未來，您都可以在不超支和增加運營資源的情況下規(guī)劃和安排您實際真正需要的容量。

四、自動化服務請求管理

第9篇：配置管理與變更管理范文

為了解決學生動手能力差、缺乏質(zhì)量觀念等問題，本文提出了以項目為驅(qū)動的基于CMM的軟件工程教學方案。其核心思想為：學生以項目組形式進行軟件項目研發(fā)，理論教學圍繞方法和工具來支撐項目，教師及組員共同把握CMM3級的“需求管理過程改進、項目跟蹤與監(jiān)督過程改進、軟件質(zhì)量保證過程改進、軟件配置管理過程改進”四個關鍵過程域，使軟件的開發(fā)過程文檔化、標準化。具體實施如下：

1.1項目組人員構成

依據(jù)項目規(guī)模，4-6名學生構成一個項目組，職責及任務分配如下（可兼職）：組長：協(xié)同教師組織管理整個開發(fā)過程。配置管理人員：對各種文檔、數(shù)據(jù)、代碼進行管理。質(zhì)保人員：執(zhí)行質(zhì)量保證計劃、測試計劃，并設計測試用例進行評審。需求專員：需求匯總以及需求規(guī)格說明文檔的撰寫。設計專員：概要設計和詳細設計，并撰寫相應的文檔。編碼及維護人員：依據(jù)設計編碼實現(xiàn)軟件系統(tǒng)，對實現(xiàn)的單元模塊進行單元測試、集成測試，完成交付后的維護工作。

1.2教師職責。

課堂教學應與項目進度無縫銜接，圍繞項目所處階段的技術和工具進行講解。項目伊始，教師指導小組長制定開發(fā)計劃及進度表，并在全程跟蹤和監(jiān)督執(zhí)行情況；其次，深入企業(yè)調(diào)研并結合GB8567-2006等軟件過程標準，制定CMM3文檔體系標準；最后，作為專家評審參與各項目組的測試與評審工作。

1.3需求管理過程改進。

需求管理是軟件工程非常關鍵的一個步驟，需求分析的完整與否直接影響到產(chǎn)品的成功交付，甚至導致軟件項目的終結。小組成員、用戶通過會議論證形式確定需求，由需求專員記錄并形成文檔資料，評審通過后提交至配置管理人員。

1.4項目跟蹤與監(jiān)督過程改進。

教師及小組組長在整個研發(fā)周期中執(zhí)行項目的跟蹤和監(jiān)督工作。根據(jù)項目的計劃，在指定的時間對項目的產(chǎn)品進行檢測，目的是規(guī)范軟件過程的流程，避免開發(fā)周期延遲的情況。

1.5軟件質(zhì)量保證過程改進。

軟件質(zhì)量保證是CMM中的一個關鍵過程域，直接影響軟件產(chǎn)品的質(zhì)量及交付。項目初期，質(zhì)保人員在教師的指導下制定質(zhì)量保證計劃并分階段檢查，如軟件結構的合理性、兼容性、易維護檢查等；其次，協(xié)同教師采用W模型對軟件產(chǎn)品進行測試和評估。在需求分析分析結束后，采用靜態(tài)測試方法，對需求規(guī)格說明文檔進行測試評審并提交測試報告；概要設計結束后結合需求規(guī)格說明，對概要設計說明書進行靜態(tài)測試并提交測試報告；詳細設計階段對詳細設計說明書進行評審，質(zhì)保人員著手設計測試用例，提交測試報告及測試用例文檔；編碼和集成階段，開發(fā)人員實現(xiàn)某一單元模塊后進行單元測試、模塊間的集成測試，提交測試報告；質(zhì)保人員依據(jù)設計的測試用例進行確認測試、系統(tǒng)測試工作，并最終提交軟件產(chǎn)品質(zhì)量評估報告。

1.6軟件配置管理過程改進。

軟件配置是一種通過標識和文檔來記錄配置項的管理工作，控制這些資料的變更、記錄和報告變更的過程狀態(tài)。每一過程活動結束都應提交評審通過的文檔、數(shù)據(jù)等資料，配置管理人員通過工具（比如VSS）進行入庫、授權修改管理，形成需求基線、設計基線、代碼基線及測試基線，使整個軟件產(chǎn)品資料齊全且版本一致，規(guī)范化管理。

2結束語