另一方面，依据IT系统通常都会经历建设，应用/运维，优化和再投资这样的规律，现在我们主要是在搞建云和一部分运维的技术。 下一阶段的重点是面向应用支撑的技术，会涉及docker和服务管理等技术。同步会做的就是资源统一管理、调度和容量管理， 算是在优化和再投资决策方面做一些事。在云平台项目， 客户的不同角色的人需要不同功能集合。 很明显， 建设和运维是IT部门的需求， 应用支持则是业务部门的需求， 资源优化和再投资方面则是CIO一类角色的需求。按照各种划分，我们安排产品研发计划、做售前技术方案是就会有针对性考虑。

　　总结一下， 云是新一代IT， 实践云是个IT架构的演进过程， 我们应该提供满足不同阶段业务目标的解决方案。 最后说句我们的宣传词，科技是第一生产力， skyform让云成为生产力。

　　Q1：请教下，不太适合采用openstack这样固定配置的管理思路。固定如何理解?

　　A: VM配置在实际环境中光disk就有好几种配置，另外网卡个数，是否支持一些特殊的硬件如光驱，USB都有可能。openstack基本不会全覆盖， 但在遗产系统中往往会有。我们也不能随便改它。这是虚拟化时代的特征，我们能做的就是先接管，做自助式管理。

　　Q2: 明白了。另外，你们基于vcenter做vmware管理，有什么特性缺失吗?多谢

　　A: 缺的其实也不少， 不过可以根据用户场景添加。但其实大家常用的基本都类似， 补一补就差不多了。

　　Q3：对用户已有的vm你们怎么接管?因为这些虚机的配置你们数据库里面没有，如何建库?

　　A: 这样的需求在国外大概5年前就类似， 我们通过API动态发现VM然后插入数据库， 配置固定包含基本的CPU，内存，Disk， 模板及其他常规几种， 也可以用key value pair保存特殊的内容。这个我们是从CloudStack时代就开始做了，现在在往openstack上迁移。有OpenStack厂商有类似实践，大家的需求和思路基本都类似

　　Q4： Vmware的存量纳管是通过openstack还是Skyform来实现?

　　A： 分两种模式， 一种可以不要openstack， 一种是在openstack上装上我们的扩展包。 扩展包不会修改openstack，在旁边做一些辅助的工作比如存一些扩展信息，目的是尽量保持原生的openstack。这样，任何一家openstack我们都可以做到较好的支持。 当然这个也比较理想， 得做点东西而且实际上还是有点限制的

　　Q5:你们是完全自己开发，还是把一些产品集成?

　　A: 除了openstack，CloudStack之类，基本都是自己开发。当然也集成了zabbix作为监控采集组件，不过不是必选。另外也集成一些大数据的技术平台技术，比如YARN，HBase之类做一些调度工作。

　　Q6: 如果配置特殊不符合你们的模型呢?比如多个三层网络手动配置了路由之类的。

　　A: 在模型不能完全支持时，就考虑功能退化，提供管理自服务和监控。用户一定要就在定制一些东西，但实际这种情况不是很多

　　Q7: 另外你们在skyform有没有做基础设施抽象? 还是基础设施都保留底层平台的特性, skyform 只负责provisioning?

　　A：做了功能抽象， 但保留扩展接口提供特性。我们在API， UI和资源池能力管理上做了设计， 申请了几个专利。

　　核心思路就是将文档上的功能矩阵build进了程序

　　Q8： 小机的自动化你们是自己做还是和厂商合作?

　　A： 曾经自己试着做过并部署但有很多问题，后来决定要聚焦就放弃用其他厂商的了。 早期做了不少东西和尝试， 比如给CloudStack搞类EMR的服务，还有HPC集群服务等等。 现在将精力集中在云管理平台上。 HPC，大数据相关的由其他相对独立团队负责， 比如我们海外的团队现在就在AWS上提供HPC， R cluster等集群服务