取消
搜索历史
热搜词
视频
活动
创新2.0
I T
产业
当前位置:首页 >互联网•IT > 大数据 > 大数据分析 > 正文
日志易产品总监饶琛琳:听运维老炮儿话运维
来源:ENI经济和信息化网  作者:赵贤慧 2017-08-08 11:25:45
如果企业一直把人力投在基础项,那就上不了优化项,上不了优化项就意味着基础项持续薄弱,持续薄弱导致运维人员永远放不出来,这是个恶性循环的情况。

记者:尊敬的各位ENI会员大家好,欢迎收看我们本期的ENI零距离,今天做客我们ENI的是日志易的饶琛琳饶总,有请他来给我们先打个招呼。

饶琛琳:大家好,我叫饶琛琳,是日志易这边的产品总监。之前是在人人网,新浪微博做过运维和系统架构的工作,出版了《网站运维技术与实践》《ELK stack权威指南》,编译了《Puppet 3 Cookbook》《Learning Puppet 4》,擅长 CDN 运维、Puppet、ELK 和 Perl 开发。希望把自己再运维方面的实践经验,通过日志易提供给更多有志于提高系统运维水平的公司和工程师们。

记者:可以说是一个有10年经验的IT运维界的老炮了。饶总,要不先聊一下日志易的基本情况吧,包括业务模式、信息化建设等都可以。

饶琛琳:日志易主要以日志为核心。因为所有的企业,无论是互联网还是非互联网的,只要有IT设备,运行的时候一定会输出一些记录的信息,包括设备开关机、密码输入有误等都会以文本信息的形式记录下来。而我们就是把这些文本信息收集好,通过分析得到更深入、更显性的知识内容。

例如公司今天突然出现一个匿名用户连续几次登录失败,大家可能会非常警惕,担心是不是有黑客要入侵等,这个时候就需要我们从日志里去挖掘提炼出相关信息反馈给客户。但这个信息并不是让大家去看原始的日志文本,因为每个人写代码习惯的不同,写下来的日志文本格式是千差万别的,如果直接看原始文本,就算是眼睛看瞎了,也拿不到更多想要有效的信息。

而日志易就是帮助大家完成这件事,将杂乱无章的文本提炼成比较有序的报表,并针对不同人群有侧重点的提供,让看得人可以明确知道分析结果以及问题的根源在哪里,这是日志易核心的一个东西。另外,我们针对的行业比较多,像金融、运营商以及互联网企业等,这是日志易主要的客户群体,同时我们会针对不同行业的IT运营具体场景,设计更加具体有效的细致产品的分装。

记者:在日志易首页看到“5000+用户、1000+节点、3000k条/秒、100TB总字节”几个数字,这在行业内意味着什么?目前业内同性质企业可以达到多少?

饶琛琳:从数据的角度来说,我们刚也提到很多企业由于系统内部是由很多不同的厂商去支持的,这导致输出的日志数据必然是杂乱无章的,所以这其实有个难点,就是大数据的难点其实不单单只是说在一个体量上,可能我们强调数据大概有几百TB或者说几千TB。但有些人就特别强调体量,可能是好几个PD。但单纯把数据说的那么大,其实并没有特殊的意义。因为我完全可以把一行日志复制上千亿遍,体量也很大,但它没有实际意义。

所以我们希望把这三个数据综合起来看,日志易服务了上千个客户,每个客户可能有上百个供货商,当然肯定不是每个客户的供应商完全不一样,但这也是累积的一个规模。所以在这三个数字中我们更多的是强调它的复杂度,因为面对这么大体量且完全不一样的规模,分析难度确实非常大,这可能就是跟单纯的说体量大不一样的地方。

目前,在做日志分析这一块我觉得日志易还是相当发达的。因为我自己本身在社区、论坛上是比较活跃的人,看到不管是技术方面的爱好者,还是一些新型的厂商,大家还是比较关注两类日志,一类就是访问日志,这个可能大家都了解,另一类就是漏洞型日志,这类型日志的价值也很明确。而对于那些不清楚不明确的东西,其背后所隐藏的价值才是应该真正被挖掘被分析的,而这个价值链目前日志易还是比较擅长的。我们有一个叫做机器算法的运维平台,这个平台强调的意义就是当我把所有的日志都拿在一起了,可以交叉产生出额外价值。

记者:饶总,您之前提到贵公司在华南那边的一个案例,客户总共有600多个系统,方便问一下,在实施这个项目的时候,我们投入总共多少个时间?

饶琛琳:这块其实有一个特别有趣的事情跟大家分享下,日志易现在的产品形态,是非常方便于构建平台工作的后续推进。我们好几个已经接入且自身系统过百的客户,实施时间大概都是一到两个月的时间。前期我们帮他接入十几,二十个系统,后续的结合就他们自己去洞察,因为这个复制性是非常强的,我们把很多的复杂操作完全公开化、产品化以后,我们只需要通过前几个系统,把这个操作流程带着客户过一遍,接下来就是看一遍自己就会的状态,那后续上百个系统的接入就可以客户自己去完成。因我觉得这可能是技术跟产品之间一个比较好的平衡点,怎样把技术产品化?要求就是客户特别容易上手,如果只是说单纯把这个平台安装部署起来,可能两个小时就能搞定,这从平台搭建的效果来说也是非常快的。

在2013年的时候,我还在新浪微博那会儿,日志分析处于刚刚兴起的状态,很多东西是要从零开始搭建,那时候为新浪微博搭建平台,前后整个实施过程花了将近5个月的时间。这是在这门技术刚刚兴起时花费的时间。现在2017年,这三年多时间,随着技术的发展和在这件事上专门投入的人力,当时在新浪,可能就只有我和其他一两个同事,在那个时候,企业内部的运营部门有很多活儿要干,不可能把所有的精力都放在这件事上,像微博这种体量的公司已经到了该投入的时候。现在很多企业,包括他的工作人员,主要精力可能还用于一些更刚需的东西,例如设备部署等。

所以这样的结果就是公司运维进入了一个恶性循环,如果一直把人力投在基础项,那就上不了优化项,上不了优化项就意味着基础项持续薄弱,持续薄弱导致运维人员永远放不出来,这是个恶性循环的情况。

记者:接着这个问题,饶总,这个大体量的数据我觉得也是分行业的,日志易立足金融、能源、运营商行业。对于不同行业来说,存在可能完全不同的日志情况,对此,在提供日志方案时该考虑和解决哪些问题?我们又是怎么做的?

饶琛琳:确实是有不同的,因为这个东西可能更多是区别于不同行业之间的IT建设水平。像金融行业的IT建设水平普遍来说,我觉得在企业里面算是比较高的。在IT基础设施上具备一个比较好的状态,所以他们会把很多精力以及关注点放在业务服务上。所以我们提供给他们的更多是业务系统日志。而对于运营商行业,IT基础设施也是不错的,但他们的业务系统可能与金融行业的差别会大一些。金融业就是跟钱打交道的东西,而运营商的业务其实非常广,像移动、联通的研究院以及具体的互联网业务,类似视频直播等形式非常广泛。日志易会根据不同业务提供不同解决方案,所以以运营商客户为例,由于自身行业性质和业务种类,我们会提供交互的方案,根据他们的业务去交互不同版本。

最后再说能源行业,可能与金融和运营商相比,它们的基础水平稍微弱一些,那我们就会先提高这部分内容,因为当基础没做好的时候,交互所谓的业务服务能力是没有意义的。这个过程就像摞金字塔,你上面的能力非常很高,但是其实对于整体来说可能就进度百分之二三,如果基础扎实,提升百分之二三也是巨大的震动,但是如果基础不牢靠,可能基础部分努努力就会实现10%的效果,这个时候上面的百分之二三可能就没那么有效了。所以对于这些基础建设稍微弱一些的行业企业,我们会让他提高的这种基础建设,因为日志易本身从技术上来说,这个产品是基于数据去提供服务的。

记者:饶总,您刚提到实时的数据分析,企业如果想要把分析速度从十分钟改成一分钟,投入的成本是非常大的,但如果当时我们并不在电脑前,可能在吃饭睡觉,那实时分析的内容可能就错过了,这样的话,您觉得实时分析还有必要吗?是不是有点鸡肋?

饶琛琳:这是个好问题,因为我之前也针对这个问题给出过回答。我觉得这个是需要分场景的,看提速在什么地方。如果是只是把服务器的CPU从30%变成80%,高级模式是10分钟发还是30分钟发,差别确实不大。但是有一些东西的实时响应能力如果不高影响就会比较大。还是以CPU这个例子来说,可能响了一分钟我还在睡,响了五分钟我才能醒过来,开始去处理这个问题,这个时候十分钟和一分钟的差距就体现出来了。因为一个CPU警示本身对于问题的解决是没有意义的,但若是追根溯源,找出到底是什么导致CPU发出了警示,我应该采取什么手段把这个原因解决。单纯追究一个CPU告警是没有意义的,你要去问为什么。有一个“五个为什么”的说法,好像是丰田还是本田提出来的,要不断的去问为什么、为什么,才能问到问题的根本。对CPU告警,要问为什么会告警?可能是服务量大,那为什么服务量会增大?不断的去问,这个过程如果你不讲究实时性,那你的故障可能就真的非常大了。

比如我十分钟收到了一个CPU告急,这十分钟我们可以接受的。那么现在,我问第一个为什么,业务系统目前的处理状态比较糟糕,为什么会糟糕?接下来你可能要去查另一部分数据。如果这个时候依然是十分钟之后得知结果,就意味着得到那个数量结果已经不是10分钟,而是20分钟了。接下来我们再问第二个为什么,又是十分钟,等问了三五个为什么拿到最初问题的结果可能已经是两个小时之后了。对于企业来说,出现故障,除了那种整个挂掉的情况,一般故障十分钟大家可以接受的,但两个小时就是完全不一样的概念。

所以一个CPU告警是一分钟还是十分钟是没区别的,但重点是你拿到一个告警去找问题,进行排查、分析的过程,可能要检索部门关键字、要做一个状态的趋势图,这个分析过程如果很慢的话,体验会很差。而且我刚举的例子还是在思维清晰、逻辑清楚的前提下,把问题解决。

但实际上,有可能你会猜错,有可能再问第一个为什么的时候,得出了一个结果,试验之后发现不对,需要重新返回到第一个为什么;但更多的可能是你可能问了三四个为什么才问对了一个,可能每个问题都需要问好几个为什么,最终才能得到问题的最终根源。而这个过程需要的时间我们需要打一个问号。

所以,实时分析的关键并不在于我们发现告警的时间,而是在得知告警之后故障恢复的时间。故障恢复时间这是一个专业名词,在考量一个运维的水平的时候,一定是要知道这个事情已经OK了,而不是说我知道这个事情就可以了。如果说我十分钟内找到事情,然后我一分钟给你解决,结果依然是很好的,这个系统建设很OK;但如果你一分钟便找到问题,结果花了两个小时才把问题解决,那是不可以的。

记者:了解了,饶总,今年五月日志易推出了1.9.1新版本产品,强化了日志解析、 SPL语言、告警设置等功能。那接下来日志易在产品方面会做出哪些调整?下次更新会是在什么时候?

饶琛琳:我们一般的更新策略是三四个月出一个新版,目标就是一般希望一年都每个月能出一个版权样子。所以1.10版应该在这一两个星期了就会推出来。新版在用户交付上我们做了一个完全的重构,在可视化方面,整个展现也比以前进化了很多,所以我相信无论是对于日志易还是我们的客户来说,都是一个比较不错的消息。

记者:好的,饶总,谢谢您!到这里本期ENI访谈就结束了,感谢大家的收看,我们下期再见。

编辑:赵贤慧
关键字:     大数据  IT运维  日志分析 
活动 直播间  | CIO智行社
姜波鲁花集团CIO

分享到微信 ×

打开微信,点击底部的“发现”,
使用“扫一扫”即可将网页分享至朋友圈。