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

2017-11-30 陈皓
《左耳听风》
课程介绍


讲述：柴巍

时长:大小3.88M

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

故障复盘过程

对于故障，复盘是一件非常重要的事情，因为我们的成长基本上就是从故障中总结各种经验教训，从而可以获得最大的提升。在亚马逊和阿里，面对故障的复盘有不一样的流程，虽然在内容上差不多，但细节上有很多不同。
亚马逊内部面对 S1 和 S2 的故障复盘，需要那个团队的经理写一个叫 COE（Correction of Errors）的文档。这个 COE 文档，基本上包括以下几方面的内容。
故障处理的整个过程。就像一个 log 一样，需要详细地记录几点几分干了什么事，把故障从发生到解决的所有细节过程都记录下来。
故障原因分析。需要说明故障的原因和分析报告。
...

展开全文
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。

精选留言

  • 茎待佳阴
    2018-01-06
    我们公司比较奇葩，记得是今年7月的一个晚上，因为那段时间用户量涨得快，所以对服务扩分片，然后，由于需要GO那边的一哥们重启代理，没沟通好，导致，他把代理重启了，我服务还没启动，导致一半的用户无法登陆。CTO当时也在那坐着，起来就把键盘摔了，在那骂半天。之后线上故障了基本也都是这样，只要出问题，就用骂来解决问题，表示问题跟领导没关系。
    共 15 条评论
    86
  • z_sz
    2018-03-03
    做得越多，错得越多，隔壁组一个男生就是因为这个考核很差愤而离职了……
    共 2 条评论
    47
  • 不会跑
    2017-12-05
    一般会在故障发生时一刀切强调止损，然后故障结束后强调事故报告，接着强调责任“划分”，最后发现责任人过少或者事故太大，那简单 加上运维团队就好；最后的最后催一催故障报告以及美化故障报告. 对的我是运维😂
    
    37
  • 杜小琨
    2017-12-15
    耳朵大叔，介绍下你对故障判责边界的划分有什么经验和原则。

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

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

    共 5 条评论
    34
  • bullboying
    2017-12-05
    故障分为自产软件类，第三方软硬件类，操作类，外部原因类共四类。
    每起故障都会有技术复盘，由研发总监牵头处理。另外会有月度管理复盘，探讨有哪些管理改进措施。所有改进措施都要创建任务单跟踪，确保必须有个结果，是落实了或者是投入产出比不合适而取消了。
    持续优化故障处理流程几年了，故障发生率和平均业务恢复时间都在持续下降中。
    共 1 条评论
    27
  • 马若飞
    2018-06-06
    我司的处理方式和亚马逊的COE类似，要写这种东西，基本内容也一样。然后严重的故障P1 P2级别的要在公司级别的每个release review大会上复盘。。。另外我司是2B公司，客户很重要，基本上出了大问题都是会给客户造成million级别的损失，所以我司没有惩罚机制，直接fire。。。
    共 1 条评论
    20
  • helloworld
    2017-12-05
    阿里做基础架构的是不是经常背锅
    
    18
  • Geek_fb3db2
    2018-11-13
    为什么网页版本 复制不了，想记录下笔记 都没法复制，这样不好吧。
    共 1 条评论
    13
  • UioSun
    2019-03-04
    支持“不从物质上惩罚工程师”。

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

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

    将员工吓得因噎废食，实在没有必要，与其如此，何不直接开除员工，这样你好我好大家好，别耽误对方。
    展开
    共 1 条评论
    12
  • Geek_fb3db2
    2018-11-13
    问题分析报告 总结原因 然后记录到oa 最后罚款或者绩效 最后该错还是错
    
    8
  • FeiFei
    2018-09-05
    在技术债的包袱下，
    在混乱的基础架构里，
    面对不确定是否可靠的服务，
    根本不可能降低故障发生率。
    
    7
  • The one | LifeHa...
    2018-12-20
    确实，上家公司做的话很多，也出了不少错，但是那些不做事的在一边看笑话，这就有点不爽了
    
    6
  • 亿光年
    2018-11-05
    在前公司也有故障复盘，我也比较喜欢这种模式，每次也都会定位问题，问多个为什么，但没有亚马逊那么丰富，也会意思性惩罚主要的责任人。当时从领导学到重要一点就是遇到故障立即想办法恢复，而不是去定位问题，定位问题可能需要个很长时间!
    共 1 条评论
    6
  • 艾尔欧唯伊
    2018-09-25
    看来我还是太渣，呆过的公司就没有复盘的，解决了就过去了。。要有人愿意口口相传已经万幸
    
    5
  • 冰梨icePear🍐
    2017-12-10
    阿里内部应该不同bu有不同的处理方式吧，反正支付宝这里比较像你描述的亚马逊的方式，需要回溯过程，分析问题，提出问题以及解决方法，最后action给相关人，在限定时间内给出action 的结果
    
    5
  • Geek_7b1383
    2020-04-25
    第一，优化故障获知和故障定位的时间----监控全面并且自动化
    第二，优化故障的处理方式-----监控发给恰当的人
    第三，优化开发过程中的问题。-----技术债定期排期优化，三级codeview
    第四，优化团队能力。-----结对编程等，团队的技术输出，学习群等

    我们公司的复盘方式同耗子哥所描述的亚马逊的复盘方式，都是责任到人，CTO参与检视并汇报的，结果是近2年来故障逐年降低，系统方面的基础工具支持越来越完善，监控故障处理方面也越来越自动化智能化
    展开
    
    4
  • MagicData
    2019-07-04
    对于惩罚故障责任人和解决故障没有因果关系是认同的，但是对于责任人，是应该有一定的惩罚机制，当然更多的是在于反思总结和后续跟进优化，而对于做的多的人，他出问题的概率相对会高，但是实际上还是与个人工作细致程度与专业程度有关系，所以对于做的多，结果好的是应该有更好的奖励措施，做到奖惩分明很重要
    
    4
  • xpisme
    2018-06-26
    一：止损 (回滚)
    二：事故通报(原因 解决的流程 TODO)
    三：case study
    
    4
  • edisonhuang
    2019-05-29
    故障复盘的指导，
    记录故障过程的详细操作，分析故障原因，ask 5 why，提出后续故障整改计划。
    故障发生后追问why，有助于优化定位故障的时间，尽量让故障处理过程自动化，审视开发过程和code review，帮助团队提升能力。
    处理故障要求举一反三的能力，系统的清除故障，优化系统，把复杂问题简单化，简化流程。优化结构，包括调优组织结构。用技术的手段解决技术的问题。
    
    3
  • abners
    2019-04-02
    我们公司会有COE复盘，之前执行的挺好的。会深层次剖析问题根源，并加以解决，到现在我感觉越来越流于形式了，团队拆分，都是回避自己的责任了😔😔
    
    2