<p>马辰龙，负责某大型网页游戏平台的运维开发，专注于运维自动化、监控系统故障自愈研究，擅长Perl开发、正则表达式、日志精确匹配。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/56dacd4c55b66d9c493cb8d0a0908b67.jpg"></p>    <p>网络游戏是对用户体验要求最严苛的IT行业之一，任何IT问题造成的业务不稳定，都可能导致玩家的流失，进而影响游戏商的营收。因此，自动化运维对于游戏平台的重要不言而喻。</p>    <p>相比起对IT基础设施运维操作的需求，业务则更需要运维提供高质量的业务保障服务，包括对业务架构及部署的持续优化，精细化的游戏健康度管理，以及快速的故障处理服务等。</p>    <p>以下就是由马辰龙先生分享的工作心得：游戏平台运维自动化扩展之故障自愈。</p>    <p>大家好，我们用一个例子作为今天分享的开始。</p>    <p>越来越复杂的网络问题常常会造成各种误报，导致各种误报信息的轰炸，出现报警我们一般先看报警内容，这种情况大家都遇到过吧？久而久之就造成了对告警信息的麻木。比如凌晨2点某机房切割网络抖动，一下过来几百条告警短信，相信大家不可能一条条的看。</p>    <p>首先我们要解决的是误报的问题。现在的监控软件无非就是Zabbix 、Nagios或者 SmokePing 这类，还会有一些单点监控软件。如果想消除误报只有多IDC去部署监控服务器，搭建多节点去监控网络问题，但这就需要使用大量的服务器资源，有没有什么好的解决方案呢？而且即使我们搭建了大量的监控服务器，又怎么去集中处理告警消息呢？</p>    <p>经过对市面上流行的监控类产品进行广泛调研，发现云智慧的监控宝可以通过分布式监测节点，多区域同时监控服务器、网站的健康状况，同时还提供一些国外节点（我们的业务涉及海外）监测海外用户的业务访问体验，而且阈值和监控方式也可以根据业务的实际需求去自定义。</p>    <p>当然作为一个崇尚运维自动化的运维人员，我看中的不仅是这些，更重要的是能够callback告警消息。如果是因为服务器网络或者其他原因导致宕机，在收到告警消息之后，让后端系统能够根据消息去自动处理是不是会更好呢。给大家看一副图来理解下：</p>    <p><img src="https://simg.open-open.com/show/889322d486c5c7d1b1acc1b4b78fa440.jpg"></p>    <p>根据回调信息，事先将其定义成一些规则，当我们匹配到了告警信息中的特定信息后，可以自主切换。</p>    <p>监控宝的URL回调可以在这里设置：</p>    <p><img src="https://simg.open-open.com/show/395381c4a6a1bf9442d3f31f5245cffd.jpg"></p>    <p>运维监控的发展</p>    <p>过去：Nagios、Cacti、Zabbix 监控单一，对告警后知后觉；</p>    <p>现在：API监控数据聚合、告警信息收敛，自动化感知；</p>    <p>未来：挖掘故障信息，制定故障自愈规则，提前感知。</p>    <p><img src="https://simg.open-open.com/show/009b515cb481c9fc8620fca6400d2199.jpg"></p>    <p>运维的建设有四个阶段，简称为四化建设：</p>    <p>第一个阶段就是标准化。标准化的意思是把主机名、内网以及配置文件统一起来，如果不统一，后面的东西就无法继续。没有一个标准化的环境，脚本是无法写下去的。</p>    <p>第二个阶段是自动化。中小型企业阶段都是自动化到平台化的过渡，平台化就是把自动化的东西分装，把功能整合，把数据做聚合，然后放在平台上来可视化。</p>    <p>第三个阶段是平台化。以后的趋势是脚本和功能必须是外部化的，这样新来的一个人才能接手。不用在服务器上跑脚本，还要同下个人交代在哪儿装。</p>    <p>最后一个阶段就是服务化。服务化是指现在云平台所承载的东西。举个例子，搭一个redis集群，用户不需要知道服务器有多少个，因为所提供的NOSQL服务打开后，用户就可以直接使用了。</p>    <p>所以我们未来要做的就是收集告警信息进行自动化处理，而不是通知运维上线处理。我们要脱离那种每天等着告警信息去处理故障，要主动出击，不要等到故障了再去处理，而且即使事后处理好了，那么时间成本也是很高的。</p>    <p>再举个栗子，一个网站在全国各地会解析为多个IP，而且还会有备用IP用来切换（被DDOS的时候，IP被封，我们需要切换）。我们会有一个脚本去检测这些IP的状态，当这些IP正常的时候才会切换到这些IP上，如果Ping不通或者有其他故障就不会去切换，否则去切换一个故障IP不是没有用吗？</p>    <p>我们在做监控的时候需要考虑很多不可控的因素，因此在写代码的时候要首先考虑异常状态，否则会造成二次故障，这是我们不愿意看到的。当故障IP 2小时内不丢包，我们就把他去掉，下次切换的时候就可以用到，反之亦然。这里提示下，对于这种时间周期可以使用redis，expire 指定ttl。</p>    <p>给大家一张图来理解下告警信息的分类：</p>    <p><img src="https://simg.open-open.com/show/5e6355d44b7596fd93e3f7f4c309f6c0.jpg"> 我们要做到能自动化的尽量自动化，不能自动化的我们要让它半自动，人工介入处理是最后的方案，因为是人就会犯错，尤其在业务出现异常，操作都是不可控的。</p>    <p>说这么多 ，核心就是需要建立自己的消息处理中心来分析问题，充分利用告警信息，大概的模型可以是这样：</p>    <p><img src="https://simg.open-open.com/show/ba3ef25dfbcbe5fc780a0ed68334f182.jpg"></p>    <p>最后，故障自愈能够给我们带来什么</p>    <p>1、非工作时间运维人员处理故障以及响应时间；</p>    <p>2、减少直接的线上操作、避免出现人为原因的二次故障；</p>    <p>3、提高运维人员对故障原因的分析、以及工作积极性；</p>    <p>4、提升运维的自身价值。</p>    <p>Q&A</p>    <p>问：如何做告警收敛？</p>    <p>答：比如我们以一台服务器为单位，每分钟的告警信息分为系统和网络告警，统一处理。（当然也能以收件人，业务关联为单位。）</p>    <p>问：对于传染型的故障，不知道有没有什么好的方案呢，就是反复访问一个问题导致骨牌性的反应。</p>    <p>答：比如网站报了500错误，那么我们发现500错误的时候，在告警的时候可以让它去错误日志里收集关于相同IP的error，一起发送。</p>    <p>问：怎么自动化的？</p>    <p>答：减少我们去服务器查日志的时间，频繁的grep xxx。</p>    <p>问：百度爬虫并发大没抗住，怎么自动化处理？</p>    <p>答：首先你是想让它爬还是不爬，不爬就匹配useragent。</p>    <p>问：你们故障自愈是哪些情况？是通过日志？还是api url监控？通过特定故障返回特定值？？因为java的日志各种情况都有。</p>    <p>答：面对DDOS流量型攻击，通过分析url使用防火墙封禁，首先是日志。</p>    <p>问：DDOS怎么分析url？？有什么特征吗？？</p>    <p>答： DDOS是没有日志的，可以通过网络告警去触发，CC攻击分析你的URL，规则可以自己去定义，有些注入、刷API等通过正则去匹配。运维人员要利用好日志，所有的问题都是从日志中分析行为发现的。</p>    <p>问：我们上了ELK，Java除了假死自动重启，好像没什么自愈的。</p>    <p>答： ELK可以使用API拉日志，去分析业务的运行状态，ELK的面太大，这里细节就不多说了。</p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s/yFRCeX26VOgIycSq1bL1lg</p>    <p> </p>