e-works数字化企业网  »  文章频道  »  基础信息化  »  云计算和虚拟化

云端的SRE发展与实践

2017/8/13    来源:极客头条    作者:普存      
关键字:云端  SRE发展  
SRE(Site Reliability Engineering)是Google于2003年提出的概念,将软件研发引入运维工作。现在渐渐已经成为各大互联网公司技术团队的标配。

    我们可以把运维理解为运营维护,运营是指通过经验积累、数据分析,推动整体服务质量的改进;维护是针对线上的服务,还有业务的需求,我们能够用专业的技术来满足他们。
 
    下面讲一下在稳定性保障方面的实践。
 
    业务稳定性保障实践
 
    故障起因&实例
 
    首先,我们来总结下故障的起因,同时举一些例子来说明具体的情况。
 
    ① 变更。美团点评线上服务的日常发版超过300次,另外还有一些运维的基础变更,包括网络、服务组件等。举个例子,线下做变更的时候,我们写一个简单的Nginx配置,如下图所示。
 
云端的SRE发展与实践
 
    它和线上写的配置,在红色部分的顺序发生了变化,如果rewrite的指令在set指令之后,可以生效,结果符合预期。当我们把rewrite指令前置后,break指令会被先执行,会结束整个重写过程,rewrite之后的set就不执行了,导致配置上线之后,Nginx找不到后端的服务,整个线上的服务就崩溃了。如果做好充分的灰度,我们就能及时发现问题并解决,但是我们在上线的过程中缺少了灰度过程。事实上,标准的SOP(标准操作程序)应该是上图中的五步,但是负责变更的同学想当然也好,或者是粗心大意也好,在线下测试以后没有发现异常,就直接全量上线了,最终酿成大祸。
 
    ② 容量。一些大的节假日或者秒杀抢购都会带来大流量,异常流量攻击或者爬虫抓取也会带来流量突增。如下图所示,这是猫眼发生的一次较大的事故,这个故障主要的原因是最底层的、最后端的服务容量不到位,在流量发生大的变化的时候它没撑住,关键的服务峰值上涨5倍,DAU相交元旦(前一个历史峰值)涨了一倍。
 
云端的SRE发展与实践
 
    主要是两个问题导致的,一个是我们对于大的活动评估不准确,还有一个是它的容量不对等。相当于前端的应用评估是可以撑住的,但是后面的底层没有撑住,前端的流量都打到后端,后端撑不住,整个服务就挂了。由此,我们至少要做到两点,第一要知己,了解自身能承载的容量情况,这点我们可以通过压测或者一些历史数据的参考获取到这个容量。第二要知彼,准确知道前端过来的流量究竟有多大,可以通过运营和技术的联动,在出现一些大的活动或者大的节假日的时候,通过他们的容量评估和历史数据做出相应的判断,进而做一些容量的准备;另外,要了解下游系统的容量水位,一旦低于本服务的容量,我们就要做好限流,并且提醒下游服务做相应的容量匹配。
 
    ③ 隐患。隐患主要针对系统设计存在的一些缺陷,还有一些组件的交叉调用、关键报警的缺失、链路容量不对称等。这类问题是比较难发现的,需要我们深入进行研究。这方面的实例我们可以看下下面这个图,没有操作之前,它的数据包是沿着绿色的线走的,做了操作之后,部分数据包就沿着红色走了。变更前后的主要影响是,红色链路的数据包session发生了变化,因为最初的时候session在IMGW1上,在链路发生变化后,对于TCP有状态的连接,再往后就找不到它后端了,数据包没办法发送过去,这时候数据就丢失掉了,无法连接数据库,这个业务就挂掉了。
 
云端的SRE发展与实践
 
    不过业务层在设计架构之初,应该考虑到网络不稳定的情况。针对上面的隐患,大概有三个方法。
 
    第一个就是做全链路的演习,模拟一个真实的场景,经过模拟演习,还是多多少少能暴露出来一些问题。我们可以针对这些问题,去完善我们的故障预案、修复线上漏洞,做演习的时候也能验证我们的报警系统是否正常运转。
 
    第二个是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的算法,引入人工智能来做突破。
 
    产品方面,我们现在做的所有工具,经过线上业务大规模的校验,正在往产品化的方向发展,希望能把它做成成型的产品,放在美团云上,能给美团云的用户提供服务。不只服务于我们自己,也服务于他人。
 
    最后是技术架构,美团点评发展过程中一些疑难问题的解决方案,或者针对挑战的经验积累,经过线上大规模业务的校验,最终能形成一些成熟的方案,它能为美团云上的用户提供最前沿的技术参考。
 
    云是大势所趋,它能把很多底层的问题封装起来,让我们有更多精力去做更重要的事情。
 
责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐