成果上報申請書-BOSS系統(tǒng)高可用性能力提升項目

附件 1：成果上報申請書 成果名稱 BOSS 系統(tǒng)高可用性能力提升 成果申報單位 成果承擔部門 /分公司 項目負責(zé)人姓名 成果專業(yè) 類別 * 支撐 網(wǎng) 成 果 研究 類別 * 現(xiàn)有業(yè)務(wù)優(yōu)化 省 內(nèi) 評審 結(jié)果 * 通過 關(guān)鍵詞索引（ 3 5 個） 業(yè)務(wù)支撐網(wǎng) ； BOSS； 電信級 文章摘要（ 200 字左右）： 在 市場 競爭 激烈 、 以客戶為導(dǎo)向的今天，業(yè)務(wù)的發(fā)展、市場的開拓和客戶滿意度的提升等方面對業(yè)務(wù)支撐系統(tǒng)提出了更高的要求。對中國移動廣西公司來說，提升系統(tǒng)的可靠性和可用性，構(gòu)建電信級的業(yè)務(wù)支撐網(wǎng)系統(tǒng)，已成為增強企業(yè)核心競爭力、提升客戶滿意度的重要手段。 BOSS 系統(tǒng)做為業(yè)務(wù)支撐網(wǎng)的核心系統(tǒng)，系統(tǒng)龐大、架構(gòu)復(fù)雜，自 BOSS1.5 上線以來，系統(tǒng)就一直受到穩(wěn)定性差，故障頻發(fā)且故障引發(fā)業(yè)務(wù)中斷時間長的困擾。本項目將以科學(xué)的方法和手段深入分析目前系統(tǒng)癥狀，找出對策，以 7X24 小時不間斷可用服務(wù)電信級 BOSS系統(tǒng)為目標，通過對系統(tǒng)逐步實施改造、優(yōu)化，逐漸提高 BOSS 系統(tǒng)的可靠性和可用性， 探討如何持續(xù)漸進的建設(shè)電信級的業(yè)務(wù)支撐系統(tǒng)的思路 。 省內(nèi)試運行效果（ 300 字以上）： 從 2007 年 4 月份開始實施，截止到 9 月底取 得的效果： 1、系統(tǒng)平臺層面 營業(yè)系統(tǒng)：提升營業(yè)數(shù)據(jù)庫、中間件的處理能力，解決營業(yè)數(shù)據(jù)庫 RAC 在節(jié)點主機宕機時不能正?；榻庸軉栴}。 客服系統(tǒng)：完成了網(wǎng)絡(luò)優(yōu)化改造和客服數(shù)據(jù)庫單點故障改造。 帳務(wù)系統(tǒng)：提升帳務(wù)應(yīng)用、數(shù)據(jù)庫的處理能力，完成帳務(wù)數(shù)據(jù)庫單點故障改造。 計費系統(tǒng)：完成擴容提升計費系統(tǒng)的處理能力。 CBOSS：完成 BES 配置集群、建立 CBOSS 應(yīng)急系統(tǒng) 。 PRM/CHANNEL：完成從營業(yè)中間件分離出來，消除單點故障隱患。 結(jié)算系統(tǒng)：完成主機遷移提升系統(tǒng)處理能力，消除單點故障隱患。 即開即通：配置了雙 機，負載均衡，完成了全區(qū) BOSS 到 HLR 的備用路由的開通，通過路由切換腳本完成主備路由切換，主路由實現(xiàn)冗余，整個系統(tǒng)完成了消除單點故障的改造。 二卡合一：配置了雙機，負載均衡，消除消除單點故障。 2、維護管理層面 完善并演練了各子系統(tǒng)的應(yīng)急預(yù)案，其中做為核心系統(tǒng)的 營業(yè)系統(tǒng)的中間件在數(shù)據(jù)庫后臺之間的應(yīng)急方案切換速度由原來的 2 個 多小時縮短到 30 分鐘左右。 BOSS 網(wǎng)管本地化需求已完成部分功能，監(jiān)控手段、維護流程得到進一步完善。 3、系統(tǒng)實施改造后， 不管是故障次數(shù)、故障影響業(yè)務(wù)時長均比上半年有了明顯下降。 文章主體（ 3000 字以上，可附在表格后）： 根據(jù)成果研究類別，主體內(nèi)容的要求有差異，具體要求見表格后的“填寫說明”。 文章主體： 一、項目簡介 （一）項目背景 在 市場 競爭 激烈 、 以客戶為導(dǎo)向的今天，業(yè)務(wù)的發(fā)展、市場的開拓和客戶滿意度的提升等方面對業(yè)務(wù)支撐系統(tǒng)提出了更高的要求。對中國移動廣西公司來說，提升系統(tǒng)的 可靠 性和可用性，構(gòu)建電信級的業(yè)務(wù)支撐網(wǎng)系統(tǒng)，已成為增強企業(yè)核心競爭力、提升客戶滿意度的重要手段。 BOSS 系統(tǒng)做為業(yè)務(wù)支撐網(wǎng)的核心系統(tǒng)， 系統(tǒng)龐大、架構(gòu)復(fù)雜， 自 BOSS1.5 上線以來，系統(tǒng)就一直受到穩(wěn)定性差， 故障頻發(fā)且 故障引發(fā)業(yè)務(wù)中斷時間長的困擾。本項目將 以科學(xué)的方法和手段 深入分析目前系統(tǒng)癥狀， 找出對策， 以 7X24 小時不間斷可用服務(wù)電信級 BOSS系統(tǒng)為目標，通過對系統(tǒng)逐步實施改造、優(yōu)化，逐漸 提高 BOSS 系統(tǒng)的 可靠性和可用性， 探討 如何持續(xù)漸進的 建設(shè)電信級的業(yè)務(wù)支撐系統(tǒng)的 思路 。 （二）項目實施過程 1、首先提出了電信級 BOSS 系統(tǒng)的定義 參照對電信級網(wǎng)絡(luò)的定義 ， 提出了電信級水平的 BOSS 系統(tǒng)的定義： 電信級 BOSS 系統(tǒng)可認為與電信級網(wǎng)絡(luò)相對應(yīng)，是以可運營為核心，提供 7X24 小時不間斷可用服務(wù)的業(yè)務(wù)支撐系統(tǒng)。應(yīng)具備以下特性： 高可用性（ Availability）： 可以提供長時間不中斷的、可用的服務(wù)； 高可管理性（ Serviceability）： 基于標準技術(shù)，可進行遠程的故障管理、性能管理、配置管理、安全管理； 高可擴展性（ Scalability）： 支持平滑單點容量上的擴展性和多點地域上的擴展性； 高安全性（ Security）： 具有較高的安全特性。 2、總體思路 在對電信級 BOSS 系統(tǒng)逐步認識和 探討 的基礎(chǔ)上， 提出建立相關(guān)科學(xué)的評估方法和模型， 通過 對 BOSS 系統(tǒng) 現(xiàn)狀分析、改造、完善 等階段逐步 向 電信級 水平 的 BOSS 系統(tǒng) 演進 ，進而提高 BOSS 系統(tǒng)的高可用性。 進而并把相關(guān)的方法、經(jīng)驗用于指導(dǎo)日后 BOSS 系統(tǒng)的滾動建設(shè)。 3、實施過程簡介 （ 1） 2007 年 4-5 月，提出電信級 BOSS 系統(tǒng)定義，探討、 建立相關(guān)科學(xué)的評估方法和模型，據(jù)此對 BOSS 系統(tǒng)現(xiàn)狀分析，從系統(tǒng)平臺、應(yīng)用系統(tǒng)、開發(fā)測試、日常維護管理等多個維度對目前的 BOSS 系統(tǒng)進行普查、分析，找出關(guān)鍵問題、缺陷所在。 （ 2） 2007 年 6-9 月， 根據(jù)分析出的問題、缺陷，結(jié)合現(xiàn)實條件，對已具備條件的，立即著手制定方案實施優(yōu)化改造；對還未具體條件 的，制定策略方案后續(xù)實施 ，完成第一階段系統(tǒng)平臺層面的實施改造。 通過 BOSS2.0 工程、客服系統(tǒng)網(wǎng)絡(luò)擴容改造工程、統(tǒng)一開通應(yīng)急、 CBOSS 應(yīng)急、二卡合一應(yīng)急等維護項目來重點完善原系統(tǒng)的設(shè)計缺陷，解決性能瓶頸、單點故障問題 ,提高故障反映和處理速度； 通過 BOSS 測試系統(tǒng)擴容改造工程，為 BOSS 應(yīng)用軟件的在軟件生命周期的各個階段開展提供基本的質(zhì)量保證。 加強了各工程的壓力測試和異常測試。 通過演練來不斷完善各子系統(tǒng)系統(tǒng)應(yīng)急預(yù)案，熟悉應(yīng)急流程，積累應(yīng)急經(jīng)驗。 加強監(jiān)控手段，完善維護流程。 建立了定期系統(tǒng)分析、維護機 制以及定期與集成商溝通交流機制。 完成了中間件在應(yīng)用級的動態(tài)均衡優(yōu)化測試，為下一步實施奠定基礎(chǔ)。 （ 3） 2007 年 10 11 月，實施應(yīng)用層面的優(yōu)化改造，實現(xiàn) BOSS 系統(tǒng)應(yīng)用的動態(tài)均衡負載，真正實現(xiàn)應(yīng)用的高可用性。 （三）項目創(chuàng)新性 1、首次提出了電信級水平的 BOSS 系統(tǒng)的概念和定義。 2、提出了 評估 電信級 BOSS 系統(tǒng)高可用性的 科學(xué)方法 。 3、提出了建設(shè)高可用性 BOSS 系統(tǒng)的思路 ， 用于指導(dǎo)對現(xiàn)有系統(tǒng)的改造和日后 BOSS 系統(tǒng)的滾動建設(shè)。 4、 提出 了 中間件在應(yīng)用 層面 的 真正做到 動態(tài)均衡優(yōu)化 的 解決方案。 （四）項目實 施效果 從 2007 年 4 月份開始實施，截止到 9 月底取得的效果： 1、系統(tǒng)平臺層面 營業(yè)系統(tǒng)：提升營業(yè)數(shù)據(jù)庫、中間件的處理能力，解決營業(yè)數(shù)據(jù)庫 RAC 在節(jié)點主機宕機時不能正常互為接管問題。 客服系統(tǒng)：完成了網(wǎng)絡(luò)優(yōu)化改造和客服數(shù)據(jù)庫單點故障改造。 帳務(wù)系統(tǒng)：提升帳務(wù)應(yīng)用、數(shù)據(jù)庫的處理能力，完成帳務(wù)數(shù)據(jù)庫單點故障改造。 計費系統(tǒng)：完成擴容提升計費系統(tǒng)的處理能力。 CBOSS：完成 BES 配置集群、建立 CBOSS 應(yīng)急系統(tǒng) 。 PRM/CHANNEL：完成從營業(yè)中間件分離出來，消除單點故障隱患。 結(jié)算系統(tǒng)：完成主機遷移提升系 統(tǒng)處理能力，消除單點故障隱患。 即開即通：配置了雙機，負載均衡，完成了全區(qū) BOSS 到 HLR 的備用路由的開通，通過路由切換腳本完成主備路由切換，主路由實現(xiàn)冗余，整個系統(tǒng)完成了消除單點故障的改造。 二卡合一：配置了雙機，負載均衡，消除消除單點故障。 2、維護管理層面 完善并演練了各子系統(tǒng)的應(yīng)急預(yù)案，其中做為核心系統(tǒng)的 營業(yè)系統(tǒng)的中間件在數(shù)據(jù)庫后臺之間的應(yīng)急方案切換速度由原來的 2 個 多小時縮短到 30 分鐘左右。 BOSS 網(wǎng)管本地化需求已完成部分功能，監(jiān)控手段、維護流程得到進一步完善。 3、系統(tǒng)實施改造后， 不管是故障次 數(shù)、故障影響業(yè)務(wù)時長均比上半年有了明顯下降。 二、項目詳細內(nèi)容 1、立項背景 在 市場 競爭 激烈 、 以客戶為導(dǎo)向的今天，業(yè)務(wù)的發(fā)展、市場的開拓和客戶滿意度的提升等方面對業(yè)務(wù)支撐系統(tǒng)提出了更高的要求。對中國移動廣西公司來說，提升系統(tǒng)的 可靠 性和可用性，構(gòu)建電信級的業(yè)務(wù)支撐網(wǎng)系統(tǒng)，已成為增強企業(yè)核心競爭力、提升客戶滿意度的重要手段。 BOSS 系統(tǒng)做為業(yè)務(wù)支撐網(wǎng)的核心系統(tǒng)， 系統(tǒng)龐大、架構(gòu)復(fù)雜， 自 BOSS1.5 上線以來，系統(tǒng)就一直受到穩(wěn)定性差， 故障頻發(fā)且 故障引發(fā)業(yè)務(wù)中斷時間長的困擾。 下圖為 2007 年上半年故障和投訴情 況統(tǒng)計： 2007 年 1 - 6 月 B O S S 系統(tǒng)故障統(tǒng)計12754525345106579563217024681 2 3 4 5 6月份次數(shù)0200400600800分鐘故障次數(shù) 故障時長月度批量投訴情況7512 231015861547170141669313330510152 0 0 7 年1 月 2 0 0 7 年2 月 2 0 0 7 年3 月 2 0 0 7 年4 月 2 0 0 7 年5 月 2 0 0 7 年6 月 2 0 0 7 年7 月0500100015002000批量投訴次數(shù) 批量投訴用戶數(shù) 可以看到： BOSS 系統(tǒng)穩(wěn)定性差、故障頻發(fā)且影響業(yè)務(wù)時間長。 上半年 BOSS 系統(tǒng)的故障主要集中在營業(yè)系統(tǒng)、二卡合一、 CBOSS 等關(guān)鍵系統(tǒng)上。 上半年， BOSS 系統(tǒng)出現(xiàn)不穩(wěn)定以及不同程度的退服情況，造成批量投訴情況發(fā)生的次數(shù)以及人數(shù)均有較大幅度的上升 。 本項目將 以科學(xué)的方法和手段 深入分析目前系統(tǒng)癥狀， 找出對策， 以 7X24 小時不間斷可用服務(wù)電信級 BOSS 系統(tǒng)為目標，通過對系統(tǒng)逐步實施改造、優(yōu)化，逐漸 提高 BOSS 系統(tǒng)的 可靠性和可用性， 探討 如何持續(xù)漸進的 建設(shè)電信級的業(yè)務(wù)支撐系統(tǒng)的 思路。 2、詳細 技術(shù) 內(nèi)容 項目目標： 提升 BOSS 系統(tǒng)的高可靠性和高可用性；探索如何持續(xù)漸進地向電信級水平的BOSS 系統(tǒng)演進 。 項目實施思路： 1、按業(yè)務(wù)關(guān)鍵程度進行梳理，從系統(tǒng)平臺、應(yīng)用系統(tǒng)、開發(fā)測試、日常維護管理等多個維度對目前的 BOSS 系統(tǒng)進行普查、分析，找出關(guān)鍵問題所在。 2、根據(jù)分析出的問題、缺陷，結(jié)合現(xiàn)實條件，對已具備條件的，立即著手制定方案實施優(yōu)化改造；對還未具體條件的，制定策略方案后續(xù)實施。 3、第一階段主要針對系統(tǒng)平臺層面進行優(yōu)化改造，重點解決解 決性能瓶頸、單點故障問題；制定應(yīng)急措施，完善應(yīng)急預(yù)案。 一、理論研究 提出了電信級水平的 BOSS系統(tǒng)的概念和定義及 對電信級 BOSS系統(tǒng)高可用性的評估方法和模型。 （一）電信級 BOSS 系統(tǒng) 參照對電信級網(wǎng)絡(luò)的定義， 電信級 BOSS 系統(tǒng)可認為與電信級網(wǎng)絡(luò)相對應(yīng)，是以可運營為核心，提供 7X24 小時不間斷可用服務(wù)的業(yè)務(wù)支撐系統(tǒng)。應(yīng)具備以下特性： 高可用性（ Availability）： 可以提供長時間不中斷的、可用的服務(wù)； 高可管理性（ Serviceability）： 基于標準技術(shù)，可進行遠程的故障管理、性能管理、配置管理 、安全管理； 高可擴展性（ Scalability）： 支持平滑單點容量上的擴展性和多點地域上的擴展性； 高安全性（ Security）： 具有較高的安全特性。 1、 可用性 可用性是一個統(tǒng)計概念，具體計算方法是： 系統(tǒng)可用性（ Availability） = MTBF/(MTBF+MTTR) 其中： MTBF 指平均無故障時間， MTTR 指平均故障修復(fù)時間。 高可用性對于業(yè)務(wù)支撐系統(tǒng)非常重要。具體體現(xiàn)為可長時間不間斷的提供服務(wù)。 設(shè)備的高可用性是設(shè)備軟硬件架構(gòu)和功能模塊可用性的綜合，主要影響對象包括：（ 1）硬件（ 2）操作系統(tǒng) （ 3）中間件（ 4）數(shù)據(jù)庫（ 5）應(yīng)用軟件。 系統(tǒng)的高可用性是通過高可用性組網(wǎng)技術(shù)實現(xiàn)。 2、 可管理性 可管理性對于運營商網(wǎng)絡(luò)至關(guān)重要。電信級網(wǎng)絡(luò)應(yīng)當提供符合中國移動標準接口和標準協(xié)議的遠程故障管理、性能管理、配置管理、安全管理等功能。電信級網(wǎng)絡(luò)中的網(wǎng)元設(shè)備應(yīng)支持開放標準管理接口連接集中網(wǎng)絡(luò)管理系統(tǒng)。 3、 可擴展性 設(shè)備應(yīng)支持設(shè)計規(guī)格范圍內(nèi)的線性擴展能力。在規(guī)格擴展范圍內(nèi)，系統(tǒng)性能不足時，可在縱向通過增加硬件模塊、軟件模塊擴展系統(tǒng)的處理能力，也可在橫向通過集群、 4 7 層交換等方式增加系統(tǒng)的可擴展性。 4、 安全性 系統(tǒng)安全性包括網(wǎng)絡(luò)安全、主機安全、操作系統(tǒng)安全、數(shù)據(jù)庫安全、應(yīng)用安全等等，電信級 BOSS 系統(tǒng)應(yīng)從組網(wǎng)和設(shè)備兩個層次對安全性進行要求，以保證電信級電信級 BOSS系統(tǒng)和設(shè)備在管理面、控制面和數(shù)據(jù)面的安全，并符合薩班斯法案的要求。 （二）、電信級 BOSS 系統(tǒng)可用性評估 評估方法重點用于對業(yè)務(wù)支撐系統(tǒng) 進行電信級評估，作為優(yōu)化系統(tǒng)結(jié)構(gòu)、提高系統(tǒng)可用性的基礎(chǔ)。 采用分層的方法對系統(tǒng)進行解析 、評估 ，針對每一層次分別進行分析和要求，再將低層次拼裝為高層次系統(tǒng)。支撐業(yè)務(wù) 系統(tǒng) 可按業(yè)務(wù)提供粒度劃分為 3 個層次 ,如圖 2-1 所示： 業(yè)務(wù)整體方案層 ：指整個 BOSS 系統(tǒng)在全區(qū)范圍內(nèi)的部署方案，包括各子系統(tǒng)節(jié)點間的邏輯路由策略、異地容災(zāi)保護等。 業(yè)務(wù)系統(tǒng)層 ：指能夠獨立完成某項業(yè)務(wù)的本地站點 ,以及業(yè)務(wù)系統(tǒng)內(nèi)部完成某類業(yè)務(wù)流程中一個獨立功能環(huán)節(jié)的軟硬件綜合體，如：營業(yè)系統(tǒng)、客服系統(tǒng)等。 物理設(shè)備層 ：業(yè)務(wù)系統(tǒng)內(nèi)部每一個有獨立物理封裝的設(shè)備、設(shè)備群及在設(shè)備上安裝的系統(tǒng)平臺軟件，如：主機、防火墻、雙機集群、 ORACLE RAC 等。 營 業(yè) 系 統(tǒng) 計 費 系 統(tǒng) 帳 務(wù) 系 統(tǒng) 客 服 系 統(tǒng)C B O S S業(yè) 務(wù) 系 統(tǒng) 層主 機 主 機交 換 機 交 換 機S A N 交 換 機S A N 交 換 機磁 盤 陣 列磁 盤 陣 列物 理 設(shè) 備 層防 火 墻 防 火 墻B O S S 系 統(tǒng)業(yè) 務(wù) 整 體 方 案 層圖 2-1 系統(tǒng)層次結(jié)構(gòu)圖 在電信級 BOSS 系統(tǒng)特征中， 最重要 的特征是可用性 。系統(tǒng)的整體可用性體現(xiàn)在系統(tǒng)從微觀到宏觀的多個層面，保證電信級 BOSS 系統(tǒng)需要對系統(tǒng)中各個層面進行全面評估。 采用自底向上的研究方法，分物理設(shè)備層、業(yè)務(wù)系統(tǒng)層和業(yè)務(wù)整體解決方案層三個層面，在各層定義不同粒度的可用性指標，分別進行建模，進而在此基礎(chǔ)上進行可用性綜合評估。 物理設(shè)備層： 從物理設(shè)備故障概率的角度分析可用性。 業(yè)務(wù)系統(tǒng)層：用隨機 Petri 網(wǎng)重點分析典型的邏輯系統(tǒng)：集群系統(tǒng)、雙機備份等，分別進行建模并進行定量分析。對于給定拓撲的業(yè)務(wù)系統(tǒng)，可通過業(yè)務(wù)流程和物理設(shè)備層、業(yè)務(wù)邏輯設(shè)備層的模型求 解，定量的對業(yè)務(wù)系統(tǒng)進行可用性分析，得到整個系統(tǒng)的平均無故障時間，評估響應(yīng)時延等指標。 業(yè)務(wù)整體 方案層 ： 主要涉及業(yè)務(wù)在各子系統(tǒng)節(jié)點間的邏輯路由策略、異地容災(zāi)保護等。 1、 可用性評估方法 （ 1）業(yè)務(wù)整體方案層可用性 系統(tǒng)的可靠性計算很大程度上取決于系統(tǒng)故障定義。系統(tǒng)故障定義不同，算法也不同。比如，系統(tǒng)中某些單元故障將導(dǎo)致整個系統(tǒng)癱瘓，而某些單元故障只會導(dǎo)致系統(tǒng)部分功能喪失。 根據(jù) Bellcore SR-TSY-001171 以及 TL9000 中的相關(guān)定義，系 統(tǒng)級故障基本可以分為兩大類： TSD(Total System Downtime)和 PSD(Partial System Downtime)。 計算系統(tǒng)的可靠性 /可用性指標主要是計算各個 Di（第 i 個單元的年中斷時間Downtime） 。 首先需要進行一個簡單的故障模式影響分析，以確定系統(tǒng)各組成單元中，哪些會引起系統(tǒng) TSD，哪些會引起 PSD。然后主要的任務(wù)就是計算這些單元的 Di。 根據(jù)上面提供的故障定義，明確對 BOSS 系統(tǒng)可用性指標的定義。將整個系統(tǒng)的各種故障分別列出，然后根據(jù)故障的影響分別計算出單個故障的 Di。 參照通信設(shè)備業(yè)界網(wǎng)上運行數(shù)據(jù)統(tǒng)計方法標準 TL9000，對 于 BOSS 系統(tǒng) 的可靠性指標，采用如下的統(tǒng)計方法： SDTDTniii1)P( 其中： DT 整個 系統(tǒng) 的年中斷時間； iDT 第 i 個 節(jié)點 的年中斷時間； iP 第 i 個 節(jié)點 故障所影響容量； S 整個 系統(tǒng) 的總?cè)萘浚?n系統(tǒng) 中設(shè)備的臺數(shù)。 （ 2）業(yè)務(wù)系統(tǒng)層可用性 由業(yè)務(wù)邏輯設(shè)備組成高可用性的業(yè)務(wù)系統(tǒng)，主要是減少業(yè)務(wù)邏輯間的耦合性， 增加冗余業(yè)務(wù)流程來實現(xiàn)，使得某個業(yè)務(wù)邏輯設(shè)備的單點故障不影響其它業(yè)務(wù)邏輯的功能，業(yè)務(wù)網(wǎng)邏輯設(shè)備的切換不影響其它業(yè)務(wù)邏輯。 在業(yè)務(wù)系統(tǒng)的設(shè)計中，應(yīng)充分考慮增加串行業(yè)務(wù)流程的冗余度的同時，降低業(yè)務(wù)邏輯間的耦合性，以保證整個業(yè)務(wù)系統(tǒng)的高可用性。 圖 2-2 見圖 2-2 所示，在業(yè)務(wù)流程中，至少存在一條冗余業(yè)務(wù)鏈路，當主業(yè)務(wù)流程出現(xiàn)故障時（如 A1B1C1） ,業(yè)務(wù)能自動切換到備用業(yè)務(wù)流程： A2B2C2，并且要求此切換對客戶是透明的。 存在雙機切換的設(shè)備應(yīng)該 避免直接串聯(lián)，而通過中間的非雙機切換設(shè)備來進行故障隔離或交叉連接來實現(xiàn)故障隔離，減少業(yè)務(wù)網(wǎng)邏輯設(shè)備間的耦合，任何業(yè)務(wù)部件的故障切換，都不會引起其它業(yè)務(wù)邏輯的切換。而主業(yè)務(wù)流程中任何一個業(yè)務(wù)邏輯的故障，使其它業(yè)務(wù)流程也進行切換，從而整個業(yè)務(wù)流程從主業(yè)務(wù)流程切換到備業(yè)務(wù)流程，若每業(yè)務(wù)流程主備切換成功率為 90，則整個業(yè)務(wù)流程切換成功率為： 0.9*0.9*0.9=0.729，業(yè)務(wù)可靠性大大降低。 （ 3）物理設(shè)備層可用性 各層面可用性最終體現(xiàn)到物理設(shè)備可用性指標的獲取，物理設(shè)備可用性評估是電信級BOSS 系統(tǒng)可用性研 究的基礎(chǔ)。 設(shè)備層分為硬件和軟件兩部分，軟硬件可用性在特性上具有很大差別： 物理退化。軟件不存在物理退化現(xiàn)象，硬件失效則主要由于物理退化所致。這就決定了軟件正確性與軟件可靠性密切相關(guān)，一個正確的軟件任何時刻均可靠。然而一個正確的硬件元器件或系統(tǒng)則可能在某個時刻失效； 復(fù)雜性。軟件內(nèi)部邏輯高度復(fù)雜，而硬件設(shè)備間的內(nèi)部邏輯較為簡單，這就在很大程度上決定了設(shè)計錯誤是導(dǎo)致軟件失效的主要原因，而導(dǎo)致硬件失效的可能性則相對很小。 唯一性。軟件是唯一的，軟件拷貝不改變軟件本身，而任何兩個硬件不可能絕對相同，概率方法更適合 應(yīng)用于硬件可靠性預(yù)測。 由于上述種種原因，軟件可靠性比硬件可靠性更難保證。 綜合考慮軟件失效和硬件失效，則系統(tǒng)可用度計算公式為： ni 1 AAA 軟件硬件系統(tǒng) 串聯(lián)部分可用性 設(shè)備的可用性度量包括可用性評估和可用性預(yù)測。 可用性評估指收集整理系統(tǒng)測試和系統(tǒng)運行期間得到的失效數(shù)據(jù)，并進行統(tǒng)計推理，斷定系統(tǒng)當前的可用性。它是對從過去到當前點所得到的可用性的度量。其主要目的是評價當前可用性，并確定一個可用性模型是否為回溯的正確依據(jù)。 可用性預(yù)測指利用可知的任何軟件度量與規(guī)程確定未來軟件的可用性。 單一廠家提供的 設(shè)備通常提供整個設(shè)備的可用度，可以以該數(shù)據(jù)作為可用性預(yù)測的依據(jù)，并在系統(tǒng)上線運行后對其故障情況進行統(tǒng)計，并根據(jù)統(tǒng)計數(shù)據(jù)進行可用性評估；對于軟硬件由不同廠家提供的設(shè)備，則需要分別對其可用性進行預(yù)測和統(tǒng)計。 硬件可用性 硬件的故障往往由于物理 (包括化學(xué) ) 的機制所致 , 因而描述硬件可靠性的模型比較單一 , 硬件失效率符合浴盆曲線。 硬件可用性可通過可用度或年 停機時間 表示： 可 用度M T T RM T BFM T BFA 年 停機時間 Downtime 8760 60 (1-A) mins/yr。 MTBF 預(yù) 測方法 目前業(yè)界對于硬件 MTBF 的預(yù)測可以通過分析器件可用性、單元（如板卡）可用性以及系統(tǒng)可用性（如冗余設(shè)計中的備份關(guān)系）得到整個硬件設(shè)備的可用性指標。 MTBF 為失效率的倒數(shù)： MTBF=1/失效率； 其中： 失效率 是單位時間內(nèi)設(shè)備的失效數(shù)占該時間段開始時正常工作設(shè)備總數(shù)的比值。它反映的是設(shè)備發(fā)生失效的相對速率即故障瞬時強度 串聯(lián)結(jié)構(gòu)的失效率是各單元失效率的累加； 并聯(lián)（冗余系統(tǒng)）的失效率采用可修產(chǎn)品的馬爾可夫模型計算。 一般電子設(shè)備的失效率 都遵循浴盆曲線規(guī)律，如圖 2-3 所示 ： 圖 2-3 浴盆曲線 MTTR預(yù)測方法 因設(shè)備的應(yīng)用場景不同，維護方式不同，預(yù)計值或者經(jīng)驗值都僅是一個參考，如可以參考 BELLCORE GR 512，根據(jù)業(yè)界情況設(shè)定 MTTR。 表 2-1 GR 512 推薦的 MTTR Site Classification On-site repair time (hours) Dispatch time (hour) Total Service Restoral time (hours) Attended site 1 2 3 Unattended site 1 3 4 在系統(tǒng)招標時，廠 家應(yīng)承諾 MTTR 時間，在可用性評估時，以此事件為準。 軟件可用性 目前業(yè)界軟件可靠性預(yù)計方法還不成熟，軟件可用性的高低很大程度上取決于軟件生產(chǎn)過程中開發(fā)流程和質(zhì)量管理體系，可以通過對廠家軟件開發(fā)流程和質(zhì)量管理體系的檢查、評估對其軟件產(chǎn)品的可用性進行判斷，以作為系統(tǒng)割接入網(wǎng)的依據(jù)。 軟件可用性預(yù)計和 評估 軟件可用性度量包括可靠性評估和可靠性預(yù)測。 可靠性評估指收集整理系統(tǒng)測試和系統(tǒng)運行期間得到的失效數(shù)據(jù)，并進行統(tǒng)計推理，斷定系統(tǒng)當前的軟件可靠性。它是對從過去到當前點所得到的可靠性的度量。其主要目的是評價當前可靠性，并確定一個可靠性模型是否為回溯的正確依據(jù)。 可靠性預(yù)測指利用可知的任何軟件度量與規(guī)程確定未來軟件的可靠性?？煽啃灶I(lǐng)域中習(xí)慣將可靠性預(yù)測稱為可靠性預(yù)計。 軟件可靠性術(shù)語 軟件可靠性領(lǐng)域的術(shù)語定義，主要有： 軟件錯誤（ Software Error）：指在軟件生存期間內(nèi)的不希望或不可接受的人為的錯誤，其結(jié)果導(dǎo)致軟件缺陷的產(chǎn)生，是一種人為的過程，相對于軟件本身來說是一種外部行為。比如，將求平均值當作求最大值，和將輸出電壓值當作輸出電流值等都是軟件錯誤。 軟件缺陷（ Software Defect）： 是存在于軟件之中的那些不希望或不可接受的偏差，其結(jié)果是軟件運行于某一特定的條件時出現(xiàn)軟件故障，這時稱軟件缺陷被激活。以靜態(tài)形式存在于軟件內(nèi)部。比如，少一個逗號、多一條語句等都是軟件缺陷。當軟件意指程序時，軟件缺陷與軟件 bug 同義。 軟件故障（ Software Fault）：是指軟件運行過程中出現(xiàn)的一種不希望或不可接受的內(nèi)部狀態(tài)，可能引起一個功能部件不能完成所要求的功能的一種意外情況，若故障不加處理，便可能產(chǎn)生失效，是一個動態(tài)行為。比如，軟件處于執(zhí)行一個多余循環(huán)過程時就是一個軟件故障。 軟件失效（ Software Failure）：軟件運行時產(chǎn)生的一種不希望或不可接受的外部行為結(jié)果，也就是表現(xiàn)出的功能與用戶需求不一致，功能部件執(zhí)行其規(guī)定功能的能力終止，用戶無法完成所需要的應(yīng)用。 它們的關(guān)系如下：軟件錯誤 軟件缺陷 軟件故障 軟件失效。軟件失效是最終表現(xiàn)在用戶面前的結(jié)果。 軟件開發(fā)流程保證 軟件可靠性數(shù)據(jù)是可靠性評估的基礎(chǔ)。 要進行有效的軟件可靠性評估，首先必須 建立軟件錯誤報告、分析與糾正措施系統(tǒng)。按照相關(guān)標準的要求，制定和實施軟件錯誤報告和可靠性數(shù)據(jù)收集、保存、分析和處理的規(guī)程，完整、準確地記錄軟 件測試階段的軟件錯誤報告和收集可靠性數(shù)據(jù)。 如何提高軟件可靠性 軟件與硬件不同 , 不會因多次使用而發(fā)生失效 ， 軟件的故障不是由于物理機制所造成的 , 軟件不存在故障率呈增長趨勢的耗損故障期 , 軟件的缺陷 解決 一個就減少一個。 軟件開發(fā)周期錯誤和軟件故障分類的百分數(shù)分別如表 2-2 和表 2-2 所示。 表 2-1 軟件開發(fā)周期各階段錯誤的百分比 軟件開發(fā)周期各階段 需求分析 設(shè)計 編碼與單元測試 綜合測試 運行與維護 錯誤百分比（ %） 55 17 13 10 5 表 2-2 軟件故障分類的百分比 故障分類 需求變化 邏輯設(shè)計 數(shù)據(jù) 相互 環(huán)境 人的因素 計算 文件提供 其他 故障分類百分比（ %） 36 28 6 6 5 5 5 2 7 由表 2-1、表 2-2 的統(tǒng)計數(shù)據(jù)表明，在軟件生命周期的各個階段都會可能發(fā)生軟件錯誤或故障， 為了保證軟件的可靠性，應(yīng)在軟件生命周期的各個階段千方百計地減少缺陷。同時，統(tǒng)計數(shù)據(jù)也表明，軟件錯誤的修改費用也是越晚越高的。 一個好的軟件開發(fā)流程可以提高軟件開發(fā)團隊的工作效率，控制開發(fā)過程中的風(fēng)險，保證軟件開發(fā)進度并且提高軟件產(chǎn)品質(zhì)量 。 為保證軟件的可靠性，應(yīng)該在軟件生命周期的各個階段開展各項基本 的質(zhì)量保證活動，以減少缺陷。 （三）建設(shè)高可用性 BOSS 系統(tǒng)的思路 BOSS 系統(tǒng)龐大而復(fù)雜，子 系統(tǒng) 繁多 。 根據(jù)以上的幾個層面的分析，我們要建設(shè)高可用的電信級 BOSS 系統(tǒng)， 須要從物理設(shè)備層、業(yè)務(wù)邏輯層、系統(tǒng)整體 3 個方向進行設(shè)計考慮。 1、 物理設(shè)備層面的設(shè)計 物理設(shè)備層是系統(tǒng)可用性的最基本保障，因此，在考慮建設(shè) 高可用的電信級的 BOSS 系統(tǒng)時，必須首先在物理層面保障系統(tǒng)的高可用性，消除單點故障，這里主要包括硬件和軟件兩個方面。 （ 1） 硬件方面： 主要從以下幾個方面考慮： 對于關(guān)鍵的業(yè)務(wù)系統(tǒng)，服務(wù)器主機方面必須考慮雙 機集群，以滿足系統(tǒng)基本的高可用性條件。目前主流的小型機設(shè)備供應(yīng)商 IBM、 HP、 SUN 等都有相應(yīng)的高可用性 HA（ High Availability）解決方案，其根本原則就是提供硬件設(shè)備的高可用性，即：在其中一臺設(shè)備失效的情況下，另一臺設(shè)備能自動接管原有的業(yè)務(wù)，以保持業(yè)務(wù)的連續(xù)性。 對于物理網(wǎng)絡(luò)結(jié)構(gòu)，必須提供備用的網(wǎng)絡(luò)路由鏈路， 包括備用的網(wǎng)絡(luò)設(shè)備（路由器、交換機、防火墻等）和傳輸電路等。 對于底層的數(shù)據(jù)庫，也要考慮冗余備份。數(shù)據(jù)庫存放的是業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，是所有系統(tǒng)正常運行的基礎(chǔ)，因此必須考慮實現(xiàn) 2 個或以上的數(shù)據(jù) 庫實例以提供數(shù)據(jù)庫的高可用性。目前主流的數(shù)據(jù)庫產(chǎn)品提供商都有相應(yīng)的 HA 解決方案，如： ORACLE 的RAC 等。 在設(shè)備選型時， 需要大到 電信級網(wǎng)絡(luò)設(shè)備指標標準 (設(shè)備要求分 冊 )要求，同時由于 UNIX 系統(tǒng)在可靠性、穩(wěn)定性、抗病毒攻擊等方面都比 WINDOWS 具有先天性的優(yōu)勢，而目前低端 UNIX 服務(wù)器價格已接近相同性能的 PC SERVER，因此在 BOSS 這樣的關(guān)鍵業(yè)務(wù)支撐系統(tǒng)里，應(yīng)盡量考慮使用 UNIX SERVER 而不是 PC SERVER。 （ 2） 軟件方面： 對于一個高可用性的 BOSS 系統(tǒng)，有了冗余的硬件設(shè)計 只是最基本的設(shè)計要求，軟件方面（系統(tǒng)軟件和應(yīng)用軟件）則更為重要。沒有軟件的冗余設(shè)計，那么從業(yè)務(wù)系統(tǒng)來說是不具備高可用性條件的。 對于系統(tǒng)軟件，在 BOSS 系統(tǒng)里最重要的是中間件。出于 BOSS 業(yè)務(wù)的關(guān)鍵性，在選擇中間件軟件時必須考慮產(chǎn)品的成熟性，以直接提升 BOSS 系統(tǒng)的高可靠性。 對于應(yīng)用軟件，與硬件不同 , 不會因多次使用而發(fā)生失效，軟件的故障不是由于物理機制所造成的 , 軟件不存在故障率呈增長趨勢的耗損故障期 , 軟件的缺陷解決一個就減少一個。因此， 為保證軟件的可靠性，應(yīng)該在軟件生命周期的各個階段開展各項基本的質(zhì) 量保證活動，以減少缺陷。 2、 業(yè)務(wù)系統(tǒng)層的設(shè)計 物理設(shè)備層滿足高可用性的條件后，只是在底層平臺給予了系統(tǒng)高可靠性的條件，而業(yè)務(wù)系統(tǒng)層實現(xiàn)高可用性是系統(tǒng)具有高可用性的重要保障。為保證系統(tǒng)的高可用性，在業(yè)務(wù)系統(tǒng)的設(shè)計中，應(yīng)從以下幾個方面考慮： 充分考慮增加串行業(yè)務(wù)流程的冗余度的同時，降低業(yè)務(wù)邏輯間的耦合性，減少各子系統(tǒng)互相影響的深度，以保證整個業(yè)務(wù)系統(tǒng)的高可用性。 必須考慮各應(yīng)用子系統(tǒng)的自動切換機制的實現(xiàn)。在中間件、應(yīng)用系統(tǒng)等方面，應(yīng)該在系統(tǒng)設(shè)計階段和底層系統(tǒng)物理設(shè)備平臺結(jié)合起來一起考慮各子系統(tǒng)的自動切換和回切 機制。在這個層面，可通過自行開發(fā)或借助第三方的軟件或硬件來實現(xiàn)，如：四 /七 層交換機等。 3、 業(yè)務(wù)整體解決方案層的設(shè)計 建設(shè)電信級的 BOSS 系統(tǒng)，還需在業(yè)務(wù)的整體解決方案層進行相應(yīng)的設(shè)計考慮，主要包括： 系統(tǒng)設(shè)計時需考慮各子系統(tǒng)的路由策略，通過冗余設(shè)計避免出現(xiàn)一個子系統(tǒng)失效而整個系統(tǒng)失效的情況發(fā)生； 考慮建設(shè)系統(tǒng)的異地容災(zāi)系統(tǒng)，分析業(yè)務(wù)的關(guān)鍵程度，并根據(jù)各子系統(tǒng)不同的等級來實現(xiàn)系統(tǒng)的數(shù)據(jù)級容災(zāi)和應(yīng)用級容災(zāi)。 建立各子系統(tǒng)的應(yīng)急方案。容災(zāi)系統(tǒng)是在“災(zāi)難時刻”才啟用的，而應(yīng)急方案是解決臨時問題而啟用的，其目的是更 快速的保障業(yè)務(wù)應(yīng)用的連續(xù)性。 建立完善的網(wǎng)管系統(tǒng)，對各個網(wǎng)元進行實時監(jiān)控，并對異常情況及時通過短信、郵件、聲音等方式報警。 明確維護指標，完善系統(tǒng)維護流程，按 ITIL 的方法論，嚴格執(zhí)行事件管理、問題管理、變更管理、配置管理等流程。 二、項目具體實施 （一） 實施思路 通過 BOSS 系統(tǒng)現(xiàn)狀普查分析、改造優(yōu)化、評估完善等階段逐步向電信級水平的 BOSS系統(tǒng)演進，進而提高 BOSS 系統(tǒng)的高可用性。 1、 普查分析階段 對現(xiàn)有 BOSS 系統(tǒng)軟、硬件可用性情況逐一進行普查、分析，確定制約系統(tǒng)可靠性的短板、缺陷、單點故障隱患， 制定下一階段性目標等。 2、 改造優(yōu)化階段 根據(jù)不同系統(tǒng)的發(fā)展范圍、用戶總數(shù)、經(jīng)濟受益和社會影響力等因素，將系統(tǒng)分為關(guān)鍵系統(tǒng)、一般系統(tǒng)兩類，據(jù)此確定各系統(tǒng)整改的優(yōu)先級別， 結(jié)合具體改造代價： 對于有現(xiàn)實條件的，開始實施改造； 對于目前受條件限制的，提出改造方案，并在后續(xù)落實。 3、 評估完善階段 根據(jù)上面的 可用性評估方法或軟件后評估體系進行階段性的評估、總結(jié)，提出完善方案，持續(xù)進行整改。 （二） BOSS 系統(tǒng)現(xiàn)狀分析 從系統(tǒng)平臺、應(yīng)用系統(tǒng)、開發(fā)測試環(huán)境、日常維護管理等多個維度對目前的 BOSS 系統(tǒng)進行普查、分析，針對 業(yè)務(wù)關(guān)鍵程度進行梳理。 1、 總體框架 下面是 2004 2007 年廣西移動 BOSS 系統(tǒng)的發(fā)展過程： 時間 2004 2005 2006 2007 BOSS 系統(tǒng) 1.0 1.5 2.0 用戶規(guī)模（萬） 800 1000 1300 目前 BOSS 系統(tǒng)存在以下兩個主要特點： （ 1）技術(shù)：網(wǎng)元較多、標準復(fù)雜、發(fā)展較快 包括主機 /操作系統(tǒng)、存儲、網(wǎng)絡(luò) /安全、數(shù)據(jù)庫、中間件、應(yīng)用軟件。 （ 2）架構(gòu)：架構(gòu)復(fù)雜、功能繁多、數(shù)據(jù)海量 業(yè)務(wù)支撐系統(tǒng)主要包括：營業(yè)系統(tǒng)、計費系統(tǒng)、帳務(wù)系統(tǒng)、客服系統(tǒng)、結(jié)算系統(tǒng)、 CBOSS等等 。 2、 系統(tǒng)平臺 （ 1） 主機 通過普查分析，發(fā)現(xiàn)目前系統(tǒng)主要存在性能不足、單點故障等隱患，或者 硬件已具備冗余條件，但應(yīng)用系統(tǒng)不具備自動切換的條件，雖然在某些環(huán)節(jié)上實現(xiàn)了高可用性，但系統(tǒng)整體上實際還達不到高可用性的要求 。 系統(tǒng) 網(wǎng)元 配置 說明 營業(yè) 營 業(yè) 數(shù)據(jù) 庫節(jié)點 1 IBM P690(32CPU,128G 內(nèi)存 ) cpu/內(nèi)存利用率高，單臺主機不能支撐全部數(shù)據(jù)庫功能，實際上單點故障仍然存在 營 業(yè) 數(shù)據(jù) 庫節(jié)點 2 IBM P690(32CPU,128G 內(nèi)存 ) 營業(yè)中間件 1 IBM P690 分區(qū) (12CPU,48G內(nèi)存 ) 中間件與多個后臺應(yīng)用（如工單調(diào)度）部署在一起，性能不足，特別是內(nèi)存 /交換區(qū)經(jīng)常告警。 應(yīng)用不具備自動切換能力，實際上單點故障仍然存在。 營業(yè)中間件 2 IBM P690 分區(qū) (12CPU,44G內(nèi)存 ) 營業(yè)中間件 3 IBM P690 分區(qū) (8CPU,64G內(nèi)存 ) 應(yīng)急數(shù)據(jù)庫 IBM P690 分區(qū) (12CPU,40G內(nèi)存 ) 同時在運行客服應(yīng)急庫，性能不足影響數(shù)據(jù)庫復(fù)制 客服 客服數(shù)據(jù)庫 IBM P690 分區(qū) (12CPU,34G內(nèi)存 ) 1、單點故障隱患 2、網(wǎng)卡沒有配 成 Etherchannel 無線營業(yè)廳 IBM P650(8CPU,32G 內(nèi)存 ) 1、單點故障隱患 2、應(yīng)用不具備自動切換能力。 綜 合 客服 后臺 IBM P650(8CPU,64G 內(nèi)存 ) 計費 計費應(yīng)用 1 IBM P690 分區(qū) (12CPU,35G內(nèi)存 ) 1、單臺主機不能支撐全部計費應(yīng)用功能 2、應(yīng)用不具備自動切換能力。 計 費 應(yīng)用 2（ MDB） IBM P690 分區(qū) (12CPU,47G內(nèi)存 ) 計費數(shù)據(jù)庫 1 IBM P690 分區(qū) (8CPU,22G內(nèi)存 ) 1、單臺主機不能支撐全部數(shù)據(jù)庫 功能 2、網(wǎng)卡沒有配成 Etherchannel 計費數(shù)據(jù)庫 2 IBM P690 分區(qū) (8CPU,28G內(nèi)存 ) 帳務(wù) 帳務(wù)數(shù)據(jù)庫 IBM P690 分區(qū) (8CPU,20G內(nèi)存 ) 單點故障隱患 帳 務(wù) 應(yīng)用 1（ MDB) IBM P690 分區(qū) (12CPU,55G內(nèi)存 ) 1、單臺主機不能支撐全部帳務(wù)應(yīng)用功能 2、應(yīng)用不具備自動切換能力。 帳務(wù)應(yīng)用 2 IBM P690 分區(qū) (12CPU,35G內(nèi)存 ) CBOSS cboss 應(yīng)用 IBM P650(8CPU,48G 內(nèi)存 ) 1、單臺主機不能支撐全部帳務(wù) 應(yīng)用功能 2、應(yīng)用不具備自動切換能力。 3、網(wǎng)卡沒有配成 Etherchannel cboss數(shù)據(jù)庫 IBM P650(6CPU,12G 內(nèi)存 ) PRM CHANNEL PRM/CHANNEL IBM P650(8CPU,32G 內(nèi)存 ) 與無線營業(yè)廳共用一臺主機，單點故障隱患 結(jié)算 結(jié)算應(yīng)用 IBM P670(8CPU,48G 內(nèi)存 ) 性能不足，單點故障隱患 結(jié)算數(shù)據(jù)庫 IBM M85(6CPU,6G 內(nèi)存 ) 性能不足，單點故障隱患 （ 2） 數(shù)據(jù)庫 以營業(yè)數(shù)據(jù)庫為例， 營業(yè)數(shù)據(jù)庫做為整個 BOSS 系統(tǒng)的核心數(shù)據(jù)庫，現(xiàn)狀如下： 數(shù)據(jù)庫運行情況 數(shù)據(jù)規(guī)模：規(guī)模從 2005 年底 1.8T 發(fā)展至 2007 年上半年 6.8T 系統(tǒng)備份：全庫備份從 2005 年底 3.5 小時發(fā)展至 2007 年底 8小時 存在問題及風(fēng)險 數(shù)據(jù)庫表空間不能循環(huán)使用，歷史工單數(shù)據(jù)保留時間過長導(dǎo)致數(shù)據(jù)庫增長過大。 數(shù)據(jù)庫數(shù)據(jù)規(guī)模增大，導(dǎo)致系統(tǒng)備份及后臺事務(wù)時間窗增長； 數(shù)據(jù)庫內(nèi)單表記錄數(shù)增大， 表和索引存在大量的碎片沒有及時分析整理 ,數(shù)據(jù)處理效率降低，造成查詢統(tǒng)計速度變慢，數(shù)據(jù)修改操作爭用情況加??； 業(yè)務(wù)高峰期，業(yè)務(wù)請求對資源的爭用導(dǎo)致系統(tǒng)抗風(fēng)險 能力降低，表現(xiàn)為系統(tǒng)速度變慢，故障增多，對表的維護操作時間增長。 數(shù)據(jù)表、索引數(shù)量不斷增加，增加維護管理難度及應(yīng)用復(fù)雜度。 單個節(jié)點主機宕機時另外一個節(jié)點不能正常接管數(shù)據(jù)庫。 3、 網(wǎng)絡(luò) 客服座席到客服系統(tǒng)、 BOSS 系統(tǒng)的網(wǎng)絡(luò)鏈路，是 2 條 10*2M，總帶寬是 20M（ 2 條鏈路是主、備關(guān)系）。自 07 年 2 月客服擴容改造之后，客服座席的網(wǎng)絡(luò)流量增大，平時的鏈路帶寬均值在 15Mbps 左右，高峰時達到鏈路速率的限制，出現(xiàn)了客服座席業(yè)務(wù)響應(yīng)遲緩、數(shù)據(jù)丟失等故障現(xiàn)象。 圖 3-1 客服座席網(wǎng)絡(luò)拓撲 4、應(yīng)用系統(tǒng) （ 1）即開 即通 接口主機存在單點故障；沒有備份路由； 出現(xiàn)網(wǎng)絡(luò)故障時 人工干預(yù)太多，發(fā)生故障時自動化程度太低，存在無法快速處理的風(fēng)險 。 （ 2）一級 BOSS（ CBOSS） 缺乏監(jiān)控手段； 接口表記錄太多導(dǎo)致一級 BOSS 接口處理不及時 ； 一級 BOSS 接口上發(fā)緩慢 ；用戶狀態(tài)、定購關(guān)系 目前只能通過第二天凌晨集團下發(fā)的錯單文件進行檢查。要實現(xiàn)實時監(jiān)控，只能在組包上傳的時候判斷每個號碼是否智能網(wǎng)號碼，對系統(tǒng)資源消耗較大 。 （ 3）二卡合一 由于 BOSS 側(cè)作為服務(wù)端，一旦要進行切換，必須要智能網(wǎng)一側(cè)修改指向 IP 地址 。 5、開發(fā)、測試環(huán)境 設(shè) 備 數(shù)量 配置 使用說明 IBM P650 1 IBM P650， 8CPU(1.45G)， 32GRAM，2GE， 2FE， 2FC， 2*73GHdisk 測試數(shù)據(jù)庫 IBM P570 1 IBM P570， 4CPU(1.45G)， 32GRAM，2GE， 2FE， 2FC， 2*73GHdisk 應(yīng)用測試 設(shè) 備 數(shù)量 配置 使用說明 IBM S7A 1 IBM S7A， 12CPU(226MHz)，12GRAM， 1GE， 2FE， 2*9.1GHdisk 開發(fā)、源碼編譯 IBM S7A 1 IBM S7A， 12CPU(226MHz)，12GRAM， 1GE， 2FE， 2*9.1GHdisk，1*18.2GHdisk 開發(fā)、源碼編譯 BOSS 系統(tǒng)目前 開發(fā)環(huán)境 所用的兩 臺 IBM S7A主機 為 2002 年 BOSS 集中化工程建設(shè)的時候所購 ， 年代久遠，設(shè)備陳舊， CPU 時鐘頻率太低，且生產(chǎn)廠家已不對其提供技術(shù)升級和板卡替換，造成性能無法提升，已不能 可以滿足源碼的開發(fā)和編譯。 BOSS 系統(tǒng) 測試環(huán)境 所用的 機器 設(shè)備 配置（ CPU/內(nèi)存） 較 低，部分測試不能做全區(qū)數(shù)據(jù)的測試，如帳務(wù) MDB、計費 MDB 等需要大內(nèi)存的環(huán)境 ，常常要借助部分生產(chǎn)環(huán)境來兼做測試，影響了生產(chǎn)環(huán)境的使用 。 同 時環(huán)境過于集中，不利于開展測試、管理、配置、變更和維護， 嚴重影響應(yīng)用開發(fā)測試的進度和測試質(zhì)量 ，進而影響到 BOSS 系統(tǒng)應(yīng)用割接上線的質(zhì)量和系統(tǒng)穩(wěn)定性 。 應(yīng)用程序在上線前缺乏嚴謹?shù)臏y試計劃，除了 功能測試外，缺乏各種異常測試、壓力測試。 6、 維護管理 在維護管理方面主要存在下列問題： （ 1）維護指標不明確。 如對每個子系統(tǒng)的維護指標是什么？可用性要求是什么？ （ 2） 維護流程、應(yīng)用上線控制不夠規(guī)范，未能很好執(zhí)行事件管理、問題管理、變更管理、配置管理等流程。 未能充分充分利用 BOSS 網(wǎng)管的監(jiān)控、告警功能。 （ 3）沒有 定期維護窗口，沒有建立定期維護系統(tǒng)的機制。 （ 4）應(yīng)急措施不力：應(yīng)急方案沒有經(jīng)過演練來驗證；系統(tǒng)平臺或應(yīng)用更改后沒有及時對應(yīng)急方案進行變更；做為核心系統(tǒng)的營業(yè)系統(tǒng)的在實施應(yīng)急措施進行應(yīng)用切換時，時間長（ 2 3 小時）。 （ 5）關(guān)鍵系統(tǒng)主機維護控制臺放在機房，未能延伸至亞航辦公室，導(dǎo)致主機宕機重啟處理時間過長。 （三）具體措施 現(xiàn)階段主要針對系統(tǒng)平臺層面進行優(yōu)化改造， 通過 2007 年 BOSS2.0 擴容改造工程、客服系統(tǒng)網(wǎng)絡(luò)擴容改造工程 、建立應(yīng)急系統(tǒng)等措施來 重點完善原系統(tǒng)的設(shè)計缺陷，解決性能瓶頸、單點故障問題。 重 點解決解決性能瓶頸、單點故障問題；制定應(yīng)急措施，完善應(yīng)急預(yù)案，減短故障處理時長、提高系統(tǒng)穩(wěn)定性。 1、措施一：系統(tǒng)平臺改造 （ 1）即開即通系統(tǒng) 增加一臺主機，負載均衡互為備份； 網(wǎng)絡(luò)改造增加備用路由。 通過腳本實現(xiàn)切換備用路由，并移交監(jiān)控室進行實時監(jiān)控和切換，保障在第一時間及時發(fā)現(xiàn)路由問題并加快備用路由切換速度 ,從而提高開機及時率。 （ 2）一級 BOSS（ CBOSS） 地 市 公 司B O S S網(wǎng) 絡(luò)營 業(yè) 數(shù) 據(jù) 庫1 0 . 1 8 2 . 1 1 . 1 3 5（ 營 業(yè) 中 間 件3）1 0 . 1 8 2 . 1 1 . 1 3 3（ 營 業(yè) 中 間 件2）1 0 . 1 8 2 . 1 1 . 1 3 1（ 營 業(yè) 中 間 件1）1 0 . 1 8 2 . 1 4 . 8 3(路 由 器)1 0 . 1 8 2 . 2 5 1 . 2 5 4（ 二 樞 紐 ）1 0 . 1 8 2 . 1 1 1 . 1 9 7（ 白 沙 ）網(wǎng)運傳輸線路N N H L R 1 N N H L R 2 B H H L R 2 監(jiān) 控 發(fā) 現(xiàn) 網(wǎng) 元 斷 連切 換 備 用 路 由1 0 . 1 8 2 . 1 1 . 1 4 71 0 . 1 8 2 . 1 4 . 3外 省 一 級 B O S S 系 統(tǒng)1 0 . 1 8 2 . 1 1 . 1 4 3( 一 級 B O S S 數(shù) 據(jù) 庫 )1 0 . 1 8 2 . 1 1 . 1 4 1( 一 級 B O S S 應(yīng) 用 )營 業(yè) 庫計 費 庫S N 路 由 器 1S N 路 由 器 2集 團 公 司 交 換 中 心1 0 . 1 8 2 . 1 1 . 2 9( 一 級 B O S S 應(yīng) 急 數(shù) 據(jù) 庫 ) 加強監(jiān)控手段； 建立基于 BES 服務(wù)的 PARTITION 集群。 建立 CBOSS 應(yīng)急系統(tǒng)。 更換 CBOSS 應(yīng)用為多后臺進程版本，實現(xiàn)一定程度的負載均衡 （ 3）客服系統(tǒng) 更換核心網(wǎng)絡(luò)設(shè)備 ,擴容網(wǎng)絡(luò)帶寬、新增熱備鏈路路由； 客服數(shù)據(jù)庫新增一臺主機配置成雙節(jié)點 RAC。 （ 4）二卡合一 增加一臺接口主機，負載均衡互為備份 （ 5）其他關(guān)鍵系統(tǒng) 營業(yè)系統(tǒng)：更換營業(yè)數(shù)據(jù)庫主機；中間件主機擴 CPU/內(nèi)存；解決營業(yè)數(shù)據(jù)庫 RAC在節(jié)點主機宕機時不能正?；榻庸軉栴}。 帳務(wù)系統(tǒng)：帳務(wù)應(yīng)用擴容 CPU/內(nèi) 存；帳務(wù)數(shù)據(jù)庫新增一臺主機配置成雙節(jié)點 RAC 。 計費系統(tǒng)：計費應(yīng)用、計費數(shù)據(jù)庫主機擴容 CPU、內(nèi)存。 PRM/CHANNEL 系統(tǒng)：從營業(yè)中間件分離出來，配置 HA 雙機互備，負載均衡。 結(jié)算系統(tǒng)：更換結(jié)算數(shù)據(jù)庫和結(jié)算應(yīng)用主機，配置 HA 雙機互備。 2、措施二：應(yīng)用系統(tǒng)改造優(yōu)化 系統(tǒng)監(jiān)控：梳理分析各個子系統(tǒng)的關(guān)鍵監(jiān)控點，通過 BOSS 網(wǎng)管、腳本、存儲過程等手段利用短信直接把告警發(fā)給維護人員，加快反應(yīng)速度把故障消滅在萌芽狀態(tài)。 CBOSS：針對影響集團公司五項考核指標的薄弱環(huán)節(jié)進行加強應(yīng)急措施：如建立基于 BES 服務(wù) 的 PARTITION。 集群、建立應(yīng)急系統(tǒng)、更換多后臺進程版本等。 BOSS 全編上線：把控改造進度、嚴謹測試，精心組織、周密部署確保了全編版本割接成功。 3、 措施三：開發(fā)測試環(huán)境優(yōu)化改造 改 造 后改 造 前測 試 環(huán) 境測 試 環(huán) 境開 發(fā) 環(huán) 境I B M S 7 A1 2 C P U , 2 4 G R A MI B M S 7 A1 2 C P U , 2 4 G R A MI B M P 6 7 0 L P A R4 C P U , 8 G R A M營 業(yè) 應(yīng) 用 測 試C B O O S 測 試接 口 測 試客 服 測 試I B M P 6 7 0 L P A R4 C P U , 8 G R A M營 業(yè) 測 試 庫P R M / C H A N N E LI B M P 5 7 08 c p u , 1 6 G R A M帳 務(wù) 測 試計 費 測 試經(jīng) 分 1 . 5 測 試開 發(fā) 環(huán) 境I B M P 6 9 0 L P A R8 C P U ， 2 4 G R A MI B M P 6 9 0 L P A R8 C P U ， 2 4 G R A MI B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A M營 業(yè) 測 試 庫營 業(yè) 發(fā) 布 庫營 業(yè) 回 退 應(yīng) 用I B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A M營 業(yè) 發(fā) 布 應(yīng) 用營 業(yè) 培 訓(xùn)I B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A MP R M / C H A N N E L帳 務(wù) M D B接 口I B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A M自 動 測 試 庫客 服 測 試帳 務(wù) 應(yīng) 用I B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A M營 業(yè) 測 試 應(yīng) 用營 業(yè) 回 退 庫I B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A M計 費 應(yīng) 用計 費 M D BI B M P 6 5 08 C P U ， 2 4 G R A MP R M / C H A N N E L 前 臺無 線 營 業(yè) 廳 前 臺網(wǎng) 上 自 助 前 臺I B M P 6 5 06 C P U ， 2 8 G R A MC B O S SI B M P 6 5 06 C P U ， 2 8 G R A M自 動 測 試 應(yīng) 用1 、 配 置 低 處 理 性 能 不 足2 、 測 試 環(huán) 境 不 全3 、 B O S S 和 經(jīng) 分 測 試 環(huán) 境 混 在一 起1 、 遷 移 到 2 臺 I B M P 5 9 5 、 3臺 P 6 5 0 ， 提 升 主 機 處 理 能力2 、 利 用 主 機 分 區(qū) 功 能 ， 實現(xiàn) 物 理 集 中 、 應(yīng) 用 邏 輯 分開 通過 BOSS 測試系統(tǒng)擴容改造工程新增主機、資源整合，把舊的開發(fā)測試環(huán)境遷移到新的系統(tǒng)平臺上 ，建立了開發(fā)、測試、發(fā)布、回退、培訓(xùn)等多個環(huán)境，為應(yīng)用軟件的在軟件生命周期的各個階段順利開展提供保障。 嚴把應(yīng)用開發(fā)測試進度控制，除了進行功能測試、集成測試外，加強進行各種壓力測試、異常測試 。 4、 措施 四：優(yōu)化 BOSS 運維流程 發(fā)揮 BOSS 網(wǎng)管系統(tǒng)作用：完善 BOSS 各子系統(tǒng)設(shè)備在 BOSS 網(wǎng)管系統(tǒng)上的配置，充分利用 BOSS 網(wǎng)管加強系統(tǒng)監(jiān)控、告警，把故障消滅在萌芽狀態(tài)。 建立周、月分析制度：通過各種性能收集、分析工具定時收集數(shù)據(jù)進行分析，找出應(yīng)用瓶頸所在，提交應(yīng)用集成商共同解決。 完善應(yīng)急方案：通過演練來不斷完善系