对智能感知的定义：更聪明的感知，通过引入新技术、人工智能，做到：感知范围全面，感知波动精细，知道影响根因，能抽象出实际业务架构图...。
智能感知关键工作：
- 感知影响范围；
- 感知波动变化（不仅仅是超阈值的报警，用于故障边缘的压测和演练，日常的运营）；
- 感知影响根因（大家都有波动、报警时，是谁引起的，谁放大了，谁削峰填谷了？）
- 感知强弱依赖，能抽象出实际业务架构图（这个环节的关键是剪枝操作，能判断出哪些是可以剪枝的，否则架构图完全不可读）
前两个做到了，才能做第三个，我们这里的根因分析不仅仅是故障时的根因分析，还包括波动，故障边缘的根因分析等。
智能感知的典型使用场景
在事故边缘压测和演练越来越重要
压测和演练时，如果出了事故和损失，业务是要写COE的；压测演练不出事故，很多问题又暴露不出来。
取舍下，我们是否可以在业务可接受范围内（出事故的边缘）做压测演练呢？ 既不出事故，也能暴露问题。
这就需要我们有：
- 强大的感知能力（自动化全面覆盖）
- 专家知识的预判能力（大量规则的维护）
- 快速止损的能力（能刹住车，积压的消除能力）
这也是混沌工程所期望做到的价值最大化，同时最小爆炸半径的演练。
日常运营需要从指标运营升级到感知隐患
技术运营的目的是提前发现隐患。而现在的运营只是对一些关键指标做抓手分析，这些指标跟是否会导致故障隔了很远，这也是业务是否重视该指标的一个主要原因？
比如慢查询，实际发生过什么样的事故？故障初期耗时的表现跟现在的表现有啥差别？
日常运营需要从指标运营升级到感知隐患，这样才更有说服力，价值更大。（从静态单一指标到动态多特征变化规则）
这就需要维护很多实际故障案例的特征变化规则，这部分规则维护成本高，只能自动化维护：
-
规则的持续维护难度高：就像目前的报警配置，太多地方需要配置，配置后过了一段时间后，规则是否还适合，由于规则多，很容易遗漏。
-
规则的沉淀，人工成本大（一次实际的故障，需要分析大量的数据找出异常点，人工很难全面分析）。
异常事件感知
异常发现逻辑：
- 对于饱和度类指标，要感知阈值，比如：容器、线程池是有限的资源，当超过阈值，会影响业务。
- 对于流量和吞吐量，要感知业务波动，看跟预期是否一样？业务波动时，并不一定会导致容量不足，但是仍然需要分析。每个服务的业务可接受波动都不一样？一个服务一个模型，维护成本高，除非必要，否则最好还是一个简单的通用模型。
异常事件输出：
- 何时或某个时间段，有哪些指标，出现了啥样的异常特征？
在链路级别，尤其要注意下面异常特征：
- 量级变化：全链路上，正常请求不会放大，是否有放大，是这个环节检查的。
- 走势检查： 谁先出现这个波动，谁有问题。注意：MQ会有削峰填谷的作用，会改变这个走势一致性。
在做持续优化时，一定要关注两个指标：
- 异常识别准确率
- 根因分析准确率
架构资产需要能感知业务变化
企业架构确定的原则是重要的架构资产，这部分是否被不断业务变更导致了变化呢？需要能主动感知到，而不是通过沟通来确定。
架构资产的感知主要依赖强弱依赖的判定。强弱依赖的判定需要架构梳理和验证，这部分工作要做到自动化、智能化。
同时对依赖要做抽象提炼，做到剪枝，整合出业务的架构图。
线上问题实时感知
上面几个感知是对历史数据的感知，实时性要求不高，数据相对来说比较全面。
当要做线上问题实时感知时，可作为凭据的数据并不全面，而且判定规则要求更快，对感知算法要求挑战更高，需要做算法依赖和算法精简。
总结
随着人工智能技术的逐步成熟，架构师要善用智能感知工具，才能以最小代价了解、分析问题情况，提升自己的业务价值。
