某科技研发云计算心酸史之工作计划总结

《某科技研发云计算心酸史之工作计划总结》由会员分享，可在线阅读，更多相关《某科技研发云计算心酸史之工作计划总结（29页珍藏版）》请在装配图网上搜索。

1、工 作 总 结（2011年11月2012年9月）虚拟化基础架构业务部王 毅2012-9-24目录1.概述42.项目52.1云计算服务底层核心52.2云计算服务管理系统132.3云计算服务监控系统162.4弹性计算应用172.5云计算服务计费系统182.6云计算服务用户中心系统192.7云服务192.8云服务容管理系统202.9企业私有云实体机柜操作系统202.10企业私有云实体机柜监控系统203.团队建设203.1初期203.2中期203.3后期204.总结201.概述从2011年11月份至2012年九月份，我主动要求接受公司分派的云计算开源软件OpenStack的研发任务，到至今已经完成云计

2、算产品服务的大部分功能，并基于已经研发出来的功能生产出一系列的软件产品共花了11个月的时间。在这11个月的时间里，无论是对于产品项目的开发、云计算底层服务研发，还是团队建设等方面都遇到了不同程度的问题和困难。虚拟化基础架构业务部从刚刚开始的“IaaS组”到现在成为部门，人员也由最初的四个人发展到现在的13个人。以下是我从项目和团队建设两个方面着手，将问题融入到项目和团队建设当中来进行虚拟化基础架构业务部的工作总结。2.项目目前虚拟化基础架构业务部围绕着云计算底层服务的研发所完成的项目比较多，主要包括云计算服务管理系统-PUBECM、云计算服务监控系统-PUBECC、弹性计算应用-ECA、云计算

3、服务计费系统-CSBS、云计算服务用户中心系统-CSUC、云服务-CSNT、云服务容管理系统-CSMS、企业私有云实体机柜操作系统-PRVECM、企业私有云实体机柜监控系统-PRVECC等。其实，作为云计算服务底层的研发工作，也可以算是一个主要的项目，毕竟它是我们云计算服务底层的核心。2.1云计算服务底层核心2011年11月，由于当时我还在颖部门下作为一个组的组长，我们所接受的任务是ESDP的开源和ESDP的开源的开发。我们组准确的来讲一共只有四个人，在接触了云计算服务开源软件OpenStack以后，由于我跟同组的凌志对OpenStack的云存储部分“swift”从安装到使用都已经进行完成，所

4、以也不得不对OpenStack的虚拟机部分对晓明进行辅助性工作。当时云计算开源软件OpenStack给我的感觉是必须集中精力，才能够顺利的进行，因此我主动要求承接云计算服务开源软件OpenStack的研发工作。在研发初期，我们主要的精力还是对于OpenStack的集群式安装部署，因为OpenStack是一个开源性的软件，除了它自己的开源项目，包括云存储（swift）、云虚拟机（nova）、镜像服务（glance）、统一身份认证系统（keystone）、管理系统（当时被叫做“dashboard”，后来改称为“horizon”）之外，还包括其他的一些开源的软件项目服务。如：数据库服务（mysql）

5、、时钟服务（ntp）、消息队列服务（rabbitmq）、虚拟服务器远程服务（noVNC）、网络服务（network）、访问工具（ecua）、卷组服务（volume）等等。各个服务之间首先必须安装正确，在安装正确的基础之上通过配置文件的相互配置才能够达到想要的功能效果，除此之外各个服务之间的安装还存在一个顺序的问题，所以要顺利的安装集群部署就需要反复的实验，为了保证实验的正确性和准确性，我们有的时候不得不要求将服务器进行重新格式化；之所以格式化的主要原因是卸载往往有的时候是无法卸载干净的，同样的安装过程，对于卸载的服务器有的时候能成功；而有的时候却成功不了，这大大干扰了我们的安装思路。后来公司不

6、允许进行服务器的重新格式化，原因是服务器所在集装箱的机柜不能够经常反复的开启，对服务器机柜的温度有很大的影响，容易造成服务器的损坏；由于服务器当时在八角楼C4机房，我们只有使用的权限，对于有的时候所发生的服务器死机需要重启等工作，我们只能间接的通过网络部来配合进行完成，而网络部负责这项工作的王烨辉的工作也很忙，我们很多时候不得不进行等待，这也给我们的工作带来了一定的困难和麻烦。当时我们服务器在机房中一共拥有20台服务器，为了能够在沟通和管理上方便，我针对于服务器进行了从1#20#的编号，其中15#19#五台服务器是DELL的R410服务器，其他服务器是2GB的存配置。为了保证安装脚本在我们自己

7、掌控下顺利进行，我决定将八角楼的服务器中的1#机和2#机搬到了办公地点作为云存储的脚本安装与功能测试；后来亚丽组的志楠和贺军的加入所带来的两台惠普服务器成为了办公地点虚拟机的脚本安装与功能研发和测试的环境，通过这四台服务器组成了我们的办公地点的实验环境。但是为了能够彻底解决OpenStack底层各项服务之间的搭配工作，能够准确的找到问题的出现位置，锁定服务目标；我采取了将服务器各个服务单独存放至一台物理服务器当中，来进行功能性验证和观察。准确的来讲在C4八角楼机房里有18台服务器供我们使用，但是由于不能够经常性的重新格式化服务器和经常性的进入服务器机房，所以我们对于C4机房中的18台服务器的使

8、用非常慎重，当然也大大影响了我们的工作效率。OpenStack的官方，只是介绍了表面层次上的大体原理，以与各个服务之间的相互作用服务，但是像ntp、rabbitmq这样的其他开源服务是没有介绍的，我们所找到的线索完全得益于从网上下载某些志同道合的网友所提供的安装部署文档；但是想要达到和解决各个服务以单独物理服务器提供服务的目的，这项工作仍然非常的艰难。为了避免机房服务器的重新安装，我下令让研发人员在自己的台式机上通过virtual box安装虚拟服务器，我们自己的台式机箱只有2GB的存，最多也就可以跑三台虚拟机，所以只能在这三台虚拟机上跑安装脚本，另外由于我们的台式机CPU等配置不支持虚拟化，

9、所以我们只能够通过返回的命令行提示来确定是否安装成功，但创建虚拟机是得不到任何验证的；同时我们只能关掉一部分已经安装了虚拟服务器后再跑其他的虚拟服务器，花在查看上的时间非常多，更不要说再遇到问题和解决问题了。在这个工作过程的进行当中，我们实验环境服务器所在机柜的PDU坏了，对于PDU的采购花了很长一部分时间，大概有一个月左右，这也导致了我们的工作无法在实验环境的18台服务器中进行。我们只能在自己的台式服务器里的虚拟机中跑我们的脚本。在初期的过程中，我们并不敢跑大的虚拟机镜像，而是采用了OpenStack官方没有操作系统界面，只有命令行的小型ubuntu镜像。在整理和跑通安装脚本并等到实验环境的

10、PDU修复后，我们才得以反复进行我们的安装脚本的实验，这个时候我们的卸载脚本也已基本成熟。可以说安装部署方面的问题已经基本上得到了解决。公司还要求可以自动进行安装部署，为了实现这个目标，我们将实验环境的12#服务器当作我们安装部署的资源机环境，安装部署资源大概占到了40GB左右。之所以需要一个资源机，是因为在我们的安装过程中，经常遇到了版本不统一和不一致所导致的无法安装成功，究其根源在于采用apt-get的方式安装都是采用网上资源进行下载后的安装，地址是一样的，版本却改变了。OpenStack当时还相当的不成熟，源代码更新比较快，同样的安装地址，昨天还可以正确安装并安装成功，转过天来就会出现有

11、些命令都执行不通的情况出现，Keystone（身份认证）和glance（镜像服务）的安装版本不一致就导致了我们很长一段时间对于Glance的命令执行不得不采用EC2工具绕过了Keystone。最终的解决是将版本统一后，将glance的安装步骤和Keystone的结合安装过程顺序进行倒置才成功的。在以上工作完成的基础上，由我完成了OpenStack的手动安装文档的初版编写，和一个版本的脚本自动安装部署由贺军来完成的，但是对于公司的要求我们还是有很大一段距离的。比如说，对于不同的开源服务对服务器都有不同的要求，mysql数据库服务要求存和CPU；Volume卷组存储服务要求硬盘多一些，glance

12、镜像服务要求存更大一些；控制节点的要求比较一般，计算节点则对存要求非常高；rabbitmq消息队列服务要求网络；network也需要网络和服务器存给予很好的支持；还有目前对于network和quantum服务最好是能够进行服务器的单独支持；存储服务方面，代理节点的要求一般，但是存储节点需要有存和硬盘的支持等等。需要考虑的是服务器成本的降低以与整体服务的优化等方面的原因，将服务安排在指定的服务器，并自动进行修改配置；其实，在有了资源服务器的支持以后，脚本安装和人为的手动安装方面的速度是相差不大的。从安装的正确性和准确性以与成功率上来讲，手动安装更加保质保量。我号召团队成员多关注 群中全国的竞争对

13、手的情况，竞争对手的情况要比我们好很多，无论从实验环境方面还是人员构成方面都令我们羡慕不已，为了不落后于竞争对手，我要求在进行以后工作的同时着手将云计算服务底层的一些功能接口进行了梳理，包括统一身份验证服务（keystone）、镜像服务（glance）、云主机服务（nova）和存储服务（swift）等接口功能。这些接口功能也为后来的各项云计算服务产品项目的开发打下了良好的基础。OpenStack是用python语言开发的，在官方上有很好的接口服务文档，通过官方接口文档的描述，我们知道OpenStack是采用的 协议的Restful接口技术实现的，类似于通常所说的WebService接口服务技术

14、。对于接口的调用，研发人员从网上下载了针对于存储服务的两种接口调用源代码，一个是java的；另一个C#语言的。通过接口对于现有的功能的理解后，我对云计算服务有了更加深刻的理解，主要是云存储和虚拟机两个方面；我认为可以建设一个云服务的，可以提供类似于网盘服务以与虚拟主机的同时，还可以将企业的应用服务做在创建虚拟机的镜像当中，这样就实现了网上的SaaS平台，并通过的方式向岩光副总提交了我的想法。由于当时公司想要一个比较绚丽的，所以.net的silverlight可以达到要求。亚丽部门就负责了云服务的开发工作，我们作为底层对他们提供接口服务，他们最先的工作主要是云存储。我让开发人员将接口源码进行了梳

15、理，为了能够更好的给亚丽部门的于彪组提供更好的服务支持，我让王琳将C#接口的源代码进行有效的整理和分割，我让凌志将swift做了安装部署后，为于彪组提供关于云存储的技术服务支持。虽然沟通方面我们也经常在见面打招呼的时候询问是否有什么问题，但是接口方面的技术支持也总是断断续续。为了验证在镜像中放入大的应用服务，在启动虚拟服务器时可以将作在镜像当中的应用服务进行正常的使用，我们制作了包含国外SAP应用的服务镜像，该镜像的制作过程中也遇到了很多的问题和麻烦，首先需要将多个光盘的安装文件进行合并，这个SAP服务的安装文件一共有200多个GB，其中安装文件有四个，主要的安装文件就有200多个GB，当时在

16、这个地方就存在着一个问题，就是将四个安装文件进行合并，合并成功以后再上传至服务器中。但是我们的合并没有成功，主要原因是安装文件太大了，普通的服务器或者台式机在进行合并的过程中需要花费很长的时间，并且经常是等待很长的时间，不知道计算机是否还在进行着合并过程。在我的直觉和猜测的引导下，我决定不进行安装文件的合并，以200多GB的主安装文件来进行应用的服务器安装和镜像的制作。镜像制作成功后，另外一个问题就是由于实验环境服务器性能的影响，通过镜像服务glance上传镜像需要花费很长的时间，而且上传至glance所在的物理服务器以后，再上传至计算节点物理服务器，又需要镜像的长时间拷贝；这个在当时Open

17、Stack的Diablo版本中是无法进行镜像上传进度的提示的，直到我们后来升级为OpenStack的Essex版本以后才得以解决。最终我们成功实现了将大的应用服务SAP放置在已经制作完成的镜像文件中，并成功启动该镜像的虚拟机，由于实验环境服务器的影响，速度非常慢。在进行了目前现有功能和参考网上其他云服务产品功能以后，我筛选出了我们还没能够实现的功能，其中包括增开虚拟机外网代理、虚拟机实例快照、虚拟机负载均衡、虚拟机双机热备、虚拟机实例迁移、外部接口调用修改虚拟机主机名称、虚拟机时区不同步、Glance于Swift服务的整合、虚拟机计算节点运行状况监控、虚拟机配额限制服务、多控制节点集群、接口控

18、制虚拟机网络带宽流量、提高OpenStack数据库的稳定性等等功能。这些功能有些成功的实现了，但是也有受制于实验环境、网络环境的限制以与研发团队技术能力方面的影响，我们没有成功。对于功能的实现我决定必须本着几个原则入手：1.在进行功能性实验前必须写好实现方案，以功能为单位进行方案文档的编写，计划好步骤，并按照步骤一步一步进行实验；2.不管成功与否，对于出现的问题以与针对问题进行的解释性记录必须落实在实现方案的文档上；3.如果实现方案最终成功，对成功的实验功能进行总结；如果不成功，说明不成功并注明不成功的理由或者是怀疑理由；以备将来进行针对性解决。为了能够从根本上解决底层中出现的大量Bug和帮助

19、我们将来的研发工作，我认为研发团队中的每个人必须对OpenStack大体结构框架有非常准确和清晰的把握，在此基础之上才更加有把握进行源代码的修改和二次开发整合。我带着团队中的部分人员进行了文档的翻译性工作，在翻译工作的过程中也是我能够确定的了解到官方文档只是表面上的介绍或者接口功能的介绍，对底层功能的研发意义虽然有但是却并不大，这也是我错误的认识了开源软件这个概念。正在这个关节上，OpenStack的Essex版本发布了，官方上很多文档进行了更新，我们有部分的文档的原有依据丢失了，只能凭借我们版本库中所存储的原有文档进行翻译性的查看。我们通过对官方上的资料查看以与网上搜索到的信息资料，发现新版

20、本的Essex改变了原来的Diablo版本中的很多不足，也包括我们目前所无法解决的Bug，比如镜像服务glance上传镜像时的上传百分比的现实；最让人感到抑郁的底层的数据库表结构的改变非常的大，这让我们花费了很多功夫在Diablo版本上的功夫很有可能是白做了。可是，也就是在这个时候，公司的SaaS平台需要上线，我们要负责底层的虚拟化环境的搭建，我们需要为SaaS平台提供集群式部署的服务器，统计下来SaaS平台需要30到40台不同配置的高性能虚拟服务器来进行支持。我们也从网络运维部门获得了8台R710和1台R810，另外我们给了网络部几台R310并给了所有的R410作为正式生产环境的服务器，提供

21、其他服务的支持。有几个问题明显的摆在我的面前，正式生产环境就要上线了，底层服务的Diablo版本还有很多Bug和不稳定的因素，在此基础上搭建正式生产环境，很多问题是无法应付的；将来在此基础上升级风险性是可想而知的，耽误了服务怎么办？因为一旦SaaS平台一旦给公司带来盈利，赚钱的话，每一分钟、每一秒钟都是耽误不起的；OpenStack的Essex新版本已经解决了原有的很多Bug问题，数据库底层也与原来的版本发生了很大的变化；最重要的特点是Essex在网络方面提出了新的服务quantum；究竟采用Diablo版本还是Essex版本，前者对于将来研发的风险性很大，同时我们很可能会出现研发方向的迷失，

22、而对于后者如果我们成功搭建完成的话不但可以解决老版本残留的问题，对于将来的工作可以开辟出大片的空间；最终的结论是Diablo版本的风险会发生在将来，而Essex版本的风险性就在当时，因为我们还没有成功集群式安装。可是，就当时的情况而言，基于低配置实验环境的安装，不可能；但是有了正式的生产环境，明摆着的更好的实验环境，不如拼一把。我把我的想法告诉了我的团队，在跟岩光副总进行沟通以后，我们在正式生产环境上基于新的Essex版本搭建了云计算服务平台。后来的事实也证明，我的这个决定是正确的。云计算服务底层核心服务的研发方面，目前具备了大部分的虚拟机的功能，在整个团队的这11个月以来，基本上是两个方面的

23、工作容，一个是对基于云计算服务核心底层的上层产品的接口和技术支持、环境的维护；另一个就是云计算服务的核心研发这两个方面的工作；对于基于研发的文档知识积累，我认为这一点非常的重要，研发工作必须落实在文档上面，尽管绝大部分研发人员对于文档不够重视，但是当遇到问题的时候，原始的文档就提供了必要的帮助。2.2云计算服务管理系统云计算服务管理系统是最早完成的一个系统项目，当时OpenStack对于云计算服务底层拥有一个软件界面可以操控的系统，名称叫做“dashboard”，后来官方将其改名为“horizon”，“horizon”这个软件系统是用python语言进行开发的，在安装过程中也是需要进行配置文件

24、的配置修改，基于mysql数据库来进行存储业务数据，其他就是调用OpenStack的相应接口，来实现给用户进行云计算服务的界面操作。对于“horizon”这个被OpenStack囊括在其的云计算服务操作系统来说，它有几个不好的地方：1.完全基于OpenStack云计算服务的底层功能接口和进行模块的划分，如果不了解OpenStack的原理的话，是无法理解并使用和操作的；2.缺乏人性话，也就是在客户体验性方面做的还差一些，页面显示也不是很美观，比如：它没有分页的操作，更不要说对于模糊的查询操作了。基于这些特点，我编写了适合我们进行操作的云计算服务操作系统的需求并进行了业务方面的设计。为什么要提出这

25、个系统项目，我主要是基于以下几个方面的原因：1.对于云计算服务底层，我们需要有自己的操作系统软件，这个毫无疑问是必须的；2.对于我们已经实现的接口服务，没完没了的通过命令行进行加以验证相当麻烦。另外，该系统也是我们接口功能逐渐实现和确认的一个终点，可以完全体现我们的工作，我们实现的功能，还有我们的价值；3.这个操作系统目前可以给我们自己进行使用，随着逐渐的优化和改良，将来早晚会成为公司的产品，我们的工作是有用功，将来不会白做；4.该操作系统服务当中包含着我们已经实现的接口调用，可以把它比作一个活字典，对于接口源代码的调用可以准确的找到位置并进行复制和粘贴，为将来其他产品项目的开发打下良好的基础

26、。从后来的各个系统项目服务来说已经印证了这一点；这也是我们为什么后来系统项目得以快速开发的主要原因。当然，在该系统项目的开发过程中，也遇到了很多的问题，比如对于一些业务数据，我们采取的是没有调用OpenStack所提供的接口服务，而是通过对OpenStack底层中各个服务所涉与到的数据库与数据库表结构之间的逻辑关系进行关联性方面的数据检索，当然这必须建立在我们对OpenStack数据库表结构相当了解的基础上。另外，有很多接口在OpenStack服务当中并没有提供，必须通过调用命令行执行才能够做到，这个对于系统项目的响应速度来讲的确是慢了很多，但是能够达到我们现阶段的目的。在云服务器资源和云存储

27、资源的监控显示方面，我们也有很大的问题，比如云存储，我们没有办法通过接口获得剩余的存储资源、已使用的资源，我们就不得不通过人为设定系统总的存储资源，通过命令行调用获得存储已经占用的资源，剩余的则就是未使用的存储资源等等。对于统一身份验证（Keystone）来讲，在Diablo版本中它是有超级管理员用户的，它可以管理所有的租户和租户下的用户，但是对于后来的Essex版本来讲是没有超级管理员用户的。对于这一点，OpenStack的“horizon”服务当中也是以一个租户为单位进行登录并进行服务的。从这一个角度来讲，我认为OpenStack服务还是面向于大批量集群式公有云服务的，因为“公有云”往往给

28、我在概念上的理解就是“资源无上限”。目前该系统项目的项目名称我给他取名字叫做“pubecm”。这个系统项目目前的缺陷是浏览器兼容方面还有一些问题，功能上很多还没有来得与增加；由于当时最初的目的是给我们自己使用的，所以页面风格沿用了2011年公司联查时的系统项目的玻璃质感风格。但是，在随后的企业私有云实体机柜的操作系统诞生后，企业私有云实体机柜的操作系统囊扩了pubecm的所有功能，而且在页面风格和美化以与客户体验等方面都完全超过了pubecm，我现在一直考虑以企业私有云操作系统取代该系统项目。因为企业私有云实体机柜的操作系统是从pubecm中升级出来的，它青出于蓝而胜于蓝一点都不为过。2.3云

29、计算服务监控系统云计算服务监控系统是在后期为了能够更好的监控公司SaaS平台正式生产环境而做的一个系统监控项目。这个项目的需求和业务设计都是由我一个人来完成的。它主要包括这么几个方面的容：整体概况、CPU使用情况、存使用情况、磁盘使用情况和存储资源使用情况这五个方面对服务器资源进行监控。在这个系统项目开发的过程中，遇到的最大的问题就是资源的上限一直都没有一个统一和准确的数据，在报警线数据方面我们也仍然没有一个准确的数字。关于资源上限也就是指整个服务的计算节点一共有多少核CPU，而这些CPU能够虚拟出多少核的CPU，这些虚拟出的CPU最大数量就是它的上限数量，而真正使用了多少以后，它的服务性能会

30、降低或者说有很大的影响；这一点上我们一直没有得到很好的解决。我对研发人员提出的要把OpenStack底层的算法搞清楚，通过它的算法和我们实际的参数我们得到它的上限数据；这个算法虽然是被研发人员掏出来了，但是对于具体的数据一直没有一个准确的答案。最后没办法，我们通过正式生产环境实际的数据库中的数据得到准确的答案。在正式生产环境中，有其中一个生产虚拟机服务器的计算节点，它部所生产的虚拟机的CPU总和是它实际CPU核数的3倍，运行状况没有任何的问题。3倍的这个数据对于我来讲，已经相当的奢侈了，所以我就将3倍这个数据定为CPU的最大上限数量；对于存来讲，OpenStack的官方给的参数一直都是1.5倍

31、，也就是说生产虚拟机服务器的计算节点物理机存的1.5倍是它能够虚拟出的存的最大数量，因此我保守的将1.5倍作为了存最大上限的倍数参数。对于磁盘空间而言，它是不需要虚拟化的，剩余多少就是多少。这样我们解决了监控系统对于数据的监控问题。2.4弹性计算应用弹性计算应用系统是为了能够给SaaS平台添加应用而做的一个小型的创建虚拟机服务器、给企业用户分配虚拟机服务器和销毁虚拟机服务器的一个小型的应用。该应用的需求设计和业务设计也是由我来完成的。该弹性计算应用，就功能上来讲该项目并不大，但是说到它当时的风险性也是与SaaS平台底层的ESSEX版本搭建是绑定在一起的，这个应用于SaaS平台上的其他应用相比，

32、它很特殊，它的特殊性就在于它完全调用底层的接口创建虚拟机，而这些虚拟机是与支持SaaS平台的虚拟机以与各个应用所占用的虚拟机服务器是平级的。因此首先为了能够把握和控制住底层资源的限制使用而不影响SaaS平台的其他应用，我们必须开发一个弹性计算应用的后台管理系统，这个系统的目的是将底层的虚拟机服务器规格（CPU核数、存大小、磁盘空间）同步到弹性计算应用的业务数据库中，通过管理员的筛选过滤掉大的规格，使注册和登录SaaS平台的用户只能够创建和使用低配置的虚拟机服务器。在进行该应用的开发时，首先必须开发除了底层调用的其他部分，因为底层环境还处在搭建过程当中。最大的问题是当时我们还是IaaS组，组没有

33、专门的美工，美工需要从于彪组进行借用，当时于彪组负责美工的是郜帅；但是郜帅还负责于彪组的美工以与手机云存储的页面设计工作，对于弹性计算应用的页面美化方面肯定是精力投入的不会很多，但是开发任务也非常急。为了能够达到页面美化方面的要求，我组织组的开发人员周六都干起了美化的工作，他们都很尽力，但是他们毕竟不是美工专业人员，所以页面没有能够达到我的要求，作为管理人员来讲我是说不出什么来的。最终是由云俪所管理的美工组后来又重新给改良的。2.5云计算服务计费系统云计算服务计费系统是公司岩光副总提出的一个项目，该项目的主要目的是支持云服务的，对云服务上的产品进行定价服务的。由于我之前有过关于计费系统项目方面

34、的经验，我针对于该系统项目进行了针对于客户和业务统计方面的扩展，因为产品的价格是与供求关系以与产品的成本密不可分的。对于客户对产品的购买服务，我们需要对于客户有所了解和理解。比如，客户的不同年龄段、不同的地域、企业还是个人等等对于产品的需不同的，云服务作为公司云计算服务对外的窗口而言，对客户的分析以与对产品购买情况的分析还有客户所关注的产品等等都需要进行统计，从统计分析中获得我们想要的结论。随后在与岩光副总的坚持下，将该计费系统进行了拆分，原计费系统被修改为只是对云服务产品的类型和价格进行制订；而对于用户的统计和分析以与用户注册参数的制订等被拆分并独立成为用户中心系统。这个系统的开发不涉与底层

35、云计算的核心支持服务，唯一需要关联的就是需要将云计算服务底层的镜像（操作系统,windows XP、ubuntu等）和虚拟机规格（CPU核数、存大小和硬盘空间）同步到计费系统的业务数据库当中来，并进行定价，以供云服务获取这些价格数据后，通过接口调用创建相应的虚拟机。在页面美化风格方面，由于是公司部自己使用，所以对于页面风格仍然沿用了2011年公司联查时统一的玻璃质感风格。2.6云计算服务用户中心系统云计算服务用户中心系统是从计费系统当中拆分出来的一个系统项目，该项目的主要功能是面向于云服务的用户。该项目的需求分析和设计也是由我来完成的。该系统首先是通过参数管理模块对云服务注册用户所需要注册的参

36、数进行管理，比如所属国家、所属省市、所在行业、所从事职业以与用户需要反馈的问题类型与问题等等。再有就是对于客户的充值、使用和剩余金额以与用户对于不同产品的购买清单等等，系统中还包括用户的统计功能，比如年龄、性别、针对于不同产品的不同购买人群的统计等。该系统项目并不涉与云计算服务底层的接口调用，是普通的Web项目。由于是给公司自己部使用的，所以在页面风格上仍然沿用的2011年公司联查时的玻璃质感风格。2.7云服务云服务是在SaaS平台结束以后，由于彪组转接给我们的。这个项目最初于彪组采用的是.net技术进行的研发。由于我们在外围产品方面主要采用的是以java语言进行的开发，所以无论从需求分析设计

37、、页面设计还有底层代码实现上，我们可以说是推倒重来的。该的主要起的作用是对公司云计算服务的技术力量以与公司现有的云计算服务产品对外进行展示的窗口。在云计算服务的技术力量方面展示上提供云主机、云存储和云硬盘三个云计算服务技术力量的展示；在产品方面有企业私有云实体机柜实体产品和企业私有云方案两种供网上用户下订单的方式进行推广销售。为用户提供了用户中心和控制台这两个模块对注册登录用户提供云计算的应用服务。由云计算服务计费系统、用户中心系统和容管理系统对该提供信息数据支持服务。2.8云服务容管理系统 云服务的容管理系统是对云服务的容展示信息的后台管理系统，该系统的主要容包括产品服务动态管理、市场活动管

38、理、客户案例管理以与合作伙伴管理等功能模块。该系统的业务需求前期是由我来完成，后期由立召完成对需求文档的编写，并完成开发工作。2.9企业私有云实体机柜操作系统企业私有云实体机柜是企业私有云实体机柜的云计算服务软件产品之一，该系统主要面向于购买企业私有云实体机柜产品的企业网络管理人员，由管理人员登入系统，进行虚拟服务器的创建、快照备份、分配/释放IP、升级、暂停、运行、销毁等操作。该系统项目的需求分析和业务设计是由我来完成的。该系统项目是一个产品软件，从页面风格、客户体验还有功能的使用等方面都做到了全面的细化。 在该产品的开发过程当中，也是由于云计算服务底层核心的影响造成了功能不稳定的情况，比如

39、有的时候迁移成功，有的时候迁移不成功，有的时候升级成功而有的时候升级不成功。由于采用的是3台R310的2GB存的低配置，创建的虚拟机只可以是512MB存的小型镜像；所以有些bug不得不怀疑是由于底层服务器性能方面的影响，造成功能的不稳定。后来从网络部借用了2台R710高配置的服务器一周多的时间，问题才加以解决。2.10企业私有云实体机柜监控系统企业私有云实体机柜监控系统，也是企业私有云实体机柜的软件产品之一。该系统的主要功能是对企业私有云实体机柜的物理资源机以与生产虚拟机的物理服务器资源的监控。该系统的需求分析、业务逻辑设计是由我来完成的。该系统产品项目的主要功能包括整体使用情况、服务器情况、

40、CPU使用情况、存使用情况、磁盘空间情况、外网IP数量监控、虚拟机报警和资源与报警等几个数据监控模块。面向于企业的数据中心管理人员，能够直观的查看企业私有云实体机柜的使用情况。3.团队建设在团队建设方面，我将虚拟化基础架构业务部从最初的“IaaS”组到现在一共分为初期、中期和后期三个阶段，初期阶段是从2011年11月份到年后在C6办公到搬到B8楼的202之前；中期阶段是我们在B8楼的202室的工作期间；后期阶段是我们从B8楼的202室再次搬回到C6。在这三个阶段过程中，对于团队的建设也曾经遇到了很多的困难和问题，毕竟从管理角度来讲，团队中的人员变动，哪怕只增加一个成员都会经过形成期、震荡期、表

41、现期和正规期四个阶段。在团队建设方面我可以说投入了大量的精力，虚拟化基础架构业务部的团队成员大多数的能力都非常强，同时个性也非常强，尤其对于一直高新技术的团队，管理的难度和强度是非常大的。从了解他们到理解他们，平稳他们的工作情绪，改善他们的工作心态，提高他们的工作效率和工作质量是非常费神的一项工作。3.1初期团队人员统计表序号现有人员加入离开1王毅2王凌志3王琳4瑞祥5志楠6贺军7志涛8健总计8人在团队建设的初期，我的团队中包括我在一共只有四个成员，他们是我、王凌志、王琳和瑞祥。从每个人的性格特点来讲，王凌志是一个非常有灵气的人，聪明、能干有想法、胆子大，认准的事情即使是错误的也敢作，如果做的

42、事情方向正确，是非常得力的一个好帮手；但是缺点是，对待事情缺乏成熟的思考，这往往也是我为什么需要重点关注他的原因；王琳是一个Java开发人员，只对开发感兴趣，对云计算可以说兴趣不大，他的技术能力我非常认可，开发速度非常快，对于有疑问和不同的见解敢于大胆提出来，但是缺点和不足是，往往在某些开发过程当中采用了我个人认为不合理的设计模式；文档的编写能力上差一些，有待培养。瑞祥的优点是测试方面的技术、只是经验丰富，缺点是非常爱玩游戏，但是对于我的提醒和忠告他还是能够听进去的，在给分配安排工作后，还是可以做到扔下游戏主动工作的，但是工作完成的质量方面也许个人能力的影响不是非常的好。由于工作的需要，从亚丽

43、组调配来了志楠和贺军，志楠是一个非常钻研技术的人，工作起来有一股轴劲，认准的事情八匹马都拉不回来，但是在我后来的教导和指引下，已经改变了很多，在做事情的正确逻辑思维方向上有很大的进步。贺军为人性格胆小，但是做事情非常踏实和实在，在某些技术关键点上能够提出合理的建议，并有让我出乎意料的正确的想法；但是他们两个人都有一个最大的缺点就是不善于表达，从这一点来说，这个缺点是非常致命的，肯定会影响到他们将来的职业发展。我往往在开会或者指定工作方案的时候尽量给他们说话的机会，让他们可以尽情的表达出他们的想法，锻炼他们的表达思维；虽然进展缓慢，但是效果比之前已经好很多了。之后健和志涛加入了我们的团队，健是岩

44、光副总从其他的云计算服务公司挖过来的，在虚拟化云计算方面有过一到两年的工作经验，对于虚拟化方面以与虚拟化的底层比我们熟悉很多，他的学习能力非常强，从工作状态中可以看的出对云计算技术还是非常有热情的，缺点也是在沟通上，他的沟通不像是贺军那样的先天的缺陷，而是过于保守。志涛是我们部门当时急于需要的一个网络、服务器硬件方面的工程师，他往往给人的感觉是让人放心，喜欢微笑，乐乐呵呵的，就是这样一个表现让我对他的人和工作方面的管理大意了。这个人在工作态度上还是很认真的，但是缺乏社会工作经验以与人际关系间的应对，对于公司的管理制度难以适应，以与在团队当中的自傲性格使得他后来离开了公司，从对他的了解和关注方面

45、来讲，我需要负有一定的责任。随着初期团队的雏形逐渐成形，慢慢的团队会进入到形成期，为了能够加深彼此的了解，我请了团队所有成员去“万家灯火”的一个餐馆吃了一顿饭，大家在一起欢声笑语，大吃大喝。我心里也非常高兴，但是心里的压力也大，将来他们就是公司云计算的中坚力量和核心成员，他们能做到吗。在饭桌上大家畅所欲言，我也说了我对将来的一些想法，希望大家能够团结；工作方面多沟通多互相帮助。我也试图跟他们每个人进行聊天和对话，了解他们的个人想法。3.2中期团队人员统计表序号现有人员加入离开1王毅2王凌志3王琳4瑞祥5志楠6贺军7志涛8健9蓝文静10磊11立召12霍世彬13程乐总计10人中期主要是指我们由C6

46、搬到B8的这段时间，也就是在B8的202工作的这段时间，在搬过去以后，我的团队增加了蓝文静、磊、立召、霍世斌以与实习生程乐这些人员。蓝文静这个女孩就像她的名字所描述的那样，是一个文静的女孩，是做测试的，为了弥补瑞祥在测试过程当中的疏漏，有文静来进行弥补我也是非常放心的。文静为人踏实，在文档的整理以与翻译的工作过程中是非常稳重的；磊是新招的开发人员，比较偏爱于UI。基本的工作技能偏向于页面表现层方面，但是不好的是业务逻辑方面差一些，反应上稍显迟钝。这个需要慢慢的进行培养。立召的技术扎实全面，工作态度认真，踏实稳重，唯一不好的地方是思维视野方面还不够开阔，这方面需要我给他机会来进行足够的锻炼。霍世

47、彬性格上来讲是一个可爱的小伙子，更刚来时从颖那反馈来的“二”来形容根本就是冤枉了他。网络方面的技术比较全面，不足之处在于书本上的东西了解比较多，但是实践上还是少了些。程乐是一个在校的大学生，没有工作经验，是来公司进行实习的。性格比较孤僻，技术上基本的理论知识都是具备的，但是不足的是社会经验少，他给人的感觉是依赖性比较强但是又不想去依赖别人，后来的事实也证明了这一点。在团队建设的中期发展阶段里，我大部分的精力都花在了工作进展和项目的管理与设计过程当中，但是越是这样，往往团队当中发生的事情就越多，当然也有我所察觉到的和没有察觉到的。首先，蓝文静提出了辞职，并离开了公司。最初对于蓝文静的定位还只是一

48、个测试人员，但是由于部分的测试工作已经完成的时候，为了避免人力资源的浪费，我开始让她更多的接触一些云计算服务官方文档的资料整理，在这方面的工作我是这样理解的，虽然我们是以OpenStack为切入点，以它为切入点向外进一步展开对云计算的研发，但是从根上来讲还是要从OpenStack的官方文档入口，并整理和梳理出我们自己对它的理解和认识，目前的人员状况还不能够完全有把握查看OpenStack的源代码并基于源代码进行修改以达到我的要求，再者随着人员的不断加入和扩大，我们也需要拥有自己的培训资料，也就是说不管是谁、应聘的什么职位，只要进入IaaS组，就必须对我们的云计算工作围和工作容有所了解，以达到工

49、作上的沟通顺畅，工作能够保证拥有统一的步伐和步调。公司不允许进行组的知识性培训，按照公司的理解，上班来不是上学来的这一原则，我让文静在整理文档并进行翻译的同时，整理了一套python语言的培训教程，通过定期的将文静整理的资料跟大家共同探讨的同时，顺便将python语言进行了短暂的培训。这也为后来组的研发团队进一步深入OpenStack的研究和修改功能代码打下了一个良好的开端。最终，文静还是由于个人原因，因为她要结婚，所以必须到塘沽去追随他的丈夫，而离开了公司。瑞祥是由于公司部门部调整，因为公司的部门部成立了测试组，所以他离开我们的团队，但是他所工作的测试围仍然是以我们组的软件产品项目为主，所以

50、我们还是有工作交集的。对于他爱玩游戏这一缺点，我私下里也跟他单独谈论过多次，我站在他个人的角度出发，提出要为自己的将来着想，游戏给他带来不了什么，对他起不到任何作用和好处；我的这些良苦用心希望他将来能够体会的到。志涛的离开有他自己的原因，也有部分我的责任，我之前已经说明过了。在B8楼202的工作工程中，除了对底层服务研发、维护和对上层软件产品项目开发的设计与管理方面的工作外。筛选待面试人员的工作简历并进行面试也成为了我日常工作过程中不可缺少的一部分，当然也是团队建设过程中所必须的。工作也经常被打断，简历也经常会收到很多份，并从中筛选出我需要的人员。立召和磊都是这一时期吸纳进来的开发人员。对于研

51、发团队的管理上，王琳可以说在云计算服务产品的系统项目的研发方面功不可没，因为之前的云计算服务操作系统、用户中心系统、计费系统，虽然需求分析、业务逻辑设计都是由我来做的，但是代码的开发都是由他一个人来完成，在开发速度上因为采用的是他所熟悉的开发框架SSH+LigerUI所以非常快。但是在制作弹性计算应用时，他却了我认为致命的错误，他把弹性计算应用的所有页面作在了一个页面文件当中，这也包括后来的监控系统；后来在我得知到这个情况以后，专门在开会时找他询问了这个问题。他从访问速度、软件性能以与前台页面异步调用的开发效率以与弹性计算应用是一个小的项目等方面说明了他的理由，在听取了他的意见以后，我认为我要

52、考虑软件项目整体的可扩展性，可维护性以与更加重要的合理性来考虑。为了能够达到我的要求和目的，我让磊接手了弹性计算应用的修改和维护工作，让立召全面接手了云计算计费系统和用户中心系统这两个项目的修改和维护工作。平均分担了三个人的工作量，的确开发工作都压在王琳一个人的身上也太不公平；王琳则继续底层接口服务以与对磊和立召的指导和支援。对于云计算服务底层的研发工作，我主不能够将所有的功能服务控制在某一个人的手里。由于在凌志身上产生了不稳定因素，所以我将OpenStack的新版本Essex的研发工作向贺军和志楠方面有所倾斜；健的精力集中在了基于核心的外围功能的扩展方面，大部分的新版本研发工作，尤其是新版本

53、的特性“虚拟网络（Quantum）”集中在了志楠和贺军的手里，我对他们进行了模块的划分；为了能够让他们顺利在运行过程中修改和调试底层扩展研发的代码，我将剩余的实验环境服务器对他们进行了分配，使得他们可以在自己的集群中运行自己修改的代码，并最终结合得到我们自己的一个版本源码。这样，对于底层云计算服务核心代码我们就能够逐渐的进行自己掌控。后来，他们也都慢慢的做到了这一点。程乐是一个在校的大学实习生，他来自天大。从表面上来看文绉绉的，是一个干技术的料。在对待他的问题上，我把他委托给了王琳来作为他的指导老师，王琳是技术开发出身，包括我在很多的开发人员没有接受过实习培训这样的经历。对于程乐而言我和王琳都

54、是非常看好的，毕竟是名牌大学的毕业生。起初，我想把一些边缘的工作交给他，试一试他的技术能力到了一个什么样的程度，在得到王琳的认可后，我对他和霍世彬进行了云计算方面的培训，程乐与霍世彬不同。他并没有对云计算表现出了太大的兴趣，我解释说云计算服务是我们底层的核心，你们开发方面的任务是围绕这个核来进行产品的开发，需要调用底层服务的接口来完成产品项目。在王琳对他的指导方面，我也曾经批评过王琳，对于实习生你需要耐心的给他讲解，不要把书给他并告诉他知识在哪页。但是却遭到了程乐的反驳，程乐反驳的理由是他没有我想的那么差，这让我感到非常意外。在工作过程中，程乐也了一个致命的错误，他把正式环境当中身份认证系统中

55、的某个表中的数据搞乱了，导致服务不通。这在当时来讲是个大事，大家都非常紧的弥补程乐的这个过失，当然也把程乐吓坏了，但是我没有批评程乐而是采取了安慰的措施。这个时候，凌志就报不平了，因为上次凌志错把服务器关闭了，也导致了工作顺延的恶果，遭到了我的严厉批评。我跟凌志解释说，他是一个还没有毕业的学生，犯错误是不可避免的，这个错误咱们也有责任，但是如果对他进行严厉的批评，凭他的抗压能力，对他的未来是没有任何好处的。对于程乐来说，我认为除了提高他的技术能力外，给他一个正确的方向和对未来的定位是非常重要的，当然怎么样摆正心态与同事进行沟通。这方面才是他真正缺少的，也是实习能够给他带来的最大意义。3.3后期

56、团队人员统计表序号现有人员加入离开1王毅2王凌志3王琳4志楠5贺军6健7磊8立召9霍世彬10程乐11云俪12马红英13任建勇14叶珺恺总计13人后期这一阶段围是我们从B8楼又重新搬回到C6楼直到现在的这个阶段。在这个阶段，公司又重新进行了改组。我们原来的IaaS组变为了虚拟化基础架构业务部，除了程乐由于对云计算缺乏兴趣以与我们的指导工作没有到位而去了其他的组织外，人员也有所增加，增加了云俪、任建勇、马红英和叶珺恺四个人，他们两个人是测试，另外两个是美工。其中云俪和任建勇分别是原来的测试组和美工组的组长。云俪作为原美工组的组长，她的页面美化技术能力很强而且她的另一大特点是具有非常好的创造能力，能

57、够在我原有想法的基础上增加软件的美化功能；马红英也是美工技术能力相当强的人员，任建勇在测试方面有很多丰富的知识，工作态度上和为人处事上让我感到很放心。叶珺恺是新近公司的测试人员，对于测试人员来讲最主要的就是他们的责任心和测试技术能力，她也完全达到了我的要求。但是团队再次进入了形成期，首先测试和开发就是一个矛盾体，美工方面的前台设计本身也会给开发提高一定的难度。所以，我首先对新加入团队的成员进行了云计算工作围和工作容以与知识等方面的培训。为了，消除掉团队互相之间磨合期所带来的隐患，我把部门部所有的人员召集起来开了一次会议，会议的容有两个方面，一个是树立部门的目标，我把我的想法和目标说给了部门的所

58、有的人，并得到了大家的一致认可；另一方面，我再次强调了不允许有拉帮结派，必须互相之间相互理解和多沟通，打造一个团结高效的团队。这次会议之后，我所顾虑的问题没有发生，部门部同事之间团结协作，这也就是为什么在8月7日以后，我们能够非常高效和快速的完成企业私有云实体机柜的“操作系统”、“监控系统”、“云服务”、“云服务容管理系统”的主要原因所在。4.总结以上是我从项目、团队建设以与在项目和团队建设方面的问题所进行的阐述，现在我对我在2011年11月至今的工作的总结。从项目上来讲，包括云计算服务底层核心算在，一共包括了十个软件产品项目，在这是个软件产品项目中，大多数的问题还是基于云计算服务底层核心的项目中，目前还存在着功能需要挖掘、功能不稳定等等问题。但是从整体来讲，现在从我接手开始所认定的工作目标已经基本上实现了。从团队建设上来说，目前人员构成上除了对于云计算服务底层核心的研发方面还缺少人才，人员框架已基本定型。人员在云计算服务以与软件系统项目的开发方面能力上均有很大程度的提高，也基本符合云计算服务研发人员的配备要求。但是，目前的底层实验环境简陋和缺少，给进一步的研发和云服务的产品上线带来了很大的困难。希望在这方面公司可以给予大力的支持。29 / 29