从DSMART V2发布谈起

白鳝的洞穴 2021-10-29

3677

今天的文章做个小广告。大家可能看老白的公众号东一锤子西一榔头的，不知道老白怎么会有那么多闲工夫写这些玩意。也是靠着大家帮衬，老白的基石数据主要是做一些智能化运维工具和IT服务的，这些年也算是能够平静的活着。D-SMART是我们团队花费了4年时间打造的一款“运维知识自动化”系统，最初的主要作用是辅助团队的IT服务业务做系统优化，通过工具化和智能化减轻专家与技术人员的工作负担,并提高服务的标准化水平。做着做着发现这套东西给一些客户自用也很有不错，于是就把这款工具经过改造，开始面向客户进行销售了。

实际上任何一款运维工具都无法完全替代人，目前的人工智能也好，知识自动化也好，大多还是数据智能，和人脑的水平还相距甚远。自动化或者说智能化工具与专家的分析能力比较还是存在较大的差距的，因此D-SMART现在用的最好的模式是客户+工具+服务厂商+专家远程服务的业务模式。无论是用户还是第三方服务商还是基石数据都从中获得了巨大的收获。这也是前阵子我发文所说的“IT运维生态化”。

通过工具，形成生态化的协作关系，才是真正解决复杂的运维问题目前能够做到的路线。如果谁号称通过自己的工具就能解决主要问题，往往都不太靠谱。

虽然如此，D-SMART确实给团队的能力带来了巨大的提升。首先是效率的提升，以往分析一个问题，哪怕是我们公司最为资深的专家，也需要大量的采集数据，对着数据冥思苦想大半天，才能有所发现，而现在在D-SMART的帮助下，不需要再去采集数据，也不需要对着数据做分析，D-SMART的分析工具自动会帮你把这一切都做好，一个问题的分析时间可以从数小时降低为数分钟。两年前，我们用D-SMART帮助一个北京的客户分析一个节假日的故障的时候，因为疫情的原因，只能采取远程分析的方式。在使用离线数据的情况下，我们只用了不到5分钟就定位了问题的根因。

D-SMART的第二个比较重要的作用是知识积累和知识标准化。D-SMART的核心是标准化的知识库，这些知识库都是经过专家验证过的，相对有效的，因此这些知识可以帮助团队中并未具备此种能力的工程师去分析故障。我们北京的一个合作伙伴使用D-SMART给几个用户维护MYSQL数据库，他们的DBA并不具备MYSQL数据库运维的基本能力，不过利用D-SMART已经多次帮助用户发现问题并完成根因分析了。

D-SMART V2在界面上和V1.9.X差别不是很大，用户界面并不是D-SMART的长项，因为D-SMART本身不是给人做监控用的，作为运维人员的你并不需要总是去看这个界面。D-SMART是作为一个自动化分析引擎，随时帮客户采集相关数据，并且做自动分析，然后再通过各种告警手段或者各种报告向用户提供分析结果。因此也有一些用户把D-SMART当成自己的智能运维平台中的一个能力组件，为大平台提供一定的能力。在D-SMART的用户手册里专门有一小节介绍了懒人用法，通过各种远程协助来运维自己的系统，这是一种生态化的运维体系。

可能有朋友会提出疑问，远程协助会不会很贵，实际上在年度订阅费中增加很少的费用你就可以享受远程协助了，这是一种大家都用得起的专家服务，起步价是几千起步的，这也是生态化的优势所在。

D-SMART的另外一类客户是IT系统十分庞大，比如说我们目前服务的客户中，最大的客户有上千个数据库实例，而运维人员只有区区十几个，还要负责日常的各种工程实施，系统上线等工作。哪怕让他们每天对所有数据库做个日检，别的事情就啥也不用做了。这种情况下，日常运维的时候连看看监控大屏都没时间了。D-SMART对这样的用户是十分友好的，因为你只需要相信你的D-SMART就好了，有事它会叫你的。当然D-SMART也不是全能的神，也会犯错误。不过没关系，如果这次它错过了一条重要的报警，那么知识生态会立即对此进行总结。后端的专家会协助客户分析新的运维场景，快速构建新的预警模型和诊断工具，快速的弥补平台存在的缺陷。大部分工作可以在数个工作日之内完成。

谈了半天D-SMART，下面该谈谈D-SMART V2有啥新特性了。首先V2版本已经脱离了纯数据库运维工具的范畴，已经纳入了大量新的运维对象，从而满足客户更为广泛的要求；其次V2版本针对信创的需求，增加了很多国产数据库、中间件、存储系统的支持。下面我们看看支持列表：

最近我们在一个政府的优化项目中，针对某个城市的移动APP做压测，发现无论如何优化，并发量总是上不去。经过绝望的几天分析之后，部署了D-SMART一分析，立即发现REDIS存在比较严重的问题。看来V2版本上，关系型数据库之外的一些IT组件的诊断分析能力也已经逐步达到实战要求了。

在V2的后续版本中，我们很快还会支持Oceanbase、TDSQL、GBASE 8S等目前信创领域较为活跃的产品。

除了运维对象的增加之外，D-SMART V2中继续在生态化、智能化、自动化这三方面发力。

通过与企业微信对接，D-SMART可以构建一个客户+服务商+专家+智能助手推送的服务生态，不同团队的人员可以基于共同的系统进行团队协作，从而让运维工作变得更为简单，专家支持变得更为快捷。用户只要能够在D-SMART服务器上开通一个VPN通道，单向访问企业微信的接口，D-SMART就会自动将各种告警信息推送到这个虚拟运维团队里。这个虚拟运维团队可能包含客户的运维人员、第三方的技术人员和基石数据的专家。大家可以在这个虚拟微信群里，用微信进行交流，对某个告警进行讨论。甚至必要时，用户在D-SMART上点击一下按钮，就可以把一份系统自动生成的诊断报告发送到群里或者发送给群里的某个专家。

除了生态方面的能力更为强大外，D-SMART V2提供了更为丰富的报告。除了建转运合规性检查报告支持运维对象的范围更为广泛之外，系统巡检报告、系统特检报告、日检汇总报告、SQL审计报告、容量分析预测报告、数据库对象审计报告等各种报告给大型数据中心运维团队提供了更多的便捷。通过这些报告，运维团队可以更为简单的掌握系统运行情况。

最后要谈的就是自动化和智能化方面的提升。D-SMART V1.9注重的是智能化诊断辅助的能力。通过D-SMART的诊断分析报告让运维人员和专家减轻分析的工作量，可以更快的发现问题和定位问题。而D-SMART V2中的知识图谱做了十分重大的升级，利用升级后的知识图谱，我们可以向用户提供更强大的智能化分析能力。

通过知识库进行自动推理，智能化运维工具可以自动对发现的问题进行后台诊断。整个诊断过程中不会访问任何生产库的数据，都是利用已经采集的指标进行分析，因此后台自动分析不会影响生产系统。

如果是比较严重的问题，还可以使用智能化诊断工具进行自动问题定位和故障溯源。比如系统中突然出现日志同步延时过高的问题，最高超过200毫秒，这是什么原因导致的呢？

智能化运维工具直接给出了诊断的结果：

通过分析，系统中存在大量的TOP SQL，IO延时过大，REDO并发写的量过大三个因素可能是导致该问题出现的主因。

D-SMART是一个以数据为核心的知识自动化系统，数据、大数据分析算法、机器学习、深度学习模型等作为构成D-SMART的基础能力的组件并不是D-SMART具有目前的能力的最关键的因素。把专家积累了几十年的经验和大数据、人工智能结合起来，并通过服务生态化不断地积累算法的能力才是其中的关键。回想起2018年发布第一个商用版本的D-SMART 1.2的时候，那个D-SMART和现在的D-SMART在软件的架构上差别并不大，所不同的是，系统中的知识库已经不可同日而语了，知识的不断积累才能造就更好的D-SMART。而积累知识不仅仅是专家的功劳，更多的知识是来自于客户现场的案例。D-SMART的成长的最大推动力是IT运维生态化。

数据库

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

从DSMART V2发布谈起

评论