本文作者：杭州驻云信息科技有限公司总经理，陈峰
云计算爆发式的增长
文章的开头，我们先来看一组数据：阿里巴巴集团财报显示，截止2016年3月31日，阿里云已拥有超过230万用户；2016年第一季度阿里云营收10.66亿元，同比增长175%。
以上这组数据，可以从侧面反映现在的IT市场，云计算的使用率越来越高，越来越多的用户开始接受并使用云计算了，这是一件好事。不过，笔者作为一名多年的云计算从业者，在为众多的客户提供云计算服务的时候，隐隐地发觉这个市场仍有一些可以提高的地方。
首先，我们先来看一下云计算面向的用户群体包含哪些：
个人站长、个人开发者
中小微企业（非互联网）
互联网企业
中大型传统企业（民营企业、央企、国企等）
各级政府部门
教育部门、科研机构
这些用户对云计算的认识大体分为了以下三种：
拒绝派：谈云色变，觉得云不靠谱不安全；
盲目派：没有充分的理解云计算，但又觉得云可以解决一切问题；
实力派：全面拥抱云计算，并能很好地将云计算和自身的业务系统结合起来；
如何用好云计算
随着各大云计算厂商纷纷将自身优秀的IT技术以云服务的模式开放出来，作为准备上云或者已经上云的用户其实需要从三个层面做好相应的准备，以便更好地拥抱云计算，提升自身IT业务的服务能力：
1.心理期望层面
对各大云计算平台应该抱以一个合理的期望值。对用户而言，云计算确实比传统的IDC大幅度提高了技术能力和服务能力，让用户可以方便快捷地获取优质的IT能力，并且能够实现按需付费、弹性伸缩的IT架构。
可用性
毕竟云计算厂商不是神也不是万能的，不可能让所有的云服务的可用性都能达到100%，我们以阿里云上使用量最大的产品云服务器ECS为例，其可用性的官方数据为99.95%，就是说在一年中大约有0.1825天，即4.38小时的时间，云服务器ECS是可能会出问题而导致服务中断的。进过笔者调研，阿里云、腾讯云、亚马逊AWS、微软Azure的云服务器承诺的可用性均为99.95%。
由于各大云平台已经形成了规模效应，拥有的数据中心遍布各大城市、甚至是全球，每个数据中心的服务器数量基本都以万计，且各数据中心之间的网络连接也是十分复杂。在如此庞大的基础架构下，极有可能出现牵一发而动全身的情况，毕竟天灾人祸不可避免，水灾、火灾、断电、地震、甚至是工程师误操作均有可能发生。那是不是说云计算也不可靠，或者没办法解决这些问题呢？其实不然，云计算在这个层面还是为用户提供一定的保障和技术手段。如何实现，笔者将在后面的章节进行说明。
性能
经常有用户一上来就问，这个云平台能够支撑我应用多少的并发量，这其实是一种非常不专业的问法，好比去医院看病，一进门就问医生我得了什么病。
系统的性能犹如人的身体，它是一种综合性的表现，是多个器官协同工作之后的结果。所以影响性能的因素，除了网络、服务器性能之外，还包括数据结构、数据库设计、SQL写法、缓存的设计、消息队列等中间件的使用，还有很关键的代码结构、框架设计等多个层面。因此，要了解系统上云之后的性能，首先要有一个合理的架构设计，然后还要配合专业的性能测试和评估之后才能得出。另外，一个体系的性能优化，是随着业务发展而逐步展开的系统性工程，是需要多方配合的（不仅仅是一项简单的单项工作而已）。
所以，系统性能这件事，用户千万不能过于盲目地全盘指望云平台，云平台可以在一定的层面帮助你，但是核心的优化工作还是需要用户通过提升技术能力去实现的。
2.应用架构层面
笔者与很多的云计算用户交流，并且提供过服务，发现很多人并没有把云计算的优势发挥出来，归纳一下，大体上有以下问题：
把云服务器当做了云计算的全部
云服务器虽然是云计算里非常重要的服务，但是它仅仅上百种云产品中的一项而已。除非应用真的非常简单，不然千万不能让云服务器承担所有的工作，比如安装数据库、消息队列、缓存等组件，这在性能、扩展性、管理等多个层面都是不合理的。
没有接受按需付费和获取的理念
很多用户的固有思维还没有转变，不管应用如何，都喜欢采用高配的云资源，这其实是一种资源和金钱的浪费，按需获取和弹性伸缩式云计算最核心的功能之一，用户应该充分理解并运用这两个特性。
应用架构没有云化，没有充分地实现分布式和高可用的云上架构
这个问题应该是最核心的问题，上了云平台后，用户最关心的两个问题有：数据可靠性和应用的可用性（不中断性），以阿里云为例，笔者对此有如下建议：
合理地采用一些云平台的组件：如负载均衡SLB、数据库服务RDS、分布式数据库服务DRDS、对象存储OSS、消息队列服务、缓存服务、日志服务等，这比自建系统会更高效、性能更好、扩展性更强、维护更方便、可用性更高，当然前提是需要你的应用系统做一定的改造，主要是跟这些组件之间的API交互方面的代码，不会涉及到核心业务逻辑性的代码，改动量是可控的。
数据的可靠性如何保障：首先假如你用了阿里云的对象存储OSS，它本身就是一备三的冗余，会有一份数据放在同个AZ（可用区）的不同机柜上，还有一份数据放到同一个Region（地域）下另外的AZ（可用区）里，所它的数据可靠性高达10个9，这个数据基本可以代表数据不会丢失。当然假如你还不放心，还可以将数据备份到不同的Region（地域）下。假如你用了云数据盘，你也可以按需设置快照规则，让阿里云自动地帮你来做云数据盘的快照，这些快照都是存储在对象存储OSS里的，所以云盘数据可靠性也高达5个9。
应用的可用性如何保障：近期阿里云华北区2的某个可用区出现问题中断了服务，导致部分用户的系统近1个小时无法访问，但是也有部分用户成功的避免这场事故，他是如何实现的呢？其实很简单，要在云上构建真正的分布式和多可用区的部署。在这里我们暂且不提实现难度较高的一地两中心、两地三中心、双活三活等技术方案，笔者强烈建议用户实现一定程度的高可用架构：负载均衡SLB（支持部署多可用区）+多台云服务器ECS（分布在同个地域下的不同可用区内）+ 数据库服务RDS + 对象存储OSS + 缓存服务OCS（可选），这应该是最容易实现也最便宜的高可用架构。当然，你的应用需要做一定的改造以便能够实现分布式，这里面最核心的问题是能够做到应用的无状态（如session做统一的管理）和静态文件独立存储于OSS（如图片、视频、音频、用户上传的附件等，甚至包含CSS、JS等文件）。这样的架构至少能保证在一个可用区出现故障的时候，应用的服务不会中断。
概念普及：
地域（Region）是指根据地理位置我们把某个地区的基础设施服务集合称为一个区域
可用区（AZ）是指在同一地域内，电力和网络互相独立的物理区域（机房）。
3.团队能力层面
云计算的出现，在某种程度上解放了大量以前只关注底层的机房、硬件和网络运维的技术人员。一家企业最核心其实是他的业务系统，而不是机房里的那一堆机器，这些设备最大的价值是其计算能力、存储能力、网络能力能够支撑企业核心业务的开展。
现在有了云，企业可以将更多的资源和精力花在业务的开拓上了，所以在团队能力上其实也有一个新的要求。
运维人员
应该将更多的精力关注到上层应用，保证应用、数据库等核心业务能够高效、稳定地运作。所以在云时代，对于运维人员又了新的要求，一方面要加强云计算的学习，另外一方面还要学习企业的业务应用，多了解各中间件、数据库、系统框架等层面的知识，在业务系统的持续集成、各类发布、降级限流等流域多下功夫，帮助企业尽可能地实现自动化运维的模式。
程序员
在云时代，程序员要多学习主流云平台的核心产品，尤其是这些产品对外公布的API，在未来的程序里，会集成越来越多的云产品，API就是程序与云平台进行交互的唯一途径
架构师
架构师是一个系统的规划者和建设者，在统筹规划期间，就应该选择合适的成熟的技术方案，随着云平台的发展，云上各个组件的优劣势、适应场景、如何搭配使用等事情都应该是架构师关注的点。
总体来说，云计算产业已经发展到如今的规模，但各厂商仍应加强市场教育和宣导工作，让更多的用户真正的了解云计算，更好地使用云计算，让应用系统在云上的运行做到高枕无忧。作为云计算的从业者，笔者和笔者所在的公司都希望能为这个产业尽自己的一份力。