7-6 选择云服务提供商 · 波仔的云计算课

📄 一句话概括

选云服务商不是比谁参数高，而是先把【你在乎什么】转成一组权重，再让各家的分数去乘它。这一节要立的是一个顺序：先写权重，再打分——因为反过来做（先看谁顺眼，再补理由）几乎必然发生。而从使用者的角度看，真正要守住的只有三条底线：数据拿得走、证书是真的、先跑一遍。

📝 本节和前面几节的关系

它接着 7-5 往下走：目标定好了（半年后拿哪三个数字检验），接下来要选一把趁手的工具。 而【目标】本身就是选型的输入——你在乎什么，取决于你的目标是什么（Demo 第一列的权重，就是 7-5 那句目标的翻译）。

它同时也是 2-13 那节【术语差异】的自然延伸：那一节说【同一个名词，各家叫法不同】，这一节给出一套【把它们摆到同一张表里比】的办法。

一、选型是把需求转成权重

先说一句最实用的话：选型之争，九成不是发生在【谁更好】上，而是发生在【什么更重要】上。

原因是【谁更好】没有标准答案——对一家公司最好的方案，对另一家可能完全不合适。所以真正能讨论的只有一件事：在这个具体场景里，哪些维度更重要，各占几成。

所以选型的动作顺序是固定的：

列出维度——成本、合规、团队熟悉度、支持、锁定风险……
给每个维度定权重——加起来 100%。
逐项打分——用同一把尺子（比如 1 ~ 10 分）。
相乘后加总——得到总分。

这个顺序的关键在【先写权重】。因为一旦先看了三家的资料再看权重，人会自动把【顺眼那家占优的维度】写得更重——这不是不诚实，是本能。

一个提醒：权重不是拍脑袋定的，它来自 7-5 的目标和 7-2 的清单。 比如清单里合规系统占了三分之一，那【合规与安全】这一项的权重就不该低。

二、动手 Demo：加权评分与它的一次反转

看到什么算成功：

==================================================================================================
【Demo 6】选择云服务提供商：使用者的角度
==================================================================================================

  【一】选型不是比参数，是把需求转成权重

  维度                权重    厂商 A    厂商 B    厂商 C    在看什么
  --------------------------------------------------------------------------------------------
  总成本              30%     7         9         6         谁更便宜
  合规与安全          25%     9         7         8         证书与数据落地
  团队熟悉度          20%     8         5         6         上手要多久
  支持质量            15%     7         8         7         出事时找谁
  迁移与锁定风险      10%     6         7         9         以后能不能走
  --------------------------------------------------------------------------------------------
  加权总分                    7.60      7.35      6.95      A 暂时领先

  【二】权重一变，结果可能就反转

    把【总成本】的权重从 30% 提到 50%，其余按比例缩到 20 / 15 / 10 / 5：

  厂商                原权重下      成本为重时    变化
  --------------------------------------------------------------------------------------------
  厂商 A              7.60          7.50          掉到第二
  厂商 B              7.35          7.80          升到第一
  厂商 C              6.95          6.65          仍居末位

    → 同一份打分，换个权重就换个人胜出。
      这说明【权重才是决策的实质】，打分只是把权重算出来。
      所以要吵的是【成本占几成】，而不是【A 好不好】。

  【三】使用者角度的三条底线

    1. 退出条款：数据能不能完整拿走？要不要付费？
    2. 合规证明：证书是不是【纸面上的】，覆盖不覆盖你要用的服务？
    3. 跑一次试点：挑一个真实但低风险的负载，先跑 30 ~ 60 天。

    这三条不靠宣传页，靠合同和实测。

读结果：

第一张表的分数其实是可以错的，因为它是主观的。它真正的作用是把主观判断摊在桌面上——谁给的分、为什么给这个分，全部要写成文字。 意见不合的时候，争论的对象就从【谁更好】变成了【这一项该打几分】，范围小得多，也吵得清楚得多。
第二张表是这一节的重点。同一份打分，只是把成本的权重从 30% 提到 50%，第一名和第二名就换了位置。它证明了一件事：分数是【算出来】的，结论是【权重】定的。 所以团队真正该拍板的是权重，不是分数。
第三段的三条底线，性质和其他所有维度都不同。它们是【一票否决项】——分数再高，只要数据拿不走、证书是空的，这个选择就不能做。 换句话说：前两张表是在【可选项】里挑最好的，第三条是在确认【这压根是不是可选项】。

三、三条底线，逐条展开

为什么把这三条单独列出来：因为它们在评分表里只是一项，实际上却是【有没有资格参与评比】的问题。

第一条：退出条款（数据拿得走吗）

锁定的代价由三部分组成：① 数据出流量（把数据搬走要按量付费）；② 对专有服务的依赖（用了某家独有的服务，搬走就得重写）；③ 承诺消费（买了包年或预留容量，没到期走不掉）。

三条里最容易被忽略的是第 ② 条——数据搬得走，但代码搬不动。所以能选开源标准的组件就选（这一条对应的是第二章讲过的【开源化潮流】）。

第二条：合规证明（证书是真的吗）

要点是问清三件事：① 是哪一份认证（不是【我们很安全】这种话）；② 它覆盖不覆盖你要用的那个服务（同一家的不同产品，认证范围可能不一样）；③ 能不能提供【纸面文件】给你存档。

第三条：先跑一遍（Demo 只写 30 ~ 60 天，是有道理的）

为什么一定要跑：因为【控制台的顺手程度】【支持响应的速度】【真实账单的样子】，这三样在宣传材料里都看不到。 而它们恰恰是日常使用中最影响体验的部分——一次 30 ~ 60 天的真实负载，比十份白皮书更能说明问题。

四、为什么强调【使用者的角度】

教材这一条的标题特意写了【使用者的角度】，值得点一下。

因为云服务商的角度和你不一样。 它的角度是服务尽可能多的客户，所以它的产品线会越来越全、默认值会越来越松、文档会越来越通用（这在 7-4 讲过）。这些对它是合理的，对你却可能全是负担—— 你只需要其中一小块，却要承担【选项太多而选错】的风险。

所以【使用者的角度】意味着三件事：

服务商的角度	使用者的角度
功能越多越好	够用就行，多出来的都是要学的
默认能用就行	默认往往是松的，得自己收紧
文档越通用越好	要的是【我这个场景怎么做】

这也解释了为什么选型要落到【权重】上：权重就是你把自己的实际需求，从服务商的通用能力里【切出来】那一下。

30 秒实验

打开任意一家云服务商的官网定价页，做一件事：

找一个你实际会用到的规格（比如 2 核 4G 的虚拟机），然后把它的【月费】和【按小时计费的月累计】都算一遍。

看完通常会有两个发现：

按小时付费的总价，往往比【包月价】贵——这是【灵活】的价格。
页面上一定有大量你没看懂的项——那些就是本节说的【服务商角度的产品线】，它们不属于你的权重。

这两个发现合起来就是选型的常识：价格是可以算的，功能是不必全懂的——你只需要认出【哪些是你要的】。

常见误区

错误：选型就该选功能最全的那家。——纠正：功能全对你未必是好事。功能越多，默认值越松、选项越杂、要学的东西越多（这正是【服务商角度】与【使用者角度】的分歧所在）。对能力有限的团队，功能少一点的平台反而更容易用对。 所以选型的标准不是【它能做多少】，而是【我要的那几件它做得好不好】。
错误：先看各家方案，再定评估标准。——纠正：顺序反了会不知不觉地偏心。看了资料之后再定权重，人会本能地把【顺眼那家占优的维度】写重一些——这不是不诚实，是人的认知本能。 所以正确顺序是先写权重、锁定，再去看资料打分。Demo 第二张表之所以能发现【换个权重就换个人】，正是因为权重可以被单独拿出来检查——如果权重是在看完资料之后定的，这个检查就没意义了。
错误：分数算出来谁高就选谁。——纠正：分数是辅助的，不是决定的。Demo 里 7.60 和 7.35 只差 0.25——这个差距远小于打分本身的误差（同一项两个人可能给出 6 分和 8 分）。在这种情况下，选谁都合理，此时该看的是团队更愿意长期维护哪一个。分数的作用是排除明显不合适的，不是从两个都不错的里面硬挑一个。
错误：试点只是走个形式，反正最后还是会买。——纠正：试点的价值恰恰在于它可能让你【不买】。30 ~ 60 天的真实负载，能暴露宣传材料里看不到的三样东西（控制台是否顺手、支持响应多快、账单长什么样）。如果试点只是【先跑通再说】，那它确实就是形式——所以试点开始前，一定要先定好【什么情况下判定不合适】。 没有判定标准的试点，最后总会以【跑通了】收场。

自测三问（点开对答案）

1. 为什么说【要吵的是成本占几成，而不是 A 好不好】？ —— 因为**【A 好不好】是一个没有共同标准的问题**。觉得 A 好的人，**往往是把某个维度看得更重**；觉得 B 好的人，**是把另一个维度看得更重**。**两边都在回答不同的问题，所以永远吵不出结果。** 而**把争论翻译成权重**，问题就变成了**一个可以表决的具体数字**（成本占三成还是五成）。**更关键的是：权重一旦定下来，分数怎么算就是中立的**——**Demo 第二张表那一次反转就是这样被发现的，而不是靠谁说服谁。** 2. 为什么【锁定】的代价里，最容易被忽略的是【对专有服务的依赖】？ —— 因为**前两项是有账单的**（数据出流量看得见数字、承诺消费写在合同里），**而第三项是没账单的**。**你用了某家独有的数据库或消息队列，数据本身用标准格式也能导出——** **但代码里那些专有的调用，导出不了。** 它不会在你签合同的时候出现，**只会在几年后你真想搬家的时候，变成一笔算不清的改造费。** 这就是为什么选型阶段就要**优先挑开源标准的组件**——**不是为了今天省钱，是为了那天还走得动。** 3. 为什么【换一家不比新建一个】在选型这件事上是成立的？ —— 因为**迁走的成本远高于进来的成本**。**进一家新平台：注册、跑试点、按文档搭——快的话几天。** 而**迁走一家老平台：数据要搬、代码要改、两边要并行一段时间、业务不能停**——**7-2 的 6R 清单已经在讲这件事了**（那次搬的是自建到云，这次搬的是云到云，代价结构是一样的）。**所以选型这一步花的时间，是在为未来避免一次大规模搬迁。** 这也是为什么本章把【选择】单独列成一节，而不是塞进流程里带过。

☐ 下一节（7-7 云服务提供商概要：背景）