前序

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

从算法的角度看智能运维

智能 + 运维

• 异常检测
  • 动态阈值检测：时序算法
  • 日志文本异常检测：文本处理算法
• 根因分析
  • 知识图谱
  • 数据挖掘/神经网络
  • 等等
• 故障自恢
  • 故障影响评估
• 故障预测
  • 条件概率、概率图模型等等

总结

如何结合以上的思路，落地智能运维，后续的文章会讲到。