另外一点，通过故障平台我们对所有的故障进行汇总，系统能根据汇总的信息对不同的故障进行分类，也能总结出我们线上不同故障类型的占比，进而做一些定点的突破。
在故障管理之后，我们又做了一些数据挖掘相关的工作，在初期，我们运维的数据主要来自于监控平台或者是业务主动上报，而在现在这个阶段，我们会主动挖掘一些信息，比如线上服务的请求量、响应时间等来做一些定向的分析。
职责＆使命
如上图所示，我们的使命从最开始的变更与救火，到现在已经逐渐转变为防火与驱动变革。通过数据运营，我们能反向的驱动业务。工作核心是稳定性，这一点一直没变。
我们可以把运维理解为运营维护，运营是指通过经验积累、数据分析，推动整体服务质量的改进；维护是针对线上的服务，还有业务的需求，我们能够用专业的技术来满足他们。
下面讲一下在稳定性保障方面的实践。
业务稳定性保障实践 故障起因&实例
首先，我们来总结下故障的起因，同时举一些例子来说明具体的情况。
① 变更。美团点评线上服务的日常发版超过300次，另外还有一些运维的基础变更，包括网络、服务组件等。举个例子，线下做变更的时候，我们写一个简单的Nginx配置，如下图所示。
它和线上写的配置，在红色部分的顺序发生了变化，如果rewrite的指令在set指令之后，可以生效，结果符合预期。当我们把rewrite指令前置后，break指令会被先执行，会结束整个重写过程，rewrite之后的set就不执行了，导致配置上线之后，Nginx找不到后端的服务，整个线上的服务就崩溃了。如果做好充分的灰度，我们就能及时发现问题并解决，但是我们在上线的过程中缺少了灰度过程。事实上，标准的SOP（标准操作程序）应该是上图中的五步，但是负责变更的同学想当然也好，或者是粗心大意也好，在线下测试以后没有发现异常，就直接全量上线了，最终酿成大祸。
② 容量。一些大的节假日或者秒杀抢购都会带来大流量，异常流量攻击或者爬虫抓取也会带来流量突增。如下图所示，这是猫眼发生的一次较大的事故，这个故障主要的原因是最底层的、最后端的服务容量不到位，在流量发生大的变化的时候它没撑住，关键的服务峰值上涨5倍，DAU相交元旦（前一个历史峰值）涨了一倍。
主要是两个问题导致的，一个是我们对于大的活动评估不准确，还有一个是它的容量不对等。相当于前端的应用评估是可以撑住的，但是后面的底层没有撑住，前端的流量都打到后端，后端撑不住，整个服务就挂了。由此，我们至少要做到两点，第一要知己，了解自身能承载的容量情况，这点我们可以通过压测或者一些历史数据的参考获取到这个容量。第二要知彼，准确知道前端过来的流量究竟有多大，可以通过运营和技术的联动，在出现一些大的活动或者大的节假日的时候，通过他们的容量评估和历史数据做出相应的判断，进而做一些容量的准备；另外，要了解下游系统的容量水位，一旦低于本服务的容量，我们就要做好限流，并且提醒下游服务做相应的容量匹配。
③ 隐患。隐患主要针对系统设计存在的一些缺陷，还有一些组件的交叉调用、关键报警的缺失、链路容量不对称等。这类问题是比较难发现的，需要我们深入进行研究。这方面的实例我们可以看下下面这个图，没有操作之前，它的数据包是沿着绿色的线走的，做了操作之后，部分数据包就沿着红色走了。变更前后的主要影响是，红色链路的数据包session发生了变化，因为最初的时候session在IMGW1上，在链路发生变化后，对于TCP有状态的连接，再往后就找不到它后端了，数据包没办法发送过去，这时候数据就丢失掉了，无法连接数据库，这个业务就挂掉了。
