PingCAP CTO 黄东旭：如何做出让人爱不释手的基础软件最近有一件事情让我印象特别

最近有一件事情让我印象特别深刻，作为引子和大家唠一唠：我们在内部做一些极端的流量回归仿真实验时，在TiKV（TiDB的分布式存储组件）上观测到了异常的CPU使用率，但是从我们的GrafanaMetrics、日志输出里面并没有看到异常，因此也一度困惑了好几天，最后靠一位老司机盲猜并结合profiling才找到真凶，真凶出现在谁都没有想到的地方：Debug用的日志模块（澄清一下：目前这个Bug已经修复了，而且这个Bug的触发是在非常极端压力的场景下+日志级别全开才会出现，请各位用户放心）。
这篇文章并不是做Bug分析，我觉得更重要的是，找问题过程中我们使用的工具、老司机的思考过程。作为一个观察者，我看到年轻的同事看着老司机熟练地操作perf和在各种各样工具和界面中切换那种仰慕的眼神，我隐约觉得事情有点不对：这意味着这门手艺不能复制。
事后，我做了一些关于基础软件用户体验的调研，发现该领域的理论和资料确实挺少（大多数是ToC产品的研究，系统软件相关的大概只有UNIX哲学流派），而且缺乏系统化，依赖于作者个人「品味」，但是软件体验的好和坏显然存在，例如一个有经验的工程师看到一个命令行工具，敲几下就知道是否好用，是不是一个有「品味」的工具。
很多时候「品味」之所以被称为「品味」，就是因为说不清道不明，这固然是软件开发艺术性的一种体现，但是这也意味着它不可复制，不易被习得。我觉得这也不好，今天这篇以及可能接下来的几篇文章（虽然后几篇我还不知道写啥，但是先立个Flag）会试着总结一下好的基础软件体验到底从哪里来。
作为第一篇，本文将围绕可观测性和可交互性两个比较重要的话题来谈。至于为什么把这两点放在一起聊，我先卖个关子，最后说。
1、可观测性
可观测性是什么？这可从我两年前发表的《我眼中的分布式系统可观测性》[1]一文中可见一斑，相同的内容我在这里就不赘述。随着在TiDB中对可观测性实践的深入，对这个话题有了更深的理解，为了更好的理解，我们首先先明确一个问题：当我们在聊可观测的时候，到底是谁在观测？
2、是谁在观测？
很多朋友可能会一愣，心想：这还用说，肯定是人，总不能是机器。没错，的确是人在观测，但就是这么一个浅显的道理往往会被软件设计者忽略，所以这两者的区别到底是什么？为什么强调人这个主体很重要？
要回答这个问题，需要清楚一个现实：人的短期工作记忆是很有限的。大量的心理学研究表明，人类工作记忆的容量大致只有4 ，即在短期同时关注4项信息[2] ，再多的信息就要靠分模块的方式记忆，如我们快速记忆电话号码的方式，以13800001111为例，我们通常不是一个个数字背，而是形如：138-0000-1111进行分组。
在了解人的心智模型的一些基础假设和带宽后，我想很多系统软件开发者大概不再会炫耀：我的软件有1000多个监控项！这不仅不是好事，反而让更多的信息破坏了短期记忆的形成，引入了更多的噪音，让使用者在信息的海洋里花很多时间找关键信息，以及不自觉的分类（我相信大脑的一个不自觉的后台任务就是对信息建索引和分类，注意这同样是消耗带宽的），所以第一个结论：软件应用一屏的界面里面最好只有4个关键信息。那么，接下来的一个问题是：哪些是关键信息？什么是噪音？
3、区分关键信息和噪音
这个问题没有标准答案。对于系统软件来说，我的经验是：跟着关键资源走。软件其实很简单，本质就是对硬件资源的使用和分配，讲究平衡的艺术。关键的硬件资源无非也就下面几个，对于下面每一个关键资源在某个采样时间段（单点没有太多意义），都可以通过一些简单的问题的询问，得到对系统运行状态的大致图景：