编者的话:邱洋,品高云(BingoCloud)的产品总监,国内首个商用云操作系统 BingoCloudOS 云操作系统由他的团队创建,从 2008 年开始,他见证了品高云从零到现在的过程。现在是品高云的第七个年头,他笔下的“品高云七年”是怎样的?

01 概述

随着云平台中支撑的应用越来越多,企业 IT 系统的开发、测试、生产运维等工作的敏捷度提升明显(一般会在 100%以上),但此时在 CEO 的眼里,云平台始终是个花钱的 IT 应用。而一个 IT 应用到底产生了多少收益? 是否值得持续投入 ?在企业中往往都缺乏客观的参考依据。

另一方面,对于集团性公司来说,往往需要通盘考虑 IT 建设的规范化,如果总部或某分支机构建设了一套 IT 系统,如果效果明显就会在集团内推广。而这又可能带来“县官不如现管”、“水土不服”、“虎头蛇尾”等问题。而对于云平台这种与 ERP 系统平级的 战略性 IT 系统 来讲,只有能 持续的产生正向的反馈效果 ,才能给企业信心和更加深入的方向。

要解决上述问题,必须升级企业 IT 管理思路,将 IT 部门的定位 从成本中心向利润运营中心转变 。通过对中国医药、招商局、腾讯、招商银行等集团型云客户;以及广州政务云、地铁轨交云等行业云案例的思路分析。发现客户的云平台建设应该在五化上下功夫,包括:集约化、标准化、显性化、流程化和蓝图化。

02 资源管理集约化

集团性企业往往拥有大量的 IT 资产,这些资产分布在总部机房、分支机构、运营商 IDC 机房等。通过云平台的建设,应该将这些资源统一纳入管理,进入企业的 CMDB(配置管理数据库)中。跟传统建设 CMDB 需要大量探针和手工的工作不同,由于所有资源被云平台统一调度,因此无论在事前(如上架/准备资源)、事中(如运维/监控资源)、事后(如排障/变更资源)所产生的信息都可以自动更新到 CMDB 中。

某银行客户全云资产监控大图—虚拟数据

近年来由于企业 IT 系统外延、互联网化、移动化等趋势明显,公有云也逐渐在大型企业中开始使用,但是始终有些问题对于企业来讲如鲠在喉,他们是:

公有云和私有云的架构往往不同,如何进行统一的管理?

一般公有云中讲服务(如弹性云主机、虚拟私有云等),而私有云中主要讲各种云技术(如虚拟机、SDN 等)。如要将两者有机的调度起来实现互联互通甚至无缝迁移,首先需要让两者拥有平等沟通的机制—开放标准的 API;然后将公/私云技术统一用云服务能力来描述(如弹性服务器、弹性硬盘等);最后通过上层自助服务平台统一进行服务的申请和管理。

在统一平台中交付公有云和私有云资源

如何避免公有云“服务锁定”?

从商业利益的角度考虑,商家永远希望锁定客户,而企业一定不希望这样。 就像外出吃饭一样,我们不可能永远在一个餐厅吃饭,因为会吃腻、服务下降、有更好吃的餐厅等。

而云中存放的往往是客户的业务应用、业务数据,甚至操作习惯,更容易锁定用户。这时就要小心了,一般的云主机、云硬盘等还好迁移,而对于高级的服务,如 RDS、中间件服务、大数据处理、非关系数据库等一旦使用之后很难解套,运维过程变为黑盒且不可控,后面隐藏着巨大的迁移成本和安全风险。

因此,建议企业以自己的技术路线为前提,将公有云作为一个额外的资源池使用,只使用其基本的服务(如云主机、云硬盘等),而其他高级服务(如 RDS、容器服务等)可以考虑利用私有云的自动化部署、云编排等能力按需构建,这样的能力使得云服务的能力始终掌控在企业手里,而在运维层面可以做到足够透明,在异构的公有云之间迁移也将变得更加”轻松“。

企业应用众多哪些业务适合公有云?

从品高云的客户中了解到,大型企业的 IT 应用系统是以百计的,有些甚至上千,而这些应用哪些适合迁移到公有云,哪些又不适合,企业往往很难决策,一旦方向失败很有可能直接影响业务上线后的正常运行。

单纯从应用是否有互联网访问一个维度来判断,是不准确的。例如某制药企业的 ERP 系统,虽然有开放接口给互联网电商访问的功能,但是却不一定适合放在公有云中,因为这个系统同时也被内部财务部门使用。

针对这种情况,品高依据 13 年的大型企业 IT 建设与顾问经验,总结出一套云应用部署规划方法论,并在国药、广铁等客户的实际应用得到了良好的反馈。例如:我们建议企业分别在弹性、安全性、生命周期、面向群体、系统类型等 5 个维度上进行评估打分,并最终得到企业的应用部署分析象限图(哪些适合公有云、哪些必须私有云,哪些甚至可以混合部署)从而辅助客户进行决策。


某客户应用部署建议象限图

企业本地应用如何向公有云迁移?

针对这个问题没有标准答案,但是建议企业选择哪些同时拥有公有云和私有云建设运营经验,以及在实际案例中只少迁移超过 1000 台服务器以上规模的厂商来进行入围考虑。

另一方面,为了更好规避系统迁移失败风险,整个过程需要设计完善的方案。因此建议从规划(包括信息搜集、迁移评估、关联分析、风险分析、迁移策略制定)、详细设计(包括迁移方案制定、计划制定、风险应对计划)、实施执行(包括预迁移、验证测试、正式迁移、正式切换、迁移报告)以及后续管理(包括业务迁移监控、迁移优化)等 4 个阶段制定相应方案。


应用迁移流程阶段示意图

03 服务内容标准化

当企业开始资源“大集中”,并能有条不紊的管理之后,接下来的问题是:资源毕竟有限,众多 IT 需求是否都要满足?此时企业会针对自身的 IT 水平制定标准 服务目录和对应的 SLA。前者说明能做什么,后者则描述做到什么程度。

针对服务水平我很佩服麦当劳,无论任何一家麦当劳,菜单一致,出品时间一致,口感也几乎相同,在这种情况下客户的满意度往往是最高的(因为想要和得到的内容永远一致)。

通常成熟企业的 IT 服务管理,会参考类似 ITIL 的最佳实践,但是由于技术的限制,虽然都有完善的监督和流程机制,但由于执行层大多是“人工”,这就为 IT 服务带来了不可控风险,致使制定的 SLA 难以完成,或者不敢制定太高的 SLA,这势必阻碍企业 IT 的进步发展。要改善这一窘境,应该更多将服务 交给“ 机器人”去执行 ,利用其一丝不苟的特性并配以监督机制,可以使得 SLA 可以更好的得到保障。

云平台提供了众多的自动化功能,可以很好的提升企业的 SLA。但跟传统网管和虚拟化软件由管理员来具体操作不同,云平台应该提供重要组件“ 自助服务平台 ”,将自动化功能以云服务目录形式提供,服务菜单上可能会有如:云主机服务、数据库服务、负载均衡服务、应用部署服务等供需求者选择。需求者在云服务目录中直接提交需求后,少者几秒钟,多者几十分钟,就可以看到服务的结果。

就像麦当劳菜单也会区分清真和普通客户一样,随着企业 IT 运营水平的不断提高,相信会有更多 IT 服务被创新出来,此时就要针对业务部门、分支机构的特点进行分析, 有针对性 的提供服务目录,例如:生产保障部门往往需要集群服务维系可靠性,而研发部门往往单机就可以满足需求;集团总部可能需要网盘/邮件/移动中间件这种规范层面的服务,而子公司则可能需要广告投放、工程项目管理这样的业务服务能力。

相信在这样标准的架构下,每个企业员工在获取 IT 服务的体验,就像去麦当劳一样,从服务菜单中选择想要的 IT 服务,之后片刻就可以获得。


某客户的自助云服务目录---区分开发/测试/生产不同

04 服务能力显性化

传统管理思路下,IT 建设采用计划模式(当年做次年的),也就是说 IT 系统的效果最快也是在第二年才看到效果,更不用说很多所谓效果是拍脑袋和依据以往经验推断出来的,总体来讲就是 IT 究竟创造了多少价值,缺乏有效的衡量标准。

云平台的一个重要能力体现就是“可量化”(参考 NIST 定义云的 5 个特征)。每个用户在云平台中享受的服务、使用的资源都被记录下来,并且按照一定的规则转换为价值,一般常用的规则有代币衡量、资源衡量这两种方法:

  • 代币衡量 :通过将资源的最小单位如每 CPU、每 G 内存、每 T 硬盘、每个软件 licnese、每个软件用户等设置一个代币单价(如金币、豆豆等),然后在配以时长或区间模式进行计算,最终得到某用户消费的代币总额。某种情况下这个代币可以和钱是 1:1 的关系(因为企业采用外包形式一样要付出成本的),这样就直观的表现出 IT 服务所创造的价值,之后再通过跟企业每年的 IT 实际投入做对比,在运作良好的情况下,IT 部门甚至可以体现“利润中心”的价值(产出大于投入)。


在云平台中设定资源价值

  • 资源衡量 :通过将资源(如 cpu,内存,硬盘空间等)以配额形式发放给分支机构,分支机构在年初提资源打包预算申请,公司不在直接给予金钱,而是资源配额。通过合理预测和量化实际使用率(往往初期估算的资源投入都是满负荷的情况,发生的概率很低,就算发生也可以用资源池中其他低负荷资源)就不必为每个分支机构真实购买所有资源 。在年尾时可以将 IT 实际的投入和预算对比, 在运作良好的情况下,可以体现 IT 部门节省大批资金的价值

某客户内部 IT 营收情况图

05 工作过程流程化

跟互联网公有云的模式不同,往往由于企业部门众多,为了更好的规范权责关系,势必对工作的流程有一定的要求,有些复杂的流程可能还要跨部门跨组织进行审批,但这并不是说明审批就和云计算的自助模式水火不容,通过对品高云现有客户实际使用情况的总结,发现企业可以按照云平台用户范围的逐步扩大而应用不同的云服务流程:

  • 不需要流程 :如只在 IT 运维部门内部使用,因为都是管理员在操作。此时如果企业有自己的 ITIL 系统或 OA 系统,可以继续使用。
  • 一站审批 :如在整个 IT 部门使用,各团队被分配配额自助申请资源,由平台管理员依据可用物理资源现状做统一审批(按优先级)。
  • 配额审批 :一般用于事业部制单一企业使用,各需求部门在年初需要时向 IT 部门统一申请项目配额,之后可以按需自助申请云服务。
  • 多级灵活审批 :一般用于集团多分支企业使用,各需求组织一开始跟总部申请统一配额,之后在实际使用时组织内部门向自己上级发起申请,审批通过后就可以使用云服务。
  • ITIL 售后流程 :一般单一企业以上部署了云服务时使用,各级组织用户对 IT 服务的建议、问题以及对故障的申报等工作,应该有标准的支撑流程,可以参考 ITIL 流程。这一流程既可以在云平台中实现,也可以对接企业现有 ITIL 系统实现。

06 实施步骤蓝图化

由于集团型企业的 IT 部门必须运营在严格的规章制度、方针指引和过程管控之下,同时由于企业的业务目标、管理思路和信息化建设成熟度迥异,对于贴身的个性化服务、服务的延续性、信息安全等都有比较高的诉求,因此,企业实施云计算的过程也更加复杂和多样化:【纵向技术层面】需要从应用到平台到最后的基础设施进行综合的考虑和规划。【横向管理层面】还需要考虑组织架构的变化、原有应用程序的迁移、原有应用程序架构的改变等,用以适应云计算环境下的应用开发、部署、运行和运维。因此,如何确定企业内云计算的战略和部署,就变得尤其重要。

企业云运营逻辑架构

对于集团企业来说,由于内部 IT 的复杂性,因此企业内部署云不太可能一步到位,应该是个渐进的过程,通常来说包括数据中心集中整合、服务提供与自动化、应用云化、服务化运营四个阶段。

第一步:数据中心的整合集中、标准化和优化

通过整合、集中和标准化,简化对现有 IT 基础设施的管理,降低成本和管理难度,这是企业 IT 平台设施环境降低复杂性和成本的第一步。

这一过程将企业分散的硬件设备资源进行了物理集中,形成了规模化的数据中心基础设施。尤其对一些大型企业或者集团企业,通过规划、管理以及标准化等措施,把分散在各部门、分子公司的数据中心资源进行资产盘点,根据企业的业务需求和管理需求,重新规划数据中心的区域划分和容灾策略,逐步进行旧有资源的迁移和新购资源的整合集中机制,最终建立基于云计算的数据中心基础架构。

在数据中心新的规划过程中,企业将建立自己的标准和新的 IT 业务服务的规范,用以指引既有的业务扩展或者新业务的上线部署,从而解决 IT 资源分散管理和容灾的相关问题。

第二步:服务提供与自动化

对于企业 IT 部门来说,企业云将其职责转化为运营中心,信息化部门负责服务的规划、设计、优化等,具体的服务交付、运维工作交由云平台来完成。

在服务规划设计的过程中,IT 部门需要重点关注如下方面:

云平台服务规划示例

第三步:应用迁移云化

当企业在建立了统一管理的数据中心并能提供服务后,需要根据应用的重要程度、安全级别、使用对象、生命周期等,规划传统部署在物理机上的业务平台和企业应用向云中迁移的蓝图。

迁移的策略应以业务需求为导向、总体拥有成本降低为目标、安全可靠有效运行为准则,遵循以下原则:

  • 由表及里,先易后难 ,优先迁移关联应用较少,比较容易迁移恢复业务的应用系统。
  • 先普通、后核心 ,从非核心应用入手,逐步向企业平台应用及核心应用演进,迁移过程中,可以先试点整合,再小规模迁移,最后进行全面应用迁移阶段。
  • 选择非业务繁忙时段 实施迁移,如夜晚、节假日等。

基于上述原则,企业现有的应用迁移流程分为如下四个阶段:前期迁移规划、设计迁移过程,实施迁移,后续应用管理。


某集团客户应用迁移要点制定示例

第四步:运营服务化

云计算到最后的转型阶段,就是一切皆服务,动态的基础架构、企业级的平台服务、企业内的各种应用、关键行业的业务流程、软件、信息、商业应用套件和解决方案都可以成为服务。因此,企业 IT 部门,主要精力在于梳理服务目录,并提供可视化、安全性和自动化的平台管理,专注于服务的提供和业务的运营,从而实现企业新的 IT 蓝图:IT 资源能够弹性扩展,IT 服务可以按需、自助获取。在提升业务敏捷性的同时,进一步大幅降低成本。对于部分企业,通过云计算的实施,还可能创造出新的商务模式,为更多的客户提供服务。在这个步骤,IT 部门应考虑如下几个方面:

某集团服务化运营要点制定示例

PS:以上蓝图内容摘选自品高与国药集团联合发布的《企业云计算演进策略与实践报告》白皮书,如有需要可与品高客服联系。

07 总结

当企业真正开始实行集约化、标准化、显性化、流程化和蓝图化的云模式管理时,就说明了企业已经迈入运营式 IT 管理阶段,IT 部门的定位也从成本中心向利润运营中心转变,在这个阶段企业的信息技术能力和能动性将充分发挥,所获得的数据信息也将开始爆炸式增长,视角也将变得逐渐开阔,如果说之前的 IT 都在依靠经验和顾问进行规划的话,那么这个阶段就可以真正依据“大数据”的力量,做出对未来的需求的预测,从而做到运筹帷幄、决胜 N 年之前。


-第四部完-