随着云计算技术和产品的逐步成熟，以及对安全性和可控性的要求，不少大中型企业已经建成或者正在建设私有云。私有云对企业带来的效益包括提高 IT 资源利用率、提高 IT 运维效率、降低信息化 TCO、提升 IT 服务质量、加快业务系统的 TTM 等等很多方面。但实际情况是公司花了大把资金建设了一个甚至多个高大上的云平台，但感觉资源发放还是慢，资源利用率依然低，运维起来反而更复杂，完全没有收获当初厂商承诺的效益。
资源的发放不仅仅是通过镜像克隆一台虚拟机实例那么简单，还需要做很多配置拉通工作，例如配置 VLAN、安全策略、路由等等，这些网络配置环节如果没有自动化，就会拖慢整个资源发放的速度，这样的云平台就不算是一个完整功能的云平台。
影响资源发放速度的原因之一是没有做端到端的自动化，大多数情况下是没有引入网络自动化功能，这个可以通过启用 SDN、VXLAN 等技术来实现，本文不做进一步讨论;二是在资源发放流程中引入了人工审批环节，这个问题和资源利用率低、运维效率低等问题都是因为没有用好云平台而导致的，不是云平台本身的问题。本文主要介绍怎么用云平台才能充分发挥私有云的价值。
任何一种新技术或新系统都需要在流程和组织结构上进行适配，十几年前很多企业实施 ERP 系统，效益好的都是哪些在流程和组织上进行适配的企业，这几年热推的 DevOps，也是需要做好流程和组织适配才能充分发挥 DevOps 的价值，私有云也是一样。
1、调整系统建设模式
在传统 IT 环境下，业务系统的建设流程通常如下图所示。
私有云平台建成投产后，业务系统建设的基本流程没有变化，但要求在某些环节的具体操作上作出改变，以适配云计算的特点，进而发挥出云计算的价值。我把需要作出调整的环节加亮显示了。
首先，由于云平台为企业搭建了统一的资源池，并提供了业务系统所需要的 IaaS 和 PaaS 层云服务，所以单个业务系统的建设过程中不再需要独立采购硬件设备和基础软件(操作系统、虚拟化软件、中间件)，而是在私有云初始建设过程中或未来的资源池扩展过程中对硬件设备和基础软件进行集中采购并集中部署。单个业务系统的建设过程中仅需要采购云服务未包含的专有软件，并通过申请云服务的形式来使用底层 IT 基础设施资源和基础软件。
第二，由于云平台通过自动化技术完成了硬件设备和基础软件的部署和配置，业务系统的实施过程中不再需要部署和配置硬件设备和基础软件了，只需要在申请的云服务(虚拟机服务、存储服务、中间间云服务等)基础上部署和配置业务系统的专有软件。所以上述的“硬件安装及配置”和“基础软件部署及配置”两个环节可以省掉。
第三，由于云平台提供了丰富的 PaaS 服务，包括各种云中间件、各种 API、微服务框架等，完全可以基于这些 PaaS 服务进行应用软件的架构设计、开发及测试，并将通过验收测试的应用软件直接部署在云平台上。这样的应用软件从架构设计到部署运行都是在云平台之上进行，也就是我们常说的 Cloud Native 应用，通过这种方式才充分发挥了云平台的价值。
经过改造适配后的业务系统建设流程如下图所示：
2、引入资源配额机制
不同于公有云，在私有云中云服务是不收费的，如果我们不做任何审批或限制，租户都倾向于申请比实际需求多得多的资源，人为导致了资源的浪费。所以我们需要去评审云服务申请的合理性，不合理的云服务申请统统拒绝。但问题又来了，如果在每一次租户申请云服务的过程中都去人为审批该次服务申请的合理性，带来的工作量足以让人崩溃，而且加入人为审批环节也将拖慢资源发放的速度，显然这不是好的方式。
我们改进一下流程，引入资源配额机制。业务系统是云平台上的租户，在业务系统申请云服务之前，让业务系统管理员(也就是租户管理员)先根据业务系统的需求申请一定数量的资源配额，云平台管理员或上级租户管理员对其资源配额申请的业务合理性进行评估，如果没有问题，就在云平台上给该租户分配资源配额。后面租户管理员申请具体的云服务时，云平台检查该租户名下的可用配额是否足够，足够的话就不再进行人工审批，自动进行资源的发放;如果不足够再提醒租户管理员对配额进行扩展。
3、引入资源考核机制
资源配额机制能够避免云服务的滥用，但是否能保证资源利用率的提升呢，答案是未必，因为资源配额评审时是没法评估到资源利用率的。那为了提升云平台整体资源池的利用率，我们还需要以租户为单位引入资源考核机制，按照一定周期(月度、季度、年度)对租户的资源利用率进行晾晒排名，针对资源利用率高的租户在业绩上给予奖励，针对资源利用率低的租户，在业绩上进行惩罚，并在其下一次扩展资源配额时进行更为严格的审批。另外也需要考核配额的使用率，针对申请大量配额而不申请实际资源的租户进行惩罚。
4、调整系统运维模式
业务系统建成投产后即进入系统运维阶段。传统 IT 环境下，业务系统独自占用网络、存储、服务器、操作系统、中间件和数据库等 IT 资源，IT 资源没有在企业范围内进行共享。这就导致在系统运维方面，各业务系统会组建专门的团队负责运维该业务系统独自占用的 IT 基础设施资源、基础软件和应用软件，一个业务系统的运维团队和另一个业务系统的运维团队是相互隔离的，没有实现运维人员、运维技术和运维工具的共享;另外，同一个运维团队中的人往往同时负责运维存储、网络、服务器甚至操作系统等，没有实现运维人员的专业化分工，整体运维效率低下。如下图左半部分所示。
私有云平台建成后，由于网络、存储、服务器、操作系统、中间件和数据库等由云平台统一部署和配置，故这些 IT 资源也由云平台运维团队负责统一运维，而不再是由原来分散在不同业务系统的小型运维团队负责，具体做法可以是将这些小型运维团队合并精简成一个大型的云平台运维团队，实现运维人员、运维技术、运维工具的共享和最大化利用。另外，云平台运维团队负责管理的资源规模比较庞大，由一个人同时负责网络运维和存储运维的做法已经不切实际，所以需要针对每一种资源设立独立的专业小组进行运维，达成运维工作的专业化分工，这种专业分工结合运维自动化技术将大幅提高运维效率。如图右半部分所示。
需要注意的是，由于云平台不负责业务系统应用软件的部署和配置，所以应用软件的运维工作还是会落在业务系统项目组这边，而且由于各个业务系统的应用软件有各自的特点，所以还是采取单独运维的方式。
5、调整 IT 组织结构
业务系统的建设模式和运维模式调整之后，还需要对 IT 组织结构进行调整，这样才能确保这些调整后的模式能够正常运作。
传统 IT 环境下的 IT 组织结构大致如下图所示，IT 部门在 IT 管理领导下主要按照业务系统划分成不同的项目组，每个业务系统项目组负责该系统的建设，同时也负责该系统的 IT 基础设施资源、基础软件和应用软件的运维。除了业务系统项目组之外，针对跨系统的支撑型工作成立专项项目组，例如信息安全、数据中心和整体 IT 规划等。
而私有云建成后，云平台作为一个统一管理 IT 基础设施资源和基础软件的平台，也需要同信息安全和数据中心一样，成立专门的项目组。云平台项目组负责云平台的建设及运维、IT 基础设施资源池的建设和运维、基础软件的部署和运维，因此，业务系统项目组不再需要负责 IT 基础设施资源池和基础软件的运维，仅需负责应用软件的运维。另外，由于云平台项目组统一建设和运维网络资源池，则数据中心项目组也无需再负责网络环境的建设和运维，仅需负责数据中心风火水电的建设及运维。为了更好地发挥出云计算的价值，还需要成立专门的软件研发团队，专门致力于设计、开发及测试 Cloud Native 的应用。
私有云模式下的 IT 组织结构大致如下图所示。
6、总结
私有云为企业搭建统一的 IT 基础设施资源池，并将底层 IT 基础设施资源和基础软件封装为云服务，这些资源池和云服务由企业独占使用，并由该企业完全控制和管理。为了充分发挥私有云的价值，要求业务系统建设时通过申请云服务的方式进行业务系统的搭建，也要求在业务系统运维时将 IT 基础设施资源和基础软件进行统一运维，还要求引入资源配额机制和资源考核机制来提高资源的利用率，同时要求成立专门的云平台项目组负责云平台和资源池的建设及运维。
本文作者：佚名
来源：51CTO
