基于PaaS平臺(tái)的電信CRM系統(tǒng)開(kāi)發(fā)運(yùn)營(yíng)方案研究與實(shí)踐

王倩， 施志銘， 陳泳， 劉曉蓬, 代武成

(中國(guó)電信股份有限公司 上海分公司, 上海 200122)

0 引言

隨著云平臺(tái)的發(fā)展和PaaS平臺(tái)組件技術(shù)的逐漸成熟， PaaS平臺(tái)自身性能日益健壯、運(yùn)維體系比較合理，且有良好的彈性縮擴(kuò)容的工作機(jī)制。因此，越來(lái)越多的企業(yè)級(jí)互聯(lián)網(wǎng)應(yīng)用直接構(gòu)建在了PaaS平臺(tái)上。

這樣做的好處是各應(yīng)用系統(tǒng)不再需要過(guò)多關(guān)注分布式組件本身的工作原理和機(jī)制，包括分布式數(shù)據(jù)、分布式緩存、分布式消息中間件等，而是可以把更多精力投入到業(yè)務(wù)應(yīng)用本身的業(yè)務(wù)研發(fā)和運(yùn)營(yíng)推廣之上。

但有利也有弊，同時(shí)會(huì)使用應(yīng)用運(yùn)營(yíng)人員對(duì)分布式組件和平臺(tái)本身缺乏了解，導(dǎo)致過(guò)分相信平臺(tái)提供的性能保障而減少應(yīng)用本身的性能考慮和性能優(yōu)化的動(dòng)力，也會(huì)導(dǎo)致在出現(xiàn)故障時(shí)應(yīng)用側(cè)過(guò)多依賴平臺(tái)解決問(wèn)題或應(yīng)用與平臺(tái)之間出現(xiàn)維護(hù)職責(zé)的相互推諉。

如何充分利用平臺(tái)優(yōu)勢(shì)抓住機(jī)遇發(fā)展業(yè)務(wù)？又如何解決新型平臺(tái)架構(gòu)之下帶來(lái)的新問(wèn)題？

1 PaaS平臺(tái)對(duì)傳統(tǒng)應(yīng)用開(kāi)發(fā)及運(yùn)營(yíng)帶給的變化分析

1.1 舉一個(gè)可能的傳統(tǒng)的IT系統(tǒng)應(yīng)用開(kāi)發(fā)及運(yùn)營(yíng)的場(chǎng)景：

當(dāng)完成各種前置工作(如商務(wù)、技術(shù)招投標(biāo)、預(yù)算申請(qǐng)下達(dá)等)，進(jìn)行一個(gè)企業(yè)內(nèi)IT系統(tǒng)的實(shí)際開(kāi)發(fā)階段，大致需要以下步驟：

① 了解業(yè)務(wù)需求(盡量細(xì)致而明確);

② 根據(jù)需求確定應(yīng)用技術(shù)架構(gòu)和具體技術(shù)選型;

③ 申請(qǐng)開(kāi)發(fā)、測(cè)試及生產(chǎn)硬件環(huán)境資源;

④ 確立開(kāi)發(fā)團(tuán)隊(duì)和開(kāi)發(fā)流程;

⑤ 完成開(kāi)發(fā)并在測(cè)試環(huán)境中部署;

⑥ 內(nèi)部測(cè)試和業(yè)務(wù)測(cè)試;

⑦ 完成生產(chǎn)環(huán)境部署;

⑧ 業(yè)務(wù)正式上線運(yùn)營(yíng);

⑨ 發(fā)現(xiàn)問(wèn)題或產(chǎn)生新的需求;

⑩ 重復(fù)1、3、5、6、7、8、9的動(dòng)作(可能需求的變化導(dǎo)致技術(shù)選型需要進(jìn)行，或開(kāi)發(fā)團(tuán)隊(duì)結(jié)構(gòu)調(diào)整，則2、4的動(dòng)作也需要重復(fù))。

1.2 在PaaS平臺(tái)和新型開(kāi)發(fā)理念下應(yīng)用開(kāi)發(fā)及運(yùn)營(yíng)的場(chǎng)景

如圖1所示。

圖1 PaaS平臺(tái)與應(yīng)用、基礎(chǔ)設(shè)施的關(guān)系

前置工作完成后，在實(shí)際開(kāi)發(fā)階段步驟將有很大不同：

① 了解整體需求后直接進(jìn)行需求分解和開(kāi)發(fā)；

② 開(kāi)發(fā)測(cè)試和業(yè)務(wù)測(cè)試完成后上線部署

③ 業(yè)務(wù)正式運(yùn)營(yíng)；

④ 產(chǎn)品問(wèn)題或新需求后直接在分解后的任務(wù)項(xiàng)上改動(dòng)或快速迭代產(chǎn)生新的任務(wù)項(xiàng)后快速開(kāi)發(fā)部署(受技術(shù)選型和開(kāi)發(fā)團(tuán)隊(duì)結(jié)構(gòu)影響很小)。

1.3 傳統(tǒng)與新型IT開(kāi)發(fā)的變化分析

根據(jù)上述兩類開(kāi)發(fā)模式的步驟列舉，不難看出差別?；赑aaS的新型開(kāi)發(fā)理念下，開(kāi)發(fā)步驟變得不再像傳統(tǒng)意義上的開(kāi)發(fā)步驟那么冗長(zhǎng)、那么中規(guī)中矩。原因何在？

首先， PaaS平臺(tái)身處應(yīng)用層(SaaS)和基礎(chǔ)設(shè)施(IaaS)層之間，起到了緩沖、橋梁的作用(見(jiàn)圖1)時(shí)，由于PaaS可以事先根據(jù)應(yīng)用的近期、中期、遠(yuǎn)期規(guī)劃提前向基礎(chǔ)設(shè)施申請(qǐng)資源，保證提前量，再向應(yīng)用層提供封裝后的資源服務(wù)，使得原本應(yīng)用構(gòu)建的一個(gè)基礎(chǔ)步驟——硬件資源申請(qǐng)的過(guò)程變得不再繁瑣而苛刻。

第二，PaaS上提供的公共組件如分布式數(shù)據(jù)、緩存、消息中間件、應(yīng)用服務(wù)框架[1]都有一定之規(guī)，從根本上約束了應(yīng)用側(cè)的技術(shù)架構(gòu)和技術(shù)工具選型都在一個(gè)可控范圍內(nèi)，不允許應(yīng)用側(cè)天馬行空。這在一定意義上當(dāng)然也可以說(shuō)是限制了應(yīng)用的發(fā)揮，但在更多場(chǎng)景下，是提高了工作效率、減少了多應(yīng)用之間的技術(shù)壁壘。

第三、多數(shù)PaaS平臺(tái)還會(huì)對(duì)應(yīng)用部署有規(guī)范要求，例如采用容器技術(shù)，要求開(kāi)發(fā)的服務(wù)有一定限量，如，要求一個(gè)容器鏡像上部署不超過(guò)20個(gè)服務(wù)、對(duì)服務(wù)報(bào)文處理時(shí)延最大要求等，每一個(gè)容器鏡像所占用cpu、內(nèi)存都可以大致量化，這一舉措從根本上保障了資源使用可以真正切片，這一點(diǎn)與第一點(diǎn)基礎(chǔ)設(shè)施的申請(qǐng)息息相關(guān)。同時(shí)，也使得需求變化導(dǎo)致的服務(wù)增加、服務(wù)增加導(dǎo)致容器鏡像增加、容器鏡像增加導(dǎo)致資源動(dòng)態(tài)擴(kuò)容[2]，這一條連鎖反應(yīng)鏈變成順理成章。

第四、從軟的能力上看，畢竟PaaS所限定的主流應(yīng)用技術(shù)是大多數(shù)開(kāi)發(fā)人員的首選，因此當(dāng)需求的異常變化也好、運(yùn)營(yíng)正常迭代的需求變化也好，對(duì)開(kāi)發(fā)團(tuán)隊(duì)的技術(shù)要求是一致的，那么由于需求變化即使開(kāi)發(fā)團(tuán)隊(duì)人數(shù)不足或團(tuán)隊(duì)人員流失，也能較快的擴(kuò)充或重組團(tuán)隊(duì)，并很快地響應(yīng)需求。同時(shí)，并非必須但常常與PaaS同時(shí)出現(xiàn)的微服務(wù)開(kāi)發(fā)思路，也使得開(kāi)發(fā)人員可以通過(guò)數(shù)據(jù)和微服務(wù)拆分、容器化的部署，對(duì)已有應(yīng)用的數(shù)據(jù)結(jié)構(gòu)、程序代碼可以最大限度地保護(hù)。當(dāng)需求變更時(shí)，開(kāi)發(fā)人員需要做的經(jīng)常是加、減法，而不是數(shù)據(jù)結(jié)構(gòu)和代碼的重構(gòu)，這一點(diǎn)可以從根本上把開(kāi)發(fā)團(tuán)隊(duì)內(nèi)的溝通和知識(shí)經(jīng)驗(yàn)的傳遞的成本降低。當(dāng)然這里并不是說(shuō)溝通和知識(shí)傳遞不重要，而是從快速響應(yīng)需求、快速迭代的角度，可以最大限度地先快速開(kāi)發(fā)上線。

綜上，PaaS平臺(tái)和微服務(wù)技術(shù)已經(jīng)為開(kāi)發(fā)運(yùn)營(yíng)一體化提供了良好的土壤，如何實(shí)施？筆者認(rèn)為需要分兩部分。第一，是業(yè)務(wù)運(yùn)營(yíng)與開(kāi)發(fā)的一體化，這需要通過(guò)面向?qū)ο蟮乃枷牒头桨概c解決。第二，是開(kāi)發(fā)與系統(tǒng)運(yùn)營(yíng)的一體化，需要通過(guò)分層的思想去解決。接下來(lái)將重點(diǎn)闡述在上海電信CRM系統(tǒng)重構(gòu)過(guò)程中的這一解決方案。

2 PaaS平臺(tái)及微服務(wù)場(chǎng)景下通過(guò)面向?qū)ο蟮乃枷雽?shí)現(xiàn)業(yè)務(wù)運(yùn)營(yíng)與開(kāi)發(fā)一體化

根據(jù)上一節(jié)對(duì)傳統(tǒng)應(yīng)用和新型應(yīng)用的開(kāi)發(fā)運(yùn)營(yíng)的比較分析，我們可以看出，基于PaaS平臺(tái)及其延伸開(kāi)發(fā)理念的支撐下，對(duì)應(yīng)用側(cè)的業(yè)務(wù)研發(fā)、快速運(yùn)營(yíng)迭代而言，可以說(shuō)是一個(gè)前所未有的機(jī)遇。如何抓住機(jī)遇大力發(fā)展業(yè)務(wù)，如何把平臺(tái)帶來(lái)的優(yōu)勢(shì)發(fā)揮出來(lái)并揚(yáng)長(zhǎng)避短？這是目前面臨的一個(gè)課題。筆者認(rèn)為，需要分為兩個(gè)方面進(jìn)行破題：可持續(xù)的一體化的業(yè)務(wù)運(yùn)營(yíng)和分層級(jí)的系統(tǒng)運(yùn)營(yíng)，本節(jié)將重點(diǎn)闡述業(yè)務(wù)運(yùn)營(yíng)部分。系統(tǒng)運(yùn)營(yíng)部分將在下一節(jié)闡述。

2.1 何為可持續(xù)的業(yè)務(wù)運(yùn)營(yíng)？

有必要解釋一下本文對(duì)業(yè)務(wù)運(yùn)營(yíng)的定義：應(yīng)用系統(tǒng)上線后的一切由業(yè)務(wù)發(fā)起的變更和實(shí)施的全過(guò)程，稱之為業(yè)務(wù)運(yùn)營(yíng)。即，業(yè)務(wù)運(yùn)營(yíng)的出發(fā)點(diǎn)是為了將應(yīng)用系統(tǒng)發(fā)揚(yáng)光大、不斷地對(duì)內(nèi)擴(kuò)展功能、對(duì)外擴(kuò)大使用，不斷地制造需求、實(shí)現(xiàn)需求、吸引更多的用戶、提升用戶的體驗(yàn)。業(yè)務(wù)運(yùn)營(yíng)不僅僅強(qiáng)調(diào)業(yè)務(wù)發(fā)展本身，還強(qiáng)調(diào)可持續(xù)運(yùn)營(yíng)的理念。也就是說(shuō)業(yè)務(wù)方與開(kāi)發(fā)實(shí)現(xiàn)方本為一體，需求提出者就是需求實(shí)現(xiàn)者，是真正的DevOps的工作方法。

2.2 如何讓需求提出者去實(shí)現(xiàn)需求？

面向?qū)ο蟮暮诵睦砟钍菍?duì)事物從具體中進(jìn)行抽象，抽象的過(guò)程中要分析事物有哪些對(duì)象，對(duì)象有哪些特征(即屬性)，對(duì)象間、屬性間有那些關(guān)系，針對(duì)這些對(duì)象、屬性、關(guān)系可以有哪些操作，抽象結(jié)束后，一個(gè)事物的本質(zhì)就呈現(xiàn)出來(lái)了。再進(jìn)而分析這些對(duì)象的共同點(diǎn)，即，從對(duì)象引出類的概念，同類對(duì)象有相同的屬性、關(guān)系、操作。再進(jìn)而分析這些同類對(duì)象在相同部分中的些微不同點(diǎn)，即有了繼承和多態(tài)的概念，等等。如見(jiàn)圖2所示。

圖2 面向?qū)ο蟮氖挛锍橄蠓椒?/p>

由此而構(gòu)建了面向?qū)ο蟮耐暾碚擉w系。不論是面向?qū)ο蟮母黝惥幊陶Z(yǔ)言還是各類建模分析方法，都在這個(gè)理論體系之下。

對(duì)于需求提出者而言，往往苦于只會(huì)表達(dá)具體業(yè)務(wù)場(chǎng)景，不會(huì)抽象為事物本質(zhì)，使用面向?qū)ο蟮某橄蠓椒梢杂行У慕鉀Q這一問(wèn)題。以電信行業(yè)傳統(tǒng)的產(chǎn)品的CRM需求舉例，每一個(gè)產(chǎn)品可以理解為一個(gè)對(duì)象，例如傳統(tǒng)的直線電話、centrex、pbx、DID、公用電話都可以抽象為固定電話這個(gè)產(chǎn)品類，移動(dòng)電話也是一個(gè)類,寬帶也可以視作一個(gè)類。產(chǎn)品對(duì)象本身可以分層級(jí)，即子對(duì)象。例如，來(lái)電顯示，可以是固定電話的子對(duì)象，也可以是移動(dòng)電話的子對(duì)象。同一個(gè)子對(duì)象在不同的父對(duì)象下，操作可以不同。

例如，還是來(lái)電顯示這個(gè)產(chǎn)品，在固定電話這個(gè)父對(duì)象下，收費(fèi)操作可以是6元，而在移動(dòng)電話這個(gè)父對(duì)象下，收費(fèi)操作可以是10元。同理[3]，屬性也可以進(jìn)行抽象，例如，接入方式可以視作固定電話這個(gè)類的屬性，同時(shí)也可以作為寬帶這個(gè)類的屬性，而光纖接入、銅纜接入都可視作是屬性的具體取值。對(duì)于對(duì)象、屬性都可以定義相關(guān)的操作，例如剛剛談起的對(duì)象收費(fèi)是一種操作，改接入方式這個(gè)屬性也可以是一種操作。如圖3所示。

圖3 抽象后的CRM產(chǎn)品需求的業(yè)務(wù)模型

經(jīng)過(guò)抽象后的產(chǎn)品需求已經(jīng)可以直接轉(zhuǎn)化為系統(tǒng)的數(shù)據(jù)模型設(shè)計(jì)，如圖4所示。

同理，可以解決更為復(fù)雜的商品的業(yè)務(wù)模型設(shè)計(jì)。商品的抽象過(guò)程中發(fā)現(xiàn)，在商品對(duì)象、商品屬性、商品關(guān)系、商品的業(yè)務(wù)流程操作、商品的收費(fèi)操作都可以先繼承產(chǎn)品的內(nèi)容，再在商品的內(nèi)容上增加新的對(duì)象、屬性、關(guān)系、收費(fèi)。而產(chǎn)品本身并無(wú)渠道操作，這是需要商品本身獨(dú)有的操作。在服務(wù)事件操作上，商品先繼承產(chǎn)品操作然后再根據(jù)商品實(shí)例的特殊性對(duì)服務(wù)事件進(jìn)行覆蓋，即可以停止該服務(wù)事件操作，也可以用其他個(gè)性化的服務(wù)事件操作替代，實(shí)現(xiàn)對(duì)象內(nèi)操作的多態(tài)性。產(chǎn)品與商品業(yè)務(wù)模型的對(duì)比如下，如表1所示。

圖4 抽象后的CRM產(chǎn)品業(yè)務(wù)模型可直接轉(zhuǎn)為系統(tǒng)模型

表1 CRM產(chǎn)品與商品的業(yè)務(wù)模型對(duì)比

商品與產(chǎn)品之間的業(yè)務(wù)關(guān)系模型如圖5所示。

圖5 商品與產(chǎn)品的關(guān)系模型

而商品與商品之間的業(yè)務(wù)關(guān)系模型如圖6所示。

圖6 商品之間的關(guān)系模型

經(jīng)過(guò)此番業(yè)務(wù)抽象而形成商品業(yè)務(wù)模型，也同樣可以直接轉(zhuǎn)為數(shù)據(jù)模型，如圖7所示。

圖7 抽象后的CRM商品業(yè)務(wù)模型可直接轉(zhuǎn)為數(shù)據(jù)模型

綜上，業(yè)務(wù)運(yùn)營(yíng)人員通過(guò)面向?qū)ο蠓椒▽?duì)電信應(yīng)用系統(tǒng)例如CRM系統(tǒng)的需求進(jìn)行抽象，可以直接轉(zhuǎn)為數(shù)據(jù)模型。而開(kāi)發(fā)人員基于微服務(wù)設(shè)計(jì)理念，就可以將數(shù)據(jù)模型直接封裝為數(shù)據(jù)服務(wù)，進(jìn)而多個(gè)數(shù)據(jù)服務(wù)可以封裝在一個(gè)容器鏡像內(nèi)，實(shí)現(xiàn)對(duì)外提供服務(wù)。

以檢查商品之間的關(guān)系的對(duì)外查詢服務(wù)為例，可以直接根據(jù)數(shù)據(jù)模型來(lái)設(shè)計(jì)該服務(wù)的入?yún)⑷绫?所示。

表2 商品間關(guān)系的查詢服務(wù)入?yún)⒈?/p>

并直接通過(guò)數(shù)據(jù)模型設(shè)計(jì)該服務(wù)的出參如表3所示。

這樣，業(yè)務(wù)運(yùn)營(yíng)人員自然而言地參與到了系統(tǒng)開(kāi)發(fā)的過(guò)程中。在系統(tǒng)上線運(yùn)營(yíng)后，如果有需求變化，業(yè)務(wù)運(yùn)營(yíng)人員可以直接反應(yīng)到業(yè)務(wù)模型、數(shù)據(jù)模型的變化之中，開(kāi)發(fā)人員可以快速通過(guò)數(shù)據(jù)模型來(lái)更新對(duì)外服務(wù)并完成容器鏡像的部署。由此，基于PaaS平臺(tái)的高效率、可持續(xù)的開(kāi)發(fā)與業(yè)務(wù)運(yùn)營(yíng)一體化的工作就能得以有序開(kāi)展。

表3 商品間關(guān)系的查詢服務(wù)出參表

3 PaaS平臺(tái)+微服務(wù)場(chǎng)景下的通過(guò)分層思想實(shí)現(xiàn)開(kāi)發(fā)與系統(tǒng)運(yùn)營(yíng)一體化

上一節(jié)闡述了如何基于PaaS平臺(tái)和微服務(wù)來(lái)實(shí)現(xiàn)業(yè)務(wù)運(yùn)營(yíng)與開(kāi)發(fā)的面向?qū)ο蟮囊惑w化，本節(jié)來(lái)闡述開(kāi)發(fā)與系統(tǒng)運(yùn)營(yíng)的一體化。

系統(tǒng)運(yùn)營(yíng)與業(yè)務(wù)運(yùn)營(yíng)的差異在于，業(yè)務(wù)運(yùn)營(yíng)團(tuán)隊(duì)關(guān)注的是系統(tǒng)的功能豐富、應(yīng)用推廣、使用感知、快速實(shí)現(xiàn)，系統(tǒng)運(yùn)營(yíng)團(tuán)隊(duì)關(guān)注的是系統(tǒng)的運(yùn)行總體穩(wěn)定、風(fēng)險(xiǎn)可控制、手段可預(yù)設(shè)、故障可快速恢復(fù)。即，系統(tǒng)運(yùn)營(yíng)團(tuán)隊(duì)既要關(guān)注平臺(tái)穩(wěn)定性和應(yīng)用系統(tǒng)穩(wěn)定性，而在故障處理、日常巡檢等處理方面，更是需要分層級(jí)、自動(dòng)化地建立系統(tǒng)運(yùn)營(yíng)的工作機(jī)制。

3.1 基于PaaS平臺(tái)的電信業(yè)務(wù)場(chǎng)景微服務(wù)化示例

以電信的業(yè)務(wù)辦理為例，將一個(gè)典型的業(yè)務(wù)場(chǎng)景來(lái)拆分為微服務(wù)的調(diào)用關(guān)系如圖8所示[4]。

圖8 電信業(yè)務(wù)受理的微服務(wù)化示例

將原來(lái)的單體應(yīng)用微服務(wù)化的過(guò)程大致為：根據(jù)業(yè)務(wù)設(shè)計(jì)出的業(yè)務(wù)對(duì)象，轉(zhuǎn)為數(shù)據(jù)對(duì)象后，就可以針對(duì)客戶、產(chǎn)品、商品等產(chǎn)品對(duì)象，以及業(yè)務(wù)訂購(gòu)、算費(fèi)的對(duì)象上的操作提供原子級(jí)別的基礎(chǔ)數(shù)據(jù)服務(wù)，進(jìn)而組裝為分子級(jí)的業(yè)務(wù)共享服務(wù)，再進(jìn)行形成用戶定位、業(yè)務(wù)受理、費(fèi)用結(jié)算三個(gè)應(yīng)用模塊。

因此，如果從一個(gè)業(yè)務(wù)流程為視角，開(kāi)發(fā)人員將應(yīng)用模塊逐步拆分，那么調(diào)用鏈過(guò)程還算清晰，如圖9所示。

圖9 開(kāi)發(fā)視角的服務(wù)拆分過(guò)程

然而，如果從整個(gè)應(yīng)用系統(tǒng)、乃至整個(gè)平臺(tái)的西系統(tǒng)運(yùn)營(yíng)的角度，關(guān)系就復(fù)雜得多，可以說(shuō)已經(jīng)超出了人腦的掌控范圍，如圖10所示。

3.2 開(kāi)發(fā)與系統(tǒng)運(yùn)營(yíng)分層的幾大要素

因此，要進(jìn)行如此復(fù)雜的調(diào)用場(chǎng)景的系統(tǒng)運(yùn)營(yíng)，解決之道就是進(jìn)行分層。

分層的總體思路為：將系統(tǒng)監(jiān)控、異常告警、日常關(guān)鍵業(yè)務(wù)巡檢、故障處理和查證解決等系統(tǒng)運(yùn)營(yíng)的方方面面，都需要按平臺(tái)系統(tǒng)運(yùn)營(yíng)與應(yīng)用開(kāi)發(fā)加以區(qū)分，并分層級(jí)地部署。

在平臺(tái)的系統(tǒng)運(yùn)營(yíng)視角下，運(yùn)營(yíng)人員的關(guān)注界面應(yīng)該如下，包括平臺(tái)總體情況和各應(yīng)用調(diào)用鏈的總體情況和走勢(shì)，如圖11所示。

圖10 平臺(tái)運(yùn)營(yíng)視角的服務(wù)調(diào)用示意圖

而在應(yīng)用開(kāi)發(fā)視角下，開(kāi)發(fā)人員關(guān)注的調(diào)用鏈界面應(yīng)如下，更多地關(guān)注每個(gè)環(huán)節(jié)的具體日志、報(bào)錯(cuò)信息和上下游關(guān)系，如圖12所示。

圖12 應(yīng)用視角調(diào)用鏈關(guān)注界面

除了系統(tǒng)運(yùn)營(yíng)關(guān)注要點(diǎn)的分層，在人員組織上，也許進(jìn)行分層。基于PaaS平臺(tái)和微服務(wù)的場(chǎng)景，需要大致分為平臺(tái)、數(shù)據(jù)、應(yīng)用三個(gè)層級(jí)，而平臺(tái)內(nèi)還可分為一線、二線、高級(jí)等多個(gè)層級(jí)。如圖13所示。

圖13 系統(tǒng)運(yùn)營(yíng)的人員組織的分層結(jié)構(gòu)

3.3 應(yīng)用側(cè)與平臺(tái)側(cè)的系統(tǒng)運(yùn)營(yíng)分層與職責(zé)分工

根據(jù)PaaS平臺(tái)的應(yīng)用發(fā)布、日常運(yùn)營(yíng)、故障處理的特點(diǎn)，制定應(yīng)用側(cè)與平臺(tái)側(cè)的系統(tǒng)運(yùn)營(yíng)分層與職責(zé)分工如表4所示。據(jù)此來(lái)實(shí)現(xiàn)應(yīng)用與系統(tǒng)運(yùn)營(yíng)的協(xié)調(diào)聯(lián)動(dòng)和應(yīng)急處置方案。

表4 應(yīng)用側(cè)與平臺(tái)側(cè)的系統(tǒng)運(yùn)營(yíng)分層和職責(zé)分工

利用面向?qū)ο蠛头謱铀枷雽?shí)現(xiàn)基于PaaS平臺(tái)的電信CRM系統(tǒng)開(kāi)發(fā)運(yùn)營(yíng)方案的研究與實(shí)踐

工作項(xiàng)應(yīng)用側(cè)的系統(tǒng)運(yùn)營(yíng)平臺(tái)側(cè)的系統(tǒng)運(yùn)營(yíng)日常運(yùn)輸每日巡檢內(nèi)容:1、關(guān)鍵日志:通過(guò)平臺(tái)提供的日志查詢界面2、微服務(wù)詞用鏈:通過(guò)平臺(tái)提供的pinpoint調(diào)用鏈界面3、接口:通過(guò)pinpoint可以查詢到接口的失敗率、時(shí)延4、隊(duì)列深度:通過(guò)平臺(tái)監(jiān)控界面可以查看及要求告警推送。5、接口性能監(jiān)控6、主動(dòng)探測(cè)的配置和告警7、調(diào)用鏈各環(huán)節(jié)日志分析8、服務(wù)調(diào)用的報(bào)錯(cuò)處理9、服務(wù)性能優(yōu)化日常監(jiān)控與巡檢、包括平臺(tái)組件健康度、平臺(tái)組件負(fù)載情況、平臺(tái)集群可用性、以及基礎(chǔ)設(shè)施、大數(shù)據(jù)等配套資源可用性等;平臺(tái)組件賬號(hào)管理應(yīng)用統(tǒng)一發(fā)布平臺(tái)故障應(yīng)急響應(yīng)與一般性故障處理平臺(tái)常規(guī)資源的分配與變更配套資源申請(qǐng)平臺(tái)構(gòu)建、包括集群部署、集群擴(kuò)容、組件升級(jí)等平臺(tái)組件巡檢質(zhì)量管控平臺(tái)組件負(fù)載趨勢(shì)分析與資源回收平臺(tái)數(shù)據(jù)備份與清理平臺(tái)安全管理、包括安全掃描、安全整改、周期性應(yīng)急演練平臺(tái)高級(jí)資源的分配與變更、包括SDK框架批量調(diào)整配置、分布式數(shù)據(jù)庫(kù)對(duì)象變更等故障處理處理流程:現(xiàn)象分析-故障初判(在用戶的第一接觸界面)-影響范圍分析-故障定位-故障應(yīng)急預(yù)案-故障驗(yàn)證-故障分析報(bào)告應(yīng)急預(yù)案(服務(wù)重啟、版本回遇、灰度、資源擴(kuò)容、TcpSQL的發(fā)現(xiàn)和分析、預(yù)賣演練等)的策略由應(yīng)用與平臺(tái)共同制定、實(shí)際操作可以根據(jù)場(chǎng)景進(jìn)行分工。故障升級(jí)與協(xié)調(diào)平臺(tái)組件疑難故障處理平臺(tái)故障與組件BUG踴躍管理平臺(tái)組件性能調(diào)優(yōu)運(yùn)維方案各中心制定中心運(yùn)維方案(監(jiān)控需求、告警需求、運(yùn)維流量、運(yùn)維責(zé)任人、故障分析流租、制定應(yīng)急預(yù)案等),由平臺(tái)配合。平臺(tái)規(guī)劃平臺(tái)運(yùn)維流程、規(guī)范、操作手冊(cè)的編制平臺(tái)組件功能需求管理、由應(yīng)用側(cè)配合。配套工作跨應(yīng)用的故障協(xié)助查證、接口類故障協(xié)助查證、中心間故障協(xié)同查證等配合應(yīng)用側(cè)查證

4 總結(jié)

PaaS平臺(tái)和微服務(wù)技術(shù)相對(duì)于傳統(tǒng)的IT系統(tǒng)平臺(tái)而言，給應(yīng)用開(kāi)發(fā)帶來(lái)的優(yōu)勢(shì)明顯，但問(wèn)題和挑戰(zhàn)也很多。文中提出的面向?qū)ο蠓椒▉?lái)實(shí)現(xiàn)業(yè)務(wù)運(yùn)營(yíng)與開(kāi)發(fā)的一體化、可持續(xù)化，以及開(kāi)發(fā)與系統(tǒng)運(yùn)營(yíng)的分層的思想和方案，可以最大限度地解決這些問(wèn)題和挑戰(zhàn)，并且已經(jīng)在上海電信的CRM系統(tǒng)重構(gòu)中的得到了驗(yàn)證。然而，在PaaS平臺(tái)和微服務(wù)的新環(huán)境下，作為電信運(yùn)營(yíng)商需要改變工作思路，從搭平臺(tái)、搭硬件、搭管道，轉(zhuǎn)向業(yè)務(wù)運(yùn)營(yíng)、系統(tǒng)運(yùn)營(yíng)、用戶運(yùn)營(yíng)，這樣才能揚(yáng)其長(zhǎng)、避其短，充分將PaaS平臺(tái)及微服務(wù)等技術(shù)效果發(fā)揮到極致，這對(duì)每一個(gè)電信BOSS系統(tǒng)從業(yè)人員而言，還任重道遠(yuǎn)，需要不斷積極探索新的方案并加以實(shí)踐，在實(shí)踐中積累更豐富的經(jīng)驗(yàn)。