写点什么

OaaS 会是理想的运维外包模式吗?

  • 2014-02-17
  • 本文字数:4484 字

    阅读完需:约 15 分钟

2013 年,互联网上出现了一个新的概念:OaaS(Operations as a Service,运维即服务)。该概念的主要推动者、云络科技的 CEO 兼 CTO Steve Mushero 在数次访谈演讲中曾多次介绍过 OaaS 的概念,简单来说就是:

服务器运维的外包。

运维外包本身不是非常新的概念,只不过过去经常服务于企业和事业单位,以人员驻场,定期巡检,短期项目或者故障响应的方式来提供服务。云络科技的重点则放在了“拥有上百万用户的互联网系统”上面,专门处理大型互联网系统在运维中遇到的问题。在云计算业务发展迅速的当下,他们也专注于做针对 AWS、RackSpace、阿里云等云平台用户的运维服务。

可以想象,此类“高大上”的运维服务在推广上会面临巨大的挑战,而执行起来也并不容易。在本次采访中,我们列出了一些此类服务面临的一些可以预见到的问题,希望借此了解云络科技在做这块业务五年以来积累的一些感想和经验。

嘉宾简介:

Steve Mushero,云络科技 CEO 兼 CTO。从业 20 多年,曾任土豆网 CTO、Beyond Access Communications 和 AirReview 首席架构师。他也是《Managing White-Collar Job Migration to Asia》一书的作者。

InfoQ:首先,您觉得云络科技的运维服务,或者说 OaaS 的模式,跟传统的运维外包模式有什么不同呢?

Steve:运维外包本身并不是非常新的概念,但云络的运维外包服务和我们所熟悉的服务有所不同,主要有如下几点:

一、服务的周期不同

常见的运维外包服务多以短期项目的方式来进行。例如搭建一个企业 内部业务系统,搭建一个高可用集群或者应用服务器等,只要安装部署完成,通过验收,再给予一定时期或一定次数的免费质保服务。 而云络的运维外包服务立足于长期持续的服务模式,每年持续签约,问题负责到底,服务没有终点站,质保不设有限期。

二、服务的内容不同

常见的运维外包服务多针对某个专业的系统或软硬件设备,或者某个项目,总之服务的技术范围总是局限于先前所销售的某个产品或系统,与之无关的产品,工具或系统则一概不负责。例如用户自身制定的备份计划任务,对系统的监控数据跟踪和分析等,原有的运维外包服务均不负责。

而云络的运维外包服务服务的对象是用户,而不是只是某个系统。云络的运维服务内容异常的丰富,基本涵盖了一个运维团队日常工作中所需要做的所有事务,包括各种常见系统和日常琐事,甚至像开设一个新用户账户并为之分配 ftp 上传空间配额这样的小事,云络也非常乐意替用户完成。云络所服务的用户时常会感觉到他们多了一个强力的运维部,而不是多了一个只负责特定事务的外包服务商。

三、服务的时机和目标不同

常见的运维外包服务商通常以项目来进行服务,服务期内包含一定的服务次数,在用户出现故障寻求帮助时进行快速响应。因此他们服务的时机是“事后”服务,执行服务的时候,故障已经发生,所以服务的目标是尽快“修复”故障。

而云络的服务是 24x7 不间断服务,而非仅在“事后”响应的服务。由于有独立的监控团队持续跟踪用户的系统和服务器状况,云络常常会提前预知潜在的故障并做出预防措施,即便出现突发故障,云络也会比用户先一步得知故障,尽快开展工作。因此云络的服务是全天候的“事前预防”,“事中处理”,“事后总结”的专业运维服务。 而且由于云络的服务是按年续约,期间并不限制服务次数,所以云络的服务目标是尽全力“避免故障”,而非仅仅是尽全力“解决故障”。

四、服务的对象和技术不同

常见的运维外包服务最主要的服务对象是各种企业,政企,事业单位等,主要涉及 Windows 和企业信息化应用的技术领域,例如 CRM 系统,SAP 系统,OA 系统,邮件系统或者审计系统等。由于这类用户的工作和时间特性,非工作时间服务器的压力会小得多,再者由于用户群较小,数量固定,发展变化慢,服务器的并发压力并不大。同时这类用户常常也允许服务器有更多的容错时间。例如在深夜发生故障或停机调整,对企业的业务影响甚微。

而云络所服务的对象主要为互联网,移动互联网,游戏,视频媒体,电子商务等,他们的系统通常构建在开源的系统之上,对服务器运行稳定的要求相对会更高。不仅用户数无法准确预估,还常常会发生爆炸式增长,这对服务器的性能和安全都是严峻挑战,况且这些企业的业务高峰时间常常发生在非工作时间。在这些企业巨大的刚性需求下,这方面的专业运维人员却相对更少,而云络提供的服务正是在尽力弥补这方面的缺口。

InfoQ:你认为哪一类的任务属于关键型任务,以至于人们需要为这些任务配置高质量的运维服务?

Steve:任何对公司来说属于核心业务的在线系统都属于关键型任务,这天然包括各类电子商务、游戏、移动应用和类似的典型互联网系统。对于此类系统而言,不可靠、缓慢、不安全或者管理成本过高,都会造成公司的麻烦。

InfoQ:一般是哪一类客户会认可你的观点?

Steve:我们发现那些服务器上了一定规模的正规互联网公司对我们的服务有较大的需求。有些小企业的网站比较简单,对运维工作往往不在意,但如果在线系统涉及到他们的核心业务,他们也会非常关心。一般而言,在遭遇过网站宕机事故,或者在服务器上投入了很多成本之后,大家会意识到他们的服务器其实很重要,但很多人不知道如何解决自己的问题,如何增强可靠性,同时不会浪费太多的钱。

InfoQ:运维在“工作成效”方面有一个悖论:如果你做得好,没人会看到;人们仅仅在出现问题的时候才注意到你。这个悖论困扰很多运维团队,同时也使得对外的运维服务很难作为商品售卖。你是如何让你的客户理解运维工作的价值的?

Steve:的确,运维工作存在于互联网的影子里,这些后端的工作仅在出现问题的时候才被人们发现并抱怨。但是现在情况有些好转:当人们看到在双十一这样的大活动或其他大促活动中,系统没有出现任何问题,他们开始意识到其中的价值。我看到的大部分互联网公司都遭遇过系统问题或宕机事故,所以他们十分明白自己需要做哪些改进。另外,被黑客攻击过,或者服务器 /IDC 成本增长惊人的公司也十分明白其中的价值。

InfoQ:理想的 OaaS 应该是通用的可扩展的服务,还是定制化的一对一服务?

Steve:两者都有。首先,针对所有的系统来说,运维的理念、技术、最佳实践和过程都是通用的。但是,每个公司和每个系统都有一些不同,所以以做第三方运维服务来做生意其实是很困难的事情。我们的 OaaS 是标准化的,但是有很多可以定制的组件,同时定制组件的方式是标准的,这样可以同时实现灵活性和可伸缩性。

InfoQ:你如何计算你们团队的成本?客户又如何计算使用你们的成本? 一般来说,你们是运维领域的专家,雇佣你们的费用要高于招聘一个普通运维工程师的价格。

Steve:使用我们的服务其实比客户自己招聘运维要更加便宜,因为我们虽然在各个领域都很专业,但我们的成本可以分摊到所有的客户身上。比如,很少有客户能够负担专职 MySQL DBA,但是使用我们的服务的话,可能每个月只需要用一天,这样的成本效率就很高了。

InfoQ:你们每个客户关系的确立都需要长期的沟通,这意味着获取每一个新客户的成本是相当高的。你们在销售团队方面的投入如何?

Steve:我们的确需要很强的销售团队,不过很多时候,很多合作伙伴提供了很多的帮助。同时,每个新客户的跟进并没有很长的时间,一般有一个月的周期,见面两三次也就有结论了,因为我们这类服务的客户,要么是比较着急需要运维服务的,要么是了解一下情况再等等的。如果对方要等等,我们会继续跟进三个月。这段期间如果他们遇到问题,或者工程师离职了,或者有了新项目,他们往往还会回来找我们的,因为我们在这个领域还没有竞争对手。

InfoQ:你们目前有 90 多人的规模,团队方面是如何划分的?

Steve:有三分之二的人员是为客户做实施的,其中有一半是系统工程师,另外一半是项目管理、7x24 客服、协调、紧急响应等支持性的团队。我们还有研发团队,系统改进团队,培训团队,QA 团队,安全团队,以及流程 / 文档团队。

其他就是销售、市场、管理、财务、人力和行政。

InfoQ:运维服务化在美国市场似乎还挺流行的,为什么在中国市场做起来这么困难?你是如何探索这背后的原因的?

Steve:实际上我们这类服务在美国市场也是比较新的,我们的合作伙伴 RackSpace 算是这个市场上最大的玩家,不过他们的核心服务是基于他们自己的数据中心来提供的。全球范围来看,此类服务都是比较新的,因为运行一个大规模的互联网系统是很困难的事情,尤其对于那些成百上千的服务器都分散在上百家 IDC 或云平台、甚至分散在不同国家、不同行业、运行着不同技术栈的系统来说更是如此。

在中国市场,外包服务本身就比较新,对销售团队来说是很大的挑战,我们需要时间来建设我们的销售团队和合作伙伴渠道,让客户能够更充分的理解我们是做什么的。我们需要创作大量的文章,举办各种会议,做很多市场活动以赢得认可,这方面我们已经做的已经越来越好了。

InfoQ:你之前提到过,对你们业务更加有效的沟通都是跟老板沟通,而不是跟运维工程师沟通。你是如何发现这一点的?

Steve:这实际上要看情况,我们其实也经常会直接跟运维工程师沟通。这往往取决于公司的 CEO/CTO 对运维团队的信任度,因为有些管理层担心运维团队的实力不够,或者运维团队的工作太忙。我们其实很愿意跟公司现有的运维团队一起合作,我们的工作让他们的工作更加轻松可控,而他们也能够从我们的团队那里学习不少东西。

当然,老板们更关心可靠性、规模、成本控制这些宏观层面的东西,所以他们对我们的说法更敏感也更容易接受。其实不少运维团队、IT 经理和 IT 工程师对新事物的接受度还是很高的。

也有工程师会担心我们来了会抢他们的饭碗,不过一起工作之后他们会明白我们的服务不仅对他们的公司有好处,对他本人的职业发展也有好处。

InfoQ:你觉得运维服务这个市场有多大?目前看起来,似乎是一个比较小的市场,大部分都是接私活的,就你们在正规做并发出比较大的声音。你觉得运维服务市场的增长点在哪里?

Steve:中国共有百万量级的互联网服务器,全球有亿级的服务器,所以这是个很大的市场。抛去腾讯、百度、Google、微软这些巨头和那些规模特别小的系统,需要管理的服务器仍然有上百万。AWS 应该很快也有百万台服务器了。

在西方,像 2nd Watch 和 DataPipe 这样的公司已经在企业级管理服务方面做的不错,他们为企业管理 ERP、email、HR、财会等核心业务。虽然他们做的不是互联网业务,不过随着整个世界向互联网迁移的过程,类似的互联网服务也会越来越多。

与此同时,云计算的发展也会扩大这个市场的边界,每个人都在重新思考他们的战略和技术。将业务运转在云上往往要比将业务跑在物理服务器单机上更加复杂、更加困难,所以公司会需要更多的帮助。

InfoQ:你们会一直做运维服务这个业务吗?还是也在尝试一些其他的业务?

Steve:运维服务是我们的核心业务,我们会一直做下去。我们也在尝试为规模较小的云计算用户提供一些云端的自动化服务,也在为一些较大的客户在他们自己的系统中提供自动化服务。我们自己的产品线一直在增加,比如我们的全球备份系统、系统审计、自动化服务器优化服务、云迁移服务等。

无论业务如何发展,我们的宗旨是不变的,就是要让互联网更好、更快、更安全、更可靠、让客户更加成功。我们做的所有事情都会围绕这个目标来设计。

2014-02-17 00:543017

评论

发布
暂无评论
发现更多内容

第十三周学习笔记

Meow

大数据技术与应用

天天向上

极客大学架构师训练营

第 9 周作业

Steven

极客大学架构师训练营

极客时间架构 1 期:第 13 周 数据应用(二) - 命题作业

Null

架构师训练营 Week13 - 课后作业

极客大学架构师训练营

架构师知识体系

天天向上

极客大学架构师训练营

Architecture Phase1 Week13:HomeWork

phylony-lu

极客大学架构师训练营

第十三周总结

fmouse

极客大学架构师训练营

第十三周 作业1

Yangjing

极客大学架构师训练营

第四周作业

胡益

架构师训练营第9周 命题作业

月下独酌

极客大学架构师训练营

第十三周作业

fmouse

极客大学架构师训练营

第十三周作业

Meow

第四周学习总结

胡益

架构师训练营 1 期 - 第 十三周总结(vaik)

行之

极客大学架构师训练营

架构师训练营第 13 周课后练习

叶纪想

极客大学架构师训练营

架构师训练营 总结9

Arthur

极客大学架构师训练营

架构师训练营 1 期 - 第 十三周作业(vaik)

行之

极客大学架构师训练营

架构师训练营 作业9

Arthur

极客大学架构师训练营

week9-作业一

未来已来

数据应用(二)课后练习

ABS

架构入门感悟之九

笑春风

极客时间架构 1 期:第 13 周 数据应用(二) - 学习总结

Null

常用数据分析指标,PageRank算法

garlic

极客大学架构师训练营

第九章作业

Geek_9527

【架构师训练营 1 期】第十三周作业

诺乐

团队沟通中的教练式对话

Alan

团队管理 个人成长 教练 28天写作

架构师训练营 Week13 - 数据应用(2) 总结

极客大学架构师训练营

第九周大作业

小兵

架构师训练营第一期 - 第十三周课后作业

卖猪肉的大叔

极客大学架构师训练营

以满天星辰为灯塔,照亮百度“大航海计划”背后的AI棋局

脑极体

OaaS会是理想的运维外包模式吗?_亚马逊云科技_sai_InfoQ精选文章