1. 模块功能
-
异常检测：发现用户可见数据的异常
-
异常响应：采用报警与工单来推进异常模块修复
-
异常修复：受损数据修复
这个流程，和网络安全监控是非常像的。网络基础安全是从运维部门细分出来的，方法的继承自然不奇怪了。 观察运维近些年的发展，能给安全建设带来些启发，比如说：SRE、AIOps、自动化编排、混沌工程、云原生可观测性。
2. 实现方法
2.1 数据采集
-
指标数据采集
-
日志采集
-
数据包采集
-
事件数据采集
-
策略配置采集
2.2 数据计算
-
大数据计算资源获取：如果有得力的数据团队支撑是最好的
-
关键指标数据计算：按不同时间粒度/指标纬度聚合
2.3 异常检测
-
离线异常检测：离线异常检测是个技术深且场景通用的模块，后续会在github上开源算法模块
-
多平台数据横向对比：对比不同的数据源，避免陷入信息茧房
2.4 异常响应
-
紧急告警：对需要立即处理的异常进行告警
-
工单系统：对不需要立即处理的异常事件分发给指定工作人员，并跟踪处理流程
-
运维预案：告警操作手册，故障分析报告，用于知识沉淀
2.5 异常修复
-
缺失数据补全
-
异常数据修正
和明星塌方了，出演视频要换脸，需要一帧帧地修复，是个低频但累人的工作。我总结了有以下几种方法：
-
重算，从原子数据恢复成业务数据，采用和实时计算一样的逻辑，适用于原子数据存在的场景
-
替换，用前一天同一时刻时间的数据覆盖，适用于周期数据
-
构造，按场景构造，如果是攻击趋势，就构造成尖刺状
在早期是一秒一秒数据填的，后来开始用随机数补，用拟合预测的方式补， 像碗儿匠一样想把数据修的像没坏过。
3. 技术点
- SRE
- 《SRE-Google运维解密》
- 《Google系统架构揭秘-构建安全可靠的系统》
- 时间序列分析
- AIOP-KPI监控
4. 失败分析
4.1 数据工程的失败
-
端数据采集的失败：花费了大量时间在做数据的搬运与预处理
-
数据寻址难：存储在不同机器上，但缺少有效的机器资源统一管理
-
数据一致性难：基础数据格式变更快、并无有效通知
-
数据埋点规范未有效推进：数据埋点优先级低，研发忽略
-
-
基础数据计算平台能力未能充分利用
- 大数据计算平台资源限制：申请到的计算资源有限（资源获取能力差）
-
异常检测策略
- 异常检测策略跟不上需求迭代速度
- 对异常的解释不足以支撑问题归因
4.2 异常没那么重要
- 大量未处理的异常事件累积，处理人员麻了
5. 个人收获
5.1 SRE技巧
- 监控技巧：
- 监控指标定义原则：延迟+吞吐量+错误记录 (Weave Cloud的RED方法)
- TICK技术栈
- 告警技巧：准确率低于 50% 报警是不能使用
- 分诊响应：按数据资产重要性、异常量级（异常指标是不是特别大）、异常范围（是不是多个资产有异常）、异常持续时间进行分级响应
5.2 研发技巧
- 使用airflow作为工作流引擎，将数据计算任务编排起来，做到策略自动化编排
- 异常检测技巧：时序趋势异常 RLS filter、prophet
5.3 非技术因素技巧
-
少自己造轮子，充分利用公司提供的基础支撑服务
e.x. 我现在采用低代码应用平台来搭建工单系统/报表系统
- 需求收敛，有多少人做多少事
- 业务异常是否频出和业务团队工程化程度有很大关系，如果没有能力改变基础建设，就聚焦在最关键的模块
- 根因定位的前提是模块错误日志有采集，如果没有，请放弃
- 向优秀的产品化的解决方案学习，但牢记资源有限的情况下需求收敛
- 异常处理需要轮岗，长期看到系统的错误，容易对团队失去信心
- 工作中能接触到重要的东西才是核心
