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

工作总结〔2024年11月～2024年9月〕虚拟化根底架构业务部王毅2024-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.总结 20

1.概述从2024年11月份至2024年九月份，我主动要求接受公司分派的云计算开源软件OpenStack的研发任务，到至今已经完成云计算产品效劳的大局部功能，并基于已经研发出来的功能生产出一系列的软件产品共花了11个月的时间。在这11个月的时间里，无论是对于产品工程的开发、云计算底层效劳研发，还是团队建设等方面都遇到了不同程度的问题和困难。虚拟化根底架构业务部从刚刚开始的“IaaS组〞到现在成为部门，人员也由最初的四个人开展到现在的13个人。以下是我从工程和团队建设两个方面着手，将问题融入到工程和团队建设当中来进行虚拟化根底架构业务部的工作总结。

2.工程目前虚拟化根底架构业务部围绕着云计算底层效劳的研发所完成的工程比较多，主要包括?云计算效劳管理系统-PUBECM?、?云计算效劳监控系统-PUBECC?、?弹性计算应用-ECA?、?云计算效劳计费系统-CSBS?、?云计算效劳用户中心系统-CSUC?、?云效劳网站-CSNT?、?云效劳网站内容管理系统-CSMS?、?企业私有云实体机柜操作系统-PRVECM?、?企业私有云实体机柜监控系统-PRVECC?等。其实，作为云计算效劳底层的研发工作，也可以算是一个主要的工程，毕竟它是我们云计算效劳底层的核心。2.1云计算效劳底层核心2024年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#的编号，其中15#～19#五台效劳器是DELL的R410效劳器，其他效劳器是2GB的内存配置。为了保证安装脚本在我们自己掌控下顺利进行，我决定将八角楼的效劳器中的1#机和2#机搬到了办公地点作为云存储的脚本安装及功能测试；后来张亚丽组的张志楠和张贺军的参加所带来的两台惠普效劳器成为了办公地点虚拟机的脚本安装及功能研发和测试的环境，通过这四台效劳器组成了我们的办公地点的实验环境。但是为了能够彻底解决OpenStack底层各项效劳之间的搭配工作，能够准确的找到问题的出现位置，锁定效劳目标；我采取了将效劳器各个效劳单独存放至一台物理效劳器当中，来进行功能性验证和观察。准确的来讲在C4八角楼机房里有18台效劳器供我们使用，但是由于不能够经常性的重新格式化效劳器和经常性的进入效劳器机房，所以我们对于C4机房中的18台效劳器的使用非常慎重，当然也大大影响了我们的工作效率。OpenStack的官方网站，只是介绍了外表层次上的大体原理，以及各个效劳之间的相互作用效劳，但是像ntp、rabbitmq这样的其他开源效劳是没有介绍的，我们所找到的线索完全得益于从网上下载某些志同道合的网友所提供的安装部署文档；但是想要到达和解决各个效劳以单独物理效劳器提供效劳的目的，这项工作仍然非常的艰难。为了防止机房效劳器的重新安装，我下令让研发人员在自己的台式机上通过virtualbox安装虚拟效劳器，我们自己的台式机箱只有2GB的内存，最多也就可以跑三台虚拟机，所以只能在这三台虚拟机上跑安装脚本，另外由于我们的台式机CPU等配置不支持虚拟化，所以我们只能够通过返回的命令行提示来确定是否安装成功，但创立虚拟机是得不到任何验证的；同时我们只能关掉一局部已经安装了虚拟效劳器后再跑其他的虚拟效劳器，花在查看上的时间非常多，更不要说再遇到问题和解决问题了。在这个工作过程的进行当中，我们实验环境效劳器所在机柜的PDU坏了，对于PDU的采购花了很长一局部时间，大概有一个月左右，这也导致了我们的工作无法在实验环境的18台效劳器中进行。我们只能在自己的台式效劳器里的虚拟机中跑我们的脚本。在初期的过程中，我们并不敢跑大的虚拟机镜像，而是采用了OpenStack官方没有操作系统界面，只有命令行的小型ubuntu镜像。在整理和跑通安装脚本并等到实验环境的PDU修复后，我们才得以反复进行我们的安装脚本的实验，这个时候我们的卸载脚本也已根本成熟。可以说安装部署方面的问题已经根本上得到了解决。公司还要求可以自动进行安装部署，为了实现这个目标，我们将实验环境的12#效劳器当作我们安装部署的资源机环境，安装部署资源大概占到了40GB左右。之所以需要一个资源机，是因为在我们的安装过程中，经常遇到了版本不统一和不一致所导致的无法安装成功，究其根源在于采用apt-get的方式安装都是采用网上资源进行下载后的安装，地址是一样的，版本却改变了。OpenStack当时还相当的不成熟，源代码更新比较快，同样的安装地址，昨天还可以正确安装并安装成功，转过天来就会出现有些命令都执行不通的情况出现，Keystone〔身份认证〕和glance〔镜像效劳〕的安装版本不一致就导致了我们很长一段时间对于Glance的命令执行不得不采用EC2工具绕过了Keystone。最终的解决是将版本统一后，将glance的安装步骤和Keystone的结合安装过程顺序进行倒置才成功的。在以上工作完成的根底上，由我完成了OpenStack的手动安装文档的初版编写，和一个版本的脚本自动安装部署由张贺军来完成的，但是对于公司的要求我们还是有很大一段距离的。比方说，对于不同的开源效劳对效劳器都有不同的要求，mysql数据库效劳要求内存和CPU；Volume卷组存储效劳要求硬盘多一些，glance镜像效劳要求内存更大一些；控制节点的要求比较一般，计算节点那么对内存要求非常高；rabbitmq消息队列效劳要求网络；network也需要网络和效劳器内存给予很好的支持；还有目前对于network和quantum效劳最好是能够进行效劳器的单独支持；存储效劳方面，代理节点的要求一般，但是存储节点需要有内存和硬盘的支持等等。需要考虑的是效劳器本钱的降低以及整体效劳的优化等方面的原因，将效劳安排在指定的效劳器，并自动进行修改配置；其实，在有了资源效劳器的支持以后，脚本安装和人为的手动安装方面的速度是相差不大的。从安装的正确性和准确性以及成功率上来讲，手动安装更加保质保量。我号召团队成员多关注QQ群中全国的竞争对手的情况，竞争对手的情况要比我们好很多，无论从实验环境方面还是人员构成方面都令我们羡慕不已，为了不落后于竞争对手，我要求在进行以后工作的同时着手将云计算效劳底层的一些功能接口进行了梳理，包括统一身份验证效劳〔keystone〕、镜像效劳〔glance〕、云主机效劳〔nova〕和存储效劳〔swift〕等接口功能。这些接口功能也为后来的各项云计算效劳产品工程的开发打下了良好的根底。OpenStack是用python语言开发的，在官方上有很好的接口效劳文档，通过官方接口文档的描述，我们知道OpenStack是采用的http协议的Restful接口技术实现的，类似于通常所说的WebService接口效劳技术。对于接口的调用，研发人员从网上下载了针对于存储效劳的两种接口调用源代码，一个是java的；另一个C#语言的。通过接口对于现有的功能的理解后，我对云计算效劳有了更加深刻的理解，主要是云存储和虚拟机两个方面；我认为可以建设一个云效劳的网站，可以提供类似于网盘效劳以及虚拟主机的同时，还可以将企业的应用效劳做在创立虚拟机的镜像当中，这样就实现了网上的SaaS平台，并通过邮件的方式向陈岩光副总提交了我的想法。由于当时公司想要一个比较绚丽的，所以.net的silverlight可以到达要求。张亚丽部门就负责了云效劳网站的开发工作，我们作为底层对他们提供接口效劳，他们最先的工作主要是云存储。我让开发人员将接口源码进行了梳理，为了能够更好的给张亚丽部门的于彪组提供更好的效劳支持，我让王琳将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改变了原来的Diablo版本中的很多缺乏，也包括我们目前所无法解决的Bug，比方镜像效劳glance上传镜像时的上传百分比的现实；最让人感到抑郁的底层的数据库表结构的改变非常的大，这让我们花费了很多功夫在Diablo版本上的功夫很有可能是白做了。可是，也就是在这个时候，公司的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数据库来进行存储业务数据，其他就是调用OpenStack的相应接口，来实现给用户进行云计算效劳的界面操作。对于“horizon〞这个被OpenStack囊括在其内的云计算效劳操作系统来说，它有几个不好的地方：1.完全基于OpenStack云计算效劳的底层功能接口和进行模块的划分，如果不了解OpenStack的原理的话，是无法理解并使用和操作的；2.缺乏人性话，也就是在客户体验性方面做的还差一些，页面显示也不是很美观，比方：它没有分页的操作，更不要说对于模糊的查询操作了。基于这些特点，我编写了适合我们进行操作的云计算效劳操作系统的需求并进行了业务方面的设计。为什么要提出这个系统工程，我主要是基于以下几个方面的原因：1.对于云计算效劳底层，我们需要有自己的操作系统软件，这个毫无疑问是必须的；2.对于我们已经实现的接口效劳，没完没了的通过命令行进行加以验证相当麻烦。另外，该系统也是我们接口功能逐渐实现和确认的一个终点，可以完全表达我们的工作，我们实现的功能，还有我们的价值；3.这个操作系统目前可以给我们自己进行使用，随着逐渐的优化和改良，将来早晚会成为公司的产品，我们的工作是有用功，将来不会白做；4.该操作系统效劳当中包含着我们已经实现的接口调用，可以把它比作一个活字典，对于接口源代码的调用可以准确的找到位置并进行复制和粘贴，为将来其他产品工程的开发打下良好的根底。从后来的各个系统工程效劳来说已经印证了这一点；这也是我们为什么后来系统工程得以快速开发的主要原因。当然，在该系统工程的开发过程中，也遇到了很多的问题，比方对于一些业务数据，我们采取的是没有调用OpenStack所提供的接口效劳，而是通过对OpenStack底层中各个效劳所涉及到的数据库及数据库表结构之间的逻辑关系进行关联性方面的数据检索，当然这必须建立在我们对OpenStack数据库表结构相当了解的根底上。另外，有很多接口在OpenStack效劳当中并没有提供，必须通过调用命令行执行才能够做到，这个对于系统工程的响应速度来讲确实是慢了很多，但是能够到达我们现阶段的目的。在云效劳器资源和云存储资源的监控显示方面，我们也有很大的问题，比方云存储，我们没有方法通过接口获得剩余的存储资源、已使用的资源，我们就不得不通过人为设定系统总的存储资源，通过命令行调用获得存储已经占用的资源，剩余的那么就是未使用的存储资源等等。对于统一身份验证〔Keystone〕来讲，在Diablo版本中它是有超级管理员用户的，它可以管理所有的租户和租户下的用户，但是对于后来的Essex版本来讲是没有超级管理员用户的。对于这一点，OpenStack的“horizon〞效劳当中也是以一个租户为单位进行登录并进行效劳的。从这一个角度来讲，我认为OpenStack效劳还是面向于大批量集群式公有云效劳的，因为“公有云〞往往给我在概念上的理解就是“资源无上限〞。目前该系统工程的工程名称我给他取名字叫做“pubecm〞。这个系统工程目前的缺陷是浏览器兼容方面还有一些问题，功能上很多还没有来得及增加；由于当时最初的目的是给我们自己使用的，所以页面风格沿用了2024年公司联查时的系统工程的玻璃质感风格。但是，在随后的企业私有云实体机柜的操作系统诞生后，企业私有云实体机柜的操作系统囊扩了pubecm的所有功能，而且在页面风格和美化以及客户体验等方面都完全超过了pubecm，我现在一直考虑以企业私有云操作系统取代该系统工程。因为企业私有云实体机柜的操作系统是从pubecm中升级出来的，它青出于蓝而胜于蓝一点都不为过。2.3云计算效劳监控系统云计算效劳监控系统是在后期为了能够更好的监控公司SaaS平台正式生产环境而做的一个系统监控工程。这个工程的需求和业务设计都是由我一个人来完成的。它主要包括这么几个方面的内容：整体概况、CPU使用情况、内存使用情况、磁盘使用情况和存储资源使用情况这五个方面对效劳器资源进行监控。在这个系统工程开发的过程中，遇到的最大的问题就是资源的上限一直都没有一个统一和准确的数据，在报警线数据方面我们也仍然没有一个准确的数字。关于资源上限也就是指整个效劳的计算节点一共有多少核CPU，而这些CPU能够虚拟出多少核的CPU，这些虚拟出的CPU最大数量就是它的上限数量，而真正使用了多少以后，它的效劳性能会降低或者说有很大的影响；这一点上我们一直没有得到很好的解决。我对研发人员提出的要求是把OpenStack底层的算法搞清楚，通过它的算法和我们实际的参数我们得到它的上限数据；这个算法虽然是被研发人员掏出来了，但是对于具体的数据一直没有一个准确的答案。最后没方法，我们通过正式生产环境实际的数据库中的数据得到准确的答案。在正式生产环境中，有其中一个生产虚拟机效劳器的计算节点，它内部所生产的虚拟机的CPU总和是它实际CPU核数的3倍，运行状况没有任何的问题。3倍的这个数据对于我来讲，已经相当的奢侈了，所以我就将3倍这个数据定为CPU的最大上限数量；对于内存来讲，OpenStack的官方给的参数一直都是1.5倍，也就是说生产虚拟机效劳器的计算节点物理机内存的1.5倍是它能够虚拟出的内存的最大数量，因此我保守的将1.5倍作为了内存最大上限的倍数参数。对于磁盘空间而言，它是不需要虚拟化的，剩余多少就是多少。这样我们解决了监控系统对于数据的监控问题。2.4弹性计算应用弹性计算应用系统是为了能够给SaaS平台添加应用而做的一个小型的创立虚拟机效劳器、给企业用户分配虚拟机效劳器和销毁虚拟机效劳器的一个小型的应用。该应用的需求设计和业务设计也是由我来完成的。该弹性计算应用，就功能上来讲该工程并不大，但是说到它当时的风险性也是与SaaS平台底层的ESSEX版本搭建是绑定在一起的，这个应用于SaaS平台上的其他应用相比，它很特殊，它的特殊性就在于它完全调用底层的接口创立虚拟机，而这些虚拟机是与支持SaaS平台的虚拟机以及各个应用所占用的虚拟机效劳器是平级的。因此首先为了能够把握和控制住底层资源的限制使用而不影响SaaS平台的其他应用，我们必须开发一个弹性计算应用的后台管理系统，这个系统的目的是将底层的虚拟机效劳器规格〔CPU核数、内存大小、磁盘空间〕同时到弹性计算应用的业务数据库中，通过管理员的筛选过滤掉大的规格，使注册和登录SaaS平台的用户只能够创立和使用低配置的虚拟机效劳器。在进行该应用的开发时，首先必须开发除了底层调用的其他局部，因为底层环境还处在搭建过程当中。最大的问题是当时我们还是IaaS组，组内没有专门的美工，美工需要从于彪组进行借用，当时于彪组负责美工的是郜帅；但是郜帅还负责于彪组的美工以及手机云存储的页面设计工作，对于弹性计算应用的页面美化方面肯定是精力投入的不会很多，但是开发任务也非常急。为了能够到达页面美化方面的要求，我组织组内的开发人员周六都干起了美化的工作，他们都很尽力，但是他们毕竟不是美工专业人员，所以页面没有能够到达我的要求，作为管理人员来讲我是说不出什么来的。最终是由张云俪所管理的美工组后来又重新给改良的。2.5云计算效劳计费系统云计算效劳计费系统是公司陈岩光副总提出的一个工程，该工程的主要目的是支持云效劳网站的，对云效劳网站上的产品进行定价效劳的。由于我之前有过关于计费系统工程方面的经验，我针对于该系统工程进行了针对于客户和业务统计方面的扩展，因为产品的价格是与供求关系以及产品的本钱密不可分的。对于客户对产品的购置效劳，我们需要对于客户有所了解和理解。比方，客户的不同年龄段、不同的地域、企业还是个人等等对于产品的需求是不同的，云效劳网站作为公司云计算效劳对外的窗口而言，对客户的分析以及对产品购置情况的分析还有客户所关注的产品等等都需要进行统计，从统计分析中获得我们想要的结论。随后在与陈岩光副总的坚持下，将该计费系统进行了拆分，原计费系统被修改为只是对云效劳产品的类型和价格进行制订；而对于用户的统计和分析以及用户注册参数的制订等被拆分并独立成为用户中心系统。这个系统的开发不涉及底层云计算的核心支持效劳，唯一需要关联的就是需要将云计算效劳底层的镜像〔操作系统,windowsXP、ubuntu等〕和虚拟机规格〔CPU核数、内存大小和硬盘空间〕同时到计费系统的业务数据库当中来，并进行定价，以供云效劳网站获取这些价格数据后，通过接口调用创立相应的虚拟机。在页面美化风格方面，由于是公司内部自己使用，所以对于页面风格仍然沿用了2024年公司联查时统一的玻璃质感风格。2.6云计算效劳用户中心系统云计算效劳用户中心系统是从计费系统当中拆分出来的一个系统工程，该工程的主要功能是面向于云效劳网站的用户。该工程的需求分析和设计也是由我来完成的。该系统首先是通过参数管理模块对云效劳网站注册用户所需要注册的参数进行管理，比方所属国家、所属省市、所在行业、所从事职业以及用户需要反响的问题类型及问题等等。再有就是对于客户的充值、使用和剩余金额以及用户对于不同产品的购置清单等等，系统中还包括用户的统计功能，比方年龄、性别、针对于不同产品的不同购置人群的统计等。该系统工程并不涉及云计算效劳底层的接口调用，是普通的Web工程。由于是给公司自己内部使用的，所以在页面风格上仍然沿用的2024年公司联查时的玻璃质感风格。2.7云效劳网站云效劳网站是在SaaS平台结束以后，由于彪组转接给我们的。这个工程最初于彪组采用的是.net技术进行的研发。由于我们在外围产品方面主要采用的是以java语言进行的开发，所以无论从需求分析设计、页面设计还有底层代码实现上，我们可以说是推倒重来的。该网站的主要起的作用是对公司云计算效劳的技术力量以及公司现有的云计算效劳产品对外进行展示的窗口。网站在云计算效劳的技术力量方面展示上提供云主机、云存储和云硬盘三个云计算效劳技术力量的展示；在产品方面有企业私有云实体机柜实体产品和企业私有云方案两种供网上用户下订单的方式进行推广销售。网站内为用户提供了用户中心和控制台这两个模块对注册登录用户提供云计算的应用效劳。由云计算效劳计费系统、用户中心系统和网站内容管理系统对该网站提供信息数据支持效劳。2.8云效劳网站内容管理系统云效劳网站的内容管理系统是对云效劳网站的内容展示信息的后台管理系统，该系统的主要内容包括产品效劳动态管理、市场活动管理、客户案例管理以及合作伙伴管理等功能模块。该系统的业务需求前期是由我来完成，后期由李立召完成对需求文档的编写，并完成开发工作。2.9企业私有云实体机柜操作系统企业私有云实体机柜是企业私有云实体机柜内的云计算效劳软件产品之一，该系统主要面向于购置企业私有云实体机柜产品的企业网络管理人员，由管理人员登入系统，进行虚拟效劳器的创立、快照备份、分配/释放IP、升级、暂停、运行、销毁等操作。该系统工程的需求分析和业务设计是由我来完成的。该系统工程是一个产品软件，从页面风格、客户体验还有功能的使用等方面都做到了全面的细化。在该产品的开发过程当中，也是由于云计算效劳底层核心的影响造成了功能不稳定的情况，比方有的时候迁移成功，有的时候迁移不成功，有的时候升级成功而有的时候升级不成功。由于采用的是3台R310的2GB内存的低配置，创立的虚拟机只可以是512MB内存的小型镜像；所以有些bug不得不疑心是由于底层效劳器性能方面的影响，造成功能的不稳定。后来从网络部借用了2台R710高配置的效劳器一周多的时间，问题才加以解决。2.10企业私有云实体机柜监控系统企业私有云实体机柜监控系统，也是企业私有云实体机柜内的软件产品之一。该系统的主要功能是对企业私有云实体机柜的物理资源机以及生产虚拟机的物理效劳器资源的监控。该系统的需求分析、业务逻辑设计是由我来完成的。该系统产品工程的主要功能包括整体使用情况、效劳器情况、CPU使用情况、内存使用情况、磁盘空间情况、外网IP数量监控、虚拟机报警和资源及报警等几个数据监控模块。面向于企业的数据中心管理人员，能够直观的查看企业私有云实体机柜的使用情况。3.团队建设在团队建设方面，我将虚拟化根底架构业务部从最初的“IaaS〞组到现在一共分为初期、中期和后期三个阶段，初期阶段是从2024年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的研究和修改功能代码打下了一个良好的开端。最终，文静还是由于个人原因，因为她要结婚，所以必须到塘沽去追随他的丈夫，而离开了公司。张瑞祥是由于公司部门内部调整，因为公司的部门内部成立了测试组，所以他离开我们的团队，但是他所工作的测试范围仍然是以我们组的软件产品工程为主，所以我们还是有工作交集的。对于他爱玩游戏这一缺点，我私下里也跟他单独谈论过屡次，我站在他个人的角度出发，提出要为自己的将来着想，游戏给他带来不了什么，对他起不到任何作用和好处；我的这些良苦用心希望他将来能够体会的到。张志涛的离开有他自己的原因，也有局部我的责任，我之前已经说明过了。在B8楼202的工作工程中，除了对底层效劳研发、维护和对上层软件产品工程开发的设计及管理方面的工作外。筛选待面试人员的工作简历并进行面试也成为了我日常工作过程中不可缺少的一局部，当然也是团队建设过程中所必须的。工作也经常被打断，简历也经常会收到很多份，并从中筛选出我需要的人员。立召和张磊都是这一时期吸纳进来的开发人员。对于研发团队的管理上，王琳可以说在云计算效劳产品的系统工程的研发方面功不可没，因为之前的云计算效劳操作系统、用户中心系统、计费系统，虽然需求分析、业务逻辑设计都是由我来做的，但是代码的开发都是由他一个人来完成，在开发速度上因为采用的是他所熟悉的开发框架SSH+LigerUI所以非常快。但是在制作弹性计算应用时，他却范了我认为致命的错误，他把弹性计算应用的所有页面作在了一个页面文件当中，这也包括后来的监控系统；后来在我得知到这个情况以后，专门在开会时找他询问了这个问题。他从访问速度、软件性能以及前台页面异步调用的开发效率以及弹性计算应用是一个小的工程等方面说明了他的理由，在听取了他的意见以后，我认为我要考虑软件工程整体的可扩展性，可维护性以及更加重要的合理性来考虑。为了能够到达我的要求和目的，我让张磊接手了弹性计算应用的修改和维护工作，让李立召全面接手了云计算计费系统和用户中心系统这两个工程的修改和维护工作。平均分担了三个人的工作量，确实开发工作都压在王琳一个人的身上也太不公平；王琳那么继续底层接口效劳以及对张磊和李立召的指导和支援。对于云计算效劳底层的研发工作，我主张不能够将所有的功能效劳控制在某一个人的手里。由于在凌志身上产生了不稳定因素，所以我将OpenStack的新版本Essex的研发工作向贺军和志楠方面有所倾斜；李健的精力集中在了基于核心的外围功能的扩展方面，大局部的新版本研发工作，尤其是新版本的特性“虚拟网络〔Quantum〕〞集中在了张志楠和张贺军的手里，我对他们进行了模块的划分；为了能够让他们顺利在运行过程中修改和调试底层扩展研发的代码，我将剩余的实验环境效劳器对他们进行了分配，使得他们可以在自己的集群中运行自己修改的代码，并最终结合得到我们自己的一个版根源码。这样，对于底层云计算效劳核心代码我们就能够逐渐的进行自己掌控。后来，他们也都慢慢的做到了这一点。程乐是一个在校的大学实习生，他来自天大。从外表上来看文绉绉的，是一个干技术的料。在对待他的问题上，我把他委托给了王琳来作为他的指导老师，王琳是技术开发出身，包括我在内很