中国IDC圈8月12日报道，运维在“云江湖”的地位毋庸置疑。可以说，没有云运维就没有云计算。这其中，不仅是传统数据中心的运维管理，还有新技术如Container运维、Hadoop运维、Spark运维、安全运维等。在世纪互联蓝云事业部技术运维总经理汤涛看来：“中国本土市场，混合云和公有云在IT预算上的比例是10：1，即10元投入在混合云，1元在公有云。而快速发展的混合云市场，使得传统运维也在迅速向云运维转型。其中，有挑战，更有机遇。”

云运维要更集中、专业和精准

在混合云的场景中，现有应用迁入云是比较多的一类。企业希望新系统能够更加“高可用”。汤涛就Cluster集群和混合云方案做了一个对比。为了保证高可用，传统方案多是2台或者4台服务器做Cluster集群，一台宕机另一台还可以正常运行。但此方案局限性也很明显：

首先，扩容难度大。传统业务数量的增加最终使服务器容量到达上限，这时必然需要扩容。也就是将2台服务器做的Cluster集群升级到4台或8台，或者更多服务器。但需要所有服务器配置几乎相同，但现在IT环境中，硬件发展日新月异，1年以后的硬件设备配置就有很大不同。这意味着推倒重来，成本要增加很多。 其次，预估难度大。随着“互联网+”深入，更多高并发、高流量的互联网业务场景增多，但搭建Cluster集群时无法预计最终用户的数量，也许设计时是满足1万或10万的用户访问，但面对百万级或千万级用户访问，IT架构肯定完全不同。如果设计成满足10万用户的访问标准，那么在百万甚至千万的量级访问之下，系统肯定出现问题。而这样无法预估的场景在互联网、物联网的发展中，都很容易出现。 第三，TCO高。企业内部的MIS、CRM、ERP等系统，用户量相对稳定，增长也比较平缓。但在如7-9点，17-19点是打卡、OA等预计有相对峰值的访问量。其他时间段都比较平缓。所以如果是按照峰值配置了多台服务器，显然在很多时间内是无法满负载工作的，从资源上看，这是很大的浪费。

汤涛分析道：“如果同样场景采用混合云方案，传统IT架构需要250台服务器，云架构也许只需要100台服务器或者更少就够了。在硬件和电力支出等方面都有很大的节省，应用层以下的运维也全面由云服务提供商所承担，节省人力、物力和财力。”

事实上，关于运维工作范畴的变化，已经被很多云上初创团队所验证：混合云架构下，传统运维负责应用层，云运维负责数据中心的风火水电以及云操作系统等。汤涛表示：“以前在系统出现问题时，技术部门会对服务器、桌面、应用系统等进行排查，但混合云后，传统IT架构变成基于云架构，应用更多在云端。而云计算的本质就是资源共享，每一个操作所影响的都是平台上若干企业用户的应用。所以云运维工程师需要从针对单机、单系统向多服务器、多系统、多平台的管理，更集中、更专业化的方向转变，需要更加小心和谨慎，更具精准度的处理。比如服务器打补丁，原来是下载后，工程师直接安装，但现在需要全方位测试和部署。云平台的运维每一个操作都要遵守严格的规定（运维SOP编制指南）。这对运维工程师的学历、技术水平、专业能力等都有更的高要求。在蓝云运维团队中，多数工程师都需要半年或者更长时间的专业性训练后，才能正式进入云运维工作。”

而随着混合云应用的逐步深入，汤涛对CSDN云计算表示：“现在很多新业务上线速度很快，很多企业都和蓝云运维团队沟通，希望能够实现运维的外包服务。同样我们也看到，ITSM（IT服务管理）也开始走向云化服务。”

从运维角度看全网负载均衡

从运维的角度来看，自动缩放、弹性扩容、负载均衡（SLB技术）都是很重要的技术。尤其是已获得了可信云计算认证的WindowsAzure的全网负载均衡（Traffic Manager）。简单来说，就是在拥有不同的数据中心、多个操作单元的基础上，根据状态的有无、服务器负载、网络带宽和速度等因素，将流量变化智能地导向到不同的服务器集群上。如同一个智能的交通调度中心，这个智能全网负载系统通过循环负载均衡、性能负载均衡、故障转移负载均衡等功能，帮助企业自动监测并自动定向交通流量，为企业选择一条最快最高效的交通线路到达目的地。但云服务往往都是跨地域的，所以要真正实现全网负载均衡并不容易。“从研发走向稳定至少需要2-3年，这也是为何目前仅有由世纪互联运营的Windows Azure能够通过该项认证的原因。”

在汤涛看来，全网负载均衡的技术点包括故障转移、轮询、按性能分配等，这些对用户而言都很重要。事实上，雷击、断网、DDos攻击等宕机，包含私有云、混合云、公有云都会遇到，通过全网负载均衡可以不仅可以指向Azure云服务，还可以指向用户的私有云或者混合云，即使是其他的云服务提供商的云服务也是可以的。比如同样一个用户端域名可以指向分布在10个不同云上的10个站点，任何一个云节点故障发生时，用户都可以指向其他9个。所以只要10个云节点中的1个不宕，服务就能有效提供。

全网负载均衡不同于CDN

CDN是推送到用户的静态或半静态内容，无法实现交互和交易。全网负载均衡可以实现到交易这一级。 全网负载均衡也不同于本地负载均衡（SLB技术）。

汤涛详细解释：从底层技术来看，用户的架构设计时，传统IT架构和云架构不同，前者更多在IaaS层，后者会用到云的虚拟机，而在真正能体现云价值的软件层涉及较少。这也是曾经业内有人将虚拟化和云计算试图划等号的原因。然而仅有虚拟化是不够的，更多是基于PaaS层的云化服务，更多特征或者功能的服务。比如跨中心的高可用，HA（High Availability），从架构上使应用无状态化，是PaaS层的技术。举个例子，10台虚拟机跑一个应用，这10台虚拟机中都存有与用户相关的所有状态，保存在共享缓存中或者数据库中，然后通过数据中心同步实现变化的统一性。当这10台中任何1-2台宕掉时不会影响业务正常运转，也不会影响暂存数据或者已存储数据。

Azure在国内的北京和上海的数据中心中，数据是自动同步的，所以简单地说只需将无状态应用直接放到两个数据中心，再架一个全网负载指向即可。当一个出现问题，自动转到另一个上。当架构重新设计时，全网负载可以指向用户私有云数据中心，或者第三方数据中心（其他公有云数据中心），所采用的就是Azure Traffic Manager技术。相当于在Azure和其他数据中心通过VPN架设起来，在不停机的情况下执行升级和服务维护，实现高速通路。无论是其他办公室还是数据中心，都可以享受全网负载的优势。

谈到具有财务保障的高达99.9%的月度SLA服务等级协议保证，汤涛还分享了一些技术细节：由于Azure提供6份备份，容灾方面的考虑，首先是数据层面，其次是应用层面，出现问题不仅是保护数据，还有让用户可以随时访问到关键应用。比如有些关键应用可能一分钟都不能宕机。这时就不仅需要应用级容灾，还需要异地灾备，跨城（1000公里以上）异地灾备。而Azure的北京和上海的数据中心是通过高速“双”光纤连接的，两条通路是相对独立的，可以避免如地震、“挖掘机”这类问题。如果用Azure的PaaS，只要将虚拟机放入可用级中，就已自动实现跨区管理，比如说同一数据中心不同机架，或者不同数据中心之间，任何一个机器宕掉，系统都能自动识别，并且自动启动一个新的实例起来。再加上自动缩放、实时监测，就能自动适应，并提供高度稳定、可用的解决方案，效果很好。

举个例子，用户配置是4台虚拟机，其中2台出现问题，不需人工干预，系统自动会从不同机架上调配2台新虚拟机实例，这样在上海和北京的数据中心，这样就一直保持4个虚拟机在响应用户需求。这是Azure PaaS实例层面一个很重要的技术，国内其他云服务企业在蓝云的带领下，也在逐步提供这样的服务。

不止如此，为了提升运维服务水平，除了高效响应和分级处理制度外，运维团队还从不同指标中选择最优组合指标来判断问题的出现、状况、处理方案，汤涛表示：“不仅有传感器，还需要有监控传感器的体系，通过这样的二级防护体系来保障运维稳定、安全和高效。在一些实际场景中，在用户的请求下蓝云还会帮助用户分析是解决方案的问题还是平台的Bug，甚至可以从代码角度进行排查。”

随着云计算的深入，传统IT运维过度到云运维，已是趋势。而无论是自动化还是规模化，运维都是朝高精尖方向发展，如果运维工程师能主动学习，更宽广的云运维之路就在前方。