智能运维（AIOps）系列之一：个人对智能运维的理解

前序
本人从事了 5年 的智能运维开发，把这几年的想法和思路在此跟大家分享一下，主要是为了起到抛砖引玉的作用。该序列总共5部分：

智能运维系列之一 — 概述：主要是讲述自己对智能运维的理解；
智能运维系列之二 — 什么是人工智能
智能运维系列之三 — 什么是智能运维
智能运维系列之四 — 智能运维落地的思路：讲述的是这几年在开发智能运维的过程中挫折和思考；
智能运维系列之五 — 总结
个人认知过程
至从2016年，开始从事智能监控开发之后，就跟智能运维搭上了不解之缘。

2016/2017年：刚开始做监控的时候，研究了几乎市面上所有监控产品，和相关的技术文章、视频。这个时候，主要是接触了大数据相关的技术，包括：Kafka、Spark、HiTSDB、ELK等。
《大数据日知录》：分布式系统相关的理论、以及大数据相关的技术；
《从零开始学习架构》：阿里的一位大神写的，关于 分布式系统架构 的一整套方法论；
2018年：随着监控的逐步完善。开始考虑结合数据挖掘相关技术，产生新的业务价值。刚开始学习人工智能的是有，由两本书对我影响比较大：
《智能系统指南》：较为全面的介绍了人工智能各个分支的技术；
《人工智能 — 一种现代的方法》：是加州大学伯克利分校的教授 和 Google 研究院主管 合著的一本书。这本书理论性很强，个人认为几乎囊括了人工智能各个分支的相关算法。
2019年：进入了千寻的运维保障部门，接触到了更为庞大的业务。对智能运维有了进一步的理解。同时跟公司数据平台的同事有了交流，对数据仓库在智能运维的应用，有了初步的想法，并且开始尝试实践。
运维
《Google SRE运维解密》：google 关于高可用保障的一本数据；
赵成的运维体系管理课（极客时间）：关于运维的经验分享
《AIOps标准白皮书》：较为全面的介绍了智能运维。
人工智能
智能运维前沿（微信公众号）：了解智能运维在业内的前沿技术；
数据方向
《数据仓库工具箱 — 维度建模权威指南》：数仓建设的完整的方法论，以及样例解释
2020年：开始基于特定的业务，搭建智能运维的解决方案。对完整的智能运维解决方案，开始有了自己独特的理解；
总结一下自己的认知过程

从不同的角度看智能运维，以质量保障为例
个人认为，智能运维是一套复杂的人工智能的解决方案。智能运维的落地，需要集思广益，从多个角度去思考，才能够少走弯路。

从业务的角度看智能运维
首先，智能运维是建立在运维的基础之上的，只有了解了现有的运维的内容和技术体系，我们才能够合理的思考，智能运维在整个运维体系中的地位和作用。

运维的职责
持续交付体系建设
配置管理：版本控制
环境管理：开发环境、集成测试环境、预生产环境、生产环境等；
发布变更
构建与持续构建
稳定性体系建设
应急响应
安全生产：制定故障定级定责的标准，故障定级、故障定责、故障追责、故障应急、故障复盘
混沌工程：
技术运营
监控管理
事件管理
成本管理
SLA平台
用户体验管理
运维技术体系（运营一体化平台）
SLA体系
SLI，服务质量指标，服务的某项质量的一个具体的量化指标；
SLO，服务质量目标，服务的某项SLI的具体目标值，或者目标范围；
SLA，服务质量协议，描述在服务不达SLO情况下的后果；
基础组件
CMDB：是面向资源的管理，是运维的基石
敏感资源
发布变更系统
功能模块
整体
用户体验分析平台：用于分析运营一体化平台的用户访问量，指导该平台的产品设计和迭代
质量保障
监控系统
故障管理系统
故障自恢
故障演练平台
SLA 平台
成本优化
运维资产管理
成本分析和优化
效率提升
各类自动化系统
智能运维如何在运维中起到作用（以质量保证为例）
目标：

1分钟发现问题 – 5分钟定位问题 – 10分钟故障恢复；
故障预测
故障影响评估
发布变更影响评估
从产品的角度看智能运维
目标群体
智能运维的使用方，是一群有着丰富经验的运维专家，但是可能对数据分析、数据挖掘没有任何概念
通过跟运维的兄弟们沟通，我发现他们对智能运维抱着两种极端的看法：

希望算法能够准确地告诉他们出了什么问题；
不相信算法给出的结论；
算法只能保证一定的准确率，但是无法保证100%的准确定。

解决思路
个人认为，刚开始做智能运维的时候，不应该直接做数据分析，而是先把相关数据产品做起来。

第一步（数据产品）：针对特定场景，先收集相关联的数据，以及做好数据展示。以此提高运维解决问题的效率，同时积累相关的业务经验（可落地）；
第二步（数据分析）：基于第一步完成的数据产品，可以提供数据分析的结论作为参考。同时提供用户（运维）反馈分析结果是否准确的评估；
第三步：形成研发和用户的互动机制；
从数据的角度看智能运维
什么是数据工程
数据工程包括了：

数据采集
数据清洗
数据建模（数据仓库/知识图谱）：数据仓库的作用，主要有三点
解决数据关联问题，避免数据孤岛；
共享数据逻辑：频繁使用的计算逻辑，可以作为公共的属性放在核心维度表里面；
隔离数据源的变化；
数据展示
为什么需要数据工程
运维，天然就是大数据。很多公司，最大的数据就是来源于运维部门；
运维的数据类型包括了：

基础的硬件信息、应用的信息；
中间件的信息；
监控数据
告警数据
等等
运维的业务场景包括了：

应用部署；
监控
排障；
容量规划；
等等
海量的数据，以及丰富的业务场景。使得建立数据仓库具有天然的可行性和必要性。
同时数据仓库的数据，也能够为数据分析和数据挖掘提供底层的数据支撑；

从工程的角度看智能运维
系统开发
整个智能运维解决方案，把运维几乎所有的业务系统都囊括进来：

基础组件
CMDB
应用配置管理
支撑系统
监控系统
故障预案
混沌工程：可以验证 故障检测、故障分析、故障恢复等的有效性，同时也可以为 智能运维 提供数据样本；
故障管理平台
等等
数据分析
动态阈值检测服务：涵盖了 算法模型、样本管理、算法评估等；
日志文本检测服务
根因分析服务
故障影响评估服务
等等
平台化建设思路（建议采用云原生技术）
云原生技术
理论
第一个理论基础是：不可变基础设施。这一点目前是通过容器镜像来实现的，其含义就是应用的基础设施应该是不可变的，是一个自包含、自描述可以完全在不同环境中迁移的东西
第二个理论基础就是：云应用编排理论。当前的实现方式就是 Google 所提出来的“容器设计模式”，这也是本系列课程中的 Kubernetes 部分所需主要讲解的内容。
组成要素
微服务
应用间通过 Restful API通讯
可以被独立的部署，更新，扩缩容和重启
DevOps
自动化发布管道，CI工具
快速部署到生产环境
开发，运维协同合作
持续交付
频繁发布，快速交付，快速反馈，降低发布风险
容器化
微服务的最佳载体
从算法的角度看智能运维
智能 + 运维
异常检测
动态阈值检测：时序算法
日志文本异常检测：文本处理算法
根因分析
知识图谱
数据挖掘/神经网络
等等
故障自恢
故障影响评估
故障预测
条件概率、概率图模型等等
总结
如何结合以上的思路，落地智能运维，后续的文章会讲到。