共计 7139 个字符，预计需要花费 18 分钟才能阅读完成。
前言
翟佳，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/
