2020年 DevOps 领域值得推荐的工具
从今天开始，让我们使用最佳 DevOps 工具。
DevOps 革命已然成为主流，各类 DevOps 工具的人气一路飙升。根据 Google Trends 的统计，互联网用户对“DevOps 工具”的搜索量一直在稳定增长，而且整体发展趋势也相当稳定。
由于 DevOps 涵盖整个软件开发生命周期，期间涉及多种可选工具选项。没有哪种工具能够适合所有情况，但是针对各类应用场景都有对应的、发展较为成熟的工具。我们把整个 DevOps 实践过程中使用到的工具分为以下几类：
- 开发与构建工具
- 自动化测试工具
- 部署工具
- 运行时 DevOps 工具
- 协作 DevOps 工具
一个成熟且成功的 DevOps 实践必须建立一套完整的工具管道，以上五类工具就包含在其中。
1. 开发与构建工具
这类工具是 CI/CD 管道堆栈的基础，一切也以此作为起点。
开发与构建工具需要协调多个事件流，并能与外部工具轻松集成。根据软件开发生命周期，这类工具又可以分为三个子类别：
- 源代码控制管理（SCM）
- 持续集成（CI）
- 数据管理
2020 年，我们最推荐的 SCM 技术是 Git，所以建议选择的 SCM 工具最好提供出色的 Git 支持能力。在 CI 方面，最重要的是在临时容器化环境中运行及执行构建任务的能力。至于数据管理，我们希望工具能够变更数据库架构，并使其与应用程序版本保持一致。
SCM+CI工具：Gitlab与Gitlab-CI
Gitlab 无疑是 2020 年最强大的 DevOps 生命周期工具，并将在可预见的未来将成为创新领域的领导者。
Gitlab 的核心定义是在于提供一款完美的 Git repo 管理工具，其基于 Web 的用户界面详尽且易于使用。更重要的是，即使是 Gitlab 的免费版本也足以解决用户的各类需求，且分别提供 SaaS 与本地设施版本。
目前市面上的 SCM 工具多种多样，但没有哪位竞争者能够像 Gitlab 那样多年来一直坚持将“持续集成”能力引入 repo 当中。我们只需要将.gitlab-ci.yml 文件粘贴至 repo 的根目录当中，Gitlab-CI 即可根据用户在文件中作出的定义触发各类操作。总而言之，这两款工具彼此配合、成为代码持续集成领域当之无愧的领导者。
主要优势
成熟—该产品于 2013 年正式投放市场，表现稳定且提供良好的支持服务。
开源— Gitlab 的免费版本并没有削减开发团队所需要的各项核心功能。而不同付费选项又进一步提供了更多附加功能，可根据组织的具体规模与需求带来更大的价值。
易用且强大的 CI— 目前市面上没有哪款工具能够像 Gitlab-CI 一样将持续集成直接嵌入 SCM 当中。用户可以利用 Docker build 轻松完成构建任务，内置报告功能也让 build 故障调试变得简便易行。总之，无需复杂的集成与业务流程，即可对多种必要工具进行编排。
无限集成— Gitlab 还能轻松集成 DevOps 各核心类别中的不同工具选项。如此一来，开发人员与运营人员将可立足任意环境通过真实来源获取与其应用程序相关的信息。
与竞争对手的比较
市面上的同类工具有很多，但大多无法与 Gitlab 相比肩。
GitHub — GitHub 是一套面向小型及早期开发群体的 SaaS 源代码管理系统，但对于需要在网络当中保留知识产权资产的大型企业，GitHub 提供的唯一选项只有.OVA 虚拟机。由于这款工具不支持高可用性保障，on-prem 部署的维护难度会比较高，且在业务规模增长到一定程度后必然引发服务器崩溃。另外，GitHub Actions（最近刚刚推出，但仍不提供本地版本）与 CI-as-Code 的长期缺席，迫使用户自行准备 CI 工具以管理集成。最后，GitHub 的使用成本要远高于一切 Gitlab 版本。
Jenkins — 虽然 Jenkins 已经成为持续集成工具中的默认标准，但它却始终缺少源代码控制元素。换句话说，Jekins 一直无法与 SCM 工具真正统一起来。相比之下，Gitlab 这样的工具能够同时兼顾这两大功能，消除不必要的复杂性因素。另外，与目前的现代 Web 应用程序相比，Jenkins 糟糕的用户体验可能让很多朋友不堪忍受。
BitBucket/Bamboo — 恕我直言，在大家考虑使用两种工具来完成 Gitlab 本身就能完成的任务的同时，这套方案就已经落入下风了。虽然 BitBucket 云已经能够支持 Gitlab-CI/GitHub Action 功能，但还没有哪家成熟企业（超过初创公司的规模）能够轻松进行部署与使用。更夸张的是，本地版本的 BitBucket 服务器甚至不支持 BItBucket Pipelines！
2020 年头号数据管理工具：FlywayDB
Web 应用程序开发中最容易被忽视的方面就是数据库的自动化需求。人们往往是事后才想起需要为应用程序的新版本部署数据库 schema 变更。Schema 变更往往会添加或重命名多个列或表。如果应用程序版本与 schema 版本不匹配，还有可能彻底破坏应用程序的正常运行。最后，由于存在两套不同的系统，通过应用程序升级来协调数据库变更也比较困难。好消息是，FlyWayDB 自己就足以解决以上所有的问题。
主要优势
数据库版本控制 — FlyWay 允许用户轻松创建各数据库版本、跟踪数据库迁移并轻松完成 schema 变更的前滚与回滚——整个过程无需配合定制构建解决方案。
二进制或内置—大家可以选择在应用程序的启动过程中、或者以二进制可执行文件的形式运行 Flyway。用户可以在代码中直接使用此工具，使其在启动时能够检查版本功能并运行适当迁移，从而令数据库与应用程序的版本保持同步。当然也可以临时运行 cmd 行，在无需重建整体应用程序的前提下为现有数据库提供良好的灵活性。
与竞争对手的比较
与 FlyWay 处于同一定位的竞争对手不太多，但我们仍有必要分析双方的实力差距：
LiquiBase — Liquibase 跟 FlyWay 非常相似。事实上，如果能找到经验丰富的专项负责人员，我其实更倾向于将 LiquiBase 选定为标准解决方案。
Flocker — 这款工具更多强调对容器化应用程序的管理——相信很多朋友都有切身体会，在容器当中运行数据库往往非常困难，需要精心规划才能达成目标。我建议大家使用 RDS 这类数据库服务，最好不要轻松尝试在容器之内运行关键数据存储。
2. 自动化测试工具
我们首先需要将自动化工具引入整个测试“金字塔”体系，然后才能对自动测试工具进行评估。
整个测试金字塔分为 4 层：
- 单元测试 — 这是所有自动化测试的基础。单从数量角度来看，单元测试的数量应该远远高于其他测试类型。单元测试应由软件开发人员负责编写与运行，以确保应用程序中的特定组成部分（即「单元」）符合设计要求并能够按照预期方式运行。
- 组件测试 — 组件测试的主要目标在于验证测试对象的输入 / 输出行为。这能确保测试对象的功能以符合必要规范的形式正常运作。
- 集成测试 — 在这一测试阶段，我们需要将各个软件模块组合起来并共同进行测试。
- 端到端测试 — 这一层的测试目标非常明确了，我们需要从头到尾跟踪应用程序流程，保证其与预期结果保持一致。
由于单元与组件层测试单纯由应用程序开发人员负责，且通常根据具体编程语言而有所区别，因此这部分工作不在 DevOps 的讨论范围之内。
2020 年头号集成测试工具：Cucumber
Cucumber 将规范与测试文档合并为统一的动态文件。Cucumber 能够自动完成测试，因此能够保证用户规范将始终保持更新。如果大家希望构建 Web 自动化测试框架并在 Web 应用程序之上模拟用户行为，不妨在项目当中使用带有 Java 与 Cucumber BDD 的 Selenium WebDriver——这将是您学习并实现 Cucumber 测试功能的良好起点。
主要优势
行为驱动型开发（BDD） — 适用于 BDD 测试，而且已经成为这一领域中的首选测试框架（相较于传统测试驱动型开发）。
动态文件 —文档记录一直是项令人头痛的工作，但在以代码形式对测试内容进行定义之后，Cucumber 测试可以自动生成文件以匹配测试需求，并保证各项需求始终保持同步。
支持 —目前市面上有多种支持工具可供选择，但对于规模较大的严肃项目来说，工具维护者的态度将决定方案的可靠性与可持续性。Cucumber 团队拥有充足的资金与支持架构，足以在可预见的未来保持这款工具的健康发展。
与竞争对手的比较
这一领域中有着多种框架与面向特定技术场景的工具，但只有 Cucumber 最接近“普适性”解决方案的层次。
2020 年头号端到端测试工具
进行端到端测试时，我们需要重点关注以下两个核心问题：
- 功能测试
- 负载测试
功能测试，顾名思义是要测试我们需要的一切是否按预期正常发生。在点击 SPA 上的某些页面、填写不及格并单击 Submit 时，数据将显示在数据库当中，且屏幕显示提交成功！
此外，我们还需要测试在同一场景下，数量为 x 的用户发出的同时操作是否得到了正确处理。
如果缺少这两种重要的测试类型，最终 CI/CD 管道运行表现将出现巨大差异。
功能测试：SoapUI Pro
SoapUI 在 API 测试领域已经拥有相当丰富的积累，这主要受益于 SOAP Web 服务的默认地位。虽然我们已经不再构建新的 SOAP 服务，但这款工具的名称并未因此改变，且仍在向着用户的实际需求不断发展。SoapUI 为后端 Web 服务的自动化功能测试提供了一整套出色的构建架构，其中一切元素都能轻松与持续集成工具将结合，作为 CI/CD 管道中的组成部分协同运行。
主要优势
广泛的文档资源 — 这款工具已经存在了多年时间，因此大家可以在网上轻松找到用于指导负载测试配置的学习资源。
易用性—尽管目前市面上的 API 测试工具有很多，但 SoapUI 在单一服务中囊括了多种服务接口，从而让测试构建变得更加简单。
与竞争对手的比较
Selenium — Selenium 是另一款重要的测试工具。如果您正在构建并运行基于 Java 语言的应用程序，那么我们其实更推荐 Selenium。但是，如果您的诉求在于使用多种技术处理同一款完整的 Web 应用程序，那么 Selenium 在非 Java 语言用户手中显得有些笨拙。
负载测试：LoadRunner
在对应用程序中各个层面进行负载测试时，LoadRunner 表现出了无可替代的全面优势。虽然 LoadRunner 价格较高且难于上手，但它却是唯一能够模拟出极端压力环境、并真正让技术架构师们对新代码建立起充分信心的测试工具。另外，我也觉得是时候将负载运行技巧从 SQA 资源转移到开发团队当中。
主要优势
广泛的文档资源 — 这款工具已经存在了多年时间，因此大家可以轻松在网上找到用于指导负载测试配置的学习资源。
协议支持 — 从 ODBC 到 AJAX、再到 HTTPS 乃至应用程序偶尔使用的其他晦涩协议，LoadRunner 总能提供良好的支持能力。相比之下，为了协议支持而同时使用多种负载测试工具只会增加整个流程的复杂性。
与竞争对手的比较
同样的，在测试市场上并没有百试百灵的工具，因此能够不太费心地引入当前环境并直接使用的技术就算是好技术了。
3. 部署工具
在应用程序开发当中，部署工具往往受到人们的严重忽视。但对运营人员而言，如果不深入了解应用程序的代码与功能，将很难顺利使用部署工具；在另一方面，开发人员则开始越来越多地承担起代码部署的职责，因此需要尽快积累原本匮乏的部署工具使用经验。
首先，我们将部署工具分为三个子类：
- 构件管理
- 配置管理
- 部署
2020 年头号构件管理工具：Nexus
Nexus 构件存储库支持几乎所有的主要技术，包括 Java、NPM 乃至 Docker 等等。我们可以使用这款工具来存储所有的可部署构件，通过拉近软件包与构建流程之间的距离，Nexus 提供的远程软件包管理器代理功能极大提升了持续集成速度。这种作法的另一大优势，在于帮助用户全局查看跨多个软件项目使用的全部软件包，从而锁定不安全的开源软件包，避免这些软件包成为恶意人士攻击代码的载体。
主要优势
技术支持 — 自 2013 年投放市场以来，Nexus 一直拥有稳定的表现并得到开发团队的良好支持。
开源 — Nexus 的免费版并没有削减开发团队所需要的各项核心功能。而不同付费选项又进一步提供更多附加功能，可根据组织的具体规模与需求带来更大的价值。
2020 年头号配置管理工具：Ansible
Ansible 是这一领域中绝对的王者，理由非常简单：无状态。早期配置管理工具着重于管理配置状态，换句话说，如果当前状态与所需配置状态不再同步，则需要进行修复。但在新型应用程序当中，我们面对的是大量无状态组件，新版本的代码属于新的构件，并用于部署并替换现有构件。整个业务流程将由众多生命周期短暂的即席环境组成。
主要优势
无状态 — Ansible playbook 将由操作机器运行，并直接命中服务器目标。我们不在乎远程对象的状态，这让用户得以轻松通过 Packer 等工具构建出可部署对象。
开源 — 与 CentOS 类似，Ansible 同样由红帽公司负责维护。红帽在业界拥有良好声誉，其高级支持人员在维护社区方面拥有丰富经验，并确保 Ansible 持续提供各类高质量且易于使用的模块。
分子测试—配置管理本身与正常编写出的代码无区别，因此如果不对其进行测试，我们的测试目标也将无从谈起。用于测试 Ansible 角色的分子框架能够无缝运作，确保我们的测试配置能够切实满足代码测试的需求，且同样遵循应用程序代码使用的同一 CI/CD 管道。
YAML — 与其他工具相比，YAML 的入门门槛更低。对于大多数刚刚接触 DevOps 的朋友来说，配置管理都是前所未见的新鲜体验，因此上手难度越低、就越容易被人们所接受。
与竞争对手的比较
OpsCode Chef — 其实我个人的 DevOps 职业生涯就是从 OpsCode Chef 起步的。Ruby 与 Chef 都是我的心头好。但必须承认，二者根本没有应对当前无状态云原生应用程序问题的能力。当然，对于较为传统的遗留应用程序来说，这仍是一款很好的工具；但就本文讨论的应用场景，我们还是更多着眼于未来。
Puppet — Puppet 一直缺少成规模的技术社区，因此在支持能力方面完全无法与 Chef 以及 Ansible 相提并论。Puppet 虽然非常适合配置与裸机使用场景，但却无法支持 Web 应用程序类型的配置管理需求。
2020 年头号部署工具：Terraform
Terraform 解决了在网络组件到实际服务器镜像等各类场景当中，如何定义基础设施即代码这个问题。自最初发布以来，Terraform 已经经历了一段时间的发展，并建立起庞大的插件生态与支持社区，能够为用户可能遇到的几乎所有部署场景提供良好帮助。Terraform 拥有对本地、云端或其他类型运行环境的强大支持能力。最后，其最新版本还在 HCL 当中提供多种与其他传统编程语言相同的逻辑函数与类，这进一步降低了开发人员的上手与学习难度。
主要优势
云 / 环境中立性 — Terraform 能够在 Terraform 代码与基础设施供应方通信时所必需的 API 及后端逻辑之间充当接口，这意味着只要学习这一款工具，就能随处实现其部署功能。
开源 — 同样的，相信没人能对免费的工具说不，更遑论 Terraform 还拥有良好的支持社区。
与竞争对手的比较
AWS CloudFormation — 即使大家仅在 AWS 环境中工作，也可以规划自己的学习路线，而并不一定把所有希望都寄托在 AWS 服务家族身上。事实上，把所有技能与知识都放进同一个篮子只会增加职业风险。另外，AWS 的不少新服务在与 CloudFormation 正式对接之前，都会以 Terraform 模块的形式存在一段时间。
4. 运行时 DevOps 工具
任何开发项目的最终目标都是在生产环境中运行应用程序。在 DevOps 领域，我们当然希望保证对环境中的一切潜在问题保持可见性，同时将人工干预程度降至最低水平。为此运行时工具集的正确选择就成为了良好开发流程必不可少的条件。
运行时工具分为以下几个子类：
- X 即服务
- 编排
- 监控
- 日志记录
2020 年头号 X 即服务工具：AWS
亚马逊一直是云计算领域的领导者，他们不断为开发人员提供更多新的服务选项，保持整个体系的新陈代谢。如今，我们可以将几乎一切技术及模式引入 AWS，进而完成构建与运行工作。与在自有数据中心内构建、管理及维护传统硬件相比，云服务模式的成本更为合理。免费服务层让每个人都有机会在实际购买之前先体验使用感受，并快速摸索出构建应用程序的正确途径。更重要的，摆脱了自主采购的压力，摆脱了以往因预算有限而被迫做出的种种妥协。
主要优势
行业标准 — 如果大家曾经在 AWS 当中构建过应用程序，那么相关工作经验足以支撑您在任何行业找到立足之地。
免费层 — AWS 最突出的特色在于他们在业务层面从不犯错。他们允许用户试用服务并了解其工作原理，然后再决定是否投入资金来批量使用他们提供的解决方案。这种“先尝后买”的形式非常科学，我自己就从来没有贸然购买过未经过概念验证的 AWS 产品。
与竞争对手的比较
Heroku — 简而言之，除了个人项目之外，我永远不会把 Heroku 用在严肃的开发环境当中。它的透明度实在有限，企业没有理由选择这样一套平台。除了博文当中进行简单演示之外，我拒绝对 Heroku 进行任何实际层面的应用。不用，谢谢！
2020 年头号编排工具：OpenShift
大家可能已经在自己的应用程序堆栈当中使用了 Docker 或者容器技术。无服务器应用程序很棒，但显然不可能适合所有的架构模式。例如，在没有业务流程平台的情况下，我们根本就没办法使用容器。而从案例性与工具丰富度的角度来看，Core Kubernetes 的限制因素也比较多。OpenShift 是目前唯一提供 Kubernetes 平台的服务方案，其中包含 Source2Image 构建、pod 内自动化部署乃至可回溯性与监控功能。更重要的是，它能够在本地、云端乃至二者兼有的情况下运行。
主要优势
内置安全保障 — K8s 安全性很难管理，甚至可能需要具备相应博士学位的技术人来管理。而在默认情况下，OpenShift 所采用的安全机制能够极大减少开发人员的工作量，并为他们的应用程序提供更加安全的平台。
多合一解决方案 — 与默认不包含负载均衡工具的原始版 K8s 不同，OpenShift 提供所有必要功能。我可以使用它托管自己的容器、构建容器、运行 CI/CD 工具、协调外部流程、管理 secrets 等等。尽管目前的 GUI 还不够完善，但 API 优先的方法意味着所有内容都能够以脚本形式实现；而且与其他 K8s GUI 不同的是，OpenShift 使得 Kubernetes 的基础知识学习过程变得更为简单。不用博士学位了，大家欢呼起来！
与竞争对手的比较
Docker Swarm — Docker swarm 的本意是删除大量内容以简化 K8s 体系。虽然它在体量较小的应用程序中效果不错，但对于企业级应用程序则根本不起作用。此外，AWS ECS 等服务也提供类似的方法，且能够切实降低与其他服务（Lambda、IAM 等）之间的交互难度。
2020 年头号监控工具：New Relic
New Relic 的早期发行版确实在 APM 监控方面带来了良好的表现。如今，它已经发展成一套完善的监控工具，允许用户轻松监控服务器性能、容器性能、数据库性能、最终用户体验以及 APM 等等。
主要优势
易于使用 — 作为曾经的系统工程师，我使用过不少监控工具，但没有一款能够在易用性方面与 New Relic 比肩。这是一项 SaaS 服务，用户无需设置任何服务器组件即可直接使用。
端到端可见性 — 其他工具往往只关注应用程序中某个特定层面的监控。但无论强调 CPU 利用率还是网络流量，这些元素都必须协同运作才能让应用程序保持正常运行。New Relic 则允许用户将所有数据组合起来，了解应用程序中真实发生的一切。
与竞争对手的比较
Zabbix— Zabbix 是我最早使用过、而且非常喜爱的一款监控工具。但由于缺乏对云原生环境及 APM 方向的支持与发展规划，目前它的水平已经相对滞后。诚然，它仍能够很好地监控传统服务器基础设施，但也就仅此而已了。
DataDog — 这款工具过分侧重于管理生产应用程序的流程，而对代码本身的关注度不足。在真正的 DevOps 团队当中，开发人员也需要深度参与生产，因此我们并不需要这样一套单纯强调流程监控的解决方案。
2020 年头号日志记录工具：Splunk
Splunk 同样有着令人难以拒绝的魅力。长期以来，Splunk 一直是日志聚合领域的领导者，同时也在努力维持自己的统治地位。借助本地与 SaaS 产品版本，用户已经能够随时随地享受由它带来的便利。但 Splunk 也不是没有缺点——它难以运行的老毛病到现在也没能根治。
主要优势
行业标准— 企业喜欢 Splunk，也拥有充足的财力使用这套解决方案。虽然初创企业往往难以证明 Splunk 的成本合理性，但其中的不少概念与功能已经在开源替代方案中实现了。
支持效果— 简单来说，Splunk 能用、而且效果不错。其中提供多种默认的设置与即用型功能，大家无需投入大量时间阅读文档或者反复试错，即可让 Splunk 发挥其应有的作用。
与竞争对手的比较
ELK Stack — ElasticSearch、LogStash 以及 Kibana 似乎都挺酷的，毕竟它们不会向用户收取任何费用；但随着日志集的增长与应用程序数量的提升，我们越来越难以依靠内置工具维护这些日志记录方案。与 Splunk 相比，这类工具永远要耗去更多学习和上手的时间，之后才能构建起正常可用的仪表板。
5. 协作 DevOps 工具
DevOps 的第一步就是在组织内部掀起一波文化变革。虽然外来工具不可能在一夜之间改变文化传统，但却能够帮助我们培养起与同事协作的新方法。
协作工具分为以下几个子类：
- 问题跟踪
- ChatOps
- 文档
2020 年头号问题跟踪工具：Jira
尽管这一领域的竞争变得日益激烈，但 Jira 仍然稳坐头把交椅。Jira 内置的强大灵活性足以帮助开发团队与运营团队轻松管理项目中的日常工作与冲刺任务。另外，内置的标准敏捷术语也有助于企业逐步完成由传统工作方法到精准流程文化的转变。
主要优势
行业标准—与之前提到的多种其他工具一样，Jira 的应用范围极广。小型团队可以使用价格低廉的许可并获得必要功能，而大型企业也会在购买许可之后获得物有所值的体验。
集成— 在这一领域处于领先地位并快速增长，意味着其他第三方工具也会优先选择 Jira 构建本机集成，从而进一步增加 Jira 的价值。我们可以从现成列表中挑选需要的集成工具选项，整个过程一气呵成、完全无需任何特别定制。
与竞争对手的比较
Trello— 作为一款免费使用的看板工具，Trello 同样迅速积累起可观的人气。但随着业务规模的扩展，需要跟踪的问题也由数十个增长至数千个，这时 Trello 难以导航、搜索与报告的短板就开始暴露出来。
Pivotal Tracker— 在初创企业工作期间，我其实非常喜欢这款工具。但它更多关注产品管理，而非技术任务。相比之下，Jira 的产品管理功能也比较难上手，但至少可用而且足以替代其他独立的产品管理工具。
2020 年头号CHatOps 工具：MatterMost
这可能是这份榜单中最让我惊喜的上榜成员，MatterMost 继承了以往优秀工具的特性，同时引入本地部署支持以扩大自身普及范围。对于企业而言，这一点非常重要，因为它不仅能够控制数据、还可以帮助用户与本地工具相集成——换言之，我们不必为了引入新功能而被迫跨出防火墙。
主要优势
开源— MatterMost 的开源版本非常适合小型或者大型团队。与 Slack 免费版会丢失历史记录的情况不同，MatterMost 允许用户运行自有服务器，因此所有数据也都将保存在本地位置。
集成— MatterMost 的 API 几乎 100% 基于 Slack API，因此 Slack 生态中的几乎所有集成都能够无缝对接 MatterMost。
与竞争对手的比较
Slack— Slack 很棒，但项目的体量已经过于庞大，需要认真考虑盈利问题。可以预见，Slack 将很快推出全面付费政策，并在免费版本当中阉割掉大量极具价值的功能——最重要的当然是保存聊天记录功能。
Microsoft Teams— 大家可以尝试把微软产品与非微软本地产品集成一下——祝各位好运！我要说的就这么多。
2020 年头号文档工具：Confluence
无论使用哪种工具，我们都很难创建并维护高质量的技术文档。尽管最近市面上出现了不少 SaaS 文档工具，但我还是很难接受把关于关键应用程序核心技术的敏感文档存储在第三方平台当中。没错，我还是想把数据和文档保存在本地，而 Conluence 正好解决了我的这个痛点。
主要优势
易于管理—大多数自托管工具在启动与运行阶段都具有一定的复杂性，而且在规模化维护场景下会对专业技能提出要求。Conluence 服务器在这方面表现不错，能够以开箱即用的方式支持 10 到 10000 名用户。
插件— Confluence 默认创建出的美观、易于浏览、可导航文档已经足以令人满意，而丰富多彩的插件选项更是将 Wiki 的潜力发挥到了极致。
与竞争对手的比较
Read the docs— 很棒的开源项目，但我完全不会考虑在这里存储与关键应用程序相关的敏感信息。
MarkDown— 这款工具特别适合记录与代码相关的内容，但我们很难将架构、过程或者其他类型的文档直接保存为 MarkDown 格式。
Jekyll— 在记录技术信息时，我并不想简单构建一个静态站点并在每次更新时调整其中的内容。Confluence 提供简单易用的版本管理系统，极大降低了内部文档的管理难度。