網(wǎng)絡(luò)變更管理流程包括5項基本原則，其中包括風(fēng)險分析和同行評審。這些優(yōu)秀實踐可以幫助網(wǎng)絡(luò)團隊限制失敗的網(wǎng)絡(luò)更改和中斷。

[[329097]]

網(wǎng)絡(luò)變更管理是旨在減少變更失敗風(fēng)險的過程。這個流程需要幾個步驟來確保成功進行更改，但是每個步驟如何開展工作?

飛機駕駛員通常會使用定義明確的流程來確保飛行安全。同樣，網(wǎng)絡(luò)團隊可以使用定義的流程來減少因網(wǎng)絡(luò)更改失敗而造成計劃外停機的風(fēng)險。即便如此，組織有時仍發(fā)現(xiàn)更改未按計劃進行，從而導(dǎo)致停機。有些故障是由于流程故障引起的，而另一些故障是由于復(fù)雜配置的明顯影響所致。

網(wǎng)絡(luò)變更管理過程依賴于幾種基本操作原理的應(yīng)用，例如：

• 范圍確定和風(fēng)險分析
• 同行評審
• 部署前測試和驗證
• 實施和測試
• 文檔更新

網(wǎng)絡(luò)團隊在更改管理流程之前執(zhí)行創(chuàng)建更改詳細(xì)信息的過程新配置、設(shè)備連接信息和文檔)。思科公司發(fā)布的“變更管理：優(yōu)秀實踐”白皮書就是一份網(wǎng)絡(luò)變更管理的重要指南。

1.范圍和風(fēng)險分析

網(wǎng)絡(luò)變更管理過程的第一步應(yīng)該是評估提議變更的范圍，確定哪些服務(wù)可能受到影響以及誰使用這些服務(wù)。而“爆炸半徑”一詞通常用于描述變更可能產(chǎn)生的影響范圍，其中包括可能的負(fù)面結(jié)果。

團隊將希望根據(jù)以下兩個因素來衡量范圍：

(1)變更影響的端點數(shù)量;

(2)變更可能影響的服務(wù)的重要性。

一旦團隊確定了范圍，他們應(yīng)該對變更進行風(fēng)險評估。這是過去做過很多次并廣為人知的事情嗎?它是完全自動化的，還是人為錯誤會以意想不到的方式更改?是否對所涉及的技術(shù)了如指掌，或者是否有可能發(fā)生意料之外的事情?

變更的范圍將會計入風(fēng)險。與更改小型分支站點相比，對運行關(guān)鍵業(yè)務(wù)流程的基礎(chǔ)設(shè)施進行更改將給業(yè)務(wù)帶來更大的風(fēng)險。

網(wǎng)絡(luò)團隊可以使用風(fēng)險因素計算器為關(guān)鍵參數(shù)賦值。若要創(chuàng)建風(fēng)險計算器，需要從下面的示例參數(shù)取平均值，或在網(wǎng)上搜索計算器。

• 效果是否對客戶可見?(否=1，是=10)
• 有多少客戶可能受到影響?(范圍為1到10)
• 服務(wù)在范圍內(nèi)有多重要?(范圍為1到10)
• 過去是否已成功實施此更改?(是=1，否=10)
• 變更是否自動化?(范圍為1到10，取決于自動化程度)
• 更改可以在實施之前進行徹底測試嗎?(是=1，否=10)
• 供應(yīng)商文檔是否清晰明確?(范圍為1到10)
• 同行評審是否徹底，是否發(fā)現(xiàn)了任何潛在的問題?(范圍為1到10)

風(fēng)險越大，在其余的變更管理過程中，團隊就需要越謹(jǐn)慎。

2.同行評審

下一步是進行同行評審。盡管團隊可以在風(fēng)險分析之前實施這一步驟，但最好使用風(fēng)險級別來推動同行評審的徹底性。盡管所有同行評審都應(yīng)進行比較透徹的檢查，但常規(guī)更改(例如訪問控制列表更改或修改虛擬LAN)可能會收到粗略的審核。自動化測試和例行變更的部署可以幫助減輕同行評審的風(fēng)險。

熟悉網(wǎng)絡(luò)的內(nèi)部人員將進行大多數(shù)同行評審。但是，如果更改與眾不同，請設(shè)備供應(yīng)商的專家進行審核是有意義的。評審應(yīng)該反饋到風(fēng)險分析階段，可能會更新技術(shù)風(fēng)險度量，例如指示測試和文檔是否足夠。

3.部署前測試和驗證

在理想情況下，所有更改都將經(jīng)歷部署前的測試和驗證階段。低風(fēng)險、重復(fù)性變更的自動化可以消除誘惑，避免對團隊認(rèn)為低風(fēng)險的變更進行測試。當(dāng)然，范圍和風(fēng)險越大，適當(dāng)?shù)販y試和驗證提議的更改就越重要。

虛擬路由器和交換機操作系統(tǒng)實例的普及，使得自動化測試網(wǎng)絡(luò)拓?fù)涞膭?chuàng)建變得更加容易，而無需昂貴的硬件投資。團隊將需要構(gòu)建自動化來創(chuàng)建虛擬網(wǎng)絡(luò)拓?fù)洌⒃跍y試成功完成時將其拆除。

部署前測試包括團隊?wèi)?yīng)遵循的幾個步驟來評估建議的更改：

(1)在更改之前，需要驗證測試網(wǎng)絡(luò)當(dāng)前是否按預(yù)期工作。

(2)在測試基礎(chǔ)設(shè)施中實現(xiàn)更改，以確認(rèn)更改結(jié)果為所需的最終狀態(tài)。團隊?wèi)?yīng)該使用自動化流程來避免人為錯誤，并減少驗證更改的時間。如果測試環(huán)境中的驗證失敗，需要確定原因。到底是因為更改不正確而失敗?還是因為測試網(wǎng)絡(luò)不能準(zhǔn)確地表示真實的網(wǎng)絡(luò)?

(3)測試回退更改過程，以便在出現(xiàn)問題時很容易恢復(fù)到先前的狀態(tài)。撤消更改應(yīng)使網(wǎng)絡(luò)返回到初始狀態(tài)，團隊可以通過重復(fù)步驟1進行驗證。

4.實施和測試

部署前和部署后測試和驗證步驟應(yīng)遵循與部署前測試的步驟1和步驟2相同的過程。如果團隊在部署前的測試和驗證方面做得很好，則不會發(fā)生任何意外情況。如果變更后測試檢測到意外問題，團隊?wèi)?yīng)撤消變更并驗證服務(wù)是否已恢復(fù)。

在更改大型網(wǎng)絡(luò)后，某些網(wǎng)絡(luò)協(xié)議將需要更多的時間來聚合，這要求更改后的驗證過程包含延遲或聚合測試，而在小型測試環(huán)境中部署前的測試不需要這些測試。

越來越多的組織正在自動化網(wǎng)絡(luò)配置更改，目標(biāo)是遷移到基于基礎(chǔ)設(shè)施作為代碼的DevOps文化。目的是針對低風(fēng)險更改采用持續(xù)集成和持續(xù)部署測試以及部署過程。

5.文檔和網(wǎng)絡(luò)管理更新

在理想情況下，團隊將在更改創(chuàng)建過程中創(chuàng)建和更新文檔，使他們能夠查看文檔和網(wǎng)絡(luò)管理更改以及更改的詳細(xì)信息。一旦團隊實施并驗證了更改，他們便可以將文檔更改合并到網(wǎng)絡(luò)文檔系統(tǒng)中。

不要忘記根據(jù)需要更新網(wǎng)絡(luò)管理系統(tǒng)。大多數(shù)網(wǎng)絡(luò)管理系統(tǒng)都有API、這些API支持自動化流程進行更改。

如果更改驗證步驟是自動化的，則可以將其合并到定期的網(wǎng)絡(luò)驗證檢查中。這些定期檢查可以檢測高度冗余和彈性網(wǎng)絡(luò)中的故障。隨著時間的推移，團隊將建立一個覆蓋網(wǎng)絡(luò)許多部分的網(wǎng)絡(luò)驗證檢查庫。

良好的網(wǎng)絡(luò)變更管理原則為減少因變更失敗而導(dǎo)致的計劃外網(wǎng)絡(luò)中斷提供了方向。團隊?wèi)?yīng)創(chuàng)建適合其組織的流程，并努力使這個流程更加高效。