云計(jì)算技術(shù)中心配置管理流程設(shè)計(jì)與實(shí)現(xiàn)

1、云計(jì)算技術(shù)中心配置管理（CMDB）流程設(shè)計(jì)與實(shí)現(xiàn)目錄 HYPERLINK l _bookmark0 技術(shù)中心配置管理流程設(shè)定3 HYPERLINK l _bookmark1 配置管理（CMDB）設(shè)計(jì)的目的3 HYPERLINK l _bookmark2 關(guān)鍵角色、職責(zé)定義3 HYPERLINK l _bookmark3 配置控制委員會(huì)（Configuration Control Board，CCB）3 HYPERLINK l _bookmark4 項(xiàng)目經(jīng)理（Project Manager，PM）3 HYPERLINK l _bookmark5 配置管理架構(gòu)師（Configuration Man

2、agement Officer，CMO）4 HYPERLINK l _bookmark6 配置庫程序管理員（Program Librarian，PL）4 HYPERLINK l _bookmark7 項(xiàng)目工程師（Project Engineer， PE）4 HYPERLINK l _bookmark8 配置管理執(zhí)行5 HYPERLINK l _bookmark9 流程圖5 HYPERLINK l _bookmark10 1.3.1流程描述6 HYPERLINK l _bookmark11 配置管理（CMDB）框架變更8 HYPERLINK l _bookmark12 變更請(qǐng)求的提出8 HYPE

3、RLINK l _bookmark13 變更評(píng)估8 HYPERLINK l _bookmark14 變更審核8 HYPERLINK l _bookmark15 變更實(shí)施9 HYPERLINK l _bookmark16 變更確認(rèn)9 HYPERLINK l _bookmark17 L2C 配置管理（CMDB）模型設(shè)計(jì)構(gòu)建10 HYPERLINK l _bookmark18 CMDB 配置框架設(shè)計(jì)圖10 HYPERLINK l _bookmark19 CMDB 配置管理分層模型設(shè)計(jì)10 HYPERLINK l _bookmark20 CMDB 中的對(duì)象關(guān)系設(shè)計(jì)11 HYPERLINK l _boo

4、kmark21 CMDB 中自動(dòng)錄入與手動(dòng)錄入設(shè)計(jì)11 HYPERLINK l _bookmark22 CMDB 中面向應(yīng)用的配置管理一致性設(shè)計(jì)11 HYPERLINK l _bookmark23 與其他流程的關(guān)系13 HYPERLINK l _bookmark24 和變更管理流程的關(guān)系13 HYPERLINK l _bookmark25 CMDB 中配置項(xiàng)變更設(shè)計(jì)13 HYPERLINK l _bookmark26 生產(chǎn)變更流程與回滾14 HYPERLINK l _bookmark27 和發(fā)布管理流程的關(guān)系14技術(shù)中心配置管理流程設(shè)定配置管理（CMDB）設(shè)計(jì)的目的為了更科學(xué)、規(guī)范的納管技術(shù)中

5、心的資源，減少資源孤島配置，關(guān)聯(lián)所有有效資源對(duì)象。實(shí)現(xiàn)一個(gè)高效率管理信息系統(tǒng)，為內(nèi)部，為客戶提供持續(xù)可靠的運(yùn)維服務(wù)關(guān)鍵角色、職責(zé)定義云計(jì)算技術(shù)中心配置管理流程主要分為以下幾個(gè)職責(zé)/角色，分別簡述如下：配置控制委員會(huì)（Configuration Control Board，CCB）責(zé)任：權(quán)利：制定和修改項(xiàng)目的配置管理策略；接受配置管理計(jì)劃，并按相關(guān)規(guī)定貫徹與執(zhí)行； 接受配置控制委員會(huì)的報(bào)告。批準(zhǔn)、發(fā)布配置管理計(jì)劃；建立、更改基線的設(shè)置，審核變更申請(qǐng)； 根據(jù)配置管理員的報(bào)告決定相應(yīng)的對(duì)策。人員安排： 技術(shù)中心項(xiàng)目經(jīng)理、配置管理員、客戶代表、項(xiàng)目工程師等項(xiàng)目經(jīng)理（Project Manager，PM

6、）責(zé)任：權(quán)利：與 CCB 協(xié)商確定項(xiàng)目起始基線和開發(fā)里程碑； 接受配置管理計(jì)劃，并按相關(guān)規(guī)定貫徹與執(zhí)行； 接受配置控制委員會(huì)的報(bào)告。 提出配置管理計(jì)劃的修改要求； 提出配置管理的建議和要求。技能要求： 了解技術(shù)架構(gòu)和項(xiàng)目環(huán)境； 較強(qiáng)的口頭表達(dá)能力和與客戶溝通技巧； 處理糾紛的能力； 深刻了解技術(shù)中心配置管理流程； 較強(qiáng)的領(lǐng)導(dǎo)能力。人員安排： 技術(shù)中心項(xiàng)目經(jīng)理配置管理架構(gòu)師（Configuration Management Officer，CMO）責(zé)任：權(quán)利：編制配置管理計(jì)劃； 執(zhí)行配置項(xiàng)管理方案；執(zhí)行版本控制和變更控制方案； 編制配置狀態(tài)報(bào)告；向 CCB 匯報(bào)有關(guān)配置管理流程中的不符合情況。技

7、能要求： 了解配置管理架構(gòu)和項(xiàng)目環(huán)境； 深入了解技術(shù)中心的配置管理標(biāo)準(zhǔn)； 有足夠的流程設(shè)計(jì)理論積累； 較強(qiáng)的口頭表達(dá)能力與文檔能力；人員安排： 配置流程設(shè)計(jì)與規(guī)劃負(fù)責(zé)人。由二線工程師中的流程小組 Leader 擔(dān)任配置庫程序管理員（Program Librarian，PL）責(zé)任：權(quán)利：配置庫的建立和權(quán)限分配；配置管理工具的日常管理與維護(hù)； 配置庫的日常操作和維護(hù)；各配置項(xiàng)的管理與維護(hù)；對(duì)項(xiàng)目工程師進(jìn)行相關(guān)的培訓(xùn)技能要求： 對(duì)配置信息技術(shù)有深入掌握； 對(duì)配置參數(shù)調(diào)整產(chǎn)生的影響有足夠的了解人員安排： 配置流程框架執(zhí)行者。由二線工程師中的流程小組成員擔(dān)任項(xiàng)目工程師（Project Engineer，

8、 PE）責(zé)任：權(quán)利：項(xiàng)目的實(shí)施部署； 項(xiàng)目資源的錄入； 文檔的版本生成；按照指定的流暢，完成配置項(xiàng)的日常錄入和更新；技能要求： 對(duì)項(xiàng)目有足夠深入了解； 對(duì)服務(wù)器環(huán)境有深入了解； 對(duì)所有項(xiàng)目相關(guān)信息有足夠了解人員安排： 配置流程框架執(zhí)行者。由項(xiàng)目工程師擔(dān)任1.3 配置管理執(zhí)行1.3.1 流程圖流程描述 配置管理的啟動(dòng)-CCB 的成立配置管理計(jì)劃啟動(dòng)：技術(shù)中心 Leader 決定創(chuàng)建配置管理流程，發(fā)起配置管理構(gòu)建MSP 項(xiàng)目合同簽訂后，項(xiàng)目經(jīng)理可以發(fā)起配置管理構(gòu)建成立配置控制委員會(huì)（CCB）配置控制委員會(huì)做為配置管理的總負(fù)責(zé)評(píng)審組，負(fù)責(zé)整個(gè)配置管理的生命周期與決策。CCB 成員人數(shù)一般為奇數(shù)，人數(shù)

9、在 37 人范圍內(nèi)。CCB 成員包括：項(xiàng)目經(jīng)理 PM；配置管理員 CMO；客戶代表（當(dāng)為項(xiàng)目創(chuàng)建配置管理時(shí)加入）；項(xiàng)目工程師等。CCB 的決策機(jī)制原則上要求 CCB 成員意見達(dá)成一致。在不能達(dá)成一致情況下，可投票決策。技術(shù)部發(fā)起的配置管理需求，在無法達(dá)成一致情況下，由 CCB 成員投票確定，投票超過半數(shù)即為通過；客戶項(xiàng)目中無法做出決策的情況下，客戶代表擁有最終決策權(quán)；客戶項(xiàng)目中，客戶代表沒有無法做出決策情況下，采取少數(shù)服從多數(shù)的原則，由 CCB 成員投票確定，投票超過半數(shù)即為通過。 配置需求確認(rèn)CCB 成立后，由 CCB 組織會(huì)議根據(jù)項(xiàng)目的遷移部署計(jì)劃確定各個(gè)里程碑和最終托管策略。RACI：明

10、確配置管理中關(guān)鍵角色和工作范圍CMO：負(fù)責(zé)編制配置管理計(jì)劃書，按約定的時(shí)間點(diǎn)設(shè)計(jì)配置框架模版配置管理員 CMO；負(fù)責(zé)配置管理的整體管控，配置實(shí)施和配置管理計(jì)劃的實(shí)施配置基準(zhǔn)確認(rèn)：確定配置初始基線和配置項(xiàng)列表配置范圍確認(rèn)：明確要配置的資源范圍 配置管理設(shè)計(jì)完成CMO 根據(jù) CCB 會(huì)議決議的設(shè)計(jì)基線，開始設(shè)計(jì)配置管理計(jì)劃書，包含：配置管理需求；實(shí)施配置管理的責(zé)任人及其職責(zé)；配置進(jìn)度安排；標(biāo)識(shí)規(guī)則配置文檔更新規(guī)范特殊配置要求 BaseLine（客戶要求）配置庫設(shè)計(jì)；配置庫分類文檔類AWS 資源類配置范圍項(xiàng)目文檔（Documents）：項(xiàng)目規(guī)劃、服務(wù)保證計(jì)劃、合同信息、技術(shù)報(bào)告、交付文檔、用戶指導(dǎo)手

11、冊(cè)、事故總結(jié)報(bào)告等；應(yīng)用（Application）：應(yīng)用描述、版本號(hào)、安裝歷史；工具（Tools）：自動(dòng)設(shè)計(jì)工具、開發(fā)工具、測試工具、維護(hù)工具等；托管的 AWS 服務(wù)資產(chǎn)信息（AWS Resources）：用戶賬號(hào)下托管的 AWS 資源，如 EC2，ECS，EBS 等；權(quán)限分配（PL、PE）a)PL 可為每個(gè)項(xiàng)目的主要負(fù)責(zé)工程師分配配置庫操作權(quán)限，輔助 PL 完成不同項(xiàng)目的配置管理工作。一般地，為了工作能更加順利的進(jìn)行，可以適當(dāng)?shù)南掳l(fā) Add、 Checkin/Checkout、Download 等權(quán)限，但是絕對(duì)不能給予“刪除”權(quán)限。同時(shí)保證 PL 的最高操作權(quán)限。c)PE 負(fù)責(zé)后續(xù)對(duì)配置項(xiàng)的

12、更新，原則上不允許擁有“刪除”權(quán)限，不允許擁有配置框架修改權(quán)限配置庫的創(chuàng)建配置管理計(jì)劃審核通過之后，PL 即可著手組織建立配置庫。所有項(xiàng)目應(yīng)建立配置庫，以便管理各配置項(xiàng)。文檔庫空間可由 wiki 系統(tǒng)創(chuàng)建，PL 僅創(chuàng)建基線文檔庫，僅 PL 可以對(duì)其操作。AWS 資源庫可通過調(diào)用 AWS API 定時(shí)導(dǎo)入 Jira 系統(tǒng)，項(xiàng)目工程師幫忙玩善，僅 PL 可以對(duì)其操作。AWS 資源庫和文檔庫由 CMO 統(tǒng)一管理，根據(jù)項(xiàng)目各階段的實(shí)際情況定制相應(yīng)的版本選取規(guī)則，來保證托管服務(wù)的正常運(yùn)作。在變更發(fā)生時(shí)，應(yīng)及時(shí)做好基線的推進(jìn)。配置庫管理操作規(guī)范；項(xiàng)目工程師可根據(jù)獲得的授權(quán)的資源進(jìn)行操作配置庫的工作，例如

13、Add、Checkin/Checkout、Download 等；配置庫的檢出，當(dāng)發(fā)生變更且變更評(píng)審?fù)ㄟ^后，或者發(fā)現(xiàn)錯(cuò)誤且錯(cuò)誤評(píng)審?fù)ㄟ^后，由 PL 或者主要負(fù)責(zé)工程師將配置庫中的相關(guān)配置檢出至相關(guān)項(xiàng)目工程師手里，讓其完善配置；PL 或者主要負(fù)責(zé)工程師根據(jù)配置管理計(jì)劃創(chuàng)建與維護(hù)基線，變更開始時(shí)，需要“凍結(jié)”配置項(xiàng)來控制變更；配置庫的檢入，當(dāng)變更實(shí)施結(jié)束或錯(cuò)誤修正和驗(yàn)證結(jié)束，并通過配置審核后，由 PL 或者主要項(xiàng)目工程師重新錄入配置庫中；PL 定期清除配置庫里的垃圾文件；PL 定期備份配置庫。 合規(guī)審核CMO 提交設(shè)計(jì)文檔給 CCB 評(píng)審。如果通過評(píng)審，則進(jìn)行下一步構(gòu)建，如果未經(jīng)過評(píng)審，則去修正配置

14、管理計(jì)劃書，直至通過評(píng)審。 配置管理執(zhí)行PL 拿到通過評(píng)審的配置管理計(jì)劃書，按照設(shè)計(jì)規(guī)劃書執(zhí)行配置框架構(gòu)建。配置構(gòu)建：AWS 資源模版構(gòu)建自定義資源創(chuàng)建配置文檔管理構(gòu)建（wiki）配置核查PL 提交最終的配置框架給 CCB 評(píng)審。如果通過評(píng)審，則進(jìn)行下一步信息初始化，如果未經(jīng)過評(píng)審， 則需要 CCB 判定問題，并討論修正配置管理計(jì)劃書，開始配置循環(huán)，直至配置構(gòu)建通過評(píng)審。配置信息初始化PL 對(duì)初始信息進(jìn)行配置PE 根據(jù)部門/項(xiàng)目需求開始錄入配置項(xiàng)信息 配置管理維護(hù)配置管理完成后，最終由配置控制委員會(huì)（CCB）完成確認(rèn)，進(jìn)入后續(xù)配置維護(hù)環(huán)節(jié)，配置變更構(gòu)建結(jié)束。PL 持續(xù)對(duì)配置管理維護(hù)PE 持續(xù)對(duì)

15、配置項(xiàng)進(jìn)行更新 配置管理更新當(dāng)前配置無法滿足業(yè)務(wù)配置需求，需要修改配置框架時(shí)，由 PL 提交申請(qǐng)給配置控制委員會(huì)，重新啟動(dòng)配置變更流程1.4 配置管理（CMDB）框架變更在當(dāng)前的配置管理體系無法滿足技術(shù)中心新增加的配置管理需求或項(xiàng)目上無法滿足管理需求時(shí)，需要對(duì)當(dāng)前的配置管理框架進(jìn)行調(diào)整，通過配置變更流程完成 CMDB 框架變更。變更請(qǐng)求的提出 由發(fā)起者（客戶/PE）確定變更，填寫變更請(qǐng)求/評(píng)審單，描述變更原因和變更內(nèi)容，提交給 PM/中心 Leader PM/中心 Leader 進(jìn)一步評(píng)估需求，認(rèn)為需求合理且有必要操作，提交給 PL 初審 PL 根據(jù)當(dāng)前配置管理架構(gòu)，確認(rèn)無法滿足需求，需要修改

16、配置框架，提交給 CMO 評(píng)估框架可行性設(shè)計(jì)，需求發(fā)起變更評(píng)估 CMO 對(duì)填寫的變更請(qǐng)求/評(píng)審單進(jìn)行全面評(píng)估表，對(duì)申請(qǐng)表是否清晰、明確和完整性進(jìn)行審查，若 CMO 發(fā)現(xiàn)變更不明確或不完整，應(yīng)返回申請(qǐng)表給最初發(fā)起者。 當(dāng) CMO 認(rèn)定變更請(qǐng)求/評(píng)審單為可執(zhí)行時(shí)，針對(duì)需求出具配置變更評(píng)估報(bào)告變更評(píng)估原則：變更評(píng)估要分析每個(gè)變更對(duì)當(dāng)前 AWS 資源、后期維護(hù)、成本、項(xiàng)目進(jìn)度以及約定需求的影響，同時(shí)還要分析對(duì)服務(wù)的可靠性、可維護(hù)性、可移植性和性能的影響；配置變更評(píng)估報(bào)告應(yīng)描述若實(shí)施變更必須變更的配置項(xiàng)、文檔和資源；CMO 完成配置變更評(píng)估報(bào)告后，更新變更記錄，并安排 CCB 會(huì)議日程。變更審核 CCB

17、 對(duì)提交的變更申請(qǐng)進(jìn)行審核，并根據(jù)變更評(píng)估確定變更的影響級(jí)別；CCB 審核可能的結(jié)果有三種：接受變更；拒絕變更；延期變更。當(dāng) CCB 認(rèn)為信息不足時(shí)，需要 CMO 或其它相關(guān)人員提交更多信息。 變更結(jié)果確認(rèn)CCB 批準(zhǔn)的變更，由 CMO 將變更項(xiàng)目發(fā)送到指定的項(xiàng)目工程師進(jìn)行下一步的實(shí)施變更工作；CCB 拒絕的變更，由 CMO 將 CCB 拒絕變更的原因發(fā)送給發(fā)起者，并保存變更請(qǐng)求/評(píng)審單，更新變更記錄，關(guān)閉變更活動(dòng)；CCB 確認(rèn)延期變更，需要進(jìn)一步分析的，由 CMO 將變更項(xiàng)目隨同 CCB 的 Question Sheet 發(fā)送給評(píng)估分析人員；對(duì)于延期的變更，由 CMO 對(duì)變更的相關(guān)文檔進(jìn)行歸

18、檔，以便在適當(dāng)時(shí)機(jī)提交 CCB 審核。 CMO 負(fù)責(zé)整理 CCB 會(huì)議記錄，填寫變更請(qǐng)求/評(píng)審單中相應(yīng)審核項(xiàng)；更新變更記錄，如果是接受變更，還需將要變更的 CIs 狀態(tài)改為“修改中”；將變更文檔分發(fā)給相關(guān)人員。變更實(shí)施變更被批準(zhǔn)后，PL 負(fù)責(zé)變更的實(shí)施，并詳細(xì)記錄變更的內(nèi)容；由項(xiàng)目經(jīng)理/中心 Leader 對(duì)變更的實(shí)施進(jìn)行跟蹤。 對(duì)于 AWS 資源管理方式變更，必須修改設(shè)計(jì)、持續(xù)合規(guī)、測試以及變更正確性的驗(yàn)證。而且與變更相關(guān)的文檔必須修訂，以反映變更。當(dāng)變更以及測試完成后，可以正式使用。 對(duì)于項(xiàng)目計(jì)劃、配置管理計(jì)劃發(fā)生變更的，項(xiàng)目組人員要按照變更過的項(xiàng)目計(jì)劃、配置管理計(jì)劃提交配置項(xiàng)。變更確認(rèn)變

19、更實(shí)施完成后，CMO 需對(duì)變更進(jìn)行審核，審核的范圍一般涉及以下方面：測試記錄；變更請(qǐng)求；配置項(xiàng)的檢入及檢出；文件的命名；版本的編號(hào)。 審核完成后，生成最新的配置版本，由 PL 更新到基線庫中。 PL 應(yīng)重新標(biāo)識(shí)所有被影響的配置項(xiàng)及版本。 生成新版本后，CMO 負(fù)責(zé)收集所有變更信息歸檔，修改變更 CIs 狀態(tài)為“正式發(fā)布”，關(guān)閉變更，并將變更報(bào)告發(fā)送給發(fā)起者。框架變更完成1.5 L2C 配置管理（CMDB）模型設(shè)計(jì)構(gòu)建CMDB 配置框架設(shè)計(jì)圖CMDB 配置管理分層模型設(shè)計(jì)基礎(chǔ)原則：分層構(gòu)建。以 AWS 資源為核心基礎(chǔ)構(gòu)建資源模型，由 MSP 業(yè)務(wù)需求切入擴(kuò)展對(duì)象。 核心模型。即資源模型，構(gòu)建基于

20、 AWS 原生資源框架的資源對(duì)象定義。該模型的原生信息通過 AWS API 自動(dòng)獲取，動(dòng)態(tài)更新。核心模型記錄了 AWS 資源基本的關(guān)系信息。該模型主要是為了支持運(yùn)維基礎(chǔ)資源的依賴對(duì)象關(guān)聯(lián)； 擴(kuò)展模型。手動(dòng)定義的模型，擴(kuò)展模型是依賴核心模型的擴(kuò)展。擴(kuò)展模型中的對(duì)象基于應(yīng)用需要找到關(guān)聯(lián)的資源信息，如；基于某個(gè)應(yīng)用名 ftp 找到對(duì)應(yīng)的實(shí)例 EC2，通過該 EC2 的關(guān)聯(lián)找到依賴它的其它資源對(duì)象信息，比如 AMI、CFN 模版、OS 版本號(hào)等等。通過不斷的擴(kuò)展對(duì)象模型來完善運(yùn)維需求。根據(jù)分層原則，構(gòu)建基于 AWS 資源核心模型的 CMDB 分類。 Resource：AWS 資源的發(fā)現(xiàn)與管理。與 AW

21、S Console 通過 API 保持強(qiáng)一致性，所有資源做為其它資源對(duì)象的基礎(chǔ) Maintenance: 運(yùn)維配置信息管理。L2C 從運(yùn)維需求入手，所有手動(dòng)資源全部在此錄入。此處也是 L2C 運(yùn)維配置管理的起點(diǎn) Document：文檔管理。按照項(xiàng)目維護(hù)所有相關(guān)的文檔信息，指向 wiki 鏈接CMDB 中的對(duì)象關(guān)系設(shè)計(jì)基礎(chǔ)原則：配置關(guān)系不傳遞原則。所有資源在配置對(duì)象關(guān)系時(shí)僅考慮直接關(guān)聯(lián)對(duì)象，所有關(guān)系不跨越對(duì)象進(jìn)行傳遞。為減少設(shè)計(jì)復(fù)雜性，L2C 在 CMDB 模型設(shè)計(jì)中僅約定三種關(guān)系，三種關(guān)系如下： 主從關(guān)系。這種關(guān)系是一種強(qiáng)相關(guān)關(guān)系，當(dāng)主不存在時(shí)，從一定不存在，且從無法離開主單獨(dú)存在。在 L2C

22、 的配置管理平臺(tái)中用從屬 Belong 來表達(dá)。如 CPU、內(nèi)存和宿主機(jī) EC2 的關(guān)系，應(yīng)用與代碼的關(guān)系，監(jiān)控報(bào)警與指標(biāo)都屬于該種關(guān)系 依賴關(guān)系。是一種對(duì)象屬性級(jí)之間的關(guān)聯(lián)關(guān)系，對(duì)象之間非強(qiáng)相關(guān)，可以單獨(dú)存在，但是A 必須依賴 B 才能創(chuàng)建。比如某個(gè) IP 對(duì)象必須依賴子網(wǎng)對(duì)象才能創(chuàng)建，某個(gè)應(yīng)用程序要依賴主機(jī)實(shí)例對(duì)象才能存在，這是對(duì)象級(jí)別的關(guān)系 關(guān)聯(lián)關(guān)系。一種連接關(guān)系，兩者有聯(lián)系，但存在本身不依賴，可以單獨(dú)存在。如 EC2 與EIP 的關(guān)系，應(yīng)用系統(tǒng)與文檔的關(guān)系。CMDB 中自動(dòng)錄入與手動(dòng)錄入設(shè)計(jì)基礎(chǔ)原則：由自動(dòng)發(fā)現(xiàn)降低維護(hù)的成本和代價(jià)。通過手動(dòng)錄入應(yīng)用資源并創(chuàng)建與資源對(duì)象的關(guān)聯(lián) 涉及到 A

23、WS 資源狀態(tài)的變更，全部保持自動(dòng)化，維護(hù) CMDB 與 AWS 控制臺(tái)中資源的強(qiáng)一致性。 運(yùn)維配置管理與項(xiàng)目文檔配置按照真實(shí)情況由手動(dòng)錄入完成 關(guān)聯(lián)關(guān)系由手動(dòng)錄入配置完成CMDB 中面向應(yīng)用的配置管理一致性設(shè)計(jì)基礎(chǔ)原則：保證項(xiàng)目中同一版本應(yīng)用配置的一致性 L2C 的配置管理中以應(yīng)用配置對(duì)象為運(yùn)維起點(diǎn)，所有錄入基于應(yīng)用來完成 分離應(yīng)用對(duì)象所涉及關(guān)聯(lián)的對(duì)象，用于一致性保證軟件包一致性根據(jù) OS 不同單獨(dú)維護(hù)兩個(gè)分支，保證異構(gòu)系統(tǒng)中應(yīng)用軟件包的一致性在獨(dú)立分支的軟件包對(duì)象中，包含軟件包對(duì)象的常規(guī)信息。如安裝包位置、日志目錄、配置文件、端口號(hào)等軟件包的版本：同一類軟件包的不同版本單獨(dú)創(chuàng)建對(duì)象維護(hù)軟件

24、包的獨(dú)立性：應(yīng)用軟件包在獨(dú)立的對(duì)象分類 software 下維護(hù)軟件包的最小單位：以應(yīng)用進(jìn)程/開發(fā)語言為最小單位。如：java、python、tomcat7軟件包的關(guān)聯(lián)：軟件包可以被多個(gè)應(yīng)用配置對(duì)象關(guān)聯(lián)。應(yīng)用對(duì)象差異偏離修正。應(yīng)用配置的對(duì)象按照業(yè)務(wù)系統(tǒng)進(jìn)行分類，當(dāng)應(yīng)用引用的軟件包跟真實(shí)配置有差異時(shí)，在應(yīng)用對(duì)象中自行修訂，原則上不允許修改軟件包的基礎(chǔ)信息。如端口號(hào)，啟動(dòng)腳本與基礎(chǔ)軟件包不一致時(shí)，在應(yīng)用對(duì)象中單獨(dú)定義字段修正1.6 與其他流程的關(guān)系和變更管理流程的關(guān)系變更流程涉及到修改配置參數(shù)時(shí)，需要 pending 在 CMDB 錄入階段，必須在該節(jié)點(diǎn)完成 CMDB 的變更。僅當(dāng)完成 CMDB

25、變更后，才可以最終關(guān)閉工單CMDB 中配置項(xiàng)變更設(shè)計(jì) 變更觸發(fā)：當(dāng)客戶/內(nèi)部提交工單請(qǐng)求 L2C 運(yùn)維人員響應(yīng)工單，根據(jù) Jira 工單中的變更流程執(zhí)行變更 當(dāng)變更完成后，執(zhí)行變更檢查，有客戶確認(rèn)后完成工單- 工單完成后由變更流程觸發(fā) CMDB 配置項(xiàng)變更開始，由 PE 執(zhí)行變更執(zhí)行：變更前需要 pending 狀態(tài)到 CMDB 的更新，防止配置不一致當(dāng)修改配置項(xiàng)信息時(shí)，需要確認(rèn)當(dāng)前 Status 狀態(tài)為非“updating”，如果為“update”狀態(tài)，不允許修改當(dāng) Status 狀態(tài)為非“In-use”時(shí)，修改“Inuse”到“updating”，鎖定修改變更結(jié)束：當(dāng)配置項(xiàng)信息修改結(jié)束后，修改狀態(tài)為“In-use”，把 jira 工單號(hào)記入 comment配置變更檢查：所有的更新錄入起點(diǎn)必須從應(yīng)用開始檢查，核查應(yīng)用對(duì)象是否為變更對(duì)象資源變更：除非確認(rèn)為手動(dòng)修正資源，否則不允許修改資源對(duì)象應(yīng)用配置項(xiàng)：手動(dòng)錄入的變更內(nèi)容，需要二次核準(zhǔn)文檔變