1. 我的平台建设经历

毕业之后，我加入了腾讯蓝鲸，主要参与 SaaS 的开发。待了近三年之后，回武汉老家，加入青云，负责 DevOps 的研发。待了近两年之后，加入新的公司，参与业务支撑平台建设，思考业务侧对 Kubernetes 的落地实践。

我写过很多关于平台的文档，领域输出才是 PaaS 的核心竞争力 、大公司和小公司的 ToB 思路 、云原生下的 DevOps 平台 、ToB 创业公司的开源之路 - KubeSphere 、企业如何打造 ToB 产品 等，这些都是工作内容带给我的思考。

最近接触的一些事，让我有为蓝鲸再写一篇文档的想法。身处武汉，上千人的互联网公司不多，斗鱼和金山办公属于佼佼者。但他们都相继放弃了蓝鲸。这让我不解，蓝鲸是我对平台建设思考的起点。虽然我离开了蓝鲸、也离开了 KubeSphere，但一如既往地希望这两款产品能够被越来越多的人接受并使用。一方面是出于情感的原因，另一方面是他们真的很优秀。这是两款非常不一样的产品，有非常多可圈可点的地方。

2. 蓝鲸的核心价值

2.1 工具文化

蓝鲸提倡的是工具文化，解放运维，挖掘运维的价值。

我对工具文化的理解主要分为三个层次：

• 技能文档化。技能不应该与人绑定，而是可以复制的。将经验实践写成文档是低成本的沉淀和传播方式。
• 文档工具化。再好的文档都不如一个脚本来得直接。将技能文档转换为一键式的脚本，将技能的输出又提升了一个档次。
• 工具产品化。工具的领域概念太多，运行环境复杂。通过产品可以降低使用门槛，更好输出价值。

有了这样的思路，无论是建设团队，还是建设平台都将会事半功倍。但蓝鲸的价值不止于此。

2.2 直达 PaaS 金字塔

以运维系统为例，我们一起来建设一个平台，其他场景类似。

• 第一阶段

起初是百废待兴，有什么现成的东西就上什么，找不到就自己开发。监控、告警、日志、CICD、通知，各自为战，解决业务需求。因此，出现了下面这张拓扑。

• 第二阶段

随着时间的推移，孤立的信息源已经无法给业务带来更多边际价值，系统与系统之间的壁垒阻碍了 IT 基础设施的建设。因此，我们将关联的系统打通，相互调用。至此，出现了下面这张拓扑。

很多平台最终会停留在第二个阶段，因为 N 个系统就会有 N *（N -1）种连接，他们已经没有精力再干其他的事。

• 第三阶段

下面是新的拓扑结构。

所有的系统应该接入 PaaS ，通过 PaaS 标准化系统之间的调用。将问题的复杂度从 N 平方降到了 N 。

系统内部自治，可以随意变更，但对外需要提供统一的 API 接口，以供其他系统消费。同时需要配套相关的 SDK、CLI 等工具，降低使用门槛。

蓝鲸直达第三阶段，跳过了粗犷原始的第一阶段、充满陷阱的第二阶段。

2.3 领域迁移

虽然蓝鲸面向的是运维行业，但具备很强的迁移能力。

下图是蓝鲸架构的抽象。

最早接触到 aPaaS 和 iPaaS 是从 Gartner 的魔力象限，但真正落地是在蓝鲸。aPaaS 主要是托管应用，让服务可以免运维; iPaaS 主要是聚合 API 向其他应用提供标准化的接口。

针对运维领域，蓝鲸实现了作业平台、配置平台等。无论业务需要怎样的功能，只要运维领域的实现是稳定的，蓝鲸就能支撑研发快速交付 SaaS 。如果你有关注蓝鲸公开课或者蓝鲸开发者认证考试，就会有所了解，开发一个 SaaS 只需要几个小时。

那么如果将蓝鲸迁移到非运维领域，其实只需要补齐 iPaaS 的领域实现即可。比如，电商行业，需要补齐支付、物流、订单、评论管理等。

3. 使用蓝鲸会遇到的阻碍

3.1 代码部分开源

很多潜在的客户使用蓝鲸，是因为大批好用而免费的 SaaS。犹如饿汉被曼妙的身姿吸引。走近一看，却发现了斑斑点点，部分 SaaS 不开源，有些恼羞成怒，而忽略了其内在的美。

Open Core 是非常常见的开源策略。将 PaaS 平台开源，而 SaaS 大部分闭源，蓝鲸采取的就是这种策略。

PaaS 才是蓝鲸的价值核心，将 SaaS 当做第三方闭源系统使用即可。即使 SaaS 开源，也不是每个工程师能改得动。蓝鲸已经开源的 SaaS 有标准运维、蓝盾、容器管理平台，但想要参与进去也并不是一件容易的事。

3.2 技术人员的骄傲

骄傲的工程师表现在对现有系统的自信，而排斥外来系统。

在调研蓝鲸时，工程师应该保持空杯心态，多看官方的文档，多动手实践，不清楚的地方不要轻易否定，多和社区沟通。

初次部署、运维、使用蓝鲸时，肯定会遇到各种各样的问题。研究产品、解决问题也是一个学习成长的过程，蓝鲸是一个庞大的产品体系，与你过往接触的平台会有所不同。工程师需要多一点耐心去理解蓝鲸的设计。

蓝鲸始自 2012 年，从 2016 年开始放出社区版，历经这么多年而保持增长，肯定有其原因。工程师对蓝鲸产品本身也要有信心。

3.3 服务太贵

IT 的 ToB 公司琢磨了很多普通公司的需求场景。

• 外包。不想长期投入研发。
• 运维。不想部署、运维产品。
• 等保。安全问题束手无措。
• 培训。新东西上手慢。
• 咨询。陷入技术难解之题。
• 定制。想要个性化改造。
  …

这些 ToB 公司生存的空间在于客户招工程师的成本太高。由 ToB 公司为非核心业务提供兜底服务，符合社会分工的协作方式，将合适的事交给合适的人做。

蓝鲸周围有很多的服务商，蓝鲸企业版服务贵不贵得看蓝鲸能节约多少成本、自己维护需要多少成本。运维系统从来都不是一蹴而就的，而是一个不断演化改进的过程，需要自行评估。

从另外一个角度看，相较于其他开源产品，如果没有 SLA 服务商，用钱都解决不了问题，这才是真的问题。起码蓝鲸的问题，用钱还是可以解决的。

3.4 迁移成本太高

对于有一些 IT 基础设施的公司来说，使用蓝鲸意味着要放弃自己的 CMDB 等系统。这似乎有些不可接受。

但其实我反复强调的是，蓝鲸的核心在于 PaaS，底层的领域实现可以替换。只需要接入到 iPaaS ，以供上层系统消费即可。

另一个方案是将蓝鲸作为一个第三方系统，自己建设一套 PaaS ，将蓝鲸接入到自己的 iPaaS 中。即使用武力征服，最终也会被同化。蓝鲸是一个值得珍惜产品。妙哉！