【廉環(huán)話】ITIL老矣，能治“云”否?
原創(chuàng)【51CTO.com原創(chuàng)稿件】長期以來，我們著眼于IT基礎(chǔ)設(shè)施，硬件設(shè)備和軟件應(yīng)用的運(yùn)維;并且一直踐行著用ITIL這樣的框架來優(yōu)化和治理所提供的各種服務(wù)。但是隨著我們的企業(yè)開始將業(yè)務(wù)向云端進(jìn)行拓展、部署或是遷移，咱們許多IT運(yùn)維管理人員的工作職責(zé)與內(nèi)容也發(fā)生了潛移默化的變化。
無論面對的是私有云的系統(tǒng)、公有云的服務(wù)還是混合云的架構(gòu)，我們從基礎(chǔ)細(xì)節(jié)提升到了管理迭代的層面上。伴隨著這種工作內(nèi)容上的level up，愛思考的您是否考慮過一個問題：ITIL的“前半生”已為我們的企業(yè)IT服務(wù)治理帶來了不少的紅利，如今的云服務(wù)時代，它是和權(quán)游一樣面臨著“Winter is coming”呢?還是能繼續(xù)“春風(fēng)十里”呢?它對于企業(yè)各種云業(yè)務(wù)的管理是否還適用呢?答案這里先不給出，且讓我慢慢用ITIL v3的管理概念來試著和給大家探討一下對于企業(yè)云服務(wù)的治理吧。
大家都知道云服務(wù)吸引企業(yè)的地方在于：按需分配、快速發(fā)布、彈性伸縮、和資源池化。而我們常用的ITIL v3所涉及到的服務(wù)生命周期則包括：服務(wù)設(shè)計(jì)、服務(wù)轉(zhuǎn)換、服務(wù)運(yùn)營、服務(wù)改進(jìn)。細(xì)心的小伙伴一定會問：那么“服務(wù)策略”呢?這個策略嘛，比較高端，講真，我們做運(yùn)維的參與的機(jī)會并不多，所以在此暫且不表。因此，我們不難發(fā)現(xiàn)云服務(wù)和ITIL的各自四個特點(diǎn)是隱約存在著一定對應(yīng)關(guān)系的。
服務(wù)設(shè)計(jì)vs.按需分配
在這個層面上，我覺得和以前內(nèi)部IT系統(tǒng)的管理流量并沒有太大的不同之處，我們更應(yīng)該注重從業(yè)務(wù)和產(chǎn)品需求出發(fā)，對于任何要遷移到云端或是新增的云業(yè)務(wù)都須做好服務(wù)編錄設(shè)計(jì)、級別配比、和安全預(yù)設(shè)的工作。
1. 編錄設(shè)計(jì)
首先要做好產(chǎn)品和服務(wù)的分類與編錄。比如說，在典型的應(yīng)用場景中，企業(yè)所可能采用的云服務(wù)功能領(lǐng)域包括：生產(chǎn)環(huán)境云、開發(fā)測試資源云、內(nèi)訓(xùn)教學(xué)云、桌面云、以及運(yùn)維資源云等。在每一種云服務(wù)里，我們可以根據(jù)數(shù)據(jù)和服務(wù)類型進(jìn)行細(xì)化，根據(jù)各個應(yīng)用和不同系統(tǒng)之間的數(shù)據(jù)流向，勾勒出流轉(zhuǎn)的圖表，清晰地定義出何種類型的數(shù)據(jù)將會在邏輯上或物理上存儲在何處，它們是如何在組織/系統(tǒng)間進(jìn)行流動，以及它們會受到何種方式的管理和保護(hù)等。當(dāng)然，由于云業(yè)務(wù)突破了地域上的局限性，我們也要適當(dāng)?shù)貙?shù)據(jù)的存儲和可能在遷移時所涉及到的當(dāng)?shù)叵嚓P(guān)法律及監(jiān)管要求予以研究和說明。
2. 級別配比
隨著企業(yè)云業(yè)務(wù)的深入，我們以往對于用戶和客戶的服務(wù)承諾與品質(zhì)保障被逐漸地從日常工作中剝離，進(jìn)而部分轉(zhuǎn)移到了云服務(wù)商那里。在大多數(shù)企業(yè)的實(shí)踐中，IT部門降低了以往運(yùn)維工作的比重，而會花更多的時間從RTO和RPO出發(fā)，去評估包括基礎(chǔ)網(wǎng)絡(luò)帶寬、高可用性、并發(fā)數(shù)、響應(yīng)時間、存儲頻率和備份深度等指標(biāo)。
他們通過與云服務(wù)商進(jìn)行協(xié)商和約定，進(jìn)而界定出那些本企業(yè)與服務(wù)商之間，以及各個服務(wù)商之間的易重疊或不清晰部分，以免出現(xiàn)“踢皮球”的情況。這對IT部門來說既是原有服務(wù)級別的保持與延續(xù)，又能保證合理的服務(wù)資源的分配，同時還為我們馬上要提到的安全預(yù)設(shè)做好了基本準(zhǔn)備。
3. 安全
曾經(jīng)有不止一個運(yùn)維部門的小伙伴向我抱怨：“一入云端深似海，從此安全是路人”。那么到底有多深呢?讓我們具體從如下不同的角度來分析一下吧。
首先是在物理上，可分兩部分：
- 對內(nèi)，有用戶桌面云和私有云的安全。此方面我們有著以往安全實(shí)踐的經(jīng)驗(yàn)，還是同樣的操作，熟悉的味道，在此就不贅述了。
- 對外，則是云服務(wù)商或者是我們托管在IDC處的安全。他們大多數(shù)情況下僅提供入站防火墻功能，而沒有出站控制。不過這個也比較好理解，因?yàn)榫唧w的應(yīng)用環(huán)境和服務(wù)是由咱們的團(tuán)隊(duì)所自行搭建的。所以我們可以添加云WAF，通過將DNS的記錄進(jìn)行重定向，由云WAF來過濾各種未經(jīng)驗(yàn)證的訪問流量之后，再轉(zhuǎn)發(fā)給真正的云Web應(yīng)用。
其次是在邏輯上，其“任督二脈”是：相對動態(tài)的數(shù)據(jù)和相對靜態(tài)的應(yīng)用。
(1) 在一般云業(yè)務(wù)中，數(shù)據(jù)仍舊遵循著“創(chuàng)建->存儲->使用->共享->傳送->歸檔->銷毀”的生命周期軌跡，所以我們應(yīng)當(dāng)：
- 在創(chuàng)建與存儲階段：做好數(shù)據(jù)本身的加密。
- 在使用與共享階段：通過部署在虛機(jī)或是hypervisor的agent對元數(shù)據(jù)(如數(shù)據(jù)屬性標(biāo)簽)的檢索來實(shí)現(xiàn)DLP(數(shù)據(jù)防泄漏)。
- 在傳送與歸檔階段：采用SSL/TLS、VPN或SSH來實(shí)現(xiàn)數(shù)據(jù)的屏蔽并保障完整性。
- 在銷毀階段：清理數(shù)據(jù)殘留并予以脫敏或替換，以免泄露給在云空間里物理上交錯的其他租戶。
(2) 而對于云應(yīng)用方面的安全，我們可以采取身份和訪問管理(IAM)，在確保各種來自AD、LDAP或其他SaaS服務(wù)商的用戶賬號信息能夠在內(nèi)部同步的前提條件下，利用SAML、XACML或Oauth來基于角色和權(quán)限的映射矩陣，保證用戶僅能看到他們有權(quán)訪問的數(shù)據(jù)。
可見，對于IaaS模式的業(yè)務(wù)來說，由于從系統(tǒng)層面上為我們所掌控，因此完全可以利用各種工具和手段，給系統(tǒng)做“大保養(yǎng)”，來保證各類云資產(chǎn)和服務(wù)的安全。而SaaS則相反，由于我們能夠訪問和掌握的信息源數(shù)量最少，因此其安全責(zé)任主要是服務(wù)商所承擔(dān)，而約束性合同則是我們的唯一抓手。
二、服務(wù)轉(zhuǎn)換vs. 快速發(fā)布
云業(yè)務(wù)的彈性靈活和快速轉(zhuǎn)換的特點(diǎn)雖然是那么的“金光閃閃的”，但是也給我們運(yùn)維團(tuán)隊(duì)帶來了配置和變更上的復(fù)雜性。以往，我們一旦在系統(tǒng)的初期完成了配置與部署，就能夠管上一段時間。而變更更是能懟就懟回去，實(shí)在頂不住也要通過規(guī)范的流程來謹(jǐn)慎行事。而現(xiàn)在呢?由于“試錯”的成本降低了，各種“花式”的變更需求已經(jīng)成為了家常便飯，配套的配置信息也像松鼠屯糧一般妥妥地上漲。
1. 配置
我們在過往的廉環(huán)話里有討論過有關(guān)配置管理方面的各種實(shí)踐。這里，我們著重來聊一聊和云服務(wù)有關(guān)的配置方面的問題。對于企業(yè)內(nèi)部桌面云的配套設(shè)備而言，雖然很多已經(jīng)做到了OOTB(開箱即用)，但是一些例行的升級和資產(chǎn)的錄入與統(tǒng)計(jì)，還是需要我們IT人員去持續(xù)跟進(jìn)的。因此我們?nèi)匀挥斜匾局?ldquo;做一看二想三”的宗旨，搭建和維護(hù)好一個配置管理數(shù)據(jù)庫。該CMDB除了能夠根據(jù)后期實(shí)際需求進(jìn)行各種表項(xiàng)和字段的擴(kuò)充以外，還應(yīng)當(dāng)使得保存在其中的各種配置基線具有可移植性，以方便根據(jù)不同的云服務(wù)應(yīng)用場景進(jìn)行靈活組合和快速成型。
2. 變更
- 對于有計(jì)劃的服務(wù)改進(jìn)所產(chǎn)生的主動變更，高效的云服務(wù)已經(jīng)將其出錯的風(fēng)險(xiǎn)、和回滾的難度都降到了最低。我們反而應(yīng)當(dāng)跟上或是做好諸如鏡像與配置模板的修改，云存儲空間池的配額和虛擬CPU/內(nèi)存資源的增減，等方面的計(jì)劃與記錄工作。
- 而對于各種事故或故障所導(dǎo)致的被動變更，以往由于我們運(yùn)維部門對服務(wù)和系統(tǒng)的責(zé)任比較明確，因此有著絕對的掌控能力。但是如今轉(zhuǎn)到了云端， IT部門就需要根據(jù)既定的協(xié)議與云服務(wù)商事先明確好各自的職責(zé)，比如說：在什么情況下云服務(wù)商有權(quán)先采取必要的變更、再通知租戶;什么情況下我們的自行變更需要備案、甚至要得到服務(wù)商的批準(zhǔn)，以免傷及其他的租戶。
3. 測試
- 云服務(wù)發(fā)布之前：以往，我們需要配備專門的測試部門和人員，花費(fèi)時間、騰出硬件資源、并通過購買測試軟件搭建測試環(huán)境。而現(xiàn)在我們不但可以自行快速組建開發(fā)測試的云資源，還能購置一些24×7可用性的外部云測試環(huán)境。如此一來，我們就可以將精力專注于測試流程和內(nèi)容之上，對服務(wù)的響應(yīng)時間、資源利用率、容錯穩(wěn)定性、最大承壓、和在不同負(fù)載條件下的可擴(kuò)展性等方面進(jìn)行全面的性能測試。
- 云服務(wù)上線之后：我們可以在征得云服務(wù)商確認(rèn)的情況下(因?yàn)橛袝r候不同服務(wù)商的允許策略會有所差異)，做好各種漏洞掃描和滲透測試，以抵御來自縱向的外部威脅和橫向的其他租戶的攻擊。
4. 發(fā)布
- 發(fā)布方式上的轉(zhuǎn)變：我們在處理云服務(wù)的更新與發(fā)布時，用得最多的就是：“讓一部分人先用起來”的灰度發(fā)布模式。即：在允許一部分用戶繼續(xù)使用1.0版本的同時，讓另一部分用戶充當(dāng)“吃螃蟹”的小白鼠，開始使用2.0版。如果2.0運(yùn)行穩(wěn)定，而且其用戶體驗(yàn)不錯，則逐步擴(kuò)大范圍，將所有用戶都遷移到過來?？梢?，灰度發(fā)布方式更適合于發(fā)現(xiàn)、調(diào)整問題，并限制其波及面，避免被用戶“吊打”的情況發(fā)生。
- 發(fā)布效率上的提升：由于云業(yè)務(wù)實(shí)現(xiàn)了我們運(yùn)維的對象從傳統(tǒng)的以“硬件設(shè)備”為中心向著以“虛擬實(shí)例”為中心的轉(zhuǎn)變，因此在發(fā)布效率上，IT人員更能夠從各種資源池中迅速地虛擬化出各種應(yīng)用的實(shí)例，然后根據(jù)既定的策略實(shí)現(xiàn)自動化的部署。顯然，這種發(fā)布流程有效地減少了以往由于全靠人工處理所帶來的業(yè)務(wù)延遲或中斷的可能性。
三、服務(wù)運(yùn)營vs. 資源池化
1. 容量/資源池
清晰的容量和性能需求對于云服務(wù)的空間與資源的預(yù)估和購買是相當(dāng)重要的，同時也能夠在云業(yè)務(wù)的上線之初和交付之后的一段時間內(nèi)，有效地杜絕潛在的中斷和性能瓶頸。當(dāng)然，我們也應(yīng)該與云服務(wù)商事先制定好按需訂閱或擴(kuò)容條款。如果購置的是IaaS的話，我們則可以在實(shí)際需求或業(yè)務(wù)模式發(fā)生變化時，及時地根據(jù)CMDB里的模板產(chǎn)生新出的虛擬機(jī)、動態(tài)地增配CPU和內(nèi)存的數(shù)量、以及臨時將某個host遷移到他處等。
2. 高可用性/連續(xù)性
憑借著虛擬化主機(jī)和網(wǎng)絡(luò)設(shè)備的鏡像和數(shù)量的優(yōu)勢，我們的云業(yè)務(wù)可以充分發(fā)揮其服務(wù)的自愈和擴(kuò)展能力，從而實(shí)現(xiàn)HA、業(yè)務(wù)連續(xù)性、和災(zāi)難恢復(fù)的效率。我們平時的各種重復(fù)單調(diào)的維護(hù)工作量也能相應(yīng)地大幅減少。當(dāng)然，對于那些和我們的系統(tǒng)有關(guān)，但由云服務(wù)商所負(fù)責(zé)的部分，我們不能只是被動地接受其例行的測試成功報(bào)告，而應(yīng)當(dāng)主動要求，真正地參到測試環(huán)節(jié)之中。
3. 事件/故障響應(yīng)
在云業(yè)務(wù)環(huán)境中，由于突破了以往的一套系統(tǒng)僅能提供單一服務(wù)的限制，所以造成了應(yīng)用種類、數(shù)據(jù)混雜、和設(shè)備資源相互交錯的狀態(tài)。我們所面對的早就不再是能否撲捉截取到事件發(fā)生的問題了，而是各種被自動采集的海量事件集中性地?fù)涿娑鴣?，所?dǎo)致的篩選、分析和去除誤報(bào)的局面。
具體來說，對于采用SaaS模式的企業(yè)，可能會更多地需要依賴云服務(wù)商的來采取各種的應(yīng)急響應(yīng)措施。而對于使用IaaS的企業(yè)，其IT部門則有能力和責(zé)任按照我們在《安全事件響應(yīng)之五步進(jìn)階》里提到的“識別和分類->調(diào)查和取證->抑制、根除和恢復(fù)”的流程進(jìn)行應(yīng)對。我們逆推著來看：
- 抑制是關(guān)鍵，我們可以通過暫停被攻破的虛機(jī)鏡像，隔離它與其他系統(tǒng)的邏輯聯(lián)系，從而既不會破壞它上面的證據(jù)，又能夠阻止形式的惡化。
- 我們曾經(jīng)在《安全入侵應(yīng)對實(shí)務(wù)—內(nèi)網(wǎng)偵查篇》中著重討論過“取證與調(diào)查”?，F(xiàn)如今，我們來到了云端，其取證的環(huán)境變得高度動態(tài)且不定，這就對我們?nèi)∽C的各種要素，包括確定范圍、收集方式、保留語義完整、和維持證據(jù)穩(wěn)定等都帶來了挑戰(zhàn)。與此同時，隱私也是不可忽略的要素，同樣需要服務(wù)商的合作與支持。
- 而在各種事件的識別和響應(yīng)上，我們需要考慮到由于業(yè)務(wù)系統(tǒng)不再孤立的存在于我們可控的環(huán)境中，所導(dǎo)致的那些針對云服務(wù)商的攻擊也可能會給咱們系統(tǒng)帶來的“殃及池魚”的影響。例如：針對您所在的云環(huán)境本身或是其它租戶的DDOS攻擊，就算并非是攻擊的目標(biāo)，您的業(yè)務(wù)可用性也會有所波及。因此我們同樣要做好信息的收集和事件的分析等工作。
可見，我們需要建立的是一套更全面和有互動性的日常管理流程，而非針對某個產(chǎn)品或項(xiàng)目的特定應(yīng)對模式。與此同時，我們可以采用當(dāng)前比較流行的大數(shù)據(jù)分析的一些工具，在實(shí)現(xiàn)快速綜合性的智能分析的前提下，獲取本企業(yè)不同應(yīng)用中的云業(yè)務(wù)的全網(wǎng)視圖，綜合分析各種安全狀況、安全事件和安全趨勢，做到防范于未然。
四、持續(xù)改進(jìn)vs. 彈性伸縮
1. 持續(xù)監(jiān)控
對于我們一般的企業(yè)而言，IT運(yùn)維部門做好對既有云業(yè)務(wù)的監(jiān)控與管理是很有必要的。監(jiān)控的重點(diǎn)應(yīng)當(dāng)放在三個方面：
- 云平臺對外或者對于內(nèi)部員工所提供的各種應(yīng)用服務(wù)的performance。
- 在服務(wù)使用的過程中所產(chǎn)生的流量和費(fèi)用等，也就是所謂的財(cái)務(wù)監(jiān)控。
- 根據(jù)預(yù)先定義的條件和閾值，實(shí)時進(jìn)行數(shù)據(jù)庫活動監(jiān)控(DAM)、策略違規(guī)監(jiān)控、和惡意使用于入侵的監(jiān)控與分析。
記?。罕O(jiān)控只是手段，不是目的。其真正目的就是要能夠?qū)崟r了解到使用的需求、消費(fèi)狀況、和安全的態(tài)勢，通過對現(xiàn)有云服務(wù)資源的彈性調(diào)整，從而改變以往對物理資源的死板預(yù)分配和對網(wǎng)絡(luò)帶寬的滯后的模式，形成正反饋。
2. 動態(tài)調(diào)整
技術(shù)和設(shè)施都在不斷迭代和進(jìn)步，因此我們可能會從整體性能以及運(yùn)營成本等多方面考慮是否需要對運(yùn)行了一段時間的云業(yè)務(wù)進(jìn)行整體或部分的遷移。遷移的前提條件是：要保證前后服務(wù)商所提供的云服務(wù)產(chǎn)品的互操作性和延續(xù)性。就像以往能夠在不同的硬件設(shè)備環(huán)境中部署系統(tǒng)那樣，我們要求企業(yè)云業(yè)務(wù)的各種組件也能夠被來自不同服務(wù)商的環(huán)境所替換，平滑地部署應(yīng)用，并能交換導(dǎo)出/導(dǎo)入，從而最終實(shí)現(xiàn)無縫遷移和持續(xù)運(yùn)營。
有過運(yùn)維經(jīng)驗(yàn)的小伙伴應(yīng)該知道，從遷移的難度上說，SaaS>PaaS>IaaS。而可能碰到的問題會包括：舊云平臺所用到的API、數(shù)據(jù)格式、標(biāo)準(zhǔn)和支持文檔、業(yè)務(wù)的定制部分的舊平臺依賴性和新平臺的不兼容性、以及業(yè)務(wù)的起/停順序和導(dǎo)致的中斷等問題。因此，我們運(yùn)維人員需要提前理解和做好數(shù)據(jù)備份、新應(yīng)用的部署、以及切換順序和詳盡的回滾方案。同時在遷移結(jié)束、配置信息調(diào)整以及測試完成之后，我們不可馬上與舊的云服務(wù)平臺拗?jǐn)?，因?yàn)楹芸赡苄枰屝屡f云業(yè)務(wù)并行地運(yùn)行一段時間。
3. 服務(wù)商管理
前面我們屢次提到如何與云服務(wù)商進(jìn)行各種協(xié)作。但是由于他們不再會來到我們的機(jī)房或辦公區(qū)，我們也不大可能常去他們的云服務(wù)機(jī)房，而且其提供的云服務(wù)也不再顯而易見，那么我們最終如何考量他們的服務(wù)級別的達(dá)標(biāo)情況呢?我們根據(jù)實(shí)踐經(jīng)驗(yàn)發(fā)現(xiàn)：只能通過設(shè)定好的報(bào)告模板和內(nèi)容項(xiàng)的格式，并審計(jì)和匯總其呈交的各類報(bào)告，來實(shí)現(xiàn)遠(yuǎn)程地協(xié)調(diào)與管理，從而在整體上改善和提高其服務(wù)的“信價(jià)比”。當(dāng)然，我們也可以將各個服務(wù)商予以“池化”，營造良性競爭的環(huán)境，對于無法通過自身改進(jìn)來提升服務(wù)種類和質(zhì)量的服務(wù)商，就只能讓他去領(lǐng)便當(dāng)了。
總的說來，在您的云業(yè)務(wù)中，如果云服務(wù)商所提供的“XX即服務(wù)”占比越多，您在治理控制方面的靈活性就越弱，他們的責(zé)任就越大;相反，倘若他們的占比越少，您的管控能力則越強(qiáng)，相應(yīng)的負(fù)責(zé)也就越大。因此，大家依據(jù)服務(wù)合同，不應(yīng)該“互相傷害”而是要“愉快地玩耍”。
小結(jié)
上面和大家聊了不少ITIL在云治理中的運(yùn)用和實(shí)踐?？梢奍TIL的服務(wù)管理“套路”還是能夠在企業(yè)新的云應(yīng)用場景中保持老當(dāng)益壯，煥發(fā)第二春的。而作為IT運(yùn)維的我們，工作內(nèi)容已經(jīng)從原來的單純技術(shù)，滋長成了“技術(shù)+管理+業(yè)務(wù)”。
有經(jīng)驗(yàn)的小伙伴也許有這樣的體會，根據(jù)各個企業(yè)的實(shí)際規(guī)模、需求狀況，以及云業(yè)務(wù)實(shí)現(xiàn)程度的不同，各類IT管理與運(yùn)維人員也有著細(xì)微的專注點(diǎn)。比如說：基礎(chǔ)日常運(yùn)維人員會更關(guān)注于IaaS，項(xiàng)目、部署人員則更關(guān)注于PaaS，而業(yè)務(wù)支持人員可能主要關(guān)注的是SaaS。但是，無論您在企業(yè)中是什么角色，關(guān)注哪一方面的云服務(wù)，我都希望您能夠運(yùn)用ITIL這把“洛陽鏟”繼續(xù)深耕云業(yè)務(wù)，解鎖出了更多的運(yùn)維和管理的新技能。
【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】
