如何获得讲师PPT：
扫码关注公众号，后台回复「0302」即可获得讲师PPT哟～
还能一键订阅后续精彩活动内容～
Q&A环节
1、新系统首次上线，系统问题还不明确，这种情况怎么设计全面的预案？
我讲一下我们的经验哈，有几个原则是说，新系统可能是为了某个业务服务，在做这个业务的时候，把业务分级之后，系统是不是也能做一个分级？因为把业务的核心与非核心分完之后，一个业务里可能说有好几个系统，那在这些系统里边，要做一个基本的分级。哪些系统是我的一个核心的P0级的系统？这些系统绝对不能挂的。哪些系统是我的P1级或者P2级B级别的系统？这种稍微低级别的系统。
把系统的分级做完之后，去看他们之间的一个依赖关系。也就是说对系统做了一个识别，哪些是我的关键系统。那重点是去保证核心系统的可用性。核心系统对我非核心系统的一个依赖关系去做成弱依赖。通过熔断、降级来做成弱依赖。然后来看核心系统，可能会包含有哪几个不管是java的微服务或是相关数据库的依赖。然后再去看一下怎么去设计预案，那可能就包括说对java应用的容量治理，因为这种预案的话，一般就看几个维度：容量、或者说是故障隔离、拉入拉出，或者是整个的紧急回滚。可以做这几步。
对于资源的话，可能就是包括一些数据库，存储资源或者其他中间件的资源。一般来说，我们这种系统都是一些集群式的，大部分都是一些HA切换、数据重新分片等这些事情。
总结来说就是：先区分业务场景，再对系统分级，然后围绕核心系统做一些关键预案，这样的一个思路。
2、老师您好，想了解一下：贵公司在业务影响分析方面，关于RTO/RPO的分析方面有哪些经验可以分享？
先讲一下我们整体的框架是：RTO与RPO的话，现在其实是在围绕整个MTDR应急响应时间，就是五五十，五分钟发现，五分钟定位，十分钟止损。
现在RPO/RTO，更多是来整个存储层的一个RPO/RTO。我们的目标的话，还是尽可能让RPO等于零，让RTO尽可能接近零。在数据不丢的基础上，尽可能恢复达到质量的目标。
问题比较大，分成两个维度来看。
像RPO、PTO一般来说的话，一般是说存储层也就是数据、Redis、DB，或者一些其他类的缓存。系统出现问题之后，怎么能够通过重建或者通过分片通过一些HA，让数据不丢，或者数据恢复的比较快，这是存储层的。那还有整个大规模外部的业务数据中心，这种可能就是说通过一些双活、多活，去考虑整个一个RPO、RTO了。
如果回到存储层面，现阶段是围绕着数据层去看整个存储的一些数据日志的维护情况。那就是像Redis、或者DB，现在是这样的一个建设方式。
简单概括是两个维度。一个是比较狭义的围绕一个底层存储，一个是比较广义的，就是你整个一个业务数据中心，可能就是说通过这种大规模的双活、多活，那小范围就是说围绕着底层存储，对这两方面去看的。
3、怎么保障预案的新鲜度？
是一个比较关键的问题。有的时候可能说我们做完了一个预案，后面的话日常迭代，在某一个重构时预案就废掉了，那这种情况呢，我建议还是需要有一个固定的机制，你要能够定期的去检查你的预案还能不能生效？这就需要通过演练。像我们就是每个月去制造一些故障去内部演练一下预案看能不能生效。通过在系统资源里注入故障，去看预案执行完之后，是否能够达到的预期。如果这个预期是ok的，那还要看一下观测，比如日志、业务指标能不能恢复？跟你的预期是不是一样？如果不一样的，可能就是有问题了。重点还是通过去演练，一定要演练。
4、老师讲到的业务主动梳理，是人工梳理么？
其实我们也很想找一个比较好的工具哈，但是在第一步梳理业务的时候，是需要人工的。因为在整个业务梳理的时候，还是需要产品、研发、运营大家一块坐下来去看。去圈一下现在整个业务域里面包含了好几个模块，哪些模块是你的核心模块？这个是要定化的。定完之后有这个业务，那接下就要去找链路。到链路的时候就可以靠一些trace的工具，一些内容去做最终分析，就可以去用工具了。但第一步业务的话，这个是要用人工的，因为这个是需要去沟通去决策的，它是暂时是没办法去做自动化这样的。
5、事后预案主要做哪些关键动作呢？
事后预案的话，它的一个主要动作/目的，还是为了回滚或者弥补之前做的预案的一个影响。所以主要是看一下前面的预案具体做了什么事情？呃，举几个事后预案的例子。像我们大促的话，事后预案一个是把之前那些降级的活动给它打开，另外也是说会把以前做的一些大规模扩容临时关闭的系统把它打开。
像在整个故障处理过程中的话，事后处理，更多是为了弥补一下之前故障期间对用户的一个影响。它会包含两个关键动作，一个动作是，用工具或者手段去这个相关的应用范围给它拉出来。第二个是说把确定用户的影响范围之后，接下来去做一些补偿或善后。在这个大促的时候，和日常故障处理的时候，这个事情其实是不太一样的。
6、数据库系统里，在实施预案时，特别是kill、sql相关的场景，怎么能避免误杀sql？
首先是会对指标的设置会比较谨慎，确实有的时候，单一指标确实有可能会出现误杀。
一般来说，会从两个维度看。第一个维度是说这种指标的话，可能考虑复合指标，也就是说不用单一指标。就比如说你整个cpu使用率，或者说业务报错，或上层应用的错误率，会有很多符合指标。另外一个维度是说为了防抖，防止指标一抖就出现误杀，还会有一个时间的维度。比如说，持续一段时间，某个指标的水位一直超过某一段时间了，这个时候再去做一些主动去杀的一个动作。所以总结来说。一个是多个指标去做共同的交叉验证，另外一个是说通过这个拉长时间维度，防止抖动的一个情况，大概是这样子的一个思路。
7、预案做完之后需要去演练，那我如果想在生产环境上去做预案演练，那我在生产环境上做预案演练需要注意哪些问题呢？
目前的话，也是业界很多做混沌工程这块，面临的一个痛点问题。像这一块，做的比较好的一个实践经验是说，我们会先在线下做模拟，也就是说，现在我们做的演练，不管是内部做的预案类型的演练，或是其他类型的演练，所有的演练场景和注入故障的类型，都是在线下先去验证过，因为线下环境做的比较安全一些，可以做的放心一点。然后线下环境做完之后，如果整体的故障情况、爆炸半径符合预期，整个预案执行过程也符合预期，这样的话基本心里有底了，然后再去线上做。
所以现在大概是说，线上做的是线下做的一个子集，是这样的一个情况，除非说是某些线下没办法做的一些非常极端的情况。这种我们会选择在业务低峰期做，就类似于说一些比较底层的网络演练，或是一些其他类型的带宽的输入演练，这种的话，我们可能会在一个业务低峰期，然后会跟相关的一些产品方、业务方讲好，我们会在什么时间做一个演练，然后预期的影响范围是什么样子的，到时候如果真的有问题的话，我们会有一个应急的恢复/保护手段。让关联方知道这件事情，并且他们也知道我们有一个相应的一个保护手段，所以这样就ok了。
我现在讲的这种经验的话，可能跟这个预案演练没啥关系，可能都是跟我们整个混沌工程本身的一个线上演练有关系的。还有一个点需要注意的，当然这个可能其实就是我们做稳定性的一个思路哈，就是要跟你的老板要跟他讲清楚，要让他知道，现在做这个演练是什么样的一个情况？预期会有什么样的一个影响？要让你的老板知道，最坏结果是可能会搞出一个P级别的故障，要让你的老板知道现在做的这件事情，因为整体上是需要他会去帮你兜这个底的，所以这块你要跟他讲清楚。这些一些可能是跟技术没有关系，但是又是在我们整个稳定的踩坑这么多年之后的一些比较好的一个心得。
8、因为毕竟没在生产上面演练过，假如说现在去生产上面演练注入一个故障之后，我按照预案去执行（可能预案不完善），当去注入故障恢复的时候，恢复失败了？有没有这种情况？
这种的话会把它分开来看，它会分两类。
首先是说，对于整个混沌工程平台来说，就是我的底层能力。我是要具备注入故障之后，是有防护手段的。比如说注入一个故障，这故障的持续时间是可控的。比如说故障注入五分钟，五分钟之内，不管说有没有执行预案，到时候这个故障必须被消除掉。这个是整个演练测要具备的能力。
第二点是说演练平台本身，也要具备止血能力。比如说他对某个线上系统，输入延迟了。或者说注入了整个exception。那可以通过把这个节点拉出重建，或者说对某一个网络的错误异常，通过整个容器，整个数据重启，或者隔离，能够把它恢复掉，平台本身也要具备防护能力。在整个应急预案失效的情况下。整个底层的一个演练平台，它要具备能够控制爆炸半径这样的能力。就是去注入的故障范围是可控的，而且故障持续时间也是可控的，这个是底层能力要具备的。不管做不做预案，这件事情都是预案要去具备的。
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫 