万字分析全球 1000 款 DevOps 工具，中国开发工具究竟缺什么？

【导言】DevOps 概念发展的多年间，直至近几年才真正开始普及起来。本文将围绕 DevOps 工具和工程两大维度探究软件工程格局。在分析了国内外近 1000 个工具后，我们发现了以下亮点内容：

1. DevOps 工具可以抽象为以下几个大类：Design、Develop、Quality、Delivery、Telemetry、Security、Runtime、Middleware；

2. Runtime 的产品不多，但是数量级的工程效能提升往往是 Runtime 发生了变化；

3. Middleware 是个大赛道，数据库是重中之重；

4. UI 设计工具很繁荣，商业化也很好，发展趋势是跟低代码结合；

5. 开发领域的工具纷繁复杂，面对开源和大公司的挑战最多。项目管理类是商业化最好的细分领域；

6. 国外在质量工具的投入巨大，产品丰富且出色，国内几乎为零；

7. 互联网和云原生催生了持续交付的发展；

8. 可观测性重要性越来越高，AIOps 是发展方向，商业化也很成功；

9. 除了运行时安全以外，开发安全越来越受到关注，软件供应链方面也值得重视；

10. 一站式工具一定会走向开放拥抱单点工具；

11. PC 时代和互联网时代工具都是国外的，云原生时代国内的 Infra 团队有机会。

作者 | Hailong Zhang

来源 | 捡起来公众号（已获授权）

给 DevOps 下个定义

大概从 2019 年开始，DevOps 这个词语在软件工程领域出现的频率越来越高，虽然这个概念十几年前就有了，但是确实最近几年才开始真正普及，国内外均如此。在三年前，你说 DevOps，大多数人指的是 CI/CD，两年前开始有一站式的概念，DevOps 包含了从项目管理开始的一整套，而最近又开始提 DevSecOps，DevBizOps，层出不穷。现在很少有人在纠结 DevOps 这个概念了，严格意义上 DevOps 是指让开发可以干运维的工作，但实际应用中这个词语大体可以理解为现代化的软件工具和工程方法。

工具和工程是两个维度的东西，我们讲敏捷开发，瀑布开发是一种工程方法论，跟实际使用的工具无关，你用 Excel 也可以实现敏捷。但实践中，特定的工程方法论往往依赖一些特定的工具，比如敏捷依赖看板。从我们的观察来看，目前各行各业的软件开发团队使用的工程方法论依然有很大的不一样，有敏捷的，瀑布的，双轮驱动的，还有中国式敏捷等等，但是使用的工具正在逐步趋同，普遍都在往新的生产力工具上迁移。

我们对国内外近 1000 个工具做了一些研究和分析，有一些总结记录下来跟大家分享。值得一提的是这些工具的涵盖范围包含了整个软件的基础设施 Infra，而不仅仅是 DevOps。

Infra 工具地图

市面上的工具五花八门，我们需要寻找一个维度来对工具进行抽象的分类，合并同类项才能更好的理解这个行业和市场。抽象的维度有很多，比如可以根据面向客户的规模分会显的太粗，按照工具的类型分会显的太细。最后我们决定根据软件工程的阶段和层次来分，制作了下面这张地图。

这个分类的逻辑是：

1. 最底下是云，包括 AWS、腾讯云、阿里云等等，还有一些跟资源相关的产品，比如 ServiceNow、CloudFlare 等等。

2. 最上面是软件设计相关，包括 UI 设计和需求设计，也就是软件看得见的部分，比如 Figma、Adobe 等等。

3. 中间部分是真正构建软件的部分，首先是软件的开发，质检，交付，这是所有生产必不可少的三个步骤，这里包含了日常开发者打交道最多的 IDE、代码管理、需求管理、CI/CD、自动化测试等等。

4. Runtime 和 Middleware 是每个软件都依赖的部分，可以理解为软件的底座，比如容器、数据库、编程语言 SDK 等等。

5. 最右边是 Telemetry 和 Security，这两块是保证软件正常运行必不可少的，比如监控日志报警、安全扫描、入侵检测等等。

这里每个色块的大小代表了我们认为目前这个领域的市场空间，我们相信这里的面积会随着行业的发展而变化。这样的分类基本涵盖了软件工程的所有方面，当然一个产品可能会跨多个色块，特别是平台类产品。很多新产品的边界很模糊，比如一个类 Serverless 产品，同时会提供 IDE 和部分中间件。但也有一些产品是非常专注在某一个具体的领域，比如基于 AI 的 UI 自动化测试。这里会涉及到一个经常被提及的问题：一站式工具和单点工具最终会是什么关系？我们将在文章的最后部分来讨论。

我们在制作这个地图的时候，深深的意识到中国跟美国相比，在这个领域的差距真的是令人汗颜，国产化“信创”路漫漫啊。

Runtime

我们跳过最下面的 Cloud 部分，因为云这部分跟大多数公司没有关系，这个底层基础设施类似于电信运营商，注定只能是少数大公司的生意。我们先来看 Runtime 这个部分。

目前专注于做 Runtime Container（我这里用 container 是泛指运行程序的程序，serverless 也算 container 的一种）的产品不算多，跟整个技术体系的发展阶段有关。事实上数量级的工程效能提升往往是 Runtime 发生了变化，例如 Java 当年带来的变革，还有最近容器化带来的变革。下一个可以预见的 Runtime 变革是 Serverless。虽然 Serverless 已经存在了很多年，但发展的并不好，究其原因是因为程序结构和新的运行环境不匹配，所以我认为 Serverless 要能发展起来，必须是从程序结构开始的变革。目前有一些公司在这个方向上努力，例如 Netlify、Platform9，以及新晋创业公司 Inngest、Koyeb。这里的新东西都比较小众，因为适用面有限，解决了极致的效率，但不能解决规模化应用的问题。

另外一类是相对兼容现有的应用结构，提供更好的工具来帮助开发管理运行环境，Runtime Management 典型的比如 k8s、Terraform，也有一些做的很大的创业公司，例如 Pulumi.com。我们可以把这类产品都看成是新时代的 Ansible。这个领域的产品挺多的，而且不断的有新产品冒出来，是对目前的云一个很好的补充。

Middleware 中间件

说实话，在我从业生涯早期的很多年一直不理解什么叫做 Middleware 中间件，虽然我的第一份正式工作是在 Oracle 的中间件部门。这种概念在不同的时期往往有不同的涵义，最早中间件可能是指 JBoss、Tomcat 这类服务器软件，后来又包含了消息队列 EJB 之类的。我认为比较好的理解中间件的概念是：所有非程序本身，又是程序运行所必不可少的软件，例如数据库，缓存，队列，网关等等。中间件是云厂商可以直接提供给你的，但程序你必须自己写。

中间件五花八门，这里有非常多的上市公司，创业公司，是个超级大赛道。我看了一下基本可以分成 Database 和 Others，因为数据库真的是中间件皇冠上的明珠，太靓眼了。这里的 Database 不一定是传统意义上的数据库，跟数据存储和处理相关的都算，例如 Snowflake。其他还有比如 MongoDB、Influxdata、Netapp、Qumulo 等等太多了，都做的很大。

Others 里面相对就小很多，但是品类很多，例如对象存储 MinIO、服务网格 Solo.io、消息队列 Redpanda、API 网关 Kong 等等。

Design 环节：需求设计和 UI 设计

软件工程其实有很多理念都是从传统制造业借鉴的。本质都是在生产东西，一个是实物，一个是虚拟，但是在流程和管理上有很多可以借鉴的地方。所有的生产无非是设计，制造，质检，交付。我们先来看设计环节。

软件的设计分为需求设计和 UI 设计（当然也有架构设计，数据库设计等等，这一类我们认为属于开发环节）。这里的需求需要跟传统的项目管理软件比如 Jira 中的需求区分开。Jira 中的需求可以认为是已经确定要做的，进入开发流水线的。而事实上业务运行过程中有很多需求是不确定的，可能来源于 IM，邮件，口头等等，这些需求需要经过产品经理的充分评估和完善才能进入开发环节，这些需求也缺乏结构化的整理和更新例如 Roadmap 等等。所以我们可以把这里的需求设计理解为产研跟业务对接的地方。关注这个领域的产品真的不多，可能是痛点不够明显，或者通过别的工具替代了，例如文档、Excel、Jira 等等，虽然不完美但也不够痛。有一些产品做得还不错比如 Aha.io、Accompa、Productboard 等等。

而 UI 设计就有相当相当多的工具，老牌的比如 Adobe 系列，新晋明星 Figma 等等。这个领域有非常多的细分，比如产品原型设计 Mockflow、Proto.io，快速 UI 设计 Framer、Webflow，还有通用的线框工具 Miro、Lucidchart 等等。这里的发展趋势逐步的跟低代码在结合，最终可能发展为设计即代码的状态。所有这些工具确实拉低了下限，让更多的人可以上手，但真正专业的设计师还是需要能掌控细节的工具，所以 Figma 这类工具在专业群体更受欢迎。

最为复杂的 Develop 领域

开发占了整个地图中最大的一块区域，这个领域东西最多最杂，毕竟这是跟人打交道最多的地方。这里面最大的一块叫做 Project Management，包括了需求管理，Bug 管理，进度管理，度量等等，研发出了 Jira、Asana 这样的产品，都是很大的上市公司。这个领域也不断的有新产品出现比如 Rocketlane, Code Climate，但都比较垂直。值得一提的是有很多团队会用更通用的管理工具来实现同样的目的，例如 Trello，Monday，甚至 Airtable。管理是一个非常多样化的需求，所以这个领域百花齐放。我们观察到中美在这个领域的需求差异极大，国外的需求更偏向个体效率，而国内的需求更偏向于管理效率。从全球来看我们并没有看到什么产品能够挑战 Jira，基本上 Jira 的插件能力能满足绝大多数的场景需求，但国内 Jira 受到非常大的挑战，不仅仅是因为国外产品政策的原因，在贴近用户“管理”需求上，确实国外产品做的不够，例如对糅杂了瀑布模式的中国式敏捷的支持，还有对业务需求的管理等等。

开发这里的第二大领域是 Pipeline，俗称流水线，这也是从制造业借鉴过来的。这里的 Pipeline 是泛指写完代码以后所涉及到的工具，而不仅仅是 Jenkins 这样的 CI。这里的典型代表是 Gitlab，它的两个主打产品就是代码仓库和 CI，占据了 Pipeline 里面的绝大部分位置。这个领域特别繁杂，但商业化做的好的不多，绝大多数是小工具，甚至是开源工具。在这个领域做产品将面对开源最大的挑战，因为程序员喜欢在这里造轮子。Pipeline 上可以集成各种单点的工具，例如代码扫描 Sonar、代码审查 Codacy、代码搜索 Sourcegraph。还有一些更垂直的专注某个类型应用的工具，例如移动端构建 Bitrise、移动端开发 Ionic、服务器端镜像构建 Packer。

我们来说说低代码。我其实是不太相信低代码这个故事的，详细的分析可以看《低代码开发会是未来吗？》。但无论如何，在某些垂直场景下业务功能的模块化低代码确实是有价值的。事实上我们看做的好的低代码产品也往往都是垂直场景的。老牌的低代码产品比如 Mendix、Outsystems 等等。Oracle、微软、Salesforce 等等大厂也都有自己的低代码产品。另外的低代码产品大致可以分为两类，一类是流程自动化，例如 Appian、Tray、Creatio。另外一类是快速开发工具，例如 Draftbit、Towify、Thunkable。你要严格来讲 Excel 都能算是个低代码工具。总的来说我认为低代码是提高现有模式的重复创建效率，而不是解决从 0 到 1 的创造效率。

而开发真正的价值是从 0 到 1 的创造，这就需要专业的开发工具 IDE。IDE 是严格意义上的工具，也就是程序员用的那把“锤子”。每个人的喜好不同，工种不同对于锤子的要求也会不同。IDE 这个工具非常非常重要，但真正商业化的特别好的不多，这里有两个原因，一是开源，二是大公司垄断。也许是因为 IDE 实在太重要了，如果每个开发都必须付费才能使用的话，会极大的限制人类的创造力，所以很多产品是开源的，例如 Eclipse，以及它的各种衍生品，还有微软的 VSCode。还有一些大公司垄断的产品例如 XCode 也是免费的。独立的 IDE 厂商目前做的比较好的只有 JetBrains，但也谣传要被 Google 收购。

做一款好的 IDE 其实门槛非常高，因为是跟程序员打交道最多的产品，各种细节都必须做到极致才能获得青睐。可惜的是国内到目前为止还没有出现一款像样的 IDE 产品。各大云厂商都在做的 WebIDE 产品，都是基于开源的内核改的，并没有什么核心技术，而且本身 WebIDE 这个品类的定位也很尴尬，缺乏场景。IDE 作为创造力的核心，本身工具可以是免费的，只要能使得上下游生态蓬勃发展，带来的收益是更大的，这也是为啥大厂愿意在这里战略性亏损的原因。说到这里缅怀一下曾经的 IDE 工具王者 Borland。

我在做这个 Infra Map 之前从来没有想过 API Management 会被单独分为一类。这类产品似乎存在感不强，但是我错了，只是国内用的少，国外有很多产品已经很成熟。信息化在国外走的早，生态又开放，API 已经是各个产品的标配用于相互连接。API 多了自然就需要管理，于是出现了 Mulesoft 这样的产品。很多大公司也都会提供 API 全生命周期的产品例如微软、Snaplogic、Softwareag、Tibco。这个领域几乎没有开源的产品，大概只有大公司才会用到这样的产品，容易收钱。我们相信 API 的重要性会越来越大，数字世界越来越丰富，沟通和交流依赖 API。

开发这里的最后一个分类是 Resource Hub。为什么会有这个单独的分类呢？因为 GitHub。我们到底是把 GitHub 看成工具，社区，还是资源？虽然 GitHub 有工具属性，但在企业级应用上 GitLab 更胜一筹。但是在开源社区和开发者影响力上 GitHub 无人出其右。创造的过程免不了借鉴，Resource Hub 就是各种被借鉴的资源。除了代码以外，还有 Postman、RapidAPI 等提供的 API Hub。Stackshare 提供了可以借鉴的应用架构。

保驾护航的 Quality 领域

如何保障软件产品的质量是一个头疼的问题，我们可以依赖自动化的检测工具也可以依赖人工的测试。首先我们来看 Test Harness，也就是测试工具。这是一个很大的分类，绝大多数质量保障的投入都放在了这个领域。令我震惊的是国外在测试工具的投入上真的是下血本，难怪老外的产品质量好，而国内基本靠人。测试工具有很多细分，比如一些相对比较成熟的领域：

测试工具这里有一个趋势是 AI 化，包括通过历史测试数据来生成新的测试代码，或者通过视觉分析来测试 UI，比如 Test.ai、Functionize、Accelq、Applitools 等等。在看这领域的时候确实是超出我想象的，感觉像是挖到了宝藏。我没有想到老外在测试工具上已经走的如此超前了，这些工具的场景都很清晰，而且商业化的也都不错。

除了测试工具以外，测试管理也很重要。顾名思义测试管理就是把测试用例，测试计划，测试结果等等管理起来，形成结构化数据，输出报表等等，比如 TestRail、Qmetry Tricentis 等等，管理类的工具相对少一些。这里比较有意思的一家公司叫做 Sealight，引入了更数据化上下游打通的测试管理理念，值得学习。

有了工具，有了管理，那剩下的就是人了。迄今为止测试依然是一个少不了人工参与的工作，所以有一些测试服务公司承接测试的外包工作，也可能是以众包的方式来完成，例如 Testlio、 Globalapptesting、Applause。

Delivery 的演变

软件的交付包含两部分，仓储还有交付。过去我们对于可以交付的软件的仓储是比较随意的，基本都是直接放在文件系统中。随着软件工程的深入，我们发现软件的存储也是挺讲究的，包括权限、安全扫描、跨网传输等等。所以产生了 Artifactory 这个品类，典型代表 JFrog，还有开源的 Nexus。这个领域门槛不高，可替代的方案也比较多，所以没有太多公司在这里深耕。唯一一家上市公司 JFrog 市值也不高。

最早软件的交付都是通过物理介质传递的，80 后可能都有过购买软件光盘的经历。随着 BS 应用的兴起，软件的分发互联网化了，软件的交付就变成了更新服务器上的代码就行了。所以有了持续交付的概念 Continuous Delivery。几乎所有的互联网，移动互联网应用都会涉及到持续发布的问题，所以这个领域产生了很多商业工具比如 Ansible。过去应用的架构五花八门，所以交付工具也是五花八门，很多团队都是自己造的发布工具。随着云、微服务和 DevOps 的兴起，应用的架构开始趋同，交付工具也就有了统一的可能，又产生了很多新兴的发布工具例如 Harness、Octopus。还有一些工具专注灰度发布的能力，例如 Launchdarkly。

愈发重要的 Telemetry

可观测性其实一直都有，只是过去没有那么重要，因为大多单体应用或者客户端应用，架构简单，出问题容易排查。最直观的可观测性工具就是 Windows 的任务管理器，你可以看到正在运行的软件分别消耗了多少 CPU 和内存，系统卡的话你把消耗大的那个进程干掉就好了。只是在云时代，微服务架构使得软件变得十分复杂，一个问题牵扯 N 个微服务可能涉及 N 台服务器，找问题就变得很困难，所以可观测性显得尤其重要，这个领域产生了非常多的优秀商业软件，比如 Datadog。

可观测性包含几个元素，监控、日志、报警、追踪。其中只有日志是有单独商业工具的，例如 Logdna、Loggly，其他基本都是集成在一个工具中。这个领域过去基本都是自己用开源的自己搭，Prometheus、Grafana、Logstash、Skywalking，但是想把这些产品真正融合好是非常不容易的，这里涉及到海量数据的处理。所以在 Observerbility 这个领域有非常多的商业公司，除了 Datadog 以外，还有 NewRelic、Overops、LightStep 等等。所有这些工具的目的只有一个——帮助你在出问题的时候快速定位到问题。

定位到问题还不够，最好可以全自动解决问题，这就是 AIOps。虽然我认为让机器做操作很危险，但这个领域也有不少做的很大的商业公司，例如 BigPanda、Moogsoft、Dynatrace。总的来说可观测性是一个很有前景的市场，软件吞噬世界，如果软件不可控后果不堪设想。

重中之重——Security

写了这么多，终于来到了最后一块，安全。传统意义上安全往往指运行时安全，因为这里才是存放生产数据，跟客户打交道的地方，所以企业会投重金保证生产系统的运行安全，包括防火墙、进程监控等等。这个领域挺成熟的工具也很多，例如 Illumio、 Contrastsecurity、Rapid7、Sysdig 等等。这些工具从各种方面来保障应用的安全，包括网络、容器、云主机等等。这块的安全传统意义上是“运维”关注的。

另外一块开发安全最近受到的关注越来越多，解决的是软件开发相关的安全。基本上可以分为几类，静态安全（SAST）、动态安全（DAST）、软件成分分析（SCA）、交互式安全（IAST），以及运行时应用防护（RASP）。由于厂商一般不会只做一种类型的安全产品，往往会横跨几个，我就不分开列了。这里老牌的厂商比如 Checkmarx、Fortify、Synopsys、Blackduck 也有一些新晋明星 Snyk、Stackhawk、Anchore 等等。安全产品要做出核心竞争力门槛挺高的，如果只是依赖公开的漏洞库搞搞扫描就太同质化了，所以好的安全产品必须是在性能、易用性、有效性，甚至独有的分析能力等等方面做出亮点。

还有一类安全叫做“软件供应链安全”。虽然供应链安全最近被频繁提起，并且也当一个框使用，什么都往里装。但我认为严格意义上的供应链安全是有别于上述两种安全的。供应链安全核心解决的是可信的问题，也就是确保软件没有被篡改。而运行时安全和开发安全解决的是 Bug 和漏洞的问题。当然也可以把供应链安全归属为开发安全的一部分，毕竟也是开发过程中的事情。

还有一块叫做安全管理，类似于测试管理，这个品类的产品不多，主要解决的是一些审计、合规管理、风险管理、风险评估的问题，例如 Apptega、Upguard。

一站式工具 vs 单点工具

看了那么多工具，我们发现老外其实很卷，但凡有点肉的赛道都有一堆人在里面挤。好在国外市场大，毕竟是全球市场，多几家更有利于市场繁荣，有利于创新。而国内在 Infra 这个大赛道投入其实是不够的。上面讲的这些工具，每一个分类多少都有国内对标，但无论是数量还是质量都差距巨大，具体有哪些我就就不列了，共勉。

那国内那么多 ToB 的厂商的程序员天天加班在干嘛呢？老外在造轮子，我们在包轮子。国内的公司喜欢自研。到目前为止绝大部分公司的产研团队所使用的的工具都是自建的，典型的就是 GitLab Jenkins 开源的搭一搭，再弄个破解的 Jira Confluence，好一点的自己造个控制台，魔改一下开源工具，使得这些工具看起来是“一站式的”。这种美其名曰“自研”的实践一方面浪费了巨量的工程人力，你想象一下，每个团队都要投那么些人力去搭建这套东西，全中国有多少这样的团队。另外一方面使得国内的商业工具市场十分惨淡，更没人做，恶性循环。

“一站式”是国内特别喜欢提的一个概念（老外的产品似乎只有 GitLab 在一直强调 All in One），大概是中国人喜欢一条龙。我们也是主打一站式概念的，但是我们越来越感觉到想要做全是不可能的。这么多细分的领域，每个领域都有上市公司的情况下，怎么可能一个公司全做完呢？所以一站式到最后一定走向开放平台，这也是我们的发展方向。说实话，一站式是没有太多技术创新的，基本都是管理方面的演进，而管理又是非标的重灾区，并不是一个好生意。市场上的一站式产品不应该很多，有几个就足够了。而单点工具是应该要百花齐放的，在每个细分领域做精做细，这里可以萌发创新。

在制作 Infra Map 的过程中，对这个领域的发现确实是突破了我们现有的认知。国外在这个行业上的投入是巨大的，一直以来国内的团队其实都在享受国外的研发成果，从 PC 时代到互联网时代都是如此。欣慰的是我们看到在当前的云原生时代，国内的 Infra 团队开始兴起。研究历史才能洞悉未来，希望我们的一点贡献能否帮助到更多国内的团队。要相信工具会随着生产力的提升不断变化，永远有机会。

END

《》全面上市，对话世界级大师，报道中国IT行业创新创造

— 推荐阅读 —

—点这里↓↓↓记得关注标星哦~— 

一键三连 「分享」「点赞」「在看」

成就一亿技术人