當(dāng)涉及到變更時(shí)，擁有變更管理策略可以將風(fēng)險(xiǎn)最小化。遵循這些規(guī)則來(lái)調(diào)整云中的云變更管理策略和遵從性。

　　大多數(shù)企業(yè)都圍繞數(shù)據(jù)中心應(yīng)用程序制定基本的遵從性和變更管理策略。有新的規(guī)則使變更管理和遵從性策略適應(yīng)于云計(jì)算，主要關(guān)注軟件變更。

　　合規(guī)確保遵守與信息系統(tǒng)、數(shù)據(jù)存儲(chǔ)和使用相關(guān)的法規(guī)和內(nèi)部政策。

　　變更管理確保受影響的各方正確地審查對(duì)應(yīng)用程序和數(shù)據(jù)庫(kù)所做的更改，以便解決問(wèn)題。

　　傳統(tǒng)的變更管理策略連接到開(kāi)發(fā)過(guò)程，并且越來(lái)越多地連接到基于存儲(chǔ)庫(kù)的治理。任何級(jí)別的軟件更改以及任何中間件或操作系統(tǒng)更改都將通過(guò)存儲(chǔ)庫(kù)過(guò)程進(jìn)行開(kāi)發(fā)和測(cè)試。然后，企業(yè)可以應(yīng)用變更管理來(lái)通知可能受到影響的利益相關(guān)者。

　　GitOps是DevOps的一個(gè)子集，是存儲(chǔ)庫(kù)驅(qū)動(dòng)遵從性的擴(kuò)展，將其擴(kuò)展到部署。這可能改變應(yīng)用程序的體驗(yàn)質(zhì)量(QoE)。它還引入了可能影響應(yīng)用程序的新工具和api。此外，企業(yè)將GitOps模型應(yīng)用到云應(yīng)用程序中，當(dāng)時(shí)主要是基于IaaS或容器的。

　　公司開(kāi)始使用公共云提供商的api來(lái)訪問(wèn)新的服務(wù)功能，但他們往往未能擴(kuò)展其變更管理策略以納入新功能。因此，變革管理失敗了。即使在今天，CIMI公司發(fā)現(xiàn)幾乎一半的企業(yè)變更管理實(shí)踐都沒(méi)有涵蓋云托管功能的變化。

　　要使變更管理和遵從性策略適應(yīng)云計(jì)算，請(qǐng)遵循以下規(guī)則。

　　適應(yīng)當(dāng)前流程的規(guī)則

　　規(guī)則1:利用現(xiàn)有資源

　　適應(yīng)當(dāng)前的變更管理和法規(guī)遵循政策和計(jì)劃，而不是創(chuàng)建新的。當(dāng)前計(jì)劃的問(wèn)題在于它們的范圍而不是行動(dòng)。在云部署中，影響應(yīng)用程序穩(wěn)定性和QoE的因素可能是云部署前從未出現(xiàn)過(guò)的。我們的目標(biāo)是確?，F(xiàn)在包括了這些因素。

　　規(guī)則2:捕捉每一個(gè)變化

　　云更改管理策略必須捕獲云服務(wù)契約、服務(wù)承諾和云中的可計(jì)費(fèi)更改中的所有更改。并非所有的云更改都需要更改軟件或存儲(chǔ)庫(kù)控制的中間件，有些可能不會(huì)進(jìn)行常規(guī)測(cè)試。例如，對(duì)云托管區(qū)域或擴(kuò)展限制的更改不會(huì)對(duì)軟件產(chǎn)生影響，但會(huì)損害QoE。將所有云更改視為軟件更改，并要求相同級(jí)別的涉眾參與。要遵循這一規(guī)則，需要明確地將云服務(wù)責(zé)任與軟件測(cè)試過(guò)程聯(lián)系起來(lái)。

　　規(guī)則3:評(píng)估工作流

　　在變更管理策略中考慮工作流變更。工作流表示從用戶(hù)到被訪問(wèn)的應(yīng)用程序的消息交換，以及支持這些消息交換所需的網(wǎng)絡(luò)連接。云應(yīng)用程序通常由多個(gè)組件組成。由于云爆發(fā)和故障轉(zhuǎn)移設(shè)置，以及使用更復(fù)雜的技術(shù)(如服務(wù)網(wǎng)格)，一些組件進(jìn)入和離開(kāi)云。對(duì)這些內(nèi)容的任何更改都可能直接改變穩(wěn)定性、安全性和QoE。由于云提供商、互聯(lián)網(wǎng)、企業(yè)VPN或這些東西的任何組合提供網(wǎng)絡(luò)連接，服務(wù)質(zhì)量可以產(chǎn)生第二級(jí)影響。

　　一旦覆蓋了非云變更管理實(shí)踐可能遺漏的變更來(lái)源，您還必須決定如何集成它們。目標(biāo)是修改當(dāng)前的實(shí)踐和程序。一個(gè)好的起點(diǎn)是規(guī)劃應(yīng)用程序開(kāi)發(fā)、測(cè)試和部署周期。在當(dāng)前應(yīng)用變更管理的每個(gè)點(diǎn)的流程上放置一個(gè)箭頭。然后獲取新的變更源，并決定將每個(gè)變更源映射到流中的位置。

　　執(zhí)行測(cè)試

　　當(dāng)在單元測(cè)試的基礎(chǔ)上進(jìn)行云更改管理時(shí)，涉眾的經(jīng)驗(yàn)就會(huì)丟失。根據(jù)應(yīng)用程序設(shè)計(jì)和部署模型的不同，可能存在有價(jià)值的子系統(tǒng)測(cè)試。

　　要確定情況是否如此，請(qǐng)遵循以下過(guò)程:

　　步驟1從變更管理流程早期的應(yīng)用程序集成測(cè)試點(diǎn)回到每個(gè)測(cè)試點(diǎn)。

　　步驟2評(píng)估是否有足夠的功能組合在那里，并暴露在新的云相關(guān)的變化，以證明有意義的利益相關(guān)者審查結(jié)果。

　　步驟3停在那個(gè)不再正確的點(diǎn)上。

　　如果遵循這個(gè)過(guò)程，實(shí)際的變更管理程序不太可能需要太多的變更。