前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >腾讯业务监控的修炼之路(一)

腾讯业务监控的修炼之路(一)

原创
作者头像
织云平台团队
修改于 2017-10-25 06:44:14
修改于 2017-10-25 06:44:14
9.8K1
举报

作者:李光 ,现任职于腾讯社交网络运营部/织云产品团队,负责织云监控告警平台规划与运维新产品开发工作,具有多年业务运维、运营规划经验。 相关推荐: 腾讯业务监控的修炼之路「二」

欢迎大家在文末扫描作者二维码,反馈日常使用监控告警产品的痛点与具体的场景。这系列文章我会尝试用开放式(类众包)的方式去写,后续会统一评估这些反馈的场景,如果是典型共性场景,或是很小众但却能代表一个特定类型的业务,将会采纳您提供的场景,在后续的文章中会标明提供者的名字,并且附上我的建议场景解决方案,供大家交流与讨论。

概述

本文作为监控告警产品专题系列第一篇文章,涉及的主要内容为监控产品设计的相关基础知识,算是整个系列文章的一个索引。主要内容有:

• 关于监控告警的一些概念

• 立体化监控体系的阐述

老鸟们可以关注后续的文章(文末有三期内容预告,关键词:IAAS, CMDB, 组件监控

业务运维 vs 产品经理

以前做 QQ 业务运维的时候,有一类平台是自己天天会用,那这类平台是什么呢?就是监控告警平台,每天在上面查大量的业务视图、查异常、确认告警、处理告警等等。

对于运维同学来说,如果从使用频率这个维度看,监控告警类平台的使用频率要大于自动化类平台,毕竟自动化类平台多数都是由例行变更触发,而监控告警平台是我们 7X24 小时都要使用的。当时自己名下有较多的业务和几千台机器,那时有过一天收 1000 多条告警的记录,相当崩溃。其实告警如果一天超过几十条就基本是无效的,既关注不过来,也处理不过来。

在业务运维这个角色中,我更多的是从使用者这个视角去看监控。

去年下半年我从业务运维转型为产品经理,现在负责腾讯织云(企业级运维管理平台)监控告警产品线的规划与落地,在产品经理这个阶段我更多的是从建设者这个视角去看监控的。

使用者和建设者这两个视角去看待同一个事物监控告警这个产品,最大的差异点是什么呢?

使用者是点,建设者是面,使用者只关注能服务到自己的功能点,而建设者尽量要更全面的抽象多数使用者所具化的场景,在抽象的基础上在去构建功能,力争满足大部分的使用者场景,解决实际的问题。

“出了任何故障,其他环节都是可能有问题,唯独监控是一定有问题!” —— 乔治·背黑锅**

基于这两种不同的视角与在实际建设途中遇到的各种实际问题,我萌发了写一个监控专题系列的想法,哈哈,脸皮蛮厚的。自己以前都是写单篇的文章,这次也算是一个挑战了。希望通过这个专题能与大家交流下关于一款企业级监控产品是怎么样规划、设计与落地的。

可能是当产品经理习惯了用户场景与角色的分析,如果把这个主题的文章当做一个产品来看,那么其中的角色与场景是什么呢?

• 梳理一下自己在建设织云监控告警产品线的一些经验和思考。

• 对于刚入行对监控告警这个产品还不太熟悉的新业务运维同学。

• 想自己建设监控告警的运维同学或者运营建设同学。

• 正在建设监控告警平台的运维同学或者产品经理。

• 对监控告警产品天天使用的业务运维同学。

因为我现在是织云监控告警产品线的产品经理,而且这部分的产品也在分版本的持续建设中。所以后续主要的产品规划、设计、实现的讲述都是基于织云这个载体上实现。

万丈高楼平地起

本章主要介绍一些关于监控的通用方法论,我们先理清一些基本概念。

• 监控的定义?

• 监控的方式?

• 监控的类型?

• 监控的目标?

• 监控的本质?

• 监控的目的?

• 监控的产品属性?

监控的定义

通过技术手段发现服务异常,持续优化业务可用性与用户体验。这句话的关键词是 发现、持续优化、可用性,体验。

监控的方式

主动:程序内部埋点,服务主动上报自身的运行情况,一般都是具化为业务的各个属性或者指标,这种方式准、快、灵活性好,指标丰富。但是在非标准框架下会有一定的代码改造成本。

被动:无需埋点,从外部探测或获取服务的运行情况,例如ping探测、日志采集分析等等。

旁路:与程序逻辑无关,对服务质量与口碑的监控,例如舆情分析。

那么这三类有优劣之分吗?其实没有,这里的方式都是针对于不同场景的,例如对域名的监控,就可以通过该域名的外部拨测来达到监控的目标,域名的访问耗时也可以通过不同的拨测点来监控。在腾讯内部,QQ和Qzone两个海量业务对这三类监控都应用到了。

监控的类型

从大的对象范畴与层级关系来说,监控一般分为五种类型:

基础监控:这里的基础监控囊括范围比较广,主要指IAAS层(服务器、系统、网络等)

服务端监控:一般指后台服务,例如QQ的后台消息服务。

客户端监控:一般指app,手Q的客户端与微信的客户端。

WEB监控:一般指网站,例如对网站域名的拨测。

用户端监控:一般指用户舆情监控,例如某个APP的口碑好坏。

监控的目标

一个好的监控体系应该要达到以下三点目标:

全:监控对象的广度,监控点的覆盖率,例如上文提到的五种对象类型是否都能覆盖到

快:监控的性能,数据流的处理能力

准:智能分析与收敛、监控对象收拢

监控的本质

DevOps 中,运维、开发、测试这三个角色应该视角统一,这里为什么说要视角统一,就是大家在监控这个层面关注的点应该是一致的,而不是你关注你的点,我关注我的点。

例如所有的业务监控都可以抽象出三个核心指标:请求量、成功率、耗时。这三个关键指标来判断我们服务的可靠性,通过可靠性可以推算出可用性,并且可以间接反映用户使用我们产品的的体验。例如,如果服务的可靠性不好,那么用户的产品体验肯定不会好。

监控的目的

通过对上文的一些概念介绍,其实我们已经可以推导出应用监控告警的目的,就是持续优化业务服务质量,并建设质量体系。同样织云监控也是为了打造质量体系的闭环路径。

监控告警的产品属性

监控告警是一款数据类属性的产品,既然是数据类产品,那么在产品设计的时候一定要注意这样的路径闭环 数据生产数据增值数据消费,围绕着这样的路径我们就可以勾勒出很多的用户故事,用户故事就是针对具体的角色,会有什么具体的活动,以及这个活动所产生的价值。

这里举个简单的例子来说明数据生产与数据消费。随着后面详细的讲述产品建设过程中会更加详细的阐述这个闭环的路径。

数据生产:例如一台服务器上报的各种基本的 OS 指标数据,如 CPU 使用率,内存使用量等。这就产生了若干待消费的原始数据,那么我们能用这些数据干什么呢?

数据消费:对这些上报的原始数据整理可以用作视图展示,例如图形化展示该服务在最近一个小时的 CPU 使用率。 又或者对这些原始数据设定阈值,当超过某个阈值的时候,就产生告警通知。这些都是最直接的消费的场景。

我们再延伸一步对于这些消费场景产生的告警数据,是否可以再进一步消费呢?答案是可以的,例如对若干承载 CPU 计算型业务的服务器所产生的 CPU 使用率告警(生产)时间进行分析统计(消费),是不是可以基本推导出该业务的服务高峰期是大概在那个时间范围呢?

这里想说明的是多数原子数据并无单一的消费或者生产的属性,而是要取决于在具体的场景与所处的数据链条中的角色。

并且监控告警的数据加上特定的流程(ITSM)也可以驱动监控告警+自动化的大的业务逻辑交互闭环,这个场景容我先卖个关子,后面的叙述会再次提及到这部分。

监控体系

体系,泛指一定范围内或同类的事物按照一定的秩序和内部联系组合而成的整体,是不同系统组成的系统。其实这个描述是有些抽象的,咱们用大白话套用监控体系来解读下。

对于一个有一定体量的公司,需要一些不同的监控系统,通过系统与系统间的内部交互来组成一个大的整体,从而完成对不同场景下的监控需求即监控体系。用我们内部来举例,我们内部在现网上跑的监控系统也有快10套了,同样在构建体系时关键的部分也是要用动态的视角去看待这些系统所产生的数据,而不是每个系统都是一个孤立的数据孤岛。下图是织云整体的监控体系。

在织云监控告警产品建设过程中,我们融入了很多关于海量运维的监控思考与经验沉淀。

这里的监控体系是和公司体量大小有直接关系的,但是一般来说在这个体系中,应该有三类监控系统是必备的。

总结

通过上文的简单介绍,相信大家对监控告警会有个初步的宏观认识,随着后续文章的铺开,大家会逐步了解到一个企业级的监控产品是怎样从 0 到 1 演化而来的。同时下篇文章就会进入到实战阶段。 建设监控告警是一条持续且漫长的路也是蛮复杂的,坑也很多,但还是有一些基本的方法论和规律可以遵循。

监控告警产品专题内容预告(【腾讯织云】ID:TencentCOC 将连载推送,欢迎关注):

• IAAS层监控(服务器性能、网络设备、网络流量分析)等如何设计与实现?

• 一个企业级监控告警产品需要设计怎样的 CMDB?(在云化时代 CMDB 所扮演的角色越来越核心,我以前也设计过织云的 CMDB)

• 平台级的监控产品如何更好地支撑五花八门且业务形态差别很大的组件监控?

欢迎大家扫码反馈添加时请注明“姓名-公司名称-工作岗位

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
1 条评论
热度
最新
怎么感觉这里介绍的业务监控更像是应用服务监控呢?比如说的核心指标:请求量、成功率、耗时,这个更像是应用的指标
怎么感觉这里介绍的业务监控更像是应用服务监控呢?比如说的核心指标:请求量、成功率、耗时,这个更像是应用的指标
回复回复点赞举报
推荐阅读
编辑精选文章
换一批
腾讯业务监控的修炼之路「二」
织云平台团队
2017/10/25
3.7K0
腾讯业务监控的修炼之路「二」
嘉为蓝鲸张敏:运维体系为什么要基于平台化建设
涉及关键词:一体化运维、平台化运维、数智化运维、运维PaaS、运维架构治理、蓝鲸等。
嘉为蓝鲸
2024/01/30
1.1K0
嘉为蓝鲸张敏:运维体系为什么要基于平台化建设
少年,你的告警量可以更少些!
作者简介:梁定安,腾讯织云负责人,目前就职于腾讯社交网络运营部,开放运维联盟委员,腾讯云布道师,腾讯课堂运维讲师,EXIN DevOps Master讲师,凤凰项目沙盘教练,复旦大学客座讲师。* 请原
织云平台团队
2017/05/15
4.9K0
少年,你的告警量可以更少些!
嘉为蓝鲸张敏:构建多维一体的运维体系
运维一体化是近几年被广泛提起的概念,有各种解读和实践形态,在到具体的技术架构和管理实践前,我们还是要对一体化有几个基本定义,这样才能更为严肃地探讨运维一体化的本质。
嘉为蓝鲸
2024/01/25
1.8K0
嘉为蓝鲸张敏:构建多维一体的运维体系
运维管理一体化:构建多维一体化的运维体系
涉及关键词:一体化运维、平台化运维、数智化运维、运维PaaS、运维工具系统、蓝鲸等。
腾讯蓝鲸助手
2024/07/03
2K0
BizDevOps全局建设思路:横向串联,纵向深化
IT技术交付实践方法在不断迭代中持续优化。在工业化时代,Biz(业务)、Dev(开发)、Ops(运维)三者往往相对分离,甚至有时只有其中的两者或仅有一者独立存在。然而,随着时代的演进,互联网化时代带来了敏捷的先进思想,推动了业务与技术的初步融合。DevOps等理念则进一步促进了开发与运维的深度融合,打破了组织壁垒,提升了团队协作效率。如今,在数字化时代,我们更加注重以业务为中心,实施精益化、平台化、一体化的管理模式,以更好地满足业务需求。业务与技术之间的链接一步步紧密,这是业务竞争与技术发展之间的双向奔赴。BizDevOps也应运而生。
嘉为蓝鲸
2024/04/19
3360
BizDevOps全局建设思路:横向串联,纵向深化
青铜到王者:AIOps 平台在腾讯的升级之路
在海量运营方法论的指导下,运维团队构建了体系化的运维能力,为众多产品保驾护航。
织云平台团队
2018/03/28
6K1
青铜到王者:AIOps 平台在腾讯的升级之路
LLMOps+DeepSeek:大模型升级一体化运维
蛇年伊始,DeepSeek凭借其卓越表现火爆出圈,让AI大模型瞬间成为街头巷尾热议的焦点,也让大众重新燃起对AGI(通用人工智能)“平民化”的信心,DeepSeek通过先进的模型架构,带来的高效率与低成本优势,加快了应用场景的百花齐放。
嘉为蓝鲸
2025/02/21
8050
LLMOps+DeepSeek:大模型升级一体化运维
风险感知场景(一)之“监控、拨测、巡检、可观测性”
从发现风险角度,我们经常会从监控、拨测、巡检、可观测性、演练、混沌工程等角度发现风险。上周和必示的温博后聊了一下风险感知,今天理理思路,摘“监控、拨测、巡检、可观测性”4点做个简述,再看看风险感知场景的切入点。
彭华盛
2022/11/16
3.7K1
风险感知场景(一)之“监控、拨测、巡检、可观测性”
【深度好文】如何基于谷歌SRE理论,建设企业IT应用系统稳定性能力?
在当今数字化转型步伐不断加快的时代,IT应用系统的稳定运行成为了企业的业务正常运转的重要基础,因此,运维管理体系的构建也从围绕着数据中心转向围绕着应用系统方向,首个专门面向应用运维的理论体系——SRE,由Google发布后,受到了越来越多的企业的青睐,很多国内企业已经纷纷效仿Google建立SRE团队,旨在为各个业务应用系统提供更好的稳定性保障能力,为业务保驾护航。
嘉为蓝鲸
2021/09/06
1.9K0
【深度好文】如何基于谷歌SRE理论,建设企业IT应用系统稳定性能力?
【四川农信】主力军银行里的智慧运维力量-嘉为案例
四川省农村信用社联合社(以下简称“四川农信”)诞生于1951年,紧盯打造“农村金融主力军、地方金融主力军、普惠金融主力军”目标愿景,全面推进合规银行、智慧银行、主力军银行建设。至2021年12月底,四川农信有5131个营业网点,近4万名从业人员,资产规模达1.8万亿元,各项存款1.5万亿元,各项贷款8775亿元,资产规模、存款规模位居全省同业第一位、全国农信系统第七位。
嘉为蓝鲸
2023/01/17
6930
【四川农信】主力军银行里的智慧运维力量-嘉为案例
AI 时代下腾讯的海量业务智能监控实践
作者丨李春晓:腾讯高级工程师,目前为腾讯SNG社交网络运营部社交平台业务运维组员工。 海量业务的挑战 互联网业务讲究“极致、口碑、快”,经历过长时间的演进,腾讯SNG社交平台产品用户访问量已经达到亿级、十亿级, 我们的业务监控、业务分析等数据也显示:业务前、后端成功率都已经达到99%, 99.9%以上。 但随之带来的挑战也是显而易见的,例如: 1.长时间历史的发展,导致后端架构复杂,功能模块众多、监控系统多、告警量大,如何简化,让告警简单、有效? 2.关键业务成功率, 0.01%的指标告警都可能引起成千、上
企鹅号小编
2018/02/07
5.2K0
AI 时代下腾讯的海量业务智能监控实践
CMDB数据治理-从治理策略到工具落地
小魏是某银行配置经理,这天,银行部门年度会议上,运维领导突然说:“CMDB是我们整个自动化运维平台的基础,必须发挥好他主数据的价值,让大家尽可能都感受到他的价值,注意一定不能因为数据质量的问题导致大家不愿意用!”
嘉为蓝鲸
2023/02/22
1.1K0
CMDB数据治理-从治理策略到工具落地
日进斗金的银行业务保障,靠这样的运维服务!
本文介绍了如何通过自动化运维平台实现IaaS层资源的统一管理,并针对金融云场景提供了详细的解决方案。
织云平台团队
2017/09/22
1.7K0
日进斗金的银行业务保障,靠这样的运维服务!
未雨绸缪,业务连续性保障法宝——基于SRE理论的业务体系建设
作为近年热词的SRE自被提出以来,引起了各方的关注和思考。随着技术的迭代,在基础运维、云计算运维的基础上,SRE工程师更多地关注工具化、流程化的建设,更进而地去思考平台化,体系化,全面化的技术栈设计。在业务侧的推动下,企业对敏态效率和稳态安全的全面关注;对保障稳定和质量同时控制成本、提升价值和效率等多方面的需求都对SRE在企业的内部落地提出了更高和更针对性的要求。
嘉为蓝鲸
2021/11/30
1.1K0
未雨绸缪,业务连续性保障法宝——基于SRE理论的业务体系建设
详解华夏银行iDo平台一体化运维的落地过程
随着数字化转型的深入,基于中台和PaaS架构的一体化运维建设也在各行各业快速展开,但是如何将运维平台本身的能力与企业已有的工具能力进行中台化整合、工具场景如何联动,是个复杂而庞大的工程。
嘉为蓝鲸
2022/11/24
2.1K0
详解华夏银行iDo平台一体化运维的落地过程
鹏华基金研运一体化平台落地实践,探索数字化转型
5月16日,蓝鲸行业说直播专栏又迎来新一期的更新,第八期带来金融基金行业的研运一体化落地实践分享。
嘉为蓝鲸
2024/06/11
2370
鹏华基金研运一体化平台落地实践,探索数字化转型
这样的CMDB设计,居然阻止了海量告警对运维的轰炸
梁定安(大梁),运维技术总监,复旦大学客座 DevOps讲师。多年运维、运营开发和 DevOps 的工作经验,曾负责 Qzone、相册等 SNG 社交平台类业务的运维规划与管理,经历了 SNG 运维标准化、自动化、智能化建设的全程。腾讯织云负责人。 1 标题党一回!本文主要介绍运维 CMDB 的设计思路,恰当的 CMDB 设计,对运维效率的提升,如收敛告警和故障自愈等,有着意想不到的效果。 在运维自动化平台的设计理念中,我们一直提倡“减少运维对象”,并将运维对象进行抽象化、模型化、配置化的录入 CMDB 中
织云平台团队
2018/06/19
1.6K0
vivo 服务端监控体系建设实践
经过几年的平台建设,vivo监控平台产品矩阵日趋完善,在vivo终端庞大的用户群体下,承载业务运行的服务数量众多,监控服务体系是业务可用性保障的重要一环,监控产品全场景覆盖生产环境各个环节。从事前发现,事中告警、定位、恢复,事后复盘总结,监控服务平台都提供了丰富的工具包。从以前的水平拆分,按场景建设,到后来的垂直划分,整合统一,降低平台割裂感。同时从可观测性、AIOps、云原生等方向,监控平台也进行了建设实践。未来vivo监控平台将会向着全场景、一站式、全链路、智能化方向不断探索前行。
2020labs小助手
2023/01/03
1.2K0
腾讯海量监控体系经验分享
提及腾讯的海量监控的挑战,将近 20 套监控系统,指标有将近 300 多个,监控的实例超过 900 万。
腾讯大讲堂
2018/01/18
3.4K0
腾讯海量监控体系经验分享
推荐阅读
相关推荐
腾讯业务监控的修炼之路「二」
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档