社区编辑申请
注册/登录
干了两年运维,为何我毫不犹豫转了开发岗?
运维 新闻
​根据多年和运维打交道的经历,我发现,运维常常让监控变得无效……

我的监控故事

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

1、有用的监控 

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

图片

记得那会公司还是用Nagios(估计新人已经没多少人知道了),不过监控的维护工作着实费劲。后面我就开始研究zabbix,最大的好处就是它可以discovery&自动添加监控。后面我又搭了一套ELK,把业务日志都收集到一起,监控就齐活了。 

图片

由于没有添加太多告警,那会的每个告警基本都得处理,最常见的问题就是百度来爬数据,我有一套屡试不爽的处理流程: 

  • 看指标:如果是xx业务的负载高, 有90%的概率是爬虫导致的。
  • 看日志:在kibana上看访问记录,找出topx的IP段。
  • 封访问:用iptables封掉。

这就是我唯一一段的运维监控经历。由于业务简单、监控原始反而让我感觉告警是有用的。 

2、无用的仪表盘 

1)疯狂自动化 

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

图片

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

2)好看而没用的仪表盘 

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

图片

为了方便研发查看日志,运维也搞了ELK,将各种日志全部收集进去,然后将kibana丢给了业务研发。结果也可想而知,除了少数几个爱折腾的,kibana上的dashboard也没有太多人看。 

我一直相信运维的初衷都是好的,但从结果上来看,嗨的只有运维,毕竟运维很少看自己做的仪表盘……

3、没有质变 

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

图片

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

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

对监控的偏见

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

  • 一直试图通过归纳过去发生的单个问题,来预测未来可能发生的普遍问题,并忽略未来在时空上复杂的变化。

  • 一直专注于优化传统的探针模型(使用脚本测试,检查恢复并且报警)、图形化趋势展示、报警模型, 并不断提升相关流程的自动化。

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

1、人工智能还是人机交互 

喝着咖啡做运维。

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

图片

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

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

图片

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

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

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

2、监控要专注能力建设

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

图片

我认为产生这种分层的主要原因是:组织架构(康威定律)和职责分离。在这种分层下,运维通常就只负责下面两层,对于上层问题的处理,可能定位到某个具体的URL就结束了,剩下的就是研发的事情了。 

如果要解决当前这个困境,我认为应该摒弃过去按照职责进行系统建设的方式,比如做个基础监控系统、网络监控系统、业务监控系统,而是转向围绕业务价值分阶段进行能力建设,比如基础的数据采集、传输、分析、存储、展示等能力。转型成为提供海量数据收集和中央化规则计算、统一分析和报警能力的现代化监控系统【google sre】

图片

在能力建设过程中,平台团队应该以真实需求为目标,搭建最小可用平台(Thinnesr Viable Platform, TVP),并在团队中分享最佳实践和主动赋能用户,逐步成就卓越用户。同时要避免分享的都是没落地的方法论,毕竟大家都很忙。 

图片

3、尝试变得有效 

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

图片

不过这事真的有意义嘛?对于这种基础的数据的采集、分析和存储其实已经有很多商业化的方案,为什么会觉得自己几个人的小团队,配合一堆开源软件,可以做的比一个几十人的专业团队做的更好呢,而且这事离业务那么远,除了能让自己的kpi更好看,可能也并没有带来什么别的改变。 

随着造的轮子越多,也慢慢发现自己变得越无效,一直在基础问题上徘徊。通常越基础的问题,解决方案也越通用,同时解决这类问题的ROI也越低,所做的工作也越无效。也不要过分强调自己场景的特殊性,除非只是想搞一些虚荣指标,而不解决本质问题。 

那什么是有效的呢?我认为核心就是: 

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

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

展望

图片

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

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

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

2)数据收集全面开花 

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

3)新瓶装旧酒 

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

传统监控已死,可观测性已来。我的监控故事就到这里,可以在评论里聊聊你的故事。​

责任编辑:张燕妮 来源: dbaplus社群
相关推荐

2014-09-12 15:14:53

运维开发

2022-05-09 15:01:51

运维转型技术

2019-02-19 09:14:52

IT运维系统

2013-03-29 09:15:08

2020-07-15 08:07:51

运维管理技术

2018-01-17 17:02:08

运维工程师面试经历试题

2020-12-08 15:02:15

运维计算机IT

2014-04-14 10:21:15

开发运维DevOps

2020-07-17 07:46:04

运维开发技术

2018-10-15 14:26:23

2016-05-17 14:51:15

移动·开发技术周刊

2018-04-27 14:06:00

2021-03-04 10:20:41

运维工程师互联网

2018-11-15 09:08:34

2018-02-07 09:41:11

2019-06-28 11:09:41

运维Linux工程师

2015-08-10 13:32:43

运维公有云自动化运维

2011-08-04 13:24:28

IT运维

2015-08-04 17:29:01

2019-10-29 16:29:28

运维架构开发

同话题下的热门内容

大意了!平常不重视慢SQL,搞得现在系统要重构……揭秘运维工程师职业生涯天花板 SRE (Site Reliability Engineering) 的工作职责Sentry日志监控系统基本介绍及部署使用基于 Flink 构建大规模实时风控系统在阿里巴巴的落地

编辑推荐

官方自爆了!去年今天的B站原来是这样崩溃的……日志系统成本飙升千万,吓得我赶紧把ES换成ClickHouse……不做运维大冤种!锐捷乐享智能运维管理平台提供新解运维大牛万字自述:道尽十多年血泪史与转型自救路自从上了 Prometheus 监控,睡觉真“香”
我收藏的内容
点赞
收藏

51CTO技术栈公众号