昨天吐槽中移动的文章阅读量很大，看样子这个问题上可能不止我一个人想吐槽。其实文章不是针对139邮箱的，而是谈了一个普遍现象。包括我自己在内，这些年都给用户奉上了很多这样的体验不佳的系统。
我搞了8年D-SMART运维知识自动化系统，初衷也是想为DBA和企业提供一个数据库数字化运维的工具，不过这些年做下来，有很多值得用户吐槽的地方，也有大量自己都觉得不满意的地方。有一次我和一个客户的DBA谈我们的系统，他吐槽说：“你们这个系统给我们找了不少事儿，本来我们只上了个网管系统，数据库宕机、故障的时候去处置处置就行了。现在健康分一下降，告警界面上的红点亮起来了，领导看到就会让我去处理。关键是大部分告警其实并没有什么好的处置方案，或者说系统并没有告诉我可行的处置方案。于是我们上了这套系统，因此我就多了一个工作--去用这套系统！”。
当时我觉得这个DBA没有明白我们是在为他好，我们帮他们把一些系统的隐患发现了，让他们不至于小病不治变大病。我们这个行业总是喜欢用治病来做比喻，前些年我也觉得有些道理，不过后来我发现IT系统和人是不同的，人得病不及时医治是会挂了的，挂了就完结了，没有重生的机会。IT系统不会，数据库最大的故障，只要备份做好了，还是可以重生的，哪怕没有备份，也还是可以想尽一切办法去重建的。用治病去给数据库运维管理系统打广告其实是不合适的，因为错误的成本远没有比喻的那么大。实际上一件事是否必须去做，考虑的是效果和成本的平衡。
回到数据库本身，很多在专家眼里十分严重的隐患，也不一定是不处置就必然会酿成大祸的。企业如果对每个隐患都认真对待，理论上是最好的额，不过成本也是很大的，成本与效益的矛盾决定了很多问题在大爆发之前并不是一定要处置的。我曾经听过一位优化大师说过：“过早优化是万恶之源”，当时我不大明白这个道理，甚至觉得他的观点不对。后来经过一些事情，越来越发现这个观点虽然理论上很反动，但是在实践中是行之有效的。这里主要的要点就是“成效比”。
如果上了一个原本就是为了减轻DBA工作负担的系统，反而增加了DBA的负担，这绝对不是我们设计这类系统的初衷，不过确实也是普遍存在的事实。不同的企业中，不同的文化背景，不同的运维模式，不同的应用场景中，需求是大不相同的。而我们提供的只是一个标品，如果要满足各种用户的需求，需要有大量的开关和个性化功能，这在传统的运管系统中确实很难做到尽善尽美。因为对于开发商来说，这都意味着研发成本。
如果你的产品不满足用户的需求，用户就必须改变工作习惯去适应你的软件，有些改变是合理的，可以提高用户的管理水平，不过有些改变可能会让用户的工作变得更加麻烦。我以前还听过一个做产品的朋友说要“通过他们的产品教育客户，改变他们的工作习惯”，这个观点我一直是不赞成的，想教育客户的产品最终都会被市场教育的。我们只有做出用户适合的，想用的，能帮他们省时省力的产品，才会获得市场。
最近我也一直在反思智能运维系统该如何做，D-SMART已经是一个过去的产品了，虽然底层的数字化思维还没过时，但是UI交互界面已经完全过时了。在生成式AI兴起和数字化转型的今天，一个DBA为了监控而整天去盯着一堆仪表盘和报告，那纯粹是浪费时间。下一代的智能化运维系统必定是可以用更加自然的方式与DBA交互，真正能帮DBA减轻工作负担，而不会给DBA添乱的好助手。
