越来越多的传统企业选择将应用迁移上云,然而云计算产品的技术复杂性以及IT架构与传统行业的不同,决定了云运维的难度高于传统运维。我们今天将介绍企业上云过程中面临的业务挑战,并分享一些相关的建设经验。








云的概念





我们大家所说的云,一般指的就是云服务,包含有云计算、云网络以及云存储等,就是把主要的存储和运算等工作交由远端的服务器来处理,而我们的终端只需要通过网络来接收远端服务器的处理结果就可以了。


现在各个业务系统的环境正在变得越来越复杂,需要支持更大的用户并发,更稳定的网络需求,以及更强大的存储及运算能力等等。为了支撑这些不断增长的需求,企业就不得不去购买各类硬件设备和软件,另外还需要组建一个完整的运维团队来支持软硬件的正常运作,提供了包括安装调试、环境搭建、系统测试、版本升级以及信息安全等工作内容。支持这些工作的IT成本会变得非常巨大,而且费用也会随着业务系统的数量及规模的增加而不断提高。所以,各企业中的IT部门往往会被用户抱怨最多的,抱怨他们所使用的系统无法他们的需求。这时候,云计算,就应运而生了。


我们将业务系统部署到云端之后,IT部门就不需要在耗费精力去关注那些让人头痛的硬件设备了,云服务供应商会有专业的团队来提供维护服务。我们可以像使用工具一样去使用这项基于共享硬件的云服务资源,就像我们平时在外面租借共享充电宝一样便捷,而用户只需要按照需求来支付相应的费用。


我们团队曾经接触过一家IDC供应商,他们也在提供云服务,他们的做法就是采购一大批二手服务器在自己的IDC机房中搭建云平台,然后为外部用户提供公有云服务,让自己获得更多的收益。那些使用了他们云服务的企业也不会去关注自己的云服务器是跑在什么机器上,他们只关心业务系统是否能够正常访问,是否可以稳定为其客户提供服务。





云运维与传统运维的区别





不同于传统的运维,云运维有它典型的特征。二者区别对比如下图所示。


总结起来最主要的区别就是以下四点。

  • 操作目标不同

  • 认证体系不同

  • 运维手段不同

  • 系统架构差异



操作目标不同

传统的运维人员,不仅仅要保障公司业务系统的连续性和可用性,还要耗费时间在机房运维、硬件设施维护、网络布线、软硬件设备采购等业务系统所依托的底层IT基础设施,接触的都是硬件相关的工作,需要有较强的动手能力,处理来自各厂家的服务器、防火墙、交换机、存储等硬件设备。


而云运维人员则完全不需要关注这些物理设备,只需要通过网络接入去访问是云上的虚拟资源,例如云主机,云网络,云储存等。

只需要购买了云服务供应商的产品后就可以直接使用了,但是由于现在市面上的云服务商众多,若对云平台的功能不熟悉的话,也会遇到很多坑。


原先申请资源时一般只会说:“我需要4C CPU,8G内存,200G硬盘的服务器”,然后运维人员就会去帮忙创建。但是云服务商则提供了更多不同类型云主机规格的选择,比如GPU计算型、内存型、计算型、突发性能型、等等。不同类型云主机的性能差距会比较大,同时价格差异也会很大。


我们公司的性能团队几年前曾经做过一个测试。他们接到一个客户的需求,要对比市面上比较知名的公有云平台的虚拟机性能。每个平台创建一模一样配置的3台云虚拟机,对比各平台的网络稳定性、带宽实际占用以及存储的吞吐率和IOPS各项指标。在测试的时候大家都觉得应该是国内某公有云服务商的性能应该是比较好的,但是测试结果却并非如此,它的IOPS指标没有另外2家高。这就让人很疑惑,他们还进行了重复测试,结果还是一样。因此通过工单去咨询了售后技术同学,结果回复说他们对IOPS有2W的限制,而另外参与对比的其他厂商则是没有做限制。因此,如果业务系统对IOPS有较高要求的话,那么是不适合选择该厂商的。可见就像是我们常说的一个成语,因地制宜,企业在选择云平台的时候也要贴合实际需求,这时候云运维工程师的价值就提现出来了。当然,这是几年前云计算刚兴起的时候,现在可供用户选择的类型已经很多了。




认证体系不同

传统运维人员,需要获取众多“大厂”的认证,比如系统运维要学 红帽和微软的系统认证DBA要学数据库相关的认证,网络运维要学华为、思科的网络认证等等。


而云计算则是软件定义的概念,通过软件对硬件赋能,并将硬件资源进行池化,提供了可以用于服务的云主机、云空间等产品以及功能。比如云服务器的弹性伸缩可以快捷的创建云主机;虚拟网络则对硬件设备的管理进行了赋能;云数据库则是一种可弹性伸缩的数据库,且提供了容灾、备份、恢复、监控、迁移等解决方案,这些都大大降低了运维人员的操作门槛。

但是云运维工程师的工作又关系到云上的业务系统能否正常稳定地运行,因此云运维工程师所需要掌握的知识体系也相对更为丰富,既需要掌握一部分传统运维的技能,同时又需要涉及到虚拟化、容器、自动化脚本编写等相关知识,这些都对云运维工程师提出了更高的要求。



运维手段不同

与传统运维相比,云运维工程师是将被动运维变为了主动运维,通过各种服务监控、故障告警以及日志分析等工具,对业务系统及网络环境进行全面的监控管理,让自己能尽早的发现故障和隐患,从而快速定位并解决存在的各种问题。


另外还有一点,则是云服务商的选择。因为现在市面上的云服务商众多,若对云平台的功能不熟悉,也会遇到很多坑。


原先申请资源时一般只会说:“我需要4C CPU,8G内存,200G硬盘的服务器”,然后运维人员就会去帮忙创建。但是云服务商则提供了更多的选择,比如GPU计算型、内存型、计算型、突发性能型、等等。不同类型的云主机,性能差距挺大,价格差异也很大。


我们公司的性能团队几年前曾经做过一个测试。他们接到一个客户的需求,要对比市面上比较知名的公有云平台的虚拟机性能。每个平台创建一模一样配置的3台云虚拟机,对比各平台的网络稳定性、带宽实际占用以及存储的吞吐率和IOPS各项指标。在测试存储的时候大家都觉得应该是国内某公有云服务商的性能应该是比较好的,但是测试结果却并非如此,它的IOPS指标没有另外2家高。这就让人很疑惑,他们还进行了重复测试,结果还是一样。因此通过工单去咨询了售后技术同学,结果回复说他们对IOPS有2w的限制,而另外参与对比的其他厂商是没有做限制,如果业务系统对IOPS有较高要求的话,那么是不适合选择该厂商。可见就像是我们常说的一个成语,因地制宜,企业在选择云平台的时候也要贴合实际需求,这时候云运维工程师的价值就提现出来了。



系统架构差异

传统运维多是围绕以IOE架构及其产品体系进行运维,在数据库、中间件、灾备、存储、高可用等环节通常会大量采用商业闭源的软件产品及其解决方案。

这些方案的通常纵向扩展能力极强,讲究两地三中心这种典型的重量级、集中式运维管理方式。


云运维则通常是围绕开源产品及其技术方案。在负载均衡、数据库、中间件、系统容灾、分布式存储、自动化部署等环节通常大量采用开源的软件产品及其技术解决方案。


这种开源解决方案通常纵向扩展能力很弱,横向扩展能力很强。有大量社区、行业成熟案例。方案组合灵活,讲究分布式存储、负载集群、轻量级、模块化、去中心化的运维管理方式。


所以有一个很奇怪的现象,传统运维圈子通常高度认可商业的闭源产品。而云运维圈子通常高度青睐开源产品、以及其技术和理念。


但是,虽然说不需要关注物理硬件的稳定性和可靠性。我们曾经也因为这个碰到过一个大坑。因为在传统的运维模式下,当某个系统部署在服务器上后,基本就不会在变动了。但是云服务的模式下,在多服务器做负载均衡时,某台计算节点宿主机的负载过高的时候,原先跑在上面的云主机,在重启时就会自动迁移动到其他的物理服务器上。那么这时候问题就来了,因为很多商业闭源产品的授权是做了硬件信息绑定的,这个时候,当系统重新启动时,授权就失效了。我们的一家上市企业客户,之前就碰到过一次,当时幸好是在午休时间出现的,没有影响到生产线的运行。后来云服务商评估之后给出的建议就是对该虚拟机打个标签,将其固定在这台宿主机上。


原先传统运维模式下,运维人员经常需要背着包包,带有笔记本电脑以及网线、串口线等设备,前往客户的有相当一部分工作是要在机房内完成的,工作比较繁琐。而且每当碰到节假日或机房搬迁时,都会在心理先默拜一下。


早几年前,在原先公司的一次机房搬迁项目中,六十余台物理服务器从A地搬到了B地,当我们将设备上架开机之后,突然发现生产数据库进不去了。当时我们几个人顿时记得头皮发麻,进系统检查后发现是阵列卡报错了。紧急报修之后,我们在等待厂家工程师上门时都想着是不是该去拜一下服务器了,避免一会出现其他的问题。





云运维面临的挑战









云运维面临着如下的挑战:

  1. 复杂的系统

  2. 混合云环境

  3. 繁多的工具

  4. 人为的错误

  5. 运维文档的缺失

  6. 行为跟踪


1.复杂的系统

我们都知道,当业务系统的规模增长到一定量级的时候,管理和维护服务器以及其他IT基础设备的工作就会变得复杂繁琐起来,尤其是一些系统运行状态的信息搜集以及软件的安装工作,会极大的增加运维人员的工作量


2.混合云环境

随着云计算技术的不断发展,越来越多的企业和公司成为了“ 上云” 大军中的一员。像阿里云、腾讯云等众多的云服务提供商更是提供了许多优质的功能,同时随着私有云技术的流行和普及,很多企业开始倾向于使用混合云或者是多家公有云一起使用的混合环境模式来搭建系统。

那么在这样一个复杂环境下,没有一个统一的运维管理工具或平台,也极大的影响了运维人员的日常工作效率。


3.繁多的工具

在开源技术的发展下,与运维相关的各种工具是越来越多了,从自动部署到信息收集并跟踪操作记录,都有很多不同的方法和工具可以实现。


4.人为的错误

只要是人都会犯错,那么运维服务作为公司运作的基础部分,一旦在运维的过程中出现了重大的人为过错,就可能会影响到整个公司的业务。比如交换机配置出错导致公司断网。所以如何参照标准的操作流程以及自动化的运维手段来减少人为出错的几率,也是运维工作中需要注意的。


5.运维文档的缺失

拥有一个完善的知识库系统,其实可以解决很多问题,对于工作的交接或是新员工的培养都可以极大的提高效率。但现实中却有很多公司并没有在运维文档的储备上花太多心思,甚至很多企业还没有知识库系统,也没有意识到它的重要性。


6.行为跟踪

行为跟踪可以从安全和分析这两个角度来看。

从安全的角度来看,就是要监控运维人员对服务器做的操作,对一些重要数据的操作就显得尤为重要;而从分析的角度上来看,一旦系统出了故障,一些运维操作的记录就可以作为重要的线索来帮忙运维人员去定位以及解决问题。


面对以上种种问题,以及运维发展的趋势,自动化运维平台成了运维人员实现高效运维的一种必备武器。


这里介绍一下我们网新的运维管家平台,它是一个统一运维服务平台,目标是解决我们运维工作的效率和规范问题。

这个平台底层,主要就是针对我们运维的对象,包括硬件的服务器、空调等等设备,还有软件的云平台、应用系统等等。对这些软硬件我们首先是把它们监控起来,实时采集它们的工作状态。


那么具体有哪些资产需要监控管理,是在一个集中的配置管理数据库登记的。在这里登记的资产信息,就可以在往上一层的各种应用服务里面去使用,包括对它们进行各种运维操作,等等。


在运维操作这边我们提供很多自动化的执行模块,包括各种脚本、定时任务等等的功能。另一块平台还支持工单和流程的管理,让运维工作可以更规范。平台不论是自动还是人工运维的操作,最后都会留下详细地日志,我们有配套的审计和分析模块去做监管。


平台也提供跟第三方系统集成接入的接口,主要是考虑跟现有的其他系统能够配合,信息互通,避免重复建设。


在用户层面,还可以使用这些数据对用户账号进行统一认证以及权限的管理。该平台符合运维标准化规范,符合运维安全的框架。





如何做好云安全运维





企业上云后,IT运维工作和投入的成本都会相对减少。随着用户的应用环境从传统自建机房向公有云的转变,运维工作也从内网环境转到公网环境中。这对用户来说是一个非常大的转变,因为在传统环境下所有的IT基础设施和数据都是保管在企业自己的机房里,从心理上来讲,用户会感觉更安全。一旦企业将业务和数据都迁移到公有云环境后,用户会感觉到一定的风险。


但是,实际上公有云机房的IT基础设施,其可用性和安全性是远超一般企业的自建机房环境的,机房的建设和维护有着严格的标准和认证。不过也会出现一些新的安全风险。比如公有云环境下的运维管理工作都必须通过公网,那就可能导致如下问题:





1.运维流量劫持

在公有云环境下,运维工作最大的变化就是有云上的各种运维管理接口都需要通过公网地址来访问,而不是内网环境。很容易被嗅探或劫持攻击,造成运维管理账号和凭证泄露。









2.运维管理接口暴露面增大

在原来的传统运维环境下,黑客需要先入侵到内部局域网环境,然后才能进行暴力破解。但是现在公有云上的资源一般都是将远程端口或其它应用系统的管理端口直接暴露在公网上。那么一旦被黑客破解了账号密码或绕过了认证机制就能直接访问系统了。








3.账号及权限管理问题

一个root账号可能有很多人知道密码,任何获得账号密码的人只要有网络,都可以访问系统,存在账号信息泄露和越权操作的风险。









4.操作记录缺失

公有云平台上的各种云资源,可以通过云管理控制台、远程接入操作系统或应用系统远程工具等多个层面进行访问操作。如果没有相应的操作记录,一旦出现被外部入侵或内部人员越权使用账号的情况将,很难定位问题原因。






这一些风险,可以通过云服务商提供的安全功能来规避,当然一部分功能是需要付费的。比如现在某公有云服务商提供的“企业级安全组”,就是一种全新的安全组类型,相比原有的普通安全组,可以容纳更多的实例、弹性网卡和私网IP地址,同时默认拒绝任何访问请求,需要用户手动逐个添加端口。


但是这些安全功能也会有一些坑的存在。有一次我们为客户做等保服务的时候,客户用的是某服务器的公有云环境。其中几台要过等保的虚拟机需要购买云安全中心服务,但是我们购买时无法选择部分购买,然后通过工单咨询是否可以只购买其中几台虚拟机的云安全中心服务时。结果对方回复:”您好,这个是不可以的,云安全中心产品是根据账号下的服务器数量来决定的,只能继续往上增加,无法降低的,请您了解。”那么最后没办法了,等保必须要做,只能和客户去协商增加费用,对所有云主机购买了一个月的云安全服务。


另外,找到对的方法,也可以做到事半功倍。修漏洞、处理告警、事件溯源是做好云上安全运维最需要关注的三件事:


漏洞漏洞就是指系统层面存在的可能被入侵的渠道,像操作系统漏洞、应用程序漏洞以及弱口令等等,把漏洞修复好了,就能杜绝很大一部分安全隐患。

告警指的是安全产品提供的一些事件通知,及时处理这些告警问题,就可以避免攻击扩大所导致更严重破坏。

溯源指的是找到受到攻击的来源和原因,就可以帮助企业完整地梳理事故原因,避免以后再次因同样的原因而受到攻击。


用好这“三板斧”,可以保证企业的运维人员不需要具备太高深的安全知识,也可以把云安全运维做好。


但是如果漏洞太多不知道该修哪个?或者监控告警不会设置?又或者不知道如何处理事件溯源?当企业受限于这些能力时,可以试试我们浙大网新国际的安全运维检测服务。渗透测试检测有10个大类,总共包括扩73个检测点,安全运维检测有8个大类,总共40个检测点。这些检测,不仅可以帮助用户检测系统漏洞,还可以帮助用户发现应用层的漏洞,有效帮助用户预防病毒和黑客的入侵。