|
項目一：中國萬網關鍵業務平臺數據庫改造項目 |
|
項目簡介（功能與用途）： 中國萬網是國內最大的域名註冊和虛擬主機服務提供商，一直專注於中國e網絡體系（e-infrastructure）建設。中國萬網關鍵業務平臺是中國萬網對外的電子商務平臺，提供7×24小時的服務，客戶利用互聯網通過該系統進行域名註冊、主機、郵箱及其它各類業務的訂購及續費，並支付貨款，還通過該系統對個人資料及已有業務的屬性進行維護。該系統爲萬網最爲重要的業務支撐系統，只有該系統穩定高效的運行，才能保證萬網各項業務的順利開展。 該系統已投入運行，隨着運行時間的增長和業務量的不斷膨脹，也暴露出一些問題，數據庫的運行效率、高可用性及安全性需要得到進一步提升。 項目難點與解決方案： 該項目爲一個典型的對在用系統的數據庫平臺進行改造的項目。 其難點在於如何確保改造的過程中，系統能夠穩定、正常的運行，近可能減小可能的負作用，並贏得廣大開發人員及其他相關人員的積極配合。 對於此類項目，首先應該對系統運行狀況進行比較全面的監控與檢查，找出潛在的問題，提出解決方案，實施不必一步到位，可以由易而難分步實施。對於開發人員及其他相關人員，要做好充分的溝通，並進行相關的培訓，使其理解改造的合理性，得到他們的支持與配合。 一、性能方面的改進 我首先利用Oracle的statspack對系統的幾個典型時段的運行情況進行抽樣分析，利用實時監控工具對數據庫的運行情況進行跟蹤，通過操作系統的監控工具掌握系統CPU、I/O、內存換入換出操作等的情況。再有，通過對業務數據的統計分析，進一步瞭解業務量的分佈及增長情況，掌握定時批處理程序的分佈，這樣對系統的整體運行狀況有一個比較全面的瞭解，哪些方面需要改進也就清楚了。 通過衆多專家及自己親身經驗表明，應用軟件的優化往往是整個計算機系統優化的關鍵，與數據庫參數、操作系統參數的調整以及硬件的升級相比，其往往會收到更好、更經濟的效果（當然這只是多數情況下，具體問題也還需要具體分析）。而SQL的優化又是基於數據庫應用優化的重要組成部分，而如何讓開發人員認識到這一點的重要性呢。恰好這時，隨着系統運行時間的增長與數據量的增加，某些應用的效率問題突現，有的已影響到業務的正常開展，開發人員已有了對系統進行優化的願望，我就抓住這個時機，在內部開展了關於應用及SQL優化的技術交流，主要闡述瞭如下觀點： 1、 應用及SQL優化的重要性； 2、 全表掃描與索引檢索的適用條件； 3、 索引不是越多越好（通過數據結構講解索引的本質、索引的開銷、適用性、索引列的選擇及複合索引各字段順序的選擇）； 4、 多表查詢的主要方法（循環嵌套（nested loops join）、哈希連接（hash join）及排序歸併連接（sort merge join））及其各自的適用情況； 5、 不要輕易相信某些結論（如or不能用索引等等），而要以真實的執行計劃爲準； 6、 要及早重視性能問題，開發環境模擬真實的數據量，上線前進行壓力測試。 在交流中，我沒有空談理論，而是將我在檢查、監控系統時收集的有明顯優化潛力的SQL拿出來分析，並將優化前後的效果進行現場對比，多數都有10倍以上的差距，使大家切實感受到優化的潛力與效果，也明確了優化的方向。 這樣在交流結束後，在相關負責人的組織下，一方面對部分重點SQL進行優化，另一方面刪除、調整十餘個索引，釋放大量存儲空間的同時系統的邏輯、物理讀寫都下降40%以上，系統性能得以明顯提升。 二、在備份、恢復策略及高可用性方面的改進 我大體上分三個步驟來提高系統的可用性： 第一步：在不增加任何軟、硬件成本的前提下，更改相關設置，達到單庫構架下的最大可用性 將Oracle中重要的控制文件、聯機日誌文件進行多路鏡像，開設數據庫歸檔方式，並進行定期的物理備份，測試驗證備份的可恢復性，繼續保留原有邏輯備份作爲必要的補充，使系統在最短時間內並不增加任何成本的前提下有了相對完善的備份、恢復策略，提升了系統的可用性。 第二步：爭取到一臺新機器，實施Oracle Data Guard Data Guard的實質是在生產數據庫運行的同時，再建一個實時的恢復系統。以傳統方式恢復數據庫時，首先要將數據庫的備份恢復到原機器或一臺新機器上，之後還需要應用備份之後產生的日誌以使數據庫恢復到故障點。而如果數據庫比較大，產生日誌又比較頻繁的話，恢復用時就比較長，從而影響系統的可用性。爲了加快恢復，在生產庫運行的同時，事先利用數據庫的一個備份在備用機器再建立一個數據庫，生產庫產生的日誌以異步或同步方式傳輸到備用庫並進行恢復，這樣一旦主數據庫發生故障，備用數據庫可以很快完成恢復提供服務。如果主庫與備用庫分處不同的地點，Data Guard還能起到容災的作用。 由於Data Guard本質還是數據庫的備份/恢復，所以複雜性並不是很高，實施與維護的風險也比較小，除了增加一臺機器外也沒有更多的成本支出，而可用性的提高卻是非常顯著。 第三步：實施RAC+ Data Guard，即Oracle提供的最高可用性（MAA，Maximum Availability Architecture）架構。 RAC（Real Application Clusters）是其前身OPS（Oracle Parallel Server）的進一步發展，其特點是同一集羣的多臺主機可以同時以讀寫方式訪問同一數據庫，也就是說，各機器的CPU、內存、本地硬盤是獨立的，但它們要同時操作在共享磁盤上的同一數據庫。這樣，平時多個節點可以進行負載分擔，而當某一節點出現故障時，連在其上的會話可以透明、均衡、迅速地分佈到其它節點上。 我們實施的是最高可用性（MAA，Maximum Availability Architecture）的一種實現方式，即主站點採用RAC，附站點是單機，兩者之間的同步通過Data Guard實現。這一架構實施後，使系統的可用性得到進一步的提升。 在此期間，我還在公司內部主持了關於備份、恢復與高可用性方面的專題技術交流，普及了相關概念，使相關人員對這一問題有了更爲全面的瞭解。 三、安全性方面的改進 安全性的問題涉及多個層面，在我力所能及的範圍主要採取了以下一些措施： 1. 應用程序與數據庫連接的用戶與數據庫對象的屬主用戶相分離 2. 修改系統用戶默認密碼； 3. 建立規範的口令的管理制度，對口令的複雜度、分發、更改、有限週期進行管理； 4. 配置Oracle可執行文件權限； 5. 限制OS驗證，禁用遠程OS驗證； 6. 限制表空間限額； 7. 根據實際情況，開啓審計功能，進行適度審計，分析用戶訪問行爲； 8. 斷開其它數據庫對生產庫不必要的連接（dblink），只允許來自特定節點的訪問； 9. 加強數據庫的實時監控，對異常現象及時進行調查分析（如通過分析系統負載的變化發現注入漏洞，及時反饋給開發人員補救），堵塞漏洞； 10. 對敏感數據加密保存； 11. 從歸檔日誌中挖掘歷史以供分析。 通過以上措施，使數據庫系統的安全性得以提升。 項目成功與失敗的經驗歸納： 該項目爲典型的對在用系統的數據庫平臺進行改造的項目，其成功的經驗在於： 1. 爲了保持系統運行的平穩，儘量不要採用急風暴雨式的措施，而是採用小步快跑的方式，穩步推進系統的改造（CMM關於軟件過程改進的思想同樣適用於此類項目，“改進是在一系列微小的、不斷髮展的、而不是革命性的創新步驟中實現的”）； 2. 實施人員要與開發人員及其他相關人員進行密切的溝通，使他們理解並支持改造工作； 3. 任何改進措施都要在測試環境下進行測試後才能應用到生產系統，對可能產生的風險進行充分評估，準備好相應的應急預案； 4. 善於利用有利時機，宣傳改造工作的意義，推動項目的進展； 5. 實施人員一定要是數據庫方面的專家，既要有堅實的理論知識，也要有豐富的實際經驗；另外還需具備操作系統、存儲方面的知識。 你在項目中崗位與貢獻： 我是這一項目的負責人、設計者與執行者，負責原有系統的分析、提出改進措施並分步實施，還負責相關技術問題的交流與培訓。 經過我上述三個層面的改進，中國萬網電子商務平臺的運行效率與可承受負載能力有了明顯提高，負載均衡和高可用性在系統中得以體現，備份與數據庫安全管理意識逐漸在技術團隊中樹立起來，而MAA架構的實現也爲未來萬網公司的業務的擴展奠定了堅實基礎。 |
|
項目二：A省X市郵電局計費系統項目 |
|
項目簡介（功能與用途）： 該項目爲一個基於數據庫的應用開發及實施項目。 該項目實施於1997年5月至10月間，爲X市郵電局“九七工程”（電話業務計算機綜合管理系統）中計費子系統的開發與實施項目。主要功能包括客戶資料管理、計費管理、帳務管理、欠費管理、前臺收費、統計查詢及營收報表等。該系統爲郵電局（當時電信與郵政、固話與移動還未分業經營）對固定電話用戶進行計費、收費的系統，是電信企業最爲關鍵的業務支撐系統之一。 項目難點與解決方法： 該項目爲大唐電信計費系統第一個成功開局的項目，也是電信企業的計費帳務系統由foxbase/foxpro時代向大型關係數據庫（DB2/Oracle/Sybase）時代的轉變項目，雙方都缺乏經驗，主要難點體現在如下的幾個方面： 1、對需求的把握 雖然在去工程現場之前也進行了開發，但依據的有些需求尤其涉及到一些細節的地方是猜想出來的，而到了現場之後，發現實際的需求與過去的想象有比較大的差距，尤其是涉及人機交互的部分更是如此。解決的辦法就是深入業務處理的現場，去了解業務處理的現狀，徵求業務處理人員對新系統的想法，也只有你親身體會到一些基層業務人員平時勞動的艱辛，你也纔有更加強烈的願望、也纔可能通過自己的才能寫出更加實用的程序去幫助他們減輕勞動負擔，而不是用你在辦公室通過臆想而編造出的程序給他們增添新的麻煩。 2、原有系統數據導入 郵電局原有的計費系統中的各類數據有自己的格式、編碼規則及含義，而原有系統又缺乏規範的文檔資料及說明，如何將其導入新的系統而保證不出差錯。這一方面靠我們的技術人員與局方技術人員緊密溝通，儘量問清楚各表、字段及編碼規則的含義後開始編制數據轉換程序；另一方面在數據轉換程序編好後，要多次進行轉換對比實驗，通過兩個系統統計、查詢、報表的差異找出潛在的問題。 3、遇到Oracle回滾段不足的錯誤 由於當時的計費程序爲一個很大的事務，經常出現回滾段不足導致計費失敗的錯誤（當時Oracle 版本爲7 .3），最後採用事務開始前指定大的回滾段的方法解決了該問題。 4、長途話單表的設計 由於長途電話需要提供明細查詢，每月都會產生大量的話單，在線保存六個月後從系統中清除離線保存。而當時使用的是Oracle 7，還沒有提供表分區功能，所以只能將長途話單表進行水平分解，形成表名中帶有後綴的六個表。 5、技術積累不足 當時參加開局的三個人都是象我一樣剛從大學畢業一年左右的本科生或研究生，技術積累都不足，而現實的工作要求我們既要熟悉電信業務，還要掌握開發工具（powerbuilder）、數據庫管理系統（Oracle）進行軟件開發。也沒有什麼別的捷徑，只有努力學習，除了吃飯、睡覺，我們所有的時間幾乎都在機房度過，儘可能在最短的時間內完成任務。 項目成功與失敗的經驗歸納： 該項目成功上線運行。 經驗： 1. 在系統上線前，經過多次原有數據的轉入、出帳、收費的對比測試，保證了系統總體上不會出現太大的問題，即上線前的測試非常重要； 2. 選擇業務量比較少的非工作日上線，這樣發現問題可以及時改正並減少影響範圍； 3. 項目開發人員編程比較規範，編程質量較高； 4. 該局業務量不是很大、 功能及性能需求也不是很高，選擇它作爲第一個試點局，有利於系統的成功上線，即第一個工程項目難度要低一些； 5. 局方技術人員大力配合，與我方人員結下比較好的個人友誼，幫助我們克服各種困難，是項目成功的一個關鍵； 6. 項目組成員雖然年輕、經驗少，但精力旺盛、私心雜念少，大家團結一致、互相幫助，共同爲了事業而努力工作； 教訓： 1. 輕易在生產系統修改配置，導致系統運行受到影響（一次是在共享卷組建立文件系統導致集羣異常，還有一次輕易在一個表上建立索引，導致主要查詢執行計劃變壞，嚴重影響系統效率）； 2. 沒有意識到網絡差異對系統性能的影響，開始編程時客戶端與服務器端交互頻繁，在開發使用的局域網環境下感覺不出問題，而實際環境有的營業網點通過共享64K DDN專線與中心機方連通（有的偏遠的收費點甚至使用撥號上網的方式），試用新系統時明顯感到反應速度無法忍受，只好重新修改程序，減少前、後臺的交互； 3. 沒有意識到不同子系統共享數據的危險性，在後來營業系統上線時，部分信息被不同的子系統互相覆蓋更新，幸好發現及時沒有引起大的損失與影響； 4. 由於當時缺乏經驗，數據庫索引的選取、物理存儲的分佈，都有很多可以優化的地方； 5. 系統剛運行時，只是每天採用export作爲備份手段，而沒有開啓數據庫的歸檔方式，一旦發生介質故障恢復將比較煩瑣（由於當時已普遍採用RAID5技術，存儲可靠性有一定提高，另外在郵電局辦理各項業務都會有紙質單據，所以在最壞的情況下可以先將前一天的導出數據導入，再覈對單據進行數據的補錄，不會造成太大的數據丟失）；而以我現在的觀點，即使採用RAID 0+1，對於生產系統也應開啓歸檔方式，使系統更加健壯； 你在項目中崗位與貢獻： 我是大唐電信計費帳務系統的主要開創者之一，系統最初只有我們三位開發人員，我們共同參與了計費系統的分析與設計、確定數據庫的表結構，分工編碼，我具體負責後臺銷帳、前臺收費及部分查詢功能的設計與編碼。 我全程參與了該項目，包括前期項目的爭取與後期項目的實施。在項目實施過程中，進駐現場四個多月，到各營業廳瞭解實際的需求，根據新的需求重新進行軟件開發，編寫了部分原系統數據的轉換導入程序。系統上線前進行系統測試，上線過程中夜以繼日地監控系統運行情況，對反應上來的問題及時進行修正，上線後對數據庫進行優化以提高系統效率，爲該項目的成功做出了重要貢獻，也爲大唐電信軟件公司計費帳務系統的創立奠定了堅實的基礎。 |
|
項目三：B省Y市郵電局計費系統項目 |
|
項目簡介（功能與用途）： 該項目爲一個基於數據庫的應用開發及實施項目。 該項目實施於1997年11月至1998年3月，爲Y市郵電局“九七工程”（電話業務計算機綜合管理系統）中計費子系統的開發與實施項目。主要功能包括客戶資料管理、計費管理、帳務管理、欠費管理、前臺收費、統計查詢及營收報表等。該系統爲郵電局對固定電話用戶進行計費、收費的系統，是郵電局最爲關鍵的業務支撐系統之一。 項目難點與解決方法： 1、需求的變化 雖然已經有了一個計費系統的開局經驗，但來到一個新局，發現許多需求與前一個局都有很大的不同，尤其涉及人機交互的前臺程序更是如此，比如我負責的收費部分就是這樣，想不對程序進行較大的修改就上線是不可能的。解決的辦法就是再次深入業務處理的現場，去了解業務處理的現狀，徵求業務處理人員對新系統的想法，經過在營業廳的仔細觀察，我最終決定重寫收費程序，一方面是爲適應新的需求，另一方面也是全面改進第一個版本中的不足。經過三週左右，終於完成了新版本的收費程序。 2、原有系統數據導入 該局數據轉換工作較之上一個局複雜程度明顯增加。首先數據量有明顯的增加，而且有大量用戶屬於有一定預存款的用戶（而上一個局基本都是現金用戶），並且有些陳年欠費數據非常複雜，負責數據轉換的同事雖然經過精心覈對，但正式上線後仍發現有部分歷史數據導入存在問題，前臺收費廳曾一度秩序混亂。但這時，局方與我方之間、我方人員之間並沒有互相指責，大家齊心協力想辦法儘快解決問題，由於問題數據極其複雜，編寫程序批量調整稍有不慎可能引起更大的混亂，所以決定逐一處理，我臨時改寫了相關程序以方便調整，局方抽調其他崗位的人員來支援，通過大家加班加點的努力，用了一天多一點的時間終於將數據調整正確，新系統也開始穩定運行。這一事件也再一次驗證了那句話“三分技術，七分管理，十二分的數據”，數據的準確性對數據庫應用的成功是何等的重要！ 3、涉及分佈式應用 計費系統與營業系統有比較密切的關係，而這兩個系統各有獨立的數據庫，所以兩個系統的交互涉及分佈是應用。當時營業系統客戶資料的變更通過接口表的方式傳遞給計費系統；營業系統在給客戶辦理相關業務前需要檢查該客戶是否欠費，需要調用計費系統判斷是否欠費的函數；而當欠費停機的客戶交完欠費後，計費系統也需要調用營業系統的自動開機過程。上述分佈式調用都是通過Oracle的database link完成的。 4、首次遇到Oracle經典的“快照太老”錯誤 那是1998年元旦，舉國歡慶新年之際，我們在緊張地加班進行新系統上線，當新一月的帳務數據已計算完畢並覈查沒有什麼問題後，我編寫的後臺銷帳程序開始運行，該程序外層使用一個大的循環（用遊標cursor實現）取預付費用戶餘額數據，如果餘額能夠抵扣該用戶新的帳務數據，便進行一次後臺銷帳，每一次銷帳成功作爲一個事務。但運行了一段時間後，程序突然異常退出，我又試了一次，程序還是在運行了一段時間後異常退出。分析Oracle給出的錯誤，“快照太老”，我當時真是不知其所云，查閱Oracle資料對其的解釋，由於我們當時對Oracle內部瞭解有限，絕大部分解釋沒看懂，但裏面提到“大的遊標（cursor）中如果穿插commit可能會導致此類錯誤”，而我的程序正好屬於這種情況，但從邏輯上講一次銷帳作爲一個事務非常合理，也不能等所有用戶銷帳完畢後再統一提交。當時我採取的解決辦法是，在外層再嵌套一層循環，對此類錯誤引起的例外（exception）進行屏蔽，再根據相關的時間戳，繼續提取近期沒有進行過銷帳操作的用戶（即排除掉髮生“快照太老”錯誤前已銷過帳的用戶）進行處理。這樣，後臺銷帳可以順利完成了，但通過檢查日誌可以發現，一次銷帳過程要出現5-6次“快照太老”錯誤。後來，我優化程序，在提取用戶數據時加一個排序，不僅整體銷帳時間減少了一半，而且“快照太老”錯誤也基本不出現了。 項目成功與失敗的經驗歸納： 該項目成功上線運行。 經驗： 1. 遇到問題要冷靜，即使一時找不到最佳的解決方案，但也要想辦法使系統先正常運轉起來，再逐步優化解決方案； 2. 在系統上線前，經過多次出帳、收費的對比測試，保證了系統總體上不會出現太大的問題，即上線前的測試非常重要； 3. 選擇業務量比較少的非工作日上線，這樣發現問題可以及時改正並減少影響範圍； 4. 編制了內部審覈、校驗程序，如：昨天系統用戶預存款總額，加今天金額變化的量（考慮用戶交款、扣款、沖帳、調帳等的影響），應等於今天預存款總額；如果實際結果相等，證明系統運行正常，如果不等，促使相關人員分析不等的原因，儘快找出系統漏洞。內部審覈、校驗程序增強了我方與局方對新系統正確運行的信心； 5. 局方技術人員大力配合，與我方人員結下比較好的個人友誼，幫助我們克服各種困難，是項目成功的關鍵； 6. 項目組成員雖然年輕、經驗少，但精力旺盛、私心雜念少，大家團結一致、互相幫助，共同爲了事業而努力工作； 教訓： 1. 由於負責原有系統數據轉換的同事沒有參加第一次開局工作，所以經驗相對缺乏，而且這個局歷史數據也很複雜，雖然經過精心覈對，但最後還是在數據上出了問題，所以數據庫應用再怎麼強調數據的準確性都不爲過，尤其是需要進行新舊系統割接的項目更要倍加重視； 2. 由於當時缺乏經驗，數據庫索引的選取、物理存儲的分佈，都有很多可以優化的地方； 3. 系統剛運行時，只是採用export作爲備份手段，而沒有開啓數據庫的歸檔方式，一旦發生介質故障恢復將比較煩瑣； 4. 當時對系統安全性也重視不夠，協作單位開發數據採集系統的工程師也直接登錄系統數據庫，晚上誤操作刪除了用戶資料表，如果不能及時恢復必將影響第二天的正常收費，而由於上述關於備份/恢復策略的缺陷，人工補錄肯定耗時較長，幸好業務系統的用戶信息表與我們使用的基本一致，而且平時我們也是從那裏獲取的信息，所以經過連夜的緊急加班恢復了數據，沒有造成太大的影響； 你在項目中崗位與貢獻： 這是大唐電信軟件公司計費帳務系統所實施的第二個工程，我全程參與了該項目，包括前期項目的爭取與後期項目的實施。在項目實施過程中，進駐現場將近五個月，到各營業廳瞭解實際的需求，根據新的需求重新進行軟件開發。上線前進行各類的測試與對帳，上線過程中密切監控系統運行情況，對反應上來的問題及時進行修正，積極想辦法解決數據導入後產生的問題，上線後對數據庫進行優化以提高系統效率，爲該項目的成功做出了重要貢獻，也進一步擴大了大唐電信軟件公司計費帳務系統的市場。 |
|
項目四：本地網綜合計費系統開發 |
|
項目簡介（功能與用途）： 本項目爲大型數據庫應用開發項目。 大唐電信計費系統在成功開通兩個本地網後，當時根據合同，還有七個本地網要在比較短的時間內開通，這時兩個本地網的開通一方面積累了寶貴的經驗，另一方面也暴露出許多問題，要想順利完成七個本地網的開通，必須對現有版本進行整合、對系統加以完善，開發出功能更加強大、穩定的版本，以供大規模工程之需。 公司決定集中開發“本地網綜合計費系統”，功能包括客戶資料管理、計費管理、帳務管理、欠費管理、前臺收費、統計查詢及營收報表等。另外該系統還要能夠支持整個本地網，即將本地網下屬的縣局、農村支局也納入計費系統中，而已開通的兩個系統不包括縣局與農村支局。該系統爲電信企業對固定電話用戶進行計費、收費的系統，是電信企業最爲關鍵的業務支撐系統之一。 項目難點與解決方法： 1、需求的統一 已開通的兩個本地網已存在許多差異性需求，而通過對將要開通的七個本地網的調研，也發現有很多本地化需求。爲了使系統能夠有更強的靈活性，在設計時引入不同類型的參數設置，努力在需求發生變化時，只需改變參數設置，而不需要更改程序。但在開發過程中，我們也認識到，軟件的靈活性、參數化也應有限度，其代價往往是性能的與程序可讀性的下降。不要寄希望於需求不發生變化，而是要加強軟件過程管理，適應需求的變化，跟蹤管理好需求的變化，加強軟件版本控制與配置管理。 2、原有數據的轉換與導入 在前兩個本地網的開通過程中，都是我方的技術人員去努力瞭解原有數據的格式與編碼規則並編寫數據的轉換與導入程序，這既浪費時間又容易出錯，下面我們要面臨七個本地網及其下屬更多的縣局與支局，我們不可能去逐個瞭解每個遺留系統（當時很多縣局與支局都有自己獨立的計費系統）的情況。針對這種情況，我們設計了一套較爲簡單的中間表格，由局方負責原有數據轉換到中間表格，而由我方負責將中間表格的數據轉換到新系統中。 3、處理的數據量加大 由於要將本地網的縣局與支局都納入到系統中，所以系統的數據量加大，爲了更好地進行管理並提高系統性能，採用了Oracle 8新提供的分區技術。 4、更爲複雜的人員權限管理 由於要將本地網的縣局與支局都納入到系統中，所以系統需要進行更爲複雜的人員權限管理，由此設計了能與之適應的人員多級管理與授權功能。 5、各地報表需求種類繁多、格式各異，並有定製化需求 引入BO等相關工具及其設計思想，定義各類報表元素，在報表元素的基礎上定製、組合各類報表，爲解決此類問題進行了有益的探索。 項目成功與失敗的經驗歸納： 該項目取得了成功，爲大規模的工程實施打下了比較好的基礎。 經驗與教訓： 1. 軟件設計時重視配置的參數化，使系統靈活性相對較好，但也需認識到軟件的靈活性、參數化也應有限度，其代價往往是性能的與程序可讀性的下降； 2. 認識到要加強軟件過程管理，適應需求的變化，跟蹤管理好需求的變化，加強軟件版本控制，開始引入clearcase作爲配置管理工具； 3. 在E-R模型向關係模型轉換時，在遵循解規範化理論與轉換原則的基礎上，也清楚地認識到，並不是範式越高越好，爲了加快查詢速度可以適度加入冗餘，非BCNF範式的關係雖然理論上可能會發生更新異常與冗餘，但如果實際中該關係並不進行更新或更新的頻度很小，其造成的負面影響也將十分有限；軟件與數據庫設計也是一門平衡的技術，究竟規範到什麼程度，也要看具體的需求及平衡各方面的利弊，而沒有一定之規； 4. 開發初期有過分強調數據庫獨立性的傾向，想達到不需要修改程序，只需修改簡單配置，便可自由選擇數據庫管理系統的效果，但經過一段時間的努力發現要達到該目的不僅非常困難而且成本很高，並在事務處理及性能方面都存在潛在的問題； 5. 在設計之初，沒有很好地考慮有關歷史數據的保留、清理與轉儲問題，也沒有對用戶這方面的需求進行很好地分析，給日後數據庫的維護帶來一定的麻煩； 6. 開始重視開發文檔的編制與管理，編寫的文檔比原來齊全了，也較爲規範，但現在看來，應該引入被普遍接受的建模思想與建模工具，提高開發文檔的質量； 7. 在編碼方面，制定了比較嚴格的編碼規範並嚴格執行，代碼的可讀性有一定提高； 8. 測試方面，由於當時沒有專職的測試人員，致使不少軟件當中的Bug被帶到了工程現場； 你在項目中崗位與貢獻： 我是該系統主要的開發者之一，也是計費部門成立後的技術主管之一，與其他技術主管共同參與了軟件的分析、設計及數據庫設計，負責後臺銷帳、前臺收費及部分查詢功能的設計與編碼，爲該項目做出了重要貢獻。由於我負責的銷帳與收費模塊設計合理、性能優良，保證了今後幾年這部分程序在工程項目中版本的基本穩定，減小了現場實施的工作量，穩定了軟件質量，減小了維護成本。 |
|
項目五：中國電信本地電信業務計費帳務系統統一檢測項目 |
|
項目簡介（功能與用途）： 隨着1998年-1999年間，原中國電信“九七工程”（電話業務計算機綜合管理系統）的全面展開與完善以及電信企業經營管理的需要，原來作爲“九七工程”子系統的計費系統的重要性日益顯著，有必要將其獨立出來，開發與建設新的“本地電信業務計費帳務系統”。根據“九七工程”及其它信息系統建設的經驗與教訓，中國電信提出了“統一需求、統一設計、統一檢測、按省實施”的工作方法，而“統一檢測”是其中的關鍵一環，工作內容是對同中國電信簽署了合作開發合同的六十餘家軟件廠商開發的系統進行檢測。其目的主要在於保證本地計費帳務系統改造工作的順利進行，保證本地計費帳務系統核心部分的統一性，爲各省提供一個高質量的應用軟件選擇範圍，促進應用軟件開發商提高軟件開發質量，不斷完善、補充和修改應用軟件。 項目難點與解決方法： 此項目的特點在於它是對基於數據庫的應用軟件進行大規模（參測廠商有六十餘家）的入圍檢測。 此次應用軟件檢測工作是中國電信首次，也是中國計算機行業少有的大規模進行的針對應用軟件的集中檢測工作，難點在於沒有任何經驗可以借鑑，因此檢測準備工作是否細緻、充分，直接關係到檢測工作的成功與否。爲此，在原中國郵電電信總局的領導下，檢測工作組很早即着手開展了應用軟件檢測的各項準備工作，包括與國內外公司、專家進行交流、學習和討論，檢測總體方案的制定，檢測平臺方案的制定，檢測組織方案的制定，檢測工作人員的培訓，檢測環境的搭建，測試數據的準備，測試用例的編制，檢測標準的量化等諸項工作。最終形成了總體檢測方案以及各分項檢測方案，成立了相應的組織機構，制訂了嚴密的制度與管理條例。以下幾個環節是該項目成功的關鍵。 一、檢測工作的定位與角度 此次檢測不同於軟件廠商內部進行的軟件測試，內部軟件測試是軟件開發週期內的一個重要環節，其目的在於找出程序中存在的問題和錯誤。而此次檢測是在應用軟件內部測試的基礎上，從符合度和規範性兩個方面進行的檢查和測試，即檢測應用軟件與中國電信相關規範的符合程度。 二、檢測內容 根據檢測工作的定位、角度及當時軟件開發普遍存在的問題，檢測的主要內容包括文檔評測、安裝評測、數據字典靜態檢查、功能檢測、性能檢測等五個方面內容。 1、 文檔評測：當時國內軟件開發還很不規範、重程序輕文檔的現象普遍存在，而軟件=程序+文檔，沒有規範的、與實際情況相符的文檔，隨着時間的推移與軟件企業人員的流動，應用系統將越來越難以維護，這不僅是軟件開發企業的問題，也將直接影響軟件使用單位的利益。所以爲了檢查軟件的開發過程是否規範，文檔檢查是必不可少的一環。 2、 安裝評測：應用程序的安裝應該快速、簡便，尤其是客戶端的程序，不僅開發人員可以安裝，維護人員也應容易掌握。 3、 數據字典靜態檢查：相關規範規定各開發單位必須嚴格執行相關設計中規定的表名、字段名及字段類型和長度，不得修改。根據這些要求，我們開發出一套對數據字典進行檢查的程序，該程序支持ORACLE、SYBASE、INFORMIX等數據庫管理系統。 4、 功能檢測：功能檢測本着既全面又突出重點的原則，全面指的是測試用例所覆蓋的功能點應含蓋計費帳務系統的各個方面，重點突出指的是相關規範所強調的能夠提高服務質量、增強競爭能力的一些有特色的新功能，這樣既檢測了計費帳務系統的完整性，又突出了新系統的重點，使功能檢測的結果能夠切實反應被測系統的真實水平。 5、 性能檢測：計費系統是電信企業關鍵的應用系統，不僅要求有完備的功能，而且要求有良好的性能。本次性能檢測主要考察兩個方面，一是帳務週期整體出帳歷時，二是模擬有多個聯機用戶的情況下收費程序響應時間。鑑於當時我國軟件行業多數企業沒有實力或沒有意識到應在開發階段對系統進行大規模壓力測試，致使只有到了實際運行後，才發現效率方面問題的狀況，本次檢測工作，使用了國際上比較流行的性能檢測工具，模擬大量用戶同時聯機操作的情況，一方面檢測了系統承受一定壓力的狀況，另一方面也促使各開發廠商儘早考慮效率方面的問題，爲各廠商提高開發質量起到了積極的推動作用。 三、搭建檢測平臺 向IBM、HP、DEC、SUN等四個廠家分別借用了配置基本相同的雙機集羣（CLUSTER）結構中高檔小型機服務器作爲主機系統；同時ORACLE、SYBASE、INFORMIX 等數據庫廠家分別借給中國電信多套大型關係數據庫，使得每個主機系統上均安裝了上述三套大型關係數據庫，共計十二種主機、數據庫的組合供被檢測方選擇。 四、檢測數據 檢測數據一部分從現業局提取，一部分由檢測工作組構造。 五、檢測用例 檢測用例參照檢測範圍，並結合檢測數據編制而成，體現了既全面又突出特點的原則。 六、檢測用程序 開發出一套對數據字典進行檢查的程序，該程序支持ORACLE、SYBASE、INFORMIX等數據庫管理系統。 七、實測 工作量由小到大逐漸展開，第一批安排一家、第二批兩家、第三批三家，自第四批纔開始滿符負荷同時檢測五家，在這個過程中，檢測人員及時總結經驗、解決新出現的問題，使測試工作得以順利進行。 項目成功與失敗的經驗歸納： 本項目達到了檢測的目的，取得了成功，主要經驗如下： 1. 檢測工作遵循軟件工程理論的指導，並參考相關的國際、國家及行業標準； 2. 檢測工作定位準確、目標實際，檢測內容選擇恰當，爲具體工作得以順利實施提供了前提保證； 3. 檢測準備工作細緻、周到，極大地減少了實測時可能遇到的風險與問題； 4. 組織這樣大規模的測試，組織方需要有強大的協調能力，設備、技術支持到位（IBM、HP等公司的專家多次提供寶貴意見，Oracle、Sybase有專門工程師負責平臺維護，有的工程師還進駐現場監控系統運行情況），後勤保障有力； 5. 檢測工作組織管理有序，一方面人員職責明確、各司其職，另一方面能夠發揚團隊精神、互相幫助； 6. 檢測結果客觀、真實、準確，並儘量做到量化，有些檢測項目還是由計算機來完成，儘可能減少了主觀因素的干擾； 7. 採用流行的壓力測試工具模擬大規模併發操作，促進軟件開發企業儘早考慮系統性能問題。 你在項目中崗位與貢獻： 本人爲該項目技術支持組的成員與HP平臺檢測組組長，這一項目中的衆多方案、流程、測試用例、測試報告及評判標準，多數都是由本人直接起草或是在本人的建議、指導下完成的，我還參與了檢測平臺的搭建，即在HP、DEC、IBM、SUN四套硬件平臺上分別安裝維護Oracle、Sybase、Infomix等三種數據庫管理系統。我全程參與了對全國60多家計費廠商產品的測試工作，負責現場疑難技術問題的處理，我還自行開發程序對各廠家的數據字典進行依從性檢查。通過這一項目，使我在基於大型關係型數據庫的應用系統的測試方面積累了寶貴的經驗，也使我在以後有機會參與了更多的測試項目。 |
|
項目六： 中國聯通CDMA專業計費子系統上線測試 |
|
項目簡介（功能與用途）： 中國聯通是國內唯一一家對所有電信業務擁有經營權的電信運營商。爲了發揮綜合業務的優勢，實現靈活多變的營銷策略，中國聯通提出以“一個體系，多個子系統”的思路來建設綜合業務支撐系統，CDMA專業計費子系統正是本着這一原則進行建設的，由數據採集、預處理、一次批價、統計、聯機管理、系統管理等模塊組成。2002年初，爲了保證CDMA網絡正式運營之後計費子系統的準確性與高可靠性，中國聯通決定在正式運營之前對各地的CDMA專業計費子系統進行一次全面的測試。 本次測試本着公平、嚴謹、科學的原則，對被測廠商提供的軟件進行全面、規範的測試。測試工作分爲兩個階段：集中測試和現場測試階段。 集中測試階段，測試範圍覆蓋預處理、一次批價、統計管理、系統管理等模塊，重點測試系統的準確性與處理效率。現場檢測階段，測試範圍覆蓋數據採集、聯機指令、監測等模塊。 項目難點與解決方法： 當時有6家廠商承擔聯通全國31個省級計費系統的工程任務，該項目的主要難點在於如何能切實全面測試各地系統的運行狀況，並得到軟件開發商的全力支持。 爲了能圓滿完成測試任務，我們將測試工作分成集中測試與現場測試兩個部分。其中集中測試主要測試各地計費系統中共性的部分，而現場測試主要測試各地的差異性部分。 一、集中測試階段 爲了使測試取得更好的效果，測試人員做了大量、細緻的準備工作，主要包括： 調研工作，爲了使測試工作更具針對性，在項目啓動之初，相關人員就做了大量的調研與收集資料的工作。其中主要包括向相關廠商及分公司發放調查表，瞭解目前系統運行情況及廠商對測試環境的需求；收集各地C網業務開通情況及現行的資費政策；收集交換機話單格式說明；收集局數據，爲局數據覈對做準備； 測試平臺的搭建，根據廠商的需求，測試人員對測試用主機、網絡進行了重新規劃，並安排相關廠商安裝了必要的軟件環境； 測試用例的設計，軟件工程理論與實際工程經驗均表明，軟件錯誤往往發生在系統輸入與輸出的邊界值及一些特殊處理上，所以，測試人員在設計測試用例時重點考察了各種邊界情況及其它一些易發生錯誤的地方（如通話跨時段、跨天等等情況）； 測試數據的構造與提取，爲了使測試內容更加全面，測試人員熟悉了當時使用的全部6種交換機的原始話單格式，並在沒有輔助工具的條件下，手工構造了測試預處理模塊所需的原始話單（二進制格式）；另外，爲了減輕被測廠商的工作量，測試人員還提前熟悉了各軟件廠商內部的話單格式，儘可能依據廠商的內部格式，構造一次批價所需的數據；爲了進行性能測試，相關負責同志還從某省提取了上千萬的原始話單； 在測試工作的組織管理上，在項目啓動之初，就形成了本項目的《總體方案》，之後又按計劃逐漸形成了《測試流程》、《測試人員管理條例》、《被測廠商管理條例》、《測試機房管理條例》等管理文檔，另外，還組織各軟件廠商召開了測試工作的動員會，並向其發放了正式的通知函，這些都保證了測試工作有序、規範的進行。 正是上述充分的準備，爲測試工作的成功打下了良好的基礎。集中測試共對6家軟件廠商的產品進行了測試，測試主要包括4個方面的內容： （1）功能測試：測試範圍覆蓋預處理、一次批價、統計管理、系統管理等模塊； （2）性能測試：處理從現業局提取的約1000萬原始話單，記錄各階段的處理時間； （3）局向數據審查：測試人員編寫腳本，對比廠家提供的局向數據與結算中心提供的局向數據的差異； （4）對比測試：參加測試的廠商同時處理同一批話單，對比各自的計費結果，如有差異，覈查其原因。 二、現場測試 集中測試結束後，測試人員又開始了現場測試的準備工作，主要包括以下幾個方面： 試點測試，爲了使現場測試更加全面和科學，首先在北京和河北兩個分公司進行了試點測試，有關測試人員都參加了兩個試點的現場測試，制定了統一的評判標準與統一的工作流程，保證全國的現場測試工作在公平、公正、科學的基礎上順利實施； 檢查記錄和測試用例的設計，爲了使檢測工作更全面，在進行了試點分公司的現場測試後，對檢查記錄和測試用例進行了進一步的修訂和完善，並細化了現場交流的提綱； 在集中測試發現問題的基礎上，測試人員準備了現場測試中需要重點檢測和核實的方面，以便在現場測試時對廠家集中測試時發現的問題進行更深入的瞭解； 測試工作的組織管理方面，在《總體方案》的基礎上，之後又按計劃逐漸形成了《現場檢測工作流程》、《現場檢測座談會流程》等管理文檔，另外，還向各省分公司發放了現場測試通知及準備工作通知，這些都保證了測試工作能夠有序、規範地進行。 上述全面、細緻的準備工作，使得現場測試工作順利進展。現場測試人員分成4組，每組平均對6~7個省進行測試，每個省的檢測時間平均爲2天半。共檢測了由5個軟件廠商實施的28個省級計費系統的現場運營情況，按計劃在18天內完成了全國範圍的測試。現場測試的主要測試內容包括： （1）文檔審查：檢查軟件廠商提交給各分公司的文檔的種類是否齊全； （2）採集模塊的檢測：由於系統已經上線運行，所以本次檢測工作主要檢查系統目前實際運行情況，聽取相關技術人員的講解，填寫相關的記錄表。如果生產環境允許，可以製造網絡斷點，以檢查斷點續傳、自動告警、自動任務恢復等功能； （3）聯機指令模塊的檢測：事先請各分公司準備好一定數量的測試號，測試時，通過綜合營帳對這些測試號進行現場開通、增加特服、銷號等操作，通過現場的撥打測試檢查聯機指令的發送是否成功； （4）監測模塊的檢測：檢查應用系統是否能夠完成對主機、數據庫、網絡和應用程序運行時的性能和狀態進行監測； （5）對於在集中測試時，沒有提供統計模塊的軟件廠商，現場測試時要檢查其統計模塊的功能。 項目成功與失敗的經驗歸納： 本項目達到了檢測的目的，取得了成功。 1. 檢測工作遵循軟件工程理論的指導，並參考相關的國際、國家及行業標準； 2. 由於本次測試工作旨在CDMA系統正式運營之前，檢查發現專業計費子系統中存在的問題，從而督促相關人員進行改進以降低正式運營後的風險。所以，爲了使各軟件開發商更加積極地參與本次測試工作以達到更好的測試效果，對於本次測試結果，不進行橫向比較，不進行評級、打分，只作爲系統改進的依據，這樣極大地消除了軟件提供商的顧慮與抵觸心理，使他們更加積極地配合測試工作，而不是設置障礙，從而取得了比較好的測試效果； 3. 由於設計測試用例時重點考察了各種邊界情況及其它一些易發生錯誤的地方，又引入了多家廠商處理相同話單後進行對比的測試方法，所以發現了軟件當中不少深層次的錯誤，有的問題還很嚴重，促使廠商對軟件進行修正。測試達到了預期效果，既減小了聯通運營的風險，也減小了軟件廠商日後維護的風險，達到了雙贏的效果； 4. 集中測試與現場測試內容分配得當，即測試了各廠家計費系統的各個組成部分，也測試了各省本地化的內容，還最大程度上減少了核心部分的重複測試，節約了項目成本； 5. 組織這樣大規模的測試，組織方需要有強大的協調能力，設備、技術支持到位，後勤保障有力； 6. 檢測準備工作細緻、周到，極大地減少了實測時可能遇到的風險與問題； 7. 檢測工作組織管理有序，一方面人員職責明確、各司其職，另一方面能夠發揚團隊精神、互相幫助； 8. 檢測結果客觀、真實、準確，有些檢測項目還是由計算機來完成，儘可能減少了主觀因素的干擾。 你在項目中崗位與貢獻： 本人爲該項目技術方面的負責人，這一項目中的衆多方案、流程、測試用例、測試報告及評判標準，多數都是由本人直接起草或是在本人的建議、指導下完成的。集中測試時，本人負責組織進行多廠家對比測試及現場疑難技術問題的解決；現場測試準備階段，負責組織試點局的測試，制定統一的尺度與工作流程，對現場檢查記錄和測試用例進行了進一步的修訂和完善，並細化了現場交流的提綱。現場測試時，負責北方七省區的現場檢測工作，並協調、監控其他組的測試工作，爲項目的成功做出了重要貢獻。 |
說明：斜體字均爲填寫範例和說明，文字題寫不受篇幅限制，請儘量詳盡。
登記表格請同時提交信箱：[email protected] [email protected]