昨天有朋友留言讨论必要的安全设置问题，认为60% CPU使用率报警其实是企业为了运营安全而设置的一个必要的保护措施，确保核心安全生产的时候，产生一些资源浪费还是划算的。
确实这种思路是目前大多数企业IT运营的常规思路，用一些可控的一次性投入来规避运营中的安全风险，是比较经济划算的。实际上大家都十分敬仰的互联网企业，也是依靠较大的冗余度来确保核心业务安全的，在这方面，并不比传统企业高明多少。
不过这只是在数字化运维水平比较低下的时候的权宜之计，难道CPU使用率不超过60%，系统就真的不怎么出问题了吗？如果超出60%，该如何快速定位问题，预防系统出现严重故障呢？简单设置一个CPU使用率不超过60%的阈值其实并没有解决掉运维工作中的核心问题，只是给大家对某些运维场景设置了一个预警线而已。
如果我们对系统的数字化运维水平再提升一些，能够往上游去分析CPU使用率比较高的一些常见场景，我们会发现一个新的天地。CPU使用率升高这个问题实际上是能够总结出一些常见场景的，第一种情况是最常见的，TOP SQL产生了较多的逻辑读，第二种场景是大量的不合理的硬解析消耗了过多的CPU资源，第三种是闩锁争用浪费了大量的CPU资源。可能我们还能列出很多，如果你列到第十种，大概常见的场景就列得差不多了。
第一种场景是我们都经常遇到的，CPU使用率的上升很可能是瞬间的，也可能是持续的，如果是瞬间CPU资源耗尽，对系统的影响较小，很快就会平息。而持续的CPU资源耗尽会引发严重的运维故障。我们如何区分这两种场景，或者说我们如何更早地发现CPU资源耗尽的隐患呢？在运维工作中，对于某些故障场景，向前溯源是最常用的分析方法，根据故障的影响因子往前推理，可以找到更早期预警的方法。SQL的执行情况变化和逻辑读的增长可能会先于CPU资源耗尽，因此向前去跟踪SQL执行情况的变化和逻辑读的增长，或者闩锁争用的变化，肯定会有更好的效果。
构建数字化运维能力是实现早期问题发现的基础，如果我们能够对已经列出的CPU资源耗尽的十多种常见场景的相关因素都数字化建模，那么这些情况发生的初期，我们就能够获得预警了。在支流恢复大河之前，我们就能够发现汛情，可以给下游带来更多的应急处置时间，这是运维数字化的第一个好处。第二个好处是我们如果还是采用传统的监控CPU使用率的方式，那么当下游泛滥的时候，我们必须向上游溯源，去找到哪个支流出问题了，这需要更长的分析时间。而如果通过数字化之后，构建了上游预警能力，那么相当于我们把汛情预警的能力构建到了每个支流上去，我们收到的预警是更为精准的，定位也会更快。
构建了这样的能力之后，我们就可以放宽下游预警的阈值，更加灵活地释放资源使用限制，不需要通过60%这样严苛的阈值来规范CPU的使用，这样就有效地释放了成本。降本增效不能总是盯着人来做，而应该更多的要往这方面去考虑，利用数字化的手段来降本增效其实效果是很不错的。我们已经喊了十多年数字化了，IT部门更是天天呐喊数字化的旗手，不过想想IT部门目前的数字化管理水平，真的令人汗颜。
