【51CTO.com原創(chuàng)稿件】長期以來，我們著眼于IT基礎設施，硬件設備和軟件應用的運維;并且一直踐行著用ITIL這樣的框架來優(yōu)化和治理所提供的各種服務。但是隨著我們的企業(yè)開始將業(yè)務向云端進行拓展、部署或是遷移，咱們許多IT運維管理人員的工作職責與內(nèi)容也發(fā)生了潛移默化的變化。

無論面對的是私有云的系統(tǒng)、公有云的服務還是混合云的架構，我們從基礎細節(jié)提升到了管理迭代的層面上。伴隨著這種工作內(nèi)容上的level up，愛思考的您是否考慮過一個問題：ITIL的“前半生”已為我們的企業(yè)IT服務治理帶來了不少的紅利，如今的云服務時代，它是和權游一樣面臨著“Winter is coming”呢?還是能繼續(xù)“春風十里”呢?它對于企業(yè)各種云業(yè)務的管理是否還適用呢?答案這里先不給出，且讓我慢慢用ITIL v3的管理概念來試著和給大家探討一下對于企業(yè)云服務的治理吧。

[[202755]]

大家都知道云服務吸引企業(yè)的地方在于：按需分配、快速發(fā)布、彈性伸縮、和資源池化。而我們常用的ITIL v3所涉及到的服務生命周期則包括：服務設計、服務轉(zhuǎn)換、服務運營、服務改進。細心的小伙伴一定會問：那么“服務策略”呢?這個策略嘛，比較高端，講真，我們做運維的參與的機會并不多，所以在此暫且不表。因此，我們不難發(fā)現(xiàn)云服務和ITIL的各自四個特點是隱約存在著一定對應關系的。

服務設計vs.按需分配

在這個層面上，我覺得和以前內(nèi)部IT系統(tǒng)的管理流量并沒有太大的不同之處，我們更應該注重從業(yè)務和產(chǎn)品需求出發(fā)，對于任何要遷移到云端或是新增的云業(yè)務都須做好服務編錄設計、級別配比、和安全預設的工作。

1. 編錄設計

首先要做好產(chǎn)品和服務的分類與編錄。比如說，在典型的應用場景中，企業(yè)所可能采用的云服務功能領域包括：生產(chǎn)環(huán)境云、開發(fā)測試資源云、內(nèi)訓教學云、桌面云、以及運維資源云等。在每一種云服務里，我們可以根據(jù)數(shù)據(jù)和服務類型進行細化，根據(jù)各個應用和不同系統(tǒng)之間的數(shù)據(jù)流向，勾勒出流轉(zhuǎn)的圖表，清晰地定義出何種類型的數(shù)據(jù)將會在邏輯上或物理上存儲在何處，它們是如何在組織/系統(tǒng)間進行流動，以及它們會受到何種方式的管理和保護等。當然，由于云業(yè)務突破了地域上的局限性，我們也要適當?shù)貙?shù)據(jù)的存儲和可能在遷移時所涉及到的當?shù)叵嚓P法律及監(jiān)管要求予以研究和說明。

2. 級別配比

隨著企業(yè)云業(yè)務的深入，我們以往對于用戶和客戶的服務承諾與品質(zhì)保障被逐漸地從日常工作中剝離，進而部分轉(zhuǎn)移到了云服務商那里。在大多數(shù)企業(yè)的實踐中，IT部門降低了以往運維工作的比重，而會花更多的時間從RTO和RPO出發(fā)，去評估包括基礎網(wǎng)絡帶寬、高可用性、并發(fā)數(shù)、響應時間、存儲頻率和備份深度等指標。

他們通過與云服務商進行協(xié)商和約定，進而界定出那些本企業(yè)與服務商之間，以及各個服務商之間的易重疊或不清晰部分，以免出現(xiàn)“踢皮球”的情況。這對IT部門來說既是原有服務級別的保持與延續(xù)，又能保證合理的服務資源的分配，同時還為我們馬上要提到的安全預設做好了基本準備。

3. 安全

曾經(jīng)有不止一個運維部門的小伙伴向我抱怨：“一入云端深似海，從此安全是路人”。那么到底有多深呢?讓我們具體從如下不同的角度來分析一下吧。

首先是在物理上，可分兩部分：

• 對內(nèi)，有用戶桌面云和私有云的安全。此方面我們有著以往安全實踐的經(jīng)驗，還是同樣的操作，熟悉的味道，在此就不贅述了。
• 對外，則是云服務商或者是我們托管在IDC處的安全。他們大多數(shù)情況下僅提供入站防火墻功能，而沒有出站控制。不過這個也比較好理解，因為具體的應用環(huán)境和服務是由咱們的團隊所自行搭建的。所以我們可以添加云WAF，通過將DNS的記錄進行重定向，由云WAF來過濾各種未經(jīng)驗證的訪問流量之后，再轉(zhuǎn)發(fā)給真正的云Web應用。

其次是在邏輯上，其“任督二脈”是：相對動態(tài)的數(shù)據(jù)和相對靜態(tài)的應用。

(1) 在一般云業(yè)務中，數(shù)據(jù)仍舊遵循著“創(chuàng)建->存儲->使用->共享->傳送->歸檔->銷毀”的生命周期軌跡，所以我們應當：

• 在創(chuàng)建與存儲階段：做好數(shù)據(jù)本身的加密。
• 在使用與共享階段：通過部署在虛機或是hypervisor的agent對元數(shù)據(jù)(如數(shù)據(jù)屬性標簽)的檢索來實現(xiàn)DLP(數(shù)據(jù)防泄漏)。
• 在傳送與歸檔階段：采用SSL/TLS、VPN或SSH來實現(xiàn)數(shù)據(jù)的屏蔽并保障完整性。
• 在銷毀階段：清理數(shù)據(jù)殘留并予以脫敏或替換，以免泄露給在云空間里物理上交錯的其他租戶。

(2) 而對于云應用方面的安全，我們可以采取身份和訪問管理(IAM)，在確保各種來自AD、LDAP或其他SaaS服務商的用戶賬號信息能夠在內(nèi)部同步的前提條件下，利用SAML、XACML或Oauth來基于角色和權限的映射矩陣，保證用戶僅能看到他們有權訪問的數(shù)據(jù)。

可見，對于IaaS模式的業(yè)務來說，由于從系統(tǒng)層面上為我們所掌控，因此完全可以利用各種工具和手段，給系統(tǒng)做“大保養(yǎng)”，來保證各類云資產(chǎn)和服務的安全。而SaaS則相反，由于我們能夠訪問和掌握的信息源數(shù)量最少，因此其安全責任主要是服務商所承擔，而約束性合同則是我們的唯一抓手。

二、服務轉(zhuǎn)換vs. 快速發(fā)布

云業(yè)務的彈性靈活和快速轉(zhuǎn)換的特點雖然是那么的“金光閃閃的”，但是也給我們運維團隊帶來了配置和變更上的復雜性。以往，我們一旦在系統(tǒng)的初期完成了配置與部署，就能夠管上一段時間。而變更更是能懟就懟回去，實在頂不住也要通過規(guī)范的流程來謹慎行事。而現(xiàn)在呢?由于“試錯”的成本降低了，各種“花式”的變更需求已經(jīng)成為了家常便飯，配套的配置信息也像松鼠屯糧一般妥妥地上漲。

1. 配置

我們在過往的廉環(huán)話里有討論過有關配置管理方面的各種實踐。這里，我們著重來聊一聊和云服務有關的配置方面的問題。對于企業(yè)內(nèi)部桌面云的配套設備而言，雖然很多已經(jīng)做到了OOTB(開箱即用)，但是一些例行的升級和資產(chǎn)的錄入與統(tǒng)計，還是需要我們IT人員去持續(xù)跟進的。因此我們?nèi)匀挥斜匾局?ldquo;做一看二想三”的宗旨，搭建和維護好一個配置管理數(shù)據(jù)庫。該CMDB除了能夠根據(jù)后期實際需求進行各種表項和字段的擴充以外，還應當使得保存在其中的各種配置基線具有可移植性，以方便根據(jù)不同的云服務應用場景進行靈活組合和快速成型。

2. 變更

• 對于有計劃的服務改進所產(chǎn)生的主動變更，高效的云服務已經(jīng)將其出錯的風險、和回滾的難度都降到了最低。我們反而應當跟上或是做好諸如鏡像與配置模板的修改，云存儲空間池的配額和虛擬CPU/內(nèi)存資源的增減，等方面的計劃與記錄工作。
• 而對于各種事故或故障所導致的被動變更，以往由于我們運維部門對服務和系統(tǒng)的責任比較明確，因此有著絕對的掌控能力。但是如今轉(zhuǎn)到了云端， IT部門就需要根據(jù)既定的協(xié)議與云服務商事先明確好各自的職責，比如說：在什么情況下云服務商有權先采取必要的變更、再通知租戶;什么情況下我們的自行變更需要備案、甚至要得到服務商的批準，以免傷及其他的租戶。

3. 測試

• 云服務發(fā)布之前：以往，我們需要配備專門的測試部門和人員，花費時間、騰出硬件資源、并通過購買測試軟件搭建測試環(huán)境。而現(xiàn)在我們不但可以自行快速組建開發(fā)測試的云資源，還能購置一些24×7可用性的外部云測試環(huán)境。如此一來，我們就可以將精力專注于測試流程和內(nèi)容之上，對服務的響應時間、資源利用率、容錯穩(wěn)定性、最大承壓、和在不同負載條件下的可擴展性等方面進行全面的性能測試。
• 云服務上線之后：我們可以在征得云服務商確認的情況下(因為有時候不同服務商的允許策略會有所差異)，做好各種漏洞掃描和滲透測試，以抵御來自縱向的外部威脅和橫向的其他租戶的攻擊。

4. 發(fā)布

• 發(fā)布方式上的轉(zhuǎn)變：我們在處理云服務的更新與發(fā)布時，用得最多的就是：“讓一部分人先用起來”的灰度發(fā)布模式。即：在允許一部分用戶繼續(xù)使用1.0版本的同時，讓另一部分用戶充當“吃螃蟹”的小白鼠，開始使用2.0版。如果2.0運行穩(wěn)定，而且其用戶體驗不錯，則逐步擴大范圍，將所有用戶都遷移到過來。可見，灰度發(fā)布方式更適合于發(fā)現(xiàn)、調(diào)整問題，并限制其波及面，避免被用戶“吊打”的情況發(fā)生。
• 發(fā)布效率上的提升：由于云業(yè)務實現(xiàn)了我們運維的對象從傳統(tǒng)的以“硬件設備”為中心向著以“虛擬實例”為中心的轉(zhuǎn)變，因此在發(fā)布效率上，IT人員更能夠從各種資源池中迅速地虛擬化出各種應用的實例，然后根據(jù)既定的策略實現(xiàn)自動化的部署。顯然，這種發(fā)布流程有效地減少了以往由于全靠人工處理所帶來的業(yè)務延遲或中斷的可能性。

三、服務運營vs. 資源池化

1. 容量/資源池

清晰的容量和性能需求對于云服務的空間與資源的預估和購買是相當重要的，同時也能夠在云業(yè)務的上線之初和交付之后的一段時間內(nèi)，有效地杜絕潛在的中斷和性能瓶頸。當然，我們也應該與云服務商事先制定好按需訂閱或擴容條款。如果購置的是IaaS的話，我們則可以在實際需求或業(yè)務模式發(fā)生變化時，及時地根據(jù)CMDB里的模板產(chǎn)生新出的虛擬機、動態(tài)地增配CPU和內(nèi)存的數(shù)量、以及臨時將某個host遷移到他處等。

2. 高可用性/連續(xù)性

憑借著虛擬化主機和網(wǎng)絡設備的鏡像和數(shù)量的優(yōu)勢，我們的云業(yè)務可以充分發(fā)揮其服務的自愈和擴展能力，從而實現(xiàn)HA、業(yè)務連續(xù)性、和災難恢復的效率。我們平時的各種重復單調(diào)的維護工作量也能相應地大幅減少。當然，對于那些和我們的系統(tǒng)有關，但由云服務商所負責的部分，我們不能只是被動地接受其例行的測試成功報告，而應當主動要求，真正地參到測試環(huán)節(jié)之中。

3. 事件/故障響應

在云業(yè)務環(huán)境中，由于突破了以往的一套系統(tǒng)僅能提供單一服務的限制，所以造成了應用種類、數(shù)據(jù)混雜、和設備資源相互交錯的狀態(tài)。我們所面對的早就不再是能否撲捉截取到事件發(fā)生的問題了，而是各種被自動采集的海量事件集中性地撲面而來，所導致的篩選、分析和去除誤報的局面。

具體來說，對于采用SaaS模式的企業(yè)，可能會更多地需要依賴云服務商的來采取各種的應急響應措施。而對于使用IaaS的企業(yè)，其IT部門則有能力和責任按照我們在《安全事件響應之五步進階》里提到的“識別和分類->調(diào)查和取證->抑制、根除和恢復”的流程進行應對。我們逆推著來看：

• 抑制是關鍵，我們可以通過暫停被攻破的虛機鏡像，隔離它與其他系統(tǒng)的邏輯聯(lián)系，從而既不會破壞它上面的證據(jù)，又能夠阻止形式的惡化。
• 我們曾經(jīng)在《安全入侵應對實務—內(nèi)網(wǎng)偵查篇》中著重討論過“取證與調(diào)查”。現(xiàn)如今，我們來到了云端，其取證的環(huán)境變得高度動態(tài)且不定，這就對我們?nèi)∽C的各種要素，包括確定范圍、收集方式、保留語義完整、和維持證據(jù)穩(wěn)定等都帶來了挑戰(zhàn)。與此同時，隱私也是不可忽略的要素，同樣需要服務商的合作與支持。
• 而在各種事件的識別和響應上，我們需要考慮到由于業(yè)務系統(tǒng)不再孤立的存在于我們可控的環(huán)境中，所導致的那些針對云服務商的攻擊也可能會給咱們系統(tǒng)帶來的“殃及池魚”的影響。例如：針對您所在的云環(huán)境本身或是其它租戶的DDOS攻擊，就算并非是攻擊的目標，您的業(yè)務可用性也會有所波及。因此我們同樣要做好信息的收集和事件的分析等工作。

可見，我們需要建立的是一套更全面和有互動性的日常管理流程，而非針對某個產(chǎn)品或項目的特定應對模式。與此同時，我們可以采用當前比較流行的大數(shù)據(jù)分析的一些工具，在實現(xiàn)快速綜合性的智能分析的前提下，獲取本企業(yè)不同應用中的云業(yè)務的全網(wǎng)視圖，綜合分析各種安全狀況、安全事件和安全趨勢，做到防范于未然。

四、持續(xù)改進vs. 彈性伸縮

1. 持續(xù)監(jiān)控

對于我們一般的企業(yè)而言，IT運維部門做好對既有云業(yè)務的監(jiān)控與管理是很有必要的。監(jiān)控的重點應當放在三個方面：

• 云平臺對外或者對于內(nèi)部員工所提供的各種應用服務的performance。
• 在服務使用的過程中所產(chǎn)生的流量和費用等，也就是所謂的財務監(jiān)控。
• 根據(jù)預先定義的條件和閾值，實時進行數(shù)據(jù)庫活動監(jiān)控(DAM)、策略違規(guī)監(jiān)控、和惡意使用于入侵的監(jiān)控與分析。

記住：監(jiān)控只是手段，不是目的。其真正目的就是要能夠?qū)崟r了解到使用的需求、消費狀況、和安全的態(tài)勢，通過對現(xiàn)有云服務資源的彈性調(diào)整，從而改變以往對物理資源的死板預分配和對網(wǎng)絡帶寬的滯后的模式，形成正反饋。

2. 動態(tài)調(diào)整

技術和設施都在不斷迭代和進步，因此我們可能會從整體性能以及運營成本等多方面考慮是否需要對運行了一段時間的云業(yè)務進行整體或部分的遷移。遷移的前提條件是：要保證前后服務商所提供的云服務產(chǎn)品的互操作性和延續(xù)性。就像以往能夠在不同的硬件設備環(huán)境中部署系統(tǒng)那樣，我們要求企業(yè)云業(yè)務的各種組件也能夠被來自不同服務商的環(huán)境所替換，平滑地部署應用，并能交換導出/導入，從而最終實現(xiàn)無縫遷移和持續(xù)運營。

有過運維經(jīng)驗的小伙伴應該知道，從遷移的難度上說，SaaS>PaaS>IaaS。而可能碰到的問題會包括：舊云平臺所用到的API、數(shù)據(jù)格式、標準和支持文檔、業(yè)務的定制部分的舊平臺依賴性和新平臺的不兼容性、以及業(yè)務的起/停順序和導致的中斷等問題。因此，我們運維人員需要提前理解和做好數(shù)據(jù)備份、新應用的部署、以及切換順序和詳盡的回滾方案。同時在遷移結束、配置信息調(diào)整以及測試完成之后，我們不可馬上與舊的云服務平臺拗斷，因為很可能需要讓新舊云業(yè)務并行地運行一段時間。

3. 服務商管理

前面我們屢次提到如何與云服務商進行各種協(xié)作。但是由于他們不再會來到我們的機房或辦公區(qū)，我們也不大可能常去他們的云服務機房，而且其提供的云服務也不再顯而易見，那么我們最終如何考量他們的服務級別的達標情況呢?我們根據(jù)實踐經(jīng)驗發(fā)現(xiàn)：只能通過設定好的報告模板和內(nèi)容項的格式，并審計和匯總其呈交的各類報告，來實現(xiàn)遠程地協(xié)調(diào)與管理，從而在整體上改善和提高其服務的“信價比”。當然，我們也可以將各個服務商予以“池化”，營造良性競爭的環(huán)境，對于無法通過自身改進來提升服務種類和質(zhì)量的服務商，就只能讓他去領便當了。

總的說來，在您的云業(yè)務中，如果云服務商所提供的“XX即服務”占比越多，您在治理控制方面的靈活性就越弱，他們的責任就越大;相反，倘若他們的占比越少，您的管控能力則越強，相應的負責也就越大。因此，大家依據(jù)服務合同，不應該“互相傷害”而是要“愉快地玩耍”。

小結

上面和大家聊了不少ITIL在云治理中的運用和實踐。可見ITIL的服務管理“套路”還是能夠在企業(yè)新的云應用場景中保持老當益壯，煥發(fā)第二春的。而作為IT運維的我們，工作內(nèi)容已經(jīng)從原來的單純技術，滋長成了“技術+管理+業(yè)務”。

有經(jīng)驗的小伙伴也許有這樣的體會，根據(jù)各個企業(yè)的實際規(guī)模、需求狀況，以及云業(yè)務實現(xiàn)程度的不同，各類IT管理與運維人員也有著細微的專注點。比如說：基礎日常運維人員會更關注于IaaS，項目、部署人員則更關注于PaaS，而業(yè)務支持人員可能主要關注的是SaaS。但是，無論您在企業(yè)中是什么角色，關注哪一方面的云服務，我都希望您能夠運用ITIL這把“洛陽鏟”繼續(xù)深耕云業(yè)務，解鎖出了更多的運維和管理的新技能。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】

戳這里，看該作者更多好文