这些年数据库运维工具的领域各种概念层出不穷，每个用户好像都有自己的特殊情况，他们需要的运维工具的功能也千差万别，搞的有时候让我都感到有些弄不明白用户到底需要什么样的产品了。有些运维工具是企业的刚需，是高频使用的功能，比如说数据库的安装部署、自动打补丁升级，批量修改数据库配置等。随着企业私有云的建设，这些功能会逐步纳入到云平台管理的范围之中。

而对于运维监控、系统预警、系统巡检等方面的功能，大家的需求就千差万别了。我们是做运维知识自动化系统的，目的是通过将运维知识数字化帮助DBA进行运维监控、故障预警、根因分析、系统巡检、SQL审计、容量管理、安全管理等工作，通过数字化的运维知识直接辅助DBA工作，从而降低人工运维的成本。

我们的产品在某些用户那边很受欢迎，觉得工具确实对他们很有帮助。而对于某些用户来说，他们觉得还是更相信DBA的判断，还是需要依靠以前的模式来监控和管理数据库系统。还有一些企业有十分严格的管控，通过什么方式来监控系统，甚至使用什么命令，都有十分严格的要求，如果没有按照规程操作，系统出了问题，责任是很大的。

作为D-SMART产品实际上的产品经理，我也经常从运维人员的角度在思考问题，“运维知识自动化”如何才能给一线运维人员更多的帮助。前两天的一次与客户的线上交流给了我很大的启示，虽然这只是某一个用户的需求表达，不过我感觉可能他们遇到的问题还是有一定代表性的。首先他们对“运维知识自动化”这个概念十分认可，他们觉得以前买过很多数据库运维工具，但是买来的都只是工具，并没有买来运维数据库的知识，因此这些工具在他们那里使用效果都不太好，大部分买过来半年后就没人用了，我们这个工具是他们觉得可以长期使用的。

不过虽然我们的工具理念和他们比较吻合，但是我们的工具目前还无法覆盖他们日常运维监控工作的全部，一些他们日常的监控功能还没有覆盖。后来我和他们交流了一些他们日常工作的内容。我发现实际上我们的工具中的一些功能基本上能够替代他们以前的一些监控行为。因为我们之间的一些运维理念存在差异，某些我们觉得可以通过日检来解决的问题，他们需要每天定时去做一些检查。某些我们可以通过其他方式来进行评估的风险，他们习惯于用自己的方法去分析。

其实大家都在使用自己的“运维知识”来进行日常的运维工作，不过运维知识体系是十分复杂的，大家日常所依靠的运维知识虽然从理论基础上看是不矛盾的，不过在实际工作中，人们更习惯于按照自己的习惯去监控和管理数据库系统。这些习惯的差异还是会为运维人员带来很多困扰。

比如说有个客户在他们的运维手册里要求定期到服务器上采集listener的状态，我们的工具里并没有listener探活的指标，而是通过真实连接去探活数据库的可用性。其实我们的探活包含了对监听的探活，能够真正连接数据库，肯定监听是工作正常的，否则我们会采集到监听失败的消息。对于这个问题我们可以通过说服用户去接受我们的指标，不过对于用户来说，最佳的使用体验是能够直接看到监听状态的指标数据，这样的话，就完全不需要改变他们的运维习惯了。

作为运维工具的开发商，我们不能只是从工具的角度去考虑问题，让用户来适应工具的特性，甚至我还听说过某位工具厂商的朋友说要对用户的运维习惯进行教育，让他们的运维能力得到提升。对于某些用户，可能能够完全接受一种全新的监控工作模式，不过对于一些用户来说，并不一定能够做到如此。在十多年的运维工作中，他们已经积累下了一些被证明有效的运维经验，完全丢弃也是一种浪费。

大语言模型在运维领域受到追捧的一个十分重要的原因也是如此，因为它可以用你所习惯 的知识语言体系来回答你的问题，让你不需要做任何知识体系转换。这种特性也是运维工具厂商需要去学习的。通过简单的配置实现运维知识的个性化呈现，尽可能地让工具贴近用户现有的运维习惯，既可以让用户更快更好地使用工具，也可以最大限度地发挥工具的作用。

我欣然接受了客户的要求，表示一定全力配合他们，尽可能把他们所有的日常运维工具的能力都纳入到系统中去，尽可能不改变他们现有运维习惯的前提下提升他们的监控预警与故障分析能力。通过交流，双方都觉得通过这个合作，利用现有平台的基础能力，可以实现绝大多数日常运维工作的白屏化，进一步再实现部分操作的无屏化。

要实现这一点，首先需要将他们的所有日常监控、巡检操作都实现自动化采集，并通过一个集成界面让他们便捷查看。然后逐步结合一些分析算法，对这些状态和数据进行自动化分析，形成可预警的故障模型，当系统出现某类异常的时候进行自动预警。经过一段时间的磨合后，运维人员可以对系统的预警产生一定的信赖，那么运维人员今后就不一定需要定期去查看监控屏幕了，运维工作也可以逐步从白屏化向无屏化演进了。