【品高云7年】三、云在开发测试场景的需求与挑战

1.概述

　　曾几何时，开发测试是云平台切入企业市场的第一个应用场景 ，主要的原因是：一方面，这个场景下对高可用的要求不高（说白了就是，那时企业还不相信云平台能挑大梁、跑生产系统）；另一方面，开发测试工作中环境变化比较频繁，云平台的“模板”能力正好可以有效降低运维部门的重复劳动。

　　而实际上，对于管理成熟度高的企业来讲，IT系统在正式上线前需要经过，开发、测试、QA、UAT等多个环节，而这些环节的效率将直接影响业务上线时间和后续的质量，可以说与业务成功密切相关。

　　近年来，随着互联网产品快速迭代模式对传统企业研发的影响，一些新型有效的理念思想被引入，如：敏捷开发、微服务、持续继承／交付／部署等，这些思想的背后理念和采用的新技术，也对开发测试这项工作本身提出了更高的要求。

　　通过对品高云客户的开发测试需求场景的梳理，发现客户的主要需求集中在：快速环境获取、模拟生产环境、运维自动化、更低成本以及对新技术的支撑等5方面。

2. 快速获取环境

2.1.经典场景

• 开发/测试人员（威逼利诱）：系统已经开发完了，请尽快提供测试设备呀，不然业务上线晚了，领导该不高兴了。要不你先把暂时不用的设备给我用下？很快就还给你，到时请你吃饭。

• 运维人员（心若止水）：半天后回复……，这个已经被其他项目组占用了真没空闲资源了，再说项目都是平等的，我优先给你了，别人也不高兴。

• 开发/测试人员：我需要的环境是4CPU的服务器2台、里面是RedhatLinux、Websphere7.0以及Oracle11g。

• 运维人员：硬件资源是现成的，但标准模板中没有11g，如果要我们安装要等2天。

2.2.需求分析

• 企业测试资源有限，但并没有合理分配

• 资源有空闲，但没有被及时回收

• 运维人员真忙，不可能事事快速响应

• 硬件/VM模板固化，不可能软硬件按需搭配

2.3.云平台的应对策略

• 资源统一管理，通过配额（云中的虚拟货币）平衡资源分配，避免恶意占用。

• 项目模式管理，设置资源周期和SLA，定期回收和存档。

• vm硬件和软件模板分离，开发/测试按需选择。

（图：云平台中项目化的配额管理）

（图：常用软件模板管理）

3.模拟生产网络环境

3.1.经典场景

• 运维人员：你这个系统打不开页面，到底有没有认真测试呀？

• 开发/测试人员：在测试环境中明明好好的。

• 运维人员： 跟踪了下错误，发现代码中连接数据库的地方，没有从测试改为生产IP。

• 开发/测试人员：抱歉抱歉……马上改。

3.2.需求分析

• 为了统一管理和网络隔离，生产与测试环境的IP和子网不同

• 由于子网不同，应用不能配置一套搞定

3.3.云平台的应对策略

• 通过实施SDN架构，让网络和网络功能可以“虚拟化”，并按需编排

• 之后通过VPC功能（虚拟出多个相同的网络），让开发测试也用生产环境的IP配置。

（图：用SDN架构构建多的虚拟网络VPC）

4.运维自动化（持续部署）

4.1.经典场景

• 运维人员：你们测试怎么需要8台服务器这么多？

• 开发人员：系统有负载均衡、前端、中间件、数据库等多个模块需要组成集群，短期千万别铲掉，好不容易搭建起来的。

• 测试人员：版本有大bug需要重新部署。

• 开发人员：啊？那要再多等几天……。

• 开发人员：测试服务器蓝屏了，我觉得是你提供设备或网络的问题

• 运维人员：你举出证据来？

• 开发人员：我发现你没有给OS打最新的驱动补丁

• 运维人员：我只是按照你要求给环境，你又没提这个需求

4.2.需求分析

• 多机环境软件多样复杂，难以自动化保证效率

• 人工操作出问题后，权责和问题难以界定

4.3.云平台的应对策略

• 提供云资源编排和应用自动化交付技术，让“大”环境部署自动化

• 显性化交付步骤每个指令环节，让“自动化”更透明。

（图：通过部署蓝图实现自动化运维）

5.更低成本

5.1.经典场景

• 运维人员：领导，我们的业务欣欣向荣，明年预算需要多买一些服务器，尤其是SAN存储要扩容了，vm占用空间太大了！

• 领导：SAN这么贵，开发测试就用单机硬盘吧

• 运维人员：单机磁盘容易坏，测试环境出如果硬盘出问题也很麻烦

• 领导：哦，那就用SAN吧

• 运维人员：现在的SAN都没空间了呀

• 领导：卖卖卖

5.2.需求分析

• SAN存储可靠性高，但昂贵

• 物理服务器本地硬盘多便宜，但可靠性不高

• 虚拟化之后，vm数量增多，占用空间线性变化快，存储成本直线上升

5.3.云平台的应对策略

• 实施计算存储一体化（超融合）架构，充分利用分布式计算+分布式存储的性价比高的优势

• 实施二级存储架构，让SAN作为高性能业务专享、分布式作为普通业务使用，互为备份

(图：在云节点中构建分布式存储，并且支持多类存储并存)

6.新技术的挑战

6.1.经典场景

• 开发人员：现在微服务挺流行，我们要引入这种模式，并且基于docker来做持续集成

• 运维人员：别，我们以前没做过这方面运维，出了问题找谁问？

• 开发人员：docker厂商说需要新环境来部署环境

• 运维人员：又要采购服务器？

6.2.需求分析

• 新技术和新思维，受限运维技能堆栈，无法敏捷响应

• 新技术不一定能够保证自身的安全、可靠性

• 新架构可能需要“新环境” ，原有资产难以保护

6.3.云平台的应对策略

• 云平台自身提供针对docker等新技术的图形化、自动化功能，降低运维人员上手难度。

• 可利用已有的云基础设施，交付新型PaaS技术。这样底层网络、安全和弹性能力可以复用。

• 需提供开放的API和组件架构，可以快速接入新技术

（图：云平台提供ECS容器服务）

7.收益总结

　　随着敏捷开发、微服务等“互联网＋”思维方式和技术的引入，企业的开发测试工作，势必对运维技术在成本（降低）、效率（提升）、可用性（增加）和效果（显性化）等方面提出更高的要求。而开发测试云的引入，也通过快速的环境获取、能够模拟生产网络环境、运维自动化、更低的成本以及从容面对新技术的挑战等方面，更好的辅助企业完成这一生产运行前的最后一道关键工序。

　　当云平台有效支撑企业完成开发测试这一工作后，企业也开始对于云计算所带来的“效率”提升建立了信心，同时由于“持续交付和继续集成”的需要，测试阶段都自动化了，那么下一步，自然是生产运行的自动化支撑。而实际情况下，企业对云计算在这一场景下的需求，不仅仅是“效率”这么简单，而是另有更高、更苛刻的要求。