剑客
关注科技互联网

游戏平台的运维自动化扩展:故障自愈

马辰龙,负责某大型网页游戏平台的运维开发,专注于运维自动化、监控系统故障自愈研究,擅长Perl开发、正则表达式、日志精确匹配。

游戏平台的运维自动化扩展:故障自愈

网络游戏是对用户体验要求最严苛的IT行业之一,任何IT问题造成的业务不稳定,都可能导致玩家的流失,进而影响游戏商的营收。因此,自动化运维对于游戏平台的重要不言而喻。

相比起对IT基础设施运维操作的需求,业务则更需要运维提供高质量的业务保障服务,包括对业务架构及部署的持续优化,精细化的游戏健康度管理,以及快速的故障处理服务等。

以下就是由马辰龙先生分享的工作心得:游戏平台运维自动化扩展之故障自愈。

大家好,我们用一个例子作为今天分享的开始。

越来越复杂的网络问题常常会造成各种误报,导致各种误报信息的轰炸,出现报警我们一般先看报警内容,这种情况大家都遇到过吧?久而久之就造成了对告警信息的麻木。比如凌晨2点某机房切割网络抖动,一下过来几百条告警短信,相信大家不可能一条条的看。

首先我们要解决的是误报的问题。现在的监控软件无非就是Zabbix 、Nagios或者 SmokePing 这类,还会有一些单点监控软件。如果想消除误报只有多IDC去部署监控服务器,搭建多节点去监控网络问题,但这就需要使用大量的服务器资源,有没有什么好的解决方案呢?而且即使我们搭建了大量的监控服务器,又怎么去集中处理告警消息呢?

经过对市面上流行的监控类产品进行广泛调研,发现云智慧的监控宝可以通过分布式监测节点,多区域同时监控服务器、网站的健康状况,同时还提供一些国外节点(我们的业务涉及海外)监测海外用户的业务访问体验,而且阈值和监控方式也可以根据业务的实际需求去自定义。

当然作为一个崇尚运维自动化的运维人员,我看中的不仅是这些,更重要的是能够callback告警消息。如果是因为服务器网络或者其他原因导致宕机,在收到告警消息之后,让后端系统能够根据消息去自动处理是不是会更好呢。给大家看一副图来理解下:

游戏平台的运维自动化扩展:故障自愈 根据回调信息,事先将其定义成一些规则,当我们匹配到了告警信息中的特定信息后,可以自主切换。

监控宝的URL回调可以在这里设置:

游戏平台的运维自动化扩展:故障自愈

运维监控的发展

过去:Nagios、Cacti、Zabbix 监控单一,对告警后知后觉;

现在:API监控数据聚合、告警信息收敛,自动化感知;

未来:挖掘故障信息,制定故障自愈规则,提前感知。

游戏平台的运维自动化扩展:故障自愈

运维的建设有四个阶段,简称为四化建设:

第一个阶段就是标准化。标准化的意思是把主机名、内网以及配置文件统一起来,如果不统一,后面的东西就无法继续。没有一个标准化的环境,脚本是无法写下去的。

第二个阶段是自动化。中小型企业阶段都是自动化到平台化的过渡,平台化就是把自动化的东西分装,把功能整合,把数据做聚合,然后放在平台上来可视化。

第三个阶段是平台化。以后的趋势是脚本和功能必须是外部化的,这样新来的一个人才能接手。不用在服务器上跑脚本,还要同下个人交代在哪儿装。

最后一个阶段就是服务化。服务化是指现在云平台所承载的东西。举个例子,搭一个redis集群,用户不需要知道服务器有多少个,因为所提供的NOSQL服务打开后,用户就可以直接使用了。

所以我们未来要做的就是收集告警信息进行自动化处理,而不是通知运维上线处理。我们要脱离那种每天等着告警信息去处理故障,要主动出击,不要等到故障了再去处理,而且即使事后处理好了,那么时间成本也是很高的。

再举个栗子,一个网站在全国各地会解析为多个IP,而且还会有备用IP用来切换(被DDOS的时候,IP被封,我们需要切换)。我们会有一个脚本去检测这些IP的状态,当这些IP正常的时候才会切换到这些IP上,如果Ping不通或者有其他故障就不会去切换,否则去切换一个故障IP不是没有用吗?

我们在做监控的时候需要考虑很多不可控的因素,因此在写代码的时候要首先考虑异常状态,否则会造成二次故障,这是我们不愿意看到的。当故障IP 2小时内不丢包,我们就把他去掉,下次切换的时候就可以用到,反之亦然。这里提示下,对于这种时间周期可以使用redis,expire 指定ttl。

给大家一张图来理解下告警信息的分类:

游戏平台的运维自动化扩展:故障自愈 我们要做到能自动化的尽量自动化,不能自动化的我们要让它半自动,人工介入处理是最后的方案,因为是人就会犯错,尤其在业务出现异常,操作都是不可控的。

说这么多 ,核心就是需要建立自己的消息处理中心来分析问题,充分利用告警信息,大概的模型可以是这样:

游戏平台的运维自动化扩展:故障自愈

最后,故障自愈能够给我们带来什么

1、非工作时间运维人员处理故障以及响应时间;

2、减少直接的线上操作、避免出现人为原因的二次故障;

3、提高运维人员对故障原因的分析、以及工作积极性;

4、提升运维的自身价值。

Q&A

问:如何做告警收敛?

答:比如我们以一台服务器为单位,每分钟的告警信息分为系统和网络告警,统一处理。(当然也能以收件人,业务关联为单位。)

问:对于传染型的故障,不知道有没有什么好的方案呢,就是反复访问一个问题导致骨牌性的反应。

答:比如网站报了500错误,那么我们发现500错误的时候,在告警的时候可以让它去错误日志里收集关于相同IP的error,一起发送。

问:怎么自动化的?

答:减少我们去服务器查日志的时间,频繁的grep xxx。

问:百度爬虫并发大没抗住,怎么自动化处理?

答:首先你是想让它爬还是不爬,不爬就匹配useragent。

问:你们故障自愈是哪些情况?是通过日志?还是api url监控?通过特定故障返回特定值??因为java的日志各种情况都有。

答:面对DDOS流量型攻击,通过分析url使用防火墙封禁,首先是日志。

问:DDOS怎么分析url??有什么特征吗??

答: DDOS是没有日志的,可以通过网络告警去触发,CC攻击分析你的URL,规则可以自己去定义,有些注入、刷API等通过正则去匹配。运维人员要利用好日志,所有的问题都是从日志中分析行为发现的。

问:我们上了ELK,Java除了假死自动重启,好像没什么自愈的。

答: ELK可以使用API拉日志,去分析业务的运行状态,ELK的面太大,这里细节就不多说了。

游戏平台的运维自动化扩展:故障自愈 点击 阅读原文

和讲师一起实践故障自愈 

游戏平台的运维自动化扩展:故障自愈

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址