前序

本人从事了 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工具
    - 快速部署到生产环境
    - 开发，运维协同合作
  - 持续交付
    - 频繁发布，快速交付，快速反馈，降低发布风险
  - 容器化
    - 微服务的最佳载体