當(dāng)涉及到變更時(shí)，擁有變更管理策略可以將風(fēng)險(xiǎn)最小化。遵循這些規(guī)則來調(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)部政策。

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

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

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

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

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

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

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

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

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

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

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

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

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

執(zhí)行測試

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

要確定情況是否如此，請遵循以下過程:

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

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

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

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