#一分钟精髓速览 #
怎么样做好故障复盘？是否只有把事变要定责到人就能解决问题？
这是很多企业/团队都要面对的问题，有着超10年零碎稳定性保障教训的李道兵老师给咱们分享了他的观点：
故障复盘的三大关键问题：
- 怎么无效升高故障的影响？
- 事变解决的流程和准则有哪些？
- 相干管理制度怎么设置比拟正当？
故障复盘的四大留神项：
- 事变复盘不是给人定责的，要有零碎思维将优化项理论落地能力推动系统优化；
- 事变报告的重点应该是事变晋升项，监控、定位、根因、架构四个局部都必须波及；
- 事变报告的价值不仅仅是记录复盘故障，集中管理起来是很好的培训资料，能防止新人入职后走弯路；
- 架构师review是整个事变报告价值最大化重要的一部分，能够横向帮忙企业研发团队互相借鉴避坑。
道兵老师联合实践经验分享了许多干货，感兴趣的能够往下浏览残缺内容。
很多人应该都有关注SpaceX，从MK1到SN12所有的飞行器都没有胜利，那这个试验到底是失败了还是胜利了呢？借用埃隆·马斯克话来说这是一次胜利的失败，他们公司从这些失败中吸取的教训远比一次胜利的航行多的多。SpaceX 的胜利，让咱们看到如果可能系统地从失败中学习，咱们的进化速度能有多快。明天就从上面几个方面来给大家分享一些我的教训心得：
- 怎么无效升高故障的影响？
- 事变解决的流程和准则有哪些？
- 相干管理制度怎么设置比拟正当？
一、怎么无效升高故障的影响？
不同产品不同的零碎它其实齐全不一样，有的以产品性能、用户体验为护城河，像美团、支付宝这种，我不理解。从2010年到2020年我做了差不多十年的云，以稳定性和信赖为护城河的零碎，这一块我略懂一点，明天就想分享一下我这一块的教训。要做好云要有很重的资本投入，要有解决方案架构师团队，要有好的产品，再细分就是性能、老本和稳定性，明天就专一稳定性这块跟大家具体聊一聊。
1、确定高可用指标，而后拆分它
升高故障影响首先要明确你的高可用指标，再围绕指标去做具体的拆分和优化。提到稳定性就会想到可用性，可用性达到3个9每个季度有2小时的不可用工夫，4个9每个季度有13分钟不可用工夫，5个9每个季度就只有1.3分钟的不可用工夫。明天讲的内容是为了帮忙大家达成3个9和4个9 的，也是大部分企业以后的指标，想要冲击5个9的就要做自动化了，用机器代替人力，那就须要一个齐全不同的设计了。
不可用时长最简略的计算公式是：不可用时长=90天/MTBF*MTTR。MTBF指的是两次故障之间的距离时长，MTTR指的是单次故障从产生到复原所破费的工夫。要想缩减不可用时长，从公式上来看很简略，就是增大MTBF或者缩小MTTR。
2、从不同角度去想，具体能做些什么
2.1 增大MTBF
想要增大MTBF，有3个方向是能够做的——
- 首先是开发过程的品质管制，这个很重要；
- 其次是压测标准，因为很多不可用都来自压力过大，压力过大导致系统间接爆了，所以压测须要标准起来；
- 最初是上线流程，很多故障都产生在上线的霎时，因为上线就意味着变更，变更就是事变的一个常见起源，明确上线前如何进行灰度，问题怎么排查怎么回滚，这些上线流程做好了也能躲避掉一些事变。
2.2 缩小MTTR
单纯的增大MTBF肯定是不够的，举个极其的例子，你曾经一年间断4个季度不出故障，考核没事了，第五个季度来了个影响时长超5小时的大故障，你可能就间接被干掉了，所以缩小MTTR也是必须要做的事件。
将MTTR合成来看，次要分成故障发现、故障诊断和修复止损3个阶段，那这3个阶段咱们应该做些什么来升高这部分的工夫呢？
1）故障发现阶段
针对这个局部你得先搞清楚你的故障是客户发现的还是你本人发现的，如果是客户发现的那这部分的工夫就不可控了，能不能变成本人发现的，变成本人发现起码能缩小一部分的工夫，那本人发现的能不能通过一些伎俩来缩短发现工夫也是一个点。
2）故障诊断阶段
发现问题之后，如何进行疾速诊断是重点。如果齐全依赖人工，当你晓得故障产生、关上电脑进入零碎排查可能你的不可用时长就曾经超标了，所以零碎的自检能力建设很重要。自检后果是否有汇总面板，是否疾速放大故障范畴，能不能一键让零碎本人跑一套规范的测试来通知你问题出在哪里，这些都是能够优化的点。
3）修复/止损阶段
这个局部我首先要问你一个问题，针对故障你是否有对应的预案，预案是否有过演练是否可施行，有预案能够疾速响应止损解决一部分的问题。那修复止损难道就是改bug吗，显然不是，因为改bug真的很慢，兴许你从2个9冲击3个9还能够思考采取这种形式，但当你要冲击更高的稳定性指标的时候，就要学会应用其余更高效的修复形式了，比方针对故障的模块进行疾速降级。
如果遇到不得不修复的问题，那有几个要点能够来缩短这部分的工夫：
- 值班制度：要求随时有一个人可能拿到电脑来操作解决问题；
- 双人互备制度：当一个模块只有一个人理解具体的逻辑，万一这个人不能及时声援就会出问题，所以在研发的时候就要思考到这个，每个模块都起码有2个对整体了解透彻的人；
- 现场指挥制度：每次遇到大型事故现场都会十分凌乱，所以这块的设计就显得很重要，也能无效缩减修复的工夫。
二、事变解决的流程及准则有哪些？
大部分大型零碎从上线到可能齐全安稳地运行，都须要一个打磨过程，短则几个月长则须要几年。除了零碎自身的差别，是否有利用好每一次事变来改良本人的零碎也是一个重要的点。每次事变都会有事变报告和事变复盘的过程，如果不清晰这些流程的目标，那么就会流于形式，也丢失了通过事变来改良零碎的机会。
作为架构师团队的负责人，依据以往的工作教训我设计出一套事变的解决流程：止损—定位—疾速复盘—事变报告—架构师review—整改跟进，配套的还有一系列解决准则能够去领导我和我的团队更好地解决事变。
1、止损
1）止损永远是第一优先级
为什么要特意强调这个，因为所有的工程师都有很重的好奇心，在事故现场他们最想做的事件就是搞懂到底产生了什么而不是优先复原零碎服务。如果你有提前准备预案，那么就严格依照预案执行即可。
2）在保障止损成果的同时尽可能的保留事故现场
这能够为后续的定位工作提供方便，可如果保留现场会影响止损，那么还是止损优先，之后再思考如何通过革新零碎来晋升在止损时保留事故现场的能力。比如说搭建一个好的日志零碎，将所有的异样申请都记录下来，这也能帮忙咱们后续去还原事故现场。
3）止损现场要有一个决策人
决策人须要疾速断定如何止损，同时分工协调现场人员去达到止损的目标。现场最怕的情况就是只有两三个人忙的团团转，而其他人不晓得本人该干什么，也不敢去做相干的决策。
4）止损现场放弃沟通
最好的情况就是大家都在现场，那么一起疾速搬进会议室面对面地沟通合作，如果不能做到这个，决策人应该立即发动电话会议，保障大家的信息及时同步，减少近程合作的效率。
5） 及时告诉客服团队
这一点很好懂，有问题不告诉客服团队，对外沟通呈现问题，客服团队肯定会投诉过去。
以上这些止损的准则其实都是为了帮忙你更好更快地实现止损的动作，止损之后再开始思考后续的定位工作。
2、定位
1） 止损根本实现前不要花精力在定位上
止损根本实现前不要花精力在定位上，除非止损自身须要定位。如果说不进行定位止损就做不了了，那么应该立刻差遣团队最优良的人和最相熟该模块的人一起分心定位。为什么要两个人来做这个事件，因为最相熟的人很容易陷入本人的思维误区，认为本人做的就是对的，这时就须要另一个人来独特梳理，剖析业务逻辑外面有没有可能出破绽的中央。这时现场决策人就须要做一些分工，让大家去分头收集信息并察看异样情况，有什么信息都要及时汇总。
2）不要轻易停止定位
有时因为压力产生的故障，当流量顶峰过来，故障也就隐没了，这时不要轻易停止定位，防止未能发现问题根因或者因为偶合导致问题隐没。
3） 定位相干信息要时时记录
这是我常常遇到的状况，很多定位人员定位完结了，但整个逻辑链条外面很多证据都没有保留好，尽管得出了定位论断，但过程证据并不充沛。所以我会给他们提一个要求，在定位的过程中手边要开一份文档，最好能粘贴图片，随时把定位过程中的信息拷贝到文档里，不便后续查看。
4） 定位的论断能够是无奈定位，但要给出后续改良意见
我常常会强调一个观点，定位的论断能够是无奈定位，但肯定要给出事变再次发生后如何定位的改良意见。有时候故障就是隐没了，定位不到也是可能产生的，但在事变报告中要明确之后该怎么做，这样当再次遇到这个故障时能力疾速精准地定位。
3、疾速复盘
在定位实现之后我个别会进行疾速复盘的动作，拉上两三个人开站立会议，个别由负责定位的人来主讲，讲清楚事变产生的逻辑，其他人来给出信息补充或者提出质疑。当无奈排除正当狐疑时，就须要持续定位了，直到齐全定位完结。当你的逻辑都理分明了，就到了探讨事变晋升项环节，这块前面我会再开展讲。负责人在这里还要做一件事件就是安顿大家收集事变报告的必要信息，并安顿人来撰写事变报告。
4、事变报告
事变报告并不是因为出了事变，你搞砸了，我要惩办你去写书面文档，而是说这些内容很有价值，后续也会成为培训的材料。当新人进来，他能够通过这些事变报告去理解以前零碎出过哪些问题，后续又是怎么解决的，所以事变报告的逻辑肯定要残缺。
依据我的教训，事变报告应该要包含事变影响、事变工夫线、事变起因剖析、事变晋升项这几局部的内容。
1）事变影响
这部分肯定要把对应的监控图给及时截取进去并保留下来，因为监控零碎不会始终保留之前的数据，几个月或者一年之后可能数据就没有了。
2）事变工夫线
事变的工夫线记录很简略，要从事变的第一次上线开始讲，此外你不要去加逻辑，就是简略地把事变处理过程中每个工夫点零碎产生了什么变动，对应的人都干了什么做了哪些尝试这些货色梳理分明。
3）事变起因剖析
这里是须要把逻辑讲清楚的，你要多画示意图，通过示意图来清晰展示这个架构下导致故障的起因。这里有个很重要的点就是不能推测事变的起因，要排除大量的正当狐疑。单讲清楚事变产生的逻辑是不够的，还要讲清楚为什么其余的正当狐疑是不成立的，防止大家破费大量的工夫最初得出的是谬误的论断，做了谬误的优化。
4）事变晋升项
这部分我要具体说说，这块我是有具体的规范要求的，监控、定位、根因、架构四个局部都必须要有，哪个局部通过剖析的确没有晋升项就写“无”。
- 监控：两个自检的方向，事变产生后你是否第一工夫收到了监控告警，事变产生前有征兆，征兆的内容是否监控到了，如果这两个局部都OK那根本能够说监控局部没有问题。
- 定位：现有的定位流程是否通顺，有没有什么改良的点，比如说须要一些工具，或者说欠缺日志的全文检索能力、日志的格式化与可视化能力，以此来晋升定位的效率。
- 根因：根因是整个事变报告里最简略的局部，什么起因导致的事变修复优化了哪些货色。额定要说的一点是一个零碎必须有2层防御能力，只有这样能力释怀，不必放心下一次会呈现一样的问题。
- 架构：有些问题是须要通过更加宏观的变更来解决的，这部分要明确如何通过架构的变更来从根本上来打消事变的隐患。
5、架构师review
架构师review是整个事变报告价值最大化很重要的一部分。倡议大型团体都将高等级的架构师会集到一起组成架构师委员会，这不是一个名称荣誉，是须要他们来干实事的，其中一个局部工作就是定期散会review事变报告，大略2-3周一次。
review事变报告有几个点很重要：
- 督促大家产出的事变报告得合格，必须信息残缺、根因剖析透彻正当、晋升项没有问题；
- 在各个团队间进行触类旁通，对相似的危险点进行排查；
- 提供一个不同团队之间高等级的架构师的交流平台，互相学习；
6、整改跟进
每个事变报告的晋升项要写明负责人和预期的实现工夫，架构方面的晋升项个别用时比拟长也不太紧急，然而也要写明工夫，而后由项目经理团队继续跟进每个晋升项的落实状况。最怕的就是一些中等级别的事变，事变报告的晋升项洋洋洒洒写了很多，但没有具体落地施行，等到下次呈现一样的问题时才发现之前没有做整改。晋升项当然也是能够放弃的，但必须要有充沛的理由。
后面架构师review会议产生的一些论断也是须要独自立项跟进的，这些整改跟进都落实到位了，能力对系统的稳定性晋升有实质性的帮忙。
三、相干管理制度怎么设置比拟正当？
云平台自身是一个很宏大的零碎组织，后面说了很多标准化的解决流程以及相干的准则，但组织是个有机体，所以这外面还波及人的治理，这就须要管理制度来做辅助了，这边分享几个要点。
1、不要给低等级事变设指标
大家都会给零碎事变定等级，P0、P1、P2、P3，而后针对故障等级去设立不同的指标。我为什么说不要给低等级事变设指标，因为这个指标的设立容易让大家瞒哄低等级的事变。即便你的指标设置的很宽松，比如说这一个季度P2等级的事变不能超过10个，但只有设置了指标，上面的人就会想这个事变没有人发现那我就不上报了吧。这就会节约一次通过故障去晋升零碎的机会。
2、事变报告不要查究人的责任
事变报告不要查究人的责任，因为你是在建设一个零碎，事变报告的晋升项就应该体现在代码上，或者体现在一些强无效的文档里，比如说预案文档、值班制度文档。
3、要培训激励大家写事变报告
大家都感觉本人脑子好，不违心去入手写文档，这时候就须要通过培训去要求和锤炼搭档们的事变报告输入能力，激励大家多写报告，形容分明，理解它的价值。
4、事变报告要集中管理
事变报告的集中管理是为了不便后续的复用，它是很好的新人入职培训资料。咱们在书写的过程中不会去强调具体的人的责任，读起来会更主观，新人在浏览这些报告时可能理解零碎的逻辑框架，晓得一些逻辑写法会产生问题，就能更好地回避这些。
四、一个小小的实际分享
跟大家分享一个之前我还在云公司的小故事，这个工夫有点长了。
过后咱们还没有大范畴的去应用容器，在做一个小的上线动作时，在reload之后发现有一台机器齐全不能用了。工程师过后十分的好奇问题出在哪里，想去做定位，我说咱们应该先把这台机器下线而后持续跑。后续咱们要做定位的时候就发现十分的诡异，一大堆的数据没了，其实是一整个的目录都没了。咱们看了这台机器的操作记录，跟旁边的其余机器并没有什么差异。过后咱们的运维须要对多台机器做批量解决，他就找了一个能同时管制多台机器的terminal来做指令下发。运维的操作也很标准，先创立一个目录来进行相干操作，实现之后回到下级目录删除这个目录，后果就发现有台机器出问题了。
具体是什么问题呢？目录的名称是fobar，这个名称大家都很罕用，很可怜的是这台问题机器里某个目录下有个叫fobar的文件，在创立目录的那一个环节其实就曾经失败了，没有进入到这个新建的目录外面。但后续的很多操作又都胜利了，所以返回下级目录删除时呈现了问题，间接把原目录干掉了。这里fobar文件的追溯是很难的，你不晓得什么时候做了这个操作，也没有相干的监控伎俩。
针对这个问题，咱们后续的整改形式就是terminal一律不准再用了，转而应用ansible来管制机器，在其余部门分享这个故障案例的时候也是取得了统一的认同，不再应用terminal，因为不晓得哪一天会呈现故障，起初咱们也逐渐建设了ansible脚本库。当然当初曾经进入docker时代了，这些内容曾经没有意义了，但从某种角度来讲docker又是解决这个问题的一种新的架构。
五、写在最初
2年前我来到了京东云，其实是有很多想法没有去落地实现的，这边跟大家分享一下，心愿能给大家更多的启发。
1、主动根因剖析
当你领有几万台机器几千个服务的时候，就不是有没有监控警报的问题了，你永远都会有警报。那么就会产生一个需要，怎么围绕事变景象去把相干的警报筛选进去，过后有个想法就是去做零碎的逻辑自检模块。简略来说就是每个零碎都要明确本人依赖哪几个模块，这几个模块对系统的影响具体是什么。
2、黄灯与主动修复
红灯是事变、绿灯是失常，黄灯是须要尽快修复的局部，黄灯往往是事变呈现前的征兆，围绕黄灯来设计相干的主动运维体系，就能保障很多事变扼杀在产生前。
3、K8s+混沌测试冲击5个9
K8s是一个十分好的自动化运维平台，配合混沌测试的伎俩就能够打造一个十分持重的零碎。这个持重并不是说我的零碎没有任何的bug，而是面向所有可能呈现的状况我都有对应的预案，并且这些预案都曾经固化在我K8s的脚本外面，这样才有机会去冲击5个9。
关注公众号后盾回复关键词【7162】即可获取讲师PPT
讲师精彩直播回放：https://news.shulie.io/?p=5016
发表回复