【導言】DevOps 概念發(fā)展的多年間，直至近幾年才真正開始普及起來。本文將圍繞 DevOps 工具和工程兩大維度

探究軟件工程格局。在分析了國內(nèi)外近 1000 個工具后，我們發(fā)現(xiàn)了以下亮點內(nèi)容：

1. DevOps 工具可以抽象為以下幾個大類：Design、Develop、

Quality、Delivery、Telemetry、Security、Runtime、Middleware；

2. Runtime 的產(chǎn)品不多，但是數(shù)量級的工程效能提升往往是 Runtime 發(fā)生了變化；

3. Middleware 是個大賽道，數(shù)據(jù)庫是重中之重；

4. UI 設計工具很繁榮，商業(yè)化也很好，發(fā)展趨勢是跟低代碼結(jié)合；

5. 開發(fā)領域的工具紛繁復雜，面對開源和大公司的挑戰(zhàn)最多。項目管理類是商業(yè)化最好的細分領域；

6. 國外在質(zhì)量工具的投入巨大，產(chǎn)品豐富且出色，國內(nèi)幾乎為零；

7. 互聯(lián)網(wǎng)和云原生催生了持續(xù)交付的發(fā)展；

8. 可觀測性重要性越來越高，AIOps 是發(fā)展方向，商業(yè)化也很成功；

9. 除了運行時安全以外，開發(fā)安全越來越受到關注，軟件供應鏈方面也值得重視；

10. 一站式工具一定會走向開放擁抱單點工具；

11. PC 時代和互聯(lián)網(wǎng)時代工具都是國外的，云原生時代國內(nèi)的 Infra 團隊有機會。

作者 | HAIlong Zhang

來源 | 撿起來公眾號（已獲授權）

給 DevOps 下個定義

大概從 2019 年開始，DevOps 這個詞語在軟件工程領域出現(xiàn)的頻率越來越高，雖然這個概念十幾年前就有了，但是確實最近幾年才開始真正普及，國內(nèi)外均如此。在三年前，你說 DevOps，大多數(shù)人指的是 CI/CD，兩年前開始有一站式的概念，DevOps 包含了從項目管理開始的一整套，而最近又開始提 DevSecOps，DevBizOps，層出不窮。現(xiàn)在很少有人在糾結(jié) DevOps 這個概念了，嚴格意義上 DevOps 是指讓開發(fā)可以干運維的工作，但實際應用中這個詞語大體可以理解為現(xiàn)代化的軟件工具和工程方法。

工具和工程是兩個維度的東西，我們講敏捷開發(fā)，瀑布開發(fā)是一種工程方法論，跟實際使用的工具無關，你用 Excel 也可以實現(xiàn)敏捷。但實踐中，特定的工程方法論往往依賴一些特定的工具，比如敏捷依賴看板。從我們的觀察來看，目前各行各業(yè)的軟件開發(fā)團隊使用的工程方法論依然有很大的不一樣，有敏捷的，瀑布的，雙輪驅(qū)動的，還有中國式敏捷等等，但是使用的工具正在逐步趨同，普遍都在往新的生產(chǎn)力工具上遷移。

我們對國內(nèi)外近 1000 個工具做了一些研究和分析，有一些總結(jié)記錄下來跟大家分享。值得一提的是這些工具的涵蓋范圍包含了整個軟件的基礎設施 Infra，而不僅僅是 DevOps。

Infra 工具地圖

市面上的工具五花八門，我們需要尋找一個維度來對工具進行抽象的分類，合并同類項才能更好的理解這個行業(yè)和市場。抽象的維度有很多，比如可以根據(jù)面向客戶的規(guī)模分會顯的太粗，按照工具的類型分會顯的太細。最后我們決定根據(jù)軟件工程的階段和層次來分，制作了下面這張地圖。

這個分類的邏輯是：

1. 最底下是云，包括 AWS、騰訊云、阿里云等等，還有一些跟資源相關的產(chǎn)品，比如 ServiceNow、CloudFlare 等等。

2. 最上面是軟件設計相關，包括 UI 設計和需求設計，也就是軟件看得見的部分，比如 Figma、Adobe 等等。

3. 中間部分是真正構(gòu)建軟件的部分，首先是軟件的開發(fā)，質(zhì)檢，交付，這是所有生產(chǎn)必不可少的三個步驟，這里包含了日常開發(fā)者打交道最多的 IDE、代碼管理、需求管理、CI/CD、自動化測試等等。

4. Runtime 和 Middleware 是每個軟件都依賴的部分，可以理解為軟件的底座，比如容器、數(shù)據(jù)庫、編程語言 SDK 等等。

5. 最右邊是 Telemetry 和 Security，這兩塊是保證軟件正常運行必不可少的，比如監(jiān)控日志報警、安全掃描、入侵檢測等等。

這里每個色塊的大小代表了我們認為目前這個領域的市場空間，我們相信這里的面積會隨著行業(yè)的發(fā)展而變化。這樣的分類基本涵蓋了軟件工程的所有方面，當然一個產(chǎn)品可能會跨多個色塊，特別是平臺類產(chǎn)品。很多新產(chǎn)品的邊界很模糊，比如一個類 Serverless 產(chǎn)品，同時會提供 IDE 和部分中間件。但也有一些產(chǎn)品是非常專注在某一個具體的領域，比如基于 AI 的 UI 自動化測試。這里會涉及到一個經(jīng)常被提及的問題：一站式工具和單點工具最終會是什么關系？我們將在文章的最后部分來討論。

我們在制作這個地圖的時候，深深的意識到中國跟美國相比，在這個領域的差距真的是令人汗顏，國產(chǎn)化“信創(chuàng)”路漫漫啊。

Runtime

我們跳過最下面的 Cloud 部分，因為云這部分跟大多數(shù)公司沒有關系，這個底層基礎設施類似于電信運營商，注定只能是少數(shù)大公司的生意。我們先來看 Runtime 這個部分。

目前專注于做 Runtime Container（我這里用 container 是泛指運行程序的程序，serverless 也算 container 的一種）的產(chǎn)品不算多，跟整個技術體系的發(fā)展階段有關。事實上數(shù)量級的工程效能提升往往是 Runtime 發(fā)生了變化，例如 Java 當年帶來的變革，還有最近容器化帶來的變革。下一個可以預見的 Runtime 變革是 Serverless。雖然 Serverless 已經(jīng)存在了很多年，但發(fā)展的并不好，究其原因是因為程序結(jié)構(gòu)和新的運行環(huán)境不匹配，所以我認為 Serverless 要能發(fā)展起來，必須是從程序結(jié)構(gòu)開始的變革。目前有一些公司在這個方向上努力，例如 Netlify、Platform9，以及新晉創(chuàng)業(yè)公司 Inngest、Koyeb。這里的新東西都比較小眾，因為適用面有限，解決了極致的效率，但不能解決規(guī)?；瘧玫膯栴}。

另外一類是相對兼容現(xiàn)有的應用結(jié)構(gòu)，提供更好的工具來幫助開發(fā)管理運行環(huán)境，Runtime Management 典型的比如 k8s、Terraform，也有一些做的很大的創(chuàng)業(yè)公司，例如 Pulumi.com。我們可以把這類產(chǎn)品都看成是新時代的 Ansible。這個領域的產(chǎn)品挺多的，而且不斷的有新產(chǎn)品冒出來，是對目前的云一個很好的補充。

Middleware 中間件

說實話，在我從業(yè)生涯早期的很多年一直不理解什么叫做 Middleware 中間件，雖然我的第一份正式工作是在 Oracle 的中間件部門。這種概念在不同的時期往往有不同的涵義，最早中間件可能是指 JBoss、Tomcat 這類服務器軟件，后來又包含了消息隊列 EJB 之類的。我認為比較好的理解中間件的概念是：所有非程序本身，又是程序運行所必不可少的軟件，例如數(shù)據(jù)庫，緩存，隊列，網(wǎng)關等等。中間件是云廠商可以直接提供給你的，但程序你必須自己寫。

中間件五花八門，這里有非常多的上市公司，創(chuàng)業(yè)公司，是個超級大賽道。我看了一下基本可以分成 Database 和 Others，因為數(shù)據(jù)庫真的是中間件皇冠上的明珠，太靚眼了。這里的 Database 不一定是傳統(tǒng)意義上的數(shù)據(jù)庫，跟數(shù)據(jù)存儲和處理相關的都算，例如 Snowflake。其他還有比如 MongoDB、Influxdata、Netapp、Qumulo 等等太多了，都做的很大。

Others 里面相對就小很多，但是品類很多，例如對象存儲 MinIO、服務網(wǎng)格 Solo.io、消息隊列 Redpanda、API 網(wǎng)關 Kong 等等。

Design 環(huán)節(jié)：需求設計和 UI 設計

軟件工程其實有很多理念都是從傳統(tǒng)制造業(yè)借鑒的。本質(zhì)都是在生產(chǎn)東西，一個是實物，一個是虛擬，但是在流程和管理上有很多可以借鑒的地方。所有的生產(chǎn)無非是設計，制造，質(zhì)檢，交付。我們先來看設計環(huán)節(jié)。

軟件的設計分為需求設計和 UI 設計（當然也有架構(gòu)設計，數(shù)據(jù)庫設計等等，這一類我們認為屬于開發(fā)環(huán)節(jié)）。這里的需求需要跟傳統(tǒng)的項目管理軟件比如 Jira 中的需求區(qū)分開。Jira 中的需求可以認為是已經(jīng)確定要做的，進入開發(fā)流水線的。而事實上業(yè)務運行過程中有很多需求是不確定的，可能來源于 IM，郵件，口頭等等，這些需求需要經(jīng)過產(chǎn)品經(jīng)理的充分評估和完善才能進入開發(fā)環(huán)節(jié)，這些需求也缺乏結(jié)構(gòu)化的整理和更新例如 Roadmap 等等。所以我們可以把這里的需求設計理解為產(chǎn)研跟業(yè)務對接的地方。關注這個領域的產(chǎn)品真的不多，可能是痛點不夠明顯，或者通過別的工具替代了，例如文檔、Excel、Jira 等等，雖然不完美但也不夠痛。有一些產(chǎn)品做得還不錯比如 Aha.io、Accompa、Productboard 等等。

而 UI 設計就有相當相當多的工具，老牌的比如 Adobe 系列，新晉明星 Figma 等等。這個領域有非常多的細分，比如產(chǎn)品原型設計 Mockflow、Proto.io，快速 UI 設計 Framer、Webflow，還有通用的線框工具 Miro、Lucidchart 等等。這里的發(fā)展趨勢逐步的跟低代碼在結(jié)合，最終可能發(fā)展為設計即代碼的狀態(tài)。所有這些工具確實拉低了下限，讓更多的人可以上手，但真正專業(yè)的設計師還是需要能掌控細節(jié)的工具，所以 Figma 這類工具在專業(yè)群體更受歡迎。

最為復雜的 Develop 領域

開發(fā)占了整個地圖中最大的一塊區(qū)域，這個領域東西最多最雜，畢竟這是跟人打交道最多的地方。這里面最大的一塊叫做 Project Management，包括了需求管理，Bug 管理，進度管理，度量等等，研發(fā)出了 Jira、Asana 這樣的產(chǎn)品，都是很大的上市公司。這個領域也不斷的有新產(chǎn)品出現(xiàn)比如 Rocketlane, Code Climate，但都比較垂直。值得一提的是有很多團隊會用更通用的管理工具來實現(xiàn)同樣的目的，例如 Trello，Monday，甚至 Airtable。管理是一個非常多樣化的需求，所以這個領域百花齊放。我們觀察到中美在這個領域的需求差異極大，國外的需求更偏向個體效率，而國內(nèi)的需求更偏向于管理效率。從全球來看我們并沒有看到什么產(chǎn)品能夠挑戰(zhàn) Jira，基本上 Jira 的插件能力能滿足絕大多數(shù)的場景需求，但國內(nèi) Jira 受到非常大的挑戰(zhàn)，不僅僅是因為國外產(chǎn)品政策的原因，在貼近用戶“管理”需求上，確實國外產(chǎn)品做的不夠，例如對糅雜了瀑布模式的中國式敏捷的支持，還有對業(yè)務需求的管理等等。

開發(fā)這里的第二大領域是 Pipeline，俗稱流水線，這也是從制造業(yè)借鑒過來的。這里的 Pipeline 是泛指寫完代碼以后所涉及到的工具，而不僅僅是 Jenkins 這樣的 CI。這里的典型代表是 GitLab，它的兩個主打產(chǎn)品就是代碼倉庫和 CI，占據(jù)了 Pipeline 里面的絕大部分位置。這個領域特別繁雜，但商業(yè)化做的好的不多，絕大多數(shù)是小工具，甚至是開源工具。在這個領域做產(chǎn)品將面對開源最大的挑戰(zhàn)，因為程序員喜歡在這里造輪子。Pipeline 上可以集成各種單點的工具，例如代碼掃描 Sonar、代碼審查 Codacy、代碼搜索 Sourcegraph。還有一些更垂直的專注某個類型應用的工具，例如移動端構(gòu)建 Bitrise、移動端開發(fā) Ionic、服務器端鏡像構(gòu)建 Packer。

我們來說說低代碼。我其實是不太相信低代碼這個故事的，詳細的分析可以看《低代碼開發(fā)會是未來嗎？》。但無論如何，在某些垂直場景下業(yè)務功能的模塊化低代碼確實是有價值的。事實上我們看做的好的低代碼產(chǎn)品也往往都是垂直場景的。老牌的低代碼產(chǎn)品比如 Mendix、Outsystems 等等。Oracle、微軟、Salesforce 等等大廠也都有自己的低代碼產(chǎn)品。另外的低代碼產(chǎn)品大致可以分為兩類，一類是流程自動化，例如 Appian、Tray、Creatio。另外一類是快速開發(fā)工具，例如 Draftbit、Towify、Thunkable。你要嚴格來講 Excel 都能算是個低代碼工具。總的來說我認為低代碼是提高現(xiàn)有模式的重復創(chuàng)建效率，而不是解決從 0 到 1 的創(chuàng)造效率。

而開發(fā)真正的價值是從 0 到 1 的創(chuàng)造，這就需要專業(yè)的開發(fā)工具 IDE。IDE 是嚴格意義上的工具，也就是程序員用的那把“錘子”。每個人的喜好不同，工種不同對于錘子的要求也會不同。IDE 這個工具非常非常重要，但真正商業(yè)化的特別好的不多，這里有兩個原因，一是開源，二是大公司壟斷。也許是因為 IDE 實在太重要了，如果每個開發(fā)都必須付費才能使用的話，會極大的限制人類的創(chuàng)造力，所以很多產(chǎn)品是開源的，例如 Eclipse，以及它的各種衍生品，還有微軟的 VSCode。還有一些大公司壟斷的產(chǎn)品例如 XCode 也是免費的。獨立的 IDE 廠商目前做的比較好的只有 JetBrains，但也謠傳要被 Google 收購。

做一款好的 IDE 其實門檻非常高，因為是跟程序員打交道最多的產(chǎn)品，各種細節(jié)都必須做到極致才能獲得青睞。可惜的是國內(nèi)到目前為止還沒有出現(xiàn)一款像樣的 IDE 產(chǎn)品。各大云廠商都在做的 WebIDE 產(chǎn)品，都是基于開源的內(nèi)核改的，并沒有什么核心技術，而且本身 WebIDE 這個品類的定位也很尷尬，缺乏場景。IDE 作為創(chuàng)造力的核心，本身工具可以是免費的，只要能使得上下游生態(tài)蓬勃發(fā)展，帶來的收益是更大的，這也是為啥大廠愿意在這里戰(zhàn)略性虧損的原因。說到這里緬懷一下曾經(jīng)的 IDE 工具王者 Borland。

我在做這個 Infra Map 之前從來沒有想過 API Management 會被單獨分為一類。這類產(chǎn)品似乎存在感不強，但是我錯了，只是國內(nèi)用的少，國外有很多產(chǎn)品已經(jīng)很成熟。信息化在國外走的早，生態(tài)又開放，API 已經(jīng)是各個產(chǎn)品的標配用于相互連接。API 多了自然就需要管理，于是出現(xiàn)了 Mulesoft 這樣的產(chǎn)品。很多大公司也都會提供 API 全生命周期的產(chǎn)品例如微軟、Snaplogic、Softwareag、Tibco。這個領域幾乎沒有開源的產(chǎn)品，大概只有大公司才會用到這樣的產(chǎn)品，容易收錢。我們相信 API 的重要性會越來越大，數(shù)字世界越來越豐富，溝通和交流依賴 API。

開發(fā)這里的最后一個分類是 Resource Hub。為什么會有這個單獨的分類呢？因為 GitHub。我們到底是把 GitHub 看成工具，社區(qū)，還是資源？雖然 GitHub 有工具屬性，但在企業(yè)級應用上 GitLab 更勝一籌。但是在開源社區(qū)和開發(fā)者影響力上 GitHub 無人出其右。創(chuàng)造的過程免不了借鑒，Resource Hub 就是各種被借鑒的資源。除了代碼以外，還有 Postman、RapidAPI 等提供的 API Hub。Stackshare 提供了可以借鑒的應用架構(gòu)。

保駕護航的 Quality 領域

如何保障軟件產(chǎn)品的質(zhì)量是一個頭疼的問題，我們可以依賴自動化的檢測工具也可以依賴人工的測試。首先我們來看 Test Harness，也就是測試工具。這是一個很大的分類，絕大多數(shù)質(zhì)量保障的投入都放在了這個領域。令我震驚的是國外在測試工具的投入上真的是下血本，難怪老外的產(chǎn)品質(zhì)量好，而國內(nèi)基本靠人。測試工具有很多細分，比如一些相對比較成熟的領域：

測試工具這里有一個趨勢是 AI 化，包括通過歷史測試數(shù)據(jù)來生成新的測試代碼，或者通過視覺分析來測試 UI，比如 Test.ai、Functionize、Accelq、Applitools 等等。在看這領域的時候確實是超出我想象的，感覺像是挖到了寶藏。我沒有想到老外在測試工具上已經(jīng)走的如此超前了，這些工具的場景都很清晰，而且商業(yè)化的也都不錯。

除了測試工具以外，測試管理也很重要。顧名思義測試管理就是把測試用例，測試計劃，測試結(jié)果等等管理起來，形成結(jié)構(gòu)化數(shù)據(jù)，輸出報表等等，比如 TestRail、Qmetry Tricentis 等等，管理類的工具相對少一些。這里比較有意思的一家公司叫做 Sealight，引入了更數(shù)據(jù)化上下游打通的測試管理理念，值得學習。

有了工具，有了管理，那剩下的就是人了。迄今為止測試依然是一個少不了人工參與的工作，所以有一些測試服務公司承接測試的外包工作，也可能是以眾包的方式來完成，例如 Testlio、 Globalapptesting、Applause。

Delivery 的演變

軟件的交付包含兩部分，倉儲還有交付。過去我們對于可以交付的軟件的倉儲是比較隨意的，基本都是直接放在文件系統(tǒng)中。隨著軟件工程的深入，我們發(fā)現(xiàn)軟件的存儲也是挺講究的，包括權限、安全掃描、跨網(wǎng)傳輸?shù)鹊?。所以產(chǎn)生了 Artifactory 這個品類，典型代表 JFrog，還有開源的 Nexus。這個領域門檻不高，可替代的方案也比較多，所以沒有太多公司在這里深耕。唯一一家上市公司 JFrog 市值也不高。

最早軟件的交付都是通過物理介質(zhì)傳遞的，80 后可能都有過購買軟件光盤的經(jīng)歷。隨著 BS 應用的興起，軟件的分發(fā)互聯(lián)網(wǎng)化了，軟件的交付就變成了更新服務器上的代碼就行了。所以有了持續(xù)交付的概念 Continuous Delivery。幾乎所有的互聯(lián)網(wǎng)，移動互聯(lián)網(wǎng)應用都會涉及到持續(xù)發(fā)布的問題，所以這個領域產(chǎn)生了很多商業(yè)工具比如 Ansible。過去應用的架構(gòu)五花八門，所以交付工具也是五花八門，很多團隊都是自己造的發(fā)布工具。隨著云、微服務和 DevOps 的興起，應用的架構(gòu)開始趨同，交付工具也就有了統(tǒng)一的可能，又產(chǎn)生了很多新興的發(fā)布工具例如 Harness、Octopus。還有一些工具專注灰度發(fā)布的能力，例如 Launchdarkly。

愈發(fā)重要的 Telemetry

可觀測性其實一直都有，只是過去沒有那么重要，因為大多單體應用或者客戶端應用，架構(gòu)簡單，出問題容易排查。最直觀的可觀測性工具就是 Windows 的任務管理器，你可以看到正在運行的軟件分別消耗了多少 CPU 和內(nèi)存，系統(tǒng)卡的話你把消耗大的那個進程干掉就好了。只是在云時代，微服務架構(gòu)使得軟件變得十分復雜，一個問題牽扯 N 個微服務可能涉及 N 臺服務器，找問題就變得很困難，所以可觀測性顯得尤其重要，這個領域產(chǎn)生了非常多的優(yōu)秀商業(yè)軟件，比如 Datadog。

可觀測性包含幾個元素，監(jiān)控、日志、報警、追蹤。其中只有日志是有單獨商業(yè)工具的，例如 Logdna、Loggly，其他基本都是集成在一個工具中。這個領域過去基本都是自己用開源的自己搭，Prometheus、Grafana、Logstash、Skywalking，但是想把這些產(chǎn)品真正融合好是非常不容易的，這里涉及到海量數(shù)據(jù)的處理。所以在 Observerbility 這個領域有非常多的商業(yè)公司，除了 Datadog 以外，還有 NewRelic、Overops、LightStep 等等。所有這些工具的目的只有一個——幫助你在出問題的時候快速定位到問題。

定位到問題還不夠，最好可以全自動解決問題，這就是 AIOps。雖然我認為讓機器做操作很危險，但這個領域也有不少做的很大的商業(yè)公司，例如 BigPanda、Moogsoft、Dynatrace。總的來說可觀測性是一個很有前景的市場，軟件吞噬世界，如果軟件不可控后果不堪設想。

重中之重——Security

寫了這么多，終于來到了最后一塊，安全。傳統(tǒng)意義上安全往往指運行時安全，因為這里才是存放生產(chǎn)數(shù)據(jù)，跟客戶打交道的地方，所以企業(yè)會投重金保證生產(chǎn)系統(tǒng)的運行安全，包括防火墻、進程監(jiān)控等等。這個領域挺成熟的工具也很多，例如 Illumio、 Contrastsecurity、Rapid7、Sysdig 等等。這些工具從各種方面來保障應用的安全，包括網(wǎng)絡、容器、云主機等等。這塊的安全傳統(tǒng)意義上是“運維”關注的。

另外一塊開發(fā)安全最近受到的關注越來越多，解決的是軟件開發(fā)相關的安全。基本上可以分為幾類，靜態(tài)安全（SAST）、動態(tài)安全（DAST）、軟件成分分析（SCA）、交互式安全（IAST），以及運行時應用防護（RASP）。由于廠商一般不會只做一種類型的安全產(chǎn)品，往往會橫跨幾個，我就不分開列了。這里老牌的廠商比如 Checkmarx、Fortify、Synopsys、Blackduck 也有一些新晉明星 Snyk、Stackhawk、Anchore 等等。安全產(chǎn)品要做出核心競爭力門檻挺高的，如果只是依賴公開的漏洞庫搞搞掃描就太同質(zhì)化了，所以好的安全產(chǎn)品必須是在性能、易用性、有效性，甚至獨有的分析能力等等方面做出亮點。

還有一類安全叫做“軟件供應鏈安全”。雖然供應鏈安全最近被頻繁提起，并且也當一個框使用，什么都往里裝。但我認為嚴格意義上的供應鏈安全是有別于上述兩種安全的。供應鏈安全核心解決的是可信的問題，也就是確保軟件沒有被篡改。而運行時安全和開發(fā)安全解決的是 Bug 和漏洞的問題。當然也可以把供應鏈安全歸屬為開發(fā)安全的一部分，畢竟也是開發(fā)過程中的事情。

還有一塊叫做安全管理，類似于測試管理，這個品類的產(chǎn)品不多，主要解決的是一些審計、合規(guī)管理、風險管理、風險評估的問題，例如 Apptega、Upguard。

一站式工具 vs 單點工具

看了那么多工具，我們發(fā)現(xiàn)老外其實很卷，但凡有點肉的賽道都有一堆人在里面擠。好在國外市場大，畢竟是全球市場，多幾家更有利于市場繁榮，有利于創(chuàng)新。而國內(nèi)在 Infra 這個大賽道投入其實是不夠的。上面講的這些工具，每一個分類多少都有國內(nèi)對標，但無論是數(shù)量還是質(zhì)量都差距巨大，具體有哪些我就就不列了，共勉。

那國內(nèi)那么多 ToB 的廠商的程序員天天加班在干嘛呢？老外在造輪子，我們在包輪子。國內(nèi)的公司喜歡自研。到目前為止絕大部分公司的產(chǎn)研團隊所使用的的工具都是自建的，典型的就是 GitLab Jenkins 開源的搭一搭，再弄個破解的 Jira Confluence，好一點的自己造個控制臺，魔改一下開源工具，使得這些工具看起來是“一站式的”。這種美其名曰“自研”的實踐一方面浪費了巨量的工程人力，你想象一下，每個團隊都要投那么些人力去搭建這套東西，全中國有多少這樣的團隊。另外一方面使得國內(nèi)的商業(yè)工具市場十分慘淡，更沒人做，惡性循環(huán)。

“一站式”是國內(nèi)特別喜歡提的一個概念（老外的產(chǎn)品似乎只有 GitLab 在一直強調(diào) All in One），大概是中國人喜歡一條龍。我們也是主打一站式概念的，但是我們越來越感覺到想要做全是不可能的。這么多細分的領域，每個領域都有上市公司的情況下，怎么可能一個公司全做完呢？所以一站式到最后一定走向開放平臺，這也是我們的發(fā)展方向。說實話，一站式是沒有太多技術創(chuàng)新的，基本都是管理方面的演進，而管理又是非標的重災區(qū)，并不是一個好生意。市場上的一站式產(chǎn)品不應該很多，有幾個就足夠了。而單點工具是應該要百花齊放的，在每個細分領域做精做細，這里可以萌發(fā)創(chuàng)新。

在制作 Infra Map 的過程中，對這個領域的發(fā)現(xiàn)確實是突破了我們現(xiàn)有的認知。國外在這個行業(yè)上的投入是巨大的，一直以來國內(nèi)的團隊其實都在享受國外的研發(fā)成果，從 PC 時代到互聯(lián)網(wǎng)時代都是如此。欣慰的是我們看到在當前的云原生時代，國內(nèi)的 Infra 團隊開始興起。研究歷史才能洞悉未來，希望我們的一點貢獻能否幫助到更多國內(nèi)的團隊。要相信工具會隨著生產(chǎn)力的提升不斷變化，永遠有機會。

END

《新程序員001-004》全面上市，對話世界級大師，報道中國IT行業(yè)創(chuàng)新創(chuàng)造

成就一億技術人