转向AIOps之前，你应该知道什么？
FreeWheel 创建于 2007 年，总部位于美国硅谷，主要业务是提供互联网视频广告投放、监测、预测、增值等解决方案。经过十多年的发展，FreeWheel 的业务量不断增长，系统架构日趋复杂，公司运维团队面临的挑战也越来越大。FreeWheel 的运维团队经历了从最初的小规模传统运维，到按照职能细分的运维团队组织模式，再到最近几年转换 DevOps 思想，进而到 SRE 的演变，目前正在探索实践 AIOps。作为积极拥抱新技术和新思想的团队，FreeWheel 结合自身的痛点对团队、工具和流程进行持续改进，其转向 AIOps 的例子十分典型，他们踩过的一些坑对想要采用 AIOps 的企业和团队也很有借鉴意义。
1
FreeWheel 运维团队的演进
从公司 2007 年创立到现在，FreeWheel 运维团队的发展大致经历了以下几个阶段：
传统运维。公司成立初期业务量较小，系统的复杂性也不高，各方面挑战都不大。此时运维团队规模很小，各项工作基本都是大家一起完成，包括网络规划、硬件安装、软件部署、监控报警等。日常管理工作通常是通过直接执行命令或编写简单脚本来完成。
运维职责分化。随着 FreeWheel 的业务快速成长，产品线不断扩展，系统模块数量及相互间关联依赖的复杂度随之增加，基础设施也变得越来越庞大，整体运维工作变得非常复杂，运维团队面临的挑战直线上升。在这段时期 FreeWheel 将整个全球运维团队进行细分，包括系统运维、网络运维、数据库运维以及产品运维。产品运维更侧重在产品部署、服务运行等产品环境，跟软件开发人员的沟通交流更为紧密，通常会结合自身的运维经验和需求提出建议，协助设计和搭建监控、报警系统，从而使 FreeWheel 业务产品能够更好、更稳定地运行。这个阶段运维团队的组织结构变得更加清晰，各运维小组的职责变得更加明确。
DevOps。FreeWheel 有一段时间成立了专门的 DevOps 团队，负责建设从代码管理、打包测试、上线部署到配置管理、报警监控的一整套管道流程和工具平台，力争打破开发和运维之间的边界，实现更好、更快的代码上线及服务变更。但在具体实践中，由于该团队所招聘的人员运维经验偏少，对系统上线和监控的理解不够深入，同时和众多的开发团队之间也难以保障充分沟通，导致开发和运维两方面的具体需求都得不到快速有效的响应。这一阶段 FreeWheel 走过了一些弯路，值得反思。
SRE。SRE 的角色定义在 Google 首先建立和推行，FreeWheel 的产品运维组在过去一年中也进行了相关实践，结合自身现实情况，尝试使用工程的思想和手段来审视与改进生产环境的运维工作，并尽可能推动运维自动化。具体工作包括和产品开发团队一起梳理并建立 CD（持续部署）流程和平台，对业务和产品进行实时监控，关注报警以及系统的稳定性、可用性，明确定义 SLO（Service Level Objective），确保对用户承诺的 SLA（Service Level Agreement）。
2
哪些痛点促进团队转向 AIOps
在 FreeWheel 的发展过程中，业务和技术层面的多个痛点促使运维团队尝试从运维智能化的发展趋势中寻求有效的解决方案。例如：
FreeWheel 一个突出的业务模式是在直播赛事中投放广告。近年来公司服务的直播源大幅增加，从用户过来的广告数量包括流量峰值都难以预测，这对广告服务器以及后端的技术平台和架构的可扩展性和稳定性都提出了很高的要求。同时，直播赛事中广告播放的时间点和时长也是不可预测的，出问题的时间可能短至几秒甚至几毫秒，但对客户的即时影响很大，这时要捕捉到问题并及时解决故障的难度非常高。依靠传统的人工操作及简单自动化已难以有效应对上述的运维挑战。
在 FreeWheel 所聚焦的广告领域，另一个极具代表性的痛点来自于欺诈和无效流量（IVT）对数字广告生态系统所构成的重大威胁。所谓“道高一尺，魔高一丈”，IVT 的不断演变使得对应的解决方案不可能简单的一蹴而就，而需要具备持续性和智能化的特点，包括持续收集和分析流量来源、行为方式以及进行特征理解，以更好地解决 IVT 这一威胁。
同时，随着 FreeWheel 业务系统越来越复杂，基础设施各技术层面都出现了不同的挑战。例如监控层面，就出现监控系统多样化，报警条目和数据海量化，但同时报警信息不规范，各类报警邮件的主题和内容都不统一，一个问题经常引发多条报警。在这种情况下，如何在海量的报警消息中甄别有效关键信息，并在报警风暴的压力下快速准确地定位问题解决问题，成为运维团队所面临的巨大挑战。
同样在技术层面，如何对现有基础设施的使用进行有效的优化，以支撑业务的稳定运行，也是运维所面临的难题。比如在网络层面，业务量增大带来流量增多、类型复杂，同时云战略的推行也使得云端资源的访问日趋复杂，网络运维团队需要智能化的手段来有效识别流量，并做出灵活的判断和优化处理，比如给优先级高的流量预留足够的带宽，以支撑各关键类型业务的顺利开展。
随着近年来人工智能技术的快速发展，以及各领域运维数据和经验的积累为智能化运维提供数据基础，AIOps 正成为运维的下一个发展趋势。FreeWheel 希望借助这个趋势解决业务和技术层面所面临的各种挑战，进一步提升运维水平，同时推进运维团队的成长，适应公司业务、技术架构以及整体团队发展的需要。
3
FreeWheel 的 AIOps 平台建设
FreeWheel 的 AIOps 平台目前还在构建过程中，如上文所述在某些领域已经开始了探索性的工作，同时也逐步规划好未来的演进方向。
上文提到，监控层面的挑战是 FreeWheel 探索 AIOps 的重要驱动力之一，也是重点考虑的切入点。由于业务的复杂性和快速演进，FreeWheel 监控系统的报警来源变得非常多样。单就监控系统而言，FreeWheel 使用了流行的 Nagios 和 Zabbix 以及开源的 ELK 技术栈，也使用了在云端应用较多的商业软件 Datadog，以及 Splunk 等产品。下图展示了 FreeWheel 目前监控体系（包括统一报警、事件收集、分析通知平台）的架构图：
左侧的所有监控平台和日志系统都是 FreeWheel 现在的监控数据源，通过公司的邮件系统和 Slack 消息系统进行集成和整合，运维团队（主要是 NOC – Network OperaTIon Center 团队）重点关注这两个渠道的报警信息。NOC 系统内部有数据可以进行训练，会预先设定某些条件，对报警消息的主题或内容做标识，这样 NOC 就能通过识别标识，进而触发图中右侧的 OpsGenie 自动化平台。OpsGenie 提供丰富的接口，能够实现多种自动化流程和动作，例如发送即时消息、短信甚至直接打电话。这样，严重的报警或事件就能第一时间进行通知并及时得到响应。
在该体系中，Splunk 和 ELK 可以在一定程度上做机器学习，基于大量的 Metrics 和日志在内部建立一些数据模型并进行训练，生成规则协助分析并解决问题，但它们并不能覆盖所有的数据源。此外，由于报警来源太多，各种数据格式不规整，在加上监控的频度也不一样，报警有快有慢，一个问题可能引发很多报警，虽然邮件系统和 Slack 对报警消息实施了初步的整合和归集，但如图所示，由于智能化应用程度有限，它们并未能大幅消减报警风暴，并提供有益的关联分析等功能，这样运维人员分析和定位问题的效率并未大幅提升。
为了解决上述问题，FreeWheel 计划对目前的监控体系进行优化，主要是引入 MoogSoft 来替换上图中邮件系统和 Slack 所占据的中心位置，使后两者回归通知渠道的本职功能，而 MoogSoft 将进行：
将监控平台集中化和统一化，规整来自各种数据源的报警信息，使之更利于理解和分析，包括机器学习技术的应用；
汇总、关联报警信息，比如根据时间、区域、主题等维度的相关性对报警信息进行归类和压缩等；
过滤、分析数据进行知识学习，比如根据过往处理的报警事件相关信息，通过机器学习建立模型（包括特定报警事件中报警消息的模式等），以用于识别未来发生的类似报警事件。
经过如上处理，各个数据源关于同一个事件的多个报警通过机器学习的模型分析汇聚成一个报警，避免了报警风暴造成的困扰，使运维人员可以快速准确地定位到问题。OpsGenie 再触发流程及时通知相关技术响应人员，处理报警的效率就会很高。这样优化后的监控体系架构如下图所示：
此外，在分析报警事件的过程中，基于相关性的分析，Moogsoft 不仅可以为运维人员提示与当前事件类似的过往事件，还可以通过时序分析提示当前事件所聚合的成百上千报警信息中可能的根源（root cause）报警信息，以协助加速问题的分析与解决。在处理完某个报警事件后，运维人员还可以将所积累的知识标注和关联到系统中，以支持系统模型的不断提升。
在监控层面，如上文所述，FreeWheel 另一个挑战是期望在直播赛事过程中先于客户发现问题。这就需要能做到实时监控并有效预警。作为上述监控体系的补充和增强，FreeWheel 的监控团队还构建了集中统一、时效性更高的监控平台 PQM，如下图所示：
该平台采样间隔粒度更细，数据库选用专为实时监控设计的时序数据库，也引入了 Kubernetes 原生的 Prometheus 监控平台来采集数据。在报警爆发以后，监控平台可以自动做出响应，同时这套监控系统还会基于非实时流量对业务数据做异常流量的自动检测，再结合上述监控体系智能化技术进行辅助决策，就可以很好地定位问题甚至预防问题。
在监控层面之上，FreeWheel 也探索使用 AIOps 技术协助解决一些业务挑战，比如欺诈和无效流量（IVT）的识别。在机器学习方面，通常需要一个数据集合来训练模型，然后才能对其进行测试，但是建立一个准确的、表示复杂机器人流量的数据集几乎是不可能的，也是非常昂贵的。但广告决策平台的特殊定位，使得 FreeWheel 有机会解决数字广告生态系统中无效流量的问题。具体而言，应用机器学习理解最终用户的行为，形成模式构建模版，之后用聚类算法来模拟流量行为，这样可以识别突发流量，对流量进行有效的评估，更好地检测欺诈行为。FreeWheel 已开始进行初步的探索，结合广告服务器的事务日志数据进行分析，帮助做出有关 IVT 检测和删除的有效决策。
在监控层面之下的基础设施，FreeWheel 也探索使用 AIOps 技术来优化相关的运维工作。比如针对网络基础架构所面临的挑战，FreeWheel 在积极的实施 SD-WAN 技术解决方案，该技术允许针对数据中心间流量的数据包进行动态重新路由，其中的核心技术 First-Packet iQ 可以根据某个应用的首个数据包进行应用识别，使其远优于目前典型的数据包检测以及端口检测方法。这种智能化的技术有助于我们更快地识别恶意流量，减少被攻击的可能性，并优化基础设施的使用效率，更好的保障关键业务的运行，也减轻了基础设施运维的压力和风险。
总体而言，在逐渐探索采用 AIOps 技术之后，FreeWheel 团队能明显感觉到报警繁多的痛点得到了极大的缓解，一些智能决策的支持也让团队的效率明显提升，尤其能帮助运维团队快速有效地定位、识别、解决问题，降低 MTTR。对于 FreeWheel 这样业务分布在全球的公司来说，AIOps 平台和工作流程的优化能切实解决很多问题，具备很好的应用前景。
4
如何看待 DevOps，SRE 和 AIOps
FreeWheel 的运维团队经历过 DevOps， SRE 和 AIOps 的各个发展阶段，转型过程中也才踩过一些坑，对这几种运维实践有比较深的体会。
总体而言，DevOps 是一种思想的转变和进化，涉及到撰写代码、测试、发布、上线各个环节，以及相应技术手段的推进和落地，目的是打通开发和运维之间的边界，更关注从开发到生产之间的流程如何快速迭代，从而达到缩短周期并提高产品质量的目的。
SRE 更关注运维阶段，强调用工程的思想和手段来看待和解决运维问题，包括监控、报警、容量评估、系统扩展等，以及如何早期介入产品研发的架构决策，以更好地保障在线产品 SLA 的目标达成。
AIOps 则贯彻整个运维领域，从硬件资源规划、管理、实施，操作系统安装配置，到中间件及应用软件的上线、变更，以及后续的监控、报警、维护、优化等各方面都需要关注。基于海量的信息源以及大数据分析技术，结合大量运维专家的丰富经验及人工智能算法，在各个领域、各个阶段以更自动化、更智能化的方式推动运维工作的变革。
5
关于 AIOps 实践的建议
AIOps 的概念归根结底是对运维规则的智能化发现与实施，即将人工经验总结的过程变为自动学习及输出实施的过程，其目标是利用大数据、人工智能及周边技术实现对运维效率、质量、成本等方面的优化和提升。
AIOps 是运维领域发展的必然方向，凡是具有上述需求的企业，包括互联网企业以及数字化转型中的生产制造企业等，都可以考虑尝试 AIOps。FreeWheel 运维团队向 AIOps 演进是源自于自身的需求，实践过程中虽然踩过不少坑，但也确实解决了很多问题。对于决心实践 AIOps 的团队或企业，FreeWheel 基于自己切身的经历给出了一些建议：
标准化是基础。比如报警的标准化和规范化，就是 AIOps 的重要基础，否则后续的工作代价就很大。最好能有架构师团队从架构决策层面整体把控技术平台的选型、走向以及相关的标准规范，并通过强有力的治理（Governance）来统一协调，推进项目，做好平衡。
技术选型很关键。实施 AIOps，既可以选用相对成熟的商业化工具，也可以考虑自主研发，关键是结合企业自身的业务特点和能力，注意投入产出比和时效性。
找准切入点。如 FreeWheel 选择监控体系层面切入，因为数据最丰富、痛点最突出、价值最彰显。同时 FreeWheel 也选择在业务层面、基础设施层面的一些点状问题（如 IVT、SD-WAN）上探索实践。这些切入点的选择需要结合企业的特定情况，争取达成好的示范效应，同时培养团队，夯实技术支撑体系，为后续的进一步推广应用打下基础。
人员从业经验很重要。在团队方面，人员的素质和经历很重要，只有在实践中切实踩过坑，解决过实际问题，才能对技术、流程、进度有深入理解和切身体会。
希望正在看文章的你也能从 FreeWheel 的经历中吸取经验，结合自己的实际情况将运维工作做得更好。