如何获得讲师PPT：
扫码关注公众号，后台回复「Q105」即可获得讲师PPT哟～
还能一键订阅后续精彩活动内容～
Q&A环节答疑：
1、（故障演练）恢复时间目标是多少？
2、小流量验证的时候，怎么保证流量的分配均匀、准确？如果流量倾斜的话，验证结果会不准确的吧？
关于小流量验证和流量的均匀分配，我大致理解了其意义。以用户ID尾号为例，若将尾号为01的用户导向故障层面，可能存在一个问题：该用户的使用习惯或功能偏好可能并不在核心功能或我们期望验证的功能范围内。 为了更精准地验证特定功能，我们可以在流量规则中进行更精细化的配置。除了尾号外，还可以针对访问特定API路径的用户进行配置。例如，尾号为01且访问了某个特定API的用户也可以被导向故障层面。 在单独验证某个接口时，我们需要提前评估该接口的流量程度。为了确保功能的真实流量能够顺利进入线上环境并到达故障层面，我们可能会考虑扩大尾号的范围。总之，我们的目标是确保真实的用户流量能够触发并验证故障层面的表现。
3、设计故障用例、包括人工验证这块，方便分享一些经验吗？
在设计用例时，我已经提到了几个关键点，包括断言的方面。现在，我想补充一点关于自动化测试的内容。对于自动化测试，我们是否需要对某个具体响应的某个字段数据进行非常精确的匹配呢？经过评估，我们可能不需要非常精确的匹配，而只需要一个相似的匹配即可。例如，在降级场景下，某个接口仍然能够返回数据，即使这些数据不如线上那么完整或精确。我们可以通过判断字段是否有值这种模式来设计用例，这样会相对更方便。 至于人工验证方面，我并不是非常专业，因为在我之前的工作中，主要是熟悉这块业务的测试人员来负责的。因此，对于人工验证的具体细节，我可能无法给出太多专业的建议。
4、如果mock可能会导致异常，如果直接回放也会异常因为失效了，这里有什么好的办法？
直接回放功能依赖于流量达标和流量隔离的能力。由于直接回放涉及状态管理问题，如缓存和存储层面的数据，因此建议在具备这些能力后，再在预发布环境或线上环境进行真实的回放操作。若缺乏这些必要能力，直接回放可能会引发问题。具体来说，直接回放出现异常的原因需要具体分析，以便确定问题所在并采取相应的解决措施。
5、强依赖和弱依赖的故障用例设计，有啥不同吗？
在设计用例时，如何考虑依赖验证是一个关键问题。对于依赖，无论是强依赖还是弱依赖，其运营设计本质上并无显著区别。在当前的设计背景下，以缓存为例，若未采取任何降级措施，那么对于业务而言，缓存即为强依赖。因为一旦缓存失效，若无相应措施，接口返回的数据可能会出现问题。
然而，若我们实施了缓存的降级策略，比如将数据库作为后备，当redis故障时，接口仍能获取数据。这种故障场景在设计用例时也必须考虑。我们需要明确系统的当前状态，并有一个预期：依赖到底是强还是弱。例如，若无任何保障措施，预期依赖为强，则在用例设计时，该接口应能报告错误。相反，若已实施有效的降级方案，则在设计用例时，接口应能正常获取数据。这就是在设计用例时，针对不同依赖类型需要考虑的不同点。
6、请问，自动化引擎在演练执行过程中，如果出现故障或异常，怎么快速定位问题和恢复服务？
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫