本文首先提出一个必要且可行的“路线图”，然后详细阐述在 AIOps 实施过程中可采用的具体步骤，以构建出一套 AIOps 的最佳实践。
我在与客户交流 AIOps 的时候，他们时常觉得 AIOps 不够成熟，以至于无法实施各种分析。
也有人认为：AIOps 的各项能力是线性发展的，他们必须事先评估和补足当前在“处理大量的事件和警报，以及统一化分散监控”方面的能力成熟度，才能考虑切入 AIOps。
我非常理解他们的关注点，毕竟数十年来，分析师和供应商灌输了僵化的 ITIL 思想和严格的流程，使大家都不愿为那些长期存在的问题，找到替代的解决方案。
诚然，AIOps 并未直接受到 ITIL 的约束，并能够被分步骤地予以实施和改进，但是业界至今仍缺乏实际的行动指导。
本文通过早、中、后期九个步骤来给出 AIOps 所必要的最佳实践。
AIOps的快速回顾
Gartner 判断的 IT 新兴市场趋势为：传统的 IT 流程与工具已不再适合处理那些由现代数字业务所带来的挑战。这不但与数据的传输速度、种类、以及体量有关，还与从线下的历史分析转为线上的实时分析有关。
Gartner 对于这种趋势所给出的答案是：AIOps。它整合了 IT 服务管理（ITSM）、IT 运营管理（ITOM）和数据层面上的 IT 自动化。
AIOps 使得数据能够驻留在支持实时应用分析和深度历史查询的大数据平台之中。这些分析可以由那些支持对数据流进行无人值守式处理的机器学习来实现。
因此 AIOps 的基本思想是：传统的 IT 工具仍然发挥效用，例如服务管理仍然处理各种请求和事件；而性能管理仍然监视各种指标、事件和日志。
但是它们的数据被关联、并通过机器学习的分析,从而实现更好、更快的决策和任务过程的自动化。
最终状态
AIOps 的最终状态是：要保证数据能够顺畅地从多个数据源流入一个大的数据平台中。
该平台能够对来自其他来源和类型的数据予以吸收、分析和后期处理；通过机器学习来管理和修改分析算法。
它能够自动触发工作流，其输出结果会作为二次数据源被再次反馈到系统之中，使得系统实现自适应，并且通过响应各种数据卷、数据类型和数据源的变化，进而自动调整和按需通知相应的管理员。
基于上述概念，我将首先提出一个必要且可行的“路线图”，然后详细阐述在 AIOps 实施过程中可采用的具体步骤，以构建出一套 AIOps 的最佳实践。
该 AIOps 路线图共分为 9 步，他们分别是：
识别当前用例
就系统记录达成一致
确定成功的标准、并着手跟踪它们
评估当前和未来状态的数据模型
分析现有工作流
开始自动化实施
开发新的分析工作流
使组织适应新的技能集
定制各种分析技术
早期阶段
识别当前用例
鉴于各种变数情况，您最好先从自己所熟悉的方面开始。对于大多数用户来说，他们当前的各种用例方案无法应对那些新技术的发展。因此，您可以列举出自己当前正在处理、或准备解决的用例列表。
如下给出的切入点可方便您发现当前的“目标”状态：
列出如何实现各种预期的结果
评估特定用例的优先级
突出当前能力、工具、技能或过程中与目标所存在的差距
同时，这也是制定一个成功 AIOps 战略的良好开端。通过强调这种“开启”方式，我们会发现许多新的用例。
各种新的预期结果也会涌现出来，而它们的优先级将随着您的业务和技术的变化而相应地调整。可见新的 AIOps 方法会给我们带来各种新的可能性与挑战。
所以说，重要的是要在一开始就能找到从当前您所处的位置前往目标的桥梁。只有找到了您面临的问题和需要改变的地方，才能选择正确的道路去实现，反之则注定失败。
评估数据的自由度
AIOps 的首要基本元素是：来自不同工具的数据流能够自由地汇聚到大数据存储区中。
因此，您必须评估自己IT系统中获取到的各类数据的易用性和频率。我们理想的最优模型为：实时地发送数据流。
然而，目前很少有 IT 监控或服务台（service desk）工具能够支持向外流出数据。当然，它们迭代出的最新版本应该能以 REST API 方式提供编程上的交互与支持。
但是，如果使用的是基于诸如 Oracle 或 SQL 之类的传统关系数据库，由于它们在最初设计时并非为了支持数据的连续流出，那么即使具有可编程接口，也会对生产系统的性能产生巨大的影响，因此，我们可以断言它们并不能支持数据流。
可见，在制定 AIOps 策略的早期，重要的步骤之一就是要明确自己系统对于数据流的支持能力，并为如下问题给出相应的答案：
我如何能从当前的 IT 工具中获取数据？
我能得到什么样的数据？
我能够通过编程的方式来实现吗？
我获取这些数据的频率是怎样的？
通过发现这些约束条件，您可以考虑去更改当前的数据整合策略（例如，将批处理上传模式转化为流式），甚至考虑将现有的IT工具替换为那些支持实时数据流的软件。
就系统记录达成一致
AIOps 的第二个基本要素是：组织的协同和沟通。我建议 IT 运营和 IT 服务管理人员协作审查各种数据的需求，同时就各自的角色和责任达成共识。在此，我们主要着眼于基于共享数据上的协同决策。
这里所说的数据并不是那些已经流入 AIOps 大数据存储区，以待分析的数据。而是 IT 人员可以从自己环境中获悉的、用于采取行动和做出决断、并最终能够跟踪效果的那些数据。因此，整个团队需要针对数据达成如下共识：
为了突破系统当前限制所需要的最小数据集
数据所在的位置
团队所能共享的联合视图与访问权限
根据传统的 ITIL 模型，在许多成熟的组织中，满足上述条件的系统是他们的服务台。各种服务请求、事件和变更性的数据都被存放于此。
但是当 DevOps 团队开始使用 Jira（译者注：一种项目与事务跟踪的工具），来记录缺陷和功能性的改进时，该模型会受到了一定的挑战。
因为在使用 APM（译者注：一种监控和管理应用软件性能和可用性的工具）时，IT 运营与安全团队是无法通过各种本地或远程事件，来捕获或识别多种威胁的。
因此准备实施 AIOps 就意味着：您需要在应用程序、服务或业务的价值链中确定所有有效的结果性指标，并制定出一个方案来汇集这些数据。
您可以在大数据平台上构建各种“仪表板”，来筛选出具有特定用途的大数据集，即：对不同数据源产生不同的视图。
当然，您可以从“在当前环境中选择数据子集，并将其反馈（如 Jira 工单和 APM 事件等）到已建成的记录系统中”开始。
制定成功标准并开始跟踪它们
任何成功的业务与 IT 管理都起源于了解各种关键性能指标（KPI）和度量标准。因此，具有可操作性的方面包括：
了解对哪些方面进行测量
实现一致且完备的措施
定期报告或提供性能衡量的可视化
能够对责任方问责
一般大多数 IT 工具都自带有几种衡量工具和模板，它们往往能够为您提供各种参数。而我们都知道：数量是无法真正反映背后因果关系的。
如果我们只是简单地将它们放到报表上的话，并不能给企业带来业务上的提升。
中期阶段
评估当前和未来状态下的数据模型
数据模型评估是一个关键方面，但很少有人真正理解或愿意这么做。本质上说，您必须为即将上马的 AIOps 方案厘清各个数据源的数据模型，以保证这些模型能够被 AIOps 的用例所识别，进而评估出不同模型间的直接交互和预期结果。
我们之所以说它具有一定的挑战性，是因为大多数 IT 工具的数据模型对于用户都是不可见的。
很少有组织、甚至包括一些数据分析人员或专家，能真正知道大数据平台（使用的是 NoSQL）与传统数据库（使用的是 SQL）的不同之处。
AIOps 实际上是在一个大数据存储库中关联了来自不同 IT（和非 IT）源的数据，使得它们能够互联互通，从而实现分析和趋势判断。
AIOps 系统可以处理许多种共享的数据结构（如下所示），而不需要额外地进行二次开发或改进：
时间戳： 各种事件、日志和度量中带有时间点特征的数据，可以被聚集在一起用于关联事件，并按照时序进行因果分析。
属性： 某个事件、日志或度量所关联的信息键值对（key:value）, 如“状态”、“源”、“提交者”等，可用于在不同数据集之间创建关系模型。
历史性：时间序列或事件活动的过往数据，可用来预测将来的表现或门限值，如饱和度（saturation）和退化度（degradation）。
效应：一天、一周、一个月等时序数据所呈现的趋势或规律性，可用于关联多个数据集、或预测可伸缩性的资源需求。
应用程序、服务和业务模型：如果您能够定期进行发现与配置管理上的实践，就可以用它们来通知 AIOps 平台各种资产的分组、关联、依存关系、以及做到数据的去重。
总之，通过构建良好的时序数据，AIOps 能够运用各种运营监控与管理工具来关联、分析和预测各种时序数据，进而实现：
将 IT 和非 IT 类数据相集合，例如：用户数量+性能表现、延迟时间+转换率；
并能增加数据的“粒度”，例如：从 5 分钟的频率上到 1 分钟；
对数据流进行应用级的分析，例如：做到“实时”或对特定历史时间段的查询。
人工捕获的事件往往是非结构化的；而大多数设备获取的 IT 事件 blob（译者注：binary large object，二进制大对象）也只能达到半结构化。
它们都存在着：格式不一致、不够完整、大量重复等特点。因此，AIOps 应当对这些 IT 事件属性提供范式转换，为进一步分析做好准备。
如今，许多 AIOps 都能聚焦事件的管理、分析和关联。一旦数据流入 AIOps 平台，我们就必须考虑其数据结构和完整性是否支持机器分析。
常用的一种方法是：对传入的数据执行“ETL”（Extract 提取、Transform 转换、Load 加载），也就是在数据流中进行规范化和集中式转换，以便实现对数据的关联和分析。
当然，在采用 AIOps 方案之前，企业可能会面临两方面的压力：
大量有待转换、处理和分析的数据可能会使得当前的系统无法实现实时性、或升级成本高昂。
需要人工去管理和维护各种数据的结构与标准，否则系统只能对已知模型进行处理，而无法适用于新的数据类型。
另外，大多数云服务系统也会使用“标签”策略作为最佳实践。它们通过对不同类型对象的属性变量进行哈希，然后独立于对象本身，仅使用标签来进行引用、排序、关联和分析。
不同于那些带有固定公共值的预定义映射关系，标签是能够跟随数据一同变化的。
NoSQL 数据库和诸如 Elasticsearch 之类的大规模分析工具，能够通过标签来处理各种属性关系。
此外，系统还能在数据流入时就实时地打上标签，以避免任何具有未知特性的“盲数据”产生。
可见，企业需要通过具有 ETL 或标签能力的 AIOps 大数据平台，来实现对数据模型的实时评估与管控。
分析现有工作流
至此，我想您对 AIOps 方案的分析已经准备就绪了。此处的分析并非来自于 IT 工具，而是您定期或不定期进行的，旨在改进流程、降低成本和提高性能的离线式手动分析。
您可以通过手动分析 AIOps 方案，以不断迭代的方式解决自动化过程中出现的问题，进而减少花费在分析上的手动工作量，并提高分析的频率和范围。
可见，AIOps 的目的就是：减少您在手动上花费的时间和精力，通过提高速度与频率，以实现对数据集的自动化实时分析。
开始实施自动化
诚然，每个人都知道自动化的价值，但是不同团队对此有着不同的理解。随着 DevOps 所带来的持续集成与交付（CI/CD），IT 运营的自动化道路也发生了相应的影响。
IT 运营（IT Ops）：着眼于自动化任务和协调各项步骤。其中包括：实现服务台的工作自动化、自动给服务器打补丁、通过监控工具来自动修正系统错误。难点在于横跨各种工具间的步骤配合与相互联动。
DevOps：着眼于自动化自己的开发任务和业务流程，以消除瀑布式开发所带来的分段式审查过程、隔离式测试、行为合规、以及运营与上线联动等所造成的瓶颈与滞后。
可见，DevOps 的应用团队旨在通过开创新的服务（如云端应用），加快集成与交付的速度与频率。
而IT运营团队，则需要“自动化所有”，他们需要协调的不只是 CI/CD，而是整个“链条”。
如果他们不知道服务何时从测试转移到了生产环境，不知道谁手中的源代码会对产生环境造成何种影响，不知道如何识别与度量业务开发人员积压的工作，那么就无法真正有效地去管理好自己的自动化环境。
因此，IT 运营需要跟上 DevOps 团队的速度和敏捷性，综合运用工具来发现信息、共享信息，并通过与 DevOps 的沟通来“刷出自己的存在感”。
后期阶段
开发新的分析工作流
通过中期阶段对于现有工作流的分析，您应当能够自动化并扩展了自己的 AIOps 方案，同时实现了如下方面：
评估现有工作流的价值
修改和改进现有工作流
基于现有差距开发新的工作流
一旦在 AIOps 平台中实现了对现有流程的自动化，我们就可以进一步评估：正在分析的信息是否真正有用？其趋势判断的结果是否可行？以及如需更改的影响会有多大？
我们可以利用现有工作流的分析结果形成“正反馈”，从而开发出新的分析工作流。
使组织适应新的技能集
在角色上，IT 运营人员将从一般“从业者”转换为“审计者”。他们应当跳出固守了十多年的对于设备完全掌控的观念，将目光投到业务数据的分析上。
虽然不需要具有数据科学方面深度的机器分析水平，但是他们确实需要了解系统是如何处理数据、以及是否能够实现业务的目标。这也是 AIOps 将给 IT 运营人员带来的最大变化。
纵然整个市场目前尚未完全成熟，但是各个企业仍值得去培养具有 AIOps 能力的人才。假以时日，他们必将为组织带来结构化的科学转变，并让组织从中受益。
定制各种分析技术
最后在运用 AIOps 进行 IT 运营方面，组织还需要开发出一些数据科学方面的实践。通过数据科学家、开发者与分析师的协作，他们会开发出能在大数据集上运行的算法，并在代码上使用 Python 或 R 语言来实现各种数据科学的模型。
当然，IT 运营人员不必了解过多有关数学和编程方面的知识，他们只需要能够管理一个具有半智能、半自治能力的系统架构。
他们应当能够根据 AIOps 供应商所提供的多个备选分析系统，选择最适合于自己环境的组合。
在日常运营中，AIOps 平台也将能够提供实时的、定制的回归分析，以辅助做出各种决策。
本文来自：http://developer.51cto.com/art/201808/580245.htm
