左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家,骨灰级程序员
立即订阅
40357 人已学习
课程目录
已完结 108 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 洞悉技术的本质,享受科技的乐趣
免费
01 | 程序员如何用技术变现(上)
02 | 程序员如何用技术变现(下)
03 | Equifax信息泄露始末
04 | 从Equifax信息泄露看数据安全
05 | 何为技术领导力?
06 | 如何才能拥有技术领导力?
07 | 推荐阅读:每个程序员都该知道的知识
08 | Go语言,Docker和新技术
09 | 答疑解惑:渴望、热情和选择
10 | 如何成为一个大家愿意追随的Leader?
11 | 程序中的错误处理:错误返回码和异常捕捉
12 | 程序中的错误处理:异步编程以及我的最佳实践
13 | 魔数 0x5f3759df
14 | 推荐阅读:机器学习101
15 | 时间管理:同扭曲时间的事儿抗争
16 | 时间管理:如何利用好自己的时间?
17 | 故障处理最佳实践:应对故障
18 | 故障处理最佳实践:故障改进
19 | 答疑解惑:我们应该能够识别的表象和本质
20 | Git协同工作流,你该怎么选?
21 | 分布式系统架构的冰与火
22 | 从亚马逊的实践,谈分布式系统的难点
23 | 分布式系统的技术栈
24 | 分布式系统关键技术:全栈监控
25 | 分布式系统关键技术:服务调度
26 | 分布式系统关键技术:流量与数据调度
27 | 洞悉PaaS平台的本质
28 | 推荐阅读:分布式系统架构经典资料
29 | 推荐阅读:分布式数据调度相关论文
30 | 编程范式游记(1)- 起源
31 | 编程范式游记(2)- 泛型编程
32 | 编程范式游记(3) - 类型系统和泛型的本质
33 | 编程范式游记(4)- 函数式编程
34 | 编程范式游记(5)- 修饰器模式
35 | 编程范式游记(6)- 面向对象编程
36 | 编程范式游记(7)- 基于原型的编程范式
37 | 编程范式游记(8)- Go 语言的委托模式
38 | 编程范式游记(9)- 编程的本质
39 | 编程范式游记(10)- 逻辑编程范式
40 | 编程范式游记(11)- 程序世界里的编程范式
41 | 弹力设计篇之“认识故障和弹力设计”
42 | 弹力设计篇之“隔离设计”
43 | 弹力设计篇之“异步通讯设计”
44 | 弹力设计篇之“幂等性设计”
45 | 弹力设计篇之“服务的状态”
46 | 弹力设计篇之“补偿事务”
47 | 弹力设计篇之“重试设计”
48 | 弹力设计篇之“熔断设计”
49 | 弹力设计篇之“限流设计”
50 | 弹力设计篇之“降级设计”
51 | 弹力设计篇之“弹力设计总结”
52 | 管理设计篇之“分布式锁”
53 | 管理设计篇之“配置中心”
54 | 管理设计篇之“边车模式”
55 | 管理设计篇之“服务网格”
56 | 管理设计篇之“网关模式”
57 | 管理设计篇之“部署升级策略”
58 | 性能设计篇之“缓存”
59 | 性能设计篇之“异步处理”
60 | 性能设计篇之“数据库扩展”
61 | 性能设计篇之“秒杀”
62 | 性能设计篇之“边缘计算”
63 | 区块链技术的本质
64 | 区块链技术细节:哈希算法
65 | 区块链技术细节:加密和挖矿
66 | 区块链技术细节:去中心化的共识机制
67 | 区块链技术细节:智能合约
68 | 区块链技术 - 传统金融和虚拟货币
69 | 程序员练级攻略:开篇词
70 | 程序员练级攻略:零基础启蒙
71 | 程序员练级攻略:正式入门
72 | 程序员练级攻略:程序员修养
73 | 程序员练级攻略:编程语言
74 | 程序员练级攻略:理论学科
75 | 程序员练级攻略:系统知识
76 | 程序员练级攻略:软件设计
77 | 程序员练级攻略:Linux系统、内存和网络
78 | 程序员练级攻略:异步I/O模型和Lock-Free编程
79 | 程序员练级攻略:Java底层知识
80 | 程序员练级攻略:数据库
81 | 程序员练级攻略:分布式架构入门
82 | 程序员练级攻略:分布式架构经典图书和论文
83 | 程序员练级攻略:分布式架构工程设计
84 | 程序员练级攻略:微服务
85 | 程序员练级攻略:容器化和自动化运维
86 | 程序员练级攻略:机器学习和人工智能
87 | 程序员练级攻略:前端基础和底层原理
88 | 程序员练级攻略:前端性能优化和框架
89 | 程序员练级攻略:UI/UX设计
90 | 程序员练级攻略:技术资源集散地
91 | 程序员面试攻略:面试前的准备
92 | 程序员面试攻略:面试中的技巧
93 | 程序员面试攻略:面试风格
94 | 程序员面试攻略:实力才是王中王
95 | 高效学习:端正学习态度
96 | 高效学习:源头、原理和知识地图
97 | 高效学习:深度,归纳和坚持实践
98 | 高效学习:如何学习和阅读代码
99 | 高效学习:面对枯燥和量大的知识
左耳听风
登录|注册

18 | 故障处理最佳实践:故障改进

陈皓 2017-11-30
在上篇文章中,我跟你分享了在故障发生时,我们该怎样做,以及在故障前该做些什么准备。只要做到我提到的那几点,你基本上就能游刃有余地处理好故障了。然而,在故障排除后,如何做故障复盘及整改优化则更为重要。在这篇文章中,我就跟你聊聊这几个方面的内容。

故障复盘过程

对于故障,复盘是一件非常重要的事情,因为我们的成长基本上就是从故障中总结各种经验教训,从而可以获得最大的提升。在亚马逊和阿里,面对故障的复盘有不一样的流程,虽然在内容上差不多,但细节上有很多不同。
亚马逊内部面对 S1 和 S2 的故障复盘,需要那个团队的经理写一个叫 COE(Correction of Errors)的文档。这个 COE 文档,基本上包括以下几方面的内容。
故障处理的整个过程。就像一个 log 一样,需要详细地记录几点几分干了什么事,把故障从发生到解决的所有细节过程都记录下来。
故障原因分析。需要说明故障的原因和分析报告。
Ask 5 Whys。需要反思并反问至少 5 个为什么,并为这些“为什么”找到答案。
故障后续整改计划。需要针对上述的“Ask 5 Whys”说明后续如何举一反三地从根本上解决所有的问题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《左耳听风》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(34)

  • 茎待佳阴
    我们公司比较奇葩,记得是今年7月的一个晚上,因为那段时间用户量涨得快,所以对服务扩分片,然后,由于需要GO那边的一哥们重启代理,没沟通好,导致,他把代理重启了,我服务还没启动,导致一半的用户无法登陆。CTO当时也在那坐着,起来就把键盘摔了,在那骂半天。之后线上故障了基本也都是这样,只要出问题,就用骂来解决问题,表示问题跟领导没关系。
    2018-01-06
    1
    47
  • 不会跑
    一般会在故障发生时一刀切强调止损,然后故障结束后强调事故报告,接着强调责任“划分”,最后发现责任人过少或者事故太大,那简单 加上运维团队就好;最后的最后催一催故障报告以及美化故障报告. 对的我是运维😂
    2017-12-05
    24
  • z_sz
    做得越多,错得越多,隔壁组一个男生就是因为这个考核很差愤而离职了……
    2018-03-03
    19
  • bullboying
    故障分为自产软件类,第三方软硬件类,操作类,外部原因类共四类。
    每起故障都会有技术复盘,由研发总监牵头处理。另外会有月度管理复盘,探讨有哪些管理改进措施。所有改进措施都要创建任务单跟踪,确保必须有个结果,是落实了或者是投入产出比不合适而取消了。
    持续优化故障处理流程几年了,故障发生率和平均业务恢复时间都在持续下降中。
    2017-12-05
    15
  • helloworld
    阿里做基础架构的是不是经常背锅
    2017-12-05
    11
  • Geek_fb3db2
    为什么网页版本 复制不了,想记录下笔记 都没法复制,这样不好吧。
    2018-11-13
    10
  • 杜小琨
    耳朵大叔,介绍下你对故障判责边界的划分有什么经验和原则。

    另外我不认同你对阿里故障惩罚机制不认同的观点,我比较认同人是利益驱动的生物。

    作者回复: 发生故障的最佳实践是反思、总结和改善,判责对故障的解决没有因果关系。“人是利益驱动的”没错,但是“利益”和“能力”没有任何关系,处理故障是靠“能力”不靠“利益”,希望你能get到这其中的“因果关系”。

    2017-12-15
    10
  • Geek_fb3db2
    问题分析报告 总结原因 然后记录到oa 最后罚款或者绩效 最后该错还是错
    2018-11-13
    8
  • 剃刀吗啡
    我司的处理方式和亚马逊的COE类似,要写这种东西,基本内容也一样。然后严重的故障P1 P2级别的要在公司级别的每个release review大会上复盘。。。另外我司是2B公司,客户很重要,基本上出了大问题都是会给客户造成million级别的损失,所以我司没有惩罚机制,直接fire。。。
    2018-06-06
    7
  • 亿光年
    在前公司也有故障复盘,我也比较喜欢这种模式,每次也都会定位问题,问多个为什么,但没有亚马逊那么丰富,也会意思性惩罚主要的责任人。当时从领导学到重要一点就是遇到故障立即想办法恢复,而不是去定位问题,定位问题可能需要个很长时间!
    2018-11-05
    5
  • FeiFei
    在技术债的包袱下,
    在混乱的基础架构里,
    面对不确定是否可靠的服务,
    根本不可能降低故障发生率。
    2018-09-05
    4
  • UioSun
    支持“不从物质上惩罚工程师”。

    如果觉得无法掌控员工的生产力盈余,可以要求团队写周记甚至日报;如果觉得员工工作不合适,要么谈话,要么开除。惩罚工程师看起来很解气,但对这个人能否反省和进步,意义不大。不再犯错不等于反省,或许就如同文中说的,只是等于“不再触碰”。

    那惩罚的意义何在呢?这个员工成长不起来,早晚要被开除。
    延缓公司为该员工递增支付的成本吗?企业如果真的有这个资源,何不再培养一位新员工,毕竟价值观都不一致,将人留下来只是“徒添鸡肋”罢了。

    将员工吓得因噎废食,实在没有必要,与其如此,何不直接开除员工,这样你好我好大家好,别耽误对方。
    2019-03-04
    3
  • xpisme
    一:止损 (回滚)
    二:事故通报(原因 解决的流程 TODO)
    三:case study
    2018-06-26
    3
  • 冰梨icePear🍐
    阿里内部应该不同bu有不同的处理方式吧,反正支付宝这里比较像你描述的亚马逊的方式,需要回溯过程,分析问题,提出问题以及解决方法,最后action给相关人,在限定时间内给出action 的结果
    2017-12-10
    3
  • 🌚🌝
    对于惩罚故障责任人和解决故障没有因果关系是认同的,但是对于责任人,是应该有一定的惩罚机制,当然更多的是在于反思总结和后续跟进优化,而对于做的多的人,他出问题的概率相对会高,但是实际上还是与个人工作细致程度与专业程度有关系,所以对于做的多,结果好的是应该有更好的奖励措施,做到奖惩分明很重要
    2019-07-04
    1
  • edisonhuang
    故障复盘的指导,
    记录故障过程的详细操作,分析故障原因,ask 5 why,提出后续故障整改计划。
    故障发生后追问why,有助于优化定位故障的时间,尽量让故障处理过程自动化,审视开发过程和code review,帮助团队提升能力。
    处理故障要求举一反三的能力,系统的清除故障,优化系统,把复杂问题简单化,简化流程。优化结构,包括调优组织结构。用技术的手段解决技术的问题。
    2019-05-29
    1
  • 西北偏北
    复盘整个过程,系统的,全局的去思考问题,并解决,不要赶工被动的,临时的解决问题。
    2019-05-13
    1
  • abners
    我们公司会有COE复盘,之前执行的挺好的。会深层次剖析问题根源,并加以解决,到现在我感觉越来越流于形式了,团队拆分,都是回避自己的责任了😔😔
    2019-04-02
    1
  • 山分子
    耗子哥,亚马逊的工程师是不是更偏向全栈?我了解公司都有故障责任人惩罚的条款。同意您的观点,复盘主要是总结经验教训,避免类似问题再次发生,而惩罚并不能产生这种效果。
    我们复盘,也是大家一起讨论,但过程比较简单,没有具体的流程,以后得多向耗子哥学习。
    2019-04-01
    1
  • 小思绪
    线上出问题之后第一要务是及时恢复线上,但是如何及时找到问题根本原因,不是简单的事,我们就经常在这个上面吃亏。

    针对线上问题,会有定期的质量回溯,质量回溯也分几个层次,分别是小组内回溯,系统部门级别回溯,公司级别回溯。
    2019-02-17
    1
收起评论
34
返回
顶部