当前位置: www.89677.com > 互联网 > 正文

关于智能运维AIOps的一点思考,宜信正式开源其

时间:2019-11-03 09:02来源:互联网
作者:Vladimir Fedak返回搜狐,查看更多 去哪儿网基于Kubernetes/Ceph的机器学习云实践 第二位演讲者是有丰富云平台建设、运维、容器云落地等经验的叶璐老师,演讲的主题是去哪儿网基于

作者:Vladimir Fedak返回搜狐,查看更多

去哪儿网基于Kubernetes/Ceph的机器学习云实践

第二位演讲者是有丰富云平台建设、运维、容器云落地等经验的叶璐老师,演讲的主题是去哪儿网基于Kubernetes/Ceph的机器学习云实践。

图片 1

叶璐老师以深度学习的兴起为演讲开端,这要涉及深度学习的概念、兴起的原因、深度学习加速器-GPU等方面的内容。紧接着分享了深度学习在Qunar的应用,像智能客服,拿去花用户信用评级,酒店推荐等都是经典实践。

演讲最核心的部分是如何应对GPU使用资源的一系列问题,如环境无隔离、采购周期长、 资源利用率低、各种工具的环境部署成本高等。

图片 2

针对这些问题,去哪网采用的方式是构建GPU云,第一期的目标是GPU资源云化, 持业务线同学快捷定制机器学习应用,秒建秒删,一键释放GPU资源,建立统GPU 资源申请和管理等入口到Portal,降低业务线同学的接入和学习成本。做到环境隔离同时保证训练数据在分布式环境下的持久化和可靠性,以及支持Tensorflow全工具链。

如下图,是机器学习应用的一种部署情况

图片 3

叶璐表示,目前一期已经完成正在公测中,使用前后对比,在环境秒起秒删、环境隔离给开发同学提供极大的便利。在对接Ceph后,数据的可用性和可靠性大大提升,不用担心因为更换机器带来的训练数据迁移,丢失。

图片 4

GPU云基础环境固化,让开发同学免受环境安装之苦是第一步。现在Spectrum第二期也在开发中,开发工程师随时固化到Kubernetes Post-Install,提供了更高的环境定制自由度;同时Tensorflow serving的上线,为机器学习应用真正落地提供了更完整的pipeline,同时还有其他的优化,上下游的数据获取管道,预处理流程优化,Jupyter插件系统集成。

真理都是简洁的,但发现真理的过程往往是且复杂且曲折,这也是AI的魅力所在,我们相信,在学术界和工业界的共同努力下,AIOps终将展现出真理的一面。

感知源端 schema 变更,数据实时脱敏

部署AIOps解决方案可以实现以下的积极成果:

用基础设施即代码自动化架构迁移

最后一位演讲人是专注于 DevOps、持续交付,微服务以及全功能产品团队的设计、实践、落地以及经验推广的顾宇老师。他的演讲主题是用基础设施即代码自动化架构迁移。

图片 5

演讲由一个真实的架构迁移案例展开,分享了在一个东南亚互联网企业并购案例中的 DevOps 的实施案例。通过在 AWS上使用 Ansible 和 CloudFormation作为基础设施即代码的工具实现产品架构的迁移。

在互联网企业的并购过程中,不光是组织结构的融合,更是产品架构和产品团队的融合。然而在不同的企业文化、技术能力甚至是不同的国家法律法规上的融合更多的是看不到的隐形成本。

通过 DevOps 的基础设施即代码实践,把架构以及开发/运维实践固化为配置和代码。让所有的团队和成员能够依照同样的规则进行开发和运维。通过自动化的手段加速团队和产品和架构的融合过程,提升整个组织的技术水平。

首先,根据康威定理,组织和架构和基础设施架构要保持一致,就可以根据未来的组织结构设计系统架构,可以减少系统架构演进中的适应性浪费。

其次,把整个架构分层次封装:基础设施、应用和数据 三种类型分别进行封装:

  1. 基础设施通过配置管理技术封装在 Ansible 的 Playbook里,把 Ansible 作为 Cloudformation的引擎。
  2. 应用通过 Docker 镜像进行封装,根据不同的地区在构建过程中进行合并。
  3. 数据通过自动化的备份脚本和自动化的迁移脚本(Migration Scripts)实时保证可用性。

然后,根据使用场景,设计基础设施即代码的架构。能够自动的把整个架构自动的搭建和还原。根据使用场景设计安全策略,避免人为操作,减少人为故障。

顾宇老师表示,基础设计即代码和基础设施是类和对象的关系。根据不同的场景,可以采用面向对象原则进行逻辑分层。隔离不同场景的关注点。例如:持续交付关注Docker 镜像的部署和变更,应用维护关注日志的查询和操作。

最后在该案例中,顾宇老师总结了利用基础设施即代码技术的几个关键要点:

  • 架构迁移要为组织结构迁移服务
  • 把自动化和基础设施即代码当做制度使用(康威定理和逆定理)
  • 把基础设施即代码当做一个产品开发
  • 安全的架构和架构的安全
  • 基础设施逻辑分层基础设施即代码本质上是一套类库,从面向对象的原则考虑基础设施的设计。
  • 构建每日可用架构

图片 6

活动结束时,现场很多开发者还意犹未尽,围着诸位老师就自动化运维的部署、迁移等方面问题,进行探讨交流。

随智能化在各个应用领域的落地及实践,IT运维也将迎来一个智能化运维的新时代。让我们共同见微知著、未雨绸缪,当机器能越来越智能地工作,我们也要变得越来越聪明。

51CTO Tech Neo技术沙龙是51CTO在2016年开始定期组织的IT技术人员线下交流活动,目前仅限北京地区,周期为每月1次,每期关注一个话题,范围涉及大数据、云计算、机器学习、物联网等多个技术领域。

一、安全生产

数据总线 DBus 正是解决这三个问题的良方。

不间断的产品可用性,带来积极的终端用户体验 优先解决问题,而不是永久性的灭火 消除数据孤岛并实现根本性的故障修复,因为您分析了业务生成的所有数据而不是使用精简样本 日常任务的自动化,使您的IT部门能够集中精力于改进基础架构和流程,而不是处理重复且耗时的任务 更好的协作,因为对日志的深入分析有助于显示管理决策的影响,并评估采用的业务战略的效率

自动化运维与 DevOps”沙龙现场

AIOps算法:做异常处理时,主要是概率分布和聚类,分类比较少,因为GT少。做预测时,可以是多维的线性回归模型,线性回归简单,但鲁棒性差;也可以是基于深度学习的非线性模型,一则对数据要求高,二则需要监督学习;还可以是传统的贝叶斯模型,但预测效果一般。

官方网站:

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

今天, 由51CTO 主办的第十六期以“Tech Neo”为主题的技术沙龙活动如期举行,此次沙龙邀请了来自陌陌科技SRE团队负责人王景学、去哪儿网DevOps工程师叶璐和ThoughtWorks高级咨询师顾宇。希望讲师们这些基于平台、建站、深度学习等不同方式的自动化运维实践经验,多少可以为运维/开发人员带来一些的新思路。

监管要求的安稳态是把双刃剑,一方面确保了业务的安全稳定运行,另一方面却阻碍了技术创新。以金融行业为例,强调严管控,严格遵守ITIL标准流程(发布管理、配置管理、变更管理、问题管理、事件管理),追求安稳态。然而,技术创新,无论是云计算、还是DevOps、还是AIOps,都在追求敏捷态,这往往挑战了监管要求。在监管面前,一切违反监管要求的做法都是一票否决。我们可以在现有的监管框架内寻求折中,例如,在严格遵守ITIL的严管控流程的同时,把人工流程全部优化为自动化流程,但这会偏离技术创新的原有初衷。解铃还须系铃人,监管需要为技术创新改变。

图片 7

关于什么是AIOps以及为什么它很重要的最终想法

3.1 AIOps定义:AIOps是指基于已有的运维数据(访问关系、监控告警、日志),采用数据分析和机器学习方法,提高运维决策能力,解决自动化运维无法解决的问题,进一步提高运维效率。AIOps的价值不仅在于提供智能运维决策,也在于实施过程中,对已有的基础架构、应用关系、监控告警、日志数据等进行梳理,实现真正的精细化运维。当然,AI算法的局限性、场景的多样性、数据的复杂性,决定了AIOps是人力密集性、过程的曲折性,也决定了AIOps不能解决全部问题,需要人机协同和知识图谱,才能发挥AIOps最大价值。

之所以这样考虑的原因:

使用AIOps的好处

图片 8

3.4算法为尊:

Wormhole 是一个 SPAAS(Stream Processing as a Service)平台解决方案。Wormhole 面向大数据项目的开发,运维以及管理人员,致力于简化和统一开发管理流程。当今运维是典型的大数据应用领域,Wormhole 是智能运维机器学习的有力支撑,尤其是针对流式实时和流式准实时数据处理场景。同时,提供了可视化的操作界面,极简的配置流程,基于 SQL 的业务开发方式,并屏蔽了大数据处理底层技术细节,极大的降低了开发管理门槛。Wormhole 的设计理念是统一流式处理 DAG 高阶分形抽象,统一通用流转消息 UMS 协议抽象,统一通用流转消息 UMS 协议抽象。

下面是在IT部门中适合使用AIOps的一些案例:

陌陌在k8s容器方面的实践

首位演讲的是王景学老师,主要分享陌陌在k8s容器方面的实践和应用迁移方面的一些经验。当时陌陌选用k8s进行实践的主要原因是,应用发布时间过长、紧急扩容吃力,效率低且应用运行环境软件版本不一致,配置复杂,维护成本比较高,硬件资源利用率不高,总体成本比较高。

图片 9

k8s方面的设计目标有五点,分别是:提高服务的可用性,可管理性、使用k8s来管理docker集群、开发不需要关心服务器、提高资源隔离性,实现服务混合部署,应用级别基础资源监控,服务平滑迁移等。针对这些问题和目标,通过自研发布系统,基于docker和k8s的容器管理平台,便于开发者便捷地部署自己的应用程序。

如下图,是K8s架构

图片 10

针对K8s架构,王景学老师还分享了基于location和group标签的集群调度、基于ovs的网络节点架构和实现、集群在阿里云扩展和支持,测试环境中有状态应用的尝试、容器基础资源监控方面的指标等,还有在应用迁移过程中,遇到了Swap、cpu软中断及资源利用率,应用白名单等问题。

于未来,希望可以实现对应用请求量,线程数,流量等指标的监控。基准值部分,达到单实例可承载请求量,线程数,流量。伸缩方面,做到最小保留实例数,最大扩容实例数,根据监控反馈和基准值计算需要扩容和缩容的实例数, 按照各个集群资源余量按比例伸缩。

主要涉及如下四个方面工作:

服务图谱数据示例

  • Grafana、Kubernetes和terra form等流行的DevOps工具来构建这样的系统。更重要的是,尽管这个想法本身非常重要,但实施它所需的基础设施管理水平远远超过了普通公司的能力。

运维发展历程与工业革命异曲同工,工业的三次革命分别是机械化、电气化与信息化,运维则是原始手工、脚本与自动化工具。那么工业4.0悄然来临的今天,智能化又将会给运维带来哪些影响?坦白讲,AIOps是新概念,目前并没有准确且广泛使用的定义,对AIOps的认知也会随实践、反思和讨论的不断积累发生演变。但AIOps所指代的整体趋势是毋庸置疑的,智能化将逐步走进IT行业乃至社会生活的各个方面。

图片 11

作者|宜信

AIOps是一个总称,用于指代使用复杂的基础设施管理软件和云解决方案监控工具来实现自动化数据分析和日常的DevOps操作。

2.3变更管理:之前是人工配合一些工具脚本,无系统化思维能力,往往只见树木不见森林。现在是通过云提升系统外变更效率,通过自动化工具(例如Puppet和Ansible)提高系统内变更效率。

图片 12

与此同时,真正具有创新精神的公司已经在努力将人工智能算法、ML模型和DevOps系统相结合,以提供未来最先进的云监控和基础设施自动化解决方案。应用这些实践可以极大地改善客户体验,缩短产品的上市时间,更有效地使用基础设施,以及在团队中更好地进行协作。然而,即使是这些创新者也没有现成的解决方案来满足他们的需求,他们不得不使用Splunk、sumeoric、Datadog、promethus

3.6非零基构建:AIOps是在现有基础架构之上构建的智慧大脑,依赖于现有的眼(应用访问关系、监控告警、日志)和手。眼数据主要有:应用访问关系,基础架构成熟的企业,积累了应用访问关系,不成熟的企业,需要借助AIOps进行梳理;监控数据,包括设备监控数据、网络监控数据、系统监控数据、平台监控数据、应用监控数据、业务指标监控数据,这些都是结构化的时序数据;日志数据,非结构化的数据,每个系统都有自己的日志数据,不便于统一分析。手主要分为外手和内手,外手主要是在系统在外侧操作,可以通过云平台(IAAS和PAAS)实现,内手主要通过自动化工具实现,例如无代理的Ansible和有代理的Puppet。AIOps就是基于现有的眼数据,进行分析、推理、决策,然后使用现有的手进行运维。

Gartner 定义了基于算法的运维(ITOA)即是 AIOps,算法即运维,将算法运用运维领域。实际上我们在自动化运维体系中已经将算法落地到 DevOps 工具链中,例如在监控中服务图谱的动态绘制,APM 工具箱中的一键式线程分析,应用虚拟化中的弹性容量计算。但我们认为这些仍然是“自动化”的范畴,需要更加智能的方案。

原文标题:What Is AIOps: The Next Level of DevOps Services,作者:Vladimir Fedak

2.2高效运维:围绕着高可用架构,进行一些列高效运维工作,包括:资源供给、应用部署、日常变更、故障处理、数据治理等。

统一标准化消息传输协议,可靠多路消息订阅分发

【51CTO.com快译】AIOps是什么以及了解下它可以如何帮助您的IT部门,例如,利用它来快速处理所有数据。

2.1资源供给:之前是针对每次资源申请,运维人员都得把机器上架、系统安装、存储配置、网络配置等一系列流程跑一遍,涉及各个专业的人工协同,小企业人少,一个两个人搞定一切,大企业专业分工明确,这些工作需要多人协同,效率无法保证。现在是通过云计算来提升效率,主要是池化和自动化,池化是指提前准备一批资源,避免每申请一次就得准备一次,自动化是指通过自动化的流程去串接各个专业条线,避免沟通成本和低效的手工操作,提高了效率和人员安全。

以系统上线为例,我们给任务机器人一个目标“今晚 19:30 电签网关上线”。任务机器人通过“基本意图理解”知道是要驱动 CI/CD 系统 Hubble 的“一键发布”功能来发布“电签网关”这个系统。API 模型帮助任务机器人通过对句型,关键词,相关性的分析,来关联到 CI/CD 系统,也通过功能与 API 的关联,提取出来需要 buildApp 和 deployApp 两个 API,还帮助实现了两个 API 的参数填充。最后依靠 API 模型中的时序关联来确定了几个 API 的执行顺序,再加上执行时间,最终确定了执行计划。当然执行计划执行的过程会依赖“问题诊断”的认知模型。

责任编辑:

数据中心的主要职责是安全生产,围绕着安全生产有三个目标:

研发懂系统,了解业务逻辑,却“不敢”在没有运维 SRE 协助时(即使有自动化远程工具),快速解决业务问题。他们缺少全面了解基础设施、上下游应用的帮手。

那些10年前甚至是5年前构建的系统监控工具的主要缺陷是它们不是为了满足大数据时代的需求而构建的。它们既不能处理数量庞大的输入数据,也不能处理种类繁多的数据类型,更加不能与输入数据的速度保持一致。根据以往的经验,这样的云监控解决方案必须将数据分块,将看似重要的内容进行分离,并切断看似不需要的内容,最后使用焦点组和统计样本进行操作,而不是处理整个完整的数据。

3.5方案为王:学术界研究通用问题,寻找更优的算法,工业界除了需要解决通用问题,还需要解决更多的个性化问题。甲方和乙方经常不在一个频道上,乙方主打算法和产品,甲方确需要解决方案,解决应用场景中的痛点,这中间需要乙方设立解决方案部门,熟悉甲方各种套路。算法的价值在于解决问题,在算法、产品、解决方案、应用场景、产生价值整个周期中,算法仅仅是个开始,研究新算法,解决通用问题,固然很重要,利用已有算法,解决个性化问题,给出完整解决方案,才是关键。

Wormhole 是任务机器人的计算模型生产者。Wormhole 基于 Spark,既可接入 Kafka 在线实效数据进行流式处理,也可接入 HDFS 离线历史数据进行批量处理,在 Spark 之上还抽象出一套新的概念和处理模型,用户可以通过 UI 进行简单配置来实施和管理流式作业,用户只要选择数据从哪里来到哪里去,在流上执行什么样的逻辑即可启动一个流式作业。Wormhole 不光支持落地多 Sink,还支持流上处理,还可以在落 HBase 之前流上做一些数据清洗扩展等操作。

正如您所看到的,选择AIOps工具和解决方案对您的业务非常有益。这似乎是AIOps解决方案供应商的营销噱头,但其实并不是。当下,大多数企业都在努力朝着DevOps文化转型,并进行着数字化转型。

现阶段的AI得以发展,得益于算力、算法、数据的共同改良,算力是通用的,场景决定数据,数据决定算法。往往不同的场景有不同的数据,即使同一个场景的不同环境也有不同数据,这就决定了数据的适配性、算法的多样性。

其中,不断开放开源技术,推动技术共同成长是技术社区的核心目标之一。包括在今天正式开源的 UAVStack,Wormhole,DBus 等在内,已经开放七个系列的软件技术。更多开源参见技术学院官网

这样做的结果是,在数据分析阶段,一些重要的模式可能会被忽略,数据可视化的视图被完全排除。这可能使得整个过程毫无用处,就好像大数据分析不能产生可操作的业务洞察一样,它将无法提供大数据分析中最重要的价值。

二、高效运维

DevOps 工具链为任务机器人 HIT 的知识图谱构建提供了高质量的原始数据

矛盾是事物发展的源泉和动力。运维中的矛盾无处不在,既有来自业务与技术的矛盾,也有来自开发和运维的矛盾,还有来自数据中心内部的矛盾,解决这些矛盾只能靠发展。

1、自动化运维确实提升了运维时效,大幅度减少人工,提高了精细度。但自动化的执行流程是由人工定义的、明确的执行过程。随着对系统的适应力,决策力和时效性要求持续地提升,自动化运维也出现了边际效应。

原标题:下一代的DevOps服务:AIOps

三、智能运维

时效类问题:运维的本质是提供稳定可靠的服务,而达成这个目标的关键是足够好的时效。

快速处理数据。可以训练一个ML模型来处理系统生成的所有类型的数据——这是未来的方向。如果必须添加新的数据类型,模型也可以相对容易地进行调整和再训练,以保持高性能。这将确保数据的完整性和保真度,从而产生全面的分析和具体的结果。 深入的数据分析。当你能够实现对所有数据进行分析时,隐藏的模式就会出现,可操作的见解也会出现。然后,DevOps工程师就可以分析出基础设施需要调整的地方,以避免性能瓶颈的出现,并且可以坐在高管的桌前,为优化基础设施和改进运营提供具体的基于数据的建议。 日常工作的自动化。识别出事件模式后,就可以设置自动触发器。因此,当统计数据显示某些事件总是导致特定的(负面的)结果,并且必须执行某些操作来纠正问题时,DevOps工程师就可以创建触发器并自动对此类事件做出响应。

2.4故障处理:之前是接到监控告警,各专业分析根源,执行应急预案,但是存在很多问题,例如:缺乏故障预测、误报漏报、分析慢、无法自愈。现在是通过AIOps解决,实现故障预测、故障检测、根因分析、故障自愈,尽量减少人工参与。

有着各自不同的 schema 定义,例如 BIN 日志格式,JSON 格式,Plain 日志格式, 性能指标的 schema 与调用链的 schema 是不同的。

  9月15日技术沙龙

2.1高可用架构:高可用的IT基础设施可以确保应用系统的可用性与连续性,包括:应用集群、系统热迁、数据库集群、存储复制、物理备份等。

充分使用我们现有的 DevOps 工具链,而不是全面推倒重来。

因此,如果监控解决方案报告了由于连接数量增加而导致了CPU使用率的增加,诸如此类。Kubernetes就可以启动额外的应用程序实例,并使用负载平衡来分配访问流和减少负载。这是最简单的场景,而现实世界的用例则要复杂得多,需要允许自动执行任何的日常DevOps任务,使ML模型能够在特定条件下启动它,并预先处理问题,而不是在停机后。

2.2应用部署:之前是开发完交付给测试、测试完组织投产、投产完开展运维,不同阶段的人员相互割裂,应用发布部署效率低。现在通过DevOps提高效率,DevOps强调持续CI/CD,通过CI实现开发到测试的持续集成测试,通过CD实现开发到运维的持续系统部署,通过CD实现技术到业务的持续价值交付。

服务图谱:自动生成服务之间的调用关联关系

当然,要及时处理所有机器生成的数据是不可能的。然而,这正是人工智能算法(如深度学习模型)所擅长的那种任务。剩下的唯一问题是:如何在DevOps工程师的日常生活中让这些机器学习工具发挥作用?

2.3 节约成本:在满足高可用和高效的前提下,尽量节约成本,包括资源优化、性能优化、以及减少成本不敏感的资源浪费。

Think:决策。这是与自动化的核心区别,它需要通过理解人类的意图,同时收集执行环境的上下文,根据意图来安排执行计划,以及对执行计划做出调整。同时,在实际执行过程中通过对 Interaction 的反馈,将执行计划以及执行过程信息以类人化方式描述(自然语言)。它使用的核心技术包括自然语言处理,知识图谱,机器学习,搜索技术。

让AIOps进入场景

IT运维经历了三个阶段,即人工运维、自动化运维、智能运维。人工运维是指人工配合脚本。自动化运维是指系统工具的自动化,决策在人,执行在机器。智能化运维是指决策的自动化,决策在机器,执行也在机器。决策在于推理,推理依赖于规则,现阶段,规则是可编程的称为自动化,规则是可学习的称为智能化。

3、业务团队需要更多运营支持,移动化,多交互渠道,从而解放人的眼睛。

与东华软件、AWS、京东金融、饿了么四位大咖探讨精准运维!

五、结束语

Wormhole 技术架构

3.3 AIOps场景:一是质量方向,主要是异常处理,包括异常预测、异常检测、根因分析、故障自愈等。二是效率方向:主要是预测,包括批量预测、容量预测、交易量预测等。三是成本方向,包括资源优化、性能优化等。

Handson:执行。这是与聊天机器人的核心区别,根据 Think 提供的执行计划,适配计划中相关系统的 API,完成实际的服务流程编排以及服务流程执行。同时,它还需要给 Think 提供反馈,以实现迭代决策(反馈 + 调整);它也将执行过程以及执行结果反馈给 Interaction,帮助人了解执行状态(非自然语言)

3.2 数字化运维:信息化是把手工流程变成线上流程,数字化是把物理对象抽象为数字对象,通过大数据分析和机器学习算法挖掘数据的价值。大数据主要通过大量多样数据的分析,挖掘数据的价值,会使用到一些机器学习算法,机器学习主要强调决策的自动化,依赖的基础也是数据,可以说,大数据分析基础,AI是目标态。AIOps是运维数字化的直接体现。

2、传统 IT 协作模式越来越“玩不转”了。传统模式是业务找研发,研发找运维,运维找系统的“线条”模式。同时,IT 的语言与业务语言时常“鸡同鸭讲”,误读时有发生,也造成效率低。

AI算法:机器学习算法,按标注可以分为监督、非监督、半监督、强化;按用途可分为分类、聚类、回归、降维;按照方法可分为统计学、传统机器学习、深度学习等。其中,统计学(例如:正太分布、均衡分布)要求数据必须满足某种分布,在异常检测领域用的多,包括运维领域的故障处理、金融领域的反欺诈、工业领域的残次品检测。传统机器学习(例如:kmeans、随机森林、支持向向量机、贝叶斯、决策树、马尔可夫等),虽然对数据要求弱一些,但对场景依赖强,即使是同一个场景的不同环境,也需要不同模型,在数据分析领域用的比较多。深度学习(深层神经网络,例如:CNN、RNN)对数据要求高,因为更多的数据才能训练出更深的神经网络,更深的神经网络抽象表达能力更好,也就决定了场景适应能力越强,主要是用在图像技术、语音技术、自然语言处理三个通用技术领域。

初始加载和独立加载

四、监管之剑

Interaction:交互。实现与人类非 GUI 交互界面,目前实现两个方面:文字交互 CUI(内部系统聊天 / 通知,公共 IM 系统,比如微信 /QQ),语音识别与语音合成(手机终端设备)。它是人与系统交流的中介,起到翻译信息,传播信息的作用,使得人不再需要被绑定在特定系统界面才能完成相关工作。

不同的变更策略,例如服务画像数据是根据应用升级不定期变化的,日志数据也可能是这样。

调用链数据示例

Dbus 多数据源支持

技术选型上充分利用已经比较成熟的开源 AI 技术,可以做必要改进,但尽量不重复造轮子。

目前我们的任务机器人 HIT 的训练主题“问题诊断”的计算模型都是由 Wormhole 来实施训练,实际生产过程中会使用机器学习和某些经典统计模型,主要的有:

图片 13

支持分表数据汇集

指标的关联组合模型:识别出哪些指标组合是判断异常的充分条件。

AIOps 团队建设

以上的痛点归类起来可以认为是两类问题:

业务与系统的“全知”者:协调业务与系统,管理系统,支撑业务

图片 14

开源网址:

对运维领域的技术 (比如监控,容器技术,CI/CD,问题诊断等) 是清楚的,最好是专家

AI 技术还不是“平民技术”,尽管已经发展了很长时间,但它的投入产出比可能并不像使用 spring,tomcat,RabbitMQ 这些开源技术栈那样的直接。所以先做“点”的事情,再考虑“面”。要从适合的场景下切入。

我们是从传统运维转向自动化运维,进而向智能化运维迈进。通过对 DevOps 工具链的不断建设,我们形成了贯穿全维度监控,CI/CD,自动化测试,应用虚拟化的自动化运维体系。尽管如此,在金融运维 / 运营过程中,我们还是碰到以下痛点:

我们的团队主要有两类角色:

宜信技术研发中心在 CNUTCon 全球运维技术大会上宣布正式开源支撑智能化运维的三大利器:UAVStack, Wormhole, DBus。究竟是怎样的核心技术,能造就这样支撑智能化运维的利器呢?一起来看!

数据总线 DBus 持续的,自适应的将全维监控数据导入大数据存储

宜信技术社区是宜信技术生态圈建设的重要组成部分,是展示宜信技术、构建对外交流的综合性社区。旗下拥有宜信技术学院、宜信技术天地(微信公众号)、宜信技术大会等多种形式。社区主要面向宜信内部员工、合作伙伴及广大技术爱好者。

这种目标驱动的应用场景还有很多,例如让任务机器人去做线上的智能巡检,协助问题处理,甚至支持运营协作等。

API 模型包括了应用 / 服务的 API 元数据信息和实例信息,这些信息必须时刻与现实世界保持同步。而全维监控 UAV 提供了应用画像数据,由于 UAV 本身采用了微智能(强调自动发现,自我维护,自动适应)的设计,使得应用画像数据本身就时刻与现实世界保持同步。任务机器人 HIT 通过直接归集应用服务画像数据,按照 API 模型的认知关联结构,就可以生成 API 模型。而微智能的特性天然的、高质量的保障了自动化 API 模型的知识图谱构建。

图片 15

运维 SRE 变成了关键“瓶颈”,他们的经验没有被沉淀和共享。

对现有 AI 技术充分了解和掌握

最后来谈谈我们的团队。相信在面对 AIOps 的时候,大家都会思考团队要如何构成。我认为 AI 的生态体系与大数据类似,存在两种基本角色:AI 科学家和 AI 领域工程师(FE)。前者推动 AI 科学的发展,创造新的 AI 知识体系;后者是将 AI 知识运用到生产生活的某个领域,创造现实价值。

图片 16

DBus 专注于数据的收集及实时数据流计算,通过简单灵活的配置,以无侵入的方式对源端数据进行采集,采用高可用的流式计算框架,对在业务流程中产生的数据进行汇聚,经过转换处理后成为统一 JSON 的数据格式(UMS),提供给不同数据使用方订阅和消费。DBus 将 UAV 采集的全维监控数据以无侵入方式进行实时收集,为下游大数据处理平台 Wormhole 运行统计模型和机器学习提供数据源。

应用 / 服务画像:监控探针自动对应用的技术栈进行分析提取应该的元数据,其中重要的包括应用实例的 URL,有哪些服务接口方法以及 URL,使用了哪些客户端(MQ/DB/Redis/NoSQL/Http/Dubbo 等)以及访问的 URL。

图片 17

时序数据的趋势预测模型:可以根据过去若干天来预测未来一段时间某重要指标的趋势走向。

Web 浏览器客户端体验数据(Ajax)示例

图片 18

应用性能指标 & 日志数据示例

应用 / 服务画像数据示例

DBus 能够将不同的格式转换成标准格式(UMS 格式)。它会根据不同的格式和对数据转换和抽取的相关配置,对数据进行实时解析和计算。以应用性能指标和业务指标为例:数据格式是采用 MDF 文件格式(UAV 的一种格式),它是一种 JSON 格式的层次化数据,而 DBus 最终输出的 UMS 数据格式是一种以表为基本单位的数据,因此需要将数据进行扁平化,一条 MDF 日志对应的多条 UMS 数据。

图片 19

全维监控 UAV 为任务机器人 HIT 的模型训练提供了全面维度的原始数据

UAVStack 是智能化服务技术栈,是研发运维一体化的解决方案。UAV 是无人机的缩写,寓意无人机翱翔蓝天,智能的,透明的完成任务。它包括任务机器人(代号 HIT),全维监控(代号 UAV.Monitor), 应用性能管理(代号 UAV.APM), 服务治理(代号 UAV.ServiceGovern), 微服务计算(代号 UAV.MSCP),用户体验管理(代号 UAV.UEM)等。其中,UAV.Monitor+APM 为不但为智能运维采集全维监控数据,也提供了实时监控,自动化问题诊断的工具,是一站式的全维监控

举个例子,任务机器人 HIT 根据执行计划驱动 Wormhole 每十分钟从 HBase 上提取最近一个短时间窗口的数据(若干天),HIT 通过“问题诊断”知识图谱选择[时序数据的趋势预测模型]和[组合指标的异常点识别模型]对十分钟增量数据进行异常点识别,并预测出未来一小时的指标趋势,并做适当统计聚合,可以得到一个延迟 10 分钟级别的增量监控指标走向,自动识别的异常点和未来一小时的重要指标趋势预测图,同时也可以根据异常点的严重性级别进行预警。可以看到整个预警体系是非人工参与的,基于机器学习模型和增量数据准实时的推算出来了,当模型准确率越高,预警也会更精准。

业务指标数据示例

业务指标:应用可以通过埋点或日志方式提供自定义指标

图片 20

任务机器人 HIT 的核心能力来源于特定领域的知识图谱和计算模型。目前我们的训练领域包括系统 API 模型,个性化交流上下文,服务拓扑,执行计划,问题诊断等。知识图谱是实现认知关联的核心技术,而如何自动化构建知识图谱是关键的关键。成熟的 DevOps 工具链可以为自动化构建知识图谱提供高质量的原始数据。

应用日志:应用产生的各种日志,支持过滤规则。

解决上述问题的目标归纳起来是,我们需要 AIOps 系统成为

此外,DBus 还提供以下特性:

我们 AI 的实现形态是任务机器人(代号 HIT)。它是统领智能运维的“大脑”,是类人行为的软件系统。任务机器人应该具备以下能力:

尽管通过 UAV 采集到了全维度的监控数据,但是还不能直接使用这些数据来做机器学习和统计模型。其原因是由于它们的存储和查询需求是根据实时监控领域的需要来定义的,因此它们有以下特点:

图片 21

HIT 的设计理念就是对任务机器人能力的抽象。它由三种核心服务构成:

宜信开源软件系列

没有“判断力”,不能决策。存在多种可能性的运维事件,需要 SRE 介入判断和分析,才能明确是什么,然后才能对系统下达指令。例如:当发现高 CPU 报警时,服务该不该降级,应用该不该重启。而事实上,让人人都成为运维专家是难以达成的,如果 SRE 不在,问题就搞不定。

UAVStack 中 Monitor+APM 为实时监控 + 应用深度运维提供了解决方案(如图)。在智能运维体系中,它采集的全维度监控数据是机器学习和统计模型的原始数据来源。全维度的监控数据覆盖基础设施性能,应用 / 服务性能,日志,调用链,线程栈,客户端体验,业务指标,应用画像,服务图谱。

应用环境性能指标:虚拟机 / 物理机系统级以及进程级指标,例如 CPU,内存,连接数,网络流量,磁盘 IO 等

任务机器人与普通系统的另一个重要区别是:普通系统可以看成是通过编码来“机械”的完成某种事,就系统本身而言,它并不理解“我在做什么”。而任务机器人是以目标驱动的,它根据 API 模型以及其他认知模型(知识图谱)来生成执行计划,并使用 API 模型来实施执行计划,执行计划的本质是对 DevOps 系统 API 的调用。

Web 浏览器客户端体验数据:页面加载,离开页面,JS 错误,Ajax 请求,地理信息,客户端 IP 等

DBus 支持不同格式的标准化

落地方案

目前 UAVStack 开源系列包括:

图片 22

开源地址:

线程栈数据示例

问题节点的根源分析模型:跨多节点的异常行为关联性识别模型。

线程栈数据:JVM 线程 Dump+ 每个线程的 cpu,内存消耗的数据

选择较成熟的开源 AI 技术是必由之路

图片 23

我们的 AIOps 平台是以任务机器人为中心,利用大数据平台实现机器学习和统计模型的处理,与 DevOps 工具链深度集成实现智能化运维。可以从以下几个层面来解读这个架构:

图片 24

服务后台工程师:掌握服务化技术,对 AI 技术有一定了解,熟悉研发 / 测试 / 运维,具备运维经验

被存储在不同的存储源中,例如服务画像数据存储在 MongoDB,应用日志和调用链存储在 Elastic Search 中,应用性能指标和基础性能指标数据存在 RocketMQ 中等;

尽管 AIOps 会带来颠覆性的运维思维和效应,但是否也要对现有系统软件来一把推倒重来呢?AIOps 是 DevOps 的进化方向,与 DevOps 工具链深度集成是必由之路。所以 AIOps 并非是要取代现有的自动化运维体系,而是赋予现有体系智能。

任务机器人 HIT 通过 API 模型实施执行计划

值得一提的是,经过实践证明,自动化运维是智能化运维的构建基础。如果没有自动化运维的成型技术和方案,AIOps 也是空谈。用个形象的比喻,自动化运维体系中,监控系统的数据采集好比人的眼睛、耳朵是用来感知现实的,远程执行好比人的手脚是用来反馈现实的。而 AI 系统好比人的大脑,它接收感知,通过一系列处理形成决策,这是“认知”的过程,然后通过反馈给人或执行结果,体现“智慧”。

适应力不足,人工介入的滞后性。比较典型的情况是报警,通常报警是由运维人员根据经验来设置的策略,但是市场和业务发展的快速变化会使得预先设置的策略过时,不是出现频繁报警,就是出现该报的没报。

图片 25

此外,调用链的数据可以帮助自动构建时序关系,CI/CD 的项目特征和人员关联数据可以帮助构建应用与团队的映射关联(从故障问题到应用,再到代码和人员的追溯),测试用例的输入和输出可以帮助构建 API 模型的参数关系,语义关联和缺省参数等。

从层级汇报(人围着人转,人找人)的模式转变为以数据为中心,数字化运营(人围着数据转,人找数据)的模式是大趋势。而这种转变的技术基础是业务团队可以通过各种渠道(不是非得登录某某系统,也不是非得找到某某领导或联络人)快速传播信息,分享数据。

开源网址:

智能运维的自研之路

图片 26

日益兴盛的人工智能技术,让我们意识到赋予系统“智能化”是大趋势。对 AIOps,我们更愿意这样解读:AIOps 正是将人工智能技术应用到 IT 运维领域,帮助变革运维模式,提升效率和创造现实价值的“工程化”过程,也是 DevOps 的进化方向。

DBus 能够支持多种数据源,只需通过配置就可实现无侵入对接。采集端包含了数据库的日志采集端、日志采集端、各种基于 Flume 自定义插件的采集端等,这些采集端将数据实时的同步到 Kafka 中,完成数据采集工作。

DBus 自动适应格式版本变更

组合指标的异常点识别模型:组合指标在时序上异常点的自动判别。

图片 27

另一个例子,服务拓扑是反应服务之间的关联关系,在微服务架构下,这种关联关系也变得日益复杂。全维监控 UAV 提供了服务图谱,它也是基于微智能思想的数据,可以及时地与现实世界同步。HIT 也只需要归集服务图谱,按照服务拓扑的认知模型来构建知识图谱即可。

应用性能指标:包括应用集群,应用实例,应用中间件 /JVM,服务组件,客户端组件,URL,数据库连接池等性能指标

图片 28

宜信开源技术

算法数据工程师:掌握算法技术,AI 技术,具备一定的工程化能力,了解运维领域知识

对运维领域的场景是熟悉的,明白运维的标准,逻辑,原则

运营措施能够用“听得懂”的语言直接、高效地反馈给业务团队。例如资金需求上来了,资金调拨团队通过资金调拨跟上资金需求的增长,但他们并不清楚实际起到了多大效果,当然通过业务监控能够看到,但金融行业特点,移动办公 / 出差是常态,并不是时刻具备登录系统的条件,但通过微信,QQ 等就方便多了。

调用链:包含服务 / 客户端 / 方法级,所在类 / 方法,耗时,状态,请求报文,响应报文等

应用环境性能指标数据示例

业务团队希望随时随地,简单,快速的了解系统运行状况,业务运行情况,当然他们也看不懂 IT 术语,他们希望能听到“人类”的语言。

大数据处理 Wormhole 针对目标场景,基于全维监控数据进行机器学习和统计模型处理

另一个例子,任务机器人 HIT 通过“问题诊断”知识图谱选择 [指标的关联组合模型] 和 [问题节点的根源分析模型],通过应用性能指标发现 CPU 很高,关联上线程栈数据就可以知道是哪些线程引起了高 CPU,线程栈的代码栈又可以关联到服务画像,从而发现与哪个服务的 URL 有关,通过服务 URL 关联服务性能指标可掌握是否是由高并发访问引起的,关联服务图谱可以追溯是哪些上游系统在调用这个服务 URL,哪些下游系统可能会受影响,关联调用链数据可以追溯是哪些业务请求引起的,甚至对下一个时段这些业务请求峰值进行预测。

那么应该怎么建设 AIOps 系统呢?我们确立了几点原则:

  • 应用运维解决方案。

业务运营支持的成员:协调人与业务,参与运营的“助手”

运维管理的成员:协调人与系统,不是被动的工具,而是直接参与运维的“助手”

DBus 技术架构

图片 29

协作类问题:人类的生产离不开协作。尽管有了自动化运维平台或工具链,运维很多场景还是需要许多人工协作。

图片 30

我们团队的定位是 AI FE,是将 AI 技术工程化的团队,这样的团队应该具备几个特征:

图片 31

DBus 有自动适应的能力,匹配这些类型和格式的变化。它支持指标动态添加,就算每次来自 UAV 的 MDF 数据都带来新的指标类型,这些新增的指标也并不会影响解析本身数据本身;同时,它还支持动态 schema 变更,即自动感知数据的列名和数据类型,UMS 格式记录了数据的版本和列信息等,一旦发现不属于同一个版本的数据就会自动升级版本号,生成新版本的数据。例如如下的新版本比旧版本多了一个字段 RC406(一种应用性能指标,Http 响应码)。

多种数据源支持,海量数据实时传输

图片 32

复用现有 IT 优良资产,最大化资产价值也是必要的考量。

任务机器人团队早期是以虚拟团队的模式成立。因为面对新的领域在研发 / 运维体系上需要尝试新的模式,就把算法同学,后台服务同学,运维同学都拉到一块。通过知识交互,经验分享等手段,让大家逐步在认识上同步。并要求所有人掌握整个端到端过程。此外,随着智能化运维的开展,UAV,Wormhole,DBus 等团队也逐步在架构,技术,对接等层面达成一致。

痛点是技术升级的驱动力

图片 33

目标是从实际痛点入手,找到适合场景以及正确的问题来试点,而不是“大而全”的 AIOps 解决方案。

编辑:互联网 本文来源:关于智能运维AIOps的一点思考,宜信正式开源其

关键词: