福建白癜风医院 https://myyk.familydoctor.com.cn/2831/content_859322.html
最近有一件事情让我印象特别深刻，作为引子和大家唠一唠：我们在内部做一些极端的流量回归仿真实验时，在TiKV（TiDB的分布式存储组件）上观测到了异常的CPU使用率，但是从我们的GrafanaMetrics、日志输出里面并没有看到异常，因此也一度困惑了好几天，最后靠一位老司机盲猜并结合profiling才找到真凶，真凶出现在谁都没有想到的地方：Debug用的日志模块（澄清一下：目前这个Bug已经修复了，而且这个Bug的触发是在非常极端压力的场景下+日志级别全开才会出现，请各位用户放心）。这篇文章并不是做Bug分析，我觉得更重要的是，找问题过程中我们使用的工具、老司机的思考过程。作为一个观察者，我看到年轻的同事看着老司机熟练地操作perf和在各种各样工具和界面中切换那种仰慕的眼神，我隐约觉得事情有点不对：这意味着这门手艺不能复制。事后，我做了一些关于基础软件用户体验的调研，发现该领域的理论和资料确实挺少（大多数是ToC产品的研究，系统软件相关的大概只有UNIX哲学流派），而且缺乏系统化，依赖于作者个人「品味」，但是软件体验的好和坏显然存在，例如一个有经验的工程师看到一个命令行工具，敲几下就知道是否好用，是不是一个有「品味」的工具。很多时候「品味」之所以被称为「品味」，就是因为说不清道不明，这固然是软件开发艺术性的一种体现，但是这也意味着它不可复制，不易被习得。我觉得这也不好，今天这篇以及可能接下来的几篇文章（虽然后几篇我还不知道写啥，但是先立个Flag）会试着总结一下好的基础软件体验到底从哪里来。作为第一篇，本文将围绕可观测性和可交互性两个比较重要的话题来谈。至于为什么把这两点放在一起聊，我先卖个关子，最后说。

可观测性

可观测性是什么？这可从我两年前发表的《我眼中的分布式系统可观测性》[1]一文中可见一斑，相同的内容我在这里就不赘述。随着在TiDB中对可观测性实践的深入，对这个话题有了更深的理解，为了更好的理解，我们首先先明确一个问题：当我们在聊可观测的时候，到底是谁在观测？

是谁在观测？

很多朋友可能会一愣，心想：这还用说，肯定是人，总不能是机器。没错，的确是人在观测，但就是这么一个浅显的道理往往会被软件设计者忽略，所以这两者的区别到底是什么？为什么强调人这个主体很重要？