解析云产品SLA的价值
0
引言
我在2009年就全程参与某SLA99.999%的项目。因为架构设计合理（不计成本但动脑子的冗余），我们从固件到系统到应用到业务升级全部平稳过渡。
今天恰好和朋友聊到了云产品的SLA是否有价值，我就写了这篇速记文章。
1
产品功能才有SLA
SLA就是服务级别协议，就是产品功能多久不出故障，这个概念大都没有疑问，但总有朋友把SLA分成功能和性能两部分。
一个严谨的产品定义，“性能”也属于功能的一部分，所以不存在独立的性能SLA；基于相同的逻辑，诸如实施速度、服务响应、扩缩容是否无缝等细节SLA，都属于产品功能的标准定义。
2015年的虚拟机网卡只承诺能联通但没承诺内网IO和IOPS，当时客户真就为内网IO可用10G，IOPS轻松过万，否则就投诉和索赔。
一个可以随时无缝扩容的云硬盘，和一个扩容就死机丢数据的云硬盘，它俩根本不一个产品。
2
先说明外宣性SLA
外宣SLA和产品真实SLA的数值可以毫无关联，本段是分析外宣性SLA，其他段落都是谈的产品真实SLA。
外宣性SLA属于产品包装第一部分，这是必备的产品信心展示和商务承诺，以及客户做冗余设计的理论基础。
很多产品线放在官网和PPT上的SLA，主要是以信心展示为目的，贴着客户的期望值和友商的吹牛值做定义。在我来看，只要真按照SLA承诺给客户赔钱，就算拍大腿的SLA也不算糊弄客户。
真正羞辱糊弄客户的外宣性SLA，就是产品描述模棱两可和关键点缺失，用你家产品像在上阅读理解课，客户做冗余设计的基础数据非常模糊，客户做商务索赔的底气不足。
大客户技术部门做冗余设计时，根本不信任云平台的SLA，他们就把云资源按IDC标准来规划，只有商务采购会记住这些授人以柄的漂亮话往死里索赔。
云端小客户没有实质性SLA评估和冗余设计能力，所以对SLA宣传一般也只是略过。
3
SLA能决定产品成本
产品成本和产品SLA强关联，不计成本的SLA就不是一门生意。
一个产品没有SLA，或者拿外宣性SLA糊弄公司管理层，则该产品的成本估算、利润估算都是有风险的。
产品审核管理者必须盯紧主力营收型产品的SLA是否数据清晰符合逻辑，如果允许产品经理对SLA推导过程糊弄敷衍，先是会平台故障客户流失，应激反应后很快就会莫名亏损。
过去SLA推导过程可以糊弄，那是因为云产品的成本和利润都可以糊弄，但现在公有云已经进入红海了，主力营收型云产品都要实现盈利。
产品审核管理者有等同于设备采购的技术背景即可，产品经理要负责完成SLA推导工作和解释责任。
4
SLA的促销效果很差
云研发都有朴素的希望，认为做高SLA做出尖峰性能很有业务价值；但实际上SLA的促销效果非常差，因为时代已经变了。
2015年做云，因为友商故障特别高，此时你家云的SLA过99%就非常优秀，客户愿意为这份稳定性买最贵的云主机，那时的云运维能做客户的座上宾。
但只用了两三年时间，各云主流产品的SLA已经都到99.5%以上了，此时再通过SLA来促销已经比较尬聊了，谁出故障客户就索赔和迁走，不出故障也别想加钱。
我有个好玩的头脑风暴，如果产品SLA“从业内均值99.95%提高到我司独有99.96%”为卖点，各云没有能执行SLA促销的人力。
初中级云研发工程师无法解释这种粒度的SLA推导过程，只有核心研发才能解释为何SLA提高了千分之一。
极少数精英产品经理能听懂但只能靠故障去验证这个SLA数值的可行性，普通产品经理对研发的可行性评估机制彻底失效。
售前和销售能照着念PPT和各种评测获奖记录，这就是他们对千分位SLA最大的尊敬。
客户的技术工程师一般分不清友商吹的99.999999%有多大水分；客户的采购负责人对SLA的要求也很模糊，除非业务这边有SLA硬性准入门槛，否则采购不会为超出友商的SLA付费。
从客户多云冗余的角度考虑，如果大部分云厂商的SLA是99.95%，只有你家做到了99.99%。客户尽量会统一按照99.95%做冗余设计，只有小概率会去依赖你的99.99%的云产品。
5
SLA能给产研自保
SLA是个很好的产研自保工具，清晰的SLA承诺可以明确自己的能力范围。
承诺是个双向信誉约束，我经常跟别人承诺“某事今天一定做完”，潜台词就是“没到午夜就别催我”。
过去产品线搞“模糊承诺”可以坑客户坑同事，那是因为客户是贴钱沾光的，公司追求产品线快速增长。但是随着云行业走向盈利，客户、销售、售后的话语权越来越强，产品线搞“默认模糊承诺”可以被理解成“啥事都该立刻马上做到100%完美”。
如果客户要超出SLA承诺的服务，产品线可以拒绝定制也可以勇敢承接，这可比“模糊承诺”的相互试探和相互抱怨爽快多了。
6
深挖SLA的平台价值
如前文描述，抓主力营收型产品的SLA是为了排除风险，SLA吸引客户的价值不大，产研自保也不产生业务价值。
但云厂商从全局角度仍然要关注产品SLA，SLA不仅仅是技术功过晴雨表，更是云厂商深挖后台硬功的一个重要基础。
6.1 通过合理降低SLA，云平台的成本还能降低20%。有一些产品有超高到不合理、客户也不买单、拍大腿定的SLA，现在产品经理应该出面把SLA降下来降低成本。
我至今咬牙切齿的回忆，我查处过某些运维技术团队，自称有技术洁癖不让降低维护标准，深挖质疑后发现就是懒惰、无能和谋私。公司亏不亏钱不心疼对吧，那也不能丧失工程师的荣辱心啊？
对于研发团队，没有提高SLA的技术、有高成本高标准SLA技术、有低成本高SLA技术这是完全不同的三码事，谁也别想偷换概念浑水摸鱼。
6.2 随着各大云厂商招揽高手和调整目标，云技术团队做攻坚研发，完全可以在成本不变的前提下提高SLA，那就有很大概率在SLA不变的前提下降低成本。
我举不出具体的例子了，大概思路就是高手从性能角度来优化代码，高手做取舍减少过度兼容，高手们拥抱新硬件新软件。
6.3 IaaS云产品不仅卖给客户，更是PaaS云的基础设施。支撑性IaaS云提高了自己的SLA，就可以降低关联产品的SLA成本压力。
从产品演化前景上，我认为PaaS云会逐步取代IaaS云，给PaaS云产品减负的工作会越来越重要。
如果一个PaaS服务依赖的IaaS资源SLA提高了千分之一，因为是同公司可以相互信任，PaaS云在自身SLA不变的前提下，很可能优化大量成本。
因为出现了新利益新变化，跨产品线的管理考核也要做一些微调。
6.4 最后我有个盲目的隐忧，当SLA高到一定程度时，我们的故障修复的难度是更大还是更小了？
优化成本优化SLA必然追求极致精细和系统自愈，如果这个系统出现了计划外故障，靠人工干预的稳定性、可靠性、可恢复性难度都会进一步增大。
如下图的全地形挖掘机，操作特别复杂；但虽有这个隐忧，硬扛着也要干下去。
7
SLA带来产品分化
本文最后章节，我还是唠叨一下SLA给云产品带来的变化，那就是产品细分化。
产品细分的意思简单，通过不同的SLA将一种产品区分成多种产品。
例如云主机变成慢速云主机、快速云主机、SVIP云主机等等。
这种变化要求产品经理对技术成本、客户场景都有深刻的理解，也需要销售、技术支持和客户的配合理解。
比如某产品要用公网带宽，网络延迟增大5毫秒是否还能支撑业务，这5毫秒的延迟能降低多少成本，客户该如何配合迁移？
夜已深了，本段内容我就不写太多了，我只抛出一个真实的案例供大家品味。
某综合性巨头的业务部门和云计算部门通力合作，业务部门将一部分资源打标签为“慢速低优先级”，允许云平台适度调度这些云主机和容器。从业务部门角度，他们节省了上万台服务器的月租开销；从云产品线角度，他们节省了上万台服务器的空置成本。
这也是我在6.1部分提及，降低SLA能节省20%成本的案例基础。