天之家IT资讯平台

　　最近有一件事情让我印象特别深刻，作为引子和大家唠一唠：我们在内部做一些极端的流量回归仿真实验时，在 TiKV(TiDB 的分布式存储组件)上观测到了异常的 CPU 使用率，但是从我们的 Grafana Metrics、日志输出里面并没有看到异常，因此也一度困惑了好几天，最后靠一位老司机盲猜并结合 profiling 才找到真凶，真凶出现在谁都没有想到的地方：Debug 用的日志模块(澄清一下：目前这个 Bug 已经修复了，而且这个 Bug 的触发是在非常极端压力的场景下+日志级别全开才会出现，请各位用户放心)。

　　这篇文章并不是做 Bug 分析，我觉得更重要的是，找问题过程中我们使用的工具、老司机的思考过程。作为一个观察者，我看到年轻的同事看着老司机熟练地操作 perf 和在各种各样工具和界面中切换那种仰慕的眼神，我隐约觉得事情有点不对：这意味着这门手艺不能复制。

　　事后，我做了一些关于基础软件用户体验的调研，发现该领域的理论和资料确实挺少(大多数是 ToC 产品的研究，系统软件相关的大概只有 UNIX 哲学流派)，而且缺乏系统化，依赖于作者个人「品味」，但是软件体验的好和坏显然存在，例如一个有经验的工程师看到一个命令行工具，敲几下就知道是否好用，是不是一个有「品味」的工具。

　　很多时候「品味」之所以被称为「品味」，就是因为说不清道不明，这固然是软件开发艺术性的一种体现，但是这也意味着它不可复制，不易被习得。我觉得这也不好，今天这篇以及可能接下来的几篇文章(虽然后几篇我还不知道写啥，但是先立个 Flag)会试着总结一下好的基础软件体验到底从哪里来。

　　作为第一篇，本文将围绕可观测性和可交互性两个比较重要的话题来谈。至于为什么把这两点放在一起聊，我先卖个关子，最后说。

　　1、可观测性

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

　　2、是谁在观测？

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

　　要回答这个问题，需要清楚一个现实：人的短期工作记忆是很有限的。大量的心理学研究表明，人类工作记忆的容量大致只有 4，即在短期同时关注 4 项信息[2]，再多的信息就要靠分模块的方式记忆，如我们快速记忆电话号码的方式，以 13800001111 为例，我们通常不是一个个数字背，而是形如：138-0000-1111 进行分组。

　　在了解人的心智模型的一些基础假设和带宽后，我想很多系统软件开发者大概不再会炫耀：我的软件有 1000 多个监控项!这不仅不是好事，反而让更多的信息破坏了短期记忆的形成，引入了更多的噪音，让使用者在信息的海洋里花很多时间找关键信息，以及不自觉的分类(我相信大脑的一个不自觉的后台任务就是对信息建索引和分类，注意这同样是消耗带宽的)，所以第一个结论：软件应用一屏的界面里面最好只有 4 个关键信息。那么，接下来的一个问题是：哪些是关键信息?什么是噪音?

　　3、区分关键信息和噪音

　　这个问题没有标准答案。对于系统软件来说，我的经验是：跟着关键资源走。软件其实很简单，本质就是对硬件资源的使用和分配，讲究平衡的艺术。关键的硬件资源无非也就下面几个，对于下面每一个关键资源在某个采样时间段(单点没有太多意义)，都可以通过一些简单的问题的询问，得到对系统运行状态的大致图景：

　　• CPU：哪些线程在工作?这些线程都在干嘛?这些线程各自消耗了多少 CPU Time?

　　• 内存：当前内存中存储了哪些东西?这些东西的命中率情况?(通常我们更关注业务缓存)?

　　• 网络 I/O：QPS/TPS 有异常吗?当前主要的网络 I/O 是由什么请求发起的?带宽还够吗?请求延迟?长链接还是短链接(衡量 syscall 的开销)?

　　• 磁盘 I/O：磁盘在读写文件吗?读写哪些文件?大多数的读写是什么 Pattern?吞吐多大?一次 I/O 延迟多大?

　　• 关键日志：不是所有日志都有用，只有包含特定关键字的日志，人们才会关心。所以，有没有特定关键字的日志出现?

　　通过以上标准问题的灵魂拷问，必定可以对系统运行状态有一定的了解。