无锡开发网站建设鲅鱼圈网站开发

当前位置： 首页 > news >正文

无锡开发网站建设,鲅鱼圈网站开发,龙华做棋牌网站建设多少钱,网站建设英语词汇复盘的终极目标是#xff1a;还原事实#xff0c;找到薄弱点加以改进。 提到复盘#xff0c;很多人的第一反应是线上故障#xff0c;有人要背锅了。 复盘真正的价值是还原事实#xff0c;在薄弱处加以改进。如何做一次高质量的复盘#xff0c;我们给出3点建议。 1、坦…复盘的终极目标是还原事实找到薄弱点加以改进。 提到复盘很多人的第一反应是线上故障有人要背锅了。 复盘真正的价值是还原事实在薄弱处加以改进。如何做一次高质量的复盘我们给出3点建议。 1、坦然接受故障的存在 在复杂的网络系统中出现故障是再正常不过的事情。故障带来的未必都是负面的意义譬如通过小故障发现一个大隐患。或者某次故障让相关人员意识到应急预案的主要性甚至是由于故障原因特殊造成较大的影响这些可以从故障复盘中获得的宝贵经验。 用辩证的眼光去看待故障遇到故障能快速恢复发现更多问题就是正向价值。 2、汲取经验提升完善系统设计 复盘是为了总结和改进复盘故障从中汲取教训进行学习提升我们的经验完善系统的设计能做到以下几点 1、找到根因优化改进。 2、找到降低故障发生概率的方法保障业务稳定运行。 3、找到让业务快速恢复的方法降低故障影响。 每一次的线上故障都是一次实战练兵的好机会除了系统本身的高可用我们的组织也应该是高可用的我们经常说好的系统架构是具有韧性的那么好的团队组织也应该是反脆弱的。所以复盘的过程中除了找系统本身的问题还要找工具的问题、流程机制的问题、管理的问题等等。这样我们才能由点及面的系统化地解决问题即治标又治本。 3、抓住复盘关键环节 1故障还原 还原故障即发生了什么故障影响什么业务或产品等基本情况。例如“x月x日xx时xxx系统出现异常导致了xxx影响了xxx业务表象为用户无法正常下单点击下单按钮出现网络开小差出现了大量客诉等等”。 让人第一眼了解清楚这个复盘的来龙去脉。 2故障影响范围 讲清楚本次故障的影响范围包括影响时间段、影响的业务(产品)线、影响的系统(服务)、订单量、用户量、客诉量以及有无产生资损等等。 3故障时间线回放 提升系统可靠性的两个关键手段降低故障发生概率和缩短故障持续时间。回放故障的时间线即先从旁观者的角度来理一遍故障过程是为了思考如何缩短故障持续时间(MTTR)拆解时间段: 1、从故障开始到应急响应介入的时间一般是考察监控告警、人员值班oncall的合理性。 2、从应急响应介入到故障定位的时间主要考察根因分析、可观测性等工具的能力。 3、从故障定位到故障恢复的时间主要考察应急预案、快恢体系的能力。 4、从故障恢复之后到确认故障已经解决的时间一般通过用户反馈、自动化测试等确认恢复。 因此在回放时间线的过程中也要注意对以下几个关键时间点进行识别然后逐个沟通讨论如何缩短其中的每一个环节耗时。 需要注意提前识别出来的关键时间点: 故障引入时间点: 即这个故障实际上是从什么时候开始的可能是某次变更发布/线上操作/其他等。 业务指标变化时间点: 业务指标开始下跌、开始恢复等 监控告警发出时间点: 即监控是从什么发现异常的告警什么时候发出的。告警的级别、接收人是否响应超时等相关信息都要记录进来。 人员介入响应时间点: 故障对应的系统值班owner是从什么时候开始响应的。 异常定位时间点: 即定位到故障的异常点注意:故障处理过程中的根因定位并非是最底层的根本原因而是指初步确认了故障的异常点可以进行下一步的应急止血动作。 关键操作时间点:是否做了一些应急预案包括重启、恢复、止血、高可用配置等。还需要写清楚每个操作的结果即每个操作之后报错面有无缩小、系统资源水位有无变化等。 确认故障恢复时间点: 通过测试验证或者观测业务指标、系统日志等确认系统已经恢复。 4、深挖根因 一般情况下故障是由两类原因引起的包括直接(诱发)原因和根本原因也就是所谓的诱因和根因。 因此在复盘过程中既要明确诱因更要深挖根因。比如说某个业务系统由A/B/C 3个服务组成依赖关系依次是A依赖B、B依赖C某次开发同学修改了线上C服务的一个配置使用了错误的格式导致了整个业务系统不可用。那么在原因分析过程中把配置文件修改为错误的格式这个动作肯定是直接原因但是也要注意B服务对C服务的依赖关系是强依赖么?如果C服务出现异常的情况下B服务是否要进行兜底?等等。 可以基于5why分析法深挖根因多问几个为什么层层递进比如说这样的一个场景: 线上系统运行过程中某个ES节点突然抖动RT时间明显变长95线由200ms升至800ms然后引发了上游业务异常。那么在分析原因的时候要问以下几个问题: 1、为什么ES会抖动? 2、ES的可用性标准是什么? 3、ES抖动之后有出现告警吗?相关人员有第一时间介入处理吗? 4、ES抖动之后上游直接使用它的服务有兜底措施吗?是否为强依赖? 5、对于这个业务场景来说ES的直接上游系统是这条链路的核心依赖吗从整个链路上有无兜底机制? 要层层递进深挖根因千万不要浅尝辄止那样可能会错过真正的改进事项。从以往的故障来看很多问题背后都是系统设计的问题这样的问题挖得越深我们的系统可用性才会越强才能慢慢朝我们理想中的高可用架构前进。 5、改进项汇总 把时间线和根因分别确认清楚之后就能推导出我们对于本次故障复盘的改进事项了。在梳理改进事项的时候除了与故障相关系统的改进项之外还需要从整个故障处理过程来看在故障的各个环节中有无需要优化改进的地方。 比如说某个故障是靠人工(用户投诉)发现的那么要考虑下这个业务的监控告警是否完善是否能够降低故障触达时间;比如说某个故障的告警发出之后迟迟没有人响应那么要从管理制度来看对于应急值班政策的执行是否到位;比如某个故障的排查过程中定位比较苦难很多地方要靠人工去梳理很多信息那么要考虑相应的排障工具是否好用、应急预案机制是否完善等等。 还有很多其他的问题大家可以参考上面的MTTR分解环节和故障根因分解环节自己展开思考下这也是上面说要深挖根因和详细分析时间线的目的这样我们才能不浪费每一次故障的机会。 在记录改进项的时候可以考虑结合SMART原则来设计改进项: 1、S - 必须是具体的(Specific)改进项必须是可以落地的不要泛泛而谈例如”优化系统设计“这类就属于反例。重新设计A系统对B系统的依赖关系使其能够对异常进行兜底这种就属于具体的。 2、M - 必须是可以衡量的(Measurable)即改进项是可以评估的比如说通过故障演练来检验依赖关系的有效性。 3、可以达到的在当前的技术环境下这个改进项是可行的不要写未来太远的无法达到的事情。 4、其他目标具有一定的相关性可以理解与本次故障中其他改进项有关联性。 5、明确的截止期限要写清楚改进项的截止时间在到期之后进行验收。 最后改进事项重在闭环这个环即PDCA循环Plan(计划)- Do(执行)- Check(检查)- Act(处理)对于我们的故障复盘来说即所有的改进事项都必须经过故障演练通过实战演练来确保改进计划一定是有效的。 6、复盘过程中的几个关键问题 在复盘中可以把这些作为讨论的框架: 1、故障的根因是什么? 当前我们在聊的这个是根因吗?从业务场景对应的链路上看这个系统(组件)是强依赖吗?依赖是否合理、有无兜底机制。这次的变更流程是否完善、三板斧落实地是否到位。对应的观测指标是否能反映系统的真实状态应急策略是否有效等等。 2、故障为什么会发生可以避免或者降低发生概率吗? 也就是所谓的提升如果是变更引起的那么要考虑变更流程是否完善是否按照流程规范操作有无对应的防御机制。如果是某个系统组件失效导致的那么要评估该组件的可用性是多少与它所在的链路是否匹配这条链路是否要设计兜底方案等。如果是外部原因引起的那么我们对外部的这个依赖是否有过认真的评估对方的可用性能够满足我们的诉求。 3、如何快速恢复业务 1、监控告警的及时性与准确性。建立健全完善的告警机制保证快速准确的发现问题。 2、流程响应不同资产对应不同的SLA实现告警分级。对应相关人员。保障问题得到响应。 3、准确定位快速恢复。故障快速恢复降低业务影响为原则处理过程中切记不要跑偏。 4、应急预案在故障的处理过程中应急预案的有效性也将得到验证。 5、检测架构设计本身高可用是否完善是否具有容灾能力。流程制度是否规范是否需要优化。 很多故障只是表象大部分根因深挖下去都会有技术管理的因素虽然引发故障的操作可能是个人但是更应该从团队的视角去看问题避免把根因只归结到某个人身上。在故障处理过程中积极参与定位、快速止血才是正向之道。 最后复盘不是故障的结束改进事项经过验收才是因此每一个改进事项的相关方都应积极主动地push完成。同时为了最大化的利用好复盘文档的价值需要更新知识库存档与分发吸收前人经验避免重复踩坑。