写在系列开头
集团在异常检测方面做了很多积淀，本系列将开始总结一些常见的问题以及解决办法，为后来人或者感兴趣的人快速上手，权当抛砖引玉，如有兴趣或者问题可以留言或@冷愁
本章作为整体概述，站在运维的角度、日常应急处理的视角，描述现有遇到的问题，在后续的篇章中会针对每一个遇到的问题提供响应的解决方案
什么是异常检测
在开始之前，我们需要聊聊什么是异常检测。
引用*的说法
In data mining, anomaly detection (also outlier detection) is the identification of items, events or observations which do not conform to an expected pattern or other items in a dataset.
-Wikipedia Anomaly Detection在数据挖掘领域，异常检测（异常点检测）是在某个数据集中区分出不服从于已知或预期的模式（或分布）的条目、事件或者观测点。
Hawkins [Hawkins 1980]的定义：
"An outlier is an observation which deviates so much from the other observations as to arouse suspicions that it was generated by a different mechanism "
异常点就是相对于其他观测点来看有明显偏离的点，以至于怀疑其与正常点来说不属于同一个产生来源。
上述是较为直观的异常点定义，但是如何转换成机器语言或者监控方法？
主流的异常检测方案大体有以下几种：
- 基于密度的异常检测（LOF）
- 基于统计的异常检测（Holt-Winters、Confidence Interval）
- 基于偏差的异常检测（同比、环比、基线比）
- 基于距离的异常检测（KNN、Isolation Forest）
目前主要还是根据下面的统计学定义来的：
正常的数据基于一个已知分布，例如一些给定的统计学分布（泊松分布、正态分布）
异常就是明显偏离这个已知的分布的部分或点
再思考一个点，异常的本质是什么？
监控指标（就是一条曲线）的本质实际上是一个信息集合，大致分为两部分的信息
- 基于时间维度的（自身历史的数据）
- 基于同系列的维度（例如各个银行渠道，互相之间存在着信息，一个曲线下跌，其他曲线没跌，即为异常）
而以上两个维度中，2的信息不一定存在，如果仅仅从1看，那么可以通俗的理解为：
1. 历史上发生过的，今天再次发生了，认为是正常的
2. 历史上未发生的，今天发生了，那就是异常
有人要问了，我刚做了变更、重启操作，报警报出来了，这就是无效的报警呀？
所以我们为了后续的工作，必须要将此分解开来：
从数据集中获取信息进行检测我们称之为异常
人的超集经验对于报警的判定我们称之为报警订阅
从而将监控系统分为1. 异常检测 2. 报警订阅两部分
集团监控中异常检测的难点以及要解决的问题
一、季节性或周期性（Seasonality）
在实际应用当中，季节性是非常普遍存在的，例如下图中，红标的地方是否是异常呢？
貌似看起来是下跌了。但是再看过去几日的数据：
发现每天的时间点都会下跌，也就是说，这并不是异常。
这就是季节性或是周期性。
季节周期是我们监控中首先要解决的第一个问题，因为如果季节性解决不好，会导致我们的监控有大量的误报，具体表现就是每天固定的时间点都会报警，但并不是异常
二、异方差性（Heteroscedasticity）
什么是异方差？
方差我们可以直观的理解为曲线的抖动（波动）幅度，异方差就是指根据时间的不同，曲线或数据集的方差是不相同的。
我们还是从图上来看：
每天凌晨和白天的抖动幅度不一致，明显晚上抖动幅度比白天大。
大家应该能看出来问题了，如果异方差性存在，就会导致报警策略在白天、晚上的报警效果不同，这也是现在遇到的很大的问题，明明白天报警效果很好，但是到了晚上报警就非常多！
三、复杂周期性（Complex Cyclic）
什么叫复杂周期性？跟（1）的周期性有什么区别？
在日常监控中，我们会有类似的经验，曲线具有显著的天周期性（1440个点为一个周期），也会有星期周期性（1440*7 个点为一个周期），那两者都有呢？我们就有了2个周期。
除了天周期和星期周期，我们还会有月周期（例如月初冲话费、缴费的人明显增多），可是每个月的周期都是不固定的呀？有的月有28天，有的有29天，有的由30天或31天，这怎么办呢？
甚至一年也不是稳定的365天，也会有366天，平均下来就是365.25天，非整数周期什么鬼.....
这就是我们所说的『复杂周期性』
四、报警抑制（Alarm Suppression）
现在集团监控业务在飞速扩张，监控指标数也在迅猛增长，例如监控值班关注的监控指标都有几千个，每日处理报警近千条....
为了报警准确率和高效处理，我们的常规做法是不停的提高发现率、误报率，这样真的是有效的么？
五、故障原因定位（Root Cause）
故障定位可以说是重点，但是在内部一度成为谁做谁死的状态....这是什么鬼？
- 在集团内部，关系调用复杂，甚至有效的链路调用图关系都很难梳理。
- 某个中间件异常，导致若干业务收到影响，同时发送了大量的报警，如果在这么多报警中甄选有价值的信息？
在这种情况下如何引入统计过程分析来解决故障定位的问题呢？