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

某科技研发云计算心酸史之工作总结（2011年11月2012年9月）虚拟化基础架构业务部王毅2012-9-24目录1 .概述32 .项目41 .1云计算服务底层核心42 .2云计算服务管理系统112.3云计算服务监控系统142.4弹性计算应用152.5云计算服务计费系统162.6云计算服务用户中心系统172. 7云服务网站173. 8云服务网站内容管理系统184. 9企业私有云实体机柜操作系统185. 10企业私有云实体机柜监控系统193 .团队建设193. 1初期204. 2中期225. 3后期274 .总结291.概述从2011年11月份至2012年九月份，我主动要求同意公司分派的云计算开源软件OPenStaCk的研发任务,到至今已经完成云计算产品服务的大部分功能，并基于已经研发出来的功能生产出一系列的软件产品共花了11个月的时间。在这11个月的时间里,不管是关于产品项目的开发、云计算底层服务研发，还是团队建设等方面都遇到了不一致程度的问题与困难。虚拟化基础架构业务部从刚刚开始的''IaaS组”到现在成为部门，人员也由最初的四个人进展到现在的13个人。下列是我从项目与团队建设两个方面着手，将问题融入到项目与团队建设当中来进行虚拟化基础架构业务部的工作总结。2.项目目前虚拟化基础架构业务部围绕着云计算底层服务的研发所完成的项目比较多，要紧包含云计算服务管理系统-PUBECM、云计算服务监控系统-PUBECC、弹性计算应用-ECA、云计算服务计费系统-CSBS、云计算服务用户中心系统-CSlJC、云服务网站-CSNT、云服务网站内容管理系统-CSMS、企业私有云实体机柜操作系统-PRVECM、企业私有云实体机柜监控系统-PRVECC等。事实上，作为云计算服务底层的研发工作，也能够算是一个要紧的项目，毕竟它是我们云计算服务底层的核心。2.1云计算服务底层核心2011年11月，由于当时我还在杨颖部门下作为一个组的组长，我们所同意的任务是ESDP的开源与ESDP的开源网站的开发。我们组准确的来讲一共只有四个人，在接触了云计算服务开源软件OPenStaCk以后，由于我跟同组的凌志对OPenStaCk的云存储部分“swift”从安装到使用都已经进行完成，因此也不得不对OPenStaCk的虚拟机部分对晓明进行辅助性工作。当时云计算开源软件OPenStaCk给我的感受是务必集中精力，才能够顺利的进行，因此我主动要求承接云计算服务开源软件OpenStack的研发工作。在研发初期，我们要紧的精力还是关于OPenStaCk的集群式安装部署，由于OpenStack是一个开源性的软件，除了它自己的开源项目，包含云存储（swift）、云虚拟机（nova）、镜像服务（glance）、统一身份认证系统（keystone）、管理系统（当时被叫做"dashboard",后来改称之“horizon"）之外，还包含其他的一些开源的软件项目服务。如：数据库服务（mysql）.时钟服务（ntp）消息队列服务(rabbitmq)虚拟服务器远程服务(noVNC)网络服务(network)、访问工具(ecua)、卷组服务(volume)等等。各个服务之间首先务必安装正确，在安装正确的基础之上通过配置文件的相互配置才能够达到想要的功能效果，除此之外各个服务之间的安装还存在一个顺序的问题，因此要顺利的安装集群部署就需要反复的实验，为了保证实验的正确性与准确性，我们有的时候不得不要求将服务器进行重新格式化；之因此格式化的要紧原因是卸载往往有的时候是无法卸载干净的，同样的安装过程，关于卸载的服务器有的时候能成功；而有的时候却成功不了，这大大干扰了我们的安装思路。后来公司不同意进行服务器的重新格式化，原因是服务器所在集装箱的机柜不能够经常反复的开启，对服务器机柜内的温度有很大的影响，容易造成服务器的损坏；由于服务器当时在八角楼C4机房，我们只有使用的权限，关于有的时候所发生的服务器死机需要重启等工作，我们只能间接的通过网络部来配合进行完成，而网络部负责这项工作的王炜辉的工作也很忙，我们很多时候不得不进行等待，这也给我们的工作带来了一定的困难与烦恼。当时我们服务器在机房中一共拥有20台服务器，为了能够在沟通与管理上方便，我针关于服务器进行了从1#20#的编号，其中五台服务器是DELL的R410服务器，其他服务器是2GB的内存配置。为了保证安装脚本在我们自己掌控下顺利进行，我决定将八角楼的服务器中的1#机与2#机搬到了办公地点作为云存储的脚本安装及功能测试；后来张亚丽组的张志楠与张贺军的加入所带来的两台惠普服务器成为了办公地点虚拟机的脚本安装及功能研发与测试的环境，通过这四台服务器构成了我们的办公地点的实验环境。但是为了能够完全解决OPenStaCk底层各项服务之间的搭配工作，能够准确的找到问题的出现位置，锁定服务目标；我采取了将服务器各个服务单独存放至一台物理服务器当中，来进行功能性验证与观察。准确的来讲在C4八角楼机房里有18台服务器供我们使用，但是由于不能够经常性的重新格式化服务器与经常性的进入服务器机房，因此我们关于C4机房中的18台服务器的使用非常慎重，当然也大大影响了我们的工作效率。OPenStaCk的官方网站，只是介绍了表面层次上的大体原理，与各个服务之间的相互作用服务，但是像ntp,rabbitmq这样的其他开源服务是没有介绍的，我们所找到的线索完全得益于从网上下载某些志同道合的网友所提供的安装部署文档；但是想要达到与解决各个服务以单独物理服务器提供服务的目的，这项工作仍然非常的艰难。为了避免机房服务器的重新安装，我下令让研发人员在自己的台式机上通过VirtUalbox安装虚拟服务器，我们自己的台式机箱只有2GB的内存，最多也就能够跑三台虚拟机，因此只能在这三台虚拟机上跑安装脚本，另外由于我们的台式机CPU等配置不支持虚拟化，因此我们只能够通过返回的命令行提示来确定是否安装成功，但创建虚拟机是得不到任何验证的；同时我们只能关掉一部分已经安装了虚拟服务器后再跑其他的虚拟服务器，花在查看上的时间非常多，更不要说再遇到问题与解决问题了。在这个工作过程的进行当中，我们实验环境服务器所在机柜的PDU坏了，关于PDU的采购花了很长一部分时间，大概有一个月左右，这也导致了我们的工作无法在实验环境的18台服务器中进行。我们只能在自己的台式服务器里的虚拟机中跑我们的脚本。在初期的过程中，我们并不敢跑大的虚拟机镜像，而是使用了OPenStaCk官方没有操作系统界面，只有命令行的小型UbUntU镜像。在整理与跑通安装脚本并等到实验环境的PDlJ修复后,我们才得以反复进行我们的安装脚本的实验，这个时候我们的卸载脚本也已基本成熟。能够说安装部署方面的问题已经基本上得到熟悉决。公司还要求能够自动进行安装部署，为了实现这个目标，我们将实验环境的12#服务器当作我们安装部署的资源机环境，安装部署资源大概占到了40GB左右。之因此需要一个资源机，是由于在我们的安装过程中，经常遇到了版本不统一与不一致所导致的无法安装成功，究其根源在于使用apt-get的方式安装都是使用网上资源进行下载后的安装，地址是一样的，版本却改变了。OPenStaCk当时还相当的不成熟，源代码更新比较快，同样的安装地址，昨天还能够正确安装并安装成功，转过天来就会出现有些命令都执行不通的情况出现,Keystone（身份认证）与glance（镜像服务）的安装版本不一致就导致了我们很长一段时间关于Glance的命令执行不得不使用EC2工具绕过了Keystoneo最终的解决是将版本统一后，将glance的安装步骤与Keystone的结合安装过程顺序进行倒置才成功的。在以上工作完成的基础上，由我完成了OPenStaCk的手动安装文档的初版编写，与一个版本的脚本自动安装部署由张贺军来完成的，但是关于公司的要求我们还是有很大一段距离的。比如说，关于不一致的开源服务对服务器都有不一致的要求，mysql数据库服务要求内存与CPU；VoIUnIe卷组存储服务要求硬盘多一些，glance镜像服务要求内存更大一些；操纵节点的要求比较通常，计算节点则对内存要求非常高；rabbitmq消息队列服务要求网络；network也需要网络与服务器内存给予很好的支持；还有目前关于network与quantum服务最好是能够进行服务器的单独支持；存储服务方面，代理节点的要求通常，但是存储节点需要有内存与硬盘的支持等等。需要考虑的是服务器成本的降低与整体服务的优化等方面的原因，将服务安排在指定的服务器，并自动进行修改配置；事实上，在有了资源服务器的支持以后，脚本安装与人为的手动安装方面的速度是相差不大的。从安装的正确性与准确性与成功率上来讲，手动安装更加保质保量。我号召团队成员多关注QQ群中全国的竞争对手的情况，竞争对手的情况要比我们好很多，不管从实验环境方面还是人员构成方面都令我们羡慕不已，为了不落后于竞争对手，我要求在进行以后工作的同时着手将云计算服务底层的一些功能接口进行了梳理，包含统一身份验证服务(keystone)、镜像服务(glance)、云主机服务(nova)与存储服务(SWift)等接口功能。这些接口功能也为后来的各项云计算服务产品项目的开发打下了良好的基础。我让开发人员将接口源码进行了梳理，为了能够更好的给张亚丽部门的于彪组提供更好的服务支持，我让王琳将C#接口的源代码进行有效的整理与分割,我让凌志将swift做了安装部署后,为于彪组提供关于云存储的技术服务支持。尽管沟通方面我们也经常在见面打招呼的时候询问是否有什么问题，但是接口方面的技术支持也总是断断续续。为了验证在镜像中放入大的应用服务，在启动虚拟服务器时能够将作在镜像当中的应用服务进行正常的使用，我们制作了包含国外SAP应用的服务镜像，该镜像的制作过程中也遇到了很多的问题与烦恼，首先需要将多个光盘的安装文件进行合并，这个SAP服务的安装文件一共有200多个GB,其中安装文件有四个，要紧的安装文件就有200多个GB,当时在这个地方就存在着一个问题，就是将四个安装文件进行合并，合并成功以后再上传至服务器中。但是我们的合并没有成功，要紧原因是安装文件太大了，普通的服务器或者者台式机在进行合并的过程中需要花费很长的时间，同时经常是等待很长的时间，不明白计算机是否还在进行着合并过程。在我的直觉与猜测的引导下，我决定不进行安装文件的合并，以200多GB的主安装文件来进行应用的服务器安装与镜像的制作。镜像制作成功后，另外一个问题就是由于实验环境服务器性能的影响，通过镜像服务glance上传镜像需要花费很长的时间，而且上传至glance所在的物理服务器以后，再上传至计算节点物理服务器，又需要镜像的长时间拷贝；这个在当时OpenStack的Diablo版本中是无法进行镜像上传进度的提示的，直到我们后来升级为OPenStaCk的Essex版本以后才得以解决。最终我们成功实现了将大的应用服务SAP放置在已经制作完成的镜像文件中，并成功启动该镜像的虚拟机，由于实验环境服务器的影响，速度非常慢。在进行了目前现有功能与参考网上其他云服务产品功能以后，我筛选出了我们还没能够实现的功能，其中包含增开虚拟机外网代理、虚拟机实例快照、虚拟机负载均衡、虚拟机双机热备、虚拟机实例迁移、外部接口调用修改虚拟机主机名称、虚拟机时区不一致步、Glance于Swift服务的整合、虚拟机计算节点运行状况监控、虚拟机配额限制服务、多操纵节点集群、接口操纵虚拟机网络带宽流量、提高OPenStaCk数据库的稳固性等等功能。这些功能有些成功的实现了，但是也有受制于实验环境、网络环境的限制与研发团队技术能力方面的影响，我们没有成功。关于功能的实现我决定务必本着几个原则入手：1 .在进行功能性实验前务必写好实现方案，以功能为单位进行方案文档的编写，计划好步骤，并按照步骤一步一步进行实验；2 .不管成功与否，关于出现的问题与针对问题进行的解释性记录务必落实在实现方案的文档上；3 .假如实现方案最终成功，对成功的实验功能进行总结；假如不成功，说明不成功并注明不成功的理由或者者是怀疑理由；以备将来进行针对性解决。为了能够从根本上解决底层中出现的大量BUg与帮助我们将来的研发工作,我认为研发团队中的每个人务必对OPenStaCk大体结构框架有非常准确与清晰的把握，在此基础之上才更加有把握进行源代码的修改与二次开发整合。我带着团队中的部分人员进行了文档的翻译性工作，在翻译工作的过程中也是我能够确定的熟悉到官方文档只是表面上的介绍或者者接口功能的介绍，对底层功能的研发意义尽管有但是却并不大，这也是我错误的认识了开源软件这个概念。正在这个关节上，OPenStaCk的ESSeX版本公布了，官方网站上很多文档进行了更新，我们有部分的文档的原有根据丢失了，只能凭借我们版本库中所存储的原有文档进行翻译性的查看。我们通过对官方网站上的资料查看与网上搜索到的信息资料，发现新版本的ESSeX改变了原先的DiabIO版本中的很多不足，也包含我们目前所无法解决的Bug,比如镜像服务glance上传镜像时的上传百分比的现实；最让人感到抑郁的底层的数据库表结构的改变非常的大，这让我们花费了很多功夫在DiabIO版本上的功夫很有可能是白做了。但是，也就是在这个时候，公司的SaaS平台需要上线，我们要负责底层的虚拟化环境的搭建，我们需要为SaaS平台网站提供集群式部署的服务器，统计下来SaaS平台需要30到40台不一致配置的高性能虚拟服务器来进行支持。我们也从网络运维部门获得了8台R710与1台R810,另外我们给了网络部几台R310并给了所有的R410作为正式生产环境的服务器，提供其他服务的支持。有几个问题明显的摆在我的面前，正式生产环境就要上线了，底层服务的DiablO版本还有很多BUg与不稳固的因素，在此基础上搭建正式生产环境，很多问题是无法应付的；将来在此基础上升级风险性是可想而知的，耽搁了服务怎么办？由于一旦SaaS平台一旦给公司带来盈利，赚钱的话，每一分钟、每一秒钟都是耽搁不起的；OpenStack的Essex新版本已经解决了原有的很多Bug问题，数据库底层也与原先的版本发生了很大的变化；最重要的特点是Essex在网络方面提出了新的服务quantum；毕竟使用Diablo版本还是Essex版本，前者关于将来研发的风险性很大，同时我们很可能会出现研发方向的迷失，而关于后者假如我们成功搭建完成的话不但能够解决老版本残留的问题，关于将来的工作能够开发出大片的空间；最终的结论是Diablo版本的风险会发生在将来,而Essex版本的风险性就在当时，由于我们还没有成功集群式安装。但是，就当时的情况而言，基于低配置实验环境的安装，不可能；但是有了正式的生产环境，明摆着的更好的实验环境，不如拼一把。我把我的办法告诉了我的团队，在跟陈岩光副总进行沟通以后，我们在正式生产环境上基于新的Essex版本搭建了云计算服务平台。后来的事实也证明，我的这个决定是正确的。云计算服务底层核心服务的研发方面，目前具备了大部分的虚拟机的功能,在整个团队的这11个月以来，基本上是两个方面的工作内容，一个是对基于云计算服务核心底层的上层产品的接口与技术支持、环境的保护；另一个就是云计算服务的核心研发这两个方面的工作；关于基于研发的文档知识积存，我认为这一点非常的重要，研发工作务必落实在文档上面，尽管绝大部分研发人员关于文档不够重视，但是当遇到问题的时候，原始的文档就提供了必要的帮助。2.2云计算服务管理系统云计算服务管理系统是最早完成的一个系统项目，当时OPenStaCk关于云计算服务底层拥有一个软件界面能够操控的系统，名称叫做"dashboard",后来官方将其改名为“horizon"，“horizon”这个软件系统是用Python语言进行开发的，在安装过程中也是需要进行配置文件的配置修改，基于mysql数据库来进行存储业务数据，其他就是调用OPerIStaCk的相应接口，来实现给用户进行云计算服务的界面操作。关于“horizon”这个被OPenStaCk囊括在其内的云计算服务操作系统来说，它有几个不好的地方：1.完全基于OPenStaCk云计算服务的底层功能接口与进行模块的划分，假如不熟悉OpenStack的原理的话，是无法懂得并使用与操作的；2.缺乏人性话，也就是在客户体验性方面做的还差一些，页面显示也不是很美观，比如：它没有分页的操作，更不要说关于模糊的查询操作了。基于这些特点，我编写了适合我们进行操作的云计算服务操作系统的需求并进行了业务方面的设计。为什么要提出这个系统项目，我要紧是基于下列几个方面的原因：1 .关于云计算服务底层，我们需要有自己的操作系统软件，这个毫无疑问是务必的；2 .关于我们已经实现的接口服务，没完没了的通过命令行进行加以验证相当烦恼。另外，该系统也是我们接口功能逐步实现与确认的一个终点，能够完全表达我们的工作，我们实现的功能，还有我们的价值；3 .这个操作系统目前能够给我们自己进行使用，随着逐步的优化与改良，将来早晚会成为公司的产品，我们的工作是有用功，将来不可能白做；4 .该操作系统服务当中包含着我们已经实现的接口调用，能够把它比作一个活字典，关于接口源代码的调用能够准确的找到位置并进行复制与粘贴，为将来其他产品项目的开发打下良好的基础。从后来的各个系统项目服务来说已经印证了这一点；这也是我们为什么后来系统项目得以快速开发的要紧原因。当然，在该系统项目的开发过程中，也遇到了很多的问题，比如关于一些业务数据，我们采取的是没有调用OPenStaCk所提供的接口服务，而是通过对OpenStack底层中各个服务所涉及到的数据库及数据库表结构之间的逻辑关系进行关联性方面的数据检索，当然这务必建立在我们对OPenStaCk数据库表结构相当熟悉的基础上。另外，有很多接口在OPenStaCk服务当中并没有提供，务必通过调用命令行执行才能够做到，这个关于系统项目的响应速度来讲的确是慢了很多，但是能够达到我们现阶段的目的。在云服务器资源与云存储资源的监控显示方面，我们也有很大的问题，比如云存储,我们没有办法通过接口获得剩余的存储资源、已使用的资源，我们就不得不通过人为设定系统总的存储资源，通过命令行调用获得存储已经占用的资源，剩余的则就是未使用的存储资源等等。关于统一身份验证(Keystone)来讲，在DiabIo版本中它是有超级管理员用户的，它能够管理所有的租户与租户下的用户，但是关于后来的Essex版本来讲是没有超级管理员用户的。关于这一点，OPenStaCk的“horizon”服务当中也是以一个租户为单位进行登录并进行服务的。从这一个角度来讲，我认为OpenStack服务还是面向于大批量集群式公有云服务的，由于“公有云”往往给我在概念上的懂得就是“资源无上限”。目前该系统项目的项目名称我给他取名字叫做upubecm这个系统项目目前的缺陷是浏览器兼容方面还有一些问题，功能上很多还没有来得及增加；由于当时最初的目的是给我们自己使用的，因此页面风格沿用了2011年公司联查时的系统项目的玻璃质感风格。但是，在随后的企业私有云实体机柜的操作系统诞生后，企业私有云实体机柜的操作系统囊扩了PUbeCm的所有功能，而且在页面风格与美化与客户体验等方面都完全超过了pubecm,我现在一直考虑以企业私有云操作系统取代该系统项目。由于企业私有云实体机柜的操作系统是从PUbeCm中升级出来的，它青出于蓝而胜于蓝一点都不为过。2.3云计算服务监控系统云计算服务监控系统是在后期为了能够更好的监控公司SaaS平台正式生产环境而做的一个系统监控项目。这个项目的需求与业务设计都是由我一个人来完成的。它要紧包含这么几个方面的内容：整体概况、CPU使用情况、内存使用情况、磁盘使用情况与存储资源使用情况这五个方面对服务器资源进行监控。在这个系统项目开发的过程中，遇到的最大的问题就是资源的上限一直都没有一个统一与准确的数据，在报警线数据方面我们也仍然没有一个准确的数字。关于资源上限也就是指整个服务的计算节点一共有多少核CPU,而这些CPlJ能够虚拟出多少核的CPU,这些虚拟出的CPU最大数量就是它的上限数量，而真正使用了多少以后，它的服务性能会降低或者者说有很大的影响；这一点上我们一直没有得到很好的解决。我对研发人员提出的要求是把OPenStaCk底层的算法搞清晰，通过它的算法与我们实际的参数我们得到它的上限数据；这个算法尽管是被研发人员掏出来了，但是关于具体的数据一直没有一个准确的答案。最后没办法，我们通过正式生产环境实际的数据库中的数据得到准确的答案。在正式生产环境中，有其中一个生产虚拟机服务器的计算节点，它内部所生产的虚拟机的CPU总与是它实际CPU核数的3倍，运行状况没有任何的问题。3倍的这个数据关于我来讲，已经相当的奢侈了，因此我就将3倍这个数据定为CPU的最大上限数量；关于内存来讲，OPerIStaCk的官方给的参数一直都是L5倍,也就是说生产虚拟机服务器的计算节点物理机内存的L5倍是它能够虚拟出的内存的最大数量，因此我保守的将L5倍作为了内存最大上限的倍数参数。关于磁盘空间而言，它是不需要虚拟化的，剩余多少就是多少。这样我们解决了监控系统关于数据的监控问题。2.4弹性计算应用弹性计算应用系统是为了能够给SaaS平台添加应用而做的一个小型的创建虚拟机服务器、给企业用户分配虚拟机服务器与销毁虚拟机服务器的一个小型的应用。该应用的需求设计与业务设计也是由我来完成的。该弹性计算应用，就功能上来讲该项目并不大，但是说到它当时的风险性也是与SaaS平台底层的ESSEX版本搭建是绑定在一起的，这个应用于SaaS平台上的其他应用相比，它很特殊，它的特殊性就在于它完全调用底层的接口创建虚拟机，而这些虚拟机是与支持SaaS平台的虚拟机与各个应用所占用的虚拟机服务器是平级的。因此首先为了能够把握与操纵住底层资源的限制使用而不影响SaaS平台的其他应用，我们务必开发一个弹性计算应用的后台管理系统,这个系统的目的是将底层的虚拟机服务器规格（CPU核数、内存大小、磁盘空间）同步到弹性计算应用的业务数据库中，通过管理员的筛选过滤掉大的规格，使注册与登录SaaS平台的用户只能够创建与使用低配置的虚拟机服务器。在进行该应用的开发时，首先务必开发除了底层调用的其他部分，由于底层环境还处在搭建过程当中。最大的问题是当时我们还是IaaS组，组内没有专门的美工，美工需要从于彪组进行借用，当时于彪组负责美工的是都帅；但是都帅还负责于彪组的美工与手机云存储的页面设计工作，关于弹性计算应用的页面美化方面确信是精力投入的不可能很多，但是开发任务也非常急。为了能够达到页面美化方面的要求，我组织组内的开发人员周六都干起了美化的工作,他们都很尽力，但是他们毕竟不是美工专业人员，因此页面没有能够达到我的要求，作为管理人员来讲我是说不出什么来的。最终是由张云俪所管理的美工组后来又重新给改良的。2. 5云计算服务计费系统云计算服务计费系统是公司陈岩光副总提出的一个项目，该项目的要紧目的是支持云服务网站的，对云服务网站上的产品进行定价服务的。由于我之前有过关于计费系统项目方面的经验，我针关于该系统项目进行了针关于客户与业务统计方面的扩展，由于产品的价格是与供求关系与产品的成本密不可分的。关于客户对产品的购买服务，我们需要关于客户有所熟悉与懂得。比如，客户的不一致年龄段、不一致的地域、企业还是个人等等关于产品的需求是不一致的，云服务网站作为公司云计算服务对外的窗口而言，对客户的分析与对产品购买情况的分析还有客户所关注的产品等等都需要进行统计，从统计分析中获得我们想要的结论。随后在与陈岩光副总的坚持下，将该计费系统进行了拆分，原计费系统被修改为只是对云服务产品的类型与价格进行制订；而关于用户的统计与分析与用户注册参数的制订等被拆分并独立成为用户中心系统。这个系统的开发不涉及底层云计算的核心支持服务，唯一需要关联的就是需要将云计算服务底层的镜像（操作系统,windowsXP、UbUntU等）与虚拟机规格（CPU核数、内存大小与硬盘空间）同步到计费系统的业务数据库当中来，并进行定价，以供云服务网站获取这些价格数据后，通过接口调用创建相应的虚拟机。在页面美化风格方面，由因此公司内部自己使用，因此关于页面风格仍然沿用了2011年公司联查时统一的玻璃质感风格。2.6云计算服务用户中心系统云计算服务用户中心系统是从计费系统当中拆分出来的一个系统项目，该项目的要紧功能是面向于云服务网站的用户。该项目的需求分析与设计也是由我来完成的。该系统首先是通过参数管理模块对云服务网站注册用户所需要注册的参数进行管理，比如所属国家、所属省市、所在行业、所从事职业与用户需要反馈的问题类型及问题等等。再有就是关于客户的充值、使用与剩余金额与用户关于不一致产品的购买清单等等，系统中还包含用户的统计功能，比如年龄、性别、针关于不一致产品的不一致购买人群的统计等。该系统项目并不涉及云计算服务底层的接口调用，是普通的Web项目。由因此给公司自己内部使用的，因此在页面风格上仍然沿用的2011年公司联查时的玻璃质感风格。2.7云服务网站云服务网站是在SaaS平台结束以后，由于彪组转接给我们的。这个项目最初于彪组使用的是.net技术进行的研发。由于我们在外围产品方面要紧使用的是以java语言进行的开发，因此不管从需求分析设计、页面设计还有底层代码实现上，我们能够说是推倒重来的。该网站的要紧起的作用是对公司云计算服务的技术力量与公司现有的云计算服务产品对外进行展示的窗口。网站在云计算服务的技术力量方面展示上提供云主机、云存储与云硬盘三个云计算服务技术力量的展示；在产品方面有企业私有云实体机柜实体产品与企业私有云方案两种供网上用户下订单的方式进行推广销售。网站内为用户提供了用户中心与操纵台这两个模块对注册登录用户提供云计算的应用服务。由云计算服务计费系统、用户中心系统与网站内容管理系统对该网站提供信息数据支持服务。2.8云服务网站内容管理系统云服务网站的内容管理系统是对云服务网站的内容展示信息的后台管理系统，该系统的要紧内容包含产品服务动态管理、市场活动管理、客户案例管理与合作伙伴管理等功能模块。该系统的业务需求前期是由我来完成，后期由李立召完成对需求文档的编写，并完成开发工作。2.9企业私有云实体机柜操作系统企业私有云实体机柜是企业私有云实体机柜内的云计算服务软件产品之一,该系统要紧面向于购买企业私有云实体机柜产品的企业网络管理人员，由管理人员登入系统，进行虚拟服务器的创建、快照备份、分配/释放IP、升级、暂停、运行、销毁等操作。该系统项目的需求分析与业务设计是由我来完成的。该系统项目是一个产品软件，从页面风格、客户体验还有功能的使用等方面都做到了全面的细化。在该产品的开发过程当中，也是由于云计算服务底层核心的影响造成了功能不稳固的情况，比如有的时候迁移成功，有的时候迁移不成功，有的时候升级成功而有的时候升级不成功。由于使用的是3台R310的2GB内存的低配置,创建的虚拟机只能够是512MB内存的小型镜像；因此有些bug不得不怀疑是由于底层服务器性能方面的影响，造成功能的不稳固。后来从网络部借用了2台R710高配置的服务器一周多的时间，问题才加以解决。2.10企业私有云实体机柜监控系统企业私有云实体机柜监控系统，也是企业私有云实体机柜内的软件产品之-O该系统的要紧功能是对企业私有云实体机柜的物理资源机与生产虚拟机的物理服务器资源的监控。该系统的需求分析、业务逻辑设计是由我来完成的。该系统产品项目的要紧功能包含整体使用情况、服务器情况、CPU使用情况、内存使用情况、磁盘空间情况、外网IP数量监控、虚拟机报警与资源及报警等几个数据监控模块。面向于企业的数据中心管理人员，能够直观的查看企业私有云实体机柜的使用情况。3 .团队建设在团队建设方面，我将虚拟化基础架构业务部从最初的“laaS”组到现在一共分为初期、中期与后期三个阶段，初期阶段是从2011年11月份到年后在C6办公到搬到B8楼的202之前；中期阶段是我们在B8楼的202室的工作期间；后期阶段是我们从B8楼的202室再次搬回到C6。在这三个阶段过程中，关于团队的建设也曾经遇到了很多的困难与问题，毕竟从管理角度来讲，团队中的人员变动，哪怕只增加一个成员都会通过形成期、震荡期、表现期与正规期四个阶段。在团队建设方面我能够说投入了大量的精力，虚拟化基础架构业务部的团队成员大多数的能力都非常强，同时个性也非常强，特别关于一直高新技术的团队，管理的难度与强度是非常大的。从熟悉他们到懂得他们，平稳他们的工作情绪，改善他们的工作心态，提高他们的工作效率与工作质量是非常费神的一项工作。3.1 初期团队人员统计表序号现有人员加入离开1王毅2王凌志3王琳4张瑞祥5张志楠6张贺军7张志涛8李健总计8人在团队建设的初期，我的团队中包含我在内一共只有四个成员，他们是我、王凌志、王琳与张瑞祥。从每个人的性格特点来讲，王凌志是一个非常有灵气的人，聪明、能干有办法、胆子大，认准的情况即使是错误的也敢作，假如做的情况方向正确，是非常得力的一个好帮手；但是缺点是，对待情况缺乏成熟的思考，这往往也是我为什么需要重点关注他的原因；王琳是一个JaVa开发人员，只对开发感兴趣，对云计算能够说兴趣不大，他的技术能力我非常认可，开发速度非常快，关于有疑问与不一致的见解敢于大胆提出来，但是缺点与不足是，往往在某些开发过程当中使用了我个人认为不合理的设计模式；文档的编写能力上差一些，有待培养。张瑞祥的优点是测试方面的技术、只是经验丰富，缺点是非常爱玩游戏，但是关于我的提醒与忠告他还是能够听进去的，在给分配安排工作后，还是能够做到扔下游戏主动工作的，但是工作完成的质量方面也许个人能力的影响不是非常的好。由于工作的需要，从张亚丽组调配来了张志楠与张贺军，张志楠是一个非常钻研技术的人，工作起来有一股轴劲，认准的情况八匹马都拉不回来，但是在我后来的教诲与指引下，已经改变了很多，在做情况的正确逻辑思维方向上有很大的进步。张贺军为人性格胆小，但是做情况非常踏实与实在，在某些技术关键点上能够提出合理的建议，并有让我出乎意料的正确的办法；但是他们两个人都有一个最大的缺点就是不善于表达，从这一点来说，这个缺点是非常致命的，确信会影响到他们将来的职业进展。我往往在开会或者者指定工作方案的时候尽量给他们说话的机会，让他们能够尽情的表达出他们的办法，锻炼他们的表达思维；尽管进展缓慢，但是效果比之前已经好很多了。之后李健与张志涛加入了我们的团队，李健是陈岩光副总从其他的云计算服务公司挖过来的，在虚拟化云计算方面有过一到两年的工作经验，关于虚拟化方面与虚拟化的底层比我们熟悉很多，他的学习能力非常强，从工作状态中能够看的出对云计算技术还是非常有热情的，缺点也是在沟通上，他的沟通不像是贺军那样的先天的缺陷，而是过于保守。张志涛是我们部门当时急于需要的一个网络、服务器硬件方面的工程师，他往往给人的感受是让人放心，喜欢微笑，乐乐呵呵的，就是这样一个表现让我对他的人与工作方面的管理大意了。这个人在工作态度上还是很认确实，但是缺乏社会工作经验与人际关系间的应对，关于公司的管理制度难以习惯，与在团队当中的自傲性格使得他后来离开了公司，从对他的熟悉与关注方面来讲，我需要负有一定的责任。随着初期团队的雏形逐步成形，慢慢的团队会进入到形成期，为了能够加深彼此的熟悉，我请了团队所有成员去“万家灯火”的一个餐馆吃了一顿饭，大家在一起欢声笑语，大吃大喝。我心里也非常高兴，但是心里的压力也大，将来他们就是公司云计算的中坚力量与核心成员，他们能做到吗。在饭桌上大家畅所欲言，我也说了我对将来的一些办法，希望大家能够团结；工作方面多沟通多互相帮助。我也试图跟他们每个人进行聊天与对话，熟悉他们的个人办法。3.2 中期团队人员统计表序号现有人员加入离开1王毅2王凌志3王琳4张瑞祥5张志楠6张贺军7张志涛8李健9蓝文静10张磊11李立召12霍世彬13程乐总计10人中期要紧是指我们由C6搬到B8的这段时间，也就是在B8的202工作的这段时间，在搬过去以后，我的团队增加了蓝文静、张磊、李立召、霍世斌与实习生程乐这些人员。蓝文静这个女孩就像她的名字所描述的那样，是一个文静的女孩，是做测试的，为了弥补张瑞祥在测试过程当中的疏漏，有文静来进行弥补我也是非常放心的。文静为人踏实，在文档的整理与翻译的工作过程中是非常稳重的；张磊是新招的开发人员，比较偏爱于UI。基本的工作技能偏向于页面表现层方面，但是不好的是业务逻辑方面差一些，反应上稍显迟钝。这个需要慢慢的进行培养。李立召的技术扎实全面，工作态度认真，踏实稳重，唯一不好的地方是思维视野方面还不够开阔，这方面需要我给他机会来进行足够的锻炼。霍世彬性格上来讲是一个可爱的小伙子，更刚来时从杨颖那反馈来的“二”来形容根本就是冤枉了他。网络方面的技术比较全面，不足之处在于书本上的东西熟悉比较多，但是实践上还是少了些。程乐是一个在校的大学生，没有工作经验，是来公司进行实习的。性格比较孤僻，技术上基本的理论知识都是具备的，但是不足的是社会经验少，他给人的感受是依靠性比较强但是又不想去依靠别人,后来的事实也证明了这一点。在团队建设的中期进展阶段里，我大部分的精力都花在了工作进展与项目的管理与设计过程当中，但是越是这样，往往团队当中发生的情况就越多，当然也有我所察觉到的与没有察觉到的。首先，蓝文静提出了辞职，并离开了公司。最初关于蓝文静的定位还只是一个测试人员，但是由于部分的测试工作已经完成的时候，为了避免人力资源的浪费，我开始让她更多的接触一些云计算服务官方文档的资料整理，在这方面的工作我是这样懂得的，尽管我们是以OPenStaCk为切入点，以它为切入点向外进一步展开对云计算的研发，但是从根上来讲还是要从OPenStaCk的官方文档入口，并整理与梳理出我们自己对它的懂得与认识，目前的人员状况还不能够完全有把握查看OPenStaCk的源代码并基于源代码进行修改以达到我的要求，再者随着人员的不断加入与扩大，我们也需要拥有自己的培训资料，也就是说不管是谁、应聘的什么职位，只要进入IaaS组，就务必对我们的云计算工作范围与工作内容有所熟悉，以达到工作上的沟通顺畅，工作能够保证拥有统一的步伐与步调。公司不同意进行组内的知识性培训，按照公司的懂得，上班来不是上学来的这一原则，我让文静在整理文档并进行翻译的同时，整理了一套python语言的培训教程，通过定期的将文静整理的资料跟大家共同探讨的同时，顺便将Python语言进行了短暂的培训。这也为后来组内的研发团队进一步深入OPenStaCk的研究与修改功能代码打下了一个良好的开端。最终，文静还是由于个人原因，由于她要结婚，因此务必到塘沽去追随他的丈夫，而离开了公司。张瑞祥是由于公司部门内部调整，由于公司的部门内部成立了测试组，因此他离开我们的团队，但是他所工作的测试范围仍然是以我们组的软件产品项目为主，因此我们还是有工作交集的。关于他爱玩游戏这一缺点，我私下里也跟他单独谈论过多次，我站在他