2018-01-06我们公司比较奇葩，记得是今年7月的一个晚上，因为那段时间用户量涨得快，所以对服务扩分片，然后，由于需要GO那边的一哥们重启代理，没沟通好，导致，他把代理重启了，我服务还没启动，导致一半的用户无法登陆。CTO当时也在那坐着，起来就把键盘摔了，在那骂半天。之后线上故障了基本也都是这样，只要出问题，就用骂来解决问题，表示问题跟领导没关系。 2 51
2017-12-05一般会在故障发生时一刀切强调止损，然后故障结束后强调事故报告，接着强调责任“划分”，最后发现责任人过少或者事故太大，那简单 加上运维团队就好；最后的最后催一催故障报告以及美化故障报告. 对的我是运维😂 26
2018-03-03做得越多，错得越多，隔壁组一个男生就是因为这个考核很差愤而离职了…… 22
2017-12-05故障分为自产软件类，第三方软硬件类，操作类，外部原因类共四类。
每起故障都会有技术复盘，由研发总监牵头处理。另外会有月度管理复盘，探讨有哪些管理改进措施。所有改进措施都要创建任务单跟踪，确保必须有个结果，是落实了或者是投入产出比不合适而取消了。
持续优化故障处理流程几年了，故障发生率和平均业务恢复时间都在持续下降中。 1 18
2017-12-15耳朵大叔，介绍下你对故障判责边界的划分有什么经验和原则。
另外我不认同你对阿里故障惩罚机制不认同的观点，我比较认同人是利益驱动的生物。作者回复: 发生故障的最佳实践是反思、总结和改善，判责对故障的解决没有因果关系。“人是利益驱动的”没错，但是“利益”和“能力”没有任何关系，处理故障是靠“能力”不靠“利益”，希望你能get到这其中的“因果关系”。
13
2017-12-05阿里做基础架构的是不是经常背锅 12
2018-11-13为什么网页版本 复制不了，想记录下笔记 都没法复制，这样不好吧。 10- 2018-11-13问题分析报告 总结原因 然后记录到oa 最后罚款或者绩效 最后该错还是错 8
2018-06-06我司的处理方式和亚马逊的COE类似，要写这种东西，基本内容也一样。然后严重的故障P1 P2级别的要在公司级别的每个release review大会上复盘。。。另外我司是2B公司，客户很重要，基本上出了大问题都是会给客户造成million级别的损失，所以我司没有惩罚机制，直接fire。。。 8
2018-11-05在前公司也有故障复盘，我也比较喜欢这种模式，每次也都会定位问题，问多个为什么，但没有亚马逊那么丰富，也会意思性惩罚主要的责任人。当时从领导学到重要一点就是遇到故障立即想办法恢复，而不是去定位问题，定位问题可能需要个很长时间! 5
2018-09-05在技术债的包袱下，
在混乱的基础架构里，
面对不确定是否可靠的服务，
根本不可能降低故障发生率。 4
2018-06-26一：止损 (回滚)
二：事故通报(原因 解决的流程 TODO)
三：case study 4
2019-03-04支持“不从物质上惩罚工程师”。
如果觉得无法掌控员工的生产力盈余，可以要求团队写周记甚至日报；如果觉得员工工作不合适，要么谈话，要么开除。惩罚工程师看起来很解气，但对这个人能否反省和进步，意义不大。不再犯错不等于反省，或许就如同文中说的，只是等于“不再触碰”。
那惩罚的意义何在呢？这个员工成长不起来，早晚要被开除。
延缓公司为该员工递增支付的成本吗？企业如果真的有这个资源，何不再培养一位新员工，毕竟价值观都不一致，将人留下来只是“徒添鸡肋”罢了。
将员工吓得因噎废食，实在没有必要，与其如此，何不直接开除员工，这样你好我好大家好，别耽误对方。展开 3
2017-12-10阿里内部应该不同bu有不同的处理方式吧，反正支付宝这里比较像你描述的亚马逊的方式，需要回溯过程，分析问题，提出问题以及解决方法，最后action给相关人，在限定时间内给出action 的结果 3
2019-07-04对于惩罚故障责任人和解决故障没有因果关系是认同的，但是对于责任人，是应该有一定的惩罚机制，当然更多的是在于反思总结和后续跟进优化，而对于做的多的人，他出问题的概率相对会高，但是实际上还是与个人工作细致程度与专业程度有关系，所以对于做的多，结果好的是应该有更好的奖励措施，做到奖惩分明很重要 1
2019-05-29故障复盘的指导，
记录故障过程的详细操作，分析故障原因，ask 5 why，提出后续故障整改计划。
故障发生后追问why，有助于优化定位故障的时间，尽量让故障处理过程自动化，审视开发过程和code review，帮助团队提升能力。
处理故障要求举一反三的能力，系统的清除故障，优化系统，把复杂问题简单化，简化流程。优化结构，包括调优组织结构。用技术的手段解决技术的问题。 1- 2019-05-13复盘整个过程，系统的，全局的去思考问题，并解决，不要赶工被动的，临时的解决问题。 1
2019-04-02我们公司会有COE复盘，之前执行的挺好的。会深层次剖析问题根源，并加以解决，到现在我感觉越来越流于形式了，团队拆分，都是回避自己的责任了😔😔 1
2019-04-01耗子哥，亚马逊的工程师是不是更偏向全栈？我了解公司都有故障责任人惩罚的条款。同意您的观点，复盘主要是总结经验教训，避免类似问题再次发生，而惩罚并不能产生这种效果。
我们复盘，也是大家一起讨论，但过程比较简单，没有具体的流程，以后得多向耗子哥学习。 1
2019-02-17线上出问题之后第一要务是及时恢复线上，但是如何及时找到问题根本原因，不是简单的事，我们就经常在这个上面吃亏。
针对线上问题，会有定期的质量回溯，质量回溯也分几个层次，分别是小组内回溯，系统部门级别回溯，公司级别回溯。 1