在云端（2）

那我就继续无知者无畏下去了。

对于转变为云计算来说，企业确实需要不少转变。这个转变有些是日常工作上的，有些事理念上的。

那怎么应对这些转变呢？我们建议3个上云阶段：

验证Experimentation

可以用第一个上云的应用来充分了解云计算在开发、部署、测试、监测、运维上特点。用一回真正的尝试掌握云端怎么做能最省钱，最敏捷的方式是什么，怎么最好用到云计算服务商提供的服务。

迁移Migration

这个就指把私有部署的系统成批的上云。这个时候就不光是IT工程师的事儿了，企业各个部门都得参与进来协同一致的理解上云的目标，在上云中和开始使用时提出自己的想法和使用中的建议。这些部门可能包括：IT，运维，法务，HR，业务等等。

演变Transformation

很多时候，迁移和演变是一块儿的，因为在大规模应用上云时，一定有些在私有部署时的架构需要演变，就比如接触PaaS能力优化以前的部署方式。

同时，云计算服务商还会提供比如大数据、AI相关的能力，这时就会将原有应用演变为升级的应用，或者把一些应用整合为一个，还可能直接舍掉以前的应用改用SaaS。

这次和之后的文章，会对这3个阶段特别详细的介绍，这次先说说怎么做好第一步的验证Experimentation

物理上更是心态上的适应

书里举了一个企业选择员工内部使用的捐赠网站作为上云Pilot的栗子，选择的原因是：

首先，这个网站不是业务核心内容；

其次，网站的流量有阶段性的峰值，正好测试负荷能力；

并且这个网站的部署和企业的其他IT系统是独立的。

用这样的应用作为上云的验证，可以很好起到标杆作用：在第一个应用上云后对负载、花费、用户评价等做监测，让公司同事对云计算增加了解度。

在验证阶段，一个树立敏捷开发的理念非常重要

书里是用的Principles of a culture of experimentation。但我觉得“敏捷”可以当做一个简洁的翻译方式吧。

IT部门都面临一个左右为难的问题：既要保持现有系统的稳定无误，还要应对变化日益快速的业务创新需求。创新需求往往IT部门无法全部快速响应。

这时，业务部门经常会自己先弄出一个工具来，比如一些市场活动的网站、小工具等等。其实他们也一样面对一个左右问难的问题：业务部门没有很好的IT能力和管理经验，他们虽然自己先搞出个临时的东西来了，但是对于用户信息、运维往往力不从心。

云上的能力其实很好可以应对这种情况：IT部门可以通过直接引进云端的应用，为业务部门提供MVP型的工具。这样既解决了时效性，又缓解了排期紧张的难题。

这种通过云计算实现的敏捷开发，有这么几个理念：

这些理念帮助IT部门能更好的管理上云的过程，并得到更好的风险把控、资源和效率。

Gofast – 快速了解业务假设可行性，不论成功还是失败

Pushthe boundaries – 云计算不仅是IT工作方式的改变，同时是IT支持方式的转变：帮助业务假设快速验证可行性

Makedata-driven decisions – 云计算服务商会给使用者提供完整的数据追踪，这样在前期可以掌握每个尝试的ROI，以便对可行性有理性的判断

Simplify– 在企业中不是很常用到的应用，可以考虑通过云上简单的功能达成需要的价值，以便节省运维、授权、硬件的消耗

Communicateto succeed – 这是特别重要的理念：要通过持续且清晰的方式向企业决策者展现工作成果，并清晰预估风险的及应对计划/需要的资源。终极目的是让决策者感知到开发过程，而不是只在最后工作都完成了才告知他们。

（未完待续）如果初期的尝试觉得不错了，如何让更多的应用上云呢？这里会涉及更多的部门、还要决定优先次序并且控制风险呢。下次将说说如何有条不紊的做到这些。