乔新亮的 CTO 成长复盘
乔新亮
彩食鲜副总裁兼 CTO、前苏宁科技集团副总裁、TGO 鲲鹏会荣誉导师
24236 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 29 讲
开篇词 (1讲)
结束语 (1讲)
编辑手记 (1讲)
乔新亮的 CTO 成长复盘
15
15
1.0x
00:00/00:00
登录|注册

24 | 监控设计,让一切都有迹可循,尽在掌控

数据库索引变动
问题定位困难
控制手段不足
根因分析耗时
故障恢复时间延长
问题根源
问题定位困难
CPU负载突然飙升
管理者的监控设置
关注过程和结果
研发管理和团队管理
监控的目的和手段
运营效率和质量
数据化管理
业务监控
回退至稳定版本
限制调试问题
寻找变化而非bug
简单、粗暴、实用
控制变化
系统恢复
根因分析
确认系统健康
发现问题
问题分析
怪现象
控制
监视
保持系统健康状态
快速做出相应动作
及时发现系统问题
结语
企业监控
生产环境问题处理
流控和版本回退
故障恢复流程
案例分析
监控手段
监控目的
监控设计

该思维导图由 AI 生成,仅供参考

你好,我是乔新亮。
这一讲,我想和你聊聊如何做好监控设计。
你可能会想,为什么要聊监控呢?做监控不是很简单吗?
所有做技术的同学,基本都会根据公司的日志规范,在代码中打印 Log ,以记录告警和报错。许多企业,也会将日志收集分析,以此形成对系统状态的监控。如果条件允许,团队还可以使用各类免费或付费的服务器监控报警服务,多方便啊,这有啥好讲的呢?
其实在我眼里,这些都只是构成了监控的一部分,并非完整的监控体系。要想深刻理解监控的概念,我们首先要学会问自己:为什么要做监控系统?这就像许多工作方法论里强调的一样,做事先问目的 —— “start with why”。
监控的目标是及时发现系统的问题,并尽可能快地做出相应的动作,让系统一直处于健康的状态。监控,可以拆分为“监”和“控”分别理解,其含义恰好对应着两种主要手段,也就是“监视”和“控制”(中文真是博大精深)。
比如说,生产环境出现了个 bug,怎样定位问题?这需要做好“监视”;发现问题根源后如何正确响应?这需要做好“控制”。
比较无奈的情况是,研发人员知道系统出了问题,但无法定位问题;更悲催的情况是,研发人员能够定位问题,但无法控制问题,只能眼睁睁地看着故障发生。但无论哪种情况发生了,从结果来看,其实区别都不大。唯一的区别可能是,前者至少让人心存希望,后者则让人感觉整颗心都“冰凉冰凉”的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

监控设计是企业生产环境系统中至关重要的一环。本文通过实际案例深入探讨了监控设计的重要性和挑战。作者强调了监控的目标是及时发现系统问题并采取相应措施,以保持系统的健康状态。文章指出监控不仅仅是数据的收集和分析,还需要对系统进行监视和控制,并对问题做出正确响应。此外,文章还提出了简化故障恢复流程的方法,并强调了对企业系统和业务的监控重要性。通过生动的案例和深入的思考,本文向读者展示了监控设计的复杂性和重要性,提醒读者在实际工作中要重视监控设计,不仅要有监控系统,更要有正确的认知和应对策略。文章最后还对研发管理和团队管理中的监控提出了思考,为技术人员和管理者提供了有益的思考和指导。通过对监控设计的深入探讨,本文为读者呈现了监控设计的复杂性和重要性,为技术人员提供了有益的思考和指导。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《乔新亮的 CTO 成长复盘》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(23)

  • 最新
  • 精选
  • 术子米德
    🤔☕️🤔☕️🤔 有个小困惑,生产系统,有人加个索引,这个操作本生没有被监控和日志下来么? 按理说,生产系统的任何改动,都是要被监控和日志,这本该是生产系统监控最基础的工作,否则就像案例中的样子,问了半天都不知道系统已经被修改了,这不是有点搞笑么?

    作者回复: 你好,术子米德 你提的这个问题特别对,这其实也是写这篇文章的初衷。对于发布要进行监控,是这样的。这个也有监控,在发布平台也有,但是对应的DBA的忽略掉了它。这就是认知太重要的原因,大家还是要去寻找bug的思路,而不是寻找变化的思路。而大脑很神奇,就彻底忽略了它。 而当时又是下班后的时间,大家也没有去发布平台看,就相信了当事人。 很多问题事后回顾都是这样,哭笑不得,生产的问题大概如此,这也是这么多年看生产问题得出的结论。所以才总结出不是寻找bug,而不是寻找变化的恢复思路,这个认知特别重要,其实今天很多企业,也没有得出这个认知,你想想是不是?

    2020-12-20
    3
    17
  • yshan
    笔记整理: 1、监控的目标是及时发现系统的问题,并尽可能快地做出相应的动作,让系统一直处于健康的状态。监控,可以拆分为“监”和“控”分别理解,其含义恰好对应着两种主要手段,也就是“监视”和“控制”。 2、监控是为了让系统一直处于健康状态,具体的手段包括“监视”和“控制”两种。 3、生产环境出现问题,原因通常只有两个字:变化 4、变化:①外部用户请求量增大;②产品发布,一般包括代码发布、配置发布、SQL 脚本发布等; ③依赖资源变化,一般是计算、存储、网络基础设施情况变差,比如磁盘存在坏道等。 5、流控和版本回退。流控,就是做好程序的并发流量控制;版本回退,就是在生产环境的发布出现问题时,及时回退到上一个版本。 6、只要我们控制住了服务的近期变化,也就等于控制住了故障 7、生产环境是不允许查找 bug 的。在生产环境,研发人员应该寻找并消灭“变化”。从寻找 bug 到寻找变化,是一个非常大的认知转变。 8、生产环境永远不允许调试问题,出现问题立刻回退,查问题要去测试环境。 9、大版本立项,小版本上线 —— 梳理好各模块的依赖关系,将各个系统、各个服务独立发布。当然,这也需要依赖服务版本化和 CI 能力的支持。 10、监控的目的是让系统一直处于健康状态,具体手段则可分为“监视”和“控制”两种;要做好控制,一个重要的方法是做好流控和版本回退。因为在大部分情况下,消除变化就等于消除异常。

    作者回复: 你好,yshan 总结的真全面,真棒

    2020-12-18
    2
    14
  • Weehua
    学习了这篇文章,真的感同身受。我们的研发过程中,线上遇到问题几乎大部分都是变更引起的故障,所以第一时间回滚是强行要求,先止血,恢复业务,然后复盘分析,修复解决问题。监控,监是比较容易的,控反而是困难的,怎么让系统在遇到问题的时候快速恢复才是核心。当然,能及时发现问题也是很重要的。

    作者回复: 你好,Weehua 简单的办法但最管用,因为符合本质。

    2020-12-21
    3
  • Tony.xu
    乔总,您好!本节的方式&方法都很OK,很多大的公司也是在这么做的。听了这个索引的案例,我有一些补充的思考,分享一下。 1)全局性回退问题:不光是代码还有脚本这个不管是之前的普通运维方式还是DEVOPS都是应该严格准守的。 ​ 理论上来说应对这种方式的操作应该在每次上线前,确定好应急回退版本和对应回退脚本,做到一键回退。因为在回退问题指望团队 人员的回忆肯定是不靠谱的,建立应急回退制度,不但能提升团队专业度,也可以提升问题的解决效能。 ​ 其次,一定要杜绝不按照预定版本回退,也就是做到统一版本回退。如果在一个版本上线后,有一些零星更改,应该在之前的回退版本中加入补充,最好做到能够根据修改管控到既能逐级回退,也能全局回退到上一个大版本。 ​ 比如1.0--》1.01--》1.02--》2.0 (即便1.01中只是加了个索引), ​ 回退方式2.0--》1.02--》1.01--》1.0(这个不停留于理论;管理的好是完全可行的) 2)数据库脚本问题:理论上讲,数据库脚本加入索引等类似动作,是需要DBA审核的,因为研发同学对DB的认知和专业DBA是完全不在一个层次上(在一些场景下并不是加入索引就一定快的,很可能有后遗症),如果贵司这个案例之前有DBA审核机制可能就能提前杜绝这个问题。如果没有DBA,可以让团队对数据库专业领域知识很强人员替代。这个问题不是一个个案,很多公司都遇到过,其实是研发的数据库认识能力不强导致的(针对这点可以进行后续培训的)。 综上所述,遇到产生问题,第一时间能做到全局回退,而且很清晰的明白回退的版本节点,在事后的问题分析中,抓到本质原因,如果是非常特殊的情况建立记录以供所有团队参考杜绝再次犯错,如果非个案,建立后续制度进行管控。 浅见啊,希望乔总砸砖,哈哈

    作者回复: 你好,Tony.xu 思考的都特别好,这些实际就是我带领的团队都一直坚持的内容,加油。

    2021-03-05
    2
    1
  • Y024
    其实就“平平无奇”的 log 记录,很多人/产品/项目都做不好,出了问题都只能上重型武器——ide debug。

    作者回复: 你好,Y024 是的,其实记好log,本身时监控体系的一部分,如果数据都不对,不准确,后面在寻找问题时会出问题。这也是为什么我们寻找变化,而不是寻找bug的原因,很多信息都没有记录,所以难以定位。

    2020-12-20
    1
  • worfzyq
    错误一问题存疑,具体可能得看业务场景,如果涉及到c端业务肯定不能草率回滚,另外很对功能上了在下会有pr风险,当然确定这些没问题了确实可以这么做。

    作者回复: 你好,worfzyq 谢谢提出问题,我们来讨论一下。 第一,现在有问题,不回退,是业务有问题,甚至是不可用,两者权衡,取舍如何做决定,回退是最优解,因为回退的版本是业务可以正常运行的版本。 第二,发布是在业务低峰期,比如一般公司是在晚上,这时候回退了,查明问题再进行发布心理压力多小 第三,回退带来的问题就是上线失败了,但是业务不受影响;而不回退是业务受影响。如果我们不能保证每次发布一定成功,就必须有应对方案,回退就是一个保底的应对方案。回退+发布在业务低峰期,我的职业生涯中认为就是最优解决方案;回退在项目层级是不好,在业务层级对于业务影响几乎没有,是在发布失败时的最优解。 我们一起讨论,也可以结合一个具体的案来看看,是否还有更优的解,再次感谢提出问题。

    2020-12-18
    1
  • Jy
    确实是很好的做法,但我们公司还没能做到这一步,只能逐步改进。 比如业务逻辑出错导致的前端或者后台报错,能监控到但没后续,有一键回滚的能力但回滚了整个这方面的业务功能也就没了,业务不能接受,还是需要花时间来调试补上线。 想问下乔老师有无遇到这种情况呢?

    作者回复: 你好,Jy 回退应该是回到上一个稳定的业务版本,这个是在发布前就准备好的。 对于大项目,一个大版本发布的组织,这点比较难,但真的是把自己置于险地。只能在线上解决掉问题,团队的心理压力太大了。 我职业生涯碰到过,所以我再也不想再碰到这种情况,从理论上、概率上就彻底消除掉这种情况,那这个研发过程多轻松。

    2020-12-18
    1
  • 花花大脸猫
    回退这个有点不一样的看法:比如有些时候我们的系统是配合外部公司的系统一起上线完成一个闭环业务的,并且外部也明确了必须要能提供业务功能,这时候就不是简单回退能处理的了的?尤其是面对业务上很强势的业务公司,这种情况下,请问下老师有什么解法?

    作者回复: 第一,一定要有B计划 第二,如果一定是破釜沉舟,必须成功,那就要控制好研发质量,确保不会有问题。监控体系,测试覆盖率,同行评审,代码走查都要做到万无一失。

    2022-05-26
  • 戰の猫
    您好,我在听老师讲例子的时候就猜到可能是数据库出的问题。像我们发布软件,都要走change management 流程的,但是我觉得数据库好像change management 届黑洞般的存在,就算有日志,排查问题和回滚的时候特别容易忽略。经常使这种发布无法做到atomic

    作者回复: 你好, 暗夜微光 持续完善,CI,CD,CO,肯定可以达到的。

    2021-04-09
  • 知行合一
    乔总,很久没留言课程了,因为有点时间没有看课程了。这一讲让我收获一点很关键,找bug是为了解决问题,往往思路却被找bug和解决bug局限了。还是需要全局观,意识到恢复功能比找到bug价值更高,思维才不会被局限。换维思考,大繁至简,专业度就提现在简化过程上。 之前跟您分享,我发现了自己的选择方向,准备做出转变,提升上限。不过发生了很多阻碍,自己停滞不前。决定好做,迈出第一步也不难,难在坚持啊。很不顺利,就会很沮丧,想方设法的让自己维持好的心态,负重前行。 最近半年给我留下印象最深的,就是乔总的课程,说过的话。我也经常在工作中引用。感谢

    作者回复: 你好, 知行合一 太棒了,学以致用,是最好的学习效果

    2021-03-11
收起评论
显示
设置
留言
23
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部