不知云，焉知云安全。
本文是Gartner《2020年規(guī)劃指南》的十個(gè)分報(bào)告之一，介紹了企業(yè)上云的規(guī)劃趨勢(shì)。云已經(jīng)成為企業(yè)轉(zhuǎn)型和獲得競(jìng)爭(zhēng)優(yōu)勢(shì)的基礎(chǔ)，云將繼續(xù)作為數(shù)字業(yè)務(wù)所需的創(chuàng)新平臺(tái)。企業(yè)應(yīng)確保云成為組織中的主流計(jì)算平臺(tái)，并將其混合云和多云戰(zhàn)略擴(kuò)展到邊緣。
本文給出了公有云采用框架，解釋了邊緣計(jì)算和云的關(guān)系，邊緣計(jì)算和分布式云的關(guān)系，邊緣計(jì)算和物聯(lián)網(wǎng)的關(guān)系，還談到了對(duì)供應(yīng)商鎖定的見(jiàn)解。值得一讀。
圖1-《Gartner規(guī)劃指南》十大領(lǐng)域（分報(bào)告）
其中，云計(jì)算的主要技術(shù)規(guī)劃趨勢(shì)和重要規(guī)劃考慮如下圖所示：
圖2-2020云計(jì)算關(guān)鍵規(guī)劃考慮因素
我們將分別對(duì)圖中四大趨勢(shì)及其規(guī)劃考慮作進(jìn)一步描述?？紤]到該報(bào)告太長(zhǎng)，計(jì)劃分為幾篇分別介紹。本次介紹其中第一項(xiàng)：組織將制定一個(gè)全面的多云、邊緣和場(chǎng)內(nèi)戰(zhàn)略。
一 、制定全面的多云、邊緣和場(chǎng)內(nèi)戰(zhàn)略
2020年，隨著互聯(lián)網(wǎng)的可執(zhí)行性，各組織將繼續(xù)加速數(shù)字業(yè)務(wù)時(shí)代的步伐。一個(gè)安全、分散的分布式網(wǎng)絡(luò)和應(yīng)用世界將迎來(lái)機(jī)遇時(shí)代。未來(lái)幾年，預(yù)計(jì)將有30多億新客戶首次進(jìn)入商業(yè)生命周期。
據(jù)Gartner估計(jì)，到2021年，將有超過(guò)250億個(gè)連接的傳感器和端點(diǎn)。
亞馬遜、OneWeb和SpaceX等公司正在發(fā)射數(shù)千顆衛(wèi)星，將互聯(lián)網(wǎng)連接到世界各地。今天，全球約80億人口中有58%的人連接到互聯(lián)網(wǎng)。數(shù)十億新客戶和設(shè)備的增加，將顛覆每一個(gè)行業(yè)和供應(yīng)鏈。此外，隨著5G連接性、人工智能/機(jī)器學(xué)習(xí)（AI/ML）、區(qū)塊鏈、物聯(lián)網(wǎng)（IoT）、邊緣和持續(xù)的云創(chuàng)新等技術(shù)，永遠(yuǎn)改變了技術(shù)格局，企業(yè)正經(jīng)歷著一場(chǎng)IT復(fù)興。在2019年的Gartner技術(shù)專(zhuān)業(yè)人士調(diào)查中，客戶報(bào)告說(shuō)，由于變化的速度很快，技術(shù)的多樣性，他們?cè)絹?lái)越難以做出架構(gòu)決策。
為了應(yīng)對(duì)這場(chǎng)動(dòng)態(tài)和顛覆性的格局，組織必須制定一個(gè)整體的多云、邊緣和場(chǎng)內(nèi)戰(zhàn)略，足以靈活以快速適應(yīng)變化的步伐。組織還必須計(jì)劃對(duì)技能集、跨業(yè)務(wù)的供應(yīng)商知識(shí)以及云管理和治理專(zhuān)業(yè)知識(shí)的投資。
規(guī)劃考慮因素
01
制定一致的多云和混合云戰(zhàn)略
云計(jì)劃經(jīng)常會(huì)被內(nèi)部政治因素耽擱，一些企業(yè)內(nèi)部人士不愿放棄自己的控制權(quán)。組織的其他人員可能認(rèn)為，通過(guò)使用內(nèi)部資源，他們可以更好地構(gòu)建和保護(hù)應(yīng)用程序。然而，大多數(shù)組織無(wú)法與云供應(yīng)商的創(chuàng)新速度和規(guī)模經(jīng)濟(jì)相競(jìng)爭(zhēng)。大多數(shù)云供應(yīng)商都在這個(gè)速度更快、成本更低的基礎(chǔ)設(shè)施上開(kāi)發(fā)增值服務(wù)，實(shí)現(xiàn)了大規(guī)模的自動(dòng)化和商品硬件的標(biāo)準(zhǔn)化。在公有云計(jì)算領(lǐng)域的創(chuàng)新速度是最快的，反應(yīng)更快的競(jìng)爭(zhēng)對(duì)手往往會(huì)在市場(chǎng)中獲勝。
云項(xiàng)目之所以復(fù)雜，主要有兩個(gè)原因：
■組織通常有多個(gè)項(xiàng)目以不同的速度執(zhí)行。一個(gè)團(tuán)隊(duì)可能正在選擇供應(yīng)商和開(kāi)發(fā)架構(gòu)，而另一個(gè)團(tuán)隊(duì)可能剛剛起步。根據(jù)組織的規(guī)模，這些團(tuán)隊(duì)之間甚至可能不知道彼此的計(jì)劃。
■許多人需要參與云計(jì)劃，以確保實(shí)現(xiàn)適當(dāng)?shù)募軜?gòu)。許多遺留IT運(yùn)營(yíng)工具和流程不容易擴(kuò)展到云，因此需要新的工具執(zhí)行監(jiān)視、配置、故障排除、備份和其他傳統(tǒng)流程。然而，組織通常是在云團(tuán)隊(duì)和所需技能完全準(zhǔn)備好之前就已經(jīng)開(kāi)始了這些計(jì)劃。
克服這些云實(shí)現(xiàn)問(wèn)題，需要一個(gè)健全的過(guò)程。開(kāi)發(fā)這個(gè)過(guò)程的起點(diǎn)是Gartner的“實(shí)現(xiàn)公有云采用框架的解決方案路徑”，它提供了一個(gè)高層次的云采用框架（見(jiàn)圖3）。
圖3-實(shí)現(xiàn)公有云采用框架
此框架可用于確定成功實(shí)施云計(jì)劃所需的投資和步驟。然而，即便是使用采用框架的組織，也必須意識(shí)到公有云市場(chǎng)的快速發(fā)展趨勢(shì)，并相應(yīng)地進(jìn)行調(diào)整。有關(guān)詳細(xì)信息，請(qǐng)參閱“設(shè)計(jì)云策略文檔”。
02
評(píng)估分布式云和邊緣選項(xiàng)
在過(guò)去的幾十年中，計(jì)算在分布式和集中式架構(gòu)之間搖擺了很多次。云計(jì)算，從終極來(lái)看，是集中式的，而邊緣代表了向分布式拓?fù)涞霓D(zhuǎn)變（下一章將討論邊緣）。“分布式云”最終實(shí)現(xiàn)了鐘擺位于中間的平衡，即集中式計(jì)算和分布式計(jì)算相互完成。分布式云通過(guò)將云服務(wù)擴(kuò)展到更多的位置，來(lái)增強(qiáng)和改進(jìn)核心云組件和服務(wù)。Gartner對(duì)分布式云的定義如下：
在分布式云中，公有云服務(wù)（包括必要的硬件和軟件）分散到不同的物理位置（即邊緣），而服務(wù)的所有權(quán)、運(yùn)營(yíng)、治理、更新和演進(jìn)仍由原始公有云供應(yīng)商負(fù)責(zé)。
遷移到分布式云模型，可以增強(qiáng)許多計(jì)算方面，包括性能、法規(guī)遵從性、風(fēng)險(xiǎn)降低和可靠性。重要的是，云計(jì)算的核心租戶——“即服務(wù)”（as-a-service）的消費(fèi)模式——堅(jiān)持使用分布式云模式。盡管基礎(chǔ)設(shè)施本身位于經(jīng)典的公有云區(qū)域之外，但供應(yīng)商仍然負(fù)責(zé)大部分服務(wù)的交付和維護(hù)。分布式云組件不一定非要一直連接到中央公有云服務(wù)。但是，公有云控制平面必須擴(kuò)展到所有分布式云組件，因此在某些點(diǎn)上的連接性是需要的。這種模型的例子包括AWS Outposts和Microsoft Azure Stack。
有些人可能會(huì)問(wèn)，“這不就是邊緣計(jì)算的情況嗎？”根據(jù)上下文的不同，這里的答案可以是“是”或“否”。分布式云的所有實(shí)例也是邊緣計(jì)算的實(shí)例。然而，并不是所有邊緣計(jì)算的實(shí)例都是分布式云。
實(shí)際上，分布式云將在兩個(gè)不同的階段發(fā)展（見(jiàn)圖4）：
1.同類(lèi)混合：企業(yè)客戶將購(gòu)買(mǎi)云變電站，以兌現(xiàn)混合云的承諾，并避免基于延遲的問(wèn)題，同時(shí)保留云價(jià)值主張。這些客戶最初不會(huì)接受向附近鄰居開(kāi)放變電站的想法。他們將把變電站保留在自己的地盤(pán)，僅對(duì)自己開(kāi)放使用。通過(guò)讓公有云供應(yīng)商承擔(dān)一切責(zé)任，這種方法將產(chǎn)生“拯救”私有云概念和增強(qiáng)混合云的效果。
2.下一代云：在第二階段，公共事業(yè)、大學(xué)、市政府和電信公司（等）將購(gòu)買(mǎi)云變電站，并向鄰近地區(qū)開(kāi)放。這種擴(kuò)展將開(kāi)始鞏固分布式云代表下一代云計(jì)算的基礎(chǔ)。當(dāng)分布式云變電站開(kāi)始激增時(shí)，需要此類(lèi)服務(wù)的用戶不必總是購(gòu)買(mǎi)自己的服務(wù)。相反，他們可以使用在附近位置存在的變電站。
圖4-分布式云將分兩個(gè)階段發(fā)展
到2020年，分布式云將開(kāi)始呈現(xiàn)更正式的形態(tài)，因?yàn)楫a(chǎn)品開(kāi)始以更實(shí)質(zhì)的形式出現(xiàn)，并且組織開(kāi)始追求與這種計(jì)算模式自然契合的邊緣部署。作為一個(gè)組織，需要花點(diǎn)時(shí)間來(lái)確定哪些領(lǐng)域可以通過(guò)將服務(wù)轉(zhuǎn)移到另一個(gè)位置（幾乎可以肯定是離消費(fèi)者更近的位置）來(lái)改進(jìn)服務(wù)交付和業(yè)務(wù)價(jià)值。
邊緣完成云
“邊緣”和許多流行語(yǔ)一樣，被用于各種各樣的上下文和市場(chǎng)中——類(lèi)似于“云”在過(guò)去十年中的用法。Gartner將邊緣定義為人和物連接到網(wǎng)絡(luò)數(shù)字世界的物理位置。然而，大多數(shù)情況下，“邊緣”不用作名詞。相反，它用于描述特定的用例或部署方法。從這個(gè)意義上說(shuō)，“邊緣”對(duì)于技術(shù)專(zhuān)家來(lái)說(shuō)，是一個(gè)形容詞，即與技術(shù)或用例結(jié)合使用的修飾語(yǔ)。
許多人發(fā)現(xiàn)邊緣計(jì)算幾乎等同于物聯(lián)網(wǎng)。雖然物聯(lián)網(wǎng)是一個(gè)非常一致的用例，但它并不是唯一的用例。在它轉(zhuǎn)移到“核心”基礎(chǔ)設(shè)施之前，在邊緣處理數(shù)據(jù)，很可能是使用傳統(tǒng)設(shè)備（如機(jī)架服務(wù)器）進(jìn)行處理。當(dāng)集中化的數(shù)據(jù)中心或公有云區(qū)域不適合給定需求時(shí)，將邊緣計(jì)算視為處理數(shù)據(jù)和系統(tǒng)的一種方式。
邊緣計(jì)算是一種拓?fù)浣Y(jié)構(gòu)，其中信息處理更靠近創(chuàng)建和使用信息的用戶和/或設(shè)備。云是拓?fù)浣Y(jié)構(gòu)的核心。
雖然云不必是邊緣拓?fù)涞暮诵模ǔＪ恰：诵臑檫吘壩恢锰峁└郊臃?wù)、長(zhǎng)期存儲(chǔ)、集中控制和編排。如果需要邊緣部署來(lái)提供整個(gè)組織所需的每一項(xiàng)服務(wù)，那么該部署將有效地成為核心本身。
沒(méi)有核心的邊緣是虛無(wú)的邊緣。
用例從邊緣計(jì)算中獲益的程度，可以通過(guò)分析四項(xiàng)要求來(lái)確定。這四項(xiàng)要求包含了邊緣部署具有顯著積極影響的領(lǐng)域：
■延遲和決定論：光速很快，但不是無(wú)限的。將數(shù)據(jù)傳輸?shù)胶诵牟⒔邮枕憫?yīng)，可能需要太長(zhǎng)時(shí)間。例如，制造工廠可能需要在毫秒（或更短）的時(shí)間內(nèi)檢測(cè)出缺陷或機(jī)械問(wèn)題。工廠基礎(chǔ)設(shè)施和云或數(shù)據(jù)中心之間的長(zhǎng)時(shí)間的交換是不可接受的。這個(gè)用例需要很強(qiáng)的決定論，即可預(yù)測(cè)、可重復(fù)的響應(yīng)和響應(yīng)時(shí)間。決定論的好處在于，消除了可能導(dǎo)致更多故障點(diǎn)或抖動(dòng)的元素。在這種情況下，該元素是兩個(gè)系統(tǒng)之間的通信，它依賴于網(wǎng)絡(luò)性能。
■數(shù)據(jù)和帶寬：作為一個(gè)技術(shù)專(zhuān)家，你一定熟悉圖表，它用數(shù)據(jù)量描述了不可避免的和指數(shù)級(jí)的上升。這是技術(shù)專(zhuān)業(yè)人員的生活事實(shí)，也是網(wǎng)絡(luò)帶寬如此重要的原因。邊緣計(jì)算的一個(gè)必要條件是它對(duì)網(wǎng)絡(luò)使用的影響。邊緣計(jì)算可以讓組織在不將數(shù)據(jù)發(fā)送到核心的情況下，分析數(shù)據(jù)并采取適當(dāng)?shù)男袆?dòng)。這種方法可以大大減輕網(wǎng)絡(luò)的負(fù)擔(dān)。
■有限的自主權(quán)：在個(gè)人和專(zhuān)業(yè)方面，用戶繼續(xù)受到網(wǎng)絡(luò)中斷和連接不良的影響。在當(dāng)今世界，用戶會(huì)從一個(gè)幾秒鐘內(nèi)無(wú)法加載的網(wǎng)站離開(kāi)，他們希望幾乎所有服務(wù)都始終保持連接。遲早，你的網(wǎng)絡(luò)會(huì)失敗的。在這段時(shí)間里，一個(gè)能夠提供替代服務(wù)的邊緣部署（即使是以有限的方式）對(duì)用戶來(lái)說(shuō)也是無(wú)價(jià)的。
■隱私和安全：一些行業(yè)對(duì)數(shù)據(jù)的存儲(chǔ)和使用有更嚴(yán)格的要求，但所有組織都有核心安全要求需要滿足。無(wú)論這種限制是由政府實(shí)體實(shí)施的，還是由用戶期望實(shí)施的，確保在必要時(shí)存儲(chǔ)、處理和刪除數(shù)據(jù)已變得越來(lái)越重要。核心基礎(chǔ)設(shè)施并不總是滿足這些要求，經(jīng)常是因?yàn)樗挥谶h(yuǎn)離數(shù)據(jù)源的區(qū)域。在位置上進(jìn)行邊緣部署，可以緩解此問(wèn)題。
2020年，發(fā)現(xiàn)適合特定用途用例的組織，將機(jī)會(huì)主義地利用這一優(yōu)勢(shì)。這些用例將是精品，并且有很大程度的定制，因?yàn)闆](méi)有商用現(xiàn)貨（COTS）“邊緣堆棧”服務(wù)于每個(gè)人和每個(gè)行業(yè)的需求。一些常見(jiàn)元素，如設(shè)備管理和安全性，在用例之間具有可利用性。不管怎樣，2020年并不是在所有方面同時(shí)追求優(yōu)勢(shì)的一年，但這一年是用優(yōu)勢(shì)元素來(lái)提升你的環(huán)境中的一個(gè)良好協(xié)調(diào)的部分的一年。查看上面的四個(gè)要求，并評(píng)估應(yīng)用程序或用例在多大程度上受到影響。
03
重新思考多云、邊緣和場(chǎng)內(nèi)的網(wǎng)絡(luò)
多年來(lái)，組織對(duì)云網(wǎng)絡(luò)的關(guān)注主要圍繞廣域網(wǎng)延遲和帶寬、云端虛擬網(wǎng)絡(luò)以及負(fù)載平衡等網(wǎng)絡(luò)服務(wù)。兩個(gè)新的因素促使組織重新考慮他們的云網(wǎng)絡(luò)方法：
■軟件定義廣域網(wǎng)（SD-WAN）的采用，將云網(wǎng)絡(luò)的關(guān)注點(diǎn)擴(kuò)展到廣域網(wǎng)邊緣，包括云供應(yīng)商的虛擬網(wǎng)絡(luò)在內(nèi)的組織站點(diǎn)都連接到廣域網(wǎng)。
■多云采用迫使組織尋找不僅可以跨云管理虛擬網(wǎng)絡(luò)，還可以合并數(shù)據(jù)中心網(wǎng)絡(luò)的解決方案。數(shù)據(jù)中心網(wǎng)絡(luò)供應(yīng)商，如Arista Networks、Cisco、Juniper Networks和VMware，正在將其基于策略的軟件定義網(wǎng)絡(luò)（SDN）解決方案擴(kuò)展到云。
為了滿足多云提出的不斷發(fā)展的需求并利用新的網(wǎng)絡(luò)功能，組織必須：
■對(duì)廣域網(wǎng)啟用云
■利用SD-WAN實(shí)現(xiàn)基于應(yīng)用的網(wǎng)絡(luò)和云供應(yīng)商訪問(wèn)
■采用云供應(yīng)商優(yōu)先的網(wǎng)絡(luò)方式
■支持跨云供應(yīng)商和數(shù)據(jù)中心實(shí)現(xiàn)基于策略管理的SDN解決方案
■使用綜合事務(wù)和基于代理的監(jiān)視，來(lái)獲得云網(wǎng)絡(luò)的可見(jiàn)性
1）對(duì)廣域網(wǎng)啟用云
組織必須確定互聯(lián)網(wǎng)和私有傳輸?shù)恼_組合，以滿足其云需求。組織可以通過(guò)利用AWS Direct Connect、Google cloud Interconnect或Microsoft Azure ExpressRoute等服務(wù)的私有互聯(lián)，將其多協(xié)議標(biāo)簽交換（MPLS）網(wǎng)絡(luò)擴(kuò)展到云。這樣的鏈接可以提供比因特網(wǎng)連接更多的帶寬和更高的可靠性。私有互聯(lián)也會(huì)降低數(shù)據(jù)傳輸成本。然而，互聯(lián)網(wǎng)連接即使不能提供與MPLS連接相同的保障，也能滿足一些客戶的網(wǎng)絡(luò)需求。Gartner建議私有互聯(lián)客戶，使用互聯(lián)網(wǎng)至少增強(qiáng)其MPLS連接以實(shí)現(xiàn)冗余。最后，兩種連接方法都是首選的，如圖5所示。
圖5-啟用云的廣域網(wǎng)
2）利用SD-WAN實(shí)現(xiàn)基于應(yīng)用程序的網(wǎng)絡(luò)和云供應(yīng)商訪問(wèn)
SD-WAN通過(guò)創(chuàng)建與傳輸無(wú)關(guān)的結(jié)構(gòu)，來(lái)實(shí)現(xiàn)基于應(yīng)用程序的集中化管理路由。該結(jié)構(gòu)還可以擴(kuò)展到IaaS云供應(yīng)商，如圖5所示。將結(jié)構(gòu)擴(kuò)展到云，使組織能夠?qū)⑵湓拼嬖谝暈槿魏纹渌膹V域網(wǎng)站點(diǎn)，并將這些云置于相同的網(wǎng)絡(luò)策略之下。
使用SD-WAN，應(yīng)用程序路由決策將基于網(wǎng)絡(luò)的當(dāng)前狀態(tài)，在某些情況下，基于端到端的應(yīng)用程序性能。這允許組織利用互聯(lián)網(wǎng)進(jìn)行傳輸。
3）采用云供應(yīng)商優(yōu)先的聯(lián)網(wǎng)方式
組織應(yīng)在查看第三方結(jié)構(gòu)（如路由器和負(fù)載平衡器）之前，評(píng)估其云供應(yīng)商的本地網(wǎng)絡(luò)結(jié)構(gòu)是否滿足其要求。然后，為了填補(bǔ)空白，他們應(yīng)該實(shí)現(xiàn)第三方工具，如深度包檢查或高級(jí)路由。不同的數(shù)據(jù)傳輸成本，會(huì)極大地影響云中的網(wǎng)絡(luò)費(fèi)用。組織應(yīng)該將數(shù)據(jù)進(jìn)出虛擬私有云（VPC）和虛擬網(wǎng)絡(luò)（VNet）的成本作為設(shè)計(jì)參數(shù)。如果不加以管理，這種成本可能會(huì)迅速上升。
4）支持跨云供應(yīng)商和數(shù)據(jù)中心實(shí)現(xiàn)基于策略的管理的SDN解決方案
隨著企業(yè)采用多云和混合方法，跨多個(gè)云和本地?cái)?shù)據(jù)中心創(chuàng)建網(wǎng)絡(luò)策略變得很困難。SDN覆蓋層和數(shù)據(jù)中心結(jié)構(gòu)解決方案的大多數(shù)供應(yīng)商，現(xiàn)在都將其產(chǎn)品擴(kuò)展到云中。這些產(chǎn)品使組織能夠使用相同的策略和構(gòu)造集，管理其數(shù)據(jù)中心和云網(wǎng)絡(luò)。Gartner預(yù)測(cè)了兩種主要的方法：
■基于API，其中工具利用云API
■基于數(shù)據(jù)平面，需要將網(wǎng)絡(luò)設(shè)備插入云供應(yīng)商內(nèi)部的流量路徑內(nèi)
Gartner建議企業(yè)優(yōu)先考慮通過(guò)API管理云的能力，這是任何網(wǎng)絡(luò)解決方案的要求。
5）使用綜合事務(wù)和基于代理的監(jiān)視來(lái)獲得云網(wǎng)絡(luò)的可見(jiàn)性
傳統(tǒng)的網(wǎng)絡(luò)監(jiān)視技術(shù)，無(wú)論是基于日志、SNMP、流還是數(shù)據(jù)包，都假定網(wǎng)絡(luò)運(yùn)營(yíng)商：
■擁有網(wǎng)絡(luò)連接所流經(jīng)的網(wǎng)絡(luò)設(shè)備
■使用托管服務(wù)（如MPLS），并與服務(wù)供應(yīng)商建立了服務(wù)水平協(xié)議（SLA）
這兩個(gè)假設(shè)都不適用于流經(jīng)互聯(lián)網(wǎng)的流量。組織必須部署新技術(shù)來(lái)彌補(bǔ)可見(jiàn)性差距，因?yàn)樗鼈儫o(wú)法監(jiān)視不屬于自己的設(shè)備，也無(wú)法監(jiān)視與它們沒(méi)有建立SLA的鏈接。Gartner建議使用綜合事務(wù)（synthetic transactions）來(lái)查看流經(jīng)互聯(lián)網(wǎng)的流量。生成流量的工具，可以托管在服務(wù)器或最終用戶設(shè)備中。數(shù)據(jù)收集和處理通常通過(guò)SaaS交付，還可以將互聯(lián)網(wǎng)核心事件與互聯(lián)網(wǎng)上的客戶應(yīng)用程序性能關(guān)聯(lián)起來(lái)。
04
預(yù)期并預(yù)防供應(yīng)商鎖定，特別是在SaaS層
在云服務(wù)中，鎖定實(shí)際上是不可避免的。鎖定從根本上代表云供應(yīng)商的差異化能力，這通常是供應(yīng)商價(jià)值主張的核心，也是選擇該供應(yīng)商而非競(jìng)爭(zhēng)對(duì)手的原因。在許多情況下，使用云供應(yīng)商的最有效的方法，是以本地方式接受和充分利用其能力范圍。
一般來(lái)說(shuō)，IT系統(tǒng)遵循鎖定守恒原理：不管架構(gòu)如何，整個(gè)系統(tǒng)中的鎖定量大致相同，但鎖定發(fā)生的位置根據(jù)架構(gòu)的不同而有所不同。
你不能避免鎖定；你只能選擇你的鎖定點(diǎn)在哪里。因此，確定您選擇哪一組風(fēng)險(xiǎn)，以及您將如何降低這些風(fēng)險(xiǎn)。
SaaS有一個(gè)附加的鎖定維度。除了所有應(yīng)用程序軟件都具有預(yù)期的鎖定功能之外，SaaS產(chǎn)品通常僅作為云服務(wù)提供，而沒(méi)有在場(chǎng)內(nèi)運(yùn)行軟件的選項(xiàng)。大多數(shù)公司不能輕易地替換應(yīng)用軟件，因?yàn)檫@類(lèi)應(yīng)用程序之間的功能差異通常很重要。此外，大多數(shù)公司在這些應(yīng)用程序中實(shí)現(xiàn)業(yè)務(wù)流程，并在多個(gè)應(yīng)用程序之間創(chuàng)建集成。正如您無(wú)法輕松地從場(chǎng)內(nèi)Oracle Siebel CRM軟件變更為場(chǎng)內(nèi)SugarCRM軟件一樣，您也無(wú)法輕松地從那些場(chǎng)內(nèi)產(chǎn)品切換到SaaS產(chǎn)品，如Oracle CRM On Demand或Salesforce。
基本的IaaS資源，如計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)能力，不是商品。軟件基礎(chǔ)設(shè)施服務(wù)、PaaS服務(wù)和API服務(wù)，也都不是（即使它們基于開(kāi)源軟件）。所有這些能力都是根據(jù)以下變量區(qū)分的：
■功能性
■可用性、性能、安全性、質(zhì)量和成本特征
■管理和治理
“基礎(chǔ)設(shè)施即代碼”的概念和廣泛使用API來(lái)集成云服務(wù)，導(dǎo)致云依賴直接嵌入到代碼中。抽象這些接口并不能顯著增強(qiáng)可移植性，因此對(duì)鎖定的影響很小。
容器的使用可能會(huì)從應(yīng)用程序開(kāi)發(fā)人員的意識(shí)中抽象出基礎(chǔ)架構(gòu)問(wèn)題，但I(xiàn)&O管理員仍然會(huì)暴露在這些差異中。此外，I&O管理員還需要處理容器編排和管理。因此，鎖定點(diǎn)可能會(huì)移動(dòng)，但它們永遠(yuǎn)不會(huì)消失。使用第三方多云管理工具，只是將鎖定轉(zhuǎn)移到這些工具上，而且往往不能充分掩蓋提供者的差異，從而提供真正的可移植性。
在實(shí)踐中，多云組織只需將多個(gè)鎖定點(diǎn)移到多個(gè)供應(yīng)商，而不必在不同的云供應(yīng)商之間輕松移植。
為了部分降低鎖定風(fēng)險(xiǎn)：
■將鎖定視為應(yīng)用程序可移植性問(wèn)題，而不是基礎(chǔ)設(shè)施問(wèn)題?？梢浦残詰?yīng)該從單個(gè)應(yīng)用程序的角度來(lái)處理。
■為長(zhǎng)期的戰(zhàn)略應(yīng)用程序，規(guī)劃可移植性。封裝云供應(yīng)商接口。例如，將它們放在一個(gè)庫(kù)中，這樣依賴關(guān)系就清晰了，并且與應(yīng)用程序代碼的其余部分隔離開(kāi)來(lái)。
■考慮使用多云策略，在多個(gè)供應(yīng)商之間分散風(fēng)險(xiǎn)。
■建立云供應(yīng)商退出策略，預(yù)期兩年退出的時(shí)間框架。
二、容器和無(wú)服務(wù)器影響工作負(fù)載架構(gòu)
云計(jì)算是一個(gè)方便的應(yīng)用程序開(kāi)發(fā)和部署平臺(tái)，但它并沒(méi)有覆蓋所有出現(xiàn)的組織邊界和用例。公司政策、外部合規(guī)機(jī)構(gòu)和業(yè)務(wù)需求，將推動(dòng)云計(jì)算從集中化數(shù)據(jù)中心轉(zhuǎn)移到分散在邊緣位置的基礎(chǔ)設(shè)施和設(shè)備上。
當(dāng)前的行業(yè)趨勢(shì)是采用基于Docker容器和Kubernetes的容器策略，來(lái)打包、構(gòu)建和部署應(yīng)用程序。此外，組織越來(lái)越習(xí)慣于放棄管理基礎(chǔ)設(shè)施的責(zé)任（見(jiàn)圖3）。這種趨勢(shì)的邏輯下一步是無(wú)服務(wù)器計(jì)算——一種按需執(zhí)行代碼的計(jì)算方式，只對(duì)用戶使用的資源收費(fèi)。在無(wú)服務(wù)器計(jì)算中，服務(wù)器對(duì)開(kāi)發(fā)人員來(lái)說(shuō)是不可見(jiàn)的，他們只需定義要運(yùn)行的代碼。無(wú)服務(wù)器平臺(tái)在后臺(tái)執(zhí)行所有必要的配置以運(yùn)行代碼。
圖3-云原生屬性與抽象層
容器和無(wú)服務(wù)器功能基于運(yùn)行時(shí)機(jī)制，運(yùn)行時(shí)機(jī)制的抽象級(jí)別高于虛擬機(jī)（VM）。在這些抽象級(jí)別上，可以以更精細(xì)的粒度，將應(yīng)用程序和服務(wù)與資源匹配起來(lái)。改進(jìn)的粒度使編排能夠更精確地執(zhí)行，并且還使得用于應(yīng)用程序開(kāi)發(fā)的流程和用于迭代部署的流程之間能夠更緊密地集成。容器和無(wú)服務(wù)器功能都是下一代應(yīng)用程序的關(guān)鍵構(gòu)建模塊，但它們提供了不同的權(quán)衡和開(kāi)發(fā)人員體驗(yàn)，使它們?cè)谔囟ǖ挠美蟹謩e與開(kāi)發(fā)人員相關(guān)。最近，人們對(duì)使用無(wú)服務(wù)器方法運(yùn)行容器（無(wú)服務(wù)器容器）越來(lái)越感興趣，這避免了對(duì)大量運(yùn)維管理的需要。
采用容器和無(wú)服務(wù)器，增加了現(xiàn)代、分布式基礎(chǔ)設(shè)施和應(yīng)用架構(gòu)的規(guī)模和復(fù)雜性。為了最佳地管理這個(gè)新環(huán)境，組織將需要繼續(xù)投資和開(kāi)發(fā)基礎(chǔ)設(shè)施自動(dòng)化。
預(yù)計(jì)到2020年，大型公有云供應(yīng)商將進(jìn)一步推進(jìn)其自動(dòng)化工具。云供應(yīng)商甚至可以構(gòu)建通用的自動(dòng)化工具，這些工具可以在其他云或客戶自己的數(shù)據(jù)中心中運(yùn)行。（微軟的Azure自動(dòng)化工具已經(jīng)做到了。）今天，沒(méi)有一個(gè)工具可以自動(dòng)化整個(gè)基礎(chǔ)設(shè)施生命周期。但是，最復(fù)雜的公有云自動(dòng)化工具鏈可能比任何其他當(dāng)前可用的工具更接近全生命周期管理。到2020年，I&O專(zhuān)業(yè)人員仍應(yīng)期望構(gòu)建由不同自動(dòng)化工具組成的編排工具鏈。（Gartner客戶在整個(gè)基礎(chǔ)設(shè)施自動(dòng)化生命周期中平均使用8種工具。）但在未來(lái)，在公有云中誕生的自動(dòng)化工具和流程可能會(huì)取代單點(diǎn)解決方案陣列，成為自始至終自動(dòng)化基礎(chǔ)設(shè)施的單一工具集。
規(guī)劃考慮因素
2020年，I&O專(zhuān)業(yè)人員將支持和/或構(gòu)建基于容器和無(wú)服務(wù)器計(jì)算的現(xiàn)代應(yīng)用程序架構(gòu)。他們還將構(gòu)建由不同自動(dòng)化工具組成的編排工具鏈。然而，在未來(lái)，公有云中誕生的工具和流程可能會(huì)合并為端到端的基礎(chǔ)設(shè)施自動(dòng)化的單一工具，取代單點(diǎn)解決方案的集合。因此，I&O專(zhuān)業(yè)人員也需要為這種潛在的轉(zhuǎn)變做好準(zhǔn)備。
01
使用無(wú)服務(wù)器基礎(chǔ)設(shè)施以消除資源調(diào)配開(kāi)銷(xiāo)
無(wú)服務(wù)器基礎(chǔ)設(shè)施使資源能夠用作不透明的、實(shí)際上不受限制的共享池，無(wú)需預(yù)先配置即可連續(xù)使用。它還使這些資源能夠以消耗的IT服務(wù)為單位進(jìn)行定價(jià)。早期人們對(duì)無(wú)服務(wù)器基礎(chǔ)設(shè)施的大部分興趣是由函數(shù)PaaS（fPaaS，function PaaS）服務(wù)驅(qū)動(dòng)的，在該服務(wù)中，定制應(yīng)用程序邏輯的細(xì)粒度單元打包為在事件觸發(fā)時(shí)執(zhí)行的函數(shù)?，F(xiàn)在，人們對(duì)無(wú)服務(wù)器容器平臺(tái)的興趣正在增長(zhǎng)，它可以根據(jù)不同的需求自動(dòng)調(diào)整后端資源的使用以運(yùn)行容器。
fPaaS由于其低啟動(dòng)成本和無(wú)縫可擴(kuò)展性而具有吸引力。它消除了供應(yīng)服務(wù)器和配置自動(dòng)縮放函數(shù)所需的運(yùn)維人員開(kāi)銷(xiāo)。因此，管理人員可以把更多的時(shí)間用于生產(chǎn)性任務(wù)，而不是把時(shí)間花在維護(hù)專(zhuān)門(mén)支持業(yè)務(wù)所需的基礎(chǔ)設(shè)施上。
然而，fPaaS也有一些運(yùn)維上的限制和挑戰(zhàn)。fPaaS函數(shù)通常在內(nèi)存容量和執(zhí)行時(shí)間方面受到限制，需要為純無(wú)狀態(tài)運(yùn)維而設(shè)計(jì)。必須從fPaaS函數(shù)獲得的任何數(shù)據(jù)，都必須完全通過(guò)函數(shù)的回調(diào)通知方法或共享持久存儲(chǔ)進(jìn)行通信。由于fPaaS資源完全由云的底層基礎(chǔ)設(shè)施管理，運(yùn)維人員的可見(jiàn)性或控制能力有限，這使得測(cè)試和調(diào)試更加困難。此外，每個(gè)云供應(yīng)商都有自己獨(dú)特的fPaaS實(shí)現(xiàn)，具有用于函數(shù)打包和規(guī)范的專(zhuān)有API。因此，將fPaaS應(yīng)用程序遷移到其他云平臺(tái)將需要一次移植演練。
技術(shù)專(zhuān)家應(yīng)該在這些用例中利用云中的fPaaS：
■基于事件驅(qū)動(dòng)架構(gòu)（EDA）實(shí)現(xiàn)應(yīng)用程序，EDA是一種開(kāi)發(fā)模型，軟件組件在收到一個(gè)或多個(gè)事件通知后執(zhí)行動(dòng)作。
■自動(dòng)化具有無(wú)狀態(tài)、并發(fā)、等冪和可記錄特征的運(yùn)維任務(wù)，以及由自助用戶行為驅(qū)動(dòng)的運(yùn)維任務(wù)。
■構(gòu)建需要與云平臺(tái)及其原生服務(wù)進(jìn)行盡可能高集成的應(yīng)用程序。如果您承諾使用單個(gè)云平臺(tái)部署應(yīng)用程序，并且不關(guān)心將應(yīng)用程序移植到其他云服務(wù)或本地基礎(chǔ)設(shè)施，請(qǐng)選擇此方法。
無(wú)服務(wù)器容器平臺(tái)，如AWS Fargate、Azure container Instances（ACI）和Google Cloud Run（目前處于beta版），使容器能夠在沒(méi)有管理員參與的情況下運(yùn)行。無(wú)服務(wù)器容器在容器即服務(wù)（CaaS）和fPaaS抽象之間提供了折衷方案。它們?yōu)閼?yīng)用程序提供了一個(gè)看起來(lái)像標(biāo)準(zhǔn)操作系統(tǒng)的環(huán)境，但卻將大多數(shù)容量管理細(xì)節(jié)卸載到容器編排服務(wù)。使用這種方法，管理員不必為容器編排服務(wù)配置數(shù)據(jù)平面（即工作節(jié)點(diǎn)）。相反，公有云服務(wù)會(huì)自動(dòng)為運(yùn)行由容器編排器調(diào)度的pod提供資源（參見(jiàn)圖4）。
圖4-無(wú)服務(wù)器容器編排
無(wú)服務(wù)器容器平臺(tái)有一些限制，包括實(shí)例類(lèi)型的狹窄選擇和多租戶部署的要求。例如，ACI和Fargate支持實(shí)例最大為四個(gè)CPU，最大內(nèi)存容量分別為16GB和30GB。這兩個(gè)服務(wù)都不支持專(zhuān)用硬件租賃，因此容器將使用共享資源進(jìn)行部署。與fPaaS一樣，每個(gè)云供應(yīng)商都有自己獨(dú)特的實(shí)現(xiàn)無(wú)服務(wù)器容器的方法。
在這些情況下，技術(shù)專(zhuān)家應(yīng)該利用云中的無(wú)服務(wù)器容器：
■他們希望盡可能快地實(shí)現(xiàn)容器編排，而無(wú)需開(kāi)發(fā)那些運(yùn)維特定容器編排平臺(tái)所需的廣泛技能。
■它們要求對(duì)運(yùn)行容器的基礎(chǔ)設(shè)施進(jìn)行最低限度的可見(jiàn)性或控制。
■容器將在可變工作負(fù)載下運(yùn)行，管理員不想承擔(dān)配置自動(dòng)縮放程序的工程挑戰(zhàn)。
■容器化工作負(fù)載可以在無(wú)服務(wù)器容器平臺(tái)的資源限制下，在多租戶條件下運(yùn)行。
■管理員不關(guān)心其他云平臺(tái)或場(chǎng)內(nèi)基礎(chǔ)設(shè)施上容器編排的運(yùn)維一致性。
02
設(shè)計(jì)可移植性
技術(shù)專(zhuān)家必須采取原則性的方法來(lái)實(shí)現(xiàn)應(yīng)用程序的可移植性。首先，他們必須有意識(shí)地決定是否在應(yīng)用程序的設(shè)計(jì)階段優(yōu)先考慮可移植性。如果他們決定優(yōu)先考慮可移植性，那么他們必須遵守促進(jìn)可移植性的架構(gòu)原則。這將使應(yīng)用程序能夠在供應(yīng)商之間移動(dòng)，而無(wú)需進(jìn)行實(shí)質(zhì)性的重新分層或重構(gòu)。
當(dāng)您將可移植性確定為一個(gè)重要的優(yōu)先級(jí)時(shí)，您應(yīng)該將云應(yīng)用程序設(shè)計(jì)為上下文無(wú)關(guān)的。作為一種最終狀態(tài)，上下文無(wú)關(guān)性很難實(shí)現(xiàn)，有時(shí)甚至是不可能實(shí)現(xiàn)的。上下文無(wú)關(guān)的三個(gè)特征是：
■依賴關(guān)系很少：上下文無(wú)關(guān)的系統(tǒng)幾乎可以部署在任何地方，因?yàn)樗鼈儾灰蕾囉谔嗥渌δ?。它們是相?duì)自包含的。
■定義良好的接口：與上下文無(wú)關(guān)系統(tǒng)的接口方式定義良好，易于理解。
■容易滿足的依賴關(guān)系：上下文無(wú)關(guān)系統(tǒng)所具有的少數(shù)依賴關(guān)系也容易滿足。
如表1所示，隨著您從SaaS（沒(méi)有任何特征）向IaaS（三者都有）向下移動(dòng)，上下文無(wú)關(guān)性變得更加可能。因此，可移植性在IaaS層最容易實(shí)現(xiàn)。
表1.與云計(jì)算分層服務(wù)模型相一致的上下文無(wú)關(guān)原則
要評(píng)估可移植性優(yōu)先級(jí)，請(qǐng)考慮每個(gè)應(yīng)用程序的性質(zhì)，包括它將如何使用以及它可能持續(xù)多長(zhǎng)時(shí)間。在確保系統(tǒng)可靠性和滿足快速交付新功能的業(yè)務(wù)需求之間，權(quán)衡取舍。
實(shí)現(xiàn)系統(tǒng)可靠性需要關(guān)注治理實(shí)踐，以指導(dǎo)必須長(zhǎng)期保持穩(wěn)定的持續(xù)技術(shù)和過(guò)程創(chuàng)新。相比之下，交付的敏捷性側(cè)重于結(jié)果而非過(guò)程，側(cè)重于實(shí)驗(yàn)而非穩(wěn)定性，側(cè)重于顛覆性創(chuàng)新而非現(xiàn)狀。
如果您的應(yīng)用程序或工作負(fù)載是長(zhǎng)壽命的，并且對(duì)業(yè)務(wù)具有戰(zhàn)略意義，那么即使您選擇使用敏捷開(kāi)發(fā)方法來(lái)實(shí)現(xiàn)應(yīng)用程序的某些部分，可移植性也應(yīng)該是規(guī)劃的首要和中心。
使用以下條件，評(píng)估應(yīng)用程序工作負(fù)載的可移植性優(yōu)先級(jí)：
■可移植性具有更高優(yōu)先級(jí)，當(dāng)應(yīng)用程序具有系統(tǒng)性或高度戰(zhàn)略性、需要高度的開(kāi)發(fā)工作和/或?qū)⒊掷m(xù)較長(zhǎng)時(shí)間時(shí)。對(duì)于這些應(yīng)用程序，如果組織在其云應(yīng)用程序策略中不明確選擇可移植性，那么它將承擔(dān)巨大的風(fēng)險(xiǎn)。
■可移植性具有較低優(yōu)先級(jí)，當(dāng)應(yīng)用程序具有更多的機(jī)會(huì)主義，需要相對(duì)最少的開(kāi)發(fā)時(shí)間和精力，和/或可能是短暫的時(shí)。在這些情況下，“重新開(kāi)始”可能是一個(gè)更便宜和更好的選擇。面向低代碼（Low-code-oriented）的應(yīng)用程序?qū)儆谶@一類(lèi)。
03
制定自動(dòng)化策略
自動(dòng)化整個(gè)基礎(chǔ)設(shè)施生命周期是一項(xiàng)復(fù)雜的任務(wù)，無(wú)論是在公有云中還是在場(chǎng)內(nèi)完成。它需要一個(gè)專(zhuān)門(mén)的自動(dòng)化計(jì)劃，實(shí)現(xiàn)這可能需要多年的努力。因此，技術(shù)人員必須制定自動(dòng)化戰(zhàn)略。圖5描述了一個(gè)實(shí)施基礎(chǔ)設(shè)施自動(dòng)化計(jì)劃的全面框架。
圖5-基礎(chǔ)設(shè)施自動(dòng)化計(jì)劃
該框架可以有效地應(yīng)用于公有云基礎(chǔ)設(shè)施。實(shí)際上，在公有云中實(shí)現(xiàn)計(jì)算實(shí)例自動(dòng)化的工作流，與在私有基礎(chǔ)設(shè)施上實(shí)現(xiàn)虛擬機(jī)自動(dòng)化的工作流，沒(méi)有實(shí)質(zhì)性區(qū)別。但是，在每個(gè)步驟中，都有一些公有云特有的自動(dòng)化考慮：
1.準(zhǔn)備自動(dòng)化：公有云基礎(chǔ)設(shè)施所需的準(zhǔn)備工作比典型的場(chǎng)內(nèi)部署環(huán)境少得多。公有云基礎(chǔ)設(shè)施是由軟件定義的：服務(wù)通過(guò)API提供，并以抽象級(jí)別呈現(xiàn)，使它們可以立即被現(xiàn)代自動(dòng)化工具訪問(wèn)。當(dāng)自動(dòng)化場(chǎng)內(nèi)環(huán)境時(shí)，I&O團(tuán)隊(duì)將花費(fèi)大量的時(shí)間和精力對(duì)場(chǎng)內(nèi)基礎(chǔ)設(shè)施進(jìn)行現(xiàn)代化（實(shí)際上是使其更像云），作為自動(dòng)化的一個(gè)有利步驟。
2.自動(dòng)化基礎(chǔ)設(shè)施交付：主要公有云供應(yīng)商包含了內(nèi)置的自動(dòng)化工具?？蛻艨梢允褂盟鼈儊?lái)影響各種部署模式。公有云用戶可以使用AWS CodeBuild、Azure DevOps或Google cloud Build等工具，將持續(xù)集成和持續(xù)交付管道擴(kuò)展到基礎(chǔ)設(shè)施。它們還可以使用各種webhook實(shí)現(xiàn)基于事件的觸發(fā)器，或者使用各種供應(yīng)商提供的發(fā)布-訂閱技術(shù)。在許多情況下，這些工具可以替代第三方部署工具，如HashiCorp Terraform。
3.自動(dòng)化配置管理：在這里，內(nèi)置的自動(dòng)化工具也可以強(qiáng)制系統(tǒng)狀態(tài)并根據(jù)需要部署更改?？梢允褂肁WS CloudFormation、Azure Resource Manager和Automation State Configuration以及Google Cloud Deployment Manager等工具，來(lái)代替第三方持續(xù)配置自動(dòng)化（CCA）工具，如Chef、Puppet或Red Hat Ansible。主要的公有云供應(yīng)商還提供了用于監(jiān)視、日志管理和補(bǔ)丁的現(xiàn)代實(shí)用工具。
4.實(shí)現(xiàn)治理現(xiàn)代化：公有云供應(yīng)商也越來(lái)越多地實(shí)施現(xiàn)代治理工具和技術(shù)?；诓呗缘墓芾硎强捎玫?，盡管策略通常僅限于一個(gè)功能域（如身份和訪問(wèn)管理[IAM]）。主要的公有云還采用了DevSecOps，包括AWS Control Tower和用于Azure的Secure DevOps Kit（工具包）等工具，允許最終用戶建立有效的安全和合規(guī)控制。
04
擁抱DevSecOps
為整體的DevSecOps方法，調(diào)整安全和DevOps實(shí)踐。安全應(yīng)該成為流程和自動(dòng)化的一個(gè)組成部分，反過(guò)來(lái)，它應(yīng)該充分利用這些流程和自動(dòng)化的優(yōu)勢(shì)。除了支持更靈活的環(huán)境之外，這種方法還確保了安全性的一致性和可重復(fù)性。它還確保關(guān)注構(gòu)建模塊（如工作流定義、腳本、清單和鏡像），而不是每個(gè)單個(gè)的運(yùn)維和實(shí)例化。了解如何加強(qiáng)以及如何支持虛擬化、云、容器、無(wú)服務(wù)器和數(shù)據(jù)庫(kù)環(huán)境等多種生態(tài)系統(tǒng)中的安全性是關(guān)鍵。例如，圖6顯示了基于容器的應(yīng)用程序的自動(dòng)化部署過(guò)程。數(shù)字1到11說(shuō)明了DevSecOps控制可以到達(dá)的位置。
圖6-自動(dòng)化部署過(guò)程中的威脅向量
并非所有的技術(shù)堆棧都具有足夠的內(nèi)置安全性。在這些情況下，組織需要通過(guò)第三方組件（如容器安全產(chǎn)品、云工作負(fù)載保護(hù)平臺(tái)（CWPP）或運(yùn)行時(shí)應(yīng)用程序自我保護(hù)（RASP）技術(shù)）為它們提供安全性。在DevOps環(huán)境中，組織還需要改變其脆弱性評(píng)估方法。例如，它們不僅需要在工作負(fù)載上線后掃描工作負(fù)載，還需要在構(gòu)建期間或?qū)嵗皰呙枞萜饔诚?。而且，他們需要將安全測(cè)試緊密地集成到開(kāi)發(fā)管道中。安全API使這種檢測(cè)變得更容易，如果這些API還不可用，組織應(yīng)該要求它們的供應(yīng)商提供這些API。
三、組織重新考慮對(duì)多云和分布式云的運(yùn)營(yíng)
Gartner的客戶正在將更多的公有云計(jì)劃轉(zhuǎn)移到生產(chǎn)階段。到2020年，中央IT將負(fù)責(zé)控制新的異構(gòu)工作負(fù)載，部署在多個(gè)IaaS、PaaS、SaaS以及潛在的分布式云解決方案中。云計(jì)算的治理具有挑戰(zhàn)性，即使只有一個(gè)云供應(yīng)商參與其中。隨著組織朝著多云的方向發(fā)展，一致地實(shí)施治理變得越來(lái)越具有挑戰(zhàn)性。
開(kāi)發(fā)多云治理和管理流程，對(duì)于滿足共同的合規(guī)性、治理和安全需求至關(guān)重要。在2020年，主要的IaaS、PaaS和SaaS供應(yīng)商將在其產(chǎn)品中提供很少的標(biāo)準(zhǔn)化，而是提供非常不同的功能集、消費(fèi)工作流、接口和API定義。建立程序化治理，使組織能夠使用云服務(wù)，同時(shí)確保IT維持合規(guī)性和卓越的運(yùn)營(yíng)性。通過(guò)定義和建立策略（無(wú)論是否自動(dòng)化），IT使得業(yè)務(wù)能夠盡可能使用云計(jì)算。
此外，云服務(wù)的日益采用和多云的日益使用，推動(dòng)了對(duì)一致性的跨平臺(tái)管理的需求。大規(guī)模運(yùn)維云服務(wù)，對(duì)負(fù)責(zé)管理IT系統(tǒng)和服務(wù)的技術(shù)專(zhuān)家提出了一套新要求。
到2020年，傳統(tǒng)的數(shù)據(jù)中心管理工具將繼續(xù)提供有限的公有云管理功能。隨著新的原生工具和服務(wù)的不斷發(fā)布，云供應(yīng)商將推進(jìn)提供更全面管理體驗(yàn)的戰(zhàn)略。第三方獨(dú)立軟件供應(yīng)商（ISV）市場(chǎng)將繼續(xù)提供快速發(fā)展的解決方案，如云管理平臺(tái)（CMP）和工具。這些工具通過(guò)跨平臺(tái)聚合、一致性或增量功能為云平臺(tái)增加了管理價(jià)值。
規(guī)劃考慮因素
到2020年，大多數(shù)組織將接受混合架構(gòu)作為最終狀態(tài)目標(biāo)。多云和分布式云（即邊緣）應(yīng)融入組織的整體IT現(xiàn)代化戰(zhàn)略。這將需要評(píng)估新的業(yè)務(wù)方法和投資。要取得成功，IT組織必須：
01
建立多云治理和管理流程
公有云IaaS治理的一種成功方法是在自助服務(wù)啟用和控制之間微妙平衡的結(jié)果。過(guò)多的（自助服務(wù)）啟用將導(dǎo)致混亂。過(guò)多的控制將成為生產(chǎn)力和業(yè)務(wù)創(chuàng)新的障礙，并可能導(dǎo)致更多的影子IT運(yùn)營(yíng)。公有云供應(yīng)商的創(chuàng)新速度很快，快于組織的反應(yīng)和適應(yīng)速度。事實(shí)證明，試圖裝模作樣或阻礙供應(yīng)商創(chuàng)新的做法，是一場(chǎng)失敗的戰(zhàn)斗。因此，組織必須確保其自助服務(wù)啟用方法，允許直接接觸供應(yīng)商創(chuàng)新，以支持其公有云采用策略的目標(biāo)。
Gartner的公有云IaaS治理框架，包括以下準(zhǔn)備工作和五個(gè)步驟：
■第1步-定義策略：定義可編程實(shí)施的策略（也稱為“護(hù)欄”）。您應(yīng)該編寫(xiě)涵蓋以下圖3所示的8類(lèi)云管理的策略，包括“身份、安全和合規(guī)性”、“庫(kù)存清單和分類(lèi)”和“成本管理和資源優(yōu)化”。在為公有云治理定義護(hù)欄時(shí)，必須首先關(guān)注指定誰(shuí)有權(quán)訪問(wèn)什么樣的云服務(wù)，這些個(gè)人能做什么，以及在什么條件下。例如，一個(gè)策略允許某個(gè)用戶以管理員身份，從AWS訪問(wèn)Amazon彈性計(jì)算云（EC2）服務(wù)，但只能在美國(guó)東部（北弗吉尼亞州）地區(qū)。另一個(gè)策略可能允許同一用戶作為非管理員工，訪問(wèn)工作日ERP以實(shí)現(xiàn)其人力資源功能。
■第2步-實(shí)施預(yù)防性控制：執(zhí)行這些策略可防止可能對(duì)治理目標(biāo)最有害的行動(dòng)（如“保護(hù)關(guān)鍵資源和數(shù)據(jù)”）。實(shí)施預(yù)防性控制，涉及多個(gè)供應(yīng)商服務(wù)，如IAM系統(tǒng)、基于角色的訪問(wèn)控制、資源策略控制和財(cái)務(wù)審計(jì)控制。這些往往是供應(yīng)商提供的最強(qiáng)大的治理控制。
■第3步-獲得總體可見(jiàn)性：一旦對(duì)云服務(wù)的訪問(wèn)進(jìn)行了管理，組織必須通過(guò)審計(jì)工作負(fù)載和用戶行為、識(shí)別違反策略的行為和自動(dòng)化行動(dòng)過(guò)程，來(lái)保持對(duì)其云部署的可見(jiàn)性。隨著可見(jiàn)度的提高，我們可以通過(guò)追溯性的策略實(shí)施，來(lái)更好地管理和優(yōu)化云服務(wù)的使用。
■第4步-創(chuàng)建審計(jì)流程以實(shí)施追溯控制：最終用戶在管理自己的資源方面獲得了更多的自主權(quán)。因此，中央IT必須通過(guò)審計(jì)配置和糾正違反策略的行為，來(lái)管理風(fēng)險(xiǎn)和合規(guī)性。IT必須在已建立的反饋循環(huán)的基礎(chǔ)上不斷改進(jìn)治理策略。
■第5步-集成供應(yīng)商本地和第三方工具：您對(duì)多云治理策略的實(shí)施，將跨越本地云供應(yīng)商工具和服務(wù)、第三方云管理平臺(tái)和自定義開(kāi)發(fā)。IaaS和PaaS云供應(yīng)商已經(jīng)嘗試性地將他們的本地工具擴(kuò)展到其他有限領(lǐng)域的供應(yīng)商服務(wù)，比如監(jiān)視。例如，Google Stackdriver Monitoring連接Amazon EC2服務(wù)器來(lái)收集一些度量和事件。Gartner建議您至少圍繞數(shù)據(jù)存儲(chǔ)庫(kù)（識(shí)別資源狀態(tài)的唯一真實(shí)來(lái)源）和支持單點(diǎn)登錄（SSO）的聯(lián)合身份，集成管理工具。
02
為多云管理設(shè)計(jì)工具策略
組織必須通過(guò)選擇和采用最合適的云管理解決方案組合，來(lái)制定云管理工具戰(zhàn)略。創(chuàng)建一個(gè)一致的云管理工具策略需要一個(gè)定義良好的、系統(tǒng)化的方法來(lái)鞏固需求，并將工具與這些需求相匹配。其目的是在滿足所有管理需求的同時(shí)，盡量減少所需的工具數(shù)量。
組織必須從定義其管理需求開(kāi)始。這些要求可以是：
■跨平臺(tái)：所需的功能必須通過(guò)具有一致接口的多個(gè)云平臺(tái)交付。
■特定于平臺(tái)：所需功能特定于一個(gè)云平臺(tái)，并且必須允許訪問(wèn)該特定平臺(tái)中所有可用的粒度控制。
只有在定義并確定其管理需求的優(yōu)先級(jí)之后，組織才能對(duì)云管理工具進(jìn)行評(píng)估、選擇和比較。
Gartner建議優(yōu)先采用云平臺(tái)的原生工具。這些工具與云平臺(tái)深度集成，提供了對(duì)云平臺(tái)服務(wù)的最高深度和廣度的覆蓋。此外，它們嵌入在云平臺(tái)中，不需要單獨(dú)部署。
在第二階段，組織還必須選擇并采用第三方工具，來(lái)解決云平臺(tái)原生工具中的功能差距，或滿足跨平臺(tái)一致性要求。
圖3-云管理轉(zhuǎn)盤(pán)
這個(gè)框架有助于定義云管理需求和評(píng)估CMP和工具的技術(shù)能力。該框架提供了215個(gè)標(biāo)準(zhǔn)，來(lái)對(duì)管理私有、混合和公有云IaaS和PaaS的工具進(jìn)行全面評(píng)估。組織可以使用這些標(biāo)準(zhǔn)來(lái)定義圖3中描述的8個(gè)類(lèi)別（灰色）和4個(gè)跨功能屬性（藍(lán)色）的需求。
03
擁抱可觀察性
長(zhǎng)期以來(lái)，監(jiān)視基礎(chǔ)設(shè)施和應(yīng)用程序的健康和性能，一直是I&O的明確職責(zé)。歷史上，有無(wú)數(shù)的產(chǎn)品和工具（通常由技術(shù)或?qū)I(yè)團(tuán)隊(duì)負(fù)責(zé)）可用于執(zhí)行監(jiān)視功能。各小組相信，他們將得到通知，并準(zhǔn)備在出現(xiàn)問(wèn)題時(shí)作出反應(yīng)。
雖然在過(guò)去，這種方法可能已經(jīng)足夠，但是與現(xiàn)代云和云原生解決方案相關(guān)聯(lián)的速度和復(fù)雜性，已經(jīng)削弱了它的可行性。根據(jù)閾值或預(yù)定義的運(yùn)行狀況檢查進(jìn)行輪詢?nèi)匀缓苤匾?，但這已不足以始終滿足服務(wù)級(jí)別目標(biāo)（service-level objectives）或確保客戶滿意。
部分基于控制理論可觀測(cè)性的軟件可觀測(cè)性，要求有足夠豐富的儀器，以允許開(kāi)發(fā)人員和操作員：
■詢問(wèn)軟件如何工作的問(wèn)題
■在與調(diào)試比運(yùn)維更相似的過(guò)程中，詢問(wèn)內(nèi)部狀態(tài)
監(jiān)視和可觀測(cè)性之間的關(guān)鍵區(qū)別，可能在于監(jiān)視的重點(diǎn)是發(fā)現(xiàn)“已知的未知量”——即檢查錯(cuò)誤和事件，這些錯(cuò)誤和事件是已知的可能性，因?yàn)樗鼈円郧鞍l(fā)生過(guò)。另一方面，可觀察性旨在促進(jìn)“未知的未知量”的發(fā)現(xiàn)，即，以前可能從未發(fā)生過(guò)的情況，以及沒(méi)有任何檢查的情況。
可觀測(cè)性不是一個(gè)在實(shí)際情況發(fā)生后可以很容易地添加到系統(tǒng)中的屬性，例如，當(dāng)解決方案遷移到生產(chǎn)環(huán)境中時(shí)，由運(yùn)維團(tuán)隊(duì)添加。需要內(nèi)置識(shí)別和解釋未知的未知量所需的儀器。
超規(guī)模云供應(yīng)商提供存儲(chǔ)和分析運(yùn)維遙測(cè)的服務(wù)。Amazon CloudWatch、AWS CloudTrail和AWS X-Ray、Google Stackdriver和Microsoft Azure Monitor都可以在您的可觀察性計(jì)劃中發(fā)揮作用。此外，可以使用云原生遙測(cè)源和它們自己的工具并支持可觀測(cè)軟件的其他工具包括：
■大多數(shù)應(yīng)用程序性能監(jiān)視工具，如Cisco（AppDynamics）、Dynatrace、Instana和New Relic
■監(jiān)視和時(shí)間序列平臺(tái)，如Datadog、InfloxData和SignalFx（最近由Splunk收購(gòu)）
■可觀測(cè)性工具，如Honeycomb和LightStep
■分布式跟蹤標(biāo)準(zhǔn)，如OpenCensus和OpenTelemetry
不幸的是，沒(méi)有菜單可以讓人擁抱可觀察性。每個(gè)人都希望避免的一種情況是，從客戶那里收到通知，說(shuō)某個(gè)應(yīng)用程序或服務(wù)不可訪問(wèn)或速度太慢，而監(jiān)視儀表板則表明一切都很完美。
在大多數(shù)情況下，云供應(yīng)商提供的工具支持可觀測(cè)性目標(biāo)（如果被一致使用）。Gartner建議如下：
1.確保平臺(tái)、框架、工具、服務(wù)網(wǎng)格和服務(wù)發(fā)現(xiàn)機(jī)制支持并啟用軟件可觀測(cè)性。
2.使用云供應(yīng)商的監(jiān)視能力，作為觀察托管在那里的工作負(fù)載的焦點(diǎn)。對(duì)于混合和多云應(yīng)用程序，大多數(shù)基于SaaS的和許多自托管工具都支持Amazon CloudWatch、Microsoft Azure Monitor和Google Stackdriver提供的原生集合。
3.整合定制的工具和度量，使您的軟件具有可觀察性。OpenTelemetry是為這個(gè)用例設(shè)計(jì)的框架。
4.建立嵌入式儀器的標(biāo)準(zhǔn)，并作為生產(chǎn)準(zhǔn)備測(cè)試的一部分驗(yàn)證您的可觀測(cè)性機(jī)制。
04
將數(shù)據(jù)合規(guī)性策略擴(kuò)展到公有云
既然《加州消費(fèi)者隱私法》（CCPA）于2020年1月1日生效，人們對(duì)云計(jì)算中的應(yīng)用程序和數(shù)據(jù)的隱私工程重新產(chǎn)生了興趣。在公布時(shí)，有十幾個(gè)國(guó)家提出了在范圍和影響上類(lèi)似于或在某些情況下超過(guò)了聯(lián)合國(guó)貿(mào)易促進(jìn)委員會(huì)的法律草案。在聯(lián)邦一級(jí)，還提出了各種建議，以制定一項(xiàng)一致的、聯(lián)邦授權(quán)的全美國(guó)隱私立法。
組織必須創(chuàng)建一個(gè)連貫的數(shù)據(jù)生態(tài)系統(tǒng)，避免孤立的環(huán)境和零散的數(shù)據(jù)管理做法。在以數(shù)據(jù)為中心的安全架構(gòu)中，技術(shù)專(zhuān)家必須設(shè)計(jì)可以多次使用的隱私保護(hù)，以用于現(xiàn)有和未來(lái)的隱私規(guī)則。
鑒于CCPA和歐盟通用數(shù)據(jù)保護(hù)條例（GDPR）大體相似，Gartner建議采用以下務(wù)實(shí)的方法，我們可以在客戶處觀察到GDPR范圍內(nèi)的個(gè)人數(shù)據(jù)。這些方法是一個(gè)起點(diǎn)，以將隱私設(shè)計(jì)到基于云的項(xiàng)目或部署中：
■了解貴公司正在使用的云服務(wù)。在部門(mén)級(jí)別，IaaS、PaaS和業(yè)務(wù)提供的SaaS服務(wù)可能更容易解釋。然而，較小的團(tuán)隊(duì)或個(gè)人也可能使用額外的SaaS服務(wù)，以使他們的生活更輕松。了解數(shù)據(jù)真正去向的一種方法，是在邊界實(shí)現(xiàn)云訪問(wèn)安全代理（CASB）。
■策劃組織支持的云服務(wù)的正式列表。CCPA范圍內(nèi)的所有服務(wù)和供應(yīng)商必須提供實(shí)施相關(guān)控制的方法，如數(shù)據(jù)發(fā)現(xiàn)、數(shù)據(jù)生命周期管理或數(shù)據(jù)主體訪問(wèn)請(qǐng)求（DSAR，data subject access requests）。并非所有要求都適用于每個(gè)基于云的數(shù)據(jù)倉(cāng)庫(kù)。
■如果您停止使用云服務(wù)，請(qǐng)確保您可以刪除個(gè)人數(shù)據(jù)。對(duì)于IaaS，這可以通過(guò)使用靜態(tài)數(shù)據(jù)加密來(lái)完成，該加密允許您攜帶自己的密鑰（數(shù)字粉碎）。如果您使用對(duì)象（或blob）存儲(chǔ)，或者更高級(jí)別的PaaS和SaaS服務(wù)，則流程會(huì)更復(fù)雜。盡管后一種服務(wù)可能會(huì)透明地加密您的數(shù)據(jù)，但它們可能無(wú)法讓您控制加密密鑰。
■認(rèn)識(shí)到高級(jí)控制（如在云中處理數(shù)據(jù)之前屏蔽數(shù)據(jù)）適合匿名化個(gè)人數(shù)據(jù)，并使您的云部署超出CCPA的范圍。
在國(guó)際上，客戶對(duì)數(shù)據(jù)駐留的需求越來(lái)越感興趣，但云服務(wù)供應(yīng)商仍在努力解決如何最好地滿足這些要求。創(chuàng)建區(qū)域云的嘗試通常失敗。例如，微軟已經(jīng)宣布停止其德國(guó)數(shù)據(jù)托管模式，并將把德國(guó)Azure和Office 365區(qū)域重新納入全球微軟的陣營(yíng)。
試圖將公有云（一種真正的全球化現(xiàn)象）硬塞進(jìn)民族主義思維，最終是徒勞的。當(dāng)一個(gè)組織開(kāi)始在一個(gè)超規(guī)模云中存儲(chǔ)數(shù)據(jù)并執(zhí)行計(jì)算時(shí)，該組織開(kāi)始失去對(duì)其數(shù)據(jù)位置的控制。盡管供應(yīng)商提供名義上的駐留形式，但客戶應(yīng)該預(yù)料到意想不到的副作用。
Gartner建議有數(shù)據(jù)駐留需求的客戶研究新的加密技術(shù)，如多方計(jì)算和機(jī)密計(jì)算，它們聲稱可以有效地使云服務(wù)供應(yīng)商（CSP）對(duì)客戶數(shù)據(jù)視而不見(jiàn)。
05
將數(shù)據(jù)可用性策略擴(kuò)展到公有云
從導(dǎo)致航班取消的停電到導(dǎo)致存儲(chǔ)無(wú)法訪問(wèn)的人為錯(cuò)誤，無(wú)論系統(tǒng)位于何處或由誰(shuí)管理，系統(tǒng)都可能出現(xiàn)故障。無(wú)論服務(wù)位于何處，關(guān)鍵任務(wù)服務(wù)的可用性和公司數(shù)據(jù)的保護(hù)都至關(guān)重要。保護(hù)這些數(shù)據(jù)（通常是組織擁有的最重要資產(chǎn)）是一項(xiàng)信托責(zé)任，需要一個(gè)全面的數(shù)據(jù)可用性策略。
到2020年，使用公有云IaaS作為其數(shù)據(jù)中心備份目的地的企業(yè)數(shù)量，將從2017年初的10%增加至翻一番。
IT服務(wù)不再完全在場(chǎng)內(nèi)提供。利用公有云服務(wù)的混合配置現(xiàn)在是默認(rèn)配置。盡管IaaS、PaaS和SaaS供應(yīng)商提供數(shù)據(jù)彈性，但大多數(shù)都不提供本地備份或自動(dòng)故障轉(zhuǎn)移。這些分布式架構(gòu)的部署模型，迫使IT經(jīng)理和業(yè)務(wù)連續(xù)性規(guī)劃人員重新考慮傳統(tǒng)的備份和數(shù)據(jù)恢復(fù)（DR）策略。現(xiàn)有的數(shù)據(jù)中心解決方案，提供了穩(wěn)健、成熟的數(shù)據(jù)保護(hù)，但必須重新評(píng)估，以確保對(duì)所有基于云的組件的支持。此外，對(duì)網(wǎng)絡(luò)攻擊和勒索軟件威脅的認(rèn)識(shí)提升，正促使各組織審查其災(zāi)難恢復(fù)能力和災(zāi)難恢復(fù)準(zhǔn)備計(jì)劃。
云供應(yīng)商繼續(xù)投資于他們的架構(gòu)，使其具有高度的彈性和可用性。但是，彈性和可用性不足以防止意外刪除、意外中斷、惡意意圖或糟糕的軟件導(dǎo)致的數(shù)據(jù)丟失或損壞。目前，云供應(yīng)商的本地恢復(fù)工具有限且不成熟，在數(shù)據(jù)保護(hù)方面存在明顯差距。雖然云供應(yīng)商將盡一切努力保存數(shù)據(jù)，但他們通常不提供具有集中的基于策略的計(jì)劃和保留的企業(yè)級(jí)備份，也不提供細(xì)粒度的數(shù)據(jù)恢復(fù)選項(xiàng)。
基于SaaS的服務(wù)供應(yīng)商也是如此。組織對(duì)數(shù)據(jù)恢復(fù)（或賠償）沒(méi)有追索權(quán)。無(wú)論數(shù)據(jù)丟失是由服務(wù)中斷、硬件故障、數(shù)據(jù)損壞、惡意操作還是意外刪除造成的，他們都要全權(quán)負(fù)責(zé)數(shù)據(jù)的備份/恢復(fù)。對(duì)于違反SLA的情況，可以提供部分服務(wù)信用。但是，每月費(fèi)用的減少并不包括潛在的大量數(shù)據(jù)替換工作和成本，也不包括由于法律合規(guī)性處罰而造成的損失。
在2020年，Gartner建議企業(yè)重新評(píng)估其數(shù)據(jù)可用性和災(zāi)難恢復(fù)策略，以支持場(chǎng)內(nèi)和基于云的工作負(fù)載。建議包括：
■利用基于云的IaaS服務(wù)：與公有云存儲(chǔ)的集成，已成為企業(yè)備份解決方案的標(biāo)準(zhǔn)。磁盤(pán)到磁盤(pán)到云（D2D2C）備份方法允許您維護(hù)現(xiàn)場(chǎng)備份鏡像，以便快速恢復(fù)大型數(shù)據(jù)集，同時(shí)將訪問(wèn)頻率較低的長(zhǎng)期保留數(shù)據(jù)放置在云存儲(chǔ)層中。目前將遠(yuǎn)程辦公室或端點(diǎn)用戶數(shù)據(jù)備份到本地磁帶的解決方案，可以被直接將數(shù)據(jù)備份到云的成本更低、更易于管理的解決方案所取代。
基于云的災(zāi)難恢復(fù)和災(zāi)難恢復(fù)即服務(wù)（DRAA）進(jìn)一步擴(kuò)展了這一概念。這些方法通過(guò)利用直接復(fù)制到云存儲(chǔ)的基于云的備份數(shù)據(jù)或主數(shù)據(jù)，使工作負(fù)載能夠在云中運(yùn)行。云恢復(fù)作為另一級(jí)場(chǎng)內(nèi)數(shù)據(jù)中心的替代方案，可以消除設(shè)備成本并最大限度地減少備用災(zāi)難恢復(fù)IT基礎(chǔ)架構(gòu)，從而降低資本開(kāi)支和管理開(kāi)銷(xiāo)。
■評(píng)估當(dāng)前場(chǎng)內(nèi)數(shù)據(jù)可用性工具和流程的云可行性：例如，評(píng)估備份、數(shù)據(jù)復(fù)制和災(zāi)難恢復(fù)的編排能力，以確定它們是否可以擴(kuò)展以支持基于云的工作負(fù)載和數(shù)據(jù)。隨著越來(lái)越多的任務(wù)關(guān)鍵型工作負(fù)載遷移到云中或誕生在云中，需要備份/恢復(fù)和災(zāi)難恢復(fù)等標(biāo)準(zhǔn)運(yùn)維過(guò)程來(lái)支持它們。傳統(tǒng)的場(chǎng)內(nèi)備份解決方案包括強(qiáng)大的功能和成熟的管理功能，但它們不是為云部署或按需許可模式而設(shè)計(jì)的。
盡管這些解決方案中有許多基于代理的選項(xiàng)支持公有云VM，但您通常必須先獲得自己的許可證并購(gòu)買(mǎi)基于容量的軟件。您應(yīng)該利用較新的備份即服務(wù)（BaaS）供應(yīng)商的產(chǎn)品，這些產(chǎn)品可以與訂閱、基于使用的消費(fèi)模型一起部署，并可以與云實(shí)踐保持一致。IaaS和SaaS可能需要單獨(dú)的解決方案，因此請(qǐng)尋找支持基于SaaS的領(lǐng)先的應(yīng)用程序的供應(yīng)商，包括Google G Suite、Microsoft Office 365和Salesforce產(chǎn)品。
鑒于數(shù)據(jù)可用性的敏感性和重要性，重新考慮和重新架構(gòu)對(duì)所有數(shù)據(jù)中心和基于云的數(shù)據(jù)的保護(hù)，必須是當(dāng)務(wù)之急。
調(diào)整業(yè)務(wù)政策以整合基于云的數(shù)據(jù)保護(hù)策略
在向更注重云的備份和災(zāi)難恢復(fù)計(jì)劃轉(zhuǎn)變的過(guò)程中，企業(yè)應(yīng)該將業(yè)務(wù)需求與市場(chǎng)上可用的技術(shù)相結(jié)合。在為組織實(shí)施基于SaaS的解決方案時(shí)，I&O專(zhuān)業(yè)人員應(yīng)首先調(diào)查SaaS供應(yīng)商提供的本地?cái)?shù)據(jù)保護(hù)能力。然后，他們應(yīng)該與實(shí)施SaaS解決方案的業(yè)務(wù)經(jīng)理和團(tuán)隊(duì)合作，了解他們對(duì)數(shù)據(jù)保護(hù)和保留的需求。
分析公司當(dāng)前的備份和災(zāi)難恢復(fù)軟件解決方案，以確定它們是否適合SaaS應(yīng)用程序。評(píng)估所提供的能力是否能夠提供所需的保護(hù)級(jí)別。對(duì)于每個(gè)應(yīng)用程序，確定數(shù)據(jù)所在的位置（例如，場(chǎng)內(nèi)或云）以及如何最好地備份該數(shù)據(jù)。最后，調(diào)整策略以整合SaaS和基于云的應(yīng)用程序，以確保滿足公司最佳實(shí)踐，并考慮適當(dāng)?shù)闹卫砗桶踩?/p>
上述步驟總結(jié)如下：
1.審查當(dāng)前的組織備份策略，以了解基于SaaS的應(yīng)用程序適合哪里。
2.確定您需要在哪里實(shí)施第三方解決方案，以解決公有云供應(yīng)商的本地?cái)?shù)據(jù)保護(hù)工具中的差距。
3.制定一項(xiàng)戰(zhàn)略，重點(diǎn)滿足企業(yè)在云端的備份和數(shù)據(jù)保護(hù)方面的需求。具體來(lái)說(shuō)，解決與恢復(fù)點(diǎn)目標(biāo)（RPO）和恢復(fù)時(shí)間目標(biāo)（RTO）相關(guān)的公司策略。
06
對(duì)公有云安全控制實(shí)踐的再思考
云中的工作負(fù)載和數(shù)據(jù)必須與場(chǎng)內(nèi)的工作負(fù)載和數(shù)據(jù)處于相同的安全級(jí)別。雖然本地CSP控制確實(shí)很有用，但它們通常不太直觀，而且過(guò)于關(guān)注自己的環(huán)境。相比之下，客戶需要跨越多個(gè)云的直觀控制。
為了抵御云部署的各種威脅，CWPP提供了跨VM、容器、PaaS工作負(fù)載和無(wú)服務(wù)器工作負(fù)載的安全和保護(hù)功能。它們提供入侵防御、完整性控制和應(yīng)用程序控制等核心服務(wù)，以及加固、配置和差異化縱深防御的安全能力。供應(yīng)商的能力通常集中在7個(gè)分組上。圖4通過(guò)比較這些分組能力如何最好地處理一組威脅場(chǎng)景，來(lái)分析這些分組功能。
圖4.CWPP變體的“DNA標(biāo)記”類(lèi)比圖
圖4 顯示了CWPP供應(yīng)商工具中的關(guān)鍵功能。已識(shí)別出7種CWPP變體，這些變體因工具傳統(tǒng)和技術(shù)重點(diǎn)而異：
■廣譜：這一類(lèi)別包括更大的供應(yīng)商，他們將其他工具融合在一起，以產(chǎn)生跨多個(gè)操作系統(tǒng)（OS）的多方面服務(wù)能力。
■聚焦于容器：一般來(lái)說(shuō)，這一類(lèi)別涵蓋了一系列廣泛的能力，重點(diǎn)放在容器部署上。
■網(wǎng)絡(luò)和微分段：這些工具支持使用基于主機(jī)的防火墻對(duì)計(jì)算平臺(tái)進(jìn)行邏輯隔離的綜合方法。它們?cè)诰W(wǎng)絡(luò)層和應(yīng)用程序?qū)犹峁┛梢?jiàn)性控制。它們還提供網(wǎng)絡(luò)安全、訪問(wèn)控制和威脅情報(bào)服務(wù)。
■內(nèi)存和進(jìn)程完整性保護(hù)：這些工具保護(hù)計(jì)算服務(wù)，確保內(nèi)存和進(jìn)程的完整性。這些工具還將其他服務(wù)放在計(jì)算保護(hù)之上，例如嚴(yán)格的應(yīng)用程序控制、加固和配置。
■聚焦于無(wú)服務(wù)器：這些工具旨在保護(hù)無(wú)服務(wù)器、基于功能的云計(jì)算服務(wù)。他們主要關(guān)注應(yīng)用程序控制、訪問(wèn)控制和用戶行為分析。
■聚焦于EDR：這一類(lèi)別包括將端點(diǎn)檢測(cè)和響應(yīng)（EDR）功能擴(kuò)展到云中的供應(yīng)商。這些工具增加了配置和加固功能，以及工作負(fù)載行為監(jiān)視和威脅檢測(cè)。
■脆弱性、加固和配置合規(guī)性：這類(lèi)工具來(lái)自合規(guī)平臺(tái)。它們重點(diǎn)關(guān)注持續(xù)的合規(guī)性、資產(chǎn)清單和漏洞報(bào)告。
選擇正確的CWPP能力來(lái)增強(qiáng)云安全性，對(duì)技術(shù)專(zhuān)家來(lái)說(shuō)是一個(gè)挑戰(zhàn)。我們的建議可以促進(jìn)這一進(jìn)程：
■選擇一個(gè)CWPP供應(yīng)商工具，該工具涵蓋公有云供應(yīng)商的本地工作負(fù)載安全服務(wù)未解決的已識(shí)別能力差距。CWPP還可以為跨不同IaaS部署的工作負(fù)載提供一致性。
■使用CWPP提高可見(jiàn)性，以便您能夠?qū)Ξ惓：臀唇?jīng)授權(quán)的工作負(fù)載行為進(jìn)行檢測(cè)和響應(yīng)。此外，使用CWPP來(lái)加強(qiáng)控制，以便可以限制所有運(yùn)行時(shí)工作負(fù)載的威脅機(jī)會(huì)。
■利用CWPP工具，提供為應(yīng)用程序和系統(tǒng)行為形成基線的方法。然后，報(bào)告偏差以盡量減少誤報(bào)。
■通過(guò)將應(yīng)用程序控制、系統(tǒng)加固和系統(tǒng)配置優(yōu)先于以前的基于防病毒的方法，重新調(diào)整工作負(fù)載安全方法的重點(diǎn)。
