- 我的平台建设经历
毕业之后，我加入了腾讯蓝鲸，主要参与 SaaS 的开发。待了近三年之后，回武汉老家，加入青云，负责 DevOps 的研发。待了近两年之后，加入新的公司，参与业务支撑平台建设，思考业务侧对 Kubernetes 的落地实践。
我写过很多关于平台的文档，领域输出才是 PaaS 的核心竞争力[1] 、大公司和小公司的 ToB 思路[2] 、云原生下的 DevOps 平台[3] 、ToB 创业公司的开源之路 - KubeSphere[4] 、企业如何打造 ToB 产品[5] 等，这些都是工作内容带给我的思考。
最近接触的一些事，让我有为蓝鲸再写一篇文档的想法。身处武汉，上千人的互联网公司不多，斗鱼和金山办公属于佼佼者。但他们都相继放弃了蓝鲸。这让我不解，蓝鲸是我对平台建设思考的起点。虽然我离开了蓝鲸、也离开了 KubeSphere，但一如既往地希望这两款产品能够被越来越多的人接受并使用。一方面是出于情感的原因，另一方面是他们真的很优秀。这是两款非常不一样的产品，有非常多可圈可点的地方。
- 蓝鲸的核心价值
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.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 中。即使用武力征服，最终也会被同化。蓝鲸是一个值得珍惜产品。妙哉！
参考资料
[1] 领域输出才是 PaaS 的核心竞争力: https://www.chenshaowen.com/blog/domain-knowledge-is-the-key-of-paas.html
[2] 大公司和小公司的 ToB 思路: https://www.chenshaowen.com/blog/tob-thinking-of-large-and-small-companies.html
[3] 云原生下的 DevOps 平台: https://www.chenshaowen.com/blog/devops-platform-under-cloud-native.html.html
[4] ToB 创业公司的开源之路 - KubeSphere: https://www.chenshaowen.com/blog/the-road-to-open-source-for-tob.html
[5] 企业如何打造 ToB 产品: https://www.chenshaowen.com/blog/how-to-build-tob-products.html