赣州专业网站推广,怎么在自己的网站上做漂浮链接,横琴注册公司代理,群晖wordpress换端口DevOps是什么#xff1f; 对于传统的软件研发而言#xff0c;开发#xff0c;测试#xff0c;运维#xff0c;运营#xff0c;有不同的岗位进行分工协作#xff0c;以保证质量和专业度#xff0c;同一件事情#xff0c;依赖不同岗位的排期、沟通、协调#xff0c;效率…DevOps是什么 对于传统的软件研发而言开发测试运维运营有不同的岗位进行分工协作以保证质量和专业度同一件事情依赖不同岗位的排期、沟通、协调效率难免会有打折。而对于互联网业务来说快速的迭代对人力的需求非常强烈不大可能有足够的人力支撑这么多岗位。同时跨部门的沟通强烈影响了项目的进度因此一些快速发展的团队开始推行DevOps自己做测试保证代码质量自己上线运维监控告警。亚马逊很早就开始推行you build it, you run it的文化。由于自己对自己的做事情很清楚因此效率也会很高。这就是DevOps。
DevOps的挑战 DevOps责任多事情多且杂。一天的时间怎么分配我作为研发肯定是希望一天90%能够专心的写代码。但实际上只有20%的时间来写代码其他的时间做什么帮用户调查问题处理工单。做线上的运维等等。用户提了一个工单你要立马放下手中的工作去帮用户调查问题。结果就发现时间被碎片化了一天中很难有大块的时间去专门做研发。
通过数据驱动和智能自动化应对DevOps的挑战 怎么解决研发过程中时间碎片化的问题我们原来做了很多重复性的工作这些工作可以总结和沉淀下来通过工具帮我们去沉淀。我们原来需要调查问题的时候才登录集群要抓日志现在做一个采集日志的工具把所有日志的实时采集到云端当需要看日志的时候我立马就可以在服务端看到所有的日志信息。原来需要到机器上搜索日志现在在云端做倒排索引直接就可以搜索到整个集群的日志。原来我可能要用excel做一些数据分析的工作去分析我的运营效果怎么样。现在在服务端实现一套实时分析的计算引擎再加上可视化功能帮助做各种各样的报表。原来调查问题的时候要登录集群上用vim打开集群上的日志看文件上下文是什么样子的。现在在云端做一个上下文关联的功能直接在云端就可以看到所有集群上的日志和上下文信息。原来调查问题可能依赖于人的经验。现在通过AI帮我们做自动化的事情。 所以总结下来我们希望通过数据中台帮我们实现数据驱动的运维来代替原来的人工驱动。借助于AI帮我们实现自动化、智能化。通过这种数据驱动加上智能自动化的运维帮我们节省被碎片化的时间。
数据中台的挑战 如果我们要做这样一个数据中台会面临哪些挑战呢首先就是数据太少如果我们抓取的数据太少的话那么我们的信息量就会太少在分钟级别的监控里面可能很多信息就被平均掉了我们只有抓秒级监控才可以看到我们所关心的数据。第二个是实时性的挑战我们做线上故障恢复的时候都希望是说可以尽快定位问题的答案尽快去恢复这就是一个实时性的需求。如果我们找到答案太慢可能已经错过了一个最佳的自救的时间。第三系统越来越复杂我们的需求是越来越多的我们每加一个需求要加一个模块那么维护整个一套系统其实是一个非常大的挑战。最后是数据太多的问题数据太少是问题太多也是问题。太少的话信息量不足太多的话很多重要的信息被淹没。关于数据规模的问题和数据速度的问题可以通过数据中台来解决数据中台帮我们通过算力来换取一个数据的速度和规模而数据太多信息爆炸的问题我们用AI算法来换取对数据深入的洞察力。
数据中台的基础能力 数据中台具备的能力第一个就是数据采集数据采集帮我们从各个数据孤岛中从各种环境中把各种各样的格式的日志统一采集然后以统一的格式被存储起来。原来数据可能在手机上可能在网页上等等各种各样的环境格式也不一样。统一采集之后 我们就有统一的格式以后分析就非常方便了。数据采集帮我们做的脏活累活其实是帮我们节省了很多的时间。数据采集之后中台要有二次加工的能力。为什么要二次加工因为我们采集过来的数据可能包含着脏数据垃圾数据我们要过滤掉做一些转换和富华。增强数据质量数据质量增强以后分析的时候才可以得心应手。接下来就是一个查询分析的能力中台提供的进行交互式的查询分析可以在秒级别分析上亿日志。通过这种查询分析能力你可以尽情的探索你数据里面包含了什么价值。查询分析依赖于人的经验探索数据那么我们还可以借助AI自动探索数据这就是AI的预测能力和异常检测能力以及根因分析的能力。通过数据中台将AI帮助我们去获取对数据源的可观察性进而通过数据可观察性实现对运维系统的可观察性。
基于数据中台的问题调查路径 我们前面介绍了数据中台的接下来我会以一系列的实践去分享我们怎么样利用这样一个数据中台帮我们解决我们DevOps所遇到的各种各样的问题。
我们说到数据驱动的运维首先我们会面临大规模的数据如何去找有效的信息这就是一个发现的过程。原来我们通过grep搜索的关键字通过awk做一些简单的计算借助中台我们可以通过交互式查询去不停探索答案也可以通过异常检测帮助我们智能的检测数据里面到底有什么异常的信息。 当我们发现一些有效信息以后接下来怎么办我们要从这些线索出发然后去找更多的线索去找关联关系去找因果关系这个就是上下文钻取以及聚类。那么通过这种钻取我们可以找到一系列的更加关联的信息我们最终找到了信息足够多之后我们要确定最终的一个答案这个就是根因分析帮我们确定故障的根本原因是什么。
数据驱动和AI驱动的DevOps实践
1搜索和上下文 我们做数据分析最简单的形式是什么我们上网的时候用的最多的工具是什么是搜索引擎搜索可以帮我们尽情探索数据中的价值。原来我们到机器上搜索日志数据在文件中是是有序的存储的。而在采集的过程中为了性能的考虑会以乱序的形式存储下来当然我们搜索完之后可能我们看到的是乱序的日志。如何从这些乱序的日志中找它的上下文信息呢我们为每一条日志指定一个编码。当我们搜索到一条日志之后去看它的编码值再去计算它的下一条编码是什么根据编号搜索下一条日志。通过这种方式去找搜索去定位下上文 我们看一个搜索和上下文的样例。我们把所有集群的日志都被统一的采集到一起然后去搜索整个集群日志这个时候如果我们对某一台机器感兴趣的话我们可以把机器的hostname加入到搜索条件里面去。这个时候如果我们对某一些关键字不感兴趣的话我们可以过滤掉。这个时候我们定位到9条日志我们对这9条日志感兴趣。我们可以去看上下文的信息。在上下文里面可以以上下文严格有序的一种形式去看这条日志前后发生的一些事情通过这种方式找它的一个因果关系。 2全局视野和局部视野 搜索针对的对象是什么是日志日志是什么是一种事件类型的数据里面包含的信息有事件的发生的时间、对象、操作还有各种属性关于事件的描述是非常详细的。除了这种事件日志还有一种指标日志。指标日志有时间有一个汇总的数值例如用一个数值表示这一分钟有多少个浏览量。这两种数据有什么区别事件日志描述的是一个非常详细的信息所以它的体量和规模是非常大的。它代表的是我们从局部去观察问题的一种视角。而指标数据是一种汇总的信息所有它的体量非常小。但是它代表的是一种全局视角概括整个事件的信息。例如我们一分钟有1万次的访问我们用这种事件日志来表示可能就真的是1万条数据。用这种指标日志可能就是1万这一个数字这就是两者之间的差别。这两种日志之中是不是割裂的不是我们可以通过计算把事件日志转化为指标日志一个是代表大视野一个代表小视野。我们可以充分利用计算在这两种视野之间切换去调查问题。
举个例子我们面对一个事件日志可能对某一些维度感兴趣比方说时间维度那么在时间维度中统计趋势指标或者对IP维度感兴趣可以统计出IP分布他们这个时候我们就把一个事件日志转化成了指标日志从局部视野跳到全部视野看待问题。 当我们看到某一个数值比较特殊我们对它进行下钻增加维度进行更多的统计。比方说我们按照不同的IP统计出它的趋势。假如统计出来的各个维度之间我们对某一些维度感兴趣的话我们把它单独拎出来跳回我们原来的事件日志当中帮我们搜索对应的事件。这样的话我们就形成了一个调查问题的闭环我们从事件日志出发去统计它全局的信息再回到原来的事件这是一个闭环。 3聚类解决数据爆炸 事件日志的体量是非常大的现在对于我们的业务来说每天的数据量都在上涨每分钟能达到上亿条的日志日志这么多重要的信息被淹没了怎么办即使我们只关心错误的日志但是错误的信息可能都有上千条什么时候看完我们通常对于这很多大量日志的这种场景首先想的是排除法比方说我们先把一些不关心的日志排除掉逐步排除掉一些关键字逐步的缩小数据的体量慢慢靠近我们关心的信息。对于数值类来说我们怎么样排除我们可能统计数值的百分位去统计它的25分位在哪里75分位在哪里99分位在哪里假如说说我们对99分位感兴趣只需要过滤出来99分位以上的数据通过这种方式减少数值类型数据的体量。
但是这种排除法不一定可以帮助我们找到所有我们所关心的问题因为我们现在的业务实在是太复杂了维度太多了。有一个真实的案例就是有一次我们一个新版本发布有一个边界的条件没有测试到上线之后也没发现直到用户跑过来问为什么我之前可以用现在不能用现在开始报错了我到这个时候才发现发现真的是从升级那一刻开始出现一种新类型的日志原来都没有这种日志。显然用排除法是没有办法帮我解决升级后的这种异常检测怎么办呢那我们引入了智能聚类。即使每分钟产生上亿条日志可能里面不到100种类新的事件只是说每一种类新的事件重复发生了很多次所以造成整体数据的膨胀。 通过这种分析数据之间的关联性把数据里面的干扰信息过滤掉提取出里面一些公共的特征这个就是聚类。在这个例子中我们有1300万条数据人眼去看这1300万条可能一天一夜也看不到。但是我们可以通过聚类最后只有35条聚类的结果这个时候我们去看35种类型的事件其实一眼就可以看到那么在机器上到底发生了什么事情。比如说我可以一眼看到这是有这样一个timeout关键字是不是要特殊的关注它
我们怎么样利用智能聚会帮助我们解决升级后故障发现的问题。我们可以通过对比升级后你的聚类结果和升级前了聚类结果查看有没有什么差别如果一个新的事件在升级之后出现了而之前是没有的这是特殊关注的。通过这种方式我们去做告警及时发现问题及时的处理避免影响到用户。4Metric数据异常检测 通过智能聚类实现对文本类的数据异常类检测。那么对于我们刚才说的Metric指标数据怎么样寻求异常检测最简单的指标什么是一条平稳的直线围绕这样一条直线可能有一个很轻微的在正常范围之内的波动对于这种数值我们设一个固定的阈值可以很好的把一些大的抖动捕获出来。但是这是一种非常简单的场景在现实的业务中其实没有这么简单的现实的数据一定是有各种各样的波动。 最常见波动是什么是周期性。一般我们工作日它的流量比较高到了周末流量又跌下去了那就是一个周期新的波动所以对于波动性的信息我们怎么样做异常的检测我可以通过同比、环比拿当前时间点的数据和上一个周期同一个时间点的数据进行对比看看有没有发生比较大的偏差这就是同环比算法。
还有一种情况就是趋势性对于互联网业务来说增长是一种常态没有增长的业务是没有前途的。在增长的趋势中可能还有周期性的波动以及扰动。我们所关心的那种异常的点可能被掩藏在这样一个增长的趋势中对于人眼来说其实一眼就可以看出来哪一个点是异常点。但是对于算法来说检测出来这样一个异常点是一个很大的挑战。我们的解决方案是通过机器学习通过学习历史上的数据它的一个趋势性信息周期性信息然后去预测未来的点是什么样子的。那么把预测的点和真实出现的这个数据进行一个对比那么当这样一个差值发生比较大的偏差的时候就认为这是一个异常的点。通过这种方式去检测趋势性数据里面的一个异常点。
不管是周期性信息还是趋势性的信息它其实都是一种很规律的一种波动。那么还有一种数据波动称为断层。比方说原来我们一个机器它的CPU很低。突然有一天你把流量切到机器上它的CPU立马暴涨到另外一个水平但是它的波动又没有什么变化这就是断层。对于断层的数据其实统计的时候是非常难的因为在这样一个点里面它的导数是没有的。那么我们可以用专门的断层检测算法去检测出来。 最后一个就是变点变点是什么就是在某一个点它的波动形态、统计特征发生了变化。原来可能是一条平稳的直线但是在某一个时间点假如说发生了异常你的流量抖动开始发生了非常大的一个抖动这就是一个变点。通过变点算法统计所有数据里面的波动信息然后对比不同点上的波动信息进行检测这种变点。这就是我们针对Metric指标数据利用机器学习、统计算法进行异常检测的方法。
5异常根因分析 当我们检测到异常之后下一步要做什么事情要找这个异常它发生的原因是什么并且及时的去修复它。假如我们网站流量下跌了7%下跌是什么原因引起的通常人工是怎么检测这个问题的我们可能按照我们的经验逐步去排查比方说我们先到服务端看一下有没有错过日志服务端没有再看网络上有没有抖动。OK那网络端没有抖动接下来怎么办再去看用户的统计上有没有异常的一些抖动结果发现用户的统计上有抖动的话怎么办我们再去下钻去看什么类型的用户发生了抖动。比方说不同的城市有没有抖动不同的接入点有没有抖动不同的客户端有没有抖动结果发现在客户端这样一个维度有数据是抖动的。那么我们再深入的下钻去找哪一种类型的客户端发生了问题。通过这种逐层的下钻逐层去找最终定位到版本因素造成了流量下跌。 这是我们人工调查问题的一个方法这一套流程走下来其实是非常耗费时间的。我们怎么样借助算法帮助我们做这种异常检测呢这就是关联规则算法大家都听说过啤酒和尿布这个故事在一大堆物品当中啤酒和尿布同时出现的频率非常高所以我们认为它两个之间是有关联关系的然后进行关联推荐。我们可以把这种关联推荐给映射到根因分析算法。比方说我拿了一个访问日志访问日志里面有很多的错误信息然后我们再把网络日志拿过来。结果发现在网络日志里面某个交换机经常会和这个错误日志同时出现是不是可以认为这个交换机上出现了错误
如何找两个关联的项目就是我们通过频繁集算法。我们把一份错误的日志拿出来找这个日志里面它高频出现的一些数据集合。比方说我们在这样一个错误日志里面定位到IP等于1002这样一个用户他出现的频率是68%那么是不是认为这样一个用户他就是造成我们错误的一个原因不一定。为什么因为这个用户可能在错误的日志中出现的频率比较高但是在正确的日志中出现的频率也是非常高的所以你不能简单认为他就是一个错误的原因。那怎么办呢要通过差异集合算法进行统计我们把一份完整的数据按照是否有错误分成正负两份样本然后比较两个样本里面的频繁集有什么差别如果某一个集合它在一个错误的集合中出现的频率比较高而在正确的集合里面出现的频率比较低就可以认为这个集合是造成错误的根本原因。 如果我们再引入到时序维度针对我们刚才说的网站浏览量下跌的问题我们怎么样做这种根因分析呢我们首先面对一个汇总的流量下跌的曲线然后可以把我们所关心的维度都引入进来例如地区维度运营商维度客户端维度全部引入进来把各种维度自由组合各种各样的集合那么我们算出来每一个集合它的一个流量曲线计算算每一个集合它下跌的一个趋势和整体流量下跌趋势之间的关联度并且打分按照分数的高低寻找根因集合。通过这种打分找出来一个集合它对整个流量下跌的贡献是最大的。比方说我们最终统计出来上海这个地区所有的运营商流量下跌都非常的严重打分非常高那我们认为上海这个集合就是根因。 6DevOps成本控制 对于我们DevOps而言我们不仅要关心我们所做的成果还要关心我们的成本因为拿堆资源做出来的成果不代表一个人的能力用最少的资源做最大的事情才可以代表一个人的能力。我们通常做采购机器然后等待机器到货、上架最终部署这个软件交付。这是一个原来传统的上线机器的流程。这个流程是很长的一般过几个月才能拿到机器。现在有云服务一键可以创建机器当你需要的时候可以立马拿到资源这样一个流程实在太方便了。但是就是方便背后其实也有一些其他的困扰。比方说我一次测试的时候买了一台机器用完之后忘了释放结果这机器在那里跑着一直产生费用或者我在储存里面放了一大堆的数据测试完全之后忘记了删除过了很久谁都不知道这个数据是干嘛的谁也不敢删谁都不知道这个数据删掉以后会不会影响其他的业务。但是这些资源一直产生的费用。直到财务人员发现你的消费比较高的时候一般都会来踢你的屁股说你部门成本怎么这么高你要优化一下了。这个时候其实就已经是很被动了为什么因为这个时候我们去统计所有的资源统计谁在用这些资源这个流程是非常长的。我们可以通过主动的成本控制去统计我们的资源使用量实时去统计资源使用量实时去优化。 我们看一个成本控制的样例。我们把实时的把账单数据导入数据中台然后可以统计出来我这个月到底花费了多少钱预测这个月大概花多少钱以及每一个云产品花钱的数量。还可以去看过去三个月的趋势是怎么样的以及每一个产品的趋势。或者根据我们过去的趋势信息预测我未来三个月大概要花多少钱利用这个数字及时的去申请预算。
同时我们还可以在我们账单数据里面根据统计信息看一下有没有一些异常的账单。比方说我在近三个月的消费曲线中发现10月1号这一天账单发生了暴涨。我要抓出来到底是哪一个云产品产生了这么多消费于是深入下钻到日志里面去分析用刚才提到的根因分析的算法去找哪一个产品对一个消费的上涨贡献归最大所以我们发现SLS这样一个产品它的异常打分是最高的。那么我们就认为这个产品出现的消费异常及时的发出告警即可。
Summary 我们做一个总结我们介绍了调查问题的一系列案例通过这些样例展示我们如何借助于数据中台帮助我们做数据驱动以及借助AI做一些智能化、自动化的运维。通过这种数据驱动和智能、自动化的运维整体提升我们的效率减少我们被碎片化的时间。 阿里云双11领亿元补贴拼手气抽iPhone 11 Pro、卫衣等好礼点此参与http://t.cn/Ai1hLLJT
原文链接 本文为云栖社区原创内容未经允许不得转载。
