lyonger置顶2020-04-06能快速处理好故障的团队，内部文化应该也很优秀。这和军队作战类似，经常打胜仗的部队，其内部作风肯定非常严谨细致。而要提高自身作战能力，肯定是要付出代价的，军人可能会流血。相比业务肯定会存在一些因故障演练带来的损失，但随着你业务规模的扩大，这个代价其实省不了。提前向业务方沟通好的故障演练，往往比事后出故障被动处理要好。整个沟通过程，都应尽量化被动为主动，主动发现，主动汇报，主动安抚，尽量降低客户的负面情绪。而且故障过程中汇报用词也很关键，多站在对方的角度思考。另外，故障的处理应对方式，往往你和团队leader(如果这个leader干过运维，那你是幸运的)的认可度有特别大的关系，不然开展起来会很麻烦，毕竟调用的资源不少，牵扯的人又多，还可能有背锅的风险。作者回复: 我发现这位读者的分享总是这么优秀，我会置顶你的留言，让更多同行看到。
33- Helios2020-04-04我们公司因为是b端业务，不要求快速修复。 交付工程师会把软件包在客户内部署，我们称为L1，然后无论是部署问题还是业务问题都会找到对应的开发或者devops，这个过程交付工程师就全靠认识谁就问谁了。 后来公司一看不行，两端的效率都太低了，对于开发效率低的原因是因为一个客户出的问题可能其他客户也会出，要经常回答同样的问题，这时候在交付工程师和开发之间多了一层技术支持我们称为L2，最后开发和devops称为L3。L1解决不来的就问L2他们遇到的问题比较多，最后才是L3 这个时候问题解决的效率全靠L2了，因为他们要两端协调，他们就负责了指挥的角色。我觉得我们在文中讲到的角色定位做还算可以，但是技术方面的故障隔离，还有故障演练因为业务原因没有建立，老师觉得呢我们这种业务又没有必要建立呢
作者回复: 首先，感谢你前面的分享，很好的实践。 关于你提到的问题，其实这里提到的L2确实是非常关键的角色，他是承上启下的作用。是不是有必要进行故障演练，看业务、场景和客户需求，如果产品稳定，客户诉求不大，可以降低优先级，但是如果经常出问题，客户反馈比较多，建议还是跟客户一起做必要的演练。
7 
蒋悦2020-04-01故障处理过程的管理和软件开发的管理其实是一样的，只不过周期短得多。我经常和团队的人说，即使没有进展也要反馈。我带的都是小项目，一般我也要管故障处理。 不过我提一点，决策应该是“权责利”相匹配的，别决策做对了啥奖励也没有，决策做错了就直接被开了。 另外，作者回复: 你说的对，下一篇我们就会讲到“鼓励改进，而不是处罚错误”。 好像你的问题没有说完，可以补上继续提问哈。
共 3 条评论6
wholly2020-04-07受益匪浅，特别是那句：没有进展也是进展！很多从事故障处理或维护人员没有这个意识，确实很关键！我们团队的指挥官一般是负责整个系统的SE来承担，拉通的同时，也做技术决策，还是比较高效的。作者回复: 找对人和关键角色，效率自然就会大大提升。
4
Zachary2020-10-14问题到最后不再是简单的技术问题, 还要有管理(流程)和沟通作者回复: 技术只是问题的一个维度，要尝试从更多的角度去看问题，解决问题。
1
宋子龙2020-04-01太棒了👏非常受用作者回复: 对你有帮助，很开心。
1
leslie2020-04-01这个问题应当是不同公司不同情况吧：有些企业或是技术总监，有些会是部门主管；这其实涉及到的最关键问题就是权限-足够的沟通和协调权限，这种可能涉及跨部门操作的事情只能是公司的中高层。 甚至当直接协调人不在时会有相关业务部门的同级别人员去承担相应的事情。作者回复: 不同企业情况不同，这里最重要的是要有足够的授权给到。
共 2 条评论1
小炭2020-11-08至少总监级别的人物作为指挥和协调者。作者回复: 对，一定要有资源调动能力
Quinn2020-05-05为什么没有提前做出准确的评估？技术问题还是管理问题？再次发生的组织手段是什么？这里讲到当故障发生时的对应。理想情况是尽可能避免故障发生。如果没有总结出防止问题出现的手段。仍会导致混乱。作者回复: 改进措施最终一定要落地，而且可验证。不然，如你所说，问题不解决，仍然会导致相同的混乱。
- xierongfei2022-01-24这个故障处理流程 和 google SRE 那本书讲的类似。我们公司在处理故障中也慢慢引入，之前出问题全是运维排查，看日志重启服务，后面确定了责任，运维只对基础设施负责，重启和业务异常排查，全部开发来做。1