欢迎光临和记-娱乐app-欢迎您
-->
返回列表
您当前的位置:主页 > 技术优势 > 故障处理 >
妨碍处置流程和类型
时间:2020-05-01 06:28 来源:和记,和记娱乐APP 点击:

  大数据团队负责很多公司核心服务,包括olap查询、队列、日志搜索、数据传输、存储、计算等等服务,作为公司数据传输和存储及计算的中枢,服务的稳定性直接影响用户口碑和体验,间接影响着公司的营收,线上服务的稳定性是每位同学需要重点关注的事情。当然线上服务发生故障,做技术每位同学几乎都会遇到,也是作为技术RD成长中经常要经历的事。从故障中我们可以吸取到很多教训,变得越来越有经验,把我们的服务做得越来越稳定。但是并不是每一个团队/技术同学在应对故障的处理方式上,都能做到合理和科学地迅速止损,把业务影响和损失降到最小。那我们该如何做呢?才能让我们工作做得更好呢?下面流程图和详细步骤就是我们要具体做得工作。

  不管是收到报警信息,还是业务用户反馈大数据组提供的服务有问题,我们都需要进一步确认验证集群是否正常提供服务,确认的同时通知用户我们正在跟踪处理,让用户放心。收到反馈通过以下指标项迅速判断,发现大数据集群可能遇到的问题

  确认故障后,迅速拉群,把上下游用户及自己项目负责人、部门负责人都加入进来,简要整理下内容,告知用户当前情况及解决预案或方案,不要给用户感觉突然或带来惊讶,让用户有心理准备,留好buffer时间做好应对措施。如果不能及时解决,不要等待或死磕问题,请迅速联系自己的老板寻求支持和帮助(也可以请求能帮助自己的同事加入)。

  服务回滚:如果属于更新的代码BUG导致的问题,一般可通过回滚上一个程序版本来迅速恢复,不过会导致部分新功能不可用

  重启:部分问题是可以通过重启的手段来临时恢复的,以保障系统的暂时可用,但后续还需有其他方法彻底解决问题

  限流和降级:这其实是一个临时手段,通过将部分非核心系统进行降级和限制流量处理,来避免核心业务受到影响

  紧急更新:这个方式会经常被用到,明确定位问题源后,迅速修复代码或组件,然后快速更新上线,比较依赖故障处理人技术和代码逻辑、应急处理能力

  写casestudy原则:并不是所有故障都需要写casestudy,原则一如果我们服务能快速恢复且对用户部门影响很小,就不用写。原则二由各个服务SLA确定是否编写casestudy

  回顾故障处理全过程: 需要详细的记录下故障发现的时间,什么途径发现的,用了什么样的排查手段,什么样子的处理流程,处理过程中,几点几分做了什么事情,将整个过程都一一的记录下来。

  分析故障原因: 需要将团队成员聚在一起,进行讨论,分析故障发生的原因,这里的原因不是指表象的原因,需要剖析出问题的根源。

  故障改进计划: 针对当前故障要做哪些改进措施,应对类似问题,如何预防。给出可实施的方案以及时间计划。同时对故障等级进行认定,以及团队成员责任的追究和备案(但不提倡惩罚)。

  根据当前存在的问题制定出一套流程不难,难在对流程执行的跟踪和监督。因此每个故障Action都是可执行的,且有明确的执行人和Deadline,跟进故障casestudy中改进工作列表进展情况,及时closed任务。随着故障管理标准化建立和规范化,经过一段时间的积累,会沉淀一些宝贵的故障数据,为系统改进方向提供了参考,也增强了伙伴们的故障意识,避免小伙伴不会犯同类型故障,对线上环境的敬畏之心和对故障的紧急处理意识。

  以上工作做完后,就要对运维文档查漏补缺进行完善了。大数据团队每个系统或方向的小组人数多寡有差异,多的有4人,少的可能只有1人负责。人都有打盹或休息/休假的时候,自己不能处理或外出,其他人可以根据运维文档,根据故障常用恢复原则进行紧急处理。


上一篇:阻滞照料
下一篇:没有了