VOL.01 Eolink
Eolink 的創業方向是一次無心插柳。
在 Eolink 創辦之前，創始人劉昊臻先後參與了技術外包、線上醫療、O2O 電商等創業專案，但是覺得不太符合自己的期望。
2015 年底，劉昊臻想更好地管理團隊內部的 API，但市面上的產品並不能滿足需求，於是，他決定做個產品來解決 API 協作問題。沒想到，這個產品不僅解決了自己的麻煩，還可以解決所有 IT 團隊遇到的有關 API 的共同難題。
接著，劉昊臻將這 API 管理產品開源出來，在得到許多使用者的認可後，他成立了 Eolink，公司的產品逐步發展為一個定位於企業級的 API 全生命週期平臺，透過標準化的產品為中大型客戶提供 API 快速生成、API 研發管理和團隊協作、自動化測試、微服務閘道器、API 監控以及 API 開放與交易服務。
API 全生命週期平臺
API 趨勢與產品化
IT 界有個康威定律：設計系統的架構受制於產生這些設計的組織的溝通結構。在早期開發軟體，由於軟體的系統複雜度不高，所有程式碼通常被封裝成一個整體，這種架構叫做單體應用。這種軟體架構是高度整合的，就像那時候的軟體企業一般什麼東西都自己做，也很少用第三方開原始碼或者 API。
後來隨著軟體產品形態的發展（包括 PC 客戶端轉向 Web、手機端）、開源的發展、以及人們對軟體開發效率的追求，企業開始用開原始碼或者第三方 API 代替邊緣的程式碼。這時候出現了前後端分離、DevOps 的風潮，並出現了第一批 API 管理的工具，比如 Swagger、Postman 等，目標都是解決 API 的文件管理和 API 快速測試的問題。
現在，隨著雲原生的概念普及，和微服務架構改造的風潮，越來越多的企業大量使用了開源元件、第三方的 API，甚至底層的核心技術幾乎都是來自於開源元件和第三方 API，比如聲網就給大量做直播的企業提供了直播相關的 API。Linux 基金會的資料顯示，70-90% 的程式碼是由開原始碼和第三方 API 來組成的。
因此，軟體的開發變得越來越「樂高化」，也就是說開發者可以很快地透過開源元件及第三方 API 來拼湊出一個產品，而這時候的企業組織也變得更加零散。
基於這些考慮，Eolink 在 2016 年做了兩個判斷：
第一點，API 會爆發式增長，由此會帶來一系列的研發、測試、運維等問題。就像是你有 100 行程式碼的時候，你可以不做任何事情，但你有 1,000 行程式碼的時候，就必須由 Git 來幫你管理程式碼。
第二點，越來越多的企業會開放 API，由此會帶來開放、推廣、銷售、品牌、運營等問題。比如誰能找到你的 API，開發者怎麼知道哪些 API 更好或更適合自己，企業怎麼運營自己的開發者社群等。
所以，Eolink 希望把 API 的全生命週期都串聯管理起來，所謂「API 全生命週期」包含了三個層面——設計、實施和管理，而這三個層面又細分為 API 的設計、研發、測試、部署釋出、運維監控、版本管理和下線。
其他的同類產品一般來說只覆蓋其中一個層面，要麼就是設計（設計、測試）、要麼就是實施（部署釋出、運維監控）、要麼就是管理（版本管理和下線）。Eolink 的產品則是比較全面，覆蓋了整個 API 全生命週期。
其中，Eolink 的核心產品是 API 文件管理、API 自動化測試、API 監控、API 閘道器、API 開放平臺、API 交易。
API 在軟體研發中的價值
ONES：你們怎麼理解 API 在軟體研發中的價值？怎麼定義 Eolink 在此過程中的角色？
梁順安：
在 API 領域，我們看到有幾個大的推動力在促進 API 行業的快速發展。首先是技術變革的推動力。由於公有云等技術的發展，讓軟體逐步拆解為微服務架構，而拆分微服務的過程中就會產生大量的 API，圍繞著 API 的管理需求也就快速成長起來。
其次是團隊管理的推動力。由於技術變革導致 API 數量大量增長，我們發現 API 的鏈條開始變得很長，甚至比程式碼管理的鏈條還長，我們不僅需要管理 API 的設計、研發，還需要管理測試、對接等團隊協作的工作，甚至 API 釋出上線之後，我們還需要透過管理 API 的流量來保障 API 的安全、效能和穩定性，因此 API 涉及到的人員也更多，那怎麼讓圍繞 API 的相關人員能夠高效地合作，就是一個大問題，這就是我們看到的在管理方面的推動力。
最後是企業服務交付方式改變的推動力。因為 API 是一個資料和服務的標準載體，幾乎所有的網際網路服務都透過 API 的方式來傳輸和交易，因此 API 是有強資產屬性的，隨著越來越多的企業使用 API，並且透過 API 提供服務，這樣明確的商業供求關係也推動了 API 行業在未來相當長時間的持續增長。
陳景範：
從 2016 年以來，國內很多網際網路企業都搭建了「中臺」。中臺是一個能同時支撐多個業務、讓業務之間的資訊形成互動和增強的機制。我們認為，中臺的核心其實就是企業的「服務能力 API 化」，未來更多的企業都需要搭建中臺。企業一旦將 API 管理起來後，實現資訊的打通，就可以對外開放，包括開放給生態合作伙伴和使用者。這樣一來，API 就具備了交易的價值——這也是「API 資產化」的一個側面證明。從這個意義上來說，API 是企業的一筆資產，而 Eolink 就是協助企業管理好 API 這筆資產的平臺。尤其是進入「萬物互聯」的時代後，API 就是企業與世界互聯的第一介面。
ONES：你們自己在技術開發上遇到過哪些困難？如何克服這些困難？
梁順安：
我們最大的困難一直都是喜歡做創新的事情，而創新本來就是極高風險的。國內許多人創業做產品是看海外有什麼成熟的模式和產品就搬到國內，而我們在 2016 年做 API 全生命週期時，國外其實也都還沒有成熟的概念和產品，純粹是基於我們對使用者需求和市場趨勢的判斷來做，因此當時最難的是摸著石頭過河，每天透過和使用者聊天來收集需求、設計產品和商業模式。
到了 2017 年我們想做一個零程式碼的 API 自動化測試，當時市面上的產品基本都是需要寫程式碼來做自動化的，即使是 Postman 也是在這兩年才推出了流程測試。相當於我們又再一次做一些別人沒怎麼做過的事情，但我們相信這種冒險對使用者是有好處的，所以花了大量時間來設計產品，最終做了國內第一個零程式碼的 API 自動化測試。後面有許多 API 產品都參考了我們的設計，從某種意義上來說，我們也是推動了整個行業的發展。
Eolink 產品示意圖從 2018 年開始，我們一直在嘗試覆蓋 API 全生命週期的各個階段，推出一個一站式的 API 平臺，並且在此基礎上做成標準化產品。在經過兩年的打磨之後，我們在 2020 年推出了國內第一個標準化的 API 開放平臺。
陳景範：
另一個難點就是 IT 團隊永恆的話題——人效的問題，怎麼樣能更快速地給客戶提供價值。我們主要還是使用一些常規的管理手段，譬如 OKR，這裡最令人頭大的問題是怎麼本土化，做一個符合公司的 OKR，另外就是透過一些技術工具來提高我們自己的人效。
我們現在在做的一個很重要的事情就是怎麼結合我們自己的產品將研發側的 DevOps 做得更好，譬如剛剛說的 API 文件和自動化測試都有共同的特點，就是快。我們內部搞了不少 Beta 版本的工具用於自動生成 API 文件和測試用例，來實現降本增效。
還有一個重點地方就是使用 ONES 做專案管理。整個軟體工程的研發都圍繞著 ONES 來做管理，讓研發過程更井然有序，更加合理安排人力資源的問題。
ONES：萬物互聯時代的 API 管理將如何演化？貴公司將在其中扮演怎樣的角色？
陳景範：
現階段大部分公司內部的 API 管理狀態，基本上都是單點管理。所謂單點管理就是每個部門都只管理自己產生的 API，其他部門、甚至部門對自己所擁有的 API 資訊明細是不大清楚的，這就會導致很多額外的溝通成本、管理成本、協調成本。解決這個問題首先就要有一個 API 平臺，也就是說，要能一次性處理 API 的資訊有關問題，以及 API 協調問題，讓部門內部的溝通、管理、協調成本降低。這還只是部門內部的麻煩，跨部門其實也有這種困擾，只要將 API 平臺從部門平臺提升到公司平臺就能解決跨部門的成本問題。解決了公司內部的問題後其實還有一個網際網路領域的問題，譬如不同的部門、子公司之間其實不單隻可以考慮部門、子公司之間的 API，還可以考慮公司外部的 API 消費使用。
這個過程就是 API 如何平臺化，主要涉及到三個層面：第一層面是部門內部的 API 平臺，第二層面是公司內部的 API 平臺，第三層面是全球資訊網的 API 平臺，我們公司的戰略方向其實就是將這三個層面都做好，這期間會將整個 API 生態給串連起來。
生態再擴充
ONES：你們的產品助力企業客戶數字化生態建設，那麼，你們自己是怎樣打造生態的？
陳景範：
API 生態存在一些不確定性，從 API 資產維度來說，現在有些科技公司的產品就是一個一個的 API，譬如一些直播 API 和語音 API 等等，這些已確定的 API 資產能構建一個很好的消費者 API 生態。未來，這些 API 產品越多，這個生態就越大，我們的產品價值也會越大。當然，我們相信未來肯定會有越來越多的 API 產品，多到像電商產品那樣，同型別的產品會有多個牌子供大家選擇。關於超越 API 這個事情，首先我們未來的戰略方向關鍵點是在於 API 平臺以及 API 生態這兩個關鍵點上。
API 平臺這個是明確的，我們希望我們的產品從工具轉化成平臺，讓企業內部的 API 價值流動起來，給客戶帶來更多更高的價值，還希望將企業內部的 API 平臺和公網的 API 平臺組成生態平臺。譬如 API 交易這塊可以一鍵從公司內部發布，也可以一鍵獲取。
我們還可以跟一些公司構建互為生態的關係，例如 ONES。我們兩家公司的產品，一個是覆蓋 API 全生命週期，一個是覆蓋研發管理的全生命週期。在使用者價值、相容國產硬體以及系統、產品推廣、銷售線索方面，我們基本上都是研發團隊不可或缺的工具平臺，這一方面就說明了我們的客戶群體應該是高度重合的，彼此有不少互相借鑑學習的地方。
ONES：Eolink 的目標是為了提升企業客戶的研發效率，那麼 Eolink 是怎麼提升自己的研發效能的？
梁順安：
我們以前用過國外的研發管理工具，在使用的過程中，不僅我們，很多開發團隊都覺得那些工具並不符合自己的管理流程。我們往往需要在這些工具上做二次開發，其實用起來的難度是不小的。可以說，這樣的管理工具算不上效率工具。這樣，我們只好尋找其他研發管理工具。因為我們跟 ONES 有共同的企業客戶，在業務上也有互為生態的關係，所以，後來我們在自己的研發管理中也開始使用 ONES。
在選擇 ONES 之前，其實我們調研過很多這方面的產品，最終推動我們做決定的原因主要有兩點，一是 ONES 功能齊全，覆蓋研發管理全生命週期確實不是浪得虛名的（產品矩陣真的很豐富），二是 ONES 的功能上手相對簡單。
必須承認的是，ONES 更貼合我們自己的研發環境，符合我們日常的管理流程和習慣。打個比方，倘若我想在國外的研發管理軟體的 SQL 做缺陷查詢聚合，那麼我需要手動寫一些類似程式設計的欄位語句。但 ONES 是不需要這麼麻煩的，因為它本身已經整合了相關的生成器，有關的圖表也是可以直接用的。當涉及 DevOps、私有云部署，以及一些工具整合等方面，ONES 也比國外的同類工具更好用。另外，如果我們想要找客服，那麼我們在白天是可以找到 ONES 的客服的，但因為時差的原因，國外的客服在我們的白天裡是找不到的。
用了 ONES 之後，需求管理、專案管理和缺陷管理都更加有條不紊，專案資料也更容易跟蹤和統計。
成長中的開發者團隊，也有自己的精彩故事。我們相信，技術創新是團隊高效協作的結果，中小團隊也需要專業的研發管理平臺。
ONES 面向50人及以下研發團隊提供免費的團隊版啦，不限時間，不限用量，戳此處註冊使用～