阿里云面临的全方位挑战

两三年前，阿里云市场部的朋友们喜欢用一个词：3A 云。这 3 个 A 分别指代三个营业额最大的云厂商：AWS，Azure 和 Aliyun。那时候 GCP 营业额还低于阿里云，被这个词很巧妙的踢出一流阵营。

时间过得很快，在2023年，不仅 GCP 的营业额超越了阿里云，甚至国内的华为云都在接近阿里云。3A 云这个词过于脱离现实，阿里云的朋友们都不好意思用了。

笔者认为阿里云发明 3A 云这个词是一个严重的错误。它用营业额这个单一指标，掩盖了一个很重要的事实：阿里云各方面都落后美国同行至少十年，需要的是奋起追赶，根本没有资格并驾齐驱。

十年前，AWS 开始开拓企业 IT 市场：他们当时已经成为互联网中小企业的默认选择，但是尚未进入大中型企业的主流 IT 供应商名单。从各方面考察，2023 年的阿里云正好处于 AWS 十年前所处的阶段：能上云的互联网公司都已经上云了，但是传统企业仍然认为云计算是毛头小伙子玩的新潮玩意。

在这个门槛上，营业额不会再自然增长了，云厂商要么转型成一个合格的企业 IT 供应商，要么被市场淘汰。云厂商面临全方位的挑战：

1. 决策层需要提出有说服力的价值主张。

2. 产品团队需要管理企业客户需求。

3. 行销团队需要明确企业客户的画像。

4. 销售队伍需要和企业客户真实对话的能力。

5. 研发团队需要提升软件工程素质。

6. 所有团队在 IT 安全上要表现出专业度。

7. 需要若干有说服力的的企业客户成功案例。

决策层需要提出有说服力的价值主张。

十年前，AWS 试图摆脱“那些互联网企业才使用的技术供应商”这个标签，进军企业市场，这是并不容易的转型。他们需要回答第一个问题：为什么企业 IT 应该上云？在哈佛创新实验室的一次分享中， 当时还是 AWS SVP 的 Andy Jassy 给出自己的回答^[1]。他提出的六个价值主张分别是：

1. 用 CapEx 替换 OpEx。

2. 降低 IT 总成本。

3. 利用云弹性，无需容量规划。

4. 更快的敏捷速度以促进企业创新。

5. 专注能带来市场竞争力的工作。

6. 全球布局。

这六个点，先不管对不对，至少是客户听得懂的。

作为对比，我们可以看一下阿里云前 CEO 最近一次（2019年）对云计算的价值主张^[2]：

第一，云从基础设施角度来讲，把原来基础设施都云化了，都跑在网上，很多部门没有必要构建自己的单独的基础设施。云是一个分布式的7×24小时能够提供可靠服务的平台。

第二，基础技术互联网化。今天所有的技术基本上都在互联网化，用互联网技术改造。所以不管是工业、还是商业领域等的系统，都是用互联网的技术在变革。互联网有什么样的大的特点，互联网一个是全连接、全在线、实时、分享、透明、最后是数字化、智能化。今天基于互联网技术变革是一次很大的潮流。

第三，应用的数据化、智能化。中国的企业很多在完成第一步，我们叫做信息化，很多的咨询公司的原来很多工作都在帮助企业通过ERP软件完成信息化，最大的对企业效率的提升，叫做流程再造。咨询公司告诉你，你的企业流程是不对的，要这样做。今天阿里巴巴提的最多的并不是这个范畴，我们认为下一个时代要讲的更多是怎样数据化、怎样智能化。刚才说到数据是能源，是一个动力，其实在企业运营的过程当中，数据更是血液，是贯穿所有业务的血液，看你怎样利用好这个数据。有了数据还不够，必须基于数据做智能化。

这个价值主张的第一条犯了典型的循环论证逻辑谬误：你要上云，是因为基础设施都云化了。我把基础设施云化，是为了让你上云。我相信，除了他当时的下属，这个论证不能说服任何人。

价值主张的第二条更加不着调。用互联网和用云完全是两码事。你完全可以从自建机房，租赁机房，你的办公室，甚至你家里的树莓派连上互联网。如果用云就等于连接互联网的话，那么中国电信天翼云应该是自然垄断云厂商，其他云都可以打包回家了。

价值主张的第三点，本身有道理，但仍然和云计算没有关系。企业的数据化/智能化（或者说企业数字化转型）是企业 IT 部门的本职工作。云厂家强调企业数字化转型很重要，类似美团外卖强调吃饭很重要，客户的反应是：“吃饭很重要，你说的很对，但是我幼儿园毕业的时候就已经知道这个道理了。”实际上，最看重吃饭质量的客户更少点美团外卖，最看重数据的企业 IT 团队更不倾向于用云：“数据是我们企业的血液，一定要拿在手里，千万不能上云。”

这个演讲是2019年的，但是已经是最近的了，之后四年里我并没有看到阿里云推出更有说服力的价值主张。这是令人遗憾的。

产品团队需要管理企业客户需求

最近中国云计算从业者报告了一个好消息，阿里云的 PolarDB 继续入选 Gartner 云数据库魔力象限的领导者象限。阿里云骄傲的宣称“是唯一进入领导者象限的中国科技公司^[3]”，这其实有点说小了，阿里云是唯一进入领导者象限的非美国厂商。Gartner的这个报告选择了业界最优秀的19个云数据库厂商，其中 16 个是美国厂商，非美国厂商只有3家：中国的阿里云，德国的 SAP 和瑞典的 Neo4J。除了阿里云， 其他两家都未能进入领导者象限。

Gartner 分析报告是企业 IT 决策者非常信赖的决策参考，目前为止，这是中国云产品得到的最可信的业界承认。阿里云确实很可以骄傲，不过也不得不指出：阿里云 RDS 产品几乎是对 AWS RDS 的翻版复制。

实际上，阿里云的主力产品都是借鉴 AWS 的，这是跟随者最稳妥的产品规划战略，算是后进者的优势。但是在享受优势的同时，也付出了隐蔽的代价：

1. 抄到个外形但是没有抄到内核。

这一点非常明显的是，尽管阿里云几乎把 AWS 的全套产品都抄袭过来了，但是对 AWS 产品最重要的特质：Infrastructure as Code^[4]，只是敷衍一下。

用户明显可以感受到，很多阿里云的产品经理们有一个假设：用户都是在控制台创建/管理/销毁云资源的，所以控制台应该是主要用户交互界面。这个假设针对小微客户是成立的，但是针对中大型企业，缺乏自动化的云是基本不可用的。我本人的经验是，一个云原生的企业 IT 团队，其99%的云资源是通过 IaC 创建的，控制台基本只用于查看和紧急排除故障。

2. 造出了一堆零件，但是不知道怎么组装成一部商用汽车

有很多优秀的阿里云员工对自己服务的产品很熟悉，但是对其他产品完全不了解。在阿里云分享的明星案例/架构中，极少看到多个云服务的组合，往往只用了一个云服务，或者用了多个云服务但是多个云服务之间并没有协作关系。

这是阿里云最有技术含量的一个客户成功案例^[5]的架构图，可以看到只涉及 RAM 一个服务。

这是 AWS 一个普通客户成功案例^[6]的架构图，可以看到它灵活组合了多个云服务互相加成。

两者的差距，我个人认为是超过十年的。

3. 创建卡车/轿车/三蹦子/拖拉机/挖掘机五合一的全功能车。

AWS CTO Werner Vogels 认为云服务一个个的基础组件（primitives）^[7]，用户用它们来建造自己的方案。即使 AWS 现在越来越多的提供解决方案云服务，这些解决方案也是利用 AWS 的 primitives 组合而成的。比如 Data Formation 仍然是其他服务比如 S3，Glue，Redshift，Athena，EMR 和 IAM 组合而成。

这种产品管理策略基于一个假设：AWS 的用户是企业雇佣的专业 IT 人士，他们需要自行组合组件的弹性，并且有技术能力驾驭组合带来的复杂性。至于那些喜欢“只需几次点击即可创建网站或应用程序。自动配置联网、访问和安全环境”的微型客户^[8]，则是 Amazon Lightsail 的客户，和AWS 主流客户是隔离的。

很可惜，阿里云的产品管理策略没有这么清晰。试举一例， 阿里云提供了五种专业消息队列服务，云消息队列 RocketMQ 版^[9]，云消息队列 Kafka 版^[10]，云消息队列 RabbitMQ 版^[11]，云消息队列 MQTT 版^[12]，消息服务 MNS^[13]，为客户和其他云服务提供了足够的 MQ 能力。但是阿里云的数据库服务 Lindorm 仍然自行提供消息队列功能^[14]。同时，由于 MQ 功能是 Lindorm 的边缘特性，所以交付得非常简陋，以至于流式引擎的 API 都未提供。严肃的企业客户使用这个半成品，显然有巨大的风险。

另外一个例子是DataWorks。这个服务是一个数据管理的全家桶，它是如此的自成一体，甚至还有自己的运维中心^[15]，简直称得上是云中之云。

打造全家桶是一个双输的事：用户失去了自由组合云服务的灵活性，而云厂商则沦为给大客户定制产品的外包商。

4. 喜欢自己开车，让用户坐副驾驶座位。

阿里云有大量的业务领域应用程序，被当作了 云服务在出售。比如能耗宝

能耗宝是阿里云在ESG和碳中和战略大背景下推出的碳管理+能耗优化的应用服务产品，用大数据计算及人工智能技术，核算碳排量、计算碳足迹、制定降碳方案、规划碳中和路径。联合权威认证机构实现在线认证，联合金融机构提供绿色金融/碳金融服务。能耗宝还致力于让碳普惠融入居民生活，助力以人为本的低碳社区、低碳校园落地。

这不是一个专业 IT 服务，它甚至不能和阿里云其他专业 IT 云服务共享界面风格。它只是一个利用 IT 技术开发的能源管理系统。换句话说，阿里云把云用户应该干的活给干了。

这种行业应用，云厂商很难做到通用性，产品经理只能不停的加功能，把每一个大客户的需求都给堆上去，最后甚至开发起了小程序

为阿里云辩护一句，行业领先者 AWS 也有这种“我能做行业应用”的错觉。Amazon Lex和Amazon Comprehend Medical分别是客服行业和医疗行业的应用。我个人体验的结果是：超级难用，简直脑残。

总而言之，产品团队不给力的结果就是，标准产品给云厂商创造的营收的占比低，厂商不得不依赖于大量的非标产品去拉高营收。非标产品团队在内部的话语权也相应的盖过了产品团队，造成一种恶性循环。最后，整个云厂商团队围绕着少量的 KA 跪舔，自己

行销团队需要明确企业客户的画像

云厂商营销团队不尊重企业客户的专业性，用各种轻浮手段搞营销是一个行业痼疾了。几乎每个礼拜，都会涌现出新的浮夸材料。阿里云最新赞助的一个广告，标题是《女大学生第一次买服务器》^[16]，一个专业 IT 厂商广告用女大学生第一次这种没品的噱头，只能让正经用户大摇其头。

广告的内容也很业余，就是拉小白去阿里云上开虚拟机，给客户造成一种“云计算就是虚拟机大池子”的错误印象。

广告主说：

我觉得对于一位程序员来说，一个优惠的服务器是一个基本装备，不管是搭建个人博客，个人网站还是实验作业什么的，都要必备一台好的服务器。

这里面每个判断都是错的：

1. 搭建个人博客的客户，可以用阿里的语雀，免费。

2. 服务静态页的小型网站，可以用参考《9.9 元的服务器太贵，继续降本十倍》使用阿里云的对象存储，每个月9毛9。

3. 至于大数据实验，或者消息队列实验，或者 K8S 实验，都应该去使用相应的云服务。在虚拟机上自行安装软件是成本最高效率最低的方式。

当然我不是在指责广告主，显然，对这种业余水平的技术主张应该负责任的，是赞助她的阿里云营销团队。

当云计算从业者抱怨“中国大企业对云计算有误解”的时候，他们有没有想过，云厂商自己的行销团队给客户灌输了多少错误的印象，又花了多少精力给客户传递先进的理念？

销售队伍需要和企业客户真实对话的能力

和安利洗发水不一样，云计算作为一个高科技产品，销售过程需要解决方案架构师（SA）的参与。这个架构师应该是客户和阿里云服务之间的一个导航员，在了解需求之后，能给客户一张好用的参考路线图。但，实际情况是这样的吗？

我们可以看一下阿里云SA的招聘广告^[17]。

阿里云智能-公共云高级解决方案架构师（泛互KA）-华北

1、具备Java/PHP/Go/C++/nodejs/Python等至少一种语言的3年以上的开发经验，具备大型互联网应用后端系统设计开发经验或大数据/AI平台构建经验。2、在互联网细分行业中，具备一个及以上丰富的行业业务和技术经验，了解产业链上下游，了解商业模式，能够把握行业当下的业务和技术发展趋势 3、具备优秀的沟通交流能力和方案宣讲能力，能够主动挖掘客户需求，引导解决方案的设计并推动阿里云产品技术团队进行落地 4、在物联网、5G、区块链、机器学习等新技术方向上，保持强烈的好奇心，勇于进行创新实践 5、有技术型方案的POC能力 6、具备优秀的材料沉淀总结及方案输出能力 7、具备良好的团队合作精神、勇于挑战自己、承担压力 8、有担任创业公司产品技术负责人经验者优先，百万级DAU系统架构经验者优先 9、有互联网用户增长、流量变现的运营和技术实践经验 10、有开源社区代码提交经验者优先 备注：有阿里云技术认证ACP（阿里云专业认证）者优先

可以看出阿里云期望的完美候选人是曾经的“产品技术负责人”，夹着漂亮的简历走进客户的会议室，打开“优秀的材料（PPT）”，用“优秀的沟通交流能力”和客户谈“产业上下游”的“商业模式”，然后参与客户的“流量变现”方案，并影响客户的“百万DAU系统架构”。技术方面，他最好懂”物联网、5G、区块链、机器学习“，写过代码，但是不需云上生产经验，不需要懂云原生设计模式，不需要用过IaC等云工具，甚至不需要了解云产品。

鉴于招聘要求和实际工作需要会有差距，我们可以合理的推测：我在互联网公司写过三年代码，道听途说一些行业八卦，能和客户 CXO 吹水，还会写PPT，能抓到人做PoC，基本就可以应聘阿里云 SA 了。我甚至都不需要用过阿里云。

顺便一提，上述职位描述对 DevOps 的理解非常过时了。DevOps 是一种流程和组织方式，不是一个 IT 子系统。

帮助发展中客户构建业务系统、监控体系、DevOps、大数据、AI等子系统，从成本、效率、稳定性三个维度提升客户的IT能力。

我们再看看 AWS 合作伙伴 NordCloud 对同类岗位的招聘要求^[18]：

AWS云架构师

• 熟悉并具有 AWS 的实践经验（其他公共云服务如Azure和Google Cloud也是加分项）

• 具有自动化和基础设施即代码工具的实践经验（如Terraform, CloudFormation等）    ◦ 倾向于通过自动化完成任务，而非手动更改具有脚本编写经验    ◦ 熟练掌握一种编程语言（如Python, Bash）    ◦ 熟练使用shell和AWS CLI

• 使用脚本自动化并连接服务间的代码熟悉DevOps/DevSecOps和/或平台工程方面的知识和经验

• 至少3年在欧盟内的工作经验

• 流利的英语和瑞典语沟通技巧

让你脱颖而出的条件（以下任何一项都是大加分）:

• 理解本地技术（如VMware, OpenStack或Hyper-V）

• 容器技术（Kubernetes, ECS, Docker）

• 构建CI/CD管道配置管理系统（例如Ansible, Chef, Puppet等）

这里的技术要求不高，但是几乎每一个要求都是实实在在的硬技术，并且候选人不仅要懂，还要能动手。也就是他跑到客户现场，能和客户的一线工程师直接对话，这实际上也是工作的一部分：

• 为技术团队举办研讨会并提出设计建议

全世界的 SA 头号 KPI 显然是帮助销售拿下客户，但是从客户的角度出发，云厂商的 SA 价值是什么呢？我作为甲方，对云厂商 SA 的定位非常明确：用云技术解决我的 IT 技术问题。

这个定位有两个延伸含义：

1. 云厂商不应该用传统技术来解决客户的 IT 技术问题。

一个很典型的例子是，云下存储的主力是文件系统，但是云上存储的主力是对象存储系统。如果阿里云 SA 只会给客户推荐 NAS 做简单的替换，而不能在合适的时候推荐云原生的 OSS，那么客户就无法感受到云平台的技术优势，只会感受“云计算太 TMD 贵了！”。

在这个意义上，有“百万级DAU系统架构经验”的阿里云高级 SA 由于缺乏云经验， 其实是不及格的。

2. 云厂商不应该试图指导客户的业务发展。

技术团队显然应该了解业务需求，这没有疑问。但是乙方 SA 不管经验多么丰富，其对客户业务的认知不可能超越甲方技术团队。一个分不清放射科医生和放射技师的 SA，跟客户大谈医学影像共享中心；一个只做过摄像头的 SA，给客户写平安城市顶层设计；这种越界是对自己专业性和客户能力的双重不尊重。我本人是金融行业的，如果一个云厂商的 SA 过来不跟我谈EventBridge，而是跟我谈金融行业“当下的业务和技术发展趋势”，我只会给他鼓掌然后让他滚蛋。

研发团队需要提升软件工程素质

现代软件开发过程中，文档是一个很重要的产出。对于云服务来说，文档更加是产品的核心，其重要性甚至超过了实现代码。这是因为云服务的代码并不对客户开放，文档和API塑造了产品的形态。

我年初写过一篇文章《为什么阿里云有这么多低级错误》，阿里云的朋友找到我，说他们内部发起了文档整改。我对阿里云朋友虚心听取批评的态度表示赞赏，但是现在一年过去了，整改效果并没那么好。和年初一样，我仍然只需要花五分钟就可以在阿里云文档中找出一个错误链接范例。

在 Serverless 应用引擎的《设置Prometheus监控》^[19]页面，有一个链接如下：

下图为基础监控各项指标的默认布局，如果您需要自定义面板，可以选中目标区域，将其拖动至指定位置。更多信息，请参见基础监控大盘^[20]。

这个基础监控大盘链接确实没有返回404，但是它跳转的链接很明确的告知客户

No dashboards matching your query were found.

我起点是一个中文页面，却跳转到英文的 Prometheus 界面去了，整个界面也没有提供切换中文的按钮。

文档这么简单的东西，一个厂商都管理不好，那么客户平日看不到的产品版本管理，代码可测试性，系统可靠性，产品可持续性，产品正交性，客户怎么相信你管的好呢？你怎么能宣称自己和 IBM， 甲骨文，VMware 是平起平坐的专业技术提供商呢？

在这个方面，我认为包括阿里云在内的国产云厂商，和美国同行的差距不是十年，而是十七年：AWS 第一天的软件工程质量比他们今天的水平还高。

对此有疑问的朋友可以去读 AWS CTO Werner Vogels 在2006年6月和传奇计算机科学家 Jim Gray 的对话《A Conversation with Werner Vogels - ACM Queue^[21]》。对话内容覆盖了软件工程的很多方面，从具体的用什么IDE， 到宏观的需求管理，都有涉及。

在软件工程质量得到明显改进之前，我认为阿里云很难获得企业 IT 团队发自内心的尊重。

所有团队在 IT 安全上要表现出专业度

我不是安全专家，无法准确的评估阿里云的安全能力。但是今年 Kubecon NA 上以色列安全从业者^[22]Hillai Ben-Sasson分享的^[23]这个攻击阿里云的案例^[24]，实在太离谱。

根据Ben-Sasson的描述，阿里有如下几个很明显的错误：

1. 选择了隔离性很差的普通容器跑客户实例。

2. 在用户容器和管理容器之间没有必要的大量共享资源。

3. 没有应用阿里云自己宣传的精细化授权^[25]，赋予了一个credential没必要的写权限。

这一系列的低级错误，让Ben-Sasson一步步的发现，最终他获取了让其他云用户运行他代码的能力（当然，作为一个专业安全从业者，他通知了阿里云之后再公开该漏洞）。

一个案例并不能证伪阿里云的安全能力，但是令人遗憾的是，阿里云也没有其他案例证明其安全能力。

这和十年前 AWS 的处境几乎是一样的。当时的企业客户的担忧^[26]是：

• 安全问题依然是第一大关注点：客户更青睐于那些在其生态系统内提供先进的（私有的）网络服务的服务提供商，这可以避免公共云网络访问的所有问题。

一个新供应商如果无法证明其安全能力，那么企业客户会很自然的把它归于“尚未证实安全能力”的类别。这是个一票否决指标。最近几次安全故障表明，阿里云在这一方面还有很远的路要走。

需要若干有说服力的的企业客户成功案例

关于客户成功案例，非常讽刺的是，包括阿里云，腾讯云，华为云在内的十几家云厂商干了十多年云计算，一个能说得过去的云原生标杆客户都打不出来。

每家云都只会吹“中石油/国家电网/XX部委用我的云啦”，结果你打开一看，要么用个 IM，要么用个会议系统，能用虚拟机的已经算深度用云了。至于说“上云帮助客户落地 DevOps 提高了 IT 团队交付频率”的结果，那是不可能的。甚至有些案例是云厂商直接给客户外包做应用写小程序，简直丢人现脸。想详细看我怎么寒碜云厂商案例的的朋友，可以翻我去年写的《腾讯云阿里云做的真的是云计算吗?--从客户成功案例的视角》。

但这只是一个阶段性问题，在2013年，AWS 也面临程度稍弱的同样问题。当时，AWS 已经有了壳牌, Adobe, 纽约时报,华盛顿邮报和美国政府机构等企业客户^[27]，但是这些客户只是把部分边缘业务上云，所以广大企业客户的认知是“云适合当餐前开胃菜或者饭后甜点，不太适合当主菜”。我个人理解，Capital One 案例对 AWS 在企业 IT 圈子站稳脚跟有很大的帮助，其重要程度和早期的 Netflix 案例相当。

最后，云计算是技术密集行业，不是资本密集的 IDC 2.0

有些云计算从业者抱怨：“国企云利用国企身份不公平的竞争抢夺国企客户”，我只能坦率的说：如果你对客户的粘性低到今天的国企云都能搬迁你的客户，你做的那玩意不叫云，顶多算是 IDC 2.0。你给客户打三折之后还被搬走，那是市场对你价值的准确反应。

一个客户上了你的云，然后在虚拟机里自行安装 MySQL 和 Apache ，不用你的 IAM 服务，不用你的密码管理服务，不用你的审计服务，甚至不用你的对象存储服务，那云上和云下有什么区别？

客户一直都很公平，客户从 A 厂商收获的是首都在线也能提供的无差别同质服务，客户就会付给 A 厂商与首都在线同等的毛利润。要想获取微软，AWS，甲骨文和 VMware 享受的高科技毛利率，A 厂商就必须让客户切实的拿到高科技带来的生产力提升。

那种当成 IDC 经营的云平台，别说电信云能搬迁走它的客户，个体户冯老板都能搬迁。有兴趣的朋友可以读冯老板的《重新拿回计算机硬件的红利》。如果一个云厂商的心思都花在给客户推荐99元/年的服务器^[28]的时候，就应该预计到自己不会赚钱，因为它的竞争对手会推出《1元/月的云服务器》。

突破这个困局之前，云计算一哥阿里云可能还要在企业客户门口彷徨多年，甚至可能眼睁睁的看着竞争对手登堂入室。

参考资料