什么是运维经验？如何使用运维经验告警？

白鳝的洞穴 2020-11-20

1707

我们这里说的运维经验不是指广义的运维经验，而是在D-SMART中引入的一个概念。这些年老白也在总结，我们这二十多年运维积累下来的那些家底如何使用？传统的运维自动化监控依赖的是一种基于指标的运维模式。某个指标异常了，就对这个指标进行告警。运维人员也会通过一些经验或者预案进行相关的分析处置。极简运维则只关注一些关键的指标，对这些关键的指标进行闭环管理。

作为一个搞了多年运维的人，我关注系统不是从指标入手的，而是从场景入手的。某些场景下，系统肯定存在某种特殊的情况，这就是我所说的“运维经验”。实际上运维经验是一种场景化的运维监控方式，把运维人员以往遇到的问题以及专家的经验总结成一系列的场景，然后针对这些场景来设计分析与处置的规程。这就是D-SMART中“运维经验”的原始模型。

比如上面这条运维经验“DB CACHE的物理读写流量小于总IO流量的M%，则说明存在大量异常io操作”。这个运维场景是老白团队这些年经常遇到的问题。前年某银行出现系统性能问题导致十多个小时核心交易异常，最后老白团队帮助分析发现是因为周末的RMAN备份导致写IO性能异常，最后触发主键索引叶节点分裂速度下降，导致行锁争用。这种复杂的结果不是一般运维人员能够很快定位发现的，事实上这个案例当时客户请了几家做数据库运维服务的厂商前来分析，都没有定位问题。最终还是老白的团队依靠经验发现了这个问题。从这个案例，老白团队结合以往的经验，就设计了这个运维场景。

借助运维知识图谱的智能分析，发现了REDO量异常的问题，从而定位触发这个场景告警的原因是REDO的问题。通过这个运维场景提供的诊断工具，我们很容易就确认了这个问题:

实际上，在我们运维的系统中，基于已确定的场景进行运维，比看着指标来运维要容易的多，也有效的多。当某个场景出现时，我们通过智能工具和专家工具去进行分析与定位，找到问题的原因。实际上我们日常遇到的运维问题大多数都不是致命的，立即会导致系统瘫痪的，不过当这些运维场景出现时，系统或多或少的都会存在一定的健康问题。如果我们能够对这些问题进行闭环管理，那么就能够逐渐消除这些虽然不一定致命，但是会导致系统健康下降的问题，那么系统的健康状态，性能会越来越好。这就是老白一直说的“系统健康管理”的概念。

对于出现的运维经验告警，我们可以进行处置。如果我们暂时还无法定位问题，那么我们就可以发起一个状态巡检分析：

这样任务平台就会自动启动一个状态巡检任务，帮我们分析系统中可能存在的一些问题（对于比较严重的系统状态出现，D-SMART会自动启动状态巡检任务）。

而对于某些运维场景，我们处置了本次报警后，已经定位了问题，认为暂时无需进行消缺操作或者暂时无条件进行优化。那么我们可以暂时屏蔽这个报警。

这种场景化的运维是不是和我们日常的工作更为贴近呢？至少老白和老白的一些客户都觉得，场景式的运维比盯着莫名其妙的指标发呆要有趣的多。

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

什么是运维经验？如何使用运维经验告警？

评论