翟佳：StreamNative 组织构建之路丨声网开发者创业讲堂 • 第 5 期

Posted 2022-11-03 声网

前言

翟佳，StreamNative 联合创始⼈，Apache Pulsar PMC 成员与 Committer。之前任职于 EMC，担任统⼀存储部⻔技术负责⼈。

在声网开发者创业讲堂 • 第 5 期中，翟佳以「StreamNative 组织构建之路」为主题进行了分享。结合 StreamNative 项目的发展历程，分享了开源商业化项目在团队组织构建与技术管理方面的实践。

本文基于演讲内容整理，为方便阅读略有删改。

---

01 StreamNative & Apache Pulsar

1、消息流

我们的公司叫作 StreamNative，项目的名字叫作 Apache Pulsar，它是一个消息和流的基础设施。

消息是计算机领域中很重要的基础组件，它可以把现实世界发生的事情，按照时间的顺序，快速地持久化到计算机中。按照这种理解来看，我们可以很容易地理解消息和流一些广泛的使用场景。比如在智能驾驶、车联网的场景中，每台车要发送的消息可能都需要进行传输和存储；各种机器人、传感器，以及手机或者电脑中的各种 App 跟后端进行交互，可能都需要一个消息总线或者消息中间件做数据传输；大数据分析也需要从系统或者数据产生的源头把数据传输到分析和处理引擎中。这些过程可能都离不开消息总线和消息的服务。

2、消息流使⽤案例

鉴于历史发展和服务的不同场景，消息被分成了图 1 所示的左右两种不同的模型。

■图 1

第一种就是常见的各种 MQ，它负责各种线上的业务，比如我们刚刚提到的各种 App。以视频会议为例，用户可能需要通过点击等动作向后台服务方发送一些指令，这个过程中的传输就能支持线上业务（整个 App ）的运转。

第二种就是 Kafka，它主要用于业务的辅助。比如业务产生了很多数据，那么 Kafka 就会根据这些数据进行分析，并给出指导。以电商平台为例，它可以对平台产生的订单数据以及发货数据（业务）进行计算，以指导更新库存的时间；或者通过其他数据给用户提供 customer 360 的推荐服务。Kafka 主要作为数据传输的管道来使用，但由于 MQ 对数据的服务质量和消息的灵活性可能要求更高，所以 Kafka 对数据的带宽和吞吐要求更高，这就诞生了一些不同的技术。

我们公司的主要方向是提供统一的消息服务，以解决用户由于在这以上两方面使用不同的技术栈，而导致的数据分隔问题。我们所做产品的一个典型特点就是，它是一个融合的解决方案，可以提供左侧业务侧的支持，也可以提供右侧数据分析侧的支持。

在这个基础之上，我们的产品还有一个特性——它从 2012 年诞生以来就是一个存储计算分离原生的架构，比较契合向云原生方向转型的需求，它可以让用户更加弹性地使用底层的基础设施，让业务开发者更加集中在业务方向上，而不是被资源绑定。

02 组织和构建之路

今天我主要针对组织构建的话题进行简单的梳理，希望给大家提供一个参考样本。因为我认为组织建设是一个特别博大的话题，我个人也是一个小学生，只能抛开我的主观判断，从自身的经历来帮助大家理解组织和构建的过程。因为 StreamNative 做的是云原生和基础设施方向，可能相对来说涉及面比较窄，所得经验并一定适合所有人。

1、缘起

首先介绍我们为什么要成立这个公司，图 2 其实是我在办公室的第一天晚上，其他人可能都下班了。这个办公室看似很大，但它是一个共享的办公区域，我们可能就是大家看到右下角有两台显示器，这是我们最开始的两个工位，就是我和另一位联合创始人。

■图 2

其实在创业过程中大家经常会遇到一个问题，就是先研究钉子还是先研究锤子？也就是先研究要解决的问题，还是先研究通过什么来解决问题？Pulsar 是 2012 年在雅虎内部孵化的项目，在 2013 年到 2014 年左右基本完成了开发，其主要工作就是进行了消息和流场景的统一。

当时雅虎业务的压力比较高，在 2016 年雅虎把 Pulsar 开源的时候，其实内部已经在接近 1000 个 App 中做了一个全量的替换，这使 Pulsar 在雅虎内部就已经经历了很丰富的场景的磨砺。

Pulsar 在 2016 年开源到 2018 年底这两年多的时间中，又在一些例如腾讯等互联网大厂中得到了大规模的使用。在海外 Pulsar 也经过了雅虎日本、Twitter、EMC、Salesforce 等大厂的考验。所以我们是先有了钉子，也就是先解决了几个大厂的一些大规模的问题。然后又有了一个还算能用的锤子，也就是经过了很多场景的磨练。

在经历这些考验之后，作为这个项目创始团队的成员，我们认为消息这个场景有很广泛的基础，我们自身又有了一定技术基础和项目的积累，因此就决定成立了现在的公司。这听起来相对比较被动，但从另一种角度来说相对来说也比较理性。

此外，先有了一个成熟的项目，再做社区的运维，也就不怕用户的测试了，所以用户的上线可能也会更加迅速，这就是公司成立的缘起。一般创业特别是基础设施的创业，首先要面临选准方向的问题，只要方向正确，即使是开源，最上层的付费客户也能够支撑公司业务的发展，而且项目的成熟度可能也跟社区及客户的发展有直接的依赖关系。这个项目可能跟现在的很多创业公司也有点不太一样，因为之前它是属于雅虎的，雅虎要先把产权转给 Apache 基金会，我们才有机会做开源，这可能是跟其他开源厂商不一样的地方。

2、社区共建

我们的组织建设跟我们做开源做社区的方向相关，因为社区是我们付费客户的一个很重要的基础，而公司也为社区提供了很多的资源和支持，两者之间是一个相互促进、相互融合的关系。如图 3 所示，我们公司在 2019 年的 8 月 17 号举办了一场全天的 meetup，当时基本上是雅虎日本、腾讯、阿里、EMQ、中国移动以及其他一些可能不在图片上的小伙伴撑起了一天的 meetup。线下的活动是拉近和开发者交流的一个很好的机会，也是促进社区发展的一个很好的手段，但我们认为这个社区活动可能只是一个表面的形式，它本质上还是底层社区的增长。

■图 3

在社区共建方面，图 4 左边是我们看到的我们 GitHub Star 的增长，右边是每月活跃开发者的增长，在共建过程中，它实际上是一个用户和开发者不断引入的过程。左边的图是在最近 PingCAP 的开源项目中，通过对 Github 上抓取的数据进行分析所呈现的 Pulsar 项目情况。右边展示的是 APIseven 提供的工具对每月活跃开发者的统计。

■图 4

我们认为左边图片所示的关注者可能更多的是用户，但评价的最重要的指标还是右侧图片中的数据，也就是月度活跃开发者。

右边图中绿色的线是 Kafka 的每月活跃开发者，蓝色的线是 Pulsar 的每月活跃开发者，线上的点可能是一个并发的数据，就是说当月在当前这个点上有多少开发者在你的社区中贡献了代码，提交了 commit 然后合并到了主分支上。比如我们回到开源之初，在 2016 年年底到 2017 年年初贡献者可能更多的是雅虎日本以及南美的一些电商，他们在使用 Pulsar 的时候，其中的大部分或者关键的功能（比如一致性、吞吐等）能够满足要求，但也存在一些不能满足需求的场景，此时就需要根据自身需求来做一些贡献。

他们与社区共同发展，保证版本不会发生分支，同时也可以利用社区的资源享受社区成长过程中带来的其他功能。所以说，有开发者进入就相当于其对社区的认可度已经比较高，公司已经认可了这条路线并期望跟社区一起发展。

在我们刚刚提到 Meetup 时期，腾讯内部已经开始使用 Pulsar，腾讯的计费平台这样一个关键业务场景中可能投入了两三个开发人员，他们一起加入社区的贡献。StreamNative 中因为有很多 Pulsar 的原创作者（包括社区的主要运维人员和主要的代码构建者），所以他们具有更丰富的经验，可以和腾讯的计费平台专家共同探讨如何更好地实现场景。我们和腾讯的工程师进行了分工合作，这些工作可能就累积到 2018 年和 2019 年的当月贡献中了。

此后，腾讯内部的阅文集团、腾讯音乐、腾讯广告等其他业务也都进入了社区，之前的计费平台开发者也变成了历史的贡献者，现在 Pulsar 整个项目的贡献者大概接近 600 位。

在 2021 年的 6 月，Pulsar 就超过了 Kafka 社区的当月活跃开发者。最近，腾讯会议、腾讯微信的视频号推荐、腾讯内部的洋葱平台等超大流量的场景可能也都在使用 Pulsar，加上滴滴、百度、京东以及在调研的虾皮和美团等用户可能也会累计到当前这个月的开发者中来。

在这个过程中你会发现，公司和社区是一个交互的过程，在这个交互过程中，大家不在一个公司，也不在一个地方，这种方式就是异步模式。此时主要的沟通过程就是，先设置一个 Github issue 以提出需求，进行简单的设计后，就有了讨论的基础，大家可以拉起一个线上会议来做一些更深入的细节设计，之后再做进一步的拆解形成 GitHub 上的一个项目。这个项目下面会有各种拆解的小模块，每个人认领一个模块，再做这个模块的 Pull request 发布，接下来反复进行代码的 merge 和 review。

图 5 是我们社区在超过 1 万个 star 时的一个截图。左边是所有 GitHub 上关注 Pulsar 的 1 万多个用户的一个图像的缩列表，右边是用户的相关信息，比如他属于哪一个公司、他使用的邮箱、来自哪些公司等。

■图 5

图 6 展示了所有关注者在全球的分布，大家可以看到，关注者包括我们接近 600 位的贡献者可能分布在各个大洲，这样我们的沟通就必须是一个异步的远程沟通环境了。

■图 6

这也决定了我们公司文化的一个很重要的方面 —— 强调上下文，也就形成了我们组织的构建模式，就是 work from home 。

3、远程办公

我们认为远程办公模式的本质实际上就是异步沟通，它跟我们公司的基础是直接相关的。首先，我们整个公司都构建在开源基础之上，是一个技术驱动的公司。其次社区跟公司是相辅相成的关系，社区这种开源文化，使我们可以通过邮件、GitHub 方式进行讨论，这跟我们想要的高效的异步沟通模式也是直接契合的，公司的初创成员之前也都具有外企的背景，因此我们从公司最开始的时候也都比较强调这种流程。

最后，云和 SaaS 工具的发展为我们这种远程办公提供了一个很好的基础，需要的任何工具都可以支撑起来，不用花费很大的代价就能搭建起这样一个高效办公的异步沟通环境。

其实这个起步背后还有一些故事，有句话叫摸着石头过河，其实在 2019 年的时候，虽然是一个集中办公区，但我们还是有一个办公室的。到 2020 年，我们的另外一位创始人 —— CEO 郭斯杰刚好在春节那一天在美国有一场演讲，然而因为疫情出现就被困在了美国。这个过程中，我们在美国的一些同事，比如我在 EMC 的同事以及 Twitter 的一些同事也就陆续加入了 StreamNative，这样就真正形成了一个跨全球的公司。

但当时美国那边想要集中办公是不可能的，因为在那个阶段美国疫情更加严重，所以那边的同事就要进行远程办公。而我们在国内的办公室从春节之后也一直无法办公，最终我们就确定了这条路线，把我们的办公室也都退掉了，这也是当时确定这条路线的外因。

当时我们了解到 GitLab 也是通过远程办公的方式来组织他们内部 1000 多名员工的，所以当时参考了 GitLab 的 Handbook，这个 Handbook 的内容特别丰富，忍不住想给大家推荐一下，它对于怎么高效沟通、各个团队之间怎么互相协助等问题给出了一些参考经验，这就使我们更加坚定了走这条路线的决心。

4、工作挑战

远程办公可以使大家不受工作地点和时间的限制，特别是对工程师和高管而言，在这种办公形式下，要想预约会议可以很容易地找到时间空隙，从而把沟通的时间用来做其他事情，并且提高工作效率。

但远程办公也面临一些挑战：第一点是在整个开发者的成长过程中，也有一些需要详细讨论的内容，在这个过程中如何保证沟通的效率；第二点是如何在远程的状态下保证团队的凝聚力；还有一点大家比较关注的就是，远程办公是不是代表全天都在干活，没有自己的生活了呢？

5、解决方法

对于怎么解决这些问题，我们认为本质上它还是一个异步沟通，要保证异步沟通的公开透明和流程优先。

(1) 提升沟通效率

对于提高沟通的效率，我们建议要确保透明文化的建设，并且尽量使用公共的 channel。我们每个月可能都会 check 一下 slack channel 的使用率，查看有多少是 private，有多少是 public，我们希望 public 越高越好，这是我们的一个指标。此外，还要强调文档的写作以及上下文的沟通。如果你认为自己遇到的一次错误可能其他人也会遇到，那么期望你能够把遇到的问题保存下来，使其在后续持续地发挥价值。具体如下：

● 透明⽂化：全员信息公开交流，Slack、Google drive 等⽂档、信息全员公开，确保最⼤限度透明，实现最⼤化信息共享；

● 公共 channel 讨论：保证交流效率提升；

● 强调⽂档：⽂档能够保证沟通减少障碍，提升个⼈⽂档写作能⼒；

● 强调提供全量的上下⽂：邮件、⽂档修改、公共频道讯息、建⽴会议等都需要提供准确的上下⽂，确保成员理解，提升沟通效率。

(2) 目标精准，确保⾼绩效结果产出

从产出上来说，主要可以采用以下方式：

● 结果导向的价值观：异步办公带来的是全员⼯作成果产出全部为结果导向，结果导向能更好的促进⾃律以及⼯作效率提升，避免⽆效“摸⻥”；

● OKR导向：全员OKR，OKR确认上下级⽬标⼀致，公司全员⽬标对⻬，不出现分歧，更明确⼯作内容；

● 员⼯的信任和⾃由：⽬标和背景信息对⻬的前提下，企业对员⼯信任度提升，员⼯⾃由度提升，幸福感提升，⼯作效率提升。

(3) 分布式团建，团队凝聚⼒为第⼀要义

在远程办公可能也会遇到团队凝聚力方面的一些问题，我们对此也做了很多工作，比如每个月可能会有一个 cloud drink，这样即使大家不能见面，也能够从网上进行沟通交互。此外还会定期组织团建，虽然公司无法将所有成员集中在一起，但是每个团队可以自行定期组织。我们还通过 Donut 工具随机匹配大家进行沟通和交流，具体如下：

● Cloud Drink：团队凝聚⼒的产⽣在于好的管理模式，Cloud Drink 的产⽣可以⼤⼤提升团队管理的凝聚⼒，让“⻅⾯”不⽌于当下；

● 分布式团建：除了定期办公，采取“分布式”团建⽅式，团队线下聚餐、定期线下办公、年度活动等，增加团队向⼼⼒；

● Donut ：为线上随机匹配活动，会随机匹配线上⼈员进⾏每周三次的线上互动聊天，让新员⼯相互熟识。

(4) 提升⼯作和⽣活的平衡度，增加员工幸福感

对于工作和生活的平衡这一方面，我们认为这可能与你的目标以及公司的运作形式相关。如果你制定好目标，那么可能远程办公打卡就完全没有必要了。大家能够为统一的目标努力，又能够享受远程办公文化，在此过程中对个人能力也得到了一定的提升，这种通过结果驱动的文化其实对大家的打扰也不会太多。具体如下：

● 让员⼯有“⽣活”：团队管理从员⼯出发，以结果来评价绩效⽽⾮时间，促使员⼯提升⼯作效率，并拥有时间⾃由权限；

● 尊重员⼯：⾸先体现在尊重员⼯的个⼈时间，严格把控⼯作时⻓，员⼯在⾮⼯作时间不受打扰。

6、产品 < == > 组织

最后想强调的是，大家既然要创业，那么就是奔着为客户带来价值这个方向来的，所以公司有了客户之后，产品跟组织之间可能也会有一些相互影响的关系。我们的客户是从 2020 年的年底开始逐渐成长起来的，现在有接近 50 家的付费客户，但主要可能集中在欧美。有了客户之后，公司也正处在从以底层开源为基础转换到以产品为中心的过程中。对于我们的产品，大部分客户特别是海外客户是通过公有云的模式使用，我们通过 SaaS 或者是半托管的模式为用户提供全托管的服务。在这个全托管的服务过程中，我们整个公司跨全球团队的 24 小时持续的覆盖，反而也给用户带来了另一方面的价值。

但是我觉得在以后的发展中，比如随着品牌影响的逐渐提升，最近一些客户的使用规模和安全性要求逐渐提升，可能也会涉及 on-premise，这就可能需要更多的沟通和交互，随着这些客户的出现，今后组织结构可能也会逐渐有所变化。所以大家如果要选择这种模式，可能也要想清楚自己的产品未来的发展是不是适合。

07 问答环节

1、工程师如果要走管理路线，有哪些需要注意的点？

其实我也是从工程师转型走管理路线，我觉得远程办公有一个需要特别注意的地方，就是同理心，要很好地理解团队的诉求，在少量的上下文沟通中把握住大家的需求。这其实是在我看来是比较有挑战，也是平时工作中可能注意比较多的一点。

像我们这种技术创业公司，可能大家相对来说是比较理性的，在整个创业过程中，包括我们往管理层方向转型也都有一些比较好的方法可以推荐，比如《销售加速公式》等图书。其实做管理也是类似，我们都是靠着理性和逻辑带领公司走上一条更理性的路。这跟我们解 Bug 一样，发现问题、解决问题、逐渐迭代、逐渐积累。

2、您刚才说在往技术往管理转型的时候可以通过看书或者自己摸索，那么是否推荐找专业的管理方面的培训机构给团队提升管理能力呢？

我觉得如果你能找到好的教练，那么肯定是有帮助的。但从我的经验来看，在遇到问题后，如果能够尝试自己去理解问题，那么问题其实就已经解决了一半，这也跟我们刚刚提到的解 bug 的过程一样，你能够把问题描述清楚，可能就离你的答案不远了。

阅读更多

1）要了解更多关于声网 SDK和其他使用案例，请看这里的开发者指南：

https://www.agora.io/cn/community/blog?categoryId=119&offset=0

2）了解我们的更多 demo 和案例：

https://www.agora.io/cn/community/demo

3）还可以加入声网 RTE 开发者社区和我们一起讨论交流：

https://www.agora.io/cn/community/