1、精選優質文檔-傾情為你奉上企業服務總線ESB方案書1 需求綜述1.1 主數據平臺接口系統建立與SAP相同的基礎數據管理庫，通過數據總線接口同步能源集團MDM中傳輸過來的編碼或數據，以滿足電子采購平臺基礎數據管理的需求。基礎數據信息包括：物料編碼、計量單位、供應商、客戶等。1.2 業務數據接口系統業務數據通過數據總線接口同SAP、OA、EC等系統進行數據交互。 系統必須確保通過數據總線接口訪問SAP、OA、EC等系統數據與電子采購平臺數據傳輸及時準確、數據完整統一；數據總線系統SAPOA辦公系統MDMEC數據中心電商平臺中礦微星系統1.3 OA系統接口：支持將電子采購平臺中的待辦事項發送到OA辦

2、公系統進行審批，并讀取審批流。1.4 國家法定信息發布媒體：按照國家相關要求，選擇相關媒體建立統一接口，支持招標公告、變更公告、結果公示等的自動發布。如國家無強行規定，可以不做接口。2 系統解決方案2.1 系統技術架構2.1.1 運行平臺運行平臺內部按照集成應用的特點分為多個集成“通路”，目前考慮分為四類通路：1、關鍵服務通路關鍵業務、實時性要求高。2、非關鍵通路非關鍵業務，查詢等。3、服務代理通路從目標架構過渡過程中，與集成目標無關的可以采取“穿透”的方式，減少實施工作量和實施成本。另外，復用價值較低的服務請求也適合采用“代理模式”。4、低成本通路對于實時性要求不高，且信息量大的服務，可采取

3、批量處理模式，降低集成實施成本。實際部署環境中，每一類通路都可以有多個物理部署，用來保證系統的可靠性，同時也支持橫向的擴展和減少不同系統之間的相互影響。2.1.2 開發平臺基于ESB系統標準的服務接口定義、內部統一的元數據管理、數據結構和服務接口定義、路由規則等，實現多個技術通路的統一配置開發。開發平臺的是對各個技術通路實際實現方法的抽象封裝。提供服務邏輯的開發框架和組件庫，用于轉換適配邏輯、公共服務邏輯等的標準化開發、組件重用和統一管理。2.1.3 監控平臺ESB應用系統要建立統一的日志規范、流水記錄規范、錯誤碼規范、系統運行狀態檢測規范、系統運行狀態控制標準，實現對ESB系統整體統一的監視

4、和控制。是ESB系統的集成“控制面板”。主要功能包括：異常監視、通知提醒、運行控制、實時查詢、統計分析、服務的配置和發布、服務管理、統一維護和版本部署等。由于ESB系統是整個企業的服務訪問樞紐，ESB可以集中監控企業內所有的服務訪問，能夠提供各個系統的服務質量和狀態的統計數據，例如：成功率、服務響應時間、服務訪問量、服務狀態異常等。2.1.4 公共服務提供統一的流量控制服務、日志記錄、接入參數控制等公共服務。從而實現多技術平臺、多物理部署運行環境的公共服務支持。2.1.5 適配器適配器是ESB系統解決與外部系統之間各類差異的總稱。ESB將外部系統分為請求系統和服務系統兩類。 服務

5、系統適配器對于服務系統，尤其是遺留服務系統，基本集成策略是由ESB項目組開發適配器進行集成。但是服務系統適配器，并不能解決所有的服務適配問題，例如：ESB服務接口規范與服務系統規范的復雜對應和匹配工作，尤其是涉及到多個服務系統接口的復雜流程調用部分，如果由ESB組合這類服務流程組合，解決相關的交易完整性、一致性問題，代價太大而且無法保證。因此，實際集成實施過程中，不可避免的要涉及到對服務系統的改造工作。 請求系統適配器對于請求系統，ESB的基本原則是要求請求系統符合ESB的技術規范和服務接口規范。目的是減少不必要的轉換適配層次，提高系統的集成服務效率，降低資源消耗。ESB系統可為

6、請求系統提供API，對請求系統屏蔽通訊適配、報文組包等技術細節。請求系統只需要理解業務層面的接口規范，從而大大簡化請求系統的集成工作，同時還可以加強對請求系統的監控管理，同時為接口技術實現的升級改造提供輔助支持。ESB也可以開發適配器，實現請求系統的集成。主要針對那些無法改造或改造成本過高的請求系統。2.2 部署方案 2.2.1 管理監控部分部署方案 ESB系統的部署方案必須符合企業基礎架構的要求。1）WebServer和Application Server必須分離，分別部署在Web2區和APP區。或者Web2區的應用通過生產區域的APP，訪問DB。2）用戶管理要符合集團的規范。用戶權限控制統

7、一通過UM。UM決定用戶是否有權限操作ESB的管理監控平臺。UM權限通控制通過以后，由ESB管理監控應用來進行詳細的角色權限管理。3）考慮到費用問題，可以采用Apache和Tomcat。2.2.2 硬件選型建議ESB系統目標架構硬件選型主要考慮從以下因素：1）成本因素ESB系統基于Java技術實現，具有跨平臺的技術優勢，因此可將成本是考慮硬件選型的首要指標，未來隨著ESB應用規模的不斷增長，硬件成本在項目投入所占比重將會增加，因此選擇性價比高的硬件平臺是提高效費比的有效途徑。2）硬件擴容周期ESB作為企業內部信息化最為關鍵的服務樞紐，必須能夠快速響應應用規模的增長，其中包括硬件的采購周期、系統

8、擴容部署速度。3）資源調配的簡便性、靈活性ESB系統應能夠針對業務量的周期性變化，靈活的增減系統資源配置，資源的調整不應對集成服務持續性造成影響。基于上述考慮，ESB系統的硬件推薦采用刀片服務器。刀片服務器還具有以下優點：1) 硬件成本相對低廉，配套的系統軟件和中間件價格也相對較低。2) 虛擬化的集中資源管理，可有效提高資源的利用率。3) 在集群中插入新的刀片，就可以提高整體性能。4) 支持熱插拔，硬件資源可以輕松地進行替換，并且將維護時間減少到最小。5) 節約空間、便于集中管理、易于擴展和提供不間斷的服務。2.2.3 邏輯分區部署方案2.2.4 硬件配置建議其對應分配如下：名稱功能分布配置計

9、算單元數量適配器/公共服務適配器 公共服務2cpu(8核)32GB memory1*2集成核心WebMethodsMessage Broker2cpu(8核)32GB memory1*2數據庫服務器Oracle2cpu(8核)32GB memory1歸檔數據庫服務器Oracle2cpu(8核)32GB memory1備份資源池作為公共備份2cpu(8核)32GB memory1總計72.2.5 服務接口規范ESB系統負責解決實施服務接口規范與服務系統接口的差異，可將主要的實施工作控制在ESB項目范圍內，大大降低周邊系統的改造工作量，配合一些系統的瘦身計劃的分階段順利實施。2.2.6 高性能、高

10、可用性及擴展能力設計高處理能力保證措施控制信息+XML應用報文，中間層次不必解析XML應用報文，使系統不僅具備完善的管理控制能力，同時還減少了報文解析開銷，提高了效率。非阻塞的異步模式、流水線式的作業處理，提高吞吐能力。異步記錄流水日志，保證信息的完整記錄，同時不影響系統的處理性能。系統處理能力可隨硬件資源的擴展線性的增長。系統所有配置規則均加載到Cache中，運行過程中不存在對數據庫配置信息的讀寫操作，保證系統高效運行。持續穩定運行保障措施所有應用模塊均為群集部署，系統不存在單點故障隱患，某個模塊的故障不影響正常運行。系統應用版本的升級可按模塊分別進行，不影響業務的正常運行。采用數據庫分區技

11、術，實現海量數據記錄的清理和分區切換過程15秒鐘內完成，無需采用與應用相關的數據庫分表方式，實現批量數據處理對總線應用透明。系統提供完備的動態安全刷新手段，配置信息可運行時在線刷新。可擴展性系統可以在CPU、內存等資源增加及擴容的情況下自我線性擴展處理能力；每個邏輯模塊可以采用橫向擴展的多物理模塊部署。中間用隊列進行通訊。可維護性系統具有較為完善的用戶管理界面，提供對系統所有功能的維護與參數配置管理的功能；系統采用統一的服務模式和開發框架，從開發商增加可維護性，系統部署上采用多邏輯單元分離部署，減少系統內部的耦合度，增加整個系統的可維護性。2.2.7 完善的安全機制企業應用集成技術使復雜的業務

12、流程、大量的信息和數據在各IT應用系統和業務部門之間高效的流轉和共享，實現業務流程標準化和自動化，促進業務流程優化，提高建行運營效率。任何不安全因素都會造成不可估量的損失，故所有數據的傳輸、處理、交換都必須在良好的安全環境下進行，因此，必須建立一套完整的安全機制，以確保整個通信系統的安全運行。方案主要為ESB系統提供如下幾個方面的安全服務：1. 密鑰管理提供安全有效的密鑰管理方案，實現應用系統和ESB系統的密鑰產生、密鑰分發、密鑰更新、密鑰注銷等。提供密鑰的自動更新機制，保證密鑰的安全性，提供高效的對稱密碼算法，確保應用系統具有可用性和易用性。2. 身份認證保證接入ESB系統的合法性，提供應用

13、系統和ESB系統之間的雙向身份認證，采用基于證書的認證模式，系統使用的數字證書由第三方CA或者采用自運行維護的CA提供。CA證書采用離線下發的方式，以PKCS#12文件的格式安裝到ESB系統和應用接入系統。身份認證完成后，雙方得到一個64個字節的隨機數，通訊雙方使用的對稱密鑰都是基于這一組隨機數產生，對稱密鑰的選取規則雙方使用相同的策略。對稱密鑰和對方的公鑰信息存放在系統主機的共享內存，方便應用系統加密使用3. 通訊加密ESB系統的安全性是保障IT應用系統安全可靠運行的重要環節，使用PKI技術實現系統的密鑰管理和通訊加密是目前解決此類問題的最有效途徑，應用系統和ESB系統之間通訊的報文使用對稱

14、算法加密保護其機密性。為了提高密碼運算的處理速度，這里推薦使用AES算法，密鑰的長度為128bit。通訊雙方在身份認證完成后，在共享內存中保存對稱密鑰。客戶端和服務器端的加密流程如下：客戶端加/解密流程：1) 查詢共享內存中的對稱密鑰和算法ID，根據加密要求選取對稱密鑰，如果共享內存中沒有對稱密鑰，加/解密失敗。2) 使用查詢得到的對稱加密密鑰，對報文進行加/解密處理。服務器端加/解密流程：1) 根據客戶端的系統代碼，查詢共享內存的加密密鑰和算法ID，如果共享內存中沒有 對稱密鑰，加/解密失敗。2) 使用查詢得到的對稱密鑰，對報文進行加/解密處理。4. 關鍵字段MAC2.3 整體解決方案ESB

15、集成技術架構方案劃分為四個層面：渠道通迅接入、數據交換層、平臺服務調度層、服務適配層。系統的每個層次都可進行橫向擴展，實際應用中系統處理能力可以線性增長。l 對于渠道服務請求的接入，ESB提供標準的通迅協議（支持TCP/IP、HTTP、SNA、 FTP、MQSeries、JMS等協議和中間件）和標準接口規范，同時還為請求系統提供服務請求的API，屏蔽通訊協議和報文格式的技術細節，能夠提高請求系統的集成開發效率、減少轉換適配環節，同時還大大加強了總線系統對接入的控制和管理，促進了集成應用的快速推廣和可靠運行。l 對于改造成本過高的存量系統，通過集成開發在數據交換層實現分類路由、同步異步轉換、消息

16、格式轉換、代碼轉換等功能。l 平臺服務調度支持四種模式：（一）、通道，用于高時效性、高一致性、高吞吐 能力的服務；（二）、通道，用于時效性和一致性要求不高的服務；（三）、服務代理通道，目標架構過渡過程中，與當期集成目標無關，可以采取“穿透”的方式，減少實施工作量和實施成本。另外，復用價值較低的服務請求也適合采用“代理模式”；（四）、低成本通道，對于實時性要求不高，且信息量大的服務，可采取批量處理模式，降低集成實施成本及節省系統資源。l 所有適配器需要在對存量系統分析后集成開發，ESB集成方案中集成產品的相互訪問統一使用隊列方式。2.3.1 接入控制需要完成以下功能：1.對渠道提供不同協議的接入

17、功能，包括MQ，webmethods, http等協議的接入。2.對不同的渠道提供不同的接入點，實現系統負載均衡和最大限度的故障隔離，提供高容量，高可靠性的服務。3.參數服務為渠道提供統一服務接口模式，伺服渠道下載需要的通道接入信息。4.渠道通過輪詢請求方式主動下載版本變化信息，初始化變化的連接池。5.服務端進行主動控制，實時控制渠道的接入通路。6.當某一接入點故障時，通過主動控制渠道接入點，自動切換到可以的接入點，實現故障的完全隔離。7.對壓力較大的接入點，通過主動控制，把部分數據切換到壓力較小的通路，實現實現負載控制。8.服務端為渠道維護相應標識信息和其所有當前版本和歷史版本信息。9.通過

18、維護歷史版本信息，實現版本回退功能。實現方案：1. 整體架構圖2.3.2 通信接入模塊負責和外部系統進行通訊，進行原始報文數據的傳輸。通信接入層實現以下功能：1利用系統層通訊協議和請求系統進行通訊，包括TCP/IP、HTTP、SNA、FTP、MQSeries、JMS。2外部系統約定的通訊方式的實現，包括如何進行通訊連接，如何進行通訊應答，如何進行數據傳輸，如何約定通訊報文的大小，如何確定數據傳輸是否完畢，如何處理通訊錯誤，如何關閉通訊連接，如何處理通訊層數據完整性校驗等。3識別外部系統類型。4多通訊連接的并發處理。以下的功能不需要由通訊接口層完成：1.非通訊層面的數據報文的加解密。2. 非通訊

19、層面的數據報文的壓縮，解壓縮處理。通訊接入層屏蔽了所有的通訊細節，數據交換層只知道從某個外部系統獲得了或者發送了一個數據報文，至于該數據報文是如何獲得或者發送的，和數據交換層本身無關。2.3.3 請求系統適配完成從服務端返回數據到標準輸出之間的轉換或從一個渠道端請求接口數據到MBSD服務標準請求數據之間的轉換。具體功能包括：1.應用層面的數據報文的加解密。2.應用層面的數據報文的壓縮，解壓縮處理。3.數據報文類型的識別。4.數據報文的打包拆包，根據報文類型以及相關配置將數據報文拆分成統一的數據接口或者相反。5.數據接口之間的轉換，根據定義的規則從一個數據接口轉換成服務數據接口或者相反。接入適配

20、層屏蔽了數據的具體物理表示和組織，平臺服務調度層只知道收到了一個服務請求要求處理，至于該服務請求是從哪個系統發起的，原始的請求數據是什么，和服務整合層沒有關系，只和數據交換層有關。接入適配框架提供可配置的定長、變長報文轉換適配器，以及可擴展的接口可以適應各種不同格式的報文轉換。同時接入框架提供了MBSD元數據管理功能，能夠方便的定義報文的元數據，為報文的轉換以及應用的開發提供便利。2.4 集成服務功能2.4.1 服務治理提供服務標準定義、服務封裝、注冊與發布等功能, 提供位置透明性的服務路由和定位服務ESB的服務接口規范應該基于對業務流程的理解，經過抽象、歸納形成，服務接口規范獨立與現有系統的

21、具體實現，接口規范具有較強的獨立性、穩定性。從而真正消除請求系統與服務系統之間的關聯關系，實現服務的位置以及服務的具體實現與服務的訪問過程無關。我們提供MBSD規范落地實施的工具：元數據管理，服務接口定義配置，導入導出工具（可以通過web頁面形式和導出文件形式對外公布），服務規范適配的開發框架。我們提供MBSD規范落地實施的工具：元數據管理，服務接口定義配置，導入導出工具（可以通過web頁面形式和導出文件形式對外公布），服務規范適配的開發框架。 2.4.2 提供對出錯服務的及時檢測和隔離功能 ESB系統實時檢測服務系統的服務狀態，當服務出現異常時，能夠及時發現，通過監控平臺發出報警，通過人工手

22、段或預先設定的規則，對狀態異常的服務或服務系統進行迅速隔離，避免因故障導致服務阻塞，保證請求系統對其他服務的正常訪問。 2.4.3 協議轉換 支持外部系統通過TCP/IP、HTTP、SNA、FTP、MQSeries、JMS等協議和中間件與ESB平臺通訊。 一般情況下，請求系統使用ESB系統提供的API，按照ESB系統的技術標準和服務規范進行服務訪問，從而避免不必要的協議轉換開銷。 但是對于請求系統無法改造或改造成本過高的情況下，ESB系統應提供接入協議適配的功能，支持外部系統通過不同的通訊協議與ESB平臺通訊。 但是應注意，ESB更多的情況下是為了適應服務系統的技術差異，才進行通訊的適配，從系

23、統的規范化和易維護性角度考慮，不推薦被動的對請求系統進行通訊協議適配。 接入框架提供了對各種通訊協議的轉換適配器，可以滿足上述協議轉換要求。MQ自身作為消息中間件為JMS通訊協議提供底層的通訊服務。但ESB作為企業服務總線需要有大吞吐量，而同步服務并發有限，容易造成資源的阻塞，以異步的方式進行訪問，而MQ作為消息中間件，是最好的異步通訊方式。 2.4.4 消息格式轉換 支持通過元數據管理消息格式定義；支持任意類型報文之間的轉換。 消息格式轉換是集成類系統應具備的基本功能，ESB系統對于消息格式的轉換是基于配置實現的，因此消息報文的的數據域需要在配置中進行定義。 ESB的服務接口規范標準中包括規

24、范中使用的數據域。在ESB系統內部數據域分為不同的類型、長度、精度等表示形式，ESB系統引用預先定義的、規范化的元數據對服務接口規范進行描述，使用元數據可以是規范定義工作更加規范化、減少冗余、便于管理和統一維護。 元數據可根據應用范圍劃分成不同的“域”，可以更加方便的進行方便維護和管理。 ESB系統一般通過配置方式實現標準與非標準的報文轉換，包括：格式轉換和數據映射，對于復雜的映射規則可以通過增加映射功能函數（服務組件）的形式實現 MBSD接入框架提供了可配置的定長、變長報文轉換組件，以及可擴展的接口可以適應各種不同格式的報文轉換。同時接入框架提供了MBSD元數據管理功能，能夠方便的定義報文的

25、元數據，為報文的轉換以及應用的開發提供了便利。目前已經支持XML，定長等多種報文格式。 2.4.5 服務路由 基于服務ID、內容、結果等方式路由；交易流程能使用智能路由組合多個子交易。 我們采用兩個層次的路由： l 前端API進行的服務通路路由。 前端API根據ESB平臺提供的接入參數信息決定采用哪條通路（MB/WEBMETHODS）進行服務訪問。 l 核心的交易路由。由MB/WEBMTHODS核心進行路由，根據交易碼決定哪個后臺服務系統進行服務訪問。 路由方式： l 服務ID路由。也就是交易碼進行路由判斷。 l 數據依賴路由。動態的根據報文中的數據和配置業務規則進行路由選擇。 l 復雜流程路

26、由。在復雜組合交易中根據每一步的響應結果和配置的復雜交易流程來進行路由選擇。此路由在ESB平臺的流程配置來實現。 2.4.6 監控和運維 提供服務調用的記錄、測量和監控數據；提供事件檢測、觸發和發布功能；支持產品版本升級后對現有組件的兼容性。 ESB系統應記錄每一次服務訪問的流水信息，用于統計和分析。記錄過程應該是高效的，應避免流水的記錄影響服務的執行效率。流水記錄一般只記錄服務過程的摘要信息。需要時，可以通過開關控制打開或關閉詳細的報文信息。 系統還應及時捕獲服務處理過程中的各種異常信息，通過統一的控制臺發出報警，警示信息應劃分異常的類別和級別，對于重要的異常還可以通過短信等手段及時通知運維

27、人員及時處理。 監控管理的接口定義應是可擴展的，例如異常種類、異常級別、流水信息數據項等，做到信息的獲取與后續的處理動作無關，從而保證接口的兼容性、穩定性。2.4.7 服務等級可定義不同的服務等級并實現具體內容。可以從多種維度來定義服務的屬性，包括服務的級別。服務的級別可以關聯到不同的處理動作。服務級別與處理的關聯關系可以通過規則進行定義，實現功能的靈活定義與擴展。關聯的動作可以是：處理的優先級，異常提醒方式等。 2.5 系統非功能需求2.5.1 可用性系統能提供功能方面的各種需求的實現，在運行環境下提供7*24小時NONE-STOP服務；ESB是服務訪問的樞紐，不允許由于系統的故障和恢復過程

28、中斷系統服務，ESB應采用群集模式保證系統的高可用性，群集模式還可以使系統資源得到充分利用。對于數據庫服務器、通訊接入服務起等模塊的高可用性需求，為降低實現方案的復雜度和實施成本，可采用設備之間相互熱備的方式。例如數據庫服務器可以和歸檔數據庫服務器采用熱備的方式保證高可用性。系統自身的批量處理，如：數據歸檔清理，日志歸檔等工作，不能影響系統的正常運行，保證系統7*24小時連續運行。需要定期進行的系統資源累積效應消除動作，如：定期重啟Java虛擬機消除長期運行后的堆棧碎片，應保證在其他群集模塊正常運行的情況依次進行，保證系統服務不間斷。系統的配置更新應采用動態刷新的機制聯機進行，避免配置更新對系

29、統的處理能力造成影響。2.5.2 可擴展性系統可以在CPU、內存等資源增加及擴容的情況下自我線性擴展處理能力；系統的架構設計要保證系統的各個層次均可按照負載情況，單獨進行橫向的擴展，以提高處理能力。應保證處理能力隨硬件資源的擴展呈線性增長。2.5.3 可維護性統具有較為完善的用戶管理界面，提供對系統所有功能的維護與參數配置管理的功能；系統涉及到多種平臺產品和技術、采用多物理分區的部署方式，單獨對每個分區進行監控和維護是不現實的，必須提供統一的管理監控界面，實現系統的集中統一管理、監控和維護。2.5.4 安全性提供認證和授權、不可否認和機密性、安全標準的支持等。ESB系統作為服務訪問的中間層，除

30、了發布標準的安全規范以外，還要滿足各類集成應用的安全需求，要實現與存量服務系統的安全協議支配，因此ESB需要支持通訊層面，應用層面的安全技術標準。例如：對標準安全協議的支持，通訊過程加解密，MAC校驗，PKI，特定場景的數字簽名等。2.5.5 性能需求統能通過招標人的壓力測試。性能指標：日均1000萬筆數據，ESB對于關鍵數據的處理時間<1秒，對于非關鍵數據ESB的處理時間<2秒。達到系統性能指標峰值要求時，系統處理能力應留有足夠的余量，CPU，內存等系統資源的使用率應低于80%，達到平均值要求時，系統資源使用率應低于50%。保證系統在設計指標壓力情況下的長期穩定運行。2.6 公用

31、服務2.6.1 流量控制當服務訪問量超過預設的流量值時，總線系統快速擋回對該服務的訪問請求，根據服務系統的服務響應時間和返回狀態，判斷服務狀態是否異常，當服務系統發生異常達到設定的條件時，自動降低對該服務系統的訪問流量限制，避免服務系統的故障影響范圍擴大。通過交易閥值的統計來完成實時的后臺系統服務質量統計。從而達到對前端系統訪問的指示。在后臺服務質量不好的情況下，把針對此后臺的數據在接入層直接擋回，避免交易在ESB中占用過多處理資源。由于系統超時時間一般設置的比較長，防止公用通路被單一后臺服務通道堵塞，需要知道后臺系統的運行狀況，當出現問題后，及時隔離，不影響主通路運行。2.6.2 故障隔離服

32、務系統發生異常達到設定的條件時，自動降低對該服務系統的訪問流量限制，避免服務系統的故障影響范圍擴大。保留少量的探測服務對故障系統進行探測，服務系統故障排除恢復正常后，總線系統可自動恢復其正常的流量。2.6.3 統一流水號實現ESB平臺內統一標準平臺流水號的分配功能，唯一標識請求系統的發往ESB平臺單次服務調用。2.6.4 日志記錄應用日志作為服務系統的又一I/O點，也可以采用異步模式。將一個服務線程在完成一次報文處理過程中的所有日志集中一次性異步輸入到指定文件是必要的。一方面減少業務處理線程的I/O操作，另一方面講一次業務處理的日志集中輸出相比傳統的多線程分離輸出方便問題查找，大大增加了日志的

33、可讀性。2.7 管理監控由于實際部署的系統隨著需求的增加，部署會經常發生變化，對于隨著出現的多監控源，我們需要建立統一集中的管理和操作平臺。需要做到以下幾方面：2.7.1 系統平臺級監控包括cpu，內存，文件系統，各隊列深度，應用日志，應用core文件等。2.7.2 應用級監控包括各部署模塊的內部運行狀態。2.7.3 統計分析既定的匯報機制、匯報內容和匯報格式。有些匯報的內容是通過手工統計匯總的，能盡量將這些匯報物交由報表系統自動生成。ESB作為全行的運行基礎平臺，需要能向IT部分提供全面的IT資源運行情況，為全行的IT資源分配提供依據。2.7.4 異常報警對平臺運行的問題進行報警，需要有統一

34、的報警規范來支持未來報警類型的擴展，需要提供多種報警模式，例如聲音，短信，微信等。2.7.5 統一的運維管理提供應用日志，流水日志的統一處理，防止多點，多平臺部署情況下維護混亂的情況。3 技術支持與服務方案公司在大力開拓市場的同時，高度重視售后服務及技術支持工作，始終恪守“客戶滿意第一”的原則，以全力滿足用戶的一切需要為己任，向用戶提供“及時、專業、真誠”的技術服務。公司不僅為用戶提供一流的產品，而且為用戶提供一流的服務，在第一時間對用戶的服務要求做出響應。公司將盡心盡力與用戶緊密合作，為用戶單位提供及時、全面的技術支持和服務，保障系統的正常運行。3.1 技術支持與售后服務體系為滿足客戶系統7

35、X24小時不間斷、高可靠地運行，公司按照國際質量標準，形成了一套完備嚴謹的質量管理體系，實現了從產品、服務到公司運營全過程、全方位的質量管理3.2 服務管理模式公司將按如下模式進行技術支持與服務管理：1) 公司服務代表是對客戶服務需求的接口，并定位服務內容，指定服務技術人員,咨詢顧問。2) 公司服務團隊負責提供維護支持服務。3) 公司全體技術人員,咨詢顧問都可以作為后臺資源，為服務技術人員,咨詢顧問提供支持，滿足客戶的服務需求。在必要時還可以要求合作伙伴提供技術支持，為客戶提供滿意的服務。4) 客戶的服務需求將按級別優先級響應，并提供相應的服務。3.3 服務響應3.3.1 問題優先級（或問題嚴

36、重程度）級定義優先級定義：優先級判定標準1系統崩潰，無法啟動或拒絕連接等原因導致客戶無法獲得任何系統服務，并對客戶業務的正常運行造成重大影響。2系統主要功能不能正常工作，并對客戶業務的正常運行造成較大影響；生產系統不穩定，并有周期性的中斷。3系統有故障，但仍可全面運行，對客戶業務系統的正常運行有一定的或輕微的影響4優先級1、2和3之外的問題和需求，例如產品性能增強請求；產品功能、安裝或配置方面需要信息或支持，對客戶的業務運作幾乎無影響；非生產系統故障。嚴重程度定義：嚴重程度1：問題導致客戶的業務系統完全喪失服務功能，對業務至關重要的工作無法繼續進行，情況緊急。具有如下特點：數據丟失、關鍵功能喪

37、失、系統不正常刮起、系統崩潰，并在啟動后重復崩潰。嚴重程度2：問題導致客戶的業務系統喪失部分重要的服務功能，沒有可以接受的替代解決方案，但業務系統可以有限的繼續運行。嚴重程度3：問題導致客戶的業務系統喪失較少的服務功能。對業務系統影響較小，需要提供解決方案以恢復功能。嚴重程度4：問題導致客戶的業務系統沒有喪失服務功能。一般是較小的錯誤信息、不正確的結果或文檔錯誤，對業務系統運行沒有影響。3.3.2 服務響應時間在接到客戶方通過電話、信函、傳真、電子郵件等方式提出的服務請求后，我方將在規定的響應時間內盡快做出響應，并根據問題的優先級采取相應的措施。服務響應時間：優先級響應時間1< 1小時2

38、< 1工作日3< 2工作日4< 5工作日對優先級為1的問題：公司將不分晝夜和節假日，立即安排相關人員與客戶溝通，查找、分析問題原因，提供解決方案及處理意見，并采用遠程和現場服務的方式，務求在最短的時間內解決客戶的問題。對優先級為2的問題：公司將不分節假日，在接到客戶服務請求的當天內，安排相關人員與客戶溝通，查找、分析問題原因，提供解決方案及處理意見。在遠程登錄無法解決問題時，最遲在48小時之內安排相關人員到達現場提供服務。對優先級為3的問題：公司將在法定工作時間內安排相關人員與客戶聯系，盡可能通過遠程服務方式為客戶處理問題。對優先級為4的問題：公司將在法定工作時間內安排相關人

39、員與客戶聯系，客戶應與公司協商，確定采用遠程或現場服務方式及提供服務的時間注： 工作時間：周一至周五9：0018：003.3.3 問題解決時間此項僅作為內部考核參考用，不作為對客戶的承諾。服務技術人員,咨詢顧問在接到服務請求后，應該在規定的時間內給出解決方案，并根據問題的優先級采取相應的措施。 解決時間：優先級解決時間1< 0.5工作日2< 1工作日3< 2工作日4< 5工作日對優先級為1的問題：維護技術人員,咨詢顧問應該在半個工作日內確認問題原因，給出解決方案，或者至少給出解決問題的方向（例如：硬件問題：找硬件廠商等）。對優先級為2的問題：維護技術人員,咨詢顧問應該在一個工作日內確認問題原因，給出解決方案，或者給出解決問題的方向（例如：數據問題，給出切換方案），并和客戶確認實施的時間點。對優先級為3的問題：維護技術人員,咨詢顧問應該在兩個工作日內確認問題原因，給出解決方案，或者給出解決問題的方向，并確認后續實施的方式（例如：流程問題，重新設計流程、配置及測試）。對優先級為4的問題：維護技術人員,咨詢顧問應該在兩個工作日內確認問題原因，給出解決方案，或者給出解決問題的方向（例如：開發問題，給出開發需求分析，指導客戶自行