私有云建设一般分为评估，规划设计，实施，运维这几个阶段，本系列文章将会从这几个方面给出IBM PMC团队在这些方面的一些经验，当然这些经验并不是适合于每个客户，在具体项目中，我们要增加，裁剪这些经验，灵活的运用到项目中去。
本文本系列的第一篇，在私有云建设之初，我们要评估客户现有IT基础环境和应用环境，为以后的规划设计打下基础。
术语
工作负载：英文称为workload，指的是运行在各种中间件里面，或者独立运行的应用
用例：usecase，指的是从最终用户的角度来看，系统应该具有的一些功能，每个形成一定业务意义的功能构成了一个独立的用例
产出物：artifact，指的是工作的成果，包括文档，代码，配置文件等等，产出物是对用户的系统建设有意义的。
项目发起人：sponsor，指的是在项目的过程中，有拍板决定一些重要事情的人，这些人一般都是中高层人员。
架构决定：architecture decision，在项目中的一些重要架构上面的决策，这些决策会记录下来，供后面设计和实施的人参考，这些决策也要和客户一起审阅，因为架构中通常会有一些折中，这些折衷要客户知晓并同意。
云生应用：cloud native application，指的是特地为运行在云中而设计的应用，这些应用一般都有分布式，无状态等特点。
评估的意义
提到评估，大家可能有些疑惑，云不是应该动态扩展吗?我们直接把应用迁移到云上就可以了，我们为什么还需要评估现有的工作负载?要回答这个问题要从公有云和私有云的不同谈起。公有云和私有云的不同点很多，这里只是列举的一些影响到我们决策的点：
私有云中工作负载基本上是明确的，公有云中有各种各种的工作负载 私有云和公有云有一个非常大的不同点：私有云的工作负载(workload)是确定的，也就是说我们在建设私有云的时候，通常都应该知道我们将要建设的云环境中需要多少的计算能力，需要多少内存，需要多大的存储，网络方面有什么要求等。通过了解当前的工作负载，我们可以对将要建成的私有云环境有个基本准确的估计。 而公有云无法了解这些，一般来说是建设一个通用的云。或者就只能提供一些CPU密集型，存储IOPS密集型等比较宽泛的分类。通过评估，我们可以根据工作负载的需要选择合适的资源来承载。
私有云的规模相对公有云较少 私有云一般从规模来说要比公有云的规模小的多，在中国，比较小的公有云的话也至少有1000+的物理服务器，至少两个Region，而私有云的话一般来说在50到200台服务器之间。在这个较少规模的私有云中，我们在服务器，网络，存储上的决策就明显与大规模的公有云有所区别了。规模上的限制导致我们的私有云虽然也有弹性扩展能力，但是这种弹性扩展只能在一定的范围之内。 通过评估，我们可以了解客户弹性扩展的需求，建设一个适合客户需要的私有云平台。
评估的方法
访谈
访谈是一个古老但是很有效的手段，通过访谈我们可以了解到客户的IT的现状。但是要做到一个有效的访谈，还是有很多工作在里面的，首先我们要确定访谈对象：
IT运维人员，他们对现有系统的基础架构最为了解
项目的发起者，通过他们了解这个项目的业务价值和业务目标，业务价值和业务目标是项目的原则性的东西，其他一切架构决定都不能违反这个原则
通过事前发放一些调查表可以提高效率，调查表要精心设计，不要包括废话以免被调查对象产生厌恶情绪。访谈之前，我们一般会向客户发放两个调查表：
工作负载调查表 工作负载调查表主要是确定客户现有的环境中有多少应用，这些应用的类型，是否有IO密集型应用等等
数据中心调查表 数据中心调查表主要检查客户的数据中心的供电，网络的状况，检查是否满足私有云的部署要求
通过客户反馈的调查表，我们基本上对客户的数据中心有一个大概的了解，遇到不清晰的问题记录下来，在访谈的时候和客户确认。
工具收集
在国内外的私有云项目中,容量规划工具还是用得一般。因为各种各样的原因，国内的私有云项目还较少使用，常见的容量规划工具如下：
CiRBA商业软件
VMware Capacity Planner免费，但是需要VMware的授权才能使用
容量规划工具可以帮助企业识别整合的机会，使他们能够缩减过度配置虚拟机，节省了资金。 工具规划工具一般会包括两部分：agent和中央服务器。Agent会部署在客户现有的生产环境中，会在客户的生产环境运行24周，这些agent消耗的资源都比较少，不会影响客户现有的生产环境的使用，它们每隔一段时间就会将收集到数据送到中央的服务器，收集的数据包括：
CPU利用率
内存利用率
磁盘IOPS，磁盘使用大小
每一个进程对资源的利用率，包括Agent自己的
利用这些收集的数据，容量规划工具可以得出一些关于基础架构的推荐的配置。
当然，工具是死的，这些推荐的配置还是需要有经验的架构师来做检查和提高的，不过这些工具确实提供了给架构师科学决策的工具。
评估的内容
业务价值
业务价值是指客户想要通过建设这个私有云，能够直接给业务带来哪些利益，不同的项目想获得的利益不尽相同，下面是一部分例子：
更加敏捷的获得资源
在资源紧缺的时候，能够迅速扩张资源
节省运维成本
。。。。
这是最重要，但是也是最容易被忽略的部分。因为这一部分不涉及到具体的一些工作。但是我们上面提到了，业务价值是指导私有云建设的最高原则，我们在做具体设计的时候，要是要遇到很多的决策决定，这些架构决定一般会提供几个选项，这些选项有的时候是冲突的，如何决定选择哪个?我们第一要看的就是客户的业务价值了。
现有的工作流
现有工作流是现在客户环境中存在的工作流，企业中的业务流程是多种多样的，我们只需识别出和我们私有云建设相关的工作流，一般来说，这些工作流包括：
IT资源申请，审批，通知用户流程
将创建的云资源(包括VM，网络，存储)加入企业现有CMDB的流程
将创建的云资源加入企业现有IT基础架构的过程，例如将VM的名字加入DNS等等
以上这些流程根据企业的大小不一，会有不同的变化，这些变化还体现在集成的方式不一样，一些公司已经建成自己的Service Desk，他们往往倾向于利用原有的Service Desk来调用私有云的API，另外一些公司本来没有Service Desk这个平台，他们就想利用私有云平台来做这个工作。 这个工作项的产出物是用例(UseCase)，后文中会给出用例的示例。
工作负载
工作负载，从不同的角度看有不同的分类，一般可以分成两类：
传统负载
云生(Cloud native)负载
传统负载又可以分成：
web应用负载
数据库应用负载
dev、test负载
虽然负载的类型很多，但是我们如果注意到下面三个方面，那么对负载的评估也就达到要求了：
- 总的负载对计算，存储，网络能力的要求
- 特别高的IOPS的负载
- 负载的高可用性的要求 对于这三点的收集，有利于我们后面做出正确的设计决定。
计算&存储
一般来说，对工作负载的评估完成之后，也就完成了企业对计算和存储能力要求的评估了。当然，存储还是要注意一下备份和灾备的需求。
网络
和计算&存储相比，网络还是稍微有些特殊的，网络评估除了要看工作负载对网络：
吞吐量的要求，也就是带宽的要求，这个带宽包括
外网带宽
内部网络应用之间的带宽
存储网络的带宽(如果是用IP网络的话)
网络的延迟
还需要看：
网络的安全隔离的要求
网络的访问方式
网络的其他要求
系统集成点
认证授权的集成 企业一般有自己的认证授权系统，是否需要和这些认证授权系统集成?
外部应用系统集成，包括：
资产管理系统
ticket系统
Service Desk，例如Service Now等，这个在上文已经说过了
这个评估的产出物是系统上下文图(System Context Diagram)，通过这个图我们可以看到客户的系统和外界集成状况，也可以清楚的知道项目的范围。具体示例可以参见下文。
非功能性需求
安全
防火墙，IDS，漏洞扫描
灾备
为了保证业务连续性，私有云云必须有相应的灾备环境。灾备这个话题在私有云中有点艰难。架构师很难给出很好的选择。桌面云需要灾备的内容包括数据库，用户基础镜像，用户数据和档案，各模块配置信息等。我们需要了解用户现有的灾备环境，包括：
现有灾备的流程：包括灾备涉及哪些人员，灾备的 RTO 和 RPO，灾备发生时应有的操作等
使用的软硬件：确定备份使用的软硬件是什么，以及这些软硬是否有多余的容量来容纳桌面云项目的备份
备份所需的带宽：确定现有备份网络带宽以及桌面云项目所需带宽
备份的项目：评估现在数据库是怎么备份的，文件是怎么备份的，配置项是怎么备份的，把桌面云项目拆成不同的项进行备份
备份频率：备份的频率是实时的 / 每小时 / 每天 / 每星期 / 每月的，把桌面云中不同的备份项归应到不同的备份频率中
评估的产出物
用例
下面是系统用例的一个例子，这个例子说明了云管理员创建一个新的客户需要的信息，创建好了的后续流程，以及与之相关的业务流程。
虚机申请与使用功能权限：客户管理员，用户功能描述 云管理平台提供虚机申请的自服务功能。
SystemContex
下面是一个系统上下文图实例，通过这个示例我们可以看到，云管理平台需要和哪些使用者以及外部系统做集成：
非功能性需求
非功能性的需求包括安全，性能，高可用性等等方面，在评估阶段通常是列出系统要求达到的目标，具体如何达到这个目标，可以在设计阶段体现，下面是一个非功能性需求的例子：
管理平台的高可用性
描述云管理平台要求提供高可用性，整体可用性要求达到99.95%
本文转自d1net（转载）
