云端的SRE发展与实践

运维技术   2017-08-08 15:50:14 发布
您的评价:
     
0.0
收藏     0收藏
文件夹
标签
(多个标签用逗号分隔)

背景

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

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

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

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

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

在此原则的基础上,我们开始了对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支持、高度定制化资源的隔离、调度机制,还有多机房光纤直连以及较高的资源利用率。

运维自动化

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

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

  1. 复杂的事情简单化。比如引入云平台,基础设备管理都通过云平台的系统来做,把底层相关的东西全部封装,最终暴露给我们的就是接口或Web界面。

  2. 简单的事情标准化。如果你想做流程或者自动化,没有一个统一标准的话,你要考虑的点就会很多。所以我们在主机、域名等资源的命名、系统基础环境、上下线操作等方面,出了很多的标准,这些标准经历线上的实践打磨最终形成统一的规范。等标准都成型之后,我们再引入流程,比如创建一些机器,我会列出需要的操作,然后根据标准来做SOP,先流程化再自动化。我们通过代码把手工的工作释放掉,最终达到了一个自动化的水准。

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

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

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

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

数据运营

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

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

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

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

职责&使命

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

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

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

业务稳定性保障实践

故障起因&实例

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

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

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

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

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

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

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

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

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

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

经验总结

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

用户体验优化

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

针对这些问题,我们都做了一些尝试:

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

未来展望

首先技术上,目前我们自动化这块做得比较好,还会持续做,下一步就是智能化。为什么要智能化呢?其实主要面临到一个瓶颈点,有些问题是不能通过自动化解决的,比如说前面提到自动故障定位,它的决策性很强,需要很多步的决策,并不是通过程序就能直接搞定的。我们现在正在尝试一些AI的算法,引入人工智能来做突破。

产品方面,我们现在做的所有工具,经过线上业务大规模的校验,正在往产品化的方向发展,希望能把它做成成型的产品,放在美团云上,能给美团云的用户提供服务。不只服务于我们自己,也服务于他人。

最后是技术架构,美团点评发展过程中一些疑难问题的解决方案,或者针对挑战的经验积累,经过线上大规模业务的校验,最终能形成一些成熟的方案,它能为美团云上的用户提供最前沿的技术参考。

云是大势所趋,它能把很多底层的问题封装起来,让我们有更多精力去做更重要的事情。

作者简介

普存,2014年加入美团SRE团队,现任美团点评应用支持组负责人,带领团队为美团外卖、餐饮平台、金融服务等多个业务提供运维支持及业务稳定性保障工作。

回答“思考题”、发现文章有错误、对内容有疑问,都可以来微信公众号(美团点评技术团队)后台给我们留言。我们每周会挑选出一位“优秀回答者”,赠送一份精美的小礼品。快来扫码关注我们吧!

 

来自:https://tech.meituan.com/meituanyun_sre.html

 

扩展阅读

谷歌GAE运维揭秘:如何做到每天处理超过1000亿个请求
Tumblr 架构设计
小米运维—互联网企业级监控系统实践
与正则表达式有关:sre_yield
大规模集群运维经验(一)

为您推荐

MySql+Memcached架构的问题
NoSQL 在腾讯应用实践
如何选择Docker监控方案
HBase 在淘宝的应用和优化小结
架构的本质是管理复杂性,微服务本身也是架构演化的结果

更多

运维技术
分布式/云计算/大数据
相关文档  — 更多
相关经验  — 更多
相关讨论  — 更多