写在系列开头
集团在异常检测方面做了很多积淀，本系列将开始总结一些常见的问题以及解决办法，为后来人或者感兴趣的人快速上手，权当抛砖引玉，如有兴趣或者问题可以留言或@冷愁
本章作为整体概述，站在运维的角度、日常应急处理的视角，描述现有遇到的问题，在后续的篇章中会针对每一个遇到的问题提供响应的解决方案
什么是异常检测
在开始之前，我们需要聊聊什么是异常检测。
引用维基百科的说法
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）
故障定位可以说是重点，但是在内部一度成为谁做谁死的状态....这是什么鬼？
- 在集团内部，关系调用复杂，甚至有效的链路调用图关系都很难梳理。
- 某个中间件异常，导致若干业务收到影响，同时发送了大量的报警，如果在这么多报警中甄选有价值的信息？
在这种情况下如何引入统计过程分析来解决故障定位的问题呢？
