美团点评的SRE发展与实践-InfoQ

本文根据作者在美团点评技术沙龙第 21 期的分享记录整理而成。

背景

SRE（Site Reliability Engineering）是 Google 于 2003 年提出的概念，将软件研发引入运维工作。现在渐渐已经成为各大互联网公司技术团队的标配。

美团点评作为综合性多业务的互联网 + 生活服务平台，覆盖“吃住行游购娱”各个领域，SRE 就会面临一些特殊的挑战。

业务量的飞速增长，机器数量剧增，导致人工维护成本增大；而交易额的增长，对 SLA 的要求也不断提高。与此同时，一些新业务会面临大流量冲击，资源调度的挑战也随之增大。
业务类型复杂多样、业务模型千差万别，对应的技术方案也多种多样，因此 SRE 的整体维护成本大大提高。

根据上述挑战，我们需要制定相应的解决策略，策略原则主要聚焦在以下三点：

稳定，这也是 SRE 工作的核心。
效率，包括云主机交付效率，也包括我们自己内部的一些系统效率。
成本，用最少的机器提供最优质的服务。

在此原则的基础上，我们开始了对 SRE 进行的一系列改进。

SRE 演进之路

手工时代

最早期，我们前端是 4 层负载均衡，静态资源通过 Varnish/Squid 缓存，动态请求跑在 LAMP 架构下。这个时候机器很少，需要的流程很少，也没有区分应用运维、系统运维之类的。运维人员也很少，网络、机器和服务都要负责。运维的工作大部分都是靠手工，其实当时还没有成型的运维系统，现在很多初创公司都是这种架构。

云基础设施

随着业务的发展，我们的架构也做出了适当的调整。尤其是在步入移动时代以后，移动的流量比重越来越大。接入层不只是 Web 资源，还包含了很多 API 接口的服务。后端的开发语言也不再局限于 PHP，根据服务需求引入了 Java、Python、C++ 等，整个业务架构开始向微服务化变迁。伴随业务架构的变化，底层的基础架构也随之改变。最大的变化是，2014 年中的时候，所有的业务已经都跑在了云上，如下图所示。

(点击放大图像)

跑在云上的一个好处是把底层主机和网络抽象化，相当于云平台将主机创建、网络策略修改等封装到相应的系统内，对用户提供统一的平台接口。我们在做维护的时候，就能把之前很复杂的流程串连起来。也是在此时，SRE 团队初步成立，我们对整个运维相关的工作做了拆分。云计算部分（由美团云负责）主要负责主机、网络，还有系统相关的；SRE 对接业务侧，负责机器的环境、业务侧的架构优化以及业务侧相关问题的处理。

问题＆解决方案

接下来介绍一下我们在做云基础建设的过程中，遇到的问题和一些解决方案。

(点击放大图像)

如上图所示，首先是资源隔离的问题，因为这个问题，造成过几次故障。我们线上VM 的CPU、网卡都是共享的，有一次，压测的流量很高，把主机网卡的带宽基本上都占光了（当时的主机大部分都是千兆的，很容易打满），同宿主机的资源都被它争抢了，其它VM 上部署的服务的响时间变得很大，导致当时我们买单的一个服务（买单的VM 和压测的VM 部署在了同一个宿主上）直接挂掉了。

针对这个问题，我们做了两点，一个是对所有的网络资源都做了隔离，针对每个VM 作相应的配额，另外一个是针对业务特性将宿主集群做了拆分。离线业务，它不考虑CPU 的竞争，各个业务对于所部署服务的具体响应时间不是很关注，只要能在一个允许的时间段内把业务跑完就可以了，我们把这些服务单独的放在了一个离线集群。在线业务，根据不同业务的重要程度，又划分成了多个小集群。

第二个问题就是VM 打散，这个问题初期的时候暴露得并不是很明显，当时整个线上的业务还没有做细致的服务化拆分，服务都部署在一个大集群内，这种情况下即使VM 没有打散（同一个服务的多个VM 在同一个宿主），某一个宿主挂掉，影响也不是很大。但是随着业务的变化发展，再做服务化拆分之后，线上的服务基本上没有几百台做成一个大集群的情况，都是十几台，或者几十台这种小集群。

如果我们有一个10 台VM 的服务，其中5 台在一个宿主上，那么这个宿主一旦挂掉，服务整体的承载能力就砍掉了一半，风险很高，高峰期如果掉一半，这个业务就瘫痪不可用了。针对这个问题，SRE 团队跟云计算的同学做了一个持续了半年多的优化，将VM 打散率控制到了90% 以上，最终在同一个宿主上，同一个服务，不会多于两台VM。

第三个问题，完善调度成功率。经过SRE 和云计算同学的合作努力，现在的成功率已经达到了3 个9 左右。

云计算基础设施架构

(点击放大图像)

上图是我们云计算基础设施网络相关的架构图，可以看到上面是公网的入口，流量接入大部分都是走的BGP 链路。往下是多机房间的高速专线，专线的稳定性经历了线上大规模业务的校验，像外卖、团购、酒旅等，都是做多机房部署的。

另外就是高冗余的网络架构，基本上每个节点都有一个冗余设备，能保证在其中一台设备出现问题的时候，整个流量不受影响。入口和出口接入了一些自研的组件，像MGW（参考之前的博客文章“ MGW——美团点评高性能四层负载均衡”）、NAT 等，使我们对流量的管控变的更灵活。

美团点评应该是美团云最大的用户，美团云能给美团点评带来的收益有完善的 API 支持、高度定制化资源的隔离、调度机制，还有多机房光纤直连以及较高的资源利用率。

运维自动化

随着订单量和机器数的高速增长，为了更高效的运维，我们不得不往自动化的方向发展。

在自动化演进的过程中，我们总结出了自己的一套方法论。

复杂的事情简单化。比如引入云平台，基础设备管理都通过云平台的系统来做，把底层相关的东西全部封装，最终暴露给我们的就是接口或 Web 界面。
简单的事情标准化。如果你想做流程或者自动化，没有一个统一标准的话，你要考虑的点就会很多。所以我们在主机、域名等资源的命名、系统基础环境、上下线操作等方面，出了很多的标准，这些标准经历线上的实践打磨最终形成统一的规范。等标准都成型之后，我们再引入流程，比如创建一些机器，我会列出需要的操作，然后根据标准来做 SOP，先流程化再自动化。我们通过代码把手工的工作释放掉，最终达到了一个自动化的水准。

(点击放大图像)

这是服务树，它包括线上的云主机、服务及服务负责人的映射关系，根据不同的层级做一个树形的展示。它将多个周边系统进行打通，因为上面有标签，通过这个标签能识别唯一的服务。目前我们打通的系统有配制管理系统、容量系统、监控平台等，还包括线上主机的登录权限。

另外最新的一个成本核算，服务树也已经打通，通过服务树的节点，只需要进行简单的操作，就能看到每个事业群的成本情况。

(点击放大图像)

上图是我们创建机器的一个简单流程，首先由技术人员发起流程，然后到流程中心，流程中心从服务树获取服务的基础信息，然后将信息发送到运维平台，运维平台根据这些信息去云平台创建机器。

之后云平台会返回到运维平台，运维平台将创建好的机器加到流程中心提供的服务节点下，同时调用配置管理系统对机器进行环境初始化，初始化完成后会自动添加基础监控信息。之后调用部署系统，对服务进行部署。部署之后，服务根据它的服务的标签，最终注册到服务治理平台，然后就能提供线上服务了。相当于只要技术人员发起，整个流程都是能自动完成的。

自动化这块就简单介绍这些，下面介绍一下目前的现状。

数据运营

(点击放大图像)

如上图所示，现如今公司规模变得很大，我们对此做了一些相应的拆分，图中红色的部分全部由云平台来负责，从最初的接入层到底层的一些基础设施，比如机房、网络、主机，全部由云平台来封装。中间又拆封了一层，这一层是由SRE 来负责。

现在流程系统已经做得比较完善了，接下来我们新的探索目标就是数据运营这块。首先是故障管理，针对线上故障做一个统一管理，包括故障发生的时间、起因、负责人，根据它的严重程度，分为不同的故障等级。我们也会针对故障的后续改进持续跟进优化，保证每一个TODO 都能落实。

另外一点，通过故障平台我们对所有的故障进行汇总，系统能根据汇总的信息对不同的故障进行分类，也能总结出我们线上不同故障类型的占比，进而做一些定点的突破。

在故障管理之后，我们又做了一些数据挖掘相关的工作，在初期，我们运维的数据主要来自于监控平台或者是业务主动上报，而在现在这个阶段，我们会主动挖掘一些信息，比如线上服务的请求量、响应时间等来做一些定向的分析。

职责& 使命

(点击放大图像)

如上图所示，我们的使命从最开始的变更与救火，到现在已经逐渐转变为防火与驱动变革。通过数据运营，我们能反向的驱动业务。工作核心是稳定性，这一点一直没变。

我们可以把运维理解为运营维护，运营是指通过经验积累、数据分析，推动整体服务质量的改进；维护是针对线上的服务，还有业务的需求，我们能够用专业的技术来满足他们。

下面讲一下在稳定性保障方面的实践。

业务稳定性保障实践

故障起因& 实例

首先，我们来总结下故障的起因，同时举一些例子来说明具体的情况。

① 变更。美团点评线上服务的日常发版超过300 次，另外还有一些运维的基础变更，包括网络、服务组件等。举个例子，线下做变更的时候，我们写一个简单的Nginx 配置，如下图所示。

(点击放大图像)

它和线上写的配置，在红色部分的顺序发生了变化，如果rewrite 的指令在set 指令之后，可以生效，结果符合预期。当我们把rewrite 指令前置后，break 指令会被先执行，会结束整个重写过程，rewrite 之后的set 就不执行了，导致配置上线之后，Nginx 找不到后端的服务，整个线上的服务就崩溃了。如果做好充分的灰度，我们就能及时发现问题并解决，但是我们在上线的过程中缺少了灰度过程。事实上，标准的SOP（标准操作程序）应该是上图中的五步，但是负责变更的同学想当然也好，或者是粗心大意也好，在线下测试以后没有发现异常，就直接全量上线了，最终酿成大祸。

② 容量。一些大的节假日或者秒杀抢购都会带来大流量，异常流量攻击或者爬虫抓取也会带来流量突增。如下图所示，这是猫眼发生的一次较大的事故，这个故障主要的原因是最底层的、最后端的服务容量不到位，在流量发生大的变化的时候它没撑住，关键的服务峰值上涨5 倍，DAU 相交元旦（前一个历史峰值）涨了一倍。

(点击放大图像)

主要是两个问题导致的，一个是我们对于大的活动评估不准确，还有一个是它的容量不对等。相当于前端的应用评估是可以撑住的，但是后面的底层没有撑住，前端的流量都打到后端，后端撑不住，整个服务就挂了。由此，我们至少要做到两点，第一要知己，了解自身能承载的容量情况，这点我们可以通过压测或者一些历史数据的参考获取到这个容量。第二要知彼，准确知道前端过来的流量究竟有多大，可以通过运营和技术的联动，在出现一些大的活动或者大的节假日的时候，通过他们的容量评估和历史数据做出相应的判断，进而做一些容量的准备；另外，要了解下游系统的容量水位，一旦低于本服务的容量，我们就要做好限流，并且提醒下游服务做相应的容量匹配。

③ 隐患。隐患主要针对系统设计存在的一些缺陷，还有一些组件的交叉调用、关键报警的缺失、链路容量不对称等。这类问题是比较难发现的，需要我们深入进行研究。这方面的实例我们可以看下下面这个图，没有操作之前，它的数据包是沿着绿色的线走的，做了操作之后，部分数据包就沿着红色走了。变更前后的主要影响是，红色链路的数据包session 发生了变化，因为最初的时候session 在IMGW1 上，在链路发生变化后，对于TCP 有状态的连接，再往后就找不到它后端了，数据包没办法发送过去，这时候数据就丢失掉了，无法连接数据库，这个业务就挂掉了。

(点击放大图像)

不过业务层在设计架构之初，应该考虑到网络不稳定的情况。针对上面的隐患，大概有三个方法。

第一个就是做全链路的演习，模拟一个真实的场景，经过模拟演习，还是多多少少能暴露出来一些问题。我们可以针对这些问题，去完善我们的故障预案、修复线上漏洞，做演习的时候也能验证我们的报警系统是否正常运转。

第二个是 SLA，对于服务定一个比较严格的稳定性指标，并针对这个指标持续不断的优化。比如我们线上 HTTP 接入的服务，针对 accesslog 中的状态码和响应时间提炼出一个稳定性指标，这对于服务本身的稳定性情况，就多了一个可参考数值了。稳定性指标波动服务必然有问题，这时候我们就要针对它波动的点进行相应的分析，根据分析，最终能找到一些隐患。指标这块，要做到用真正的数据来反馈出线上的稳定性。

第三个就是做故障的管理，每个故障都能找到问题，TODO 能落实，各个故障的经验总结，也能共享到多个业务线。

经验总结

事故之前（比如标准 SOP、容量评估、流量压测）的核心就是要防范于未然。
事故之中的核心是快速止损，查找问题是一个相对来说难度比较大，也比较漫长的过程，因为这个时间是不可控的。但是如果我们提前有好的应急预案，就能达到快速的止损。此外，还要有服务的自我保护，还有一点，沟通也是很重要的。最开始出现问题的时候，其实是比较乱的，因为大家发现问题都很急，很多人都在问原因，这时候你问原因是没有用的，因为大家大部分是不知道，知道的话就能给出解决方案了。所以这时候需要一个完善的沟通机制，正确的时间反馈正确的消息，反馈的原则是少说表面现象，尽量说一些对于问题定位或者是对于止损方面能够有帮助的信息。
事故之后，像 TODO 落实、完善预案之类的，核心点就是吃一堑长一智，相同的问题不能发生第二次。

用户体验优化

首先从用户端开始，用户在访问我们线上业务的时候，流量是从公网到私有云，再到 Server。公网问题主要有网络劫持、多运营商环境、不可控的公网链路等。对于 Server 的话，主要就是一些传输层的协议，或者应用层的协议的问题，目前大部分业务交互还是用的 HTTP 1.0/1.1，其实 HTTP 这个协议也是需要改进的，它不太适合做频繁的业务交互。

针对这些问题，我们都做了一些尝试：

首先在公网接入这块启用 BGP，我们现在已经做了自建的 BGP 网络，不用再关心多运营商接入的问题。只需要采用 BGP 网络，数据包在公网传输寻址的时候，就可以进行最优的选路了。
面对劫持问题，我们尝试了 HTTP DNS 的方案，同时也在尝试 Shark，就是类似于公网链路加速，相当于我在用户的近端部署一个 Server，在 App 上嵌入 SDK，用户通过 App 发起的请求不用做 DNS 解析，而是先发到 Shark（参考之前的博客“美团点评移动网络优化实践”）上，再由 Shark 与后端服务交互。目前通过多种手段的持续优化，劫持问题已经少了很多。
针对业务交互的协议，上线了 SPDY 协议，对于频繁交互的业务提升还是很明显的。目前正在测试 HTTP 2.0，Server 端对于 HTTP 2.0 的支持还存在少量 bug，努力修复中，希望能早日用上。