共计 3476 个字符，预计需要花费 9 分钟才能阅读完成。
在 TiDB Hackathon 2021 赛事中，没有错过任何一届赛事的元老级选手王鹏翰再次得奖，也是继滑滑蛋之后，又一支男女朋友并肩参赛的队伍。
王鹏翰目前工作于思科旗下做利用性能治理的公司 AppDynamics，次要从事日志搜索引擎的研发和可观测性相干的一些工作。陈思雨是 PingCAP Chaos Mesh 团队的研发。
这次的参赛我的项目 Collie Diagnosing Platform，是一个集故障场景信息收集、UI 在线察看剖析、机器学习辅助诊断于一身的故障诊断剖析解决平台。联合了两人在工作中的理论场景，摸索了将来 3-5 年 DBA 和运维人员的工作形式，评委们给予了十分高的评估和期待，拿下了本届 Hackathon 的三等奖。
我的项目意义重大，让 DBA 在剖析问题时，面对那么多 Metrics，不再那么头大。
——多点 Dmall 数据库团队负责人冯光普点评
数据库自治是畛域的重要方向，参赛团队在实践和工程实际方面都做的比拟好，后续能够进一步对标阿里云的 DAS 产品进行改良欠缺，将补救这一畛域我的项目在开源方面的空白。
——美团数据库研发核心负责人李凯点评
对于团队
Q：这个队名的由来有什么故事？
陈思雨：队名来自于 Dota 的一个语音包，在游戏里如果队友做什么比拟蠢的操作的时候，播放下这条语音就达到成果了。
能够通过这条视频领会一下：https://www.bilibili.com/vide…
Q：两位都是 Hackathon 的老选手了，Hackathon 对你们的吸引力是什么呢？
王鹏翰：对我来说 Hackathon 就是进行一个 deadline 的设置，逼着你在很短时间内学大量的货色。原本我很早就想去学习一下如何用机器学习做一些根因性剖析相干的货色。然而曾经想了一年，实际上只看了一点点。在 Hackathon 中，就能够在很短的工夫内理解它并且把它应用起来。有一个 deadline 就会逼迫你疾速去学习，这个时候学习效率十分高，睡觉的时候满脑子都在想着这个中央还能怎么优化一下，那个中央还怎么搞。当然，顺便还能拿到一点奖金。
陈思雨：跟他差不多。另外，在 Hackathon 里还能看到很多不一样的 idea。
我的项目灵感
Q：你们最后为什么会想到要做这样一个我的项目的？能分享下你们的灵感是什么吗？
王鹏翰：咱们前两年参赛基本上都是在做 FDW，就是给 TiDB 接一个通用的内部数据源，往年的一等奖我的项目从某种意义上来说也是内部数据源的一种。感觉曾经做得有点心神憔悴了，那些 Hard Code 的性能对于咱们这种老年人来说，无论是脑力还是膂力都曾经跟不上了，往年就只能在搞花活的方向去另辟蹊径。
我找我的项目灵感的一个外围点是去挖掘身边实在遇到的一些状况，试图抽取出一个通用性的问题，而后去想如何通过工具或者方法论把它高效地解决掉。包含去年的 idea 如何写出一份优雅的文档，往年的 idea 如何疾速地发现故障和诊断故障，都跟工作是非亲非故的。
我当初的工作是在可观测性畛域，这个畛域目前跟机器学习相结合的货色大多都还在论文阶段，但在理论环境中如何把它更好地落地，还是比拟少有人去尝试的，刚好 TiDB 曾经把整个根底做得十分好了，就想借 Hackathon 的机会来做一些尝试。
Q：在这次较量过程中，你们的队伍成员之间是如何分工的？
王鹏翰：思雨负责如何用 TiDB 去模仿故障的产生，刚好也用了他们团队的产品 Chaos Mesh。而后我应用一些工具来代替人脑，察看这个时间段是否产生了问题，用机器学习的办法代替人做一些简略的判断。就等于说运维人员有一个很大的屏幕，下面有几十个图，每个图里都有很多的折线。个别状况下，如果一个零碎在安稳运行的话，这条线根本是平的，但呈现故障的时候，会有很大的稳定。
当初都是 DBA 用人眼去察看，故障的判断也是基于人的教训和思考模式。但当初 TiDB 中像这样的指标就曾经有几千个了，将来还会有更多。这就意味着靠人去察看这些货色会变得越来越简单，越来越慢。咱们能够用机器去帮你疾速地筛选进去，比方 1000 张图中有 10 张图有这种故障，而后你再去察看这 10 张图就能够，帮你节俭了大量的工夫。
在现实的环境下，准确率能达到 70-80%。但如果在事实环境中，你可能认为有些并不是故障，所以这个指标会有一些稳定，噪声会很大。
技术艰难 & 应答
Q：在较量过程中你们遇到过什么比拟大的技术艰难？
王鹏翰：次要是数据集品质问题。目前在 AI 畛域，算法可能不是最要害的，最要害的是数据集。如果你的数据集够好，通过相应的算法都能失去一个很好的答案。但如果你的数据集比拟蹩脚，那你得进去的答案永远是谬误的。所以咱们花了很多工夫在数据集模仿这一块。
另一块就是在思考如果换我来运维零碎，从 DBA 的角度来看问题的时候，我该如何正当设计用更高效正当的形式来做这个事件。其实不论是 TiDB 也好，还是一套零碎也好，都有一套共用的方法论，能够通过观察资源，比方 CPU 资源或内存资源，或者察看事务（一个 http 申请，一个数据库查问申请）。从而晓得零碎是否依照预期在运行。如果没有依照预期运行的时候，咱们的利用能给一个告警，还能通知你是什么起因导致系统没有按预期运行。
这就是所谓的根因剖析（Root Cause Analysis），咱们心愿通过机器学习，通知你产生故障的起因是 CPU 不够，还是机器上有另外的工作抢了 CPU 资源，那你就应该去加更多的 CPU 资源。
陈思雨：其实其这个问题不应该仅仅是 DBA 或者运维关怀的，因为他们（王鹏翰所在的 APPDynamic）是全员 Oncall 的，所以他会思考遇到一个 Oncall 的问题应该怎么去解决，应该怎么去优化这个 Oncall 的流程。咱们这次做的我的项目也是在优化这个 Oncall 的整体流程。
DBA 可能会更业余一点，咱们这次做的产品是面向那些非 DBA 人员，因为 DBA 看 Grafana 这种比拟业余的指标就会有很明确的一个判断。然而如果是刚上手的人，比如说刚开始学习 TiDB，也能够通过咱们的产品有个初步的方向判断，这个故障起因是一个网络提早还是怎么。
王鹏翰：遇到的另一个问题就是现有的机器学习也好，深度学习也好，离所谓的 AIOps 还有十分远的路要走，而且有很大的难度。为了这次的我的项目能有一个成品进去，次要依赖了两篇论文，一篇是 SIGMOD 2016 的《DBSherlock: A Performance Diagnostic Tool for Transactional Databases》，另外一篇是 VLDB 2020 的《Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases》。
这 2 篇论文做得十分好的一点就是把场景局限起来了，针对一个小的畛域、小的场景能做到高度的准确性，比方一个运维可能 10% 的工作是在解决这类问题，那这个我的项目能自动化地解决这 10% 的工作量。而后像拼积木一样，明天把这个问题的积木拼装好，下次把另外一个问题拼装好，缓缓就把整个全自动化的事件给拼接进去了。
未实现的遗憾 & 期待
Q：这次 Hackathon 的工夫无限，你们在较量过程中有什么遗憾？
王鹏翰：体验称心，实现集体的既定目标，在短时间疾速学习了机器学习，并做了个小产品。aiops 能够在一些特定的畛域升高人的工作负载，但离最终宽泛的代替运维还有十分远的路。
陈思雨：8 分钟的演示工夫太短了，咱们始终在缩减 PPT，调整咱们要突出哪些重点，还要保障在这么短的工夫内让这么多位评委老师都 get 到。
Q：你们的我的项目这次取得了三等奖，对这个我的项目将来有什么瞻望与期待？
王鹏翰：首先，这个我的项目的实现办法还十分雏形，有很多的细节还须要跟大家探讨和交换能力摸索进去。而且咱们也没有心愿把这个我的项目做成一个产品，更多的是方向上的摸索，摸索将来 3-5 年运维或 DBA 的工作形式。
随着技术的突飞猛进，运维的难度也越来越大。运维的治理对象从原来的单台机器变成了云和 Kubernetes，节点越来越多，涌现进去的信息也越来越多。从开发的角度来说，会把更多的信息裸露进去，对立地进行治理和追踪。但如何更好地利用这些信息？这个畛域在国内还是鲜有人去思考的，也就是所谓的可观测性（Observability）。
国外很多公司，包含咱们公司（AppDynamic）都是这个畛域的次要参与者，在十分沉闷地往这个方向进行一些摸索。PingCAP 曾经算是做得很不错的了，把整个数据库的可观测性做得很好。心愿国内有更多的公司和集体能去思考一下，如何使用现有的工具，让你的零碎有更好的可观测性，从而升高运维压力和老本。
