欢迎光临博天堂AG手机版
-->
返回列表
您当前的位置:主页 > 技术优势 > 故障处理 >

怎样急速处分线上打击

发布时间:2020-02-15 06:08 来源:博天堂ag,博天堂AG手机版,博天堂ag旗舰 点击:

  线上故障的处理不仅是一项技术活,更是对技术人员/技术团队反应能力、决策能力、判定能力、组织能力的考验。面对突发的生产故障,需要快速定位问题,找到解决方案,快速实施解决方案并不是一件容易的事情。本文主要包括如下内容:线上故障处理的目标、思路、步骤、基础设施。

  本文是依据平时经历的生产故障排查和处理,总结一些肤浅的方法论,以求共同探讨,共同提高,欢迎探讨。

  任何动物一旦掉进坑里,明智的做法一定是:跳坑--填坑--避坑,线上故障处理的过程也一样,优先级从高到低,线上故障处理的目标如下:

  线上服务的可用性决定着服务者的客户利益,影响着公司的收益。一旦线上环境不可用,无法服务用户,给公司/团队带来经济利益损失的同时,更为严重的会给公司/团队带来恶劣的名声。所以一般公司都会对线上环境提出稳定性和可靠性的要求,这也是团队乃至部门的kpi。为此,遇到生产故障后的第一要务是:恢复生产服务,即使不能完全恢复线上服务,也要想尽办法将对线上服务的影响降到最低。

  在恢复线上服务,尽最大限度减掉对用户/公司/团队带来的影响后,我们需要彻查问题,搞清楚故障发生的根本原因,从根本上解决问题。通常情况下,填坑和跳坑是同步在做的,完成填坑也就意味中跳坑成功,但是也有一些紧急情况下的特别跳坑方法,比如重启服务,或者服务降级/熔断等等,实际并未在当时完成填坑,而是先采取非常规手段跳坑,之后再慢慢填坑。

  找到了根本原因,解决了问题之后,我们需要举一反三,以此及彼,想想在这个故障排查和处理过程中,那些环节存在弱点?那些流程/规范/制度需要优化?这类问题是否在其他系统或者团队中也存在?通过这样的反思和自我批评,形成一份线上事故报告,不断完善流程,避免再次踩坑,也在团队中交流经验,共同提高。

  依据线上故障处理的目标及目标的优先级,线上排障的第一目标是恢复线上服务或者降低对线上服务的影响,关键点在于快速二字,在跳坑-填坑之后,再行回溯总结,以便避坑。因此,可以将线上故障处理的步骤分为:

  上述步骤并不是说要从上到下顺序进行,建议在不乱阵脚的情况下,并行去做,因为通常线上故障后会紧急启动故障处理程序,运维、开发、测试、产品各个角色都会参与进来,这时候分工下去,并行去做,不断汇总消息,做出判断,以求快速排障,恢复服务。这个思路类似于操作系统的fork/join设计思想,目的在于提高效率。

  在无法快速找到故障原因的时候,需要果断跳过故障定位环节,直接进行故障排除,比如采用服务降级、服务器扩容等手段,确保对线上服务降到最低且可控。等到线上服务撑过去之后,我们再慢慢定位故障原因,根本上解决问题。

  线上故障一般可以通过如下几种途径传递到开发/运维人员手中,按照从上到下的顺序,故障的严重程度依次变高。

  可能是开发或者运维不经意间查看生产环境的error日志,或者例行检查监控项时,看到了一些异常的现象,进而发现了故障;

  通常包括cpu、内存、io、tcp连接数、disk、线程数、GC、连接池等各个服务器指标异常,可能是服务器出现了异常,但是业务还未受到大面积影响;

  如用户登录失败率增加,订单堆积量增大,则意味中系统的异常已经很严重,影响了业务处理;

  上游系统或者下游系统的故障处理邮件/电话追溯,可能和本系统有关系,而且情况已经变得很糟糕了,需要快速定位;

  通常业务异常带来的影响传递到用户,再从用户传递到客服人员,再到技术人员手里,会存在一定时延,所以一旦有生产事件上报,这个时候严重性已经到了最高,技术人员的压力也会增大,因为会有领导的关注,产品经理的询问和催促,客户人员的焦虑带来的压力。

  上述途径传递过来的信息仅仅只是线上故障苗头,并非一定就发生了大规模的线上故障,所以首先需要确认的是这是不是一次线上故障?还是只是个例生产问题?是否和本系统有关系?一般来讲:系统监控告警和业务监控告警的情况下,大部分都和本系统有关,且可能是线上故障;而主动发现和生产事件上报则需要做甄别,可以根据上报事件个数或者问题复现的方式来评估是否是大规模线上故障,或者跟踪日志信息或者特定用户问题追溯来确定。至于关联系统故障追溯的情况,首先不要慌,先从宏观上确定本系统服务正常,一般可以检查是否有服务器监控报警,是否有业务监控报警等来确定,如果上游或者下游提供了日志,可以通过日志进行追踪,从而确定本系统是否存在故障。

  因此在得到一些线上故障苗头之后,可以通过以下途径确定是否是线上故障:业务监控告警、上报事件个数、问题重现、服务器监控等。这些途径可以并行进行,灵活组合,有时候一个手段就能确定,有时候需要组合多个手段予以判定。

  一旦确定是线上故障后,我们需要快速定位故障点,找到问题原因,以便对症下药,快速排除故障。

  故障定位是一个不断收集信息--假设--验证--尝试的循环过程,基本思路:拿到线上信息,产生怀疑点,拿到更详细的信息,进行推理验证,必要时刻,找到可行的验证措施,进行可控的尝试,或者在测试环境进行业务测试重现,性能测试重现。

  很多故障并不是由于单一原因造成的,而是多个条件同时满足时才出现的,所以,需要多收集信息,综合得到的信息,产生怀疑点,快速推理和验证,最后找到问题点,定位到故障。这个过程中可以集合大家的力量,并行去check各个点,并快速反馈信息。

  发布了最新版本,且故障最早出现时间在版本发布之后,很大程度上时由于新版本发布带来的问题,可能是bug,也可能是部署出现问题;

  未发布新版本,业务访问量猛增,服务时延增大,吞吐量先上升后下降,到最后服务直接不可用,可能原因是:业务量暴涨/遭遇攻击/上游服务异常调用;

  未发布新版本,部分服务失败,服务错误率增加,业务访问量增加,可能原因是业务访问量增大激发了潜在的并发bug,或者出现了io瓶颈等;

  业务访问量并未增加,但是服务时延下降,吞吐量下降,服务错误率增加,且服务器TCP的CLOSE_WAIT增大,这时候需要怀疑下游依赖服务是否异常。

  业务访问量并未增加,服务大范围不可用,日志中出现大量数据库错,很明显数据库可能出现问题,或者应用的数据库连接池出现问题。

  故障定位的初期,一般会先通过邮件+电话的方式进行沟通,如果几分钟之后事态变糟糕,且没有眉目,则需要紧急启动会议形式的联合排。


上一篇:ceph毛病照料记载
下一篇:小间距LED显示屏滞碍管理上