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

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