前言

曾几何时，我们在面对传统数字业务云化的浪潮下，选择喊出“上云就是未来”的口号。但事实上云化对业务来讲，并非百利而无一害。如今潮水退去，我们也在浪潮之下，逐渐看清了公有云的真正面貌，并对如何使用公有云有了清醒、理智的认知。

近一年来由于公有云服务商不可靠造成的生产环境事故频发，这也引发了我们对公有云方案的排斥，并已经建成一定规模的私有云进行替代。

本篇随笔将从我的角度出发，作为一家小创业公司在这方面的决策者，简单聊聊这两年体验下来，我对公有云和私有云的看法。

正文

为什么要去公有云？为什么下一个选择是私有云？

对于初创公司来讲，公有云确实是短时间内快速、廉价地建立服务网络的合适方法。基于虚拟化(VM)与容器化(K8S)，云服务商们对外提供标准服务，通过共用存储、网络以及虚拟化等基础设施。公共基础设施和高度自动化的系统的确一定程度上降低了我们的运维和算力成本，使我们能够有效控制整体服务成本。

但随着业务的不断发展，公有云似乎再难负担日益增长的计算压力和性能需求。这个问题的因素很多，有受限于公共基础设施而无法达到需求性能的，例如对高内网速率的要求；也有公共计算平台确实无力支撑要求性能的情况，例如文字渲染服务对高频强单核的CPU的需求。对于这些情况，无法要求公有云服务商针对某一用户进行资源倾斜，自由度更高的私有IDC应该是这类特殊需求的最好去处。

同时我们的一些业务已经进入平稳发展期。这些业务整体需求变动并不大，但大多对可靠性要求高，而且长期可能面临市场竞争和利润压缩问题。对于这些业务，彻底“降级”已然不可能——已经云化的业务，对容器编排、虚拟化等基础环境有一定要求。但需求摆在这，既不能直接回到传统‘刀耕火种’般的传统运维模式，公有云又存在诸多问题，所以这也间接论证了私有 云 对我们的必要性——兼具公有云的弹性和IDC托管的自由度，成本可控而能形成规模重资产。

我们如何建设私有云？

私有云也不是完全没有坏处。“私有云”并不是租一个IDC机柜，然后放几台刀片服务器就搞定，而是企业本身要有一套脱离公有云公共基础设施外独立实现的，针对容器编排、虚拟化、高可用存储及网络等场景的全套有效解决方案。如果做不好这些，反倒要因为不成熟的技术吃大亏。

而星河很久之前就在我的主导和推动下开始对服务器网络进行存算调度集群化、容器化和GPU资源池化的实验和升级。尽管过程磕磕绊绊，经费预算上也并不是特别充足，甚至因为技术不成熟的问题导致了一些生产事故。但当去公有云化和私有云建设被推进之时，这些曾被质疑‘没有意义’的项目和研究终于派上了用场。

落实到私有云的详细建设层面，基于先前积累的经验，经过一年的技术试验和生产体系改革，我们得以拥有一套健全的私有云服务体系，用以保障私有云业务的稳定性和可靠性。以新泉州集群的虚拟化设施为核心，业务的各个环节(生产、开发、训练)完全适配了私有云基础设施，为“下云”做足了准备。

但对于没有准备好这些事情的企业来讲，我仍然建议不可贸然下云。下云不是看财报支出拍脑袋就决定的事情，是需要针对当前生产体系和服务规模进行详尽评估后，拿出合适方案的事情。是完全去公有云，还是迁移部分生产到私有云，亦或是只对增量需求做下云安排，这些都需要慎之又慎。

“下云”后，残余的公有云设施和服务合约何去何从？

对于星河，目前的策略是迁移部分生产设施到私有云。即我们仍保有一定规模的公有云云化集群，用以在迁移和改造期间继续支持业务。但即使是完全下云后，我们也无法‘完全舍弃’公有云集群。

原因其实自然是公有云仍然提供了高弹性的计算资源扩容能力，集群扩充的流程比起私有云来讲快了五倍十倍有余。也许在企业逐渐发展壮大后，公有云未必完全退居幕后，而是作为集群的重要组成部分，继续提供高可用、可扩展、高性能的网络服务。

后记

本篇文章主要还是兴起而写，但写多了又不知道怎么拿出数据来佐证观点(涉密)，倒是有一种两难的感觉。发吧，总感觉少了点什么，不是篇好文章；不发吧，总觉得这么多字白码了。思来想去，晚上还是整理了一下发出来，各位权当电子榨菜来看，不要认真就好哈哈哈。

Q.E.D.
0xC4A1
2024-01-06 23:35 提笔
2024-02-06 22:35 完稿

感谢您的耐心阅读，希望本篇文章的观点能获得您的认同。本文编写时间较短，某些内容缺乏仔细考证和审稿，如您有别的看法，欢迎在下方评论区讨论，或通过“关于”页面联系我。