专栏首页熊二哥线上故障的思考【一线工程师必看】

线上故障的思考【一线工程师必看】

周末早上,一个哥们突然@我,问是否有线上故障处理和定级的规范或者模板,虽然手头有既有文档,但内容显的太具象了,跟我们的业务有很强的关联性,并不是那么好直接复制到他的团队中。因此,个人对过去的线上故障处理进行了回顾和思考,并进行了简要的归纳,望帮助到需要的同学。文本将按事中处理、事后总结和事前预防的顺序进行介绍,不足之处望大家不吝赐教。

换个角度来说,其实故障处理的过程,和小朋友发高烧的处理过程类似。首先mama会带孩子上医院,如果温度高医生会要求打退烧针,类似发布回滚,之后再通常吃对症的药物慢慢恢复疾病。接下来,mama会明确小朋友生病的原因,如吹风受凉,并抱怨程序员爸爸不细心。最后,mama会提出很多的预防计划,比如禁止程序员爸爸带孩子时写代码,6了6了。

1.事中处理

遇到线上故障永远是尽快处理问题,而不是追究谁的责任,有时候快速合理的故障处理,完全可以规避掉大部分的故障危害

1.1线上故障处理SOP

  • a.线上故障第一要务【发布回滚】,因此针对高风险代码,一定要单独发布,便于回滚
  • b.线上故障第二要务【周知干系人】,随时通报故障处理进度,让真正了解该问题的干系人尽早参与进来
  • c.故障代码revert【通常来说,代码问题只要无法在30分钟内修复,就一定要回退代码,避免其他项目把错误代码带上线,再次带来故障】
  • d.修复问题,冷静的完成回归测试后重新上线,如果BUG带来错误数据则需要全面评估数据清洗的风险,避免造成更加严重的次生伤害【很常见】

2.事后总结

2.1.故障定级

简单的可以定位3级【推荐更进一步细化为3-5个层次】,严重性逐步递增:a.线上bug;b.线上故障;c.线上灾难。

一定要针对不同业务、不同层次、不同持续时间、不同后果细化故障定级,并且要周知所有干系人,确认后执行,以电商平台为例。

  • 不同业务:交易、支付、领券属于重要业务,出问题对公司影响很大;C端影响通常要比B端影响大很多
  • 不同层次:前端的影响会小一些,后端的会大一些,基础的会更大【包括中间件、运维等】
  • 不同持续时间:如故障持续3分钟,bug一上线就发现,通常故障级别会比较低,持续12小时,可能CTO都危险了,因此出现问题及时通报很重要,瞒报只会无限的扩大风险
  • 不同后果:影响用户下单100单,产生15个客户投诉,影响商家编辑商品2小时等,这部分的指标一定要和业务、产品沟通确认,他们有这部分最大的发言权。

业务

持续时间

后果

定级

用户订单

5分钟

损失10万订单

线上灾难

商家商品

45分钟

商家45分钟不能编辑和新增商品信息

线上故障

用户评论

3分钟

用户3分钟不能编辑和查看评论信息

线上bug

tip:

【后果数据来源】:通常取前1日、上周同日数据作为参考,根据业务线有差异,此外,互联网业务因变化快去年的数据通常不具参考意义

【构思角度】:可以从空间、时间、组合空间和时间维度

2.2.责任人范围

明确责任人,到底是产品、开发还是测试同学的责任,亦或者是多个干系人共同分担责任。比如由于是产品设计不合理带来的bug,产品同学需要负主要责任,有测试同学参与的项目,测试同学需要和开发同学共担责任,而其他情况,就只能是开发同学自己背锅了。

2.3.故障复盘

在故障处理完成后,一定要复盘并由责任人编写Case Study,并根据相关价值决定是否需要团队内分享【一定要避免同样的问题再次发生】

2.4.故障处罚

开发人员及其多级Leader、[测试人员]及其多级Leader共同分摊,比如开发小A罚款200元,Leader罚款500元,CTO罚款1000元等。

3.事前预防

3.1.故障预防

  • a.规范代码规范、数据库设计规范、日志和告警打点规范
  • b.规范git分支建立和合并、规范测试流程【全面的单元测试、是否需要测试介入等
  • c.规范Review制度,明确审核的责任【至少要识别出代码上线带来的风险,以明确Review的仔细程度】
  • d.规范上线流程【每个项目都需要上线计划,包括配置、数据库、代码项目和发布顺序、回滚方案等】
  • f.引入灰度发布、预发和监控机制,灰度应用出现问题及时回滚
  • e.规范【数据清洗】等高风险行为,高度重视这类操作【容易被忽视】,必须提供完整方案【包括是否备份、如何回滚等】

tip:

以上内容很多是站在比较理想的角度去思考的,实务中,一定要根据具体业务、成本考量、团队能力等因素进行剪裁和权衡,㊗️永远都没有线上故障。

名词解释

SOP: Standard Operating Procedure标准操作流程,就是将某一事件的标准操作步骤和要求以统一的格式描述出来,用来指导和规范日常的工作

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 项目管理深入理解08--成本管理

    成本管理一章非常的重要,尤其是对于程序员来说,这方面非常的薄弱,但这部分知识无论是在项目管理中还是日常生活中都灰常重要,不然很难成为一个财务自由的程序员。此外,...

    用户1216676
  • 架构设计深入学习01--概论与预架构阶段

    完成一个比较复杂的项目后,终于有空看看书了,这次决定将架构设计的方法论进行一次系统的学习,借助温昱大师的《一线架构师》一书。我将把这次学习分成三部分,分别是概论...

    用户1216676
  • AngularJS快速入门

    记得第一次听说AngularJS这项很赞的Web的前端技术,那时还是2014年,年中时我们我的一个大牛兄弟当时去面试时,被问到了是否熟悉该技术,当时他了解和使用...

    用户1216676
  • 故障管理工作方法和技巧分享

    做故障管理这么久,对怎样才能做好这个工作有一些切身感受,除去一些只可意会不可言传的部分,这次我把能想到的工作技巧都总结出来了。 由于这个岗位不是互联网公司6大...

    小小科
  • 如何应对线上故障

    线上故障是我们技术同学经常遇到,也是技术成长中经常要经历的事。从故障中我们可以吸取到很多教训,变得越来越有经验。

    奎哥
  • 数据挖掘算法在物业设备设施管理的风险识别与防控应用

    物业工程肩负着维持项目各类设施设备的正常运作,保障全体业主的正常生活,令物业保值升值,是项目的心脏部门。拓端数据(tecdat)研究人员根据全国电梯故障上报汇总...

    拓端
  • 携程运维自动化平台,上万服务器变更也可以很轻松

    去年5月,勒索病毒爆发,席卷全球,影响了政府部门、医疗机构、公共交通、学校、企业等等,给全世界带来了巨大损失。

    数据和云01
  • 最佳运维实践了解一下

    很多事,你不努力一下,你都体验不到绝望的感觉。。。哈哈,越努力越绝望怎么办。。。怎么办。。。哈哈

    SRE运维实践
  • Python思维导图(一)—— 基础

    思维导图并不能涵盖所有知识点,只是梳理某个知识点下我们需要重点关注的分支;根据自己的情况可以进行拓展学习

    小菠萝测试笔记
  • keras搭建基于自动编码器的异常检测技术进行欺诈识别

    我最近阅读了一篇名为《使用自动编码器进行异常检测》的文章,在该文中对所生成的数据进行了实验,并且我认为将使用自动编码器进行异常检测这一想法应用于真实世界当中的欺...

    deephub

扫码关注云+社区

领取腾讯云代金券