刚刚，某跨国企业发生一件运维大事

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

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

初识 FreeWheel

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

除了 FreeWheel 这些外在的“迷之任性”吸引了众多求职者目光之外，还有这家公司内在的IT架构与运维。

FreeWheel 成立 10 年，从刚成立时全年广告播放量累计 100 万次，到单日广告投放接近 10 亿，运维部门用什么来保证产品稳定的应用环境?

作为对新兴技术非常敏感的高科技企业，如何选择最适合自己的技术产品?这家为美国 90% 主流电视媒体和运营商所使用的跨国企业，如何保证欧洲、美国、中国三地协同办公的高效?

FreeWheel 联合创始人美女 CTO Diane Yu 和运维副总裁梁灏舜(Vito Leung)，为我们解答了上述疑问，还原出一个真实的 FreeWheel。同时，希望给那些正面临IT运维困惑的跨国企业、高科技公司以及创新企业提供更多参考。

工程师团队的打造和磨合

这家公司活力四射，既没有历史包袱，也不缺少代码达人，他们对于产品的清晰定位，对新技术理性的判断与尝新，对IT规划的预判与从容，都有非常多值得借鉴的地方。

反其道而行之的研发中心

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

Diane 在美国工作九年，接触了很多中国程序员，她很早就发现，中国的工程师基本功很扎实，工作勤奋能力出众，但往往吃亏在语言上。

另外一个劣势是中国的 IT 人才分布在不同企业不同部门，没有成型的团队，无法做到相互扶持相互帮助，从而难以共同提高。

当时她就在思索，为什么不能招募中国最出色的工程师组成研发团队呢?后来，她遇到 FreeWheel 另外两位创始人，提出了要在北京建立研发中心的想法，并很快被他们接受。

立足中国，国内人才比肩硅谷

FreeWheel 研发中心招募的大多是清华、北大、中科院、哈工大等***高校的高材生。在团队组建之初，除了语言上的劣势比较明显之外，中外思维方式的不同也着实磨合了一段时间，很多微小的细节，Diane 之前都没有想到过这也能造成误会。

例如研发团队发邮件，关于沟通时间的书写往往按照中文习惯“年-月-日”标注，而美国对于时间的标注习惯是“月-日-年”，所以往往中国这边邮件发过去，美国的团队看得雨里雾里搞不清楚会议的时间。

但是很快，经过痛苦的“磨合期”之后，中国的研发团队爆发了惊人的研发实力，一方面团队非常有想法，研发能力很强，可以快速响应美国产品部门的需求;

另外一方面 FreeWheel 研发团队三分之一的人力都有去美国或欧洲“坐班”轮岗的经历，近距离接触产品应用、客户服务，更清楚研发的重点和方向。

当然，另外一个无需多言的好处就是快速的提升英语沟通能力。事实证明，她的决策是对的，现如今她的合作伙伴在各种场合都跟客户或者投资人表示，FreeWheel 之所以能够走到今天，与 Diane 把研发中心设立在北京这个决策分不开。“曾经也有过非常忐忑的阶段，但我很高兴事实证明我是对的。”

运维团队遇到的挑战和解决方案

以最小的代价试错

管理运维团队是运维副总裁 Vito 的重要职责之一。FreeWheel 将 60 余人的运维团队分为好几个小团队，有负责网络的，有负责基础运维的，还有专注产品应用运维的等等不一而足。

整个运维团队主要承担 3 件事：

学习和借鉴外部的新兴技术;

与公司的产品研发保持同步，随时支持;

与不同部门沟通协调，满足他们的需求。

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

数据库的选型之路

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

FreeWheel 的用户数据经历了从最初的上万条、几十 GB 到目前多达 6 亿条、上 TB 的规模，每天更新的数据就高达 1 亿条，要求达到毫秒(ms)量级的跨数据中心数据存取性能，以保证数字广告投放的实时性。为此，FreeWheel 在用户数据库的产品选型、编程接口、软件设计、运营维护等方面做了很多尝试、探索和改进。

在最初的阶段，数据量较小，基于访问性能的考虑，FreeWheel 首先尝试了业内非常流行的开源软件产品 Memcached，实现全内存存取，取得了很好的效果。

随着数据量的不断增加，全内存存储无法满足需求，接下来研发和运维的同事开始评估 Leveldb，并根据 FreeWheel 的业务需求做了一些特殊的定制化，从而实现了数据在磁盘的持久化存储，摆脱了内存容量的限制。

但是随后的问题和挑战也接踵而来，从运维的角度来看，很多问题无法得到很好的解决，例如难以实现高可用、增加节点的成本高、跨数据中心延迟大等等。

这时，FreeWheel 开始更加积极地寻求、尝试更多的软件产品和解决方案，最终选择了 Aerospike 这样一款产品。

它在 API 实现、数据存取性能、命名空间定义、低延迟数据同步、SSD 硬盘访问优化、高可用实现、运维友好性等方面具有突出的优势，使得 FreeWheel 的广告投放系统不仅在响应速度上有了巨大的提升，并且跨数据中心同步平均延迟控制在毫秒级(ms)。

产品小贴士：

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

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

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

网络文件系统的演进

在 FreeWheel，运维团队使用 NFS(Network FileSystem 网络文件系统)解决方案来实现多个系统、服务器之间的数据共享。

NFS 是一种 Linux/Unix 操作系统下被广泛使用的、非常成熟的共享文件系统，可以在计算机之间通过 TCP/IP 协议共享资源。在运维团队的推动下，NFS 的应用在 FreeWheel 经历了几个阶段。

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

随着 FreeWheel 产品的不断升级和业务模式的扩展，数据量和读写的吞吐量也越来越大，单台 NFS 服务器无法满足需求了。

于是新的解决方案是按照业务逻辑拆分现有数据资源，并分散到多台 NFS 服务器上，并且从业务逻辑的角度进行数据资源的隔离。同时这也需要推动产品和开发部门的同事一起调整应用设计来适应这种改进。

在基本解决了容量和性能的问题之后，运维团队进一步对多台 NFS 服务器的高可用和可扩展性进行了改进。

经过研究对比之后，最终选择了 Redhat Cluster Suite 作为解决方案，实现了从 2 节点互备到 4 节点多对多互备，直到目前的 7 节点多对多互备架构，从而在共享资源的读写性能、服务可用级别、系统冗余性、横向扩展能力等多方面对系统提供了强大的支撑能力。

美国、欧洲、中国三地同步协作

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

FreeWheel 在美国、欧洲、中国三地的多处办公室有各自不同的主要职能，有的办事处偏向于与用户沟通，如何更快更好地处理客户需求是重点关注的问题;有的办事处偏向工程，如何更好地服务于工程师团队是优先考虑的问题。因此不同办事处的运维团队面临并且需要解决的问题就不同。

作为一个整体的全球运维团队，如何把各个地区的需求放到一起来决定优先级，并且作为一个整体，共享一个 backlog (工作列表)就成为 FreeWheel 运维工作的一大挑战。

***解决这一难题的方法就是建立“Global Operation Project Management”流程，简单来说，各地的运维团队领导和公司的IT架构师，需要定期交流沟通所有项目，并列出优先级，确保大家保持一致。

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

FreeWheel 运维的未来，拥抱 Devops

随着业务需求的变化，FreeWheel 从只有两个机架服务器的简单系统(ui↔adserver↔db)，发展到了跨多个机房的上千台服务器，并且覆盖 cache、reporting、forecasting、nosql 等多层的复杂系统架构。

在过去的几年里，FreeWheel 采用的是私有云的解决方案，最近 FreeWheel 开始研究混合云的方向，同时使用公有云和私有云。

接下来 FreeWheel 的发展重点将放在 Devops。美国和中国的运维在这个方面有很大的差异。

在美国，绝大部分运维工程师既要有运维(系统+网络)的能力，也要有开发的能力。

而在中国，传统的运维工程师还是更多的只专注于运维。“随着中国技术行业的进步，运维领域也开始要求运维工程师除了运维的思想，也要有更多的开发思维。”

如何支持越来越快速的版本迭代?这不仅是快速的问题，更重要的是能保持生产环境系统的高质量和稳定性。这将牵涉到技术本身以及产品架构完善两方面的研究和投入。

采访后记

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

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

周雪

网络、安全频道主编