运维,放过监控-也放过自己吧

根据多年和运维打交道的经历,我发现,运维常常让监控变得无效。。。 

1.我的监控故事 
我做过两年多的运维工作,后面就转做运维平台开发了,也一步步看着监控系统越来越没用。 

1.1 有用的监控 
当我做运维要负责oncall时,我一直认为监控系统做的还可以,并不是因为做了太多事情,而是因为运维的业务还是单体应用,也没有太多的监控需要加。 

记得那会公司还是用Nagios(估计新人已经没多少人知道了),不过监控的维护工作着实费劲。后面我就开始研究zabbix,最大的好处就是它可以discovery&自动添加监控。后面我又搭了一套ELK,把业务日志都收集到一起,监控就齐活了。 由于没有添加太多告警,那会的每个告警基本都得处理,最常见的问题就是百度来爬数据,我有一套屡试不爽的处理流程: 1.看指标:如果是xx业务的负载高, 有90%的概率是爬虫导致的 2.看日志:在kibana上看访问记录,找出topx的IP段 3.封访问:用iptables封掉 
这就是我唯一一段的运维监控经历。由于业务简单、监控原始反而让我感觉告警是有用的。 

1.2 无用的仪表盘 
1.2.1 疯狂自动化 
当我转运维开发后,我发现运维对监控的需求也变了。因为自动化能力的提升,各种开源的监控系统逐步完善,运维就开始在平台里面拼命的加各种自动化的需求,对于监控系统就是自动的给业务绑定各种监控模板、告警模板、grafana仪表盘 

结果也可想而知,由于告警实在太多,运维直接屏蔽了公司的告警短信。大部分情况下都是靠业务侧发现问题,运维再介入排查。 

1.2.2 好看而没用的仪表盘 
由于收集的指标数据实在太多,为了可以给业务侧输出,运维就搞起了grafana仪表盘。不过由于grafana仪表盘上的指标实在太多,页面还会经常卡住,业务研发看着一个页面上几十个指标,也不知道哪个有用,最终还是得来找运维。 

运维,放过监控-也放过自己吧_第1张图片

 

为了方便研发查看日志,运维也搞了ELK,将各种日志全部收集进去,然后将kibana丢给了业务研发。结果也可想而知,除了少数几个爱折腾的,kibana上的dashboard也没有太多人看。 
我一直相信运维的初衷都是好的,但从结果上来看,嗨的只有运维,毕竟运维很少看自己做的仪表盘。。 

1.3 没有质变 
随着google sre概念的兴起,运维似乎是找到了最后一根稻草,毕竟这是google的运维方法论。于是,运维又开始同研发制定各种SLO、SLI指标,依据4个黄金指标(延迟、流量、错误和饱和度)来继续自丰富自己的告警库,并制定P0、P1、P2等各种告警分级,试图改变当前困境。 

运维,放过监控-也放过自己吧_第2张图片

 

但是由于业务架构微服务化,并且采用敏捷开发的模式,实际上业务的迭代速度非常快。大部分sre本身并不是做开发出身,同时严重的配比不足(研发和运维比例),导致各种指标随着时间快速失效。其结果就是告警依旧没用,每次复盘就是再加一条告警,当然这条告警也几乎不会被触发。 

这就是我经历的监控故事,你有哪些故事呢? 

2.对监控的偏见 
在对这些失败的监控经验的总结过程中,我发现两个本质的问题: 

一直试图通过归纳过去发生的单个问题,来预测未来可能发生的普遍问题,并忽略未来在时空上复杂的变化一直专注于优化传统的探针模型(使用脚本测试,检查恢复并且报警)、图形化趋势展示、报警模型, 并不断提升相关流程的自动化

上述问题只代表我当前对监控的认知,并不知道对错,也没有答案。下面则是我对监控系统当前建设的一些偏见。

2.1 人工智能还是人机交互 
喝着咖啡做运维 

前同事令我印象最深刻的就是这句话了。说完这句话的半年后,他就开始研究AIOPS了,又过了半年他就离职了,组里也再没人提AIOPS了。大部分运维对AIOPS最大的需求可能就是根因分析了,不过这就像是一座大山立在AIOPS的门外,大部分运维团队连爬的勇气也没有。 

我一直没想明白一个问题: 

运维自己都不一定能排查出问题原因,为什么会指望机器能实现这个事情。 

人和机器相比,机器更擅长于做海量数据的分析,而人则更擅长做决策。所以相比aiops我认为人机交互可能更靠谱一些: 

机器对海量数据进行全面分析,由运维对分析结果进行人脑决策 

不过感觉这事也并不容易,因为现在的sre痴迷开发的程度已经顾不上做这些事情了。决策本身也需要对数据有一定的敏感性。

2.2 监控要专注能力建设 
在过去的监控系统建设中,大家一般喜欢按照架构做垂直切分,可能长这个样子: 

运维,放过监控-也放过自己吧_第3张图片

 

我认为产生这种分层的主要原因是:组织架构(康威定律)和职责分离。在这种分层下,运维通常就只负责下面两层,对于上层问题的处理,可能定位到某个具体的URL就结束了,剩下的就是研发的事情了。 
如果要解决当前这个困境,我认为应该摒弃过去按照职责进行系统建设的方式,比如做个基础监控系统、网络监控系统、业务监控系统,而是转向围绕业务价值分阶段进行能力建设,比如基础的数据采集、传输、分析、存储、展示等能力。转型成为提供海量数据收集和中央化规则计算、统一分析和报警能力的现代化监控系统【google sre】在能力建设过程中,平台团队应该以真实需求为目标,搭建最小可用平台(Thinnesr Viable Platform, TVP),并在团队中分享最佳实践和主动赋能用户,逐步成就卓越用户。同时要避免分享的都是没落地的方法论,毕竟大家都很忙。 

2.3 尝试变的有效 
当处理问题时,就会发现公司的监控系统比知道的多,运维、研发、DBA、redis等每个部门都有自己的监控系统和仪表盘,出问题时,每个人看的都是自己部门搞的监控。为了能够建立统一的视角,有能力的公司又会倒腾出统一监控这种东西:从不同的系统里面获取各种数据,统一进行汇总分析存储,最终统一监控又会带来数据实时性、准确性、存储成本、海量数据处理等新的问题,而且这事一时半会也搞不定。 

运维,放过监控-也放过自己吧_第4张图片

 

不过这事真的有意义嘛?对于这种基础的数据的采集、分析和存储其实已经有很多商业化的方案,为什么会觉得自己几个人的小团队,配合一堆开源软件,可以做的比一个几十人的专业团队做的更好呢,而且这事离业务那么远,除了能让自己的kpi更好看,可能也并没有带来什么别的改变。 
随着造的轮子越多,也慢慢发现自己变的越无效,一直在基础问题上徘徊。通常越基础的问题,解决方案也越通用,同时解决这类问题的ROI也越低,所做的工作也越无效。也不要过分强调自己场景的特殊性,除非只是想搞一些虚荣指标,而不解决本质问题。 那什么是有效的呢?我认为核心就是: 

关注用户、关注业务,放弃过去通过经验的归纳来解决普遍问题,尝试利用数据分析的人机交互聚焦于核心业务,并通过AI/自动化处理支撑业务和通用业务 

不过这事很难,好在我不做监控。。。

3.展望 

运维,放过监控-也放过自己吧_第5张图片
去年有一个跟监控相关的很火的方向:可观测性。我对可观测性并没有太多的实践,不过在跟朋友聊可观测性时发现一些问题,这里更多的是想写下自己的困惑: 

 

1.可观测性解决什么问题 

每当聊可观测性时,我就发现大家一致认为可观测性可以解决所有的问题,就好比一把屠龙刀,所过之处寸草不生。可你要是详细问问用可观测性做了什么的时候,就会有点时光倒流的感觉,又回到各种仪表盘,满屏指标的时代。你有可观测性的故事嘛? 

2.数据收集全面开花 

可观测性技术发展速度感觉非常快,相关开源项目也越来越多,不过在数据收集上有个令我诧异的问题:有一天别人跟我说,可以在生产环境收集profiling做可观测性定位业务代码问题。诧异的点并不是技术实现,而是在于什么样的业务需要这种级别的可观测性,这种可观测性面向的用户又是谁,要解决的问题是什么?你有答案嘛?

3.新瓶装旧酒 

如果你跟同事介绍可观测性由metric、log、tracing三部分组成的时候,很容易被老运维diss,他会告诉你我们现在都已经有了,只是不太好用,丰富下就可以了,这没什么新技术,不过是新瓶装旧酒而已。这时候我通常就会提出google之前发的关于<<有意义的可用性>>里面提到的问题,如何衡量用户级别的有意义的可用性,虽然我也没有答案,不过我只想启发下对问题的思考。你是怎么理解这个问题的呢? 

小伙伴们有兴趣想了解内容和更多相关学习资料的请点赞收藏+评论转发+关注我,后面会有很多干货。我有一些面试题、架构、设计类资料可以说是程序员面试必备!所有资料都整理到网盘了,需要的话欢迎下载!私信我回复【666】即可免费获取
运维,放过监控-也放过自己吧_第6张图片

 

你可能感兴趣的:(运维,java,经验分享,面试,spring,boot)