前言

翟佳，StreamNative 聯(lián)合創(chuàng)始?，Apache Pulsar PMC 成員與 Committer。之前任職于 EMC，擔任統(tǒng)?存儲部?技術(shù)負責?。

在聲網(wǎng)開發(fā)者創(chuàng)業(yè)講堂 ? 第 5 期中，翟佳以「StreamNative 組織構(gòu)建之路」為主題進行了分享。結(jié)合 StreamNative 項目的發(fā)展歷程，分享了開源商業(yè)化項目在團隊組織構(gòu)建與技術(shù)管理方面的實踐。

本文基于演講內(nèi)容整理，為方便閱讀略有刪改。

---

01 StreamNative & Apache Pulsar

1、消息流

我們的公司叫作 StreamNative，項目的名字叫作 Apache Pulsar，它是一個消息和流的基礎設施。

消息是計算機領(lǐng)域中很重要的基礎組件，它可以把現(xiàn)實世界發(fā)生的事情，按照時間的順序，快速地持久化到計算機中。按照這種理解來看，我們可以很容易地理解消息和流一些廣泛的使用場景。比如在智能駕駛、車聯(lián)網(wǎng)的場景中，每臺車要發(fā)送的消息可能都需要進行傳輸和存儲；各種機器人、傳感器，以及手機或者電腦中的各種 App 跟后端進行交互，可能都需要一個消息總線或者消息中間件做數(shù)據(jù)傳輸；大數(shù)據(jù)分析也需要從系統(tǒng)或者數(shù)據(jù)產(chǎn)生的源頭把數(shù)據(jù)傳輸?shù)椒治龊吞幚硪嬷小＿@些過程可能都離不開消息總線和消息的服務。

2、消息流使?案例

鑒于歷史發(fā)展和服務的不同場景，消息被分成了圖 1 所示的左右兩種不同的模型。

■圖 1

第一種就是常見的各種 MQ，它負責各種線上的業(yè)務，比如我們剛剛提到的各種 App。以視頻會議為例，用戶可能需要通過點擊等動作向后臺服務方發(fā)送一些指令，這個過程中的傳輸就能支持線上業(yè)務（整個 App ）的運轉(zhuǎn)。

第二種就是 Kafka，它主要用于業(yè)務的輔助。比如業(yè)務產(chǎn)生了很多數(shù)據(jù)，那么 Kafka 就會根據(jù)這些數(shù)據(jù)進行分析，并給出指導。以電商平臺為例，它可以對平臺產(chǎn)生的訂單數(shù)據(jù)以及發(fā)貨數(shù)據(jù)（業(yè)務）進行計算，以指導更新庫存的時間；或者通過其他數(shù)據(jù)給用戶提供 customer 360 的推薦服務。Kafka 主要作為數(shù)據(jù)傳輸?shù)墓艿纴硎褂?#xff0c;但由于 MQ 對數(shù)據(jù)的服務質(zhì)量和消息的靈活性可能要求更高，所以 Kafka 對數(shù)據(jù)的帶寬和吞吐要求更高，這就誕生了一些不同的技術(shù)。

我們公司的主要方向是提供統(tǒng)一的消息服務，以解決用戶由于在這以上兩方面使用不同的技術(shù)棧，而導致的數(shù)據(jù)分隔問題。我們所做產(chǎn)品的一個典型特點就是，它是一個融合的解決方案，可以提供左側(cè)業(yè)務側(cè)的支持，也可以提供右側(cè)數(shù)據(jù)分析側(cè)的支持。

在這個基礎之上，我們的產(chǎn)品還有一個特性——它從 2012 年誕生以來就是一個存儲計算分離原生的架構(gòu)，比較契合向云原生方向轉(zhuǎn)型的需求，它可以讓用戶更加彈性地使用底層的基礎設施，讓業(yè)務開發(fā)者更加集中在業(yè)務方向上，而不是被資源綁定。

02 組織和構(gòu)建之路

今天我主要針對組織構(gòu)建的話題進行簡單的梳理，希望給大家提供一個參考樣本。因為我認為組織建設是一個特別博大的話題，我個人也是一個小學生，只能拋開我的主觀判斷，從自身的經(jīng)歷來幫助大家理解組織和構(gòu)建的過程。因為 StreamNative 做的是云原生和基礎設施方向，可能相對來說涉及面比較窄，所得經(jīng)驗并一定適合所有人。

1、緣起

首先介紹我們?yōu)槭裁匆闪⑦@個公司，圖 2 其實是我在辦公室的第一天晚上，其他人可能都下班了。這個辦公室看似很大，但它是一個共享的辦公區(qū)域，我們可能就是大家看到右下角有兩臺顯示器，這是我們最開始的兩個工位，就是我和另一位聯(lián)合創(chuàng)始人。

■圖 2

其實在創(chuàng)業(yè)過程中大家經(jīng)常會遇到一個問題，就是先研究釘子還是先研究錘子？也就是先研究要解決的問題，還是先研究通過什么來解決問題？Pulsar 是 2012 年在雅虎內(nèi)部孵化的項目，在 2013 年到 2014 年左右基本完成了開發(fā)，其主要工作就是進行了消息和流場景的統(tǒng)一。

當時雅虎業(yè)務的壓力比較高，在 2016 年雅虎把 Pulsar 開源的時候，其實內(nèi)部已經(jīng)在接近 1000 個 App 中做了一個全量的替換，這使 Pulsar 在雅虎內(nèi)部就已經(jīng)經(jīng)歷了很豐富的場景的磨礪。

Pulsar 在 2016 年開源到 2018 年底這兩年多的時間中，又在一些例如騰訊等互聯(lián)網(wǎng)大廠中得到了大規(guī)模的使用。在海外 Pulsar 也經(jīng)過了雅虎日本、Twitter、EMC、Salesforce 等大廠的考驗。所以我們是先有了釘子，也就是先解決了幾個大廠的一些大規(guī)模的問題。然后又有了一個還算能用的錘子，也就是經(jīng)過了很多場景的磨練。

在經(jīng)歷這些考驗之后，作為這個項目創(chuàng)始團隊的成員，我們認為消息這個場景有很廣泛的基礎，我們自身又有了一定技術(shù)基礎和項目的積累，因此就決定成立了現(xiàn)在的公司。這聽起來相對比較被動，但從另一種角度來說相對來說也比較理性。

此外，先有了一個成熟的項目，再做社區(qū)的運維，也就不怕用戶的測試了，所以用戶的上線可能也會更加迅速，這就是公司成立的緣起。一般創(chuàng)業(yè)特別是基礎設施的創(chuàng)業(yè)，首先要面臨選準方向的問題，只要方向正確，即使是開源，最上層的付費客戶也能夠支撐公司業(yè)務的發(fā)展，而且項目的成熟度可能也跟社區(qū)及客戶的發(fā)展有直接的依賴關(guān)系。這個項目可能跟現(xiàn)在的很多創(chuàng)業(yè)公司也有點不太一樣，因為之前它是屬于雅虎的，雅虎要先把產(chǎn)權(quán)轉(zhuǎn)給 Apache 基金會，我們才有機會做開源，這可能是跟其他開源廠商不一樣的地方。

2、社區(qū)共建

我們的組織建設跟我們做開源做社區(qū)的方向相關(guān)，因為社區(qū)是我們付費客戶的一個很重要的基礎，而公司也為社區(qū)提供了很多的資源和支持，兩者之間是一個相互促進、相互融合的關(guān)系。如圖 3 所示，我們公司在 2019 年的 8 月 17 號舉辦了一場全天的 meetup，當時基本上是雅虎日本、騰訊、阿里、EMQ、中國移動以及其他一些可能不在圖片上的小伙伴撐起了一天的 meetup。線下的活動是拉近和開發(fā)者交流的一個很好的機會，也是促進社區(qū)發(fā)展的一個很好的手段，但我們認為這個社區(qū)活動可能只是一個表面的形式，它本質(zhì)上還是底層社區(qū)的增長。

■圖 3

在社區(qū)共建方面，圖 4 左邊是我們看到的我們 GitHub Star 的增長，右邊是每月活躍開發(fā)者的增長，在共建過程中，它實際上是一個用戶和開發(fā)者不斷引入的過程。左邊的圖是在最近 PingCAP 的開源項目中，通過對 Github 上抓取的數(shù)據(jù)進行分析所呈現(xiàn)的 Pulsar 項目情況。右邊展示的是 APIseven 提供的工具對每月活躍開發(fā)者的統(tǒng)計。

■圖 4

我們認為左邊圖片所示的關(guān)注者可能更多的是用戶，但評價的最重要的指標還是右側(cè)圖片中的數(shù)據(jù)，也就是月度活躍開發(fā)者。

右邊圖中綠色的線是 Kafka 的每月活躍開發(fā)者，藍色的線是 Pulsar 的每月活躍開發(fā)者，線上的點可能是一個并發(fā)的數(shù)據(jù)，就是說當月在當前這個點上有多少開發(fā)者在你的社區(qū)中貢獻了代碼，提交了 commit 然后合并到了主分支上。比如我們回到開源之初，在 2016 年年底到 2017 年年初貢獻者可能更多的是雅虎日本以及南美的一些電商，他們在使用 Pulsar 的時候，其中的大部分或者關(guān)鍵的功能（比如一致性、吞吐等）能夠滿足要求，但也存在一些不能滿足需求的場景，此時就需要根據(jù)自身需求來做一些貢獻。

他們與社區(qū)共同發(fā)展，保證版本不會發(fā)生分支，同時也可以利用社區(qū)的資源享受社區(qū)成長過程中帶來的其他功能。所以說，有開發(fā)者進入就相當于其對社區(qū)的認可度已經(jīng)比較高，公司已經(jīng)認可了這條路線并期望跟社區(qū)一起發(fā)展。

在我們剛剛提到 Meetup 時期，騰訊內(nèi)部已經(jīng)開始使用 Pulsar，騰訊的計費平臺這樣一個關(guān)鍵業(yè)務場景中可能投入了兩三個開發(fā)人員，他們一起加入社區(qū)的貢獻。StreamNative 中因為有很多 Pulsar 的原創(chuàng)作者（包括社區(qū)的主要運維人員和主要的代碼構(gòu)建者），所以他們具有更豐富的經(jīng)驗，可以和騰訊的計費平臺專家共同探討如何更好地實現(xiàn)場景。我們和騰訊的工程師進行了分工合作，這些工作可能就累積到 2018 年和 2019 年的當月貢獻中了。

此后，騰訊內(nèi)部的閱文集團、騰訊音樂、騰訊廣告等其他業(yè)務也都進入了社區(qū)，之前的計費平臺開發(fā)者也變成了歷史的貢獻者，現(xiàn)在 Pulsar 整個項目的貢獻者大概接近 600 位。

在 2021 年的 6 月，Pulsar 就超過了 Kafka 社區(qū)的當月活躍開發(fā)者。最近，騰訊會議、騰訊微信的視頻號推薦、騰訊內(nèi)部的洋蔥平臺等超大流量的場景可能也都在使用 Pulsar，加上滴滴、百度、京東以及在調(diào)研的蝦皮和美團等用戶可能也會累計到當前這個月的開發(fā)者中來。

在這個過程中你會發(fā)現(xiàn)，公司和社區(qū)是一個交互的過程，在這個交互過程中，大家不在一個公司，也不在一個地方，這種方式就是異步模式。此時主要的溝通過程就是，先設置一個 Github issue 以提出需求，進行簡單的設計后，就有了討論的基礎，大家可以拉起一個線上會議來做一些更深入的細節(jié)設計，之后再做進一步的拆解形成 GitHub 上的一個項目。這個項目下面會有各種拆解的小模塊，每個人認領(lǐng)一個模塊，再做這個模塊的 Pull request 發(fā)布，接下來反復進行代碼的 merge 和 review。

圖 5 是我們社區(qū)在超過 1 萬個 star 時的一個截圖。左邊是所有 GitHub 上關(guān)注 Pulsar 的 1 萬多個用戶的一個圖像的縮列表，右邊是用戶的相關(guān)信息，比如他屬于哪一個公司、他使用的郵箱、來自哪些公司等。

■圖 5

圖 6 展示了所有關(guān)注者在全球的分布，大家可以看到，關(guān)注者包括我們接近 600 位的貢獻者可能分布在各個大洲，這樣我們的溝通就必須是一個異步的遠程溝通環(huán)境了。

■圖 6

這也決定了我們公司文化的一個很重要的方面 —— 強調(diào)上下文，也就形成了我們組織的構(gòu)建模式，就是 work from home 。

3、遠程辦公

我們認為遠程辦公模式的本質(zhì)實際上就是異步溝通，它跟我們公司的基礎是直接相關(guān)的。首先，我們整個公司都構(gòu)建在開源基礎之上，是一個技術(shù)驅(qū)動的公司。其次社區(qū)跟公司是相輔相成的關(guān)系，社區(qū)這種開源文化，使我們可以通過郵件、GitHub 方式進行討論，這跟我們想要的高效的異步溝通模式也是直接契合的，公司的初創(chuàng)成員之前也都具有外企的背景，因此我們從公司最開始的時候也都比較強調(diào)這種流程。

最后，云和 SaaS 工具的發(fā)展為我們這種遠程辦公提供了一個很好的基礎，需要的任何工具都可以支撐起來，不用花費很大的代價就能搭建起這樣一個高效辦公的異步溝通環(huán)境。

其實這個起步背后還有一些故事，有句話叫摸著石頭過河，其實在 2019 年的時候，雖然是一個集中辦公區(qū)，但我們還是有一個辦公室的。到 2020 年，我們的另外一位創(chuàng)始人 —— CEO 郭斯杰剛好在春節(jié)那一天在美國有一場演講，然而因為疫情出現(xiàn)就被困在了美國。這個過程中，我們在美國的一些同事，比如我在 EMC 的同事以及 Twitter 的一些同事也就陸續(xù)加入了 StreamNative，這樣就真正形成了一個跨全球的公司。

但當時美國那邊想要集中辦公是不可能的，因為在那個階段美國疫情更加嚴重，所以那邊的同事就要進行遠程辦公。而我們在國內(nèi)的辦公室從春節(jié)之后也一直無法辦公，最終我們就確定了這條路線，把我們的辦公室也都退掉了，這也是當時確定這條路線的外因。

當時我們了解到 GitLab 也是通過遠程辦公的方式來組織他們內(nèi)部 1000 多名員工的，所以當時參考了 GitLab 的 Handbook，這個 Handbook 的內(nèi)容特別豐富，忍不住想給大家推薦一下，它對于怎么高效溝通、各個團隊之間怎么互相協(xié)助等問題給出了一些參考經(jīng)驗，這就使我們更加堅定了走這條路線的決心。

4、工作挑戰(zhàn)

遠程辦公可以使大家不受工作地點和時間的限制，特別是對工程師和高管而言，在這種辦公形式下，要想預約會議可以很容易地找到時間空隙，從而把溝通的時間用來做其他事情，并且提高工作效率。

但遠程辦公也面臨一些挑戰(zhàn)：第一點是在整個開發(fā)者的成長過程中，也有一些需要詳細討論的內(nèi)容，在這個過程中如何保證溝通的效率；第二點是如何在遠程的狀態(tài)下保證團隊的凝聚力；還有一點大家比較關(guān)注的就是，遠程辦公是不是代表全天都在干活，沒有自己的生活了呢？

5、解決方法

對于怎么解決這些問題，我們認為本質(zhì)上它還是一個異步溝通，要保證異步溝通的公開透明和流程優(yōu)先。

(1) 提升溝通效率

對于提高溝通的效率，我們建議要確保透明文化的建設，并且盡量使用公共的 channel。我們每個月可能都會 check 一下 slack channel 的使用率，查看有多少是 private，有多少是 public，我們希望 public 越高越好，這是我們的一個指標。此外，還要強調(diào)文檔的寫作以及上下文的溝通。如果你認為自己遇到的一次錯誤可能其他人也會遇到，那么期望你能夠把遇到的問題保存下來，使其在后續(xù)持續(xù)地發(fā)揮價值。具體如下：

● 透明?化：全員信息公開交流，Slack、Google drive 等?檔、信息全員公開，確保最?限度透明，實現(xiàn)最?化信息共享；

● 公共 channel 討論：保證交流效率提升；

● 強調(diào)?檔：?檔能夠保證溝通減少障礙，提升個??檔寫作能?；

● 強調(diào)提供全量的上下?：郵件、?檔修改、公共頻道訊息、建?會議等都需要提供準確的上下?，確保成員理解，提升溝通效率。

(2) 目標精準，確保?績效結(jié)果產(chǎn)出

從產(chǎn)出上來說，主要可以采用以下方式：

● 結(jié)果導向的價值觀：異步辦公帶來的是全員?作成果產(chǎn)出全部為結(jié)果導向，結(jié)果導向能更好的促進?律以及?作效率提升，避免?效“摸?”；

● OKR導向：全員OKR，OKR確認上下級?標?致，公司全員?標對?，不出現(xiàn)分歧，更明確?作內(nèi)容；

● 員?的信任和?由：?標和背景信息對?的前提下，企業(yè)對員?信任度提升，員??由度提升，幸福感提升，?作效率提升。

(3) 分布式團建，團隊凝聚?為第?要義

在遠程辦公可能也會遇到團隊凝聚力方面的一些問題，我們對此也做了很多工作，比如每個月可能會有一個 cloud drink，這樣即使大家不能見面，也能夠從網(wǎng)上進行溝通交互。此外還會定期組織團建，雖然公司無法將所有成員集中在一起，但是每個團隊可以自行定期組織。我們還通過 Donut 工具隨機匹配大家進行溝通和交流，具體如下：

● Cloud Drink：團隊凝聚?的產(chǎn)?在于好的管理模式，Cloud Drink 的產(chǎn)?可以??提升團隊管理的凝聚?，讓“??”不?于當下；

● 分布式團建：除了定期辦公，采取“分布式”團建?式，團隊線下聚餐、定期線下辦公、年度活動等，增加團隊向??；

● Donut ：為線上隨機匹配活動，會隨機匹配線上?員進?每周三次的線上互動聊天，讓新員?相互熟識。

(4) 提升?作和?活的平衡度，增加員工幸福感

對于工作和生活的平衡這一方面，我們認為這可能與你的目標以及公司的運作形式相關(guān)。如果你制定好目標，那么可能遠程辦公打卡就完全沒有必要了。大家能夠為統(tǒng)一的目標努力，又能夠享受遠程辦公文化，在此過程中對個人能力也得到了一定的提升，這種通過結(jié)果驅(qū)動的文化其實對大家的打擾也不會太多。具體如下：

● 讓員?有“?活”：團隊管理從員?出發(fā)，以結(jié)果來評價績效??時間，促使員?提升?作效率，并擁有時間?由權(quán)限；

● 尊重員?：?先體現(xiàn)在尊重員?的個?時間，嚴格把控?作時?，員?在??作時間不受打擾。

6、產(chǎn)品 < == > 組織

最后想強調(diào)的是，大家既然要創(chuàng)業(yè)，那么就是奔著為客戶帶來價值這個方向來的，所以公司有了客戶之后，產(chǎn)品跟組織之間可能也會有一些相互影響的關(guān)系。我們的客戶是從 2020 年的年底開始逐漸成長起來的，現(xiàn)在有接近 50 家的付費客戶，但主要可能集中在歐美。有了客戶之后，公司也正處在從以底層開源為基礎轉(zhuǎn)換到以產(chǎn)品為中心的過程中。對于我們的產(chǎn)品，大部分客戶特別是海外客戶是通過公有云的模式使用，我們通過 SaaS 或者是半托管的模式為用戶提供全托管的服務。在這個全托管的服務過程中，我們整個公司跨全球團隊的 24 小時持續(xù)的覆蓋，反而也給用戶帶來了另一方面的價值。

但是我覺得在以后的發(fā)展中，比如隨著品牌影響的逐漸提升，最近一些客戶的使用規(guī)模和安全性要求逐漸提升，可能也會涉及 on-premise，這就可能需要更多的溝通和交互，隨著這些客戶的出現(xiàn)，今后組織結(jié)構(gòu)可能也會逐漸有所變化。所以大家如果要選擇這種模式，可能也要想清楚自己的產(chǎn)品未來的發(fā)展是不是適合。

07 問答環(huán)節(jié)

1、工程師如果要走管理路線，有哪些需要注意的點？

其實我也是從工程師轉(zhuǎn)型走管理路線，我覺得遠程辦公有一個需要特別注意的地方，就是同理心，要很好地理解團隊的訴求，在少量的上下文溝通中把握住大家的需求。這其實是在我看來是比較有挑戰(zhàn)，也是平時工作中可能注意比較多的一點。

像我們這種技術(shù)創(chuàng)業(yè)公司，可能大家相對來說是比較理性的，在整個創(chuàng)業(yè)過程中，包括我們往管理層方向轉(zhuǎn)型也都有一些比較好的方法可以推薦，比如《銷售加速公式》等圖書。其實做管理也是類似，我們都是靠著理性和邏輯帶領(lǐng)公司走上一條更理性的路。這跟我們解 Bug 一樣，發(fā)現(xiàn)問題、解決問題、逐漸迭代、逐漸積累。

2、您剛才說在往技術(shù)往管理轉(zhuǎn)型的時候可以通過看書或者自己摸索，那么是否推薦找專業(yè)的管理方面的培訓機構(gòu)給團隊提升管理能力呢？

我覺得如果你能找到好的教練，那么肯定是有幫助的。但從我的經(jīng)驗來看，在遇到問題后，如果能夠嘗試自己去理解問題，那么問題其實就已經(jīng)解決了一半，這也跟我們剛剛提到的解 bug 的過程一樣，你能夠把問題描述清楚，可能就離你的答案不遠了。

1）要了解更多關(guān)于聲網(wǎng) SDK和其他使用案例，請看這里的開發(fā)者指南：

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

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

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

3）還可以加入聲網(wǎng) RTE 開發(fā)者社區(qū)和我們一起討論交流：

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

總結(jié)

以上是生活随笔為你收集整理的翟佳：StreamNative 组织构建之路丨声网开发者创业讲堂 • 第 5 期的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。