当下越来越多的研发团队开始践行 DevOps，一边扛着业务 KPI，一边研发/上线/运维一条龙。这背后有两个主要的推手：

1. 首先是底层基础设施的日趋完善，像云厂商提供的 IaaS，文件存储，数据库还有围绕 Kubernetes 的云原生操作系统。
2. 其次是配套的相关 DevOps 开源工具，帮助研发团队能快速攒出一套工具集，承担部署，运维，数据库操作这些之前需要专业运维/SRE/DBA 才能承担的工作。

同时当下开源社区百花齐放，DevOps 团队在选择工具时也难免陷入眼花缭乱的选择障碍。本文尝试整理一套研发工具集，帮助 DevOps 团队搭建起一套最基本的研发工具体系。几点声明：

• 只谈「开源」产品。
• 只谈「工具」。像底层基础设施，比如开源数据库，分布式文件系统这些不在覆盖之列。
• 只谈 DevOps 团队「专用」。像项管软件，IM 这类其他工种也会使用的工具，不在覆盖之列。

• 只谈「基础」，这里的「基础」有两个含义：

  • 覆盖的是研发刚需场景，像研发效能度量这样的进阶工具不在覆盖之列。
  • 推荐的工具集合能让团队达到 75 分水位，如果有更高的追求，还是要结合团队情况做相应的调整。

    行业标杆

    这个大类下的工具算是业界共识，通常大家都会选。一个简单的评判标准，如果团队里有成员提议其他的产品，则需要费不少功夫解释为什么不选下面列表里的。

    代码托管/持续集成

    GitLab 或者 GitHub。这两者难分伯仲，之前私有化部署 (OP) 领域更多会选择 GitLab，但越来越多的团队现在直接使用 GitHub.com 的 private 仓库。随着 GitLab CI, GitHub Action 的日趋完善，团队也不再需要单独的持续集成 CI 工具了。

    代码搜索

    Sourcegraph。虽然 GitLab / GitHub 本身是以代码托管起家，也都提供代码搜索能力，但是他们的能力远远比不上专做代码搜索的 Sourcegraph。可能许多工程师没有意识到好的代码搜索能带来的效率提升，就像 Uber, Databricks 这些公司里的工程师一开始也没有意识到，直到他们用上。
    

    基础设施部署

    Terraform。虽然也有 Pulumi 这样的后起之秀，但 Terraform 结合 GitLab / GitHub 的 Infra-as-Code 已经形成了完整的生态。尤其对于没有历史包袱的团队来说，Terraform 是管理云资源的不二之选。

    监控&日志&仪表盘

    Prometheus + ELK + Grafana。标准三件套，当然国内美团开源的 CAT 以及源自滴滴的夜莺也值得一看。

    等待标杆

    这个大类下的工具选型还没有形成业界共识，通常大家在选型时会拿捏不准，也更有自研倾向。

    微服务部署

    Zadig
    当初看到 Zadig 的时候，心中也有疑问，因为市面上 CI / CD 工具已经很多了，而且 GitLab / GitHub 也都内置了 CI 能力，这个领域还有足够的空间么。后来通过阅读 Zadig 的文档，才理解到了他的价值点。一方面还是业务发展/复杂度的几何式上升，另一方面是云原生，微服务，Kubernetes 这套新体系的出现，叠加在一起就催生了新的场景。要让 DevOps 团队每天能在不同的环境上部署好多次，每次部署成百上千的容器/微服务，本来的那些 CI / CD 工具还是有点力不从心的。
    

    配置管理 / Feature Flag

• Apollo

• Unleash
• Flagsmith

如果要做部署 (Deploy) 和 Release (发布）的分离，以及其他一些动态配置，A / B 测试能力，就需要这个服务，而这些能力是有一定规模的在线应用都需要的。在国内，起源于携程的 Apollo 占据着统治地位，虽然他是一个配置管理服务，但不少团队也基于他做了 Feature Flag 的解决方案。

单说 Feature Flag 这块，整个业内还没有约定俗成的方案。GitLab 提供的 Feature Flag 是基于 Unleash，而 Flagsmith 则是最近势头较猛的产品。

从产品能力上来说，整个业界 Apollo 最完善，如果能在产品化上更进一步，是有希望推向全球的。

定时任务调度

DolphinScheduler
各种巡检，日常备份，定时推送都依赖于定时任务。当前的定时任务功能往往是作为一个子模块出现在其他产品中，而定时任务背后还有一个工作流引擎，这两者也成为重复造轮子的重灾区。这块 DolphinScheduler 是目前领先的方案，来自于国内的易观。和 Apollo 类似，国外暂时也没有看到特别好的方案。不过在工作流引擎层面国外已经出现了源于 Uber 的 Temporal，虽然目前暂时还没有看到工具层的通用方案，想必出现只是时间的问题。

数据库开发

Bytebase
数据库开发同样是研发流程上的刚需场景，但因为操作本身的复杂度和危险性，一直以来都需要 DBA 团队介入 (如果没有 DBA 的话，研发就只能硬着头皮裸奔操作，等着删库跑路了)。国外 DevOps 团队也有使用 Flyway, Liquibase，但因为这两者没有友好的操作界面，所以流行度有限，国内使用者更少。Bytebase 是这个领域的破局者，创始团队来自 Google，基于 Google 内部的 DevOps 数据库开发实践。产品设计贴合研发工程师习惯，其中有类似 Project 的概念，和代码仓库原生集成，再通过一系列可视化交互，SQL 自动审核规则等大大降低研发团队进行数据库开发的门槛。希望让更多的 DevOps 团队能像 Google 的研发团队一样，不需要 DBA 就能完成数据库开发工作。

有心的读者可能发现，在「行业标杆」里所列的开源工具基本都来自国外公司，但「等待标杆」这里的开源工具基本又来自国内公司。我们虽然无法解释为何国外同行一直没动静，但随着这两年国内团队研发水平的提升，各种业务又一直倒逼，自然就催生了国内团队去主动填补这些业界空白，而且更可喜的是，大家是有意识地用产品化方式去做。

总结

「工欲善其事，必先利其器」，这句话也表达了工具是产出业务成果的必要条件，但不是充分条件。选择走 DevOps 路线的技术团队，一方面要重视工具的选择和搭配，但另一方面也要明白工具再强大，业务的方向，执行的团队才是起决定性作用的。工具扮演的是一个不拖后腿，至多助攻的角色，没有一家成功的公司是仅靠好工具上位的，除非他本身做的就是那个好工具。当然最希望看到的还是背着业务 KPI 的 DevOps 团队和这些工具能够互相成就彼此，趁手的工具助力 DevOps 团队扛下业务 KPI，DevOps 又给工具反哺场景，打磨出更好的产品。

WE SHAPE OUR TOOLS, AND THEREAFTER OUR TOOLS SHAPE US。