今天我们继续讲云管理平台的第三大类模块 administration & delivery。
Self Service
这方面的代表平台云管平台Rightscale的self service功能。 用户登录云平台即可以在服务目录里申请所需要的业务，费用预估业务审核财务审核等都由系统自动通知相关方，在申请批准之后，业务部署也会自动进行。
从上图可以看到，用户可以申请的IT服务有，三层网站服务（IIS），Ubuntu linux服务器，预装php的服务器，Oracle的weblogic，Oracle database 11g…
这一类的service broker通过预定义模板为以下场景提供云资源，技术甚至复杂的应用栈
- 开发，测试
- 培训
- Demo
- 简单的生产环境
- 。。。
用户还可以选择选择适合的参数，比方说虚拟的大小，存储的类型，资源有效时间，
对IT管理部门来讲，self-service在减轻运维压力的同时还起到了对运行中的云环境进行标准化监管。
想要自己开发这个模块的同学应该看出来了，这里的分2大块：
1. Service Management 流程。
这部分从实现来讲和我们上面讲的service desk区别不大。 http://www.cnblogs.com/meowmeow/p/7064660.html
2. 模板和自动化部署
由于企业的网络架构各有不同而云上负载又多种多样，这一块的定制化要求很高。云管平台的开发团队需要保持关注azure本身的迭代release，官方镜像的更新，应用软件的更新。此外，各个企业的安全和合规性要求有不同，这也加大了开发这个模块的难度
Tips： 使用Azure的ARM template 做底层实现
配置管理
云管理员需要知道在云环境里所有正在使用的资源及其生命周期。同时，由于云弹性伸缩的特点，管理员需要知道有多少资源和服务是刚加入/变更/终止，资源间的依赖关系是怎么样的，云资源与应用的关系。我们看一张简单的云管理的CMDB图表
这个配置管理和我们上一篇的配置管理不是一个概念，自动化运维的配置管理更多指使用chef，puppet等工具做软件部署和维护。这里则需要展现在云环境里
- 正在使用的：
虚拟机,虚拟机所用的镜像，虚拟机的静态IP，负载均衡器，公共IP，数据库配置，availability set。。。。
- 过去曾使用的
虚拟机,虚拟机所用的镜像，虚拟机的静态IP，负载均衡器，公共IP，数据库配置，availability set。。。。
由于云资源的动态特性，一般建议通过云平台本身来取得配置管理的输入。云管理平台需要定期从云平台取得数据并存储(again, api, powershell,cli)。至于展现方面，其实excel也够用啦。
Tips：Tag， Tag ， Tag
Tips：必须支持所有可能被使用的资源类型