![頭圖.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1627018980216-ee8617e3-888a-4ac2-8b46-e7b10014614e.png) 
作者｜一嘯
來源｜[爾達 Erda 公眾號](https://mp.weixin.qq.com/s/AiySBaLRvMuEW-qWNoK4Jw)

任何大型工程專案的研發都會涉及到兩個非常共通的難題：

- 第一個是穩定性問題，越大的專案越難做穩定，“魔鬼在細節裡”；
- 第二個是工程研發效率。

本文我們先聊聊第二個問題，後面再談談 Erda 的穩定性建設。具體談論如何打造大型的工程研發效率之前，先回顧一下我之前在阿里的 8 年研發經歷，希望藉此形成一個有帶入感的對比。

## 我在阿里的經歷
### DataX
我剛畢業加入淘寶後，第一次真正接觸的研發工作就是參與 DataX 的開發。

datax 的工作原理就是全量將某個資料庫或儲存中的資料讀出，然後再全量寫入到另一個資料庫或儲存中，總結起來，就是為了將資料從一個地方傳輸到另一個地方。當時在淘寶的核心場景是將 MySQL 的表資料傳輸到 hdfs 中進行 mapreduce 的大資料計算，除了 hadoop 計算場景外，還有將 MySQL 資料匯入 Oracle RAC 叢集進行分析的場景。

datax 的設計其實很簡潔：1 個核心框架 + N 個資料庫或儲存外掛。當時整個研發團隊也就不過 4、5 個人，我主要負責 Oracle 資料庫的外掛開發，很多時候都是在寫外掛，因為外掛的執行本身也就是單機程式，所以整個研發工作基本都是自己一個人完成。除了最後聯調的時候，過程中也不需要過多的複雜協作，研發的效率是非常高效的。

### Logserver
後來，我開始接觸 logserver 的開發，logserver 就是接收從淘寶每一個頁面傳送過來的埋點請求，生成下游能夠消費的日誌資料。

除了上下游的需求團隊外，這個服務的開發只有我一個人全權負責，我的主要工作就是將 logserver 從 apache httpd 的架構遷移到 Nginx 架構上，核心工作就是在 Nginx 上開發一個模組。logserver 當時在很長時間內都是整個淘寶 qps 量最大的服務，沒有之一（今天就不清楚了）。

現在回想一下，大都是當初一個人在慢慢倒騰這個 Nginx 模組的場景。logserver 和 datax 一樣，都是單機版程式，同樣不需要太多的協作開發。

### dbsync
接著，我又投向 dbsync 的開發。dbsync 和 datax 要做的事情本質上差不多，就是想從全量同步資料升級到實時的增量同步。當時主要做的是從 MySQL 實時同步到 HDFS 上，印象中只有 3 個人參與開發，而我負責的工作就是寫一個 C 程式從 MySQL 中實時地將 binlog 日誌訂閱出來。

### Timetunnel
寫到這裡突然發現：在淘寶的前幾年，我一直在做資料傳輸相關的中介軟體。

TT 本質也是用來傳輸資料的，並且它本身也是一個訊息中介軟體，類似 kafka。整個 TT 的開發團隊大概 5、6 人的樣子，我的主要工作就是基於 hbase 來實現訊息的儲存引擎。

這也是我在阿里唯一一個用 java 開發的專案，其他大部分都是寫 C 和 Go。

### tengine & cdn 
後續我轉崗去了 tengine 團隊，這裡有趣度超高。團隊大概有十多人，基本都是各做各的事情(模組) ，同時也樂在其中。整個團隊頗受外界獵頭喜歡，甚至一度流傳“要挖就挖 tengine 團隊”。

最後，整個 tengine 團隊一起去做 cdn 了。在 cdn ，我被安排帶著 3、4 個人去最佳化 dns 伺服器和排程系統，大概情況就是老牌的 bind 效能不行了，於是完全重寫一個 dns 伺服器。其實，寫一個 dns 伺服器也不難，大多時候都是一個人在看 RFC ，把標準擼到絲毫不差就完事。最終，我重寫的 dns 伺服器效能大幅度超越 bind ，成功上線節省了很多機器。後續準備再用 dpdk 幹一版的，還沒來得及幹，陰差陽錯就跑去做容器了。

### 容器
在我去容器團隊前，只有一個小夥伴天天和 docker 做鬥爭，我去之後變成了兩個人，他也不再是孤軍奮戰了。

然後，我們兩個人把 docker 裡裡外外魔改了一通，將其稱之為 alidocker。改到最後，老闆們覺得始終還是 docker ，索性就決定做一個自己的容器引擎，也就是現在的 pouch。就這樣，我也算是成了 pouch 的第一個作者，可惜做了第一個版本就跑路了，現在的 pouch 也挺遺憾的。

補一句題外話（小聲吐槽）：容器團隊選擇做 Swarm 而不是 K8s 這件事情也挺遺憾的。

### 總結一下
我在阿里的 8 年，一直做系統級的基礎軟體，這些軟體有著共同的特點：

* 很基礎
* 沒有業務需求
* 迭代速度較慢
* 缺少大型團隊的協作開發
* 程式碼級複雜，但服務架構簡單
* 行業內非常地通用且標準
* 對穩定性效能要求很高
* 很容易拿出來吹牛逼 （是不是值得吹，又是另外一個話題了～）

總結而言：我在阿里 8 年待過的所有團隊，好像沒有一個用過專案協作工具、持續整合 CI/CD 、全鏈路呼叫追蹤等研發效能相關的工具。這可能就是基礎軟體的研發現狀：團隊小、單兵作戰、強調個人能力；甚至，線上 debug、 fix bug 這種事情都是做過的。

有幸，今天我還能繼續從事基礎軟體的研發工作。不同的是團隊規模更大了，近百人的團隊共同開發一個基礎軟體，一起往前快速迭代是一件非常具有工程挑戰的事情。如果今天繼續採用我過去在阿里這種粗放、散養式的研發方式肯定是行不通的。

## Erda 工程實踐
接下來聊一聊：離開阿里後，我現在所處的 Erda 團隊是如何實踐大規模工程研發的？

### 里程碑 
![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626772537210-8cfd17a3-02e1-4e3f-aac3-2bc5750e89ea.png) 
（里程碑管理）

里程碑是宏觀層面比較重要的一個工具，我們主要靠它來設定方向、框定產品大圖。如果沒有里程碑設計的話，我們很容易突然迷失方向，陷入各種日常需求和問題中。

我們一般會把里程碑做得很大，或者說設計得很遠。比如，未來兩年一個比較粗的時間點要完成的事情都放入里程碑管理。

我們 Erda 設計的里程碑，大概就是這個樣子：

![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/286919/1626868951997-530f4357-6ae2-460c-a9b8-ae5a73e7c5e6.png)

里程碑的設計和管理畢竟太 high level ，有點類似頂層設計，所以它並不能成為日常研發工作內容的安排。這有點類似於 OKR，但沒有 OKR 那麼複雜，我們只是將未來的產品大圖打散到一個比較期望的時間節奏上去，然後讓日常的工作內容儘可能沿著這條時間線往前推進。

里程碑管理好的話，其實能起到承上啟下的作用：向上，能夠給公司層面跨團隊合作形成很好的同步和信任感；向下，能指導方向，拿到研發結果，不至於一年到頭碌碌無為。

### 需求管理

![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626773268649-9ed36268-6ab7-42be-b7a3-013fb70f6afe.png)

前面我們提到了里程碑工具，要想支撐里程碑的完成，還得靠日常的具體需求和問題，這裡先一起聊聊需求。實際觀察下來，很多開發同學其實不懂什麼是真正的需求，也不懂如何接需求。

下面舉個例子。

**需求方**：Erda 能不能支援從 Excel 中匯入資料？
(初一聽，這確實是個需求，就是要支援從 Excel 這種很常見的檔案裡匯入資料。稍微思考多一點的同學，就可以繼續追問。)
**開發**：為什麼要從 Excel 匯入資料，具體的場景是什麼？
**需求方**：Excel 表格上填寫這些資料很方，我習慣先在表格上把這些工作做好，再匯入進 Erda。

追問到這裡，其實已經能夠發現。需求方的真正的痛點是 Erda 這個功能不如 Excel 方便好用，導致使用者繞了一個彎路。所以，我們真正要做的需求是優先解決這個不好用的痛點。（至於有些人就是要這個功能，那是我們另外要討論的事情了。）

最常見的需求就是，能不能加個 XX 功能。（這裡大家可以細品一下。）

綜上，我們要求產品和開發同學對於任何需求都要不斷思考，多追問幾個為什麼，拿到使用者最原始的需求。始終要記住，使用者給你的極有可能是他認為的方案，而不是原始需求。

需求管理對了，後面的開發才會少走彎路，需求是起點、是根本。

### 迭代佇列

![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626773227185-bd1b6707-1c5c-43b6-8c91-a6efd42802cf.png)

一個商業化的大規模工程團隊，一定有 PD 這個角色。PD 是做什麼的呢？除了上面提到的需求管理外，PD 最基本的工作就是設計產品邏輯，這裡就不展開描述了。

在 Erda 團隊裡，PD 最需要核心設計的是迭代佇列，注意：這裡提到的是佇列，這個佇列裡需要長期裝滿 3 個迭代，其中的 1 個迭代裡存放著最優先要解決的需求和問題。為什麼這裡是 3 個迭代的佇列，而不是 1 個迭代呢？可以思考一下，我們在系統架構中，引入訊息佇列中介軟體的作用。PD 和開發之間完全可以透過這種方式來解耦的，開發只需要從佇列中取設計好的產品任務解決問題就好，PD 只需要不斷地從需求池裡取內容經過設計後再合理排入到迭代佇列中即可，兩邊的角色都可以實現自我驅動，不需要嚴格同步工作，所以這裡的核心是為了非同步工作。

![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626773947991-5becd269-b74e-40d0-93c5-67969da6b45c.png) 
（迭代管理）

那麼，這個佇列為什麼是迭代佇列，而不直接設計成需求佇列，開發直接取需求而不是取迭代呢？

需求佇列會存在兩個很大的問題：

* 第一，迭代是用來嚴格定義一個版本的時間週期，如果沒有迭代，版本的時間週期節奏會變得很亂，會進入一種比較隨意的狀態。
* 第二，當前實際開發中的需求如果要延期解決的話，這個延期的需求重新排到哪裡去？難道重新放到需求佇列的末尾嗎？放到末尾顯然不合適。如果是迭代，就可以嚴格規定放到下一個迭代或者下下一個迭代。

### 開發過程
![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626773325392-fb1aaed9-ad3f-4dd8-bb5d-9ca5760a874e.png)

開發過程中，對我們而言非常重要的一個關鍵指標就是：我們能夠合理接受單個需求的延期，但不能接受整個版本的延期（個別的特殊情況不在討論中）。

很多人可能對於這個指標的理解僅停留在保持發版節奏上，甚至會覺得這只是一種表面工作，版本出來了，需求沒有做完有何用，為什麼不延期版本把需求全部一起做完？

其實，這個關鍵指標完全不是一個管理結果，而是技術結果。很多專案在做架構設計、程式碼設計的時候，是沒有考慮後續小步快跑的，不能小步快跑地新增新功能、解決新需求的話，就會經常性導致部分需求做了一半要延期的時候，根本停不下來，這個版本根本無法臨時放棄需求而繼續發版；更嚴重的是，需求和需求之間還是強耦合的，一個需求做不完，其他需求也不能正常發版。這都是實實在在的技術問題、程式碼問題，而不是管理問題。

![需求任務關係](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626768642149-3a763d93-7902-4184-88ed-96fc5402b087.png) 
（需求任務管理）

除了關鍵指標以外，開發過程的管理，主要是基於任務來協同的，每個需求在開發前都已經被拆分成了合理的任務，也就是說一個需求會關聯完成這個需求的所有任務，開發同學只需要每天按照優先順序完成，並及時更新反饋任務的情況和進度即可。（這裡提到了及時反饋，反饋又是一個非同步工作的關鍵機制。）

很多研發主管都喜歡有事沒事在釘釘、微信裡詢問一下具體的工作進度，或者拉個會議對一下進度，所以 “已讀 + ding 一下“ 對他們來說是一個很好的功能。我們非常不鼓勵這種依賴即時通訊工具或會議的方式來溝通、瞭解開發進度，這種方式非常同步，就和同步呼叫一樣。正確的做法，應該是開發同學每天根據自己的情況及時在專案管理工具對自己的任務進行進度更新和總結反饋，研發主管自己按需關注任務的研發進度和情況，彼此沒事不要相互打擾。

#### CI 流程
在今年年初我們決定將 Erda 開源後，就把整個團隊的日常迭代開發全部轉移到 GitHub 上執行了，因此 CI 主要是基於 GitHub 的 Action 來做的，會把常規性的檢查任務全部放到 CI 中來完成，比如：單元測試、程式碼質量檢查、規範等。這個部分比較常規，沒有什麼特別的。但 GitHub Action 太慢了，我們後續計要把 GitHub Action 遷移到 Erda 的 CI，這樣我們可以實現 CI 併發更高、跑得更快、效率更高。

#### 本地+雲端
一個很大的產品就是一個很大的軟體工程，這樣大的工程要完全放到個人膝上型電腦上進行本地除錯開發，是一件難度不小的事情。就像一箇中介軟體、一個框架、一個 webserver 等，都可以很輕鬆地放到本地電腦上開發除錯，但要把整個淘寶裝到本地電腦就有點為難了，當然我們也正在向這個方向努力。

在不能完全將整個 Erda 輕裝到本地電腦前，我們採用了本地 + 雲端聯合的方式來進行開發除錯。雲端本身是一個已經部署好的 Erda 全平臺開發環境，包含所有能夠正常工作的元件；然後使用 telepresence 打通本地和雲端 K8s 之間的網路：

* 本地可以直接使用 K8s 容器網路內的 DNS，同時支援短域名的 search 機制。
* 本地啟動一個服務，劫持 （intercept）雲端 K8s 叢集內的 Pod，當 K8s 叢集內其他服務訪問該 Pod 時，流量會轉發到本地。
* 實現將雲端 K8s 叢集 Pod 中的環境變數全部自動匯出到本地。
* 實現將雲端 K8s 叢集 Pod 中掛載的 volume 透過 sshfs 對映到本地的檔案系統。

簡而言之，本地起一個服務，可以隨意訪問 K8s 叢集內的任意 service；同時，本地的服務也能被 K8s 叢集裡的其他服務訪問到。這樣一來，確實可以大幅度提高開發除錯效率，開發人員不用在複雜環境上來來回回的折騰。

#### 整合環境
雖然 Erda 給上層的業務應用提供了很強大的持續整合、部署和運維監控等能力，但 Erda 在很長一段時間內卻不能透過自己部署自己，也就是不能實現 Erda On Erda，所以那段時間一直沒有真正的自動化整合環境，研發質量和效率也不太高。

由於 Erda 整個工程專案比較龐大，程式碼從構建到部署更新，再加上所有的自動化測試跑一遍，整個流程需要數小時，耗費時間長。所以，我們的整合環境主要採用每天夜間定時執行自動化整合 + 測試，次日上班就可以看到整合結果。整合出來的錯誤結果，當天內必須 fix 掉，這是持續保證整合效果的關鍵。

![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626769474887-f54406d0-c760-4504-b97d-eef451e52c23.png) 
（基於流水線的自動化整合）

自動化整合主要針對的是 Master 主幹分支，我們沒法做到任何一個 PR 觸發自動化整合，核心問題還是專案太、開發人員多、自動化用例太多，基於 PR 整合的時間成本接受不了。

可以看出來，我們的日常開發測試和自動化整合兩條線路也不是序列的，而是非同步關係。我們不斷地追求、設計整個工程流程的非同步化，只有非同步才能高效支撐大型工程的研發。即使你的整個工程流程執行速度非常快，沒有時間消耗的成本，同步也會有額外問題產生的；同步的最大問題就是會被異常情況打斷、干擾，哪怕是一些可以延遲處理的異常情況，也會干擾你的工作，你必須花時間先解決異常，這種打斷和干擾對研發團隊的效率影響是致命的。

![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626774431766-3f6cd316-664a-4cca-8c8d-cfd07c0ac5cb.png)

#### API 設計和自動化測試
整合環境能夠有效工作的關鍵是什麼呢？很顯然，必定是自動化測試了。

自動化測試分為自動化的單元測試、介面測試、效能測試、安全測試、UI 測試等等。日常開發過程中，效率影響最大，最頻繁的顯然是單元測試、介面測試、UI 測試。

* 單元測試比較簡單，我們放到了 CI 流程中，每一個 PR 就驅動完成了單元測試。
* 介面測試非常關鍵，我們需要覆蓋那些全鏈路場景的介面，從最頂層的介面出發完成整個系統的功能自動化測試，所以介面的自動化測試就放到了整個整合環境中完成，因為整合環境有最新、最穩定的程式碼，以及非同步執行等優勢。
* UI 的自動化測試成本相對比較高，我們目前還在嘗試階段，沒有完全達到成熟。我一直希望從智慧測試的角度，用 AI 演算法的思路去解決 UI 的自動化測試。

這裡先介紹一下介面測試。介面就是 API，要想編寫出好的介面測試用例，必須得先有 API 的設計。API 的設計從哪裡來呢？我們當然不希望從開發工程師的口中來，所以自研了 API 管理平臺，從 API 的設計到測試進行全覆蓋。開發工程師在完成需求前，首先在平臺上完成 API 的設計工作；然後將 API 的設計和需求關聯上，這樣一來，測試工程師就自主從需求裡獲取到具體的 API 資訊，完成介面測試用例的編寫。

![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626767679395-322f03af-78cc-4ffe-a79d-863abef9a134.png) 
（API 設計管理）

除了非同步協同外，打通整個工程流程，也是我們至關重要的一環，這也是我們為什麼不用 jira，jenkins 等的一個原因。

另外，我們的自動化測試用例是由測試工程師編寫、開發工程師一起維護，對測試工程師的 OKR 設定就是任何一個版本的迴歸 + 新功能測試必須控制在一個非常小的人/天內。今天 Erda 有著近百人的研發團隊，而測試只有 5 個人。

![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626865021113-018f6225-a466-4bdc-9764-9ac3764d4e5a.png) 
（基於場景的自動化自動化測試流程）

### 手工測試
有了自動化測試，為什麼還需要手工測試？手工測試顯得似乎沒有那麼高階了。

對於沒有前端 UI 的系統，自動化掉所有的測試理論上是可行的；一個有著複雜前端 UI 的系統，自動化起來還是會有很多難點，大多數做 UI 自動化的，基本也都是集中在幾個核心的流程上，很難覆蓋邊邊角角的全部場景。

在專業測試工程師眼裡，手工測試也是很重要的一部分，需要有工具、有方法來支撐的。每一個版本，手工測試用例也是要能夠被迴歸的，因此這些手工用例也要被記錄下來。

![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626767521519-dfa9445a-606a-4900-bbd7-dade57a908dc.png) 
（手工測試用例管理）

這部分我們就講到這裡，不再過多討論。

### 答疑和問題處理
Erda 作為基礎平臺性產品，使用者會比較多，零零碎碎的答疑和服務支援直接打到產研團隊的話，會消耗非常多的研發精力，因此我們建設了專門的 “SRE 團隊 + 輪值的產品研發答疑同學” 來面對客戶，針對客戶和使用者的各種問題進行答疑。除了配置專業的服務以外，另外一個更重要的事情就是需要將服務支援過程中的問題記錄到 Erda 專案的工單（tickets）中，這裡說的Erda 專案工單就是等同於 GitHub 的 Issues，它並不是一個面向客戶服務的工單系統。

![undefined](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21274/1626767435803-21ff7096-daf6-4645-b17c-cf31ad0b69ac.png)  
（答疑問題管理）

專案的工單列表在每週五需要進行 Review，將那些比較簡單、能夠快速解決的工單問題梳理出來，然後一鍵複製到迭代佇列中。這裡有兩個很關鍵的點：

1. Review 先挑選的是那些簡單的、能快速解決的問題。
2. 放入到迭代佇列，而不是需求池。

軟體系統的 bug 總是解決一個少一個，越跑越穩定，所以簡單的問題要快速解決、0 容忍對待。難的問題需要專項對待、專項解決，不對的時間節點或者資源有限的情況去死磕難題，大機率不是一個好想法。

篩選出來的工單問題千萬不要放到需求池中，一定要直接進迭代規劃。進了需求池，就不知道什麼時間才可以排上號了，明確放入迭代、明確好解決時間，快速收斂問題最重要。

### 發版經理
我們在一個迭代週期內，會輪值一個“發版經理” 的角色，發版經理要做的事情核心就是協調 + 跟蹤。當然，發版經理不是去協調團隊內的你我他的事情，也不是去跟蹤某個人有沒有划水。而是和 PD 一起確定迭代要做的需求內容，參與需求是否延期到下一個迭代的決策，確認新版本週期內幾個關鍵時間節點的產物並做好驗收，以及統一負責凍結程式碼分支等事情。總之，“發版經理”需要為新版本的效率和質量負責。

### 工具優先給誰用
最後，這裡再聊聊工具的推行使用問題。我個人在做整個研發管理過程中，有一個深切體會：工具的推行一般來自於上級，上級推行這個工具的出發點當然是為了效率；但是，你經常會發現很多研發主管在關注工具的時候，一般都是從自己的管理視覺出發，而不是真正從一線員工使用工具的視角出發。

比如，專案管理類工具的第一核心究竟應該是定位給 PM 或研發主管用，還是應該定位成工程師間的協同使用？如果你要將團隊打造成更高效的非同步協同團隊，那麼這類管理工具一定是先給一線員工使用的，真正做到讓團隊內的每個人在工具上協同起來，透過工具平臺來連線你我他。

## 架構設計
這裡談架構設計，不是想聊 Erda 的架構，我們還是聊一下工程效率這件事情：從架構層面如何做一些效率上的保障，讓大規模研發團隊可以更加從容迭代。

### 微服務化
早期版本，Erda 也是一個大的單體應用，團隊規模就幾號人，和我之前在阿里團隊經歷的差不多，協同起來非常高效，新增功能和解決問題也很快。但隨著人數的逐漸增多，過程中出確實現了很多協作問題、效率問題，反正最後就是拆分成了微服務。當然，微服務也有微服務的問題。

講微服務設計方法論的分享有很多，可以自行搜尋參考。

### 元件化協議
Erda 團隊的前後端比例，在最高時能達到 1:7，也就是一個前端要對接多個團隊的多個後端，產品開發迭代的瓶頸被前端資源限制住了。

為了解決這個問題，我們思考並探索出了一套元件化協議框架，前端提供元件庫和互動定義，專注於豐富元件的功能和改善互動體驗，如何拼裝元件和提供資料來實現業務功能，就交給後端來做，由於前端可以不關注業務邏輯和對接溝通 API 定義，中間能節省掉許多溝通成本，從而提高了整體的產品開發效率。

### db migration
對於 Erda 來說，快速迭代產生的眾多版本必須保證能夠順利升級。對我們來說，升級最難的其實是資料庫的 migration，針對這樣的一個情況，我們自己開發了一個 dbmigration 的管理框架，然後基於第一個產品版本定義好資料庫的基線，後續的每個版本都在前一個版本的基礎上開發 migration 邏輯放入到框架集中管理。Erda 的升級必須是從釋出的版本按順序一個一進行 migration 升級。

開發一個軟體可能比較容易，開發一個能夠持續升級的軟體相對來講困難度就比較高了。針對 migration 和升級，我們在測試階段也會反覆驗證這件事情。

## 寫在最後

研發管理這件事情本身管理的是技術，而不是人。我所接觸到的很多人，還是會覺得研發管理是安排一個 PM 去盯著整個研發過程，甚至拿著“鞭子”去抽那些走得慢的人。這個意識和認知肯定是不對的，只有把管理動作拉回到技術本身這件事情上，才能真正激發團隊的熱情。

另外，任何人設計的任何一個工程流程和管理，在實際落地執行的時候，都不要去追求完美、100% 的精確，這是一件不現實的事情，有誤差才是符合自然規律的，我們要做的事情就是將誤差控制在足夠小的範圍即可。能夠接受不完美，是研發 TL 的自我修養。

關於 Erda 如果你有更多想要了解的內容，歡迎新增小助手微信（Erda202106）進入交流群討論，或者直接點選下方連結瞭解更多！

* Erda Github 地址：https://github.com/erda-project/erda
* Erda Cloud 官網：https://www.erda.cloud/

聊一聊在阿里做了 8 年研發後，我對打造大型工程研發團隊的再思考

相關文章