阿里搜索事业部故障快速恢复实践-阿里云开发者社区

开发者社区> 开发与运维> 正文

阿里搜索事业部故障快速恢复实践

简介:     这篇文章中,我们将讨论面对故障时,我们为什么选择快速切流这种机制。如果选择快速切流,我们需要具备哪些条件,需要切流平台解决什么样的问题。最后,我们畅想故障快速恢复未来如何做的更好。   关于故障的几种解决思路 如何定义故障     我们一般从以下几个维度来定义故障。

这篇文章中,我们将讨论面对故障时,我们为什么选择快速切流这种机制。如果选择快速切流,我们需要具备哪些条件,需要切流平台解决什么样的问题。最后,我们畅想故障快速恢复未来如何做的更好。

一、关于故障的几种解决思路

  • 如何定义故障

我们一般从以下几个维度来定义故障。一是影响的用户数量,例如用户投诉100个或者60%的用户不可使用某功能。二是系统流量下降或者成交下跌,例如成交下跌6%。三是资损,例如广告收入下跌5%。总之,故障是用来描述系统异常对用户或者自身造成影响的一个量化指标。


故障一般分级别P4-P1,严重程度越来越高,故障到P2时就会全集团发周知信息了。故障的定级时要考虑到业务自身的规模和迭代速度。故障级别定义超高时,会让整个团队风声鹤唳经常忙于救火,进一步会影响发布,最后会让大家对于P1P2产生疲劳,不应该对新兴业务定义过高的故障级别。

阿里搜索目前对于故障的定义中,有一条专门鼓励快速恢复:5min内解决的故障,按照原等级降一级


  • 如何看待故障的定责

关于定责的原则,几经修正,即使现在还有争议。之前实行过的有:谁触发谁担责;上游接口变更未通知下游造成的上游承担;下游未按文档或者约定使用上游接口的下游承担;但是,上面的这些原则其实仅仅是为了更好的区分是谁的责任,而我们更应该回到本源,如何让已经发生的问题驱动整个系统向好的方向行进。


举个例子,A业务调用B业务接口,现在A因为变更调整了对下游的压力,把B压垮了导致整个系统流量跌为0。在实践中这是个典型的例子,甚至现在让大家去定责,不同的团队也会有不同的结果。选择A为主要责任可以说是A做了变更触发的,也可以说A私自调整了流量未及时通知B。但是我们可以换一个思路,定责为A团队会让我们的系统自然地向更好的方向演进么?B为什么会在A的压力大时彻底垮掉呢?B声称自己的服务能力为什么在流量大时就不存在了呢?B为什么没有自我保护和自己限流呢?责任该给到谁会让系统变得更好其实就较为清晰的能分辨了。


定责方面,在搜索事业部的实践中。沉淀有以下几点,供大家参考。

出现core导致的问题,不管触发原因,谁写的代码谁的团队承担;

演习时,操作者不承担责任,哪个系统挂掉,对应的团队承担责任;

一个小的触发因素导致一个超大的故障时,恶化的模块承担责任,而不是触发者;

每个模块有责任保护自己声称容量以内的流量和用户,超出流量可以限流但是不能超时,谁超时谁的责任。

阿里搜索目前秉承的基本原则是:谁更应该从系统层面规避,谁的action更倾向于让系统向好的方向演进,就更应该承担责任


  • 如何看待故障的action

一个故障一般是由一连串的问题导致,每个环节都出了问题才会导致一个严重的故障。我们选择做故障的action时有时候会有个倾向,就是加监控。这几乎是个万能的action,但是这背后其实有个隐含的依赖,就是人会处理这些报警,而且是及时处理。显然这个隐含的依赖在很多时候是不成立的。

我们选择故障的action时也应该考虑系统的自我保护,而不是加个监控了事。比如如何实现自动降级,自动限流。自动限流发生时,如何保证永远都不超时,自己声称的服务能力,即使再高的流量也垮不了(网卡未满的情况下),这个单开专题讨论,不展开了。


  • 解决故障的几种思路

当一个故障发生时,当事人采用的第一个处理策略就是我们解决故障的思路。比如:

i. 直接去线上看日志,查到异常后尝试进行恢复;

ii.收到报警后,切流恢复;

iii.尝试让系统自动定位故障在哪个地方,然后尝试去恢复它;

第一种处理方法已经在实践中越来越少的出现,因为现在大原则是先恢复后查问题,除非出现多个机房同时挂掉的情况,否则不是首选。第三种看起来也是一个不错的方向,不过在实践中这个方案的要求极高,需要系统具备:统一接口收集所有的系统指标和业务指标,统一接口收集所有的变更,给每个模块定义何为异常,给模块定义一个恢复策略。先不谈其他恢复策略了,单单一个故障单元的自动替换就有不少系统做不到,所以这个策略目前看还太激进了。

第二种策略是目前交易和搜索采用的核心策略,在收到报警之后,根据报警提示,快速把流量切到服务正常的机房。从实践上看,好一点的可以做到5min以内恢复,差一点的10min也足够了。

但是第二种策略也是有条件的,下面一节讨论快速切流的条件。


二、故障快速恢复的条件

  • 多机房和机房间延迟

如果选择快速切流作为快速恢复的手段,那么就要首先考虑切流的条件。其中就有多机房(多集群)的要求。搜索目前采用的方式是三地三机房部署,既可以做异地容灾,也可以做故障时切流。

切流最好的方式,是用户的访问直接去另外的机房。但是并不是所有的业务都有能力控制上游的入口流量分配。同时也不能因为整条链路上任意模块的故障,就能要求导购或者交易整体切流。所以,业务自身多机房部署和切流能力就是必须的。

如果不是最入口的切流,那上游过来的流量就会产生跨机房访问。跨机房的延迟就必须考虑在内,目前国内三地的主力机房A---B ping值约30ms,B---C ping值约25ms,A---C ping值约37ms。如果业务自身的服务latency远远小于该值那么切流恢复的条件就是不具备的。有时我们的系统有很多个层次,比如主搜索有java层---sp层---ha3引擎---ranking这几个层次。

我们切流时应该尽量选择自身能够控制的最上游模块,因为越往下层latency越低,跨机房的latency增加影响也就越大


  • 容量限制

切流的第二个条件是容量。不能切到其他机房(集群)后,原来ok的机房也被压垮。那这就要求其他机房,在切流模块及以下所有模块的容量,都能保证剩余机房是足够支持高峰期的。这是容量上的限制。

这里所指的容量,一般是指业务可以忍受延迟范围内的最高访问量。


  • 自动降级和容量限制的放宽

上面说的容量要求,其实是一种最初始的限制。自动降级和自动限流可以突破这个限制。自动降级指的是:系统在超出自身正常的服务容量时,采取的一种自我保护措施。自动降级一般是业务逻辑的自动更改,例如当搜索引擎的压力过大时,自动把精排数量减少。自动降级会牺牲一部分效果,但是能够自动的瞬间的提升服务能力,可以抵御突发的流量增加给系统带来的冲击

当流量继续增加,即使自动降级也无法抵御时,应该触发自动限流措施。自动限流指的是丢弃部分超出自身服务能力的请求,同时保证已经接收的请求正常返回。自动限流是非常时期采取的非常手段,不止会影响效果,更会使得部分用户的请求无结果。但这是无奈之举,是大家一起死还是保留一部分服务能力,选择肯定是后者。

如上,当实现了自动降级和自动限流之后,切流这个流量突变的操作就变成了一个相对安全的操作。假设AB两个机房容量各为60%,这时如果切流A--->B那么B机房流量会超出正常容量。B机房发生降级后,服务能力立刻提升50%,切流操作后B机房效果下降。但是可以成功支持住因为故障从A机房切过来的流量。

真实情况可能比上面的更复杂,比如考虑到超线程的影响,cpu运行到60%以上时性能会迅速恶化。三机房甚至更多机房的建设,可以明显提高双机房容灾时,允许的机房内运行水位。例如搜索三机房建设允许机房内水位运行到40%。


三、故障的快速发现---监控和报警系统

  • 监控的快速采集

数据指标的采集有两种方式,一种是基于日志的采集,这种方式依赖于系统打日志,然后定时器去触发采集动作。另一种是种下agent,agent提供标准的接口,每个应用向标准接口吐出标准格式的数据,这个数据是本地非持久化的,通过内存直接传输到远端存储。

搜索的kmonitor系统采用的是第二种,agent的方式更加快速,同时也是原监控系统amonitor的一种自然延续。目前kmonitor的监控指标标准的是20s,特殊指标可以做到5s以内。具体参考:kmonitor文章


  • 报警的快速发出

目前搜索使用烽火台作为与kmonitor对接的报警系统,烽火台支持metric维度的报警,支持多个metric之间相互运算结果的报警方式。


  • 监控缺失和ip分组依赖

目前集团的xflush或者alimonitor的监控和报警,均基于aone产品树和armory分组。对于ip漂移、分组移动都是不能容忍的。比如一个分组下面有100个容器,现在你扩容20个容器,那么很快在xflush上面会看见一个小坑,需要一段时间去同步ip列表。如果是持续不断的ip漂移(大混部之后的常态),那监控和报警有时会误报。agent直接对接metric,metric不同维度的标签,不依赖分组和应用,可以解决该问题,这是大混部之后的趋势。


四、故障的快速恢复---切流平台

  • 切流接口的统一

统一的切流接口是切流平台的条件,这里的统一不一定是一个,但是要有规范。比如现在搜索这边的切流平台基本上统一到:vipserver接口、tpp推荐切流接口和dns切流接口。


  • 实验链路的考虑

实验链路可能不是一个普遍的问题,但是在搜索和广告都存在。实验田是用来分桶验证算法效果的集群,试验田的流量一般是在java接入层通过用户id的hash做分桶,然后选择某些桶的流量进入试验田。之所以单拎出来是因为它的切流措施是特殊而且容易遗漏和出问题的。

一般试验田考虑到成本问题,只在一个机房部署。当该机房出故障时,出了主集群外试验田也应该随之切走。


  • ip漂移问题

在进行vipserver的切流时,如果仅仅是禁用掉某个机房下面所有的ip,从而达到流量切到其他机房目的。那么有一个潜在的风险就是,如果出现机房的内的iplist,在切流期间发生了变化,那么就会有流量重新进入到故障机房,这是绝对不能容忍的。

之所以提这点,是因为集团现在都在上调度器和容器化。单个损坏的节点会自动进行替换,替换的机器有新的ip,这个新ip会自动挂载到vipserver上。这时就和切流发生冲突了。解决的方案当然也很简单,vipserver现在提供一种disable机房的接口,调用这个接口后。单个ip发生漂移并不会影响整个机房的流量被切走。


  • 手机端和随时切流

为了更加快速的切掉损坏的机房,亲维平台还提供了手机端切流的功能。在pc的平台上提前建设好切流机房,可以以阿里内外为壳子。实现随时随地,快速处理故障。目前搜索内部实现的切流平台:亲维。大家可以参考。


  • GOC托管

开发同学们即使有值班机制,也有了手机端切流的快速处理能力。但是仍然不能保证24H在线。处理速度维持在5min已经是极限了。下一步需要把报警标准化和简单化,做到能够让GOC同学处理,GOC托管。


五、故障快速恢复的可持续性

  • 人工演练

目前搜索内部到10月份为止,已经人工演习了31次。几乎每个业务都演练过多次了。人工演练是这个阶段的必经之路,人工演练阶段要解决例如:流量切不干净,一对一和一对多切流的可行性,下游系统的自动降级能力。


  • 自动演练

人工演练需要专人值守,专人处理。时间一长,非常容易懈怠。实际上之前确实这样做的,但是专人搞演习是不靠谱的,对个人来说一直会有其他重要的事情会优先级高于演习。几次尝试之后,放弃了持续走人工演习的道路。

所谓自动演练,其实也没有那么复杂。理念其实很简单,就是每个子系统每周定时演练一次,由人工触发变成定时器触发。定时器是一个倒计时,如果有紧急情况就去重置这个定时器,否则就会触发演习动作。自动演练成熟的条件,就是所有的演习科目都人工演练过。自动演练目前处于开发阶段,很快就会实施。


  • 快速恢复系统的未来形态

上面提到了自愈系统,这是一种故障快速恢复的终极形态。虽然我们现在的条件还不成熟,但这是可以想象的未来。这里的自愈系统并不是指简单的故障机替换、重启、清理日志这种操作。而是指的更大规模的隔离、切流、修复、恢复于一体的系统。

上面,我们从为什么选择快速恢复作为处理故障的首选。快速恢复依赖快速监控数据收集和快速的报警,快速恢复还依赖统一便捷的切流平台。本文最后,和大家讨论了快速恢复的下一步该怎么走。

 ----------------------------

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章