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