【足迹】除了打造高可用的应用环境,FreeWheel的运维还干了什么?

简介:

【51CTO.com原创稿件】可能在不少人眼中,FreeWheel这家公司很多做法都出乎意料:公司的业务、销售、市场皆在欧美,技术研发团队却以中国为主;在女性程序员如大熊猫般稀缺的IT职场中,FreeWheel近300人的北京研发中心里,女性员工居然占约四成;企业都宣传自己求贤若渴,可像FreeWheel这样为了能留住心仪的工程师居然能特意为他在纽约新建一个办公室的又有几个?

如果说FreeWheel这些外在的“迷之任性”吸引了众多求职者目光的话,那么吸引记者的,就是这家公司内在的IT架构与运维。这家欧洲、美国、中国三地办公,其广告平台为美国90%主流电视媒体和运营商所使用的跨国企业,如何保证协同的高效?FreeWheel成立十年,从刚成立时全年广告播放量累计100万次,到单日广告投放接近10亿,运维部门用什么来保证产品稳定的应用环境 ?作为对新兴技术非常敏感的高科技企业,如何选择最适合自己的技术产品?

FreeWheel

在前后一个月的时间内,记者分别采访了FreeWheel联合创始人美女CTO Diane Yu和运维副总裁梁灏舜(Vito Leung)。通过二位的分享,解答了上文中一连串的疑问,并还原出一个真实的FreeWheel。在记者看来,这家公司活力四射,既没有历史包袱,也不缺代码达人,他们对于产品的清晰定位,对新技术理性的判断与尝新,对IT规划的预判与从容,都有非常多值得借鉴的地方。记者也希望通过此文,给那些正面临IT运维困惑的跨国企业、高科技公司以及创新企业提供更多参考。

反其道而行之的研发中心

熟悉FreeWheel的人都知道,这家跨国企业的研发中心从成立之初就设在北京。有些人将其原因归结于Diane是土生土长的北京人,有故乡情节。事实上,真相并非全部如此。

FreeWheel

Diane在美国工作九年,接触了很多中国程序员,她很早就发现,中国的工程师基本功很扎实,工作勤奋能力出众,但往往吃亏在语言上。另外一个劣势是中国的IT人才分布在不同企业不同部门,没有成型的团队,无法做到相互扶持相互帮助,从而难以共同提高。当时她就在思索,为什么不能招募中国最出色的工程师组成研发团队呢?后来,她遇到FreeWheel另外两位创始人,提出了要在北京建立研发中心的想法,并很快被接受。

FreeWheel研发中心招募的大多是清华、北大、中科院、哈工大等一流高校的高材生。在团队组建之初,除了语言上的劣势比较明显之外,中外思维方式的不同也着实磨合了一段时间,很多微小的细节Diane之前都没有想到过这也能造成误会,例如研发团队发邮件,关于沟通时间的书写往往按照中文习惯“年-月-日”标注,而美国对于时间的标准习惯是“月-日-年”,所以往往中国这边邮件发过去,美国的团队看得雨里雾里搞不清楚会议的时间。

但是很快,经过痛苦的“磨合期”之后,中国的研发团队爆发了惊人的研发实力,一方面团队非常有想法,研发能力很强,可以快速响应美国产品部门的需求,另外一方面FreeWheel研发团队三分之一的人力都有去美国或欧洲“坐班”轮岗的经历,近距离接触产品应用、客户服务,更清楚研发的重点和方向。当然,另外一个无需多言的好处就是快速的提升英语沟通能力。事实证明,她的决策是对的,现如今她的合作伙伴在各种场合都跟客户或者投资人表示,FreeWheel之所以能够走到今天,与Diane把研发中心设立在北京这个决策分不开。“曾经也有过非常忐忑的阶段,但我很高兴事实证明我是对的。”

以最小的代价试错

FreeWheel将60余人的运维团队分为好几个小团队 ,有负责网络的,有负责基础运维的,还有专注产品应用运维的等等不一而足。管理运维团队是Vito的重要职责之一。整个运维团队主要承担三件事:一是学习和借鉴外部的新兴技术;二是与公司的产品研发保持同步,随时支持;三是与不同部门沟通协调,满足他们的需求。

FreeWheel

这三件事说来容易,真正实践起来并不轻松。就拿第一件事来说,Vito需要解决FreeWheel在IT发展过程中遇到的各种挑战,其中就需要他以最小的试错代价找到最高效的解决方案。他给记者举了两个例子:

数据库的选型之路

在互联网广告行业中,基于用户的信息和历史兴趣行为进行精准广告投放已经成为一个基本需求。为了满足这一需求,需要构建一套支持高并发、低延迟、可扩展、高可用的用户数据库系统,这是很多实时广告系统面临的一个非常大的技术挑战。

FreeWheel的用户数据经历了从最初的上万条、几十GB到目前多达6亿条、上TB的规模,每天更新的数据就高达1亿条,要求达到毫秒(ms)量级的跨数据中心数据存取性能,以保证数字广告投放的实时性。

Vito 告诉51CTO记者,基于以上的业务需求,FreeWheel在用户数据库的产品选型、编程接口、软件设计、运营维护等方面做了很多尝试、探索和改进。

在最初的阶段,数据量较小,基于访问性能的考虑,他们首先尝试了业内非常流行的开源软件产品memcached,实现全内存存取,取得了很好的效果;随着数据量的不断增加,全内存存储无法满足需求,接下来研发和运维的同事开始评估leveldb,并根据FreeWheel的业务需求做了一些特殊的定制化,从而实现了数据在磁盘的持久化存储,摆脱了内存容量的限制。

但是随后的问题和挑战也接踵而来,从运维的角度来看,很多问题无法得到很好的解决,例如难以实现高可用、增加节点的成本高、跨数据中心延迟大等等。这个时候,FreeWheel开始更加积极地寻求、尝试更多的软件产品和解决方案,最终选择了aerospike这样一款产品。它在API实现、数据存取性能、命名空间定义、低延迟数据同步、SSD硬盘访问优化、高可用实现、运维友好性等方面具有突出的优势,使得FreeWheel的广告投放系统不仅在响应速度上有了巨大的提升,并且跨数据中心同步平均延迟控制在毫秒级(ms)。

产品小贴士:

Memcached是一个高性能的分布式内存对象缓存系统,用于动态Web应用以减轻数据库负载。

Leveldb是一个google实现的非常高效的kv数据库,能够支持billion级别的数据量。

Aerospike是一个键-值存储的高性能实时NoSQL(灵活模式)数据库。

网络文件系统的演进

在FreeWheel,运维团队使用NFS(Network File System 网络文件系统)解决方案来实现多个系统、服务器之间的数据共享。NFS是一种Linux/Unix操作系统下被广泛使用的、非常成熟的共享文件系统,可以在计算机之间通过tcp/ip协议共享资源。在运维团队的推动下,NFS的应用在FreeWheel经历了几个阶段。

在最初的业务阶段,他们只使用了一台NFS服务器给前/后端产品提供所有的数据共享服务,数据包括广告创意文件、用户数据报告、广告日志等等。

后来随着FreeWheel产品的不断升级和业务模式的扩展,数据量和读写的吞吐量也越来越大,单台NFS服务器就无法满足需求了,于是新的解决方案是按照业务逻辑拆分现有数据资源,并分散到多台NFS服务器上,并且从业务逻辑的角度进行数据资源的隔离。同时这也需要推动产品和开发部门的同事一起调整应用设计来适应这种改进。

在基本解决了容量和性能的问题之后,运维团队进一步对多台NFS服务器的高可用和可扩展性进行了改进。经过研究对比之后,最终选择了Redhat Cluster Suite作为解决方案,实现了从2节点互备到4节点多对多互备,直到目前的7节点多对多互备架构,从而在共享资源的读写性能、服务可用级别、系统冗余性、横向扩展能力等多方面对系统提供了强大的支撑能力。

协作痛点:如何让美国、欧洲、中国三地同步?

FreeWheel

在采访中,Vito多次表示,作为一个需要全球多地协同工作的的运维团队,最让他头疼的,并不是产品业务方面的问题,而是让不同地区的运维团队如何能有一致的目标以及优先级。

FreeWheel在美国、欧洲、中国三地的多处办公室都有各自不同的主要职能,有的办事处偏向于与用户沟通,有的办事处偏向工程,因此不同办事处的运维团队面临并且需要解决的问题就不同。Vito做了更详细的解释:如果一个团队的日常工作有很多和客户的接触,并且需要满足客户的一些特定的需求,那么如何更好更快地处理客户需求会是这个团队需要重点提高的问题;而如果办事处平常接触的主要是工程师团队,那么如何更好地服务于工程师团队也自然成为需要优先考虑的问题。

所以,作为一个整体的全球运维团队,如何把各个地区的需求放到一起来决定优先级,并且作为一个整体,共享一个backlog(工作列表)就成为FreeWheel运维工作的一大挑战。最后解决这一难题的方法就是“Global Operation Project Management”流程,简单来说,各地的运维团队领导和公司的IT架构师,需要定期交流沟通所有项目,并列出优先级,确保大家保持一致。

在协作方面,随着公司的成长,为了提高客户服务质量的标准,FreeWheel的SLA(服务等级协议)也越来越严格,流程也更加成熟,临时的需求越来越少。Vito表示,取而代之的是SOP (标准流程standard operating procedure)、硬件需求申请流程,使得团队之间的沟通和合作越来越顺畅。

2017,拥抱Devops

随着业务需求的变化,FreeWheel从只有两个机架服务器的简单系统(ui↔adserver↔db),发展到了跨多个机房的上千台服务器,并且覆盖cache、reporting、forecasting、nosql等多层的复杂系统架构。在过去的几年里,FreeWheel采用的是私有云的解决方案,而Vito告诉记者,他最近开始研究混合云的方向,同时使用公有云和私有云。

Vito透露,接下来FreeWheel的发展重点将放在Devops。他认为这个方面在美国和中国的运维有很大的差异。在美国,绝大部分运维工程师既要有运维(系统+网络)的能力,也要有开发的能力。而在中国,传统的运维工程师还是更多的只专注于运维。“随着中国技术行业的进步,运维领域也开始要求运维工程师除了运维的思想,也要有更多的开发思维。”

Vito的另外一个思索方向是如何支持越来越快速的版本迭代。显而易见,这不仅仅是快速的问题,更重要的如何在快速的同时,还能保持生产环境系统的高质量和稳定性。这将牵涉到技术本身以及产品架构完善两方面的研究和投入。

采访后记:

采访完FreeWheel,记者其实有很多专业之外的感受。这家公司的成功背后,其实有很多必然性:严谨的市场调研、理性的技术判断、精准的市场定位、高效的三地协同、还有对产品应用与开发的足够重视……他们很多做法看似与常规做法背道而驰,但细细想来却又在“情理之中”。

在国内企业走出去的大潮流下,记者也建议其他企业可以参考FreeWheel这种理性思考,不选最知名的,只选最适合自己的发展之路。

FreeWheel创建于2007年,总部位于美国硅谷,是一家专门提供互联网视频广告投放、监测、预测、增值等关键解决方案的外商独资公司。创始人是Douglas Knopper、Jon Heller和Diane Yu。

公司发展十年,目前约80%美国传统电视媒体和运营商的数字视频广告业务使用FreeWheel的服务,ComScore排名前10的视频网站大部分是公司的客户或合作伙伴。2017年开始,FreeWheel将重点开拓欧洲市场,在已经占据约50%市场份额的基础上再升级。


作者:周雪

来源:51CTO

相关文章
|
6月前
|
存储 缓存 运维
语雀生产故障不只是运维的锅
现在想来“客户第一”真的是一件很难的事情,说着虽然简单,但是站在用户视角不是一个口号,它需要管理的手段、产品的理念、研发的视线、运维的自动化去协同,我们要暂时放下部门的隔阂、放下旧的用户遗留的定位、放下研发技术手段的局限,真正站在一起去考虑才能形成合力。这个过程,我们有很多阻碍——持续商业化和变现压力、部门的拉扯、人力的变更、繁重的产品设计任务、改不完的bug、做不完的需求、甩不完的锅,还有当下不景气的整体经济现状和已过巅峰、不在风口、进入存量竞争的互联网行业大背景。
77 0
|
运维 监控 安全
高效运维:运维自动化之殇
自动化运维到底需要做什么呢?我们做了这么长时间的运维自动化,还有什么是没做的呢?怎样更优雅的实施运维自动化?运维自动化是万能的么?有哪些潜在问题?高效运维社区发起人,开放运维联盟主席萧田国将为大家分享运维自动化的那些事。
6216 0
|
运维 安全 数据中心
数据中心运维的关键在于“防患于未然”
数据中心运维是老生常谈了,网络上有很多数据中心运维的技术和管理手段,通过学习这些知识的确能够提升对运维的理解。
149 0
|
开发框架 运维 监控
你真得了解”运维开发“吗?
第一个层面,浅层意义,是指“运维工具的开发”。曾经确实如此,例如在HP(Service Manager)和IBM(Tivoli)等国外企业级解决方案为王的时代。那时,实施一套运维工具集,就像在实施SAP的ERP,全过程从咨询到落地实施,不但复杂得很,而且各位运维管理人员、运维工程师就像小学生那样好学(bei dong),毕竟领导说了,上运维系统就要走“固化-僵化-优化”的正路,但理想与现实的鸿沟,还是如此鸿沟
487 0
你真得了解”运维开发“吗?
|
运维 人工智能 Cloud Native
如何构建一个拖垮整个公司的运维系统
人肉运维,不在 DevOps 中转型,就在自动化中消亡。云化时代的运维,需要的是高铁,而不是“跑的更快的马车”。6月25日,数智创新行上海站·智能运维专场,期待您的参与。
1318 0
如何构建一个拖垮整个公司的运维系统
|
机器学习/深度学习 弹性计算 人工智能
运维大杀器来了,未来云上服务器或将实现无人值守
9月26日,阿里巴巴高级技术专家滕圣波在《GOPS全球运维大会》上发表了题为《云上服务器无人值守与自助服务实战》的主题演讲,本文根据滕圣波的演讲整理。
运维大杀器来了,未来云上服务器或将实现无人值守
|
运维 Java 测试技术
在创业公司,不懂运维的程序员如何兼顾公司的运维工作
我是一名创业公司的Java开发工程师,公司没有运维团队,由程序员负责代运维。
5529 0