写在云栖大会的感触：《诊断，为了不用诊断的价值》

1. 感言

2023年参加了云栖大会，算是带着obdiag去见了见世面吧，最大的感触就是今年大模型真的是遍地开花。本届云栖大会以“计算，为了无法计算的价值”为主题，个人理解“很多的价值是无法计算的，比如，你用着通讯软件和家人视频聊天、足不出户云游四海......这些附加价值是无法计算的。但我们可以通过可计算的东西来创造这些无法计算的价值，这就是计算的价值。”  当时打算做obdiag这款工具的时候，初衷是希望“让诊断OceanBase 数据库变得更快更容易”，我们用OceanBase为什么要去诊断，是因为存在Bug, 不论是数据库本身，还是使用数据库的业务SQL，甚至是运维数据库的人，都会存在Bug，世界上不存在一款没有任何Bug的软件。我们要去做诊断，或者说我们做诊断的终极目标是啥？ 我觉得是为了不用诊断我们的系统就能稳定高效的运行。这里不是很恰当的套用一下云栖大会的主题，“诊断，为了不用诊断的价值”。

OceanBase诊断工具相关链接：

2. 附录：

云栖大会蚂蚁展台2023年10月31日，开源会客厅《obdiag: 一款OceanBase数据库诊断的瑞士军刀》PPT

本次的分享，我主要围绕了三部分进行，分别是：obdiag的项目价值、obdiag的技术实现、obdiag的未来规划。

OceanBase是由蚂蚁集团完全自主研发的企业级分布式关系数据库，基于分布式架构和通用服务器、实现了金融级可靠性及数据一致性。通过在底层分布式引擎实现的Paxos多数派协议和多副本特性，OceanBase拥有了令人称道的高可用和容灾能力，不负“永不停机”的数据库系统的盛名，可以完美支持多地多活、异地容灾等高可用部署。

面对分布式数据库的故障时，运维人员往往束手无策。主要原因是相较集中式数据库，分布式数据库涉及单节点独立工作和多节点联合工作的模式，故障可能是某一个节点某一个模块引起的，排查问题的难度指数级增长。比如我们常见的CPU飙高，就有很多的可能性，可能是磁盘性能弱导致写入事务触发CPU高涨，也可能是集群间各节点的网络原因导致分布式查询语句耗时高，在高