2

架构设计：线上服务故障应急机制讨论

 2 years ago
source link: https://blog.csdn.net/hguisu/article/details/126599183
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

架构设计：线上服务故障应急机制讨论

hguisu 于 2022-08-30 10:58:57 发布 18

最近由于疏忽误操作导致一次大故障，在此结合网上和实践经验，总结一下线上服务故障应急机制，警惕自己时刻注意服务稳定性问题。

    · 事故的发生是量的积累的结果。
    · 再好的技术、再完美的规章 ， 在实际操作层面也无法取代人自身的素质和责任心 。

    · 任何事情都没有表面看起来那么简单 。
    · 所有事情的发展都会比你预计的时间长 。
    · 会出错的事总会出错。
    · 如果你担心某种情况发生，那么它更有可能发生 。

警示我们，在互联网公司里，对生产环境发生的任何怪异现象和问题 都不要轻易忽视，对于其背后的原因一定要彻查。同样，海恩法则也强调任何严重事故的背后 都是多次小问题的积累，积累到一定的量级后会导致质变，严重的问题就会浮出水面 。 那么，我们需要对线上服务产生的任何征兆，哪怕是一个小问题，也要刨根问底: 这就需要我们有技术攻关的能力，对任何现象都要秉着以下原则： 为什么发生？ 发生了怎么应对？ 怎么恢复？ 怎么避免？ 对问题要彻查，不能因为问题的现象不明显而忽略 。

一、线上应急的目标、原则、方法

488c099622db494bbf302c202f048fee.png

1、应急目标

     行动的方向在关键时间正确把握，在应急过程中不能偏离目标。

     生产环境发生故障，要快速优先想办法恢复服务，避免或减少因故障造成的损失，降低对用户的影响。

2、应急原则

对应应急原则总结如下：

（1）第一时间恢复系统而不是彻底查找原因解决问题，快速止损。

（2）有明显的资金损失时，要在第一时间升级，快速止损。该条用在金融领域尤为关键。

（3）当前应急负责人若短时间内无法解决问题，必须升级处理。

（4）应急过程中在不影响用户体验前提下，要保留部分现场和数据。便于恢复后定位分析问题原因。

3、应急方法和流程

     线上应急必须有组织、有计划的进行。

4、线上应急主要分为六个阶段：

应急要有总体目标：尽快恢复问题，消除影响。不管应急的那个阶段，首要问题都是优先恢复系统问题，恢复问题不要求立马定位问题，也不一定有完美的解决方案。

一般通过经验判断，启动线上的问题预处理方案等，达到快读恢复问题的目标。同时，要注意保留部分现场，便于事后定位解决并复盘问题。

1)、发现问题

通常针对系统层面来说的，问题的发现一定是借助于系统的告警、自动化监控等机制来实现的，不能由用户、业务方来告诉通知你的系统出现问题了，如果这样，你的系统出现问题已经持续了一段时间了。

监控层面，通常都是对系统层面、应用层面、资源层面进行监控。

对系统层面的监控包括：系统的CPU利用率、系统负载、内存是会用情况、网络IO负载、磁盘负载、I/O等待、交换区的使用、线程数及打开的文件句柄数等进行监控，一旦超出阈值，就及时告警。

对应用层面的监控包括对服务接口的响应时间、吞吐量、调用频次、接口成功率即接口的波动率进行监控。

对资源层面的监控包括对数据库、缓存和消息队列的监控。我们通常会对数据库负载、慢SQL、连接数等进行监控；对缓存的连接数、占用内存、吞吐量、响应时间等进行监控；对消息队列的响应时间、吞吐量、负载、积压情况进行监控。

2)、定位问题

首先要根据经验来分析 ，应急团队中有人对相应问题有经验，并确定能够通过某种手段来进行恢复，则应第一时间快速恢复，同时保留现场，然后定位问题。

应急人员定位过程中可能需要与业务负责人、技术负责人、技术人员、运营和运维一起，对产生问题的原因进行快速分析。

需要考虑如下问题：

（1）问题系统最近是否进行了上线操作？

（2）依赖的基础平台和资源是否进行了上线或者升级？

（3）依赖的系统最近是否进行了上线？

（4）运营是否在系统里面做过运营变更？

（5）网络是否有波动，联系运维人员协助排查？

（6）最近的业务访问量是否正常，是否有异常流量？

（7）服务的适用房是否有促销活动？

3)、解决问题

解决问题的阶段有时在应急处理中，有时在应急处理后。理想情况下，出现问题系统启动应急预案，每个系统会对各种问题设计止损、兜底、降级开关等策略。因此，发生严重问题先使用启用这些预案来恢复问题，之后再定位和解决问题。

解决问题当然要以定位问题为基础，必须清楚的明确分析出问题的根本原因，再提出解决问题的有效方案，切记没有明确原因之前，不要使用各种可能方法来尝试修复问题，这样可能还没有解决当前问题，可能会引出了另外一个问题。

4)、消除影响

解决问题时，某个问题可能还没有被解决就已恢复，无论在那种情况下都需要消除问题产生的影响。

5)、复盘问题

消除问题后，需要应急团队与相关方回顾事故产生的原因、应急过程的合理性，对树立处理啊的问题提出整改措施，主要聚焦一下几个问题：

（1）类似的问题还有哪些没有想到？

（2）做了哪些事情，这个事故就不会发生了？

（3）做了哪些事情，这个事故即使发生了也不会产生损失？

（4）做了哪些事情，这个事故即使法神过来，也不会产生这么大的损失？

当然，回顾事故目的不再犯类似的错误，而不是惩罚当事人。

6)、避免措施

根据回顾问题提出的改进方案和避免措施，我们必须以正式的项目管理方式进行统一管理，如果有项目经理的角色，则将避免措施和改进措施一并交给项目经理去跟进；如果没有，则请建立一个改进措施和避免措施的跟进方案和机制，否则，久而久之，问题就被忽略了。

二、技术攻关方法论

技术攻关流程图：

c2760c229766aa5e011e88ab5e364bc2.jpeg

技术攻关的目标是解决问题。

从问题发生的环境和背景入手，优先考虑上述图中的提到的几个问题：

1、最近是否有变更、升级或上线操作？

优先考虑这一条，特别是上线完成后收到系统告警，用户反馈的相关问题及时关注，如果因上线导致出现的问题，要第一时间回滚处理，避免扩大影响。

同时，建立健全上线流程和上线评审机制，每次上线都需要有快速回滚方案。

2、之前是否有遇到过类似的问题？

根据历史经验判断系统是否曾出现过相同或类似的问题，如果有解决类似的问题经验，可以参考快速的应用历史经验解决问题。

要求每次故障后复盘并总结故障原因，并给出问题解决方案，积累到经验库。

3、是否有相关领域的专家？

遇到了更深层次的问题，比如遭遇DDOS攻击、性能扛不住、网络故障、使用的中间件频繁告警等。类似问题先求助相关领域专家，他们积累了更加丰富的经验，或能更深入了解原因并快速解决问题。

以上流程仍然无法解决问题，就需要自己想办法做技术攻关了。

三、问题分析方法论

对于任何问题的分析，需要从以下几个方面入手来分析：

简称：5W

When：什么时候出现的问题？

What：什么出现了问题？

Who：谁在什么时间里发现了问题？问题影响了谁？

Where：哪里出现了问题？

Why：为什么出现了问题？

根据以上的分析，帮助你理清思路，初步对系统做判断，然后从这个系统的日志、数据、工具，并结合代码定位分析问题原因。

这里也就体现了系统中日志的重要性，好的日志能协助快速而准确的定位问题。

可以想办法「最小化复现」线上问题，最小化复现是问题产生时所依赖的组件最小化集合，容易搭建，减少了使用组件的范围，有助于迅速定位问题原因。

如果能在一个可控的环境或者仿真环境上重现问题，或者通过远程调试的手段也能协助定位问题。

定位到问题原因后，要给出解决方案。

评估解决方案对线上的影响，权衡利弊，选择最佳方案，并给出选择的原因。

将问题解决方案报备给上级进行评审，评审通过后再实施。方案需要在开发环境和QA环境进行验证，不仅仅要验证方案所解决的问题，同时，还要避免对现有功能有所影响，因此可能还需要进一步回归验证。

通过这样一系列技术攻关流程，可以保障技术攻关过程中得到完整、正确且高效的问题解决之道。


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK