备注说明：相关总结属于个人学习笔记，请勿商用，感兴趣的可在极客时间订阅该《乔新亮的CTO成长复盘》专栏学习，谢谢~
要想深刻理解监控的概念，我们首先要学会问自己：为什么要做监控系统？这就像许多工作方法论里强调的一样，做事先问目的 —— “start with why”。
监控的目标是及时发现系统的问题，并尽可能快地做出相应的动作，让系统一直处于健康的状态。
监控，可以拆分为“监”和“控”分别理解，也就是“监视”和“控制”
例子
服务器的 CPU 负载突然飙升
“最近线上有什么版本变动吗？都回退了吗？”
研发同学：只会退了指定版本没有 会退到上一个版本。
真的都回退了吗？
同学一拍脑门，犹豫地说道：“我在数据库里加了条索引，不过这肯定不会导致负载异常……”
删除索引后一切正常了。。
IT 团队的系统监控体系，到底出了什么问题？
生产环境应急恢复的最大挑战在于根因分析，即找到问题的根本原因，这往往是耗时最久的工作。
常规的操作
- 发现问题后，立即联系各相关系统负责人，以便共同排查问题；
- 要求大家在一分钟之内回复：自己治下的系统或服务是否健康（这里要将“健康”的定义想清楚，如，响应时间是否增加超过 30% 等）；
- 进行根因分析，确认导致问题的系统、服务；（人员规模也会越来越大，花费的时间就会脱离控制。）
- 完成系统恢复工作。
针对：根因分析
首先，我们要确认异常是外因导致，还是内因导致。
比如，服务响应慢，既可能是因为外部调用量变大，也可能是因为内部进程繁忙，导致 I/O 、内存、网络资源发生争抢。这步判断相对来说比较耗时间，只有当调查足够充分时，结果才可能浮出水面；
无论是内因还是外因，都要“顺藤摸瓜”，继续进行排查，最后进行恢复。
有效的方法：
流控和版本回退，简单、粗暴、实用。
流控，就是做好程序的并发流量控制；
版本回退，就是在生产环境的发布出现问题时，及时回退到上一个版本。
生产环境出现问题，原因：变化。
“变化”大三类：
- 外部用户请求量增大；
- 产品发布，一般包括代码发布、配置发布、SQL 脚本发布等；
- 依赖资源变化，一般是计算、存储、网络基础设施情况变差，比如磁盘存在坏道等。
优化过的操作
- 发现问题后，立即联系各相关系统负责人，以便共同排查问题；
- 要求大家在一分钟之内回复：自己治下的系统或服务是否健康（这里要将“健康”的定义想清楚，如，响应时间是否增加超过 30% 等）
- 此处组织两批研发力量，并行工作。第一批解决专业问题，继续跟进问题的定位和调试
- 第二批负责消灭变化，对有变化的模块进行回退，对于外部请求数量升高的模块启动流控； 恢复系统
核心
对于任何组件，都有以下两种手段同时存在： 流控手段； 发布回退手段。
认知转变
在生产环境，研发人员应该寻找并消灭“变化”。从寻找 bug 到寻找变化。
刚才例子复盘
- 错误一：负责发布的同学，没有按规定回退至稳定版本，而是询问开发同学的意见，并以其意见为准；
- 错误二：相关负责人，因为假设“一条索引不会导致故障”而知情不报，导致系统无法完全回退；
- 错误三：十几名团队成员没有将精力聚焦在线上业务恢复方面，而是试图在生产环境查找 bug。
程序员总觉得找到问题才是高手，回退解决不了问题。
记住：
要改变自己潜意识找bug的第一想法，我们的目标是：即使找不到 bug，依然可以做好故障恢复。
生产环境永远不允许调试问题，出现问题立刻回退，查问题要去测试环境。
对于复杂系统不好回滚，可以参考亚马逊：大版本立项，小版本上线 —— 梳理好各模块的依赖关系，将各个系统、各个服务独立发布。当然，这也需要依赖服务版本化和 CI 能力的支持。
总结
要做到监视一切，分析一切，控制一切，
“眼”能看见所有，“脑”能洞察一切，“手”能一手遮天，
一切业务数字化，一切数据可视化，一切控制可触发
监控的目的是让系统一直处于健康状态，具体手段则可分为“监视”和“控制”两种；要做好控制，一个重要的方法是做好流控和版本回退。因为在大部分情况下，消除变化就等于消除异常。
不单是技术、业务系统需要做好监控，研发管理、团队管理都要做好监控。
关于研发管理，我们在“高可用设计”部分曾提到：风险是经由开发环境、SIT 环境、压测环境、PRE 环境，进入生产环境的。所以我们要做的是严格检查各个环境下的异常。
所谓研发管理规范，应该为代码版本进入下一个环境设置准入标准。对于任何异常，都有负责人进行修正。
对于团队管理，我们常常说，组织是结果导向的，但管理工作是过程导向的。关注过程自然就会得到好的结果，只盯着结果往往什么也得不到。
对于一个项目、一个产品，乃至于团队的健康度，管理者有没有在关键节点设置监控？
