2.3 云服务对技术团队带来的挑战

云服务对技术团队带来的挑战可以归纳为以下几点,如图2-2所示。

图2-2 云服务对技术团队带来的挑战

(1)服务特性(Service Features)。

通用性和个性化对服务实现的挑战,云服务实现不针对特定的客户应用,在“云”的支撑下可以构造出千变万化的应用,同一个“云”可以同时支撑不同的应用运行。这要求产品设计和开发要很好地处理通用性和个性化的需求之间的平衡。

(2)可靠性(Service Availability)。

云计算服务往往服务众多客户,遍布全球,需要提供24小时不间断服务,需要提供99.99%或更高的服务可用性。

(3)可扩展性(Scalability)。

“云”的规模可以动态伸缩,满足应用和用户规模增长的需要。这要求平台在构建时就满足可随时扩展的要求。

(4)可管理性(Manageability)。

运营商的大规模数据中心的管理,比如Google云中心已经拥有100多万台服务器,亚可逊、IBM、微软、雅虎等的云中心均拥有几十万台服务器。企业私有云一般拥有数百上千台服务器。这些都需要平台的可管理性。

(5)成本效益(Cost Efficiency)。

IaaS、PaaS、SaaS的建设需要大量的投入,这需要云服务提供商在设计和建立阶段,就要以成本效益为重要的考量。

2.3.1 对研发团队的挑战

提到云计算,大家首先会想到Google File System、MapReduce、BigTable、Hadoop、NoSQL等技术,技术会对研发团队带来挑战。但是,这不是研发团队的唯一挑战,如何结合这些技术,实现自己的商务意义上的云服务,应对来自市场对云服务的根本要求,从传统软件开发,转向云服务软件开发,才是研发团队面临的最大挑战。

本质上讲,云服务是将传统企业IT服务互联网化,通过集中规模效应及引入新的服务模式,降低企业IT开销,云服务,无论是SaaS、PaaS还是IaaS,对于研发,都会面对多租户、大容量、高可用、海量数据以及高安全性的挑战。

面对多租户环境,研发团队会面对标准化与个性化功能问题,固有的软件配置方式与多租户的个性化配置有着本质差别,同时,软件功能灵活性要求比传统IT软件要高很多。而多租户也带来了服务站点、个性化用户体验等一系列新的要求,对服务软件开发提出了挑战。

传统企业级IT软件,同时在线使用的是企业内部人员,根据企业的工作时间,中断服务维护是常见的方式,而对于云服务,服务于以百万计的企业,服务中断结果往往是灾难性的,这样对系统可靠性的要求就显著提高了,如何实现高可靠性是对研发和技术运营的一个更大的挑战。

多租户和大用户量是云服务的基本特征,云服务以规模效应替代企业传统IT服务,只有在大规模情形下,才能降低成本,而大用户量意味着高并发及海量数据,如何提升计算能力、存储能力,降低服务成本,稳定一致地支持大容量及海量数据是研发团队面对的另一个挑战。

云服务平台架构如何应对这些挑战,将在技术架构部分详细讲解。

2.3.2 对技术运营团队的挑战

如前面所讲,云服务需要面对多用户及高可靠的需求,这些都对运营团队带来了不小的挑战。

首先,传统IT运营,处理问题是面对一个企业,使用模式相对单一,问题容易定位,而云服务系统,使用企业的模式千差万别,面对不同功能配置、不同流程的问题,处理要复杂很多。

其次是用量问题,系统在不停地增加不同行业、不同地域的用户,对系统、网络、存储的使用是极端不均衡的,如何应对瞬间压力上升时,对网络、存储及计算能力产生的冲击,如何预测并控制这些峰值出现,做好应对准备,都是技术运营的巨大挑战。

除了这些因素外,多用户系统将一部分配置工作交给客户管理,根据用户站点进行配置是这些配置的一个特点,这些原来由运维团队完成的配置由用户来完成,就不可避免地提升了系统维护的难度,如何应对客户配置对系统的冲击,也是运营团队的挑战之一。

最后,高可用性、7×24小时不间断服务、日常维护、升级等,都要求在服务不中断的方式下完成,同时对任何一个故障,都要能够有相应应对,保障服务不中断,这成为运营团队的巨大挑战。

2.3.3 对服务质量控制团队的挑战

服务质量控制(Service Quality Control)团队通常包含两个基础部分,一个是质控分析团队(Quality Analysis),另一个是质控实施团队(Quality Control)。这两个团队在云服务的场景下,都面临极大的挑战。

第一,多用户环境明显有别于一般的应用软件系统。在设计阶段的质量分析和实施阶段的质量检测,其实施思路和手段有极大的不同。举个例子,多用户环境可能要求在IaaS某些组件失效的情况下具备热数据迁移功能,而这个要求在一般应用服务系统中是根本不可能出现的情况。

第二,云服务的基础资源管理和大规模并发处理要求,比一般应用服务体系的压力及稳定性要求高得多。在分析和检测手段上,模拟客户端访问流量和压力测试结果复盘,也要求质控团队有更多、更强的测试设备、测试资源。那么设计、管理、采购、维护及更新这些测试资源,本身也是极其耗费精力的事情。比如,测试一个承载20 000用户的PaaS平台,就要想办法找到能够模拟并发20 000用户流量带宽的网络设备,很明显这样的设备并不存在,那么必须使用多个设备在同一时段进行并发访问,对这个并发访问程序的设计、测试方案的规划就有很高的技术要求。

第三,云服务的产线问题回放(Production Replay)是极难复现的操作。在一般应用服务中,产线问题复现,可能需要几个操作就可以了。但是在多用户及大规模集群环境下,不同的用户,不同的配置环境、操作系统及中间件等,复现场景对质控团队来说是个难以完成的任务。

第四,云服务的回归验证。和第三点一样,即便修复了某些问题,想要在产线环境下完成问题的验证,也充满着各种不确定性。

当然,上述种种问题在实践中也都有解决方案,这些解决方案各自有各自的代价。在云服务的质量工程和服务质量管理章节,将对此部分内容作充分的讲解。