金融企業(yè)云服務(wù)管理平臺架構(gòu)設(shè)計

1、 金融企業(yè)云服務(wù)管理平臺架構(gòu)設(shè)計 引語2018年正好是改革開放40周年，在改革開放之前，有個很好聽的名字“計劃經(jīng)濟”，統(tǒng)籌規(guī)劃國民經(jīng)濟，小到居民用的煤油火柴棒，大到國家大型水利樞紐工程、國防建設(shè)等，事無巨細，國家都統(tǒng)籌規(guī)劃著。隨著這個“解放思想，實事求是”的改革開放，政府部門開始轉(zhuǎn)變職能抓大放小，逐漸轉(zhuǎn)變成主導(dǎo)國計民生的大工程，其它都是民營經(jīng)濟補充、相輔相成，因此慢慢激活了市場經(jīng)濟，未來一定會以轉(zhuǎn)到服務(wù)民生為本，更豐富了居民百姓的方方面面何種組織能駕馭云服務(wù)管理平臺 企業(yè)IDC中的組織架構(gòu)剖析作為IT數(shù)據(jù)中心，IT資源粒度小管理，某種程度上真有點類似于改革開放前后的對比。數(shù)據(jù)中心一般都需要規(guī)劃

2、和管理（manage）數(shù)據(jù)中心IT資源（resources）方方面面。當云能統(tǒng)一維度IT資源時，于是就產(chǎn)生了如何規(guī)劃和管理這個資源粒度的問題，便有了各種精細化、精益化等各種高大上詞的管理平臺，毫無例外，都是從管理者（administrator）角度去考慮如何更精準管理、如何更便捷實用、操作好用地管理IT資源。因此如何找到周邊環(huán)境和定位關(guān)系，是云服務(wù)管理平臺生命力所在。 帶有自研團隊的大中型企業(yè)IDC比如借鑒中國人壽保險股份有限公司的組織架構(gòu)，可以清晰看到信息技術(shù)部、研發(fā)中心和數(shù)據(jù)中心，共同來維護業(yè)務(wù)運營中心，因此需要心云的運營和運維在數(shù)據(jù)中心就有運營場所，同時信息技術(shù)部對云技術(shù)選型、架構(gòu)評審等

3、進行協(xié)助，通過研發(fā)中心的技術(shù)投入，可以完成對云服務(wù)管理平臺的定制化落地，數(shù)據(jù)中心的這種運營機制、組織架構(gòu)及其運轉(zhuǎn)流程來適應(yīng)性開發(fā)實現(xiàn)云服務(wù)管理平臺落地。云服務(wù)管理平臺成功的關(guān)鍵因素找準周邊關(guān)系各種環(huán)境后，融合、集成、整合之類統(tǒng)一納管（cover）IT資源范圍（scope），也便有了不同類型IT資源管理工具（tool）鏈專業(yè)化平臺逐漸產(chǎn)生。即便如此，也還是需要逐步統(tǒng)一操作（operate）、統(tǒng)一流程（process）、統(tǒng)一門戶（portal）、統(tǒng)一開發(fā)（develop）及其框架（framework），統(tǒng)一各種引擎（engine），統(tǒng)一編排（orchestrate），最終自動化（automatic

4、）交付，而這些交付最終都期待以數(shù)字（data）化形式，通過面板（dashboard）展示（visible）。目標就是各種IT資源都以粒度交付，讓這些不看見粒度資源變成面板上的圖標和數(shù)字，讓人更有實體感。實質(zhì)感受還是從管理平臺到被管理環(huán)境進行控制管理。對于整個平臺首先要對數(shù)據(jù)中心的環(huán)境先適應(yīng)，即覆蓋環(huán)境的所占百分比，對于云服務(wù)管理平臺在整個數(shù)據(jù)中心的定位，即與數(shù)據(jù)中心周邊環(huán)境的進行交互的元素和接口，也需要梳理，并且建立協(xié)作機制和接口通信規(guī)范。針對接口規(guī)范需要采用統(tǒng)一的接口服務(wù)能力，比如當下采用API-gateway 來實現(xiàn)所有數(shù)據(jù)交互對外輸出服務(wù)，需要完成數(shù)據(jù)標準化、粒度化統(tǒng)一，如此既保證了平臺

5、本身的對外數(shù)據(jù)和服務(wù)輸出的穩(wěn)定性、安全性、標準化，也更易于推進自動化交付內(nèi)容。云服務(wù)管理平臺需求源云服務(wù)管理平臺的面向使用者范圍，就決定了需求源的范圍，根據(jù)這個范圍，需要規(guī)劃根據(jù)需求交付的服務(wù)目錄和服務(wù)內(nèi)容。這就是云服務(wù)管理平臺的生命力和交付內(nèi)容的管理生命周期。使用者定位使用者定位一直是所有產(chǎn)品都很難界定的事情。作為數(shù)據(jù)中心企業(yè)內(nèi)容服務(wù)平臺，在數(shù)據(jù)中心規(guī)模小的情況下，在成長過程中，通過平臺和系統(tǒng)可以使管理員釋放出更多的時間和精力來管理整個數(shù)據(jù)中心的交付和運營、運維，此時的云服務(wù)管理平臺是面向資源管理員的操作平臺。隨著時間的推移，當數(shù)據(jù)中心規(guī)模越來越大，同時業(yè)務(wù)也百花齊放，異彩紛呈，根據(jù)不同業(yè)務(wù)

6、，對數(shù)據(jù)中心的服務(wù)也要求形態(tài)各異，服務(wù)特殊的要求和標準與日俱增，此時需要的是通過平臺將這些資源粒度服務(wù)逐步釋放到業(yè)務(wù)應(yīng)用需求的手中，業(yè)務(wù)可以隨心所欲地在規(guī)定的場景下使用資源，大大釋放資源管理員的時間和精力，此時的云服務(wù)管理平臺是將數(shù)據(jù)中心資源作為商品服務(wù)，可以任由業(yè)務(wù)使用者進行搭配使用。云服務(wù)管理平臺體現(xiàn)的是自助服務(wù)和服務(wù)目錄所需要的服務(wù)開發(fā)核心能力。云服務(wù)管理平臺構(gòu)建面向用戶類型、覆蓋資源環(huán)境、數(shù)據(jù)粒度規(guī)范云服務(wù)管理平臺將數(shù)據(jù)中心的資源作為服務(wù)粒度統(tǒng)一交給平臺進行服務(wù)推廣，因此定義服務(wù)所覆蓋的內(nèi)容，內(nèi)容要素所構(gòu)建的資源粒度標準，就是云服務(wù)管理平臺在服務(wù)輸出過程中需要交互的數(shù)據(jù)粒度規(guī)范。而這些

7、數(shù)據(jù)粒度就是覆蓋資源環(huán)境的適應(yīng)性來體現(xiàn)，適應(yīng)性廣度越大、精細化越深，面向使用者交付內(nèi)容的深度也就越深，服務(wù)內(nèi)容開發(fā)要求也就越高，用戶使用起來也就越能體現(xiàn)專業(yè)化和服務(wù)化。面向使用者的統(tǒng)一門戶統(tǒng)一門戶是時下所有數(shù)據(jù)中心都必須面對的交付。首先需要用戶安全統(tǒng)一認證，用戶安全認證后，不同部門所在組織架構(gòu)中，面向不同用戶使用的資源范圍就不同，交付服務(wù)也就不同，當然根本還是用戶關(guān)注的內(nèi)容也不一樣。因此，統(tǒng)一門戶下，通過不同操作控制臺，完成資源或者業(yè)務(wù)應(yīng)用+資源的自動化交付，這是作為云服務(wù)管理平臺需要集中的功能交付，實現(xiàn)的內(nèi)容以場景化交付。當然這個過程必然會涉及到不同組織的審批流程、這個流程和業(yè)務(wù)及屬主的配置

8、管理庫（CMDB）及其關(guān)聯(lián)的資源關(guān)系。這些在日常中組成了ITIL模式下的變更管理及組織運作的流程審批環(huán)境。這些都需要通過梳理業(yè)務(wù)CMDB和資源關(guān)系，以保證業(yè)務(wù)和資源場景全鏈路數(shù)據(jù)閉環(huán)。云服務(wù)管理平臺規(guī)劃設(shè)計有了使用用戶的定位、鎖定了需求來源、限定了交付內(nèi)容，云服務(wù)管理平臺的架構(gòu)基本就以保障業(yè)務(wù)運行為中心任務(wù)進行規(guī)劃，其設(shè)計交付內(nèi)容就以滿足用戶使用為目的，構(gòu)建服務(wù)研發(fā)團隊，對服務(wù)內(nèi)容將數(shù)據(jù)中心資源進行服務(wù)化改造進行輸出。平臺規(guī)劃交付實現(xiàn)路線圖首要任務(wù)是數(shù)據(jù)中心將資源交付自動化能力輸出，釋放資源管理員時間和精力，轉(zhuǎn)而通過資源管理員日積月累的能力進行服務(wù)化改造，即將資源管理員的能力上升到服務(wù)目錄下的

9、服務(wù)內(nèi)容進行輸出。將這些服務(wù)內(nèi)容逐步優(yōu)化以提升用戶體驗，以迭代和持續(xù)改進的遞進方式不斷修復(fù)優(yōu)化整個云服務(wù)管理平臺。因此路線圖先以自動化為中心進行交付，然后逐步將自動化內(nèi)容按用戶進行服務(wù)化改造，當然這其中的數(shù)據(jù)粒度逐步改造是必不可少，也必須將這些數(shù)據(jù)分層次、優(yōu)先級進行持續(xù)實現(xiàn)。滿足內(nèi)容交付的技術(shù)選型和架構(gòu)選型探討對于技術(shù)實現(xiàn)，在當前大環(huán)境下，宜采用自主可控技術(shù)體系，即架構(gòu)安全、技術(shù)開放、高可用、高可靠、支持持續(xù)改進和服務(wù)化改造。數(shù)據(jù)中心的企業(yè)架構(gòu)，無論是技術(shù)底層和網(wǎng)絡(luò)環(huán)境都相對復(fù)雜，因此需要考慮架構(gòu)適應(yīng)數(shù)據(jù)中心環(huán)境，比如兩地三中心，基礎(chǔ)資源多個版本共存，用戶訪問安全、數(shù)據(jù)安全和易訪問性的沖突等。

10、總之，相對于云服務(wù)管理平臺來說，一般將資源放入管理方和被管理方，業(yè)務(wù)應(yīng)用運行環(huán)境放入被管理方，以IaaS、PaaS、SaaS 不同形態(tài)的服務(wù)輸出，平臺只是將這些服務(wù)進行組合編排提供給不同角色用戶進行使用。每一種用戶需要完成的服務(wù)流程大體一致，提出申請，經(jīng)過若干審批后獲取到所需要的資源服務(wù)，有的以 IaaS 資源，業(yè)務(wù)用戶自行定義和改造，自定義資源的使用內(nèi)容；有的以 PaaS資源，直接滲入業(yè)務(wù)應(yīng)用開發(fā)當中，減輕業(yè)務(wù)應(yīng)用開發(fā)對資源的維護需求；有的以 SaaS 服務(wù)進行輸出，將業(yè)務(wù)作為完整服務(wù)對外輸出。以上綜合的描述，大致可分為資源規(guī)劃方、資源管理者、資源需求方、資源使用方、資源操作維護方等。其實這

11、些都有相應(yīng)的組織部門去對應(yīng)，而且每個人對這些資源關(guān)注點都各有千秋，說到底就是各方都希望看到各自的資源全貌，每個人都期望看到自己關(guān)注的內(nèi)容。由此可見，數(shù)據(jù)中心IT資源管理需要滿足不同人不同的關(guān)注內(nèi)容，有的要求功能實現(xiàn)，有的要求數(shù)據(jù)按其關(guān)注點展示，有的要求流程連貫，有的要求統(tǒng)一門戶，有的要求操作便捷，而且安全也要統(tǒng)一認證，凡此種種，包羅萬象，都希望一個服務(wù)門戶就能涵蓋。這真有點像：百姓有問題就找政府、找警察，仿佛這兩者就能管理一切。這大概就有點類似當下云服務(wù)管理平臺的定位。云服務(wù)管理平臺交付實踐不同的技術(shù)選型、不同服務(wù)交付內(nèi)容、不同的面向用戶定義，完全有不同的云服務(wù)管理平臺身份，本次實踐是面向所有

12、業(yè)務(wù)用戶進行云服務(wù)管理平臺實踐。因此需要對資源交付到使用者相關(guān)的安全權(quán)限打通、設(shè)計防火墻、堡壘機等均要全鏈路閉環(huán)。當前實踐采用了基礎(chǔ)設(shè)施即代碼（Infrastructure as Code IaC）的理念進行云服務(wù)管理平臺技術(shù)架構(gòu)進行框架設(shè)計，圍繞自動化交付內(nèi)容進行對接集成，以業(yè)務(wù)用戶的視角進行服務(wù)化設(shè)計和實現(xiàn)，圍繞數(shù)據(jù)中心安全對業(yè)務(wù)運營進行安全保障的宗旨進行數(shù)據(jù)粒度交互全鏈路閉環(huán)。功能架構(gòu)上，可以通過將各資源管理平臺匯聚到云服務(wù)管理平臺，當然這其中需要做各種協(xié)調(diào)和妥協(xié)，畢竟不能作為專業(yè)化平臺操作使用，但是對于諸多普通用戶的操作使用，是完全可以的。因此功能架構(gòu)就要覆蓋資源范圍廣度和深度，要找到

13、足夠?qū)域?qū)動接口。從技術(shù)實現(xiàn)角度，目前很多采用openstack作為這一層的驅(qū)動層（軟件定義），當然也有自行研發(fā)或采用開源的諸如terraform 等對接各種資源，也可以自主開發(fā)納管資源模塊的接口驅(qū)動層。這一層一旦選定，基本上功能模塊、納管資源類型范圍基本上確定，也可以說是覆蓋數(shù)據(jù)中心資源的比例基本上確定。當然如果對接資源接口驅(qū)動層是開口，即可以由應(yīng)用自行開發(fā)對接插件（IaC基礎(chǔ)設(shè)施即代碼-plugin），隨著時間的推移和投入，覆蓋資源范圍和深度將逐步增加。數(shù)據(jù)架構(gòu)上，需要映射各種不同維度的數(shù)據(jù)，甚至強行將這些數(shù)據(jù)帶上屬主、屬組，之后同步入云服務(wù)管理平臺的數(shù)據(jù)層（或者統(tǒng)一數(shù)據(jù)層）進行角色和權(quán)限

14、加工，目的就是為了使用戶對數(shù)據(jù)的感受是自己在用自己的專屬數(shù)據(jù)，這部分數(shù)據(jù)梳理工作量和設(shè)計數(shù)據(jù)展示耗費諸多人力和時間，當然也要在數(shù)據(jù)層保留相當冗余量的數(shù)據(jù)，并隨時為用戶提出的需求而響應(yīng)并啟用這些數(shù)據(jù)。這部分數(shù)據(jù)來源主要可以分為兩類，一類是資源屬性相關(guān)及其操作過程附帶添加各種標簽，另一類便是純粹用于管理和安全考慮加上的關(guān)聯(lián)關(guān)系和識別標簽，這二類數(shù)據(jù)要相輔相成，實現(xiàn)用戶使用目的性和便捷性。從用戶角度，每位用戶都希望獨自擁有屬于自己的操作界面和數(shù)據(jù)，并且將相關(guān)聯(lián)的數(shù)據(jù)、權(quán)限、角色、資源等均屬于自己范圍內(nèi)的數(shù)據(jù)，在平臺的功能服務(wù)下，滿足用戶日常操作和控制管理，而并不期待從過多數(shù)據(jù)和過大范圍中尋找屬于自身

15、的內(nèi)容。因此不關(guān)注，更不期待這些不必要的內(nèi)容影響自己的日常使用。從管理者角度，任何 I T 資源都脫不開的一個命運，就是生?。ǔ鰡栴}或事故）和上手術(shù)臺（變更），任何些許的變動，都會影響到諸多使用方，因此如何評估資源變更帶給使用方影響，就需要各方管理者提供方便的查詢，或者反過來，資源管理者通知使用變更了，與使用方確認是否受影響。交付團隊角色定位及可持續(xù)優(yōu)化戰(zhàn)略實施云服務(wù)管理平臺交付團隊是連接業(yè)務(wù)用戶和資源管理員的中樞紐帶，對上（北向）業(yè)務(wù)應(yīng)用戶視角查看業(yè)務(wù)所需要資源支撐的種類、容量、運行效率，及其業(yè)務(wù)應(yīng)用涉及的所有資源維度數(shù)據(jù)及相關(guān)負責(zé)人信息進行展示、構(gòu)建及勘誤更新等?？紤]資源的服務(wù)交付逐步完善

16、，因此將安全、網(wǎng)絡(luò)、各式存儲、資產(chǎn)管理、用戶安全及相關(guān)PaaS服務(wù)、云桌面集中于統(tǒng)一門戶，并以服務(wù)目錄的方式進行可持續(xù)優(yōu)化升級和改造，不斷提升用戶體驗。平臺覆蓋環(huán)境及其數(shù)據(jù)粒度標準用戶服務(wù)全流程閉環(huán)，即要通過云服務(wù)管理平臺將資源數(shù)據(jù)粒度與業(yè)務(wù)用戶和管理資源屬性粒度保持關(guān)聯(lián)和一致性，這就需要一個強大的CMDB進行融合，沒有強大的CMDB將這些粒度數(shù)據(jù)進行關(guān)聯(lián)，難以將大相徑庭的兩者粒度數(shù)據(jù)進行全流程閉環(huán)。這個兩個維度的粒度數(shù)據(jù)的關(guān)聯(lián)是要將各自維度的數(shù)據(jù)進行模型化改造。自動化交付內(nèi)容和使用者需求的挑戰(zhàn)自動化交付是所有數(shù)據(jù)中心都夢寐以求的努力方向，但是自動化的深度是極其難以用數(shù)字化和用戶體驗來形容的。

17、諸如IaaS 服務(wù)，如果僅供給異構(gòu)虛擬化下的各種虛擬機，比較簡單；如果不同版本且異構(gòu)虛擬化就有點難度了；若按照業(yè)務(wù)應(yīng)用架構(gòu)進行編排后自動化交付資源架構(gòu)（同時通過自動化將所要基礎(chǔ)軟件也進行不同版本進行自動化交付），這其中的客戶化和自動化腳本編排和管理就變得異常復(fù)雜。那么如何在自動化交付和實現(xiàn)這些自動化所需要的開發(fā)間做一個平衡？不同的組織和不同業(yè)務(wù)需求有各自的需求，難以有一致的標準。因此云服務(wù)管理平臺對于不同組織，是有不同的交付內(nèi)容的，甚至可以說有些組織是難以駕馭這個地道的、以服務(wù)為中心的云服務(wù)管理平臺的。云服務(wù)管理平臺運營數(shù)據(jù)中心所有平臺最終多需要交付運營和運維，運維由開發(fā)團隊可持續(xù)維護并且迭代

18、升級，這是數(shù)據(jù)中心平臺的生產(chǎn)方式。使用者角色、權(quán)限和職責(zé)探討云服務(wù)管理平臺定位如果如前所述，那么云服務(wù)管理平臺的核心是什么？脫口而出的答案就是服務(wù)目錄，服務(wù)目錄背后就是各種專業(yè)平臺或者工具的能力，云服務(wù)管理平臺真的就是統(tǒng)一的入口且?guī)в袃?nèi)容（服務(wù)目錄）的門戶。云服務(wù)管理平臺的周邊環(huán)境可就復(fù)雜了，有要去對接的控制入口，有要驗證的各種服務(wù)，有要同步的各種數(shù)據(jù)，有要集成的專業(yè)化頁面或者功能模塊，有要能提供所有數(shù)據(jù)的對外服務(wù)接口，不同角色的人關(guān)注的內(nèi)容都得有，不過還有一個極其重要的、需要云服務(wù)管理平臺做的，就是將這些專業(yè)化平臺或工具所提供的數(shù)據(jù)進行分角色、分屬組、分權(quán)限去展示。這大概就是云服務(wù)管理平臺需

19、要大力做的內(nèi)容，可以說是核心，本質(zhì)是將這些各種渠道來的數(shù)據(jù)帶上屬主和屬組及其角色，再添加權(quán)限管理。平臺實現(xiàn)團隊與運營團隊關(guān)系運營團隊要為實現(xiàn)團隊提供運營過程種所產(chǎn)生的相關(guān)問題和用戶反饋，如果能提煉并且區(qū)分優(yōu)先級，平臺實現(xiàn)團隊與運營團隊就會是完美的結(jié)合，為云服務(wù)管理平臺的愿景提供更完善的服務(wù)。平臺分享粒度數(shù)據(jù)完整性、一致性和鮮活性的前提條件所有平臺的集成性都是以數(shù)據(jù)交互為媒介，實現(xiàn)數(shù)據(jù)完整性、一致性的服務(wù)傳遞，當然在平臺的每一個部分都有數(shù)據(jù)鮮活性的保證和前提條件輸入。自動化采集能力、日常操作的數(shù)據(jù)更新，是保證數(shù)據(jù)鮮活性的必備條件。平臺功能與粒度數(shù)據(jù)維護職責(zé)界限平臺功能不應(yīng)該以人工維護數(shù)據(jù)粒度和數(shù)

20、據(jù)準確性作為平臺的功能性存在，而應(yīng)該是關(guān)系映射、粒度模板標準化來推行數(shù)據(jù)完整性、一致性和鮮活性，數(shù)據(jù)屬性具備中子性，不以傳遞的變化為目的進行數(shù)據(jù)變更和切換，而應(yīng)該以關(guān)聯(lián)為依據(jù)做界限條件，如此能保證平臺與周邊系統(tǒng)完成數(shù)據(jù)交互集成。未來需要面向的開放問題所以云服務(wù)管理平臺面向誰使用，在IT數(shù)據(jù)中心中真的決定了該平臺的生命力。至于架構(gòu)、專業(yè)功能模塊、接口等，都需要滿足用戶的真實操作，因此需求多數(shù)以滿足實際用戶操作為要。云服務(wù)管理平臺門戶面向的用戶決定了功能和數(shù)據(jù)內(nèi)容，因此定制化開發(fā)等因素要與真實用戶操作需求相關(guān)聯(lián)，具體內(nèi)容應(yīng)用戶需求而關(guān)注。正因為如此難于將數(shù)據(jù)定出屬主、屬組和增添權(quán)限管理，因此很多把云服務(wù)管理平臺作為產(chǎn)品及服務(wù)