黄金三问-如何更好的聚焦改进
故障复盘往往被我们开成了批斗会，推诿扯皮撕逼会。
原因就在于我们把故障复盘的目的搞错了，总想着找人背锅，把自己的责任撇清楚，而不是聚焦在如何改进上。
或者我们原本的目的是想着改进，但是开着开着就变了味，遇到这种情况怎么办呢？
黄金三问，转移矛盾和冲突的焦点，让我们更加聚焦如何从故障中提升和改进。
- 第一，故障根因到底什么？
- 第二，我们做什么，怎么做才能确保下次不会再出类似故障？
- 第三，我们做什么，可以让本次故障时间更短，更快地恢复业务？
然后不断反复的重复三个问题，直至大家认为找到了改进的措施。
当然，大家可能还听说过5Why分析法，就是针对故障至少问5个为什么，通常就可以找到比较深层次的原因，或许不是根因，但是一定会比较有针对性了。
这个5Why的方式其实就是这三个问题的延伸，这三个问题会不断牵引着我们的讨论朝着本质问题深入，从我们实际实践的效果看，黄金三问效果会让讨论更加聚焦。
故障容忍度—业务优先还是稳定优先
关于这个话题，之前我们听到过很多，但是大多没有正面PK过。
从运维、SRE或基础平台的同事的角度看，稳定一定是优先的，任何时候都不能放弃稳定，但是从业务同事的角度看，业务发展肯定是第一位的，没有发展，光有稳定会有什么用呢。
正好，近期碰到两个类似的交流，观点也相对一致，这里分享一下。
前段时间去GTLC台北奋战做分享的时候，听环球易购的CTO乔总分享，提到了这一点。
环球易购正处于高速发展阶段，业务迭代速度快，基础设施变化也比较大，这个过程中也会遇到大大小小的故障，但是这里就有个取舍问题，到底是减缓业务开发的节奏，投入一定的时间和人力，一个个故障作分析，做改进，做好定责和绩效绑定，还是保障业务继续往前冲，提高容忍度，这个取舍怎么做？
其实就一个原则，业务在发展，能赚钱，就不要让周边这些小插曲影响了节奏，所以提高容忍度，不要在这个时候拿着故障当成了重点。
当时有个假设，如果每天能挣10个亿，出几个小故障又能怎么怎么样？难道非要把责任定清楚了，纳入到绩效考核里，科学管理了才行？这个时间成本怎么算？耽误的业务发展的收益怎么算？管理不好，对员工的积极性有打击，为竞争对手培养了人才，怎么办？
还有一个是前面参加QCon讲师演讲经验分享，跟社交大厂的总监在路上聊起来的，据说某个广告业务，虽然跟游戏比算不上最大的印钞机，但是赚钱也是哗哗滴，
所以，在他们内部貌似也没人要追着这个系统的故障问题不放，或者一定要怎么样，赚钱才是最重要的。
有的业务上去，两台主机跑起来，有自然流量进来，钱就哗哗地赚，挂了，挂了赶紧重启就行啊，别耽误赚钱就可以，据说容忍度极高。
所以，从这个两个案例来看，业务发展才是一家公司的命脉，在赚钱和故障上怎么做权衡，从上面的角度来看，就不难选择了，一定是业务优先。
当然，这里并不是说这两个业务和公司就会让故障放任自流毫不干涉，而是在业务和故障之间会有一个比较好的权衡取舍，内部仍然会有一些机制来科学地管理故障。
还有一个例外，就是对于提供基础设备和服务的厂商，如云厂商，网络设备、通信设备等等的厂商，这个没得说，一定是稳定优先，所以针对不同的特点，也要做不同的分析。
为什么需要SLO-故障认知标准的建立
关于SLO的定义这里我不做详细描述，大家可以Google或百度，也可以去看Google SRE的第二本图书，都有很详细的介绍。
这里我主要讲一下为什么需要SLO。
SLO的本质就是制定一个标准，使各方对稳定性和故障率形成一个统一的认知。
因为假设没有标准，大家默认稳定性就应该是100%，我们的系统就不应该出现故障。
这个统一的认知，在我们内部可能相对比较容易建立，通过充分的沟通和讨论，大家总会形成一个可接受的SLO标准，但是对外部，就比较困难了。
这里我先举一个例子：
我们现在很多业务都运行在云上，也就是用了很多的云服务，比如我们的直播。
几个月前T云上海光缆被挖断，视频业务受到了影响，基本上70%-80%的视频是无法观看的，从业务特点上，是因为我们绝大部分的主播都集中在江浙沪一带，而北方和华南的主播是比较少的，所以虽然是一个局部地域的影响，对于我们来说，基本就是全局的。
不过，从云厂商的角度来看，实际的监控情况显示，一个地域的部分影响只占全局影响的2%-3%左右，这时对于云厂商就要判断，为了这2%-3%的局部影响，要不要做全局的切换动作，对于其它客户会不会造成影响等等，他就要考虑更多的因素。
所以，仅仅等这样一个决策，就花了很长时间，最终从业务角度出发和考虑，还是做了切换，保障了业务恢复。
这里2%对80%，这个数字上的不一致，就是对稳定性标准认知的不统一。
这里很难界定谁对谁错，要解决这个问题，最好的方式就是引入业务SLO，有一个统一的认知标准。这就要求云厂商要站在客户和业务角度看待问题，为业务稳定性目标负责，而不能仅仅站在自身，站在一整个大盘的角度看自己是不是有问题。
但是SLO的制定和约定，特别是厂商和客户之间的SLO制定，还是会有一些GAP需要填补，或者说对于云厂商的服务要求会更高。比如：
- 云厂商的客户有很多，不同客户的标准也不一样，怎么确保这么多样性的SLO都能达标？
- 没有统一的标准，很容易造成我定了SLO，其他客户也要定SLO，我定的SLO可能是非常严格的，如果不小心把SLO公布出来了，引起很多用户要按照这个标准提要求，这对于云厂商的压力是非常大的，这也是云厂商不敢轻易承诺的一个阻力。
- 一旦为业务稳定性负责，必然就要有定制化的服务，定制化的服务就意味着独立的人力成本付出，这个显然是不符合云厂商的ROI策略的，所以落地时也很难执行到位。
所以，云厂商更多的执行SLA即可，没有必要去达成SLO，其实我一直建议，SLO的达成可以作为附加的增值服务，既然客户要求达到，那就应该付出一定的成本，因为毕竟我们是使用了厂商的专业服务能力，我想随着云计算产业的不断发展和完善，提供有价值的专业服务能力的那一天应该会到来。
在国外，Google就将这个服务包装成CRE，翻译过来就是用户稳定性工程服务，大家如果感兴趣可以在我的公众号中看另外一篇文章《Google SRE之后的CRE，一起来看看吧》。
