自动化运维场景分析

1）业务要升级某个业务规则，小二需要在若干系统管理后台里做新规则配置，如业务规则应用的系统，风控管理的系统等等，经常出现某新人不熟悉完整流程漏了某个系统的配置，导致完整的线上业务流程中断，由于业务中断的原因有多种，如何快速定位到并彻底解决这类问题成为痛点。

2）现在大数据算法在业务中发挥着巨大的价值，除了常见的推荐搜索外，在订单路由和履行决策等场景也大量应用。当升级某个算法模型时，如何做到按照最小业务单元的控制粒度来执行灰度，在出现新模型召回率、准确率下跌时如何做到快速回滚并对受影响的订单快速定位、分析和修复。

3）在分布式系统架构中，通过异步消息解耦复杂系统之间的强依赖是非常常见和优雅的架构设计策略，特别是一个 center/platform 级别系统通常会向依赖它的上下游系统发出一些自身业务单据操作或其他实体事件的 MQ 信息做为业务执行的触发条件与依据。为了避免引入过于复杂的系统设计，大家普遍采取非事务一致性消息模式，当遇到消费者系统故障或消息系统故障等各种因素导致某些消费者（consumer）出现消息丢失的情形时，作为 provider 或 consumer 如何快速发现并补全这类丢失的消息。

4）某算法引擎是个 CPU 计算密集型系统，但是由于 VM 资源隔离不干净经常出现同一台宿主机上的 VM 相互干扰导致 st 持续飙高，一旦出现这种现象就会导致算法引擎无法基于承诺的 SAL 给上游返回计算结果，从而影响业务行为。每次遇到这种情况，引擎的开发同学会第一时间分析是否为 st 飙高导致，一旦确认则通过 kill jvm 来粗暴快速的解决此次问题。此类 case 非常频繁，大多数通过客户反馈来驱动问题排查，在虚拟化资源隔离问题未彻底解决之前，作为上游的业务系统如何更高效、及时、主动的解决这类问题；

5）我们时常遇到线上突然告警，然后开发同学介入排查并执行预案（一般是几个配置变更）的场景，一般来说处理思路有如下几种：对上游做限流降级、对下游做依赖降级或启用备用方案、对某个变更做快速回滚。对于此类场景我们能否把其中有明确异常信号及处理流程的解决步骤流程化自动化，然后再去人工介入彻底解决呢？人的响应能力毕竟是有极限的，特别是非工作时段，如果能做到先“自动止血”尽可能降低影响面，然后再人工介入，业务上所受的影响会得到一定程度的降低。我们在业务上对异常的定义、识别、定位需要快速精准，要有备用解决方案，采用类似“熔断机制”的自主可控的处理思路来解决问题。