某科技研發(fā)云計算心酸史之工作總結(jié)

工作總結(jié)〔2024年11月～2024年9月〕虛擬化根底架構(gòu)業(yè)務(wù)部王毅2024-9-24

目錄1.概述 42.工程 52.1云計算效勞底層核心 52.2云計算效勞管理系統(tǒng) 132.3云計算效勞監(jiān)控系統(tǒng) 162.4彈性計算應(yīng)用 172.5云計算效勞計費系統(tǒng) 182.6云計算效勞用戶中心系統(tǒng) 192.7云效勞網(wǎng)站 192.8云效勞網(wǎng)站內(nèi)容管理系統(tǒng) 202.9企業(yè)私有云實體機柜操作系統(tǒng) 202.10企業(yè)私有云實體機柜監(jiān)控系統(tǒng) 203.團隊建設(shè) 203.1初期 203.2中期 203.3后期 204.總結(jié) 20

1.概述從2024年11月份至2024年九月份，我主動要求接受公司分派的云計算開源軟件OpenStack的研發(fā)任務(wù)，到至今已經(jīng)完成云計算產(chǎn)品效勞的大局部功能，并基于已經(jīng)研發(fā)出來的功能生產(chǎn)出一系列的軟件產(chǎn)品共花了11個月的時間。在這11個月的時間里，無論是對于產(chǎn)品工程的開發(fā)、云計算底層效勞研發(fā)，還是團隊建設(shè)等方面都遇到了不同程度的問題和困難。虛擬化根底架構(gòu)業(yè)務(wù)部從剛剛開始的“IaaS組〞到現(xiàn)在成為部門，人員也由最初的四個人開展到現(xiàn)在的13個人。以下是我從工程和團隊建設(shè)兩個方面著手，將問題融入到工程和團隊建設(shè)當中來進行虛擬化根底架構(gòu)業(yè)務(wù)部的工作總結(jié)。

2.工程目前虛擬化根底架構(gòu)業(yè)務(wù)部圍繞著云計算底層效勞的研發(fā)所完成的工程比較多，主要包括?云計算效勞管理系統(tǒng)-PUBECM?、?云計算效勞監(jiān)控系統(tǒng)-PUBECC?、?彈性計算應(yīng)用-ECA?、?云計算效勞計費系統(tǒng)-CSBS?、?云計算效勞用戶中心系統(tǒng)-CSUC?、?云效勞網(wǎng)站-CSNT?、?云效勞網(wǎng)站內(nèi)容管理系統(tǒng)-CSMS?、?企業(yè)私有云實體機柜操作系統(tǒng)-PRVECM?、?企業(yè)私有云實體機柜監(jiān)控系統(tǒng)-PRVECC?等。其實，作為云計算效勞底層的研發(fā)工作，也可以算是一個主要的工程，畢竟它是我們云計算效勞底層的核心。2.1云計算效勞底層核心2024年11月，由于當時我還在楊穎部門下作為一個組的組長，我們所接受的任務(wù)是ESDP的開源和ESDP的開源網(wǎng)站的開發(fā)。我們組準確的來講一共只有四個人，在接觸了云計算效勞開源軟件OpenStack以后，由于我跟同組的凌志對OpenStack的云存儲局部“swift〞從安裝到使用都已經(jīng)進行完成，所以也不得不對OpenStack的虛擬機局部對曉明進行輔助性工作。當時云計算開源軟件OpenStack給我的感覺是必須集中精力，才能夠順利的進行，因此我主動要求承接云計算效勞開源軟件OpenStack的研發(fā)工作。在研發(fā)初期，我們主要的精力還是對于OpenStack的集群式安裝部署，因為OpenStack是一個開源性的軟件，除了它自己的開源工程，包括云存儲〔swift〕、云虛擬機〔nova〕、鏡像效勞〔glance〕、統(tǒng)一身份認證系統(tǒng)〔keystone〕、管理系統(tǒng)〔當時被叫做“dashboard〞，后來改稱為“horizon〞〕之外，還包括其他的一些開源的軟件工程效勞。如：數(shù)據(jù)庫效勞〔mysql〕、時鐘效勞〔ntp〕、消息隊列效勞〔rabbitmq〕、虛擬效勞器遠程效勞〔noVNC〕、網(wǎng)絡(luò)效勞〔network〕、訪問工具〔ecua〕、卷組效勞〔volume〕等等。各個效勞之間首先必須安裝正確，在安裝正確的根底之上通過配置文件的相互配置才能夠到達想要的功能效果，除此之外各個效勞之間的安裝還存在一個順序的問題，所以要順利的安裝集群部署就需要反復的實驗，為了保證實驗的正確性和準確性，我們有的時候不得不要求將效勞器進行重新格式化；之所以格式化的主要原因是卸載往往有的時候是無法卸載干凈的，同樣的安裝過程，對于卸載的效勞器有的時候能成功；而有的時候卻成功不了，這大大干擾了我們的安裝思路。后來公司不允許進行效勞器的重新格式化，原因是效勞器所在集裝箱的機柜不能夠經(jīng)常反復的開啟，對效勞器機柜內(nèi)的溫度有很大的影響，容易造成效勞器的損壞；由于效勞器當時在八角樓C4機房，我們只有使用的權(quán)限，對于有的時候所發(fā)生的效勞器死機需要重啟等工作，我們只能間接的通過網(wǎng)絡(luò)部來配合進行完成，而網(wǎng)絡(luò)部負責這項工作的王燁輝的工作也很忙，我們很多時候不得不進行等待，這也給我們的工作帶來了一定的困難和麻煩。當時我們效勞器在機房中一共擁有20臺效勞器，為了能夠在溝通和管理上方便，我針對于效勞器進行了從1#～20#的編號，其中15#～19#五臺效勞器是DELL的R410效勞器，其他效勞器是2GB的內(nèi)存配置。為了保證安裝腳本在我們自己掌控下順利進行，我決定將八角樓的效勞器中的1#機和2#機搬到了辦公地點作為云存儲的腳本安裝及功能測試；后來張亞麗組的張志楠和張賀軍的參加所帶來的兩臺惠普效勞器成為了辦公地點虛擬機的腳本安裝及功能研發(fā)和測試的環(huán)境，通過這四臺效勞器組成了我們的辦公地點的實驗環(huán)境。但是為了能夠徹底解決OpenStack底層各項效勞之間的搭配工作，能夠準確的找到問題的出現(xiàn)位置，鎖定效勞目標；我采取了將效勞器各個效勞單獨存放至一臺物理效勞器當中，來進行功能性驗證和觀察。準確的來講在C4八角樓機房里有18臺效勞器供我們使用，但是由于不能夠經(jīng)常性的重新格式化效勞器和經(jīng)常性的進入效勞器機房，所以我們對于C4機房中的18臺效勞器的使用非常慎重，當然也大大影響了我們的工作效率。OpenStack的官方網(wǎng)站，只是介紹了外表層次上的大體原理，以及各個效勞之間的相互作用效勞，但是像ntp、rabbitmq這樣的其他開源效勞是沒有介紹的，我們所找到的線索完全得益于從網(wǎng)上下載某些志同道合的網(wǎng)友所提供的安裝部署文檔；但是想要到達和解決各個效勞以單獨物理效勞器提供效勞的目的，這項工作仍然非常的艱難。為了防止機房效勞器的重新安裝，我下令讓研發(fā)人員在自己的臺式機上通過virtualbox安裝虛擬效勞器，我們自己的臺式機箱只有2GB的內(nèi)存，最多也就可以跑三臺虛擬機，所以只能在這三臺虛擬機上跑安裝腳本，另外由于我們的臺式機CPU等配置不支持虛擬化，所以我們只能夠通過返回的命令行提示來確定是否安裝成功，但創(chuàng)立虛擬機是得不到任何驗證的；同時我們只能關(guān)掉一局部已經(jīng)安裝了虛擬效勞器后再跑其他的虛擬效勞器，花在查看上的時間非常多，更不要說再遇到問題和解決問題了。在這個工作過程的進行當中，我們實驗環(huán)境效勞器所在機柜的PDU壞了，對于PDU的采購花了很長一局部時間，大概有一個月左右，這也導致了我們的工作無法在實驗環(huán)境的18臺效勞器中進行。我們只能在自己的臺式效勞器里的虛擬機中跑我們的腳本。在初期的過程中，我們并不敢跑大的虛擬機鏡像，而是采用了OpenStack官方?jīng)]有操作系統(tǒng)界面，只有命令行的小型ubuntu鏡像。在整理和跑通安裝腳本并等到實驗環(huán)境的PDU修復后，我們才得以反復進行我們的安裝腳本的實驗，這個時候我們的卸載腳本也已根本成熟。可以說安裝部署方面的問題已經(jīng)根本上得到了解決。公司還要求可以自動進行安裝部署，為了實現(xiàn)這個目標，我們將實驗環(huán)境的12#效勞器當作我們安裝部署的資源機環(huán)境，安裝部署資源大概占到了40GB左右。之所以需要一個資源機，是因為在我們的安裝過程中，經(jīng)常遇到了版本不統(tǒng)一和不一致所導致的無法安裝成功，究其根源在于采用apt-get的方式安裝都是采用網(wǎng)上資源進行下載后的安裝，地址是一樣的，版本卻改變了。OpenStack當時還相當?shù)牟怀墒?，源代碼更新比較快，同樣的安裝地址，昨天還可以正確安裝并安裝成功，轉(zhuǎn)過天來就會出現(xiàn)有些命令都執(zhí)行不通的情況出現(xiàn)，Keystone〔身份認證〕和glance〔鏡像效勞〕的安裝版本不一致就導致了我們很長一段時間對于Glance的命令執(zhí)行不得不采用EC2工具繞過了Keystone。最終的解決是將版本統(tǒng)一后，將glance的安裝步驟和Keystone的結(jié)合安裝過程順序進行倒置才成功的。在以上工作完成的根底上，由我完成了OpenStack的手動安裝文檔的初版編寫，和一個版本的腳本自動安裝部署由張賀軍來完成的，但是對于公司的要求我們還是有很大一段距離的。比方說，對于不同的開源效勞對效勞器都有不同的要求，mysql數(shù)據(jù)庫效勞要求內(nèi)存和CPU；Volume卷組存儲效勞要求硬盤多一些，glance鏡像效勞要求內(nèi)存更大一些；控制節(jié)點的要求比較一般，計算節(jié)點那么對內(nèi)存要求非常高；rabbitmq消息隊列效勞要求網(wǎng)絡(luò)；network也需要網(wǎng)絡(luò)和效勞器內(nèi)存給予很好的支持；還有目前對于network和quantum效勞最好是能夠進行效勞器的單獨支持；存儲效勞方面，代理節(jié)點的要求一般，但是存儲節(jié)點需要有內(nèi)存和硬盤的支持等等。需要考慮的是效勞器本錢的降低以及整體效勞的優(yōu)化等方面的原因，將效勞安排在指定的效勞器，并自動進行修改配置；其實，在有了資源效勞器的支持以后，腳本安裝和人為的手動安裝方面的速度是相差不大的。從安裝的正確性和準確性以及成功率上來講，手動安裝更加保質(zhì)保量。我號召團隊成員多關(guān)注QQ群中全國的競爭對手的情況，競爭對手的情況要比我們好很多，無論從實驗環(huán)境方面還是人員構(gòu)成方面都令我們羨慕不已，為了不落后于競爭對手，我要求在進行以后工作的同時著手將云計算效勞底層的一些功能接口進行了梳理，包括統(tǒng)一身份驗證效勞〔keystone〕、鏡像效勞〔glance〕、云主機效勞〔nova〕和存儲效勞〔swift〕等接口功能。這些接口功能也為后來的各項云計算效勞產(chǎn)品工程的開發(fā)打下了良好的根底。OpenStack是用python語言開發(fā)的，在官方上有很好的接口效勞文檔，通過官方接口文檔的描述，我們知道OpenStack是采用的http協(xié)議的Restful接口技術(shù)實現(xiàn)的，類似于通常所說的WebService接口效勞技術(shù)。對于接口的調(diào)用，研發(fā)人員從網(wǎng)上下載了針對于存儲效勞的兩種接口調(diào)用源代碼，一個是java的；另一個C#語言的。通過接口對于現(xiàn)有的功能的理解后，我對云計算效勞有了更加深刻的理解，主要是云存儲和虛擬機兩個方面；我認為可以建設(shè)一個云效勞的網(wǎng)站，可以提供類似于網(wǎng)盤效勞以及虛擬主機的同時，還可以將企業(yè)的應(yīng)用效勞做在創(chuàng)立虛擬機的鏡像當中，這樣就實現(xiàn)了網(wǎng)上的SaaS平臺，并通過郵件的方式向陳巖光副總提交了我的想法。由于當時公司想要一個比較絢麗的，所以.net的silverlight可以到達要求。張亞麗部門就負責了云效勞網(wǎng)站的開發(fā)工作，我們作為底層對他們提供接口效勞，他們最先的工作主要是云存儲。我讓開發(fā)人員將接口源碼進行了梳理，為了能夠更好的給張亞麗部門的于彪組提供更好的效勞支持，我讓王琳將C#接口的源代碼進行有效的整理和分割，我讓凌志將swift做了安裝部署后，為于彪組提供關(guān)于云存儲的技術(shù)效勞支持。雖然溝通方面我們也經(jīng)常在見面打招呼的時候詢問是否有什么問題，但是接口方面的技術(shù)支持也總是斷斷續(xù)續(xù)。為了驗證在鏡像中放入大的應(yīng)用效勞，在啟動虛擬效勞器時可以將作在鏡像當中的應(yīng)用效勞進行正常的使用，我們制作了包含國外SAP應(yīng)用的效勞鏡像，該鏡像的制作過程中也遇到了很多的問題和麻煩，首先需要將多個光盤的安裝文件進行合并，這個SAP效勞的安裝文件一共有200多個GB，其中安裝文件有四個，主要的安裝文件就有200多個GB，當時在這個地方就存在著一個問題，就是將四個安裝文件進行合并，合并成功以后再上傳至效勞器中。但是我們的合并沒有成功，主要原因是安裝文件太大了，普通的效勞器或者臺式機在進行合并的過程中需要花費很長的時間，并且經(jīng)常是等待很長的時間，不知道計算機是否還在進行著合并過程。在我的直覺和猜測的引導下，我決定不進行安裝文件的合并，以200多GB的主安裝文件來進行應(yīng)用的效勞器安裝和鏡像的制作。鏡像制作成功后，另外一個問題就是由于實驗環(huán)境效勞器性能的影響，通過鏡像效勞glance上傳鏡像需要花費很長的時間，而且上傳至glance所在的物理效勞器以后，再上傳至計算節(jié)點物理效勞器，又需要鏡像的長時間拷貝；這個在當時OpenStack的Diablo版本中是無法進行鏡像上傳進度的提示的，直到我們后來升級為OpenStack的Essex版本以后才得以解決。最終我們成功實現(xiàn)了將大的應(yīng)用效勞SAP放置在已經(jīng)制作完成的鏡像文件中，并成功啟動該鏡像的虛擬機，由于實驗環(huán)境效勞器的影響，速度非常慢。在進行了目前現(xiàn)有功能和參考網(wǎng)上其他云效勞產(chǎn)品功能以后，我篩選出了我們還沒能夠?qū)崿F(xiàn)的功能，其中包括增開虛擬機外網(wǎng)代理、虛擬機實例快照、虛擬機負載均衡、虛擬機雙機熱備、虛擬機實例遷移、外部接口調(diào)用修改虛擬機主機名稱、虛擬機時區(qū)不同時、Glance于Swift效勞的整合、虛擬機計算節(jié)點運行狀況監(jiān)控、虛擬機配額限制效勞、多控制節(jié)點集群、接口控制虛擬機網(wǎng)絡(luò)帶寬流量、提高OpenStack數(shù)據(jù)庫的穩(wěn)定性等等功能。這些功能有些成功的實現(xiàn)了，但是也有受制于實驗環(huán)境、網(wǎng)絡(luò)環(huán)境的限制以及研發(fā)團隊技術(shù)能力方面的影響，我們沒有成功。對于功能的實現(xiàn)我決定必須本著幾個原那么入手：1.在進行功能性實驗前必須寫好實現(xiàn)方案，以功能為單位進行方案文檔的編寫，方案好步驟，并按照步驟一步一步進行實驗；2.不管成功與否，對于出現(xiàn)的問題以及針對問題進行的解釋性記錄必須落實在實現(xiàn)方案的文檔上；3.如果實現(xiàn)方案最終成功，對成功的實驗功能進行總結(jié)；如果不成功，說明不成功并注明不成功的理由或者是疑心理由；以備將來進行針對性解決。為了能夠從根本上解決底層中出現(xiàn)的大量Bug和幫助我們將來的研發(fā)工作，我認為研發(fā)團隊中的每個人必須對OpenStack大體結(jié)構(gòu)框架有非常準確和清晰的把握，在此根底之上才更加有把握進行源代碼的修改和二次開發(fā)整合。我?guī)е鴪F隊中的局部人員進行了文檔的翻譯性工作，在翻譯工作的過程中也是我能夠確定的了解到官方文檔只是外表上的介紹或者接口功能的介紹，對底層功能的研發(fā)意義雖然有但是卻并不大，這也是我錯誤的認識了開源軟件這個概念。正在這個關(guān)節(jié)上，OpenStack的Essex版本發(fā)布了，官方網(wǎng)站上很多文檔進行了更新，我們有局部的文檔的原有依據(jù)喪失了，只能憑借我們版本庫中所存儲的原有文檔進行翻譯性的查看。我們通過對官方網(wǎng)站上的資料查看以及網(wǎng)上搜索到的信息資料，發(fā)現(xiàn)新版本的Essex改變了原來的Diablo版本中的很多缺乏，也包括我們目前所無法解決的Bug，比方鏡像效勞glance上傳鏡像時的上傳百分比的現(xiàn)實；最讓人感到抑郁的底層的數(shù)據(jù)庫表結(jié)構(gòu)的改變非常的大，這讓我們花費了很多功夫在Diablo版本上的功夫很有可能是白做了?？墒牵簿褪窃谶@個時候，公司的SaaS平臺需要上線，我們要負責底層的虛擬化環(huán)境的搭建，我們需要為SaaS平臺網(wǎng)站提供集群式部署的效勞器，統(tǒng)計下來SaaS平臺需要30到40臺不同配置的高性能虛擬效勞器來進行支持。我們也從網(wǎng)絡(luò)運維部門獲得了8臺R710和1臺R810，另外我們給了網(wǎng)絡(luò)部幾臺R310并給了所有的R410作為正式生產(chǎn)環(huán)境的效勞器，提供其他效勞的支持。有幾個問題明顯的擺在我的面前，正式生產(chǎn)環(huán)境就要上線了，底層效勞的Diablo版本還有很多Bug和不穩(wěn)定的因素，在此根底上搭建正式生產(chǎn)環(huán)境，很多問題是無法應(yīng)付的；將來在此根底上升級風險性是可想而知的，耽誤了效勞怎么辦？因為一旦SaaS平臺一旦給公司帶來盈利，賺錢的話，每一分鐘、每一秒鐘都是耽誤不起的；OpenStack的Essex新版本已經(jīng)解決了原有的很多Bug問題，數(shù)據(jù)庫底層也與原來的版本發(fā)生了很大的變化；最重要的特點是Essex在網(wǎng)絡(luò)方面提出了新的效勞quantum；究竟采用Diablo版本還是Essex版本，前者對于將來研發(fā)的風險性很大，同時我們很可能會出現(xiàn)研發(fā)方向的迷失，而對于后者如果我們成功搭建完成的話不但可以解決老版本殘留的問題，對于將來的工作可以開辟出大片的空間；最終的結(jié)論是Diablo版本的風險會發(fā)生在將來，而Essex版本的風險性就在當時，因為我們還沒有成功集群式安裝?？墒牵彤敃r的情況而言，基于低配置實驗環(huán)境的安裝，不可能；但是有了正式的生產(chǎn)環(huán)境，明擺著的更好的實驗環(huán)境，不如拼一把。我把我的想法告訴了我的團隊，在跟陳巖光副總進行溝通以后，我們在正式生產(chǎn)環(huán)境上基于新的Essex版本搭建了云計算效勞平臺。后來的事實也證明，我的這個決定是正確的。云計算效勞底層核心效勞的研發(fā)方面，目前具備了大局部的虛擬機的功能，在整個團隊的這11個月以來，根本上是兩個方面的工作內(nèi)容，一個是對基于云計算效勞核心底層的上層產(chǎn)品的接口和技術(shù)支持、環(huán)境的維護；另一個就是云計算效勞的核心研發(fā)這兩個方面的工作；對于基于研發(fā)的文檔知識積累，我認為這一點非常的重要，研發(fā)工作必須落實在文檔上面，盡管絕大局部研發(fā)人員對于文檔不夠重視，但是當遇到問題的時候，原始的文檔就提供了必要的幫助。2.2云計算效勞管理系統(tǒng)云計算效勞管理系統(tǒng)是最早完成的一個系統(tǒng)工程，當時OpenStack對于云計算效勞底層擁有一個軟件界面可以操控的系統(tǒng)，名稱叫做“dashboard〞，后來官方將其改名為“horizon〞，“horizon〞這個軟件系統(tǒng)是用python語言進行開發(fā)的，在安裝過程中也是需要進行配置文件的配置修改，基于mysql數(shù)據(jù)庫來進行存儲業(yè)務(wù)數(shù)據(jù)，其他就是調(diào)用OpenStack的相應(yīng)接口，來實現(xiàn)給用戶進行云計算效勞的界面操作。對于“horizon〞這個被OpenStack囊括在其內(nèi)的云計算效勞操作系統(tǒng)來說，它有幾個不好的地方：1.完全基于OpenStack云計算效勞的底層功能接口和進行模塊的劃分，如果不了解OpenStack的原理的話，是無法理解并使用和操作的；2.缺乏人性話，也就是在客戶體驗性方面做的還差一些，頁面顯示也不是很美觀，比方：它沒有分頁的操作，更不要說對于模糊的查詢操作了?；谶@些特點，我編寫了適合我們進行操作的云計算效勞操作系統(tǒng)的需求并進行了業(yè)務(wù)方面的設(shè)計。為什么要提出這個系統(tǒng)工程，我主要是基于以下幾個方面的原因：1.對于云計算效勞底層，我們需要有自己的操作系統(tǒng)軟件，這個毫無疑問是必須的；2.對于我們已經(jīng)實現(xiàn)的接口效勞，沒完沒了的通過命令行進行加以驗證相當麻煩。另外，該系統(tǒng)也是我們接口功能逐漸實現(xiàn)和確認的一個終點，可以完全表達我們的工作，我們實現(xiàn)的功能，還有我們的價值；3.這個操作系統(tǒng)目前可以給我們自己進行使用，隨著逐漸的優(yōu)化和改良，將來早晚會成為公司的產(chǎn)品，我們的工作是有用功，將來不會白做；4.該操作系統(tǒng)效勞當中包含著我們已經(jīng)實現(xiàn)的接口調(diào)用，可以把它比作一個活字典，對于接口源代碼的調(diào)用可以準確的找到位置并進行復制和粘貼，為將來其他產(chǎn)品工程的開發(fā)打下良好的根底。從后來的各個系統(tǒng)工程效勞來說已經(jīng)印證了這一點；這也是我們?yōu)槭裁春髞硐到y(tǒng)工程得以快速開發(fā)的主要原因。當然，在該系統(tǒng)工程的開發(fā)過程中，也遇到了很多的問題，比方對于一些業(yè)務(wù)數(shù)據(jù)，我們采取的是沒有調(diào)用OpenStack所提供的接口效勞，而是通過對OpenStack底層中各個效勞所涉及到的數(shù)據(jù)庫及數(shù)據(jù)庫表結(jié)構(gòu)之間的邏輯關(guān)系進行關(guān)聯(lián)性方面的數(shù)據(jù)檢索，當然這必須建立在我們對OpenStack數(shù)據(jù)庫表結(jié)構(gòu)相當了解的根底上。另外，有很多接口在OpenStack效勞當中并沒有提供，必須通過調(diào)用命令行執(zhí)行才能夠做到，這個對于系統(tǒng)工程的響應(yīng)速度來講確實是慢了很多，但是能夠到達我們現(xiàn)階段的目的。在云效勞器資源和云存儲資源的監(jiān)控顯示方面，我們也有很大的問題，比方云存儲，我們沒有方法通過接口獲得剩余的存儲資源、已使用的資源，我們就不得不通過人為設(shè)定系統(tǒng)總的存儲資源，通過命令行調(diào)用獲得存儲已經(jīng)占用的資源，剩余的那么就是未使用的存儲資源等等。對于統(tǒng)一身份驗證〔Keystone〕來講，在Diablo版本中它是有超級管理員用戶的，它可以管理所有的租戶和租戶下的用戶，但是對于后來的Essex版本來講是沒有超級管理員用戶的。對于這一點，OpenStack的“horizon〞效勞當中也是以一個租戶為單位進行登錄并進行效勞的。從這一個角度來講，我認為OpenStack效勞還是面向于大批量集群式公有云效勞的，因為“公有云〞往往給我在概念上的理解就是“資源無上限〞。目前該系統(tǒng)工程的工程名稱我給他取名字叫做“pubecm〞。這個系統(tǒng)工程目前的缺陷是瀏覽器兼容方面還有一些問題，功能上很多還沒有來得及增加；由于當時最初的目的是給我們自己使用的，所以頁面風格沿用了2024年公司聯(lián)查時的系統(tǒng)工程的玻璃質(zhì)感風格。但是，在隨后的企業(yè)私有云實體機柜的操作系統(tǒng)誕生后，企業(yè)私有云實體機柜的操作系統(tǒng)囊擴了pubecm的所有功能，而且在頁面風格和美化以及客戶體驗等方面都完全超過了pubecm，我現(xiàn)在一直考慮以企業(yè)私有云操作系統(tǒng)取代該系統(tǒng)工程。因為企業(yè)私有云實體機柜的操作系統(tǒng)是從pubecm中升級出來的，它青出于藍而勝于藍一點都不為過。2.3云計算效勞監(jiān)控系統(tǒng)云計算效勞監(jiān)控系統(tǒng)是在后期為了能夠更好的監(jiān)控公司SaaS平臺正式生產(chǎn)環(huán)境而做的一個系統(tǒng)監(jiān)控工程。這個工程的需求和業(yè)務(wù)設(shè)計都是由我一個人來完成的。它主要包括這么幾個方面的內(nèi)容：整體概況、CPU使用情況、內(nèi)存使用情況、磁盤使用情況和存儲資源使用情況這五個方面對效勞器資源進行監(jiān)控。在這個系統(tǒng)工程開發(fā)的過程中，遇到的最大的問題就是資源的上限一直都沒有一個統(tǒng)一和準確的數(shù)據(jù)，在報警線數(shù)據(jù)方面我們也仍然沒有一個準確的數(shù)字。關(guān)于資源上限也就是指整個效勞的計算節(jié)點一共有多少核CPU，而這些CPU能夠虛擬出多少核的CPU，這些虛擬出的CPU最大數(shù)量就是它的上限數(shù)量，而真正使用了多少以后，它的效勞性能會降低或者說有很大的影響；這一點上我們一直沒有得到很好的解決。我對研發(fā)人員提出的要求是把OpenStack底層的算法搞清楚，通過它的算法和我們實際的參數(shù)我們得到它的上限數(shù)據(jù)；這個算法雖然是被研發(fā)人員掏出來了，但是對于具體的數(shù)據(jù)一直沒有一個準確的答案。最后沒方法，我們通過正式生產(chǎn)環(huán)境實際的數(shù)據(jù)庫中的數(shù)據(jù)得到準確的答案。在正式生產(chǎn)環(huán)境中，有其中一個生產(chǎn)虛擬機效勞器的計算節(jié)點，它內(nèi)部所生產(chǎn)的虛擬機的CPU總和是它實際CPU核數(shù)的3倍，運行狀況沒有任何的問題。3倍的這個數(shù)據(jù)對于我來講，已經(jīng)相當?shù)纳莩蘖?，所以我就?倍這個數(shù)據(jù)定為CPU的最大上限數(shù)量；對于內(nèi)存來講，OpenStack的官方給的參數(shù)一直都是1.5倍，也就是說生產(chǎn)虛擬機效勞器的計算節(jié)點物理機內(nèi)存的1.5倍是它能夠虛擬出的內(nèi)存的最大數(shù)量，因此我保守的將1.5倍作為了內(nèi)存最大上限的倍數(shù)參數(shù)。對于磁盤空間而言，它是不需要虛擬化的，剩余多少就是多少。這樣我們解決了監(jiān)控系統(tǒng)對于數(shù)據(jù)的監(jiān)控問題。2.4彈性計算應(yīng)用彈性計算應(yīng)用系統(tǒng)是為了能夠給SaaS平臺添加應(yīng)用而做的一個小型的創(chuàng)立虛擬機效勞器、給企業(yè)用戶分配虛擬機效勞器和銷毀虛擬機效勞器的一個小型的應(yīng)用。該應(yīng)用的需求設(shè)計和業(yè)務(wù)設(shè)計也是由我來完成的。該彈性計算應(yīng)用，就功能上來講該工程并不大，但是說到它當時的風險性也是與SaaS平臺底層的ESSEX版本搭建是綁定在一起的，這個應(yīng)用于SaaS平臺上的其他應(yīng)用相比，它很特殊，它的特殊性就在于它完全調(diào)用底層的接口創(chuàng)立虛擬機，而這些虛擬機是與支持SaaS平臺的虛擬機以及各個應(yīng)用所占用的虛擬機效勞器是平級的。因此首先為了能夠把握和控制住底層資源的限制使用而不影響SaaS平臺的其他應(yīng)用，我們必須開發(fā)一個彈性計算應(yīng)用的后臺管理系統(tǒng)，這個系統(tǒng)的目的是將底層的虛擬機效勞器規(guī)格〔CPU核數(shù)、內(nèi)存大小、磁盤空間〕同時到彈性計算應(yīng)用的業(yè)務(wù)數(shù)據(jù)庫中，通過管理員的篩選過濾掉大的規(guī)格，使注冊和登錄SaaS平臺的用戶只能夠創(chuàng)立和使用低配置的虛擬機效勞器。在進行該應(yīng)用的開發(fā)時，首先必須開發(fā)除了底層調(diào)用的其他局部，因為底層環(huán)境還處在搭建過程當中。最大的問題是當時我們還是IaaS組，組內(nèi)沒有專門的美工，美工需要從于彪組進行借用，當時于彪組負責美工的是郜帥；但是郜帥還負責于彪組的美工以及手機云存儲的頁面設(shè)計工作，對于彈性計算應(yīng)用的頁面美化方面肯定是精力投入的不會很多，但是開發(fā)任務(wù)也非常急。為了能夠到達頁面美化方面的要求，我組織組內(nèi)的開發(fā)人員周六都干起了美化的工作，他們都很盡力，但是他們畢竟不是美工專業(yè)人員，所以頁面沒有能夠到達我的要求，作為管理人員來講我是說不出什么來的。最終是由張云儷所管理的美工組后來又重新給改良的。2.5云計算效勞計費系統(tǒng)云計算效勞計費系統(tǒng)是公司陳巖光副總提出的一個工程，該工程的主要目的是支持云效勞網(wǎng)站的，對云效勞網(wǎng)站上的產(chǎn)品進行定價效勞的。由于我之前有過關(guān)于計費系統(tǒng)工程方面的經(jīng)驗，我針對于該系統(tǒng)工程進行了針對于客戶和業(yè)務(wù)統(tǒng)計方面的擴展，因為產(chǎn)品的價格是與供求關(guān)系以及產(chǎn)品的本錢密不可分的。對于客戶對產(chǎn)品的購置效勞，我們需要對于客戶有所了解和理解。比方，客戶的不同年齡段、不同的地域、企業(yè)還是個人等等對于產(chǎn)品的需求是不同的，云效勞網(wǎng)站作為公司云計算效勞對外的窗口而言，對客戶的分析以及對產(chǎn)品購置情況的分析還有客戶所關(guān)注的產(chǎn)品等等都需要進行統(tǒng)計，從統(tǒng)計分析中獲得我們想要的結(jié)論。隨后在與陳巖光副總的堅持下，將該計費系統(tǒng)進行了拆分，原計費系統(tǒng)被修改為只是對云效勞產(chǎn)品的類型和價格進行制訂；而對于用戶的統(tǒng)計和分析以及用戶注冊參數(shù)的制訂等被拆分并獨立成為用戶中心系統(tǒng)。這個系統(tǒng)的開發(fā)不涉及底層云計算的核心支持效勞，唯一需要關(guān)聯(lián)的就是需要將云計算效勞底層的鏡像〔操作系統(tǒng),windowsXP、ubuntu等〕和虛擬機規(guī)格〔CPU核數(shù)、內(nèi)存大小和硬盤空間〕同時到計費系統(tǒng)的業(yè)務(wù)數(shù)據(jù)庫當中來，并進行定價，以供云效勞網(wǎng)站獲取這些價格數(shù)據(jù)后，通過接口調(diào)用創(chuàng)立相應(yīng)的虛擬機。在頁面美化風格方面，由于是公司內(nèi)部自己使用，所以對于頁面風格仍然沿用了2024年公司聯(lián)查時統(tǒng)一的玻璃質(zhì)感風格。2.6云計算效勞用戶中心系統(tǒng)云計算效勞用戶中心系統(tǒng)是從計費系統(tǒng)當中拆分出來的一個系統(tǒng)工程，該工程的主要功能是面向于云效勞網(wǎng)站的用戶。該工程的需求分析和設(shè)計也是由我來完成的。該系統(tǒng)首先是通過參數(shù)管理模塊對云效勞網(wǎng)站注冊用戶所需要注冊的參數(shù)進行管理，比方所屬國家、所屬省市、所在行業(yè)、所從事職業(yè)以及用戶需要反響的問題類型及問題等等。再有就是對于客戶的充值、使用和剩余金額以及用戶對于不同產(chǎn)品的購置清單等等，系統(tǒng)中還包括用戶的統(tǒng)計功能，比方年齡、性別、針對于不同產(chǎn)品的不同購置人群的統(tǒng)計等。該系統(tǒng)工程并不涉及云計算效勞底層的接口調(diào)用，是普通的Web工程。由于是給公司自己內(nèi)部使用的，所以在頁面風格上仍然沿用的2024年公司聯(lián)查時的玻璃質(zhì)感風格。2.7云效勞網(wǎng)站云效勞網(wǎng)站是在SaaS平臺結(jié)束以后，由于彪組轉(zhuǎn)接給我們的。這個工程最初于彪組采用的是.net技術(shù)進行的研發(fā)。由于我們在外圍產(chǎn)品方面主要采用的是以java語言進行的開發(fā)，所以無論從需求分析設(shè)計、頁面設(shè)計還有底層代碼實現(xiàn)上，我們可以說是推倒重來的。該網(wǎng)站的主要起的作用是對公司云計算效勞的技術(shù)力量以及公司現(xiàn)有的云計算效勞產(chǎn)品對外進行展示的窗口。網(wǎng)站在云計算效勞的技術(shù)力量方面展示上提供云主機、云存儲和云硬盤三個云計算效勞技術(shù)力量的展示；在產(chǎn)品方面有企業(yè)私有云實體機柜實體產(chǎn)品和企業(yè)私有云方案兩種供網(wǎng)上用戶下訂單的方式進行推廣銷售。網(wǎng)站內(nèi)為用戶提供了用戶中心和控制臺這兩個模塊對注冊登錄用戶提供云計算的應(yīng)用效勞。由云計算效勞計費系統(tǒng)、用戶中心系統(tǒng)和網(wǎng)站內(nèi)容管理系統(tǒng)對該網(wǎng)站提供信息數(shù)據(jù)支持效勞。2.8云效勞網(wǎng)站內(nèi)容管理系統(tǒng)云效勞網(wǎng)站的內(nèi)容管理系統(tǒng)是對云效勞網(wǎng)站的內(nèi)容展示信息的后臺管理系統(tǒng)，該系統(tǒng)的主要內(nèi)容包括產(chǎn)品效勞動態(tài)管理、市場活動管理、客戶案例管理以及合作伙伴管理等功能模塊。該系統(tǒng)的業(yè)務(wù)需求前期是由我來完成，后期由李立召完成對需求文檔的編寫，并完成開發(fā)工作。2.9企業(yè)私有云實體機柜操作系統(tǒng)企業(yè)私有云實體機柜是企業(yè)私有云實體機柜內(nèi)的云計算效勞軟件產(chǎn)品之一，該系統(tǒng)主要面向于購置企業(yè)私有云實體機柜產(chǎn)品的企業(yè)網(wǎng)絡(luò)管理人員，由管理人員登入系統(tǒng)，進行虛擬效勞器的創(chuàng)立、快照備份、分配/釋放IP、升級、暫停、運行、銷毀等操作。該系統(tǒng)工程的需求分析和業(yè)務(wù)設(shè)計是由我來完成的。該系統(tǒng)工程是一個產(chǎn)品軟件，從頁面風格、客戶體驗還有功能的使用等方面都做到了全面的細化。在該產(chǎn)品的開發(fā)過程當中，也是由于云計算效勞底層核心的影響造成了功能不穩(wěn)定的情況，比方有的時候遷移成功，有的時候遷移不成功，有的時候升級成功而有的時候升級不成功。由于采用的是3臺R310的2GB內(nèi)存的低配置，創(chuàng)立的虛擬機只可以是512MB內(nèi)存的小型鏡像；所以有些bug不得不疑心是由于底層效勞器性能方面的影響，造成功能的不穩(wěn)定。后來從網(wǎng)絡(luò)部借用了2臺R710高配置的效勞器一周多的時間，問題才加以解決。2.10企業(yè)私有云實體機柜監(jiān)控系統(tǒng)企業(yè)私有云實體機柜監(jiān)控系統(tǒng)，也是企業(yè)私有云實體機柜內(nèi)的軟件產(chǎn)品之一。該系統(tǒng)的主要功能是對企業(yè)私有云實體機柜的物理資源機以及生產(chǎn)虛擬機的物理效勞器資源的監(jiān)控。該系統(tǒng)的需求分析、業(yè)務(wù)邏輯設(shè)計是由我來完成的。該系統(tǒng)產(chǎn)品工程的主要功能包括整體使用情況、效勞器情況、CPU使用情況、內(nèi)存使用情況、磁盤空間情況、外網(wǎng)IP數(shù)量監(jiān)控、虛擬機報警和資源及報警等幾個數(shù)據(jù)監(jiān)控模塊。面向于企業(yè)的數(shù)據(jù)中心管理人員，能夠直觀的查看企業(yè)私有云實體機柜的使用情況。3.團隊建設(shè)在團隊建設(shè)方面，我將虛擬化根底架構(gòu)業(yè)務(wù)部從最初的“IaaS〞組到現(xiàn)在一共分為初期、中期和后期三個階段，初期階段是從2024年11月份到年后在C6辦公到搬到B8樓的202之前；中期階段是我們在B8樓的202室的工作期間；后期階段是我們從B8樓的202室再次搬回到C6。在這三個階段過程中，對于團隊的建設(shè)也曾經(jīng)遇到了很多的困難和問題，畢竟從管理角度來講，團隊中的人員變動，哪怕只增加一個成員都會經(jīng)過形成期、震蕩期、表現(xiàn)期和正規(guī)期四個階段。在團隊建設(shè)方面我可以說投入了大量的精力，虛擬化根底架構(gòu)業(yè)務(wù)部的團隊成員大多數(shù)的能力都非常強，同時個性也非常強，尤其對于一直高新技術(shù)的團隊，管理的難度和強度是非常大的。從了解他們到理解他們，平穩(wěn)他們的工作情緒，改善他們的工作心態(tài)，提高他們的工作效率和工作質(zhì)量是非常費心的一項工作。3.1初期團隊人員統(tǒng)計表序號現(xiàn)有人員參加離開1王毅√2王凌志√3王琳√4張瑞祥√5張志楠√6張賀軍√7張志濤√8李健√總計8人在團隊建設(shè)的初期，我的團隊中包括我在內(nèi)一共只有四個成員，他們是我、王凌志、王琳和張瑞祥。從每個人的性格特點來講，王凌志是一個非常有靈氣的人，聰明、能干有想法、膽子大，認準的事情即使是錯誤的也敢作，如果做的事情方向正確，是非常得力的一個好幫手；但是缺點是，對待事情缺乏成熟的思考，這往往也是我為什么需要重點關(guān)注他的原因；王琳是一個Java開發(fā)人員，只對開發(fā)感興趣，對云計算可以說興趣不大，他的技術(shù)能力我非常認可，開發(fā)速度非?？欤瑢τ谟幸蓡柡筒煌囊娊飧矣诖竽懱岢鰜恚侨秉c和缺乏是，往往在某些開發(fā)過程當中采用了我個人認為不合理的設(shè)計模式；文檔的編寫能力上差一些，有待培養(yǎng)。張瑞祥的優(yōu)點是測試方面的技術(shù)、只是經(jīng)驗豐富，缺點是非常愛玩游戲，但是對于我的提醒和忠告他還是能夠聽進去的，在給分配安排工作后，還是可以做到扔下游戲主開工作的，但是工作完成的質(zhì)量方面也許個人能力的影響不是非常的好。由于工作的需要，從張亞麗組調(diào)配來了張志楠和張賀軍，張志楠是一個非常鉆研技術(shù)的人，工作起來有一股軸勁，認準的事情八匹馬都拉不回來，但是在我后來的教導和指引下，已經(jīng)改變了很多，在做事情的正確邏輯思維方向上有很大的進步。張賀軍為人性格膽小，但是做事情非常踏實和實在，在某些技術(shù)關(guān)鍵點上能夠提出合理的建議，并有讓我出乎意料的正確的想法；但是他們兩個人都有一個最大的缺點就是不善于表達，從這一點來說，這個缺點是非常致命的，肯定會影響到他們將來的職業(yè)開展。我往往在開會或者指定工作方案的時候盡量給他們說話的時機，讓他們可以盡情的表達出他們的想法，鍛煉他們的表達思維；雖然進展緩慢，但是效果比之前已經(jīng)好很多了。之后李健和張志濤參加了我們的團隊，李健是陳巖光副總從其他的云計算效勞公司挖過來的，在虛擬化云計算方面有過一到兩年的工作經(jīng)驗，對于虛擬化方面以及虛擬化的底層比我們熟悉很多，他的學習能力非常強，從工作狀態(tài)中可以看的出對云計算技術(shù)還是非常有熱情的，缺點也是在溝通上，他的溝通不像是賀軍那樣的先天的缺陷，而是過于保守。張志濤是我們部門當時急于需要的一個網(wǎng)絡(luò)、效勞器硬件方面的工程師，他往往給人的感覺是讓人放心，喜愛微笑，樂樂呵呵的，就是這樣一個表現(xiàn)讓我對他的人和工作方面的管理大意了。這個人在工作態(tài)度上還是很認真的，但是缺乏社會工作經(jīng)驗以及人際關(guān)系間的應(yīng)對，對于公司的管理制度難以適應(yīng)，以及在團隊當中的自傲性格使得他后來離開了公司，從對他的了解和關(guān)注方面來講，我需要負有一定的責任。隨著初期團隊的雛形逐漸成形，慢慢的團隊會進入到形成期，為了能夠加深彼此的了解，我請了團隊所有成員去“萬家燈火〞的一個餐館吃了一頓飯，大家在一起歡聲笑語，大吃大喝。我心里也非?？鞓?，但是心里的壓力也大，將來他們就是公司云計算的中堅力量和核心成員，他們能做到嗎。在飯桌上大家暢所欲言，我也說了我對將來的一些想法，希望大家能夠團結(jié)；工作方面多溝通多互相幫助。我也試圖跟他們每個人進行聊天和對話，了解他們的個人想法。3.2中期團隊人員統(tǒng)計表序號現(xiàn)有人員參加離開1王毅√2王凌志√3王琳√4張瑞祥√5張志楠√6張賀軍√7張志濤√8李健√9藍文靜√√10張磊√11李立召√12霍世彬√13程樂√總計10人中期主要是指我們由C6搬到B8的這段時間，也就是在B8的202工作的這段時間，在搬過去以后，我的團隊增加了藍文靜、張磊、李立召、霍世斌以及實習生程樂這些人員。藍文靜這個女孩就像她的名字所描述的那樣，是一個文靜的女孩，是做測試的，為了彌補張瑞祥在測試過程當中的疏漏，有文靜來進行彌補我也是非常放心的。文靜為人踏實，在文檔的整理以及翻譯的工作過程中是非常穩(wěn)重的；張磊是新招的開發(fā)人員，比較偏愛于UI。根本的工作技能偏向于頁面表現(xiàn)層方面，但是不好的是業(yè)務(wù)邏輯方面差一些，反響上稍顯遲鈍。這個需要慢慢的進行培養(yǎng)。李立召的技術(shù)扎實全面，工作態(tài)度認真，踏實穩(wěn)重，唯一不好的地方是思維視野方面還不夠開闊，這方面需要我給他時機來進行足夠的鍛煉。霍世彬性格上來講是一個可愛的小伙子，更剛來時從楊穎那反響來的“二〞來形容根本就是冤枉了他。網(wǎng)絡(luò)方面的技術(shù)比較全面，缺乏之處在于書本上的東西了解比較多，但是實踐上還是少了些。程樂是一個在校的大學生，沒有工作經(jīng)驗，是來公司進行實習的。性格比較孤僻，技術(shù)上根本的理論知識都是具備的，但是缺乏的是社會經(jīng)驗少，他給人的感覺是依賴性比較強但是又不想去依賴別人，后來的事實也證明了這一點。在團隊建設(shè)的中期開展階段里，我大局部的精力都花在了工作進展和工程的管理與設(shè)計過程當中，但是越是這樣，往往團隊當中發(fā)生的事情就越多，當然也有我所覺察到的和沒有覺察到的。首先，藍文靜提出了辭職，并離開了公司。最初對于藍文靜的定位還只是一個測試人員，但是由于局部的測試工作已經(jīng)完成的時候，為了防止人力資源的浪費，我開始讓她更多的接觸一些云計算效勞官方文檔的資料整理，在這方面的工作我是這樣理解的，雖然我們是以O(shè)penStack為切入點，以它為切入點向外進一步展開對云計算的研發(fā)，但是從根上來講還是要從OpenStack的官方文檔入口，并整理和梳理出我們自己對它的理解和認識，目前的人員狀況還不能夠完全有把握查看OpenStack的源代碼并基于源代碼進行修改以到達我的要求，再者隨著人員的不斷參加和擴大，我們也需要擁有自己的培訓資料，也就是說不管是誰、應(yīng)聘的什么職位，只要進入IaaS組，就必須對我們的云計算工作范圍和工作內(nèi)容有所了解，以到達工作上的溝通順暢，工作能夠保證擁有統(tǒng)一的步伐和步調(diào)。公司不允許進行組內(nèi)的知識性培訓，按照公司的理解，上班來不是上學來的這一原那么，我讓文靜在整理文檔并進行翻譯的同時，整理了一套python語言的培訓教程，通過定期的將文靜整理的資料跟大家共同探討的同時，順便將python語言進行了短暫的培訓。這也為后來組內(nèi)的研發(fā)團隊進一步深入OpenStack的研究和修改功能代碼打下了一個良好的開端。最終，文靜還是由于個人原因，因為她要結(jié)婚，所以必須到塘沽去追隨他的丈夫，而離開了公司。張瑞祥是由于公司部門內(nèi)部調(diào)整，因為公司的部門內(nèi)部成立了測試組，所以他離開我們的團隊，但是他所工作的測試范圍仍然是以我們組的軟件產(chǎn)品工程為主，所以我們還是有工作交集的。對于他愛玩游戲這一缺點，我私下里也跟他單獨談?wù)撨^屢次，我站在他個人的角度出發(fā)，提出要為自己的將來著想，游戲給他帶來不了什么，對他起不到任何作用和好處；我的這些良苦用心希望他將來能夠體會的到。張志濤的離開有他自己的原因，也有局部我的責任，我之前已經(jīng)說明過了。在B8樓202的工作工程中，除了對底層效勞研發(fā)、維護和對上層軟件產(chǎn)品工程開發(fā)的設(shè)計及管理方面的工作外。篩選待面試人員的工作簡歷并進行面試也成為了我日常工作過程中不可缺少的一局部，當然也是團隊建設(shè)過程中所必須的。工作也經(jīng)常被打斷，簡歷也經(jīng)常會收到很多份，并從中篩選出我需要的人員。立召和張磊都是這一時期吸納進來的開發(fā)人員。對于研發(fā)團隊的管理上，王琳可以說在云計算效勞產(chǎn)品的系統(tǒng)工程的研發(fā)方面功不可沒，因為之前的云計算效勞操作系統(tǒng)、用戶中心系統(tǒng)、計費系統(tǒng)，雖然需求分析、業(yè)務(wù)邏輯設(shè)計都是由我來做的，但是代碼的開發(fā)都是由他一個人來完成，在開發(fā)速度上因為采用的是他所熟悉的開發(fā)框架SSH+LigerUI所以非?？?。但是在制作彈性計算應(yīng)用時，他卻范了我認為致命的錯誤，他把彈性計算應(yīng)用的所有頁面作在了一個頁面文件當中，這也包括后來的監(jiān)控系統(tǒng)；后來在我得知到這個情況以后，專門在開會時找他詢問了這個問題。他從訪問速度、軟件性能以及前臺頁面異步調(diào)用的開發(fā)效率以及彈性計算應(yīng)用是一個小的工程等方面說明了他的理由，在聽取了他的意見以后，我認為我要考慮軟件工程整體的可擴展性，可維護性以及更加重要的合理性來考慮。為了能夠到達我的要求和目的，我讓張磊接手了彈性計算應(yīng)用的修改和維護工作，讓李立召全面接手了云計算計費系統(tǒng)和用戶中心系統(tǒng)這兩個工程的修改和維護工作。平均分擔了三個人的工作量，確實開發(fā)工作都壓在王琳一個人的身上也太不公平；王琳那么繼續(xù)底層接口效勞以及對張磊和李立召的指導和支援。對于云計算效勞底層的研發(fā)工作，我主張不能夠?qū)⑺械墓δ苄诳刂圃谀骋粋€人的手里。由于在凌志身上產(chǎn)生了不穩(wěn)定因素，所以我將OpenStack的新版本Essex的研發(fā)工作向賀軍和志楠方面有所傾斜；李健的精力集中在了基于核心的外圍功能的擴展方面，大局部的新版本研發(fā)工作，尤其是新版本的特性“虛擬網(wǎng)絡(luò)〔Quantum〕〞集中在了張志楠和張賀軍的手里，我對他們進行了模塊的劃分；為了能夠讓他們順利在運行過程中修改和調(diào)試底層擴展研發(fā)的代碼，我將剩余的實驗環(huán)境效勞器對他們進行了分配，使得他們可以在自己的集群中運行自己修改的代碼，并最終結(jié)合得到我們自己的一個版根源碼。這樣，對于底層云計算效勞核心代碼我們就能夠逐漸的進行自己掌控。后來，他們也都慢慢的做到了這一點。程樂是一個在校的大學實習生，他來自天大。從外表上來看文縐縐的，是一個干技術(shù)的料。在對待他的問題上，我把他委托給了王琳來作為他的指導老師，王琳是技術(shù)開發(fā)出身，包括我在內(nèi)很