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 提供丰富的接口，能够实现多种自动化流程和动作，例如发送即时消息、短信甚至直接打电话。这样，严重的报警或事件就能第一时间进行通知并及时得到响应。 郑州妇科医院:http://yyk.39.net/zz3/zonghe/1d426.html/郑州哪家医院看妇科好:http://yyk.39.net/zz3/zonghe/1d426.html/郑州无痛人流多少钱:http://yyk.39.net/zz3/zonghe/1d426.html/郑州同济妇科医院:http://yyk.39.net/zz3/zonghe/1d426.html/