背景
SRE（Site Reliability Engineering）是Google于2003年提出的概念，将软件研发引入运维工作。现在渐渐已经成为各大互联网公司技术团队的标配。
美团点评作为综合性多业务的互联网+生活服务平台，覆盖“吃住行游购娱”各个领域，SRE就会面临一些特殊的挑战。
业务量的飞速增长，机器数量剧增，导致人工维护成本增大；而交易额的增长，对SLA的要求也不断提高。与此同时，一些新业务会面临大流量冲击，资源调度的挑战也随之增大。 业务类型复杂多样、业务模型千差万别，对应的技术方案也多种多样，因此SRE的整体维护成本大大提高。
根据上述挑战，我们需要制定相应的解决策略，策略原则主要聚焦在以下三点：
1.稳定，这也是SRE工作的核心。 效率，包括云主机交付效率，也包括我们自己内部的一些系统效率。 成本，用最少的机器提供最优质的服务。
2.在此原则的基础上，我们开始了对SRE进行的一系列改进。
3.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。