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

简介:

可能在不少人眼中,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

目录
相关文章
|
4月前
|
弹性计算 运维 监控
|
2月前
|
消息中间件 运维 应用服务中间件
容器化运维:构建高可用RabbitMQ集群的Docker Compose指南
容器化运维:构建高可用RabbitMQ集群的Docker Compose指南
147 0
|
4月前
|
弹性计算 运维 监控
带你读《云上自动化运维宝典》——高弹性、高可用、低成本的云上资源管理最佳实践(1)
阿里云弹性计算技术专家高庆瑞主讲《高弹性、高可用、低成本的云上资源管理最佳实践》。
276 0
|
8月前
|
运维 应用服务中间件 网络安全
【运维知识进阶篇】集群架构-Nginx高可用Keepalived(二)
【运维知识进阶篇】集群架构-Nginx高可用Keepalived(二)
116 0
|
8月前
|
缓存 运维 网络协议
【运维知识进阶篇】集群架构-Nginx高可用Keepalived
【运维知识进阶篇】集群架构-Nginx高可用Keepalived
124 0
|
11月前
|
存储 运维 Java
Apache ZooKeeper - 高可用ZK集群模式搭建与运维
Apache ZooKeeper - 高可用ZK集群模式搭建与运维
168 0
|
运维 Kubernetes 容器
《腾讯云多Kubernetes集群高可用运维实践》电子版地址
腾讯云多Kubernetes集群高可用运维实践
108 0
《腾讯云多Kubernetes集群高可用运维实践》电子版地址
|
存储 缓存 运维
Redis高可用集群搭建,配置,运维与应用!
现如今 Redis 变得越来越流行,几乎在很多项目中都要被用到,不知道你在使用 Redis 时,有没有思考过,Redis 到底是如何稳定、高性能地提供服务的?
164 0
|
弹性计算 运维 负载均衡
【运维】使用HAproxy配置后端数据库集群 高可用及负载均衡
后端mariadb数据库galera_cluster集群参考之前文档,https://developer.aliyun.com/article/849929
1896 5
【运维】使用HAproxy配置后端数据库集群 高可用及负载均衡
|
存储 SQL Prometheus
高性能、高可用、免运维-云原生Prometheus方案与实践
SLS(阿里云日志服务)一直致力于发展成一个DevOps的数据中台,为用户提供丰富的机器数据接入、存储、分析、可视化等能力。本文主要介绍SLS如何支持Prometheus的方案,为大家提供云原生的高性能、高可用、免运维的Prometheus引擎。
7717 2