隨著計算機單機性能的提升和IT行業競爭日益激烈，云計算走進入了我們的視野中。歷史在不斷的重演，但是每次卻有不同之處。
云計算也是一樣，在20世紀60-80年代計算機的價格和維護成本只有一些大型企業和政府機構才能負擔得起。為了滿足很多用戶使用的需求，每一個用戶通過單獨的終端接入同一臺大型機。進入80年代以后，客戶機/服務器(client/server)技術的飛速發展，數據由單一的大型機分散到了很多服務器中,原來沒有計算能力的接入終端變成了個人計算機。進入90年代后期，隨著經濟全球化和企業規模的擴大，信息分散管理的弊端越來越明顯，運營成本迅速增加。信息集中化成了一種不可阻擋的趨勢。云計算讓我們又回到了新的歷史起點。
本文介紹基于私有云計算架構的軟件開發生命周期管理服務，涵蓋了虛擬化的IT基礎設施服務管理，中間件應用優管理和開發軟件代碼托管服務。如何通過對這三方面的管理策略提升服務水平是本文的核心內容。
云計算帶來的軟件生態環境的改變
云計算帶動了很多行業的發展也產生了很多新的行業領域。比如虛擬化技術，數據存儲技術和大數據(Big data)。這些變化帶來了很多機會，同時也對目前的企業提出了嚴峻的考驗。這要求企業的IT基礎架構具有更大的彈性，并保證具有高可用性。
從外部環境來看，軟件研發從早期的后臺計算模式，客戶機/服務器模式到，瀏覽器/服務器模式再到云計算時代。從面對百萬客戶機模式到數十億移動設備。
從企業內部環境來看，從僵硬的基礎架構到一個彈性云基礎架構;結構化數據到大量非機構化數據;靜態應用程序要動態服務;從被動安全策略到智能主動保護等。
云計算基礎架構特點
IT架構高可管理性 資源池化，彈性服務;自由遷移，按需服務;
在傳統的非云計算場景下，物理服務器通常只被單一租戶的單一業務使用，所以單臺服務器的利用率會比較低。隨著業務的擴展，需要不斷增加服務器的數量，這樣會使得數據中心的規模越來越龐大。相反資源利用率低下造成資源重復購買和現有資源的浪費。在云計算的場景下，由于數據中心為大量而不是單一的業務單元或用戶提供服務，所以業務量會極其龐大。靠不停地增加物理服務器對于成本和網絡規模來說都難以接受。虛擬化技術使得一臺物理服務器可以被虛擬成多臺服務器來使用，從而利用了原本閑置的資源，提高了服務器的使用率，所以使用相對較少的物理服務器就能滿足大量的業務需求。通常對于多核CPU的服務器來說，可以虛擬成每個CPU一個虛擬機來使用。當然虛擬化還要受到硬盤的每秒I/O數和內存的限制。
除了提高使用率外，虛擬化還使得服務器自由遷移變成可能。在傳統的數據中心，進行服務器的遷移是一項非常浩大的工程。必須事先進行規劃，需要謹慎計劃割接時間，做好備份。服務器需要進行斷線斷電，搬移，重新上電上線，通常業務會中斷，所以搬遷服務器是極少發生的。而使用了虛擬化技術以后，虛擬機的遷移不再涉及到物理上的搬遷。并且可以使用各種技術，例如漸進式內存復制等方法使得遷移平滑進行，保證了遷移時用戶不感知，相關業務不中斷，不受影響。
提升業務連續性虛擬化容災備份降低維護成本
自由遷移為數據中心的容災備份，節能環保，為網絡優化提供了不可替代的便利。
云集算軟件研發小故事
云計算帶來了諸多便利，但是同時對于普通人來說又非常難理解，我們來講一個云計算實際應用中的故事來讓大家對云計算有一個形象的了解。
某公司的小王剛剛晉升為項目經理，負責一個新產品的開發工作。項目處于初始階段，對于剛剛組建的團隊的小王，如何建立一套新的軟件產品研發環境感到很無助。不過當小王看到了一封公司內部云計算代碼托管服務的推廣郵件時眼前一亮。郵件的主要內容是只要簡單的為項目成員申請對應權限的帳號，建立一個項目就可以開始開發工作了。
于是小王訪問了郵件中的統一用戶服務網站并提交一個建立項目和注冊項目成員的請求，有趣的是當選擇建立新項目請求類型時，在請求說明中顯示出建立新項目的收費模式，以及服務的質量說明信息。
過了十幾分鐘小王和他的團隊成員收到了RTC項目添加新成員的邀請函。內容是新項目的訪問地址和用戶認證信息。RTC 服務默認包括了需求管理系統，任務管理系統，代碼管理工具，和測試用例管理系統。小王的團隊很快就開始了開發工作。
過了一個月代發開發的比較順利但是總是在集成的過程中出現錯誤，于是小王就把這個問題提交到了統一用戶平服務網站中，很快得到了服務管理員的回復，并建議小王使用持續構建服務。在服務管理員的幫助下把構建過程輸入到了Build Forge服務器中。并設定了定時構建的周期。之后再出現構建失敗的情況就可以查看構建服務器提供的版本比較功能定位哪些文件的改動導致了構建失敗了。
過來三個月，小王的產品作出了原型系統，銷售反饋市場反映很好，但是有很多需要改進的部分。于是小王的團隊開始快速擴張，新招聘的人員對RTC的開發環境很不熟悉。小王又找到服務管理員，這次小王對得到的答復同樣很滿意。原來針對開發平臺有一個知識庫系統，只要搜索“用戶手冊”就可以得到關于如何上傳代碼如何做構建的幫助。并且還有定期的培訓活動。
過了半年，小王的團隊人員從原來的十幾個人擴充到100人，而且還有國外的同事加入。這時小王從每月一次的服務反饋報告中看到隨著團隊人員數量增加，性能下降的警告。小王心想近期又有一個重要的版本需要發布，如果升級開發環境會停機影響開發進度可就麻煩了。小王找到了服務管理員詢問服務升級的影響。當得知服務架構是模塊化的簡單操作就可以實現服務升級，并不影響用戶使用時小王很高興。
又過了一年，在這一年中服務平臺從未停機維護這也為小王的團隊節省了不少時間。小王負責的產品順利進入到了維護期，開發人員的數量逐漸減少，在小王收到的服務反饋報告中提到目前開發員數量不斷下降，導致性能過剩，可以釋放部分資源節省成本。小王回想起以前項目購買硬件自己搭建開發環境是多么艱難，可這一切隨著云計算的到來一去不復返了。小王也自信的開始準備另外一個新產品的研發工作了。
通過上面的小故事，看起來云計算是那么的簡單易用和按需配置，但是在云計算的背后有很多不被用戶了解的知識和技術。如果想了解云計算是如何做到上面故事中講到的種種便利，需要在軟件服務，中間件管理和硬件架構中去尋找答案。
軟件開發代碼托管服務的業務驅動模式和需求
由上面的小故事引出了軟件研發生命周期中針對代碼托管服務的業務驅動模式。
針對業務需求把ITIL中的服務原型實例化，從而得出以下類型服務。
▲圖 1-1 服務分類
服務的可視化如圖 3-4 所示。這種可視化方法有助于服務管理職能和流程之間更好的溝通和協調，它有助于服務提供商更準確地定義服務。
服務原型U1獲取服務：釋放，獲得許可，提供
服務實例：快速建立開發環境,為用戶建立對應的賬戶和訪問許可，并以郵件形式通知客戶。
服務原型U2服務管理：管理，運作，維護
服務實例：使用統一用戶服務網站收集用戶需求，對服務進行管理和維護。
服務原型U3服務治療：修復，復原
服務實例：使用云計算架構和應用層冗余自動的修復服務，使服務達到24*7服務標準。
服務原型U4服務保管：存儲，保護，監控
服務實例：對云計算基礎架構，中間件和軟件中的業務信息進行監控，獲取服務的運行數據。
服務原型U5服務運作：運行，完成，記錄
服務實例：在統一用戶服務網站中，對每一個用戶請求的運行和完成結果進行記錄。
服務原型U6服務評估：分析，評估，審核
服務實例：使用監控信息對服務的運行進行分析和評估，對平臺的安全性定期審核。
服務原型U7服務更改：修改，改變，傳送
服務實例：通過云計算平臺的按需分配特性修改使用使用的硬件和網絡資源。中間件WAS集群動態配置負載能力。
服務原型U8創新服務：設計，開發，加工
服務實例：推出定制化客戶開發工具集服務。
服務原型U9溝通服務：連接，集成
服務實例：在開發環境中為客戶集成持續集成工具Build Forge和UrbanCode 產品uDeploy用以實現DevOps
京公網安備 11010502049343號