《企業IT架構轉型之道》讀書筆記

 

1 出發點：企業IT系統建設普遍面臨的問題和處境 

很多企業面臨的問題和處境：

『煙囪式』系統建設模式。

當業務部門提出業務需求，信息中心部門進行系統集成商的招投標，再進入到需求收集、需求分析、開發、測試、上線的項目周期中。某種程度上，每個新系統的上線都預示着一座新的煙囪矗立而成。這種完全基於業務需求建設系統的方式，已經成為過去20多年企業建設IT系統的標准流程，導致IT系統建設早的企業內部系統煙囪林立。這正是今天很多企業面臨互聯網轉型難的根結所在。

它帶來三大弊端：

• 重復功能建設和維護帶來的重復投資。因為大量的功能和業務在多個系統中同時存在，單單從開發和運維兩個方面成本投入的角度，對於企業來說就是一種很顯性的成本和資源浪費。

• 打通『煙囪式』系統間的集成和協作成本高昂。業界早前就提出了SOA的理念，多家廠商推出了ESB產品及解決方案，重點就是來解決此類異構系統之間的交互問題。

• 不利於業務的沉淀和持續發展。在傳統IT系統建設模式下，上線的系統就進入了系統維護期，這個時間段實際上是系統對業務需求響應非常不敏感的階段，一般半年或一年才會進行一次系統的升級。也就是說，系統業務需求響應的能力和企業本身業務發展對系統建設的要求不成比例。如果說過去，業務需求的增長態勢還算比較平滑，沒有體現出系統的響應能力有多大差距，那么在今天，互聯網時代業務需求的增長越來越迅猛，原有系統對業務響應的能力就顯得更加捉襟見肘了。

 

 

企業信息中心的組織職能只停留在『業務支持』上 

各個企業都認可信息技術部門對於企業發展的重要地位，但是，該部門往往不具有與核心部門同等的部門話語權。該問題的核心是，IT信息部門在現有模式下已經被更高的領導層定位成了業務支持部門，是一個花錢的成本中心。 

作者認為，造成這種困境的原因是因為IT信息部門的人員不懂業務。作者所說的『懂業務』是指能對業務的下一步發展有着自己的理解和看法，對業務流程如何進一步優化能更好地提升業務，甚至對企業現有的業務提出創新的想法，為企業帶來新的業務增長點。 

而其根本原因，是因為很多大型企業的IT信息化部門已經存在了20多年，一成不變的就是項目制的系統建設模式，這樣建設項目的模式除了帶來『煙囪式』建設的一系列弊端，同時使得IT信息化部門一直處於『業務支持』的職能位置，即只為了滿足業務部門需求而進行IT系統建設的實施和運維部門。這種模式下， 很多企業的IT信息化部門的員工大多數的工作內容都是項目管理。當一個項目順利上線驗收后，這些員工開始投入到下一個項目的工作中。因此，其結果是，員工增長了項目經驗，但並不能在某一專業領域得到了知識和經驗的沉淀，其最終結果是IT信息中心的員工很多少能在一個業務領域做足夠深入的了解和業務沉淀。 

這些問題是如今大多數企業都遇到的問題，阿里巴巴在2008年業務系統的建設模式、組織架構以及遇到的問題，都和大多數企業是一樣的。 

2 解決之道：共享式業務中台 

阿里巴巴電商系統的架構經歷了煙囪式架構，到分布式架構，再到共享式架構的轉變。 

當前的阿里巴巴『厚平台，薄應用』架構形態如下圖所示。目前阿里巴巴集團前端超過了25個業務單元，比如淘寶天貓聚划算等，均不是獨立地構建在阿里雲的雲平台之上。在后端阿里雲技術平台和前端業務之間有了一個『共享業務事業部』，將阿里巴巴集團前端業務中公共、通用的業務沉淀到了這個事業部，包含額用戶中心、商品中心、交易中心、評價等十幾個中心。共享業務事業部正是『厚平台』的真實體現，為阿里巴巴各種前端業務提供着相應服務中心領域內最為專業、穩定的業務服務。 

 

 

3 價值：擺脫『煙囪式』系統建設帶來的各種困境 

共享服務架構的建設，使得阿里巴巴擺脫了因為『煙囪式』系統建設方式帶來的各種問題，最終成為阿里巴巴業務中台戰略的核心組成。 

1. 回歸 SOA 的本質 - 服務重用 

作者非常認可SOA的理念，但是SOA在落地時候變了味。具體表現在：

• SOA 在企業落地時，無一例外都是通過ESB（企業服務總線），使各個系統以服務封裝或服務調用方式實現了不同系統見的業務交互。其本質上，僅僅是采用了服務的形態，以技術的視角選擇了一個科學的方式實現了系統互聯。

• 這對於企業中業務服務的持續發展和沉淀沒有任何幫助，根本就沒有實現SOA理念最核心的架構：松耦合的服務帶來業務的復用，通過服務的編排助力業務的快速響應和創新。

• SOA 理念的提出，原本是真正為企業的IT系統建設指出一條光明大道，真正提現SOA核心價值的正是這些服務，只有這些服務在業務發展過程中得到持續的演進、功能逐步完善和增強，最終變為企業在該領域最為專業的IT資產時，才能真正打到SOA中所描述的業務的快速響應，更好地支持業務創新。但實際上，SOA的項目都淪為了實現多個系統之間的集成。

 而阿里巴巴已經將集團20多個核心業務中的公共的、通用的業務以服務的形式沉淀到了共享業務事業部。整個集團的核心業務能力均建立在這樣一套共享服務體系之上，使得SOA架構的核心價值 - 服務用重用 得以實現和發揮。

 

 

 

2. 服務被業務不斷滋養 

要解決的問題：『煙囪式』系統方式以及SOA『項目制』的建設方式，導致了業務得不到沉淀和持續發展，從而造成服務不能真正成為可重用的組件，為業務的快速響應、支持業務快速創新帶來業務價值。 

原因：SOA項目是一種集成項目建設的方式，就很容易造成服務提供者面對業務提出更多要求時，考核指標、工作回報都不能得到很好提現，服務提供者主觀上沒有太大的積極性來滿足新的業務需求；再加上如果當初服務設計的功能擴展性和業務前瞻性不足，導致有心無力滿足新的需求，結果是這些服務無法再進行功能擴展，成為企業『業務穩定』運行的『服務』。 

結果：如果一個服務一味追求功能的不變，一定程度上就是固步自封，這樣的做法是在逼着其它系統去建設同樣的輪子。當越來越多的系統都建設自己輪子的時候，之前的服務就慢慢少有人問津，它就會逐步退出歷史舞台了。 

解決之道：服務不需要『業務穩定』，而是需要不停的滋養。只有在滋養中才能從最初僅提供單薄業務功能的服務，逐步成長為企業最寶貴的IT資產，而服務所需的滋養正式來自新的業務不斷進行服務的接入。 

做法：阿里巴巴共享事業部的『服務』『滋養』『穩定』這三大價值定位，定義了共享服務的真諦。服務能力的沉淀和體現的業務價值是完全成正比的，需要一個長期、持續的過程。企業不能再走入『項目制』實施SOA項目的誤區，而是需要更多一些耐心，在接下來的業務發展過程中打造這些服務。這就要求新的業務必須接入這些已經產生的服務，為這些服務能夠變得更加專業和穩定帶來急需的需求養分。 

 

 

3 共享服務體系是創新的土壤，業務中台賦予業務快速創新和試錯能力 

需求：今天所有的企業，應該在互聯網時代具備一種跟互聯網公司一樣的業務快速創新，甚至是試錯的能力。 

問題：傳統企業中，一定是需要申報預算和立項來落實業務創新的想法，傳統『煙囪式』的系統建設方式對項目投入的資金和資源自然不會少。在申請大量資金而且項目還有失敗的可能性的情況下，有業務創新想法的人在考慮到失敗帶來的影響時，一定會權衡其中的利弊，大多數人會選擇退縮。 

解決之道：利用業務中台為業務創新提供一個堅實的中台。通過中台資源的優勢，支撐業務的快速創新和業務試錯。有了業務中台后，利用原本就建設好了的專業服務，使得企業在投入少的情況，快速收獲了更多的結果。 

4 為真正發揮大數據威力做好儲備 

需求：大數據會是展現企業核心競爭力並發掘新的商業模式的推動器。 

問題：很多企業的大數據項目並未帶來期望的成效，因為有以下兩個主要問題：

• 數據分布廣、格式不統一、不標准。這還得歸咎於『煙囪式』系統建設方式，使得相關業務領域的數據分布在不同的系統中。這位大數據平台項目初期數據的抽取和同步帶來了很多的復雜工作。

• 缺少具有能基於數據進行業務建模的專家。大數據平台的威力，要有人知道怎么利用它來發揮出真正的業務價值，這是很多大數據平台難於落地或真正讓企業感受到器價值的最大障礙。 

解決之道：共享服務體系是解決這兩大問題的不二法門。

• 一方面，通過業務中台，在各相關領域在業務和數據層做了很好的融合。

• 另一方面，共享服務體系能幫助企業信息部門培育出懂業務的專家，這些人有技術功底，隨着業務能力提升，他們能成為能發揮大數據平台價值的『數據科學家』。 

5 改變組織陣型會帶來組織效能的提升

問題：大多數企業的信息中心部門的職能還停留在『業務支持』的程度，是為企業的業務部門提供IT系統支持的組織。 

解決之道：有了業務中台，整個共享服務體系中的這些服務中心進行持續的『運營』的職能勢必會落在企業信息中心這個部門。這時，可以將信息中心部門的員工按照服務中心的方式進行人員組織的重新編排，讓員工在各自擅長和感興趣的業務領域持續發展。 

結果：讓信息中心部門從之前在企業中『業務支持』的組織職能，轉變為基於企業核心業務和數據進行運營的團隊，逐步培養出企業最稀缺的『既精通業務，又熟悉技術』的復合型人才。 

 

 

4 建設：分布式框架選擇 

2007年，淘寶已經擁有超過500人的技術團隊規模，整個淘寶網站是一個幾百兆字節的WAR包，大小功能模塊超過200個。

這帶來了以下幾個問題：

• 項目團隊間協同成本高，業務響應越來越慢。

• 應用復雜度已超出人的認知。

• 錯誤難於隔離。

• 數據庫連接能力很難擴展。

• 應用擴展成本高。 

解決以上問題的根本在於業務的拆分。結果，在應用部署形態上，由之前一個幾百兆字節大小的WAR包部署模式改造成為上百個WAR包獨立部署的服務化架構。

好處：

• 降低不同模塊開發團隊間的協同成本，業務響應更加迅速。

• 大大降低系統間的耦合度以及整體復雜度，各個開發團隊可專注與各自的業務模塊。

• 避免了個別模塊的錯誤給整體帶來影響。

• 業務拆分后解放了對單數據庫集群連接數的能力依賴。每一個核心服務中心都擁有各自獨立的數據庫，緩解了之前的數據庫連接瓶頸。

• 做到針對性的業務能力擴容，減少不必要的資源浪費。 

技術選型：SOA ESB 架構還是分布式架構？ 

SOA 主要特征：

• 面向服務的分布式計算

• 服務間松散耦合

• 支持服務的組裝

• 服務注冊和自動發現

• 以服務契約方式定義服務交互方式 

傳統SOA ESB的服務調用方式的問題：

1. 每一次服務的調用者要向服務提供者進行服務交互請求時都必須通過中心的ESB來進行路由。

2. 從邏輯上看，所有服務調用都通過服務總線，服務總線的訪問和計算壓力會非常大。

3. 企業所有的業務都通過服務總線方式，則服務調用量比較大，所需的網絡帶寬要求非常高，企業需要在網絡上投入更大的成本。

4. 基於企業總線構建的服務體系，會成為企業服務調度的核心樞紐，這可能會導致『雪崩』效應，給整個平台帶來災難性后果。 

阿里巴巴分布式服務框架 HSF：

 

主要組件：

• 服務提供者。為了保障服務高可用，一般都是集群部署。每個HSF應用均是以War包的形式存在，運行在Tomcat容器中。在Tomcat 容器層，已經集成了HSF服務框架對服務提供者或服務調用者進行配置服務器發現、服務注冊、訂閱、失敗轉移等功能。目前，淘寶內部大部分應用的部署方式，還是一個虛擬機運行一個tomcat容器，每個tomcat運行一個服務應用。

• 服務調用者。這是服務的消費者，大多數也是以WAR應用包的方式運行在 tomcat 容器中。

• 地址服務器。由 Nginix 實現。

• 配置服務器。負責記錄所有服務發布和服務訂閱信息，並將服務相關信息推送到服務節點上。

• Diamond 服務器。本質上也是一個通用的統一配置管理服務。

 

5 建設：共享服務中心建設原則

關於『服務中心』的概念：

• 服務中心一定是不斷發展的。業務架構是能反應業務變化的，服務中心作為共享架構的核心元素一定也會提現出這種變化。

• 服務中心的服務形態的多樣性。有人理解的服務中心是狹義的接口服務，這比較片面化，雖然接口是服務最重要的形式。服務中心提供的服務能力，可以分為三類：

• 依賴於接口的服務

• 依賴於工具的服務

• 依賴於數據的服務 

服務中心設計的一些原則：

• 高內聚、低耦合。

• 數據完整性原則。

• 業務可運營行原則。服務中心應該是承載業務邏輯、沉淀業務數據、產生業務價值的業務單元。

• 漸進性的建設原則。服務化架構本來就是一種敏捷的實踐，推薦小步快跑的方式逐步推進。 

6 實現：數據拆分實現數據庫線性能力擴展 

需求：

服務中心需要能很好地支撐將來任何業務場景的訪問性能的要求，而數據庫是最容易產生性能瓶頸的服務組件。 

幾個步驟：

淘寶的做法是基於數據庫分庫分表的方式，利用分布式數據庫平台解決數據庫瓶頸問題。

第一步：數據庫的讀寫分離。拓展了數據庫讀讀的處理能力，整體上也提高了數據庫的讀寫能力，但這樣的架構在主數據庫上的寫能力依然沒法擴展。

 

 

 

第二步：當出現單個表的數據量很大的情況，則需要采用水平分區的方式對數據進行拆分，即將同一個表中的不同數據拆分到不同的數據庫中。比如，對用戶數據按照用戶 ID 進行 has 取模的方式實現用戶數據平均分到 8個數據庫中，確保了單個數據庫中保存的數據量在單機數據庫能提供良好讀寫性能的范圍內。

 

第三步：在2008年，阿里巴巴內部開始了分布式數據庫的研發。 

一些最佳實踐：

• 開發了分布式數據層框架TDDL。針對分庫分表場景，提供了對各種業務場景的支持更加完善，開發人員體驗更加友好，管控能力大幅提升。

• 數據盡可能平均拆分。在分庫分表場景下，最重要的一個原則就是被拆分的數據盡可能的平均拆分到后端的數據庫中。如果拆分不平均，還會產生數據訪問熱點，這就同樣存在熱點數據因為增長過快而面臨數據單表數據過大的問題。

• 盡量減少事務邊界。

• 異構索引表盡量降低全表掃描概率。一個解決思路是『拿空間換時間』。

• 將多條件頻繁查詢引入搜索引擎平台。

• 簡單就是美。 

7 實現：使用異步化與緩存

業務流程異步化 

問題：淘寶的訂單創建流程需要調用超過200個服務。如果是全線性調用，即使每個服務的響應時間都在20ms之內，那么全部流程也會超過4秒。這對客戶來說難以接受。 

解決之道：流程異步化。

 

總結：在分布式服務架構中，通過業務流程異步化，即通過服務異步調用的方式讓業務流程中業務邏輯上允許同步執行的服務同時被調用，從而解決了大量遠程服務線性調用帶來的性能問題。 

2 大促秒殺活動催生緩存技術的高度使用

需求：平台如何完美支持大促秒殺場景是一個體系工作，牽涉到應用架構設計的合理、平台穩定性報障、極強的系統擴展能力等多個方面。其中，利用緩存技術實現商品數據的高性能讀取，以滿足秒殺活動中對商品數據訪問的同時不會出現商品超賣等嚴重的業務問題。下圖是商品秒殺架構示意圖：

 

 

 

示例：在小庫存商品秒殺場景下的示例：

 

流程：

• 1.1：用戶通過商品詳情頁查看商品時，獲取的商品基本信息以及庫存是從緩存Tair 中獲取的。

• 2.1：當用戶查看到當前商品還有可賣庫存時，進入到 Buy 商品下單界面，此時商品的相關信息依然還是從緩存獲取。

• 3.1： 用戶在進行下單操作后，此時就通過數據庫本機事務操作的方式，通過商品中心的服務（IC）獲取到當前商品的真實庫存信息。

• 3.2： 當此時獲取的庫存大於 0 時，則進行庫存的扣減操作。

• 3.3： 通過該步驟更新了商品數據庫中的庫存信息

• 3.4： 在3.3 步驟的同時，也更新緩存中該商品的庫存信息。此時，前方用戶再訪問該商品信息時，看到的就是已經更新了的信息。

7 服務治理：通過鷹眼平台跟蹤服務調用鏈

業務服務化帶來的問題：

分布式服務體系建設后，整個淘寶平台變成了一個復雜無比的服務交互鏈路網。這會帶來很多問題，比如：

• 如何對每天發生的幾千億次服務調用出現報錯時快速定位問題。

• 如何實時監控到服務的運行狀態是否正常。

• 如何給運營團隊關注的業務指標提供實施呈現以便他們進行實時的精准營銷。 

解決之道：

• 對於分布式服務調用跟蹤方面的需要，阿里打造了針對分布式服務調用鏈的跟蹤平台 - 鷹眼。它通過一套分布式日志平台實現對服務調用鏈路的跟蹤，基於阿里巴巴海量日志分布式處理平台 TLog。

• 它是JStorm 流式計算引擎，對應用集群接收到的日志進行內容的解析拆分，按照不同業務場景的需求將拆分后的數據保存到不同的存儲系統中。

• 其原理是通過服務調用鏈各服務處理節點生成相應的日志信息，通過同一請求中生成的日志具有同一個ID將不同系統或服務孤立的日志串在一起，重組還原出更多有價值的信息。

  

 

價值：

• 服務實時監控。通過在應用的不同層次進行埋點日志的打印，鷹眼平台可以實現從應用入口、服務層、服務方法層的精細管控。結合監控報警能力，鷹眼可以實現異常報警。

• 服務調用鏈跟蹤：鷹眼可以幫助運維人員在Web界面上清晰還原出每一次業務請求所產生的服務鏈調用情況。該功能着重於對業務鏈路數據的實時監控。這既能幫助快速定位問題，還能對應用的優化分析帶來幫助。正是有了調用鏈跟蹤功能，阿里巴巴的服務化平台從一個無服務管控狀態變成為一個具備真正可管可控的狀態，形成了完善的服務化管控體系。

• 服務調用鏈分析。這是針對業務架構訴求的服務調用鏈分析功能，讓業務架構師對於自己設計的業務鏈路在實際生產中的運行狀況有一個直觀的了解。該功能着重於對服務調用數據按照不同維度進行離線的統計和分析。利用分析出的數據，可以更針對性地優化業務鏈路流程，或提升某些服務的服務質量，給用戶提供更好的用戶體驗。

• 業務全息排查：這本質上是將服務鏈路信息與業務事件進行了集成，將業務事件通過服務調用鏈的 traceID&rcpID 進行雙向關聯。

• 業務實時監控：將發生的業務指標變化在秒級就體現在業務大屏上。有了這樣的業務實時大屏，給市場運營人員提供有價值的參考數據，真正對企業的運營提供了精准有效的數據支持。 

8 服務治理：通過多種措施保證平台穩定性

1. 限流與降級：

• 阿里巴巴的 Sentinel 平台提供了限流和降級功能。它為整個服務化體系的穩定運行行使着警戒任務，是對資源調用的控制平台，主要涵蓋了授權、限流、降級、調用統計監控四大功能模塊。

• 限流：其作用在當過載的時候掐掉一些流量，讓系統有能力集中資源以較快的速度處理平台處理范圍內的業務請求。

• 首先需要采用壓力測試的方法對系統進行壓測。阿里巴巴開發了線上壓測鞏固，來獲取該服務所能提供的最大處理能力。

• 然后對服務資源的使用情況進行監控。在實際中，都會通過服務的QPS作為限流的關鍵判斷指標。

• 將資源監控的指標與之前獲得的服務處理上線進行比較，如果超過服務處理上限，則啟動限流。

• 阿里巴巴是通過在 Nginx 上實現的擴展組件 TMD 實現了接入層限流。

• 降級：判斷依賴的資源的響應情況，當依賴的資源響應時間過長時進行自動降級，並在指定的時間后自動恢復調用。

• 監控：提供了全面的運行狀態監控，實時監控資源的調用情況，包括QPS，響應時間，限流降級等信息。

 

2.流量調度：

• 目標：針對分布式服務系統的流量調度平台，用於屏蔽所有機器的軟硬件差異，根據機器的實時服務能力來分配機器的實時流量。

• 原理：通過秒級獲取服務器系統運行指標以及業務指標，通過流量調度平台設置的決策算法以及規則，當發現滿足規則條件的指標狀態發生時，對線上環境的服務器進行下線等操作，以屏蔽這些單點或局部出現故障的應用實例對整體平台產生擴展式的影響。

 

3.業務開關：

• Switch 是一個輕量級的開關集成框架，用來集中管理集群各應用的開關，統一業務操作業務開關的方式和API，方便進行集中化管理。

 

 

4.容量壓測及評估規划：

• 需求：要知道一個平台的處理能力是否能支持大促活動的訪問量，最常見的方式是對平台進行性能測試。

• 容量壓測：將線上真實的流量引流到壓測目標服務器上，來獲取單機QPS能力。

• 容量規划：利用服務的單機QPS數據，結合對各種服務器機型處理能力的差異化分析，對到底需要部署多少線上服務器資源才能滿足大促活動有更准確的預測。

5.全鏈路壓測：

• 這是阿里全系統每個環境都參與的雙11實戰演習，主要對零點峰值流量進行評估，以及網站承壓能力進行測試。 

6.業務一致性平台：

• 平台還是偶爾會出現業務與數據不一致的問題。

• 阿里巴巴利用BCP 平台來解決該問題。

 

 

9 服務治理：治理平台 - 共享服務平台 

服務化野蠻發展帶來的問題：

• 服務的數量和業務覆蓋范圍越來越大。

• 應用和業務架構越分越細，服務越來越專業化，跨領理解的成本越來越高。

• 服務安全控制層缺乏。

• 開發體驗很不友好，產品在接入流程，開發使用手冊建設非常之差。

• 整體服務體系缺乏一個統一的服務治理層。 

上面這些問題，可歸結為一個問題，服務治理。針對這些問題，集團的共享服務平台 SPAS 應運而生，其目標是對阿里巴巴集團的服務更好地進行治理和共享。

 

主要功能：

• 服務的描述元數據

• 服務注冊與發現機制

• 服務的訪問控制與安全策略

• 應用服務 portal

• 服務依賴與運維管理

• 服務SLA協議

• 服務消費者的管理與支持

• 服務化輔助工具支持

• 服務調用分析與報表

• 服務成本核算與服務能力變現

• 文檔與開發工具支持 

SPAS 也是一個協作的平台，是以服務為對象建立的一個在線市場。其中有三個角色：服務共享平台、服務提供者、服務消費者：

 

三個角色之間的協作方式：

 

 

示例：業務中台與前端應用協作：

• 業務中台對前端核心業務的緊密溝通機制。各個服務中心的核心架構師和運營人員會定期參與前端業務方的業務會議或重大項目的研討會。這樣，讓業務中台對於前端重要應用的業務發展動向有一個准確及時的了解，從而為業務中台如何更好地支撐這些業務做好准備和服務能力的提升。

• 建立分歧升級機制：因為兩方所處崗位和訴求的差別，有時難免對於講一個業務功能的實現放到業務中台還是在前端應用中實現存在分歧。此時，一般按照業務負責的層級關系依次升級。

• 崗位輪動推動真正換位思考：將業務中台某服務中心的負責人與對口業務的負責人進行崗位對調，讓雙方在實際工作中更真切地感知到出於不同崗位時對業務的理解和出發點。

• 業務持續沉淀及共建模式：業務中台是一個不斷沉淀，不斷完善的過程。在進行業務沉淀到中台的過程中，又會出現兩種情況：

• 一種是業務中台現有的人員對於要沉淀的業務功能自身就有較強的業務能力，能夠很好地完成將業務功能沉淀和融入到業務中台的能力，這是一種業務沉淀的典型方式。

• 另一種則是對於要沉淀到業務中台的業務，業務中台現有人員沒有足夠的業務理解和能力，此時，就會采取共建的模式，業務中台和前端應用方各自派出人員共同組建一個團隊，一起負責該業務功能的實現，以及到中台的能力沉淀。 

業務中台的考核機制：

• 服務穩定是重中之重。40%。

• 業務創新推動業務發展。25%。

• 服務接入量是衡量服務價值的重要考核。20%。

• 客戶滿意度促動服務的提升。15%。

 

謝謝您的閱讀，也歡迎關注本公眾號：