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

?CPU：哪些线程在工作？这些线程都在干嘛？这些线程各自消耗了多少CPUTime？
?内存：当前内存中存储了哪些东西？这些东西的命中率情况？（通常我们更关注业务缓存）？
?网络I/O：QPS/TPS有异常吗？当前主要的网络I/O是由什么请求发起的？带宽还够吗？请求延迟？长链接还是短链接（衡量syscall的开销）？
?磁盘I/O：磁盘在读写文件吗？读写哪些文件？大多数的读写是什么Pattern？吞吐多大？一次I/O延迟多大？
?关键日志：不是所有日志都有用，只有包含特定关键字的日志，人们才会关心。所以，有没有特定关键字的日志出现？
通过以上标准问题的灵魂拷问，必定可以对系统运行状态有一定的了解。
?更进一步的关键是，这些系统的指标一定要和业务上下文联系在一起才能好用，举例说明，对于一个支持事务的数据库来说，假设我们看到CPU线程和callstack ，发现大量的CPU时间花在了wait/sleep/idle之类的事情上，同时也没有其他I/O资源瓶颈，此时，如果只看这些的数字可能会一脸懵，但是结合事务的冲突率来看可能柳岸花明，甚至能直接给出这些lock的等待时间都花在了哪些事务，甚至哪些行的冲突上，这对观测者是更有用的信息。
也并不是说其他的信息就没用，而是相当多的信息的价值是后验的，例如：绝大多数的debug日志，或者那些为了证实猜想的辅助信息，其实在解决未知问题时候几乎没有帮助，而且还需要观察者有大量的背景知识，这类信息最好的呈现方式还是折叠起来，眼不见为净的好。
如果打开TiDB的内部Grafana就会看到大量这样的指标，如stall-conditions-changed-of-each-cf（虽然我知道这个指标的含义，但是我猜TiDB的用户里99%的人不知道），而且从名字里面我看到了写下这个名字的工程师内心的挣扎，他一定很想让其他人（或者自己）看懂这个名字指的是什么，但是比较遗憾，至少在我这里没有成功。
观察的下一步是什么？作出行动。
在做出行动之前想想，有行动的前提是什么？我们处理问题的行动大致会遵循下面模式（我自己总结的，但任何一本认知心理学的书都会有类似的概念）：观察—>发现动机—>猜想—>验证猜想—>形成计划—>行动，然后再回到观察，反复循环。
这个里面人（或者是老司机的经验）体现比较重要地方是在从观察到猜想这个环节，至于观察的动机而言无非有两种：
1.解决眼前的故障；
2.规避潜在的风险（避免未来的故障）。
假设系统没有问题，也不太需要做出改变。我觉得这两步之所以重要，是因为基本上其他环节都可以用自动化，唯独这两步很难，因为需要用到：人的知识/经验和直觉。
对于一个拥有好的可观测性的系统，通常都是能很好利用人直觉的高手，举个小的例子：当打开一个系统后台界面时，我们试着不去关注具体的文字信息，如果界面中的红色黄色的色块比较多，我们的直觉会告诉自己这个系统可能处于不太健康的状态，更进一步如果红色和黄色大致都聚集在屏幕的某个具体位置上，我们的注意力一定会聚焦到这个位置；如果一个界面上全是绿色，那应该是比较健康的状态。
怎么最大化利用人的直觉？或者说要引导到什么地方？我认为最好的点是：风险的预判。
4、人的直觉用在哪？风险的预判
此处需要利用一些先验知识。在聊这个话题之前，我想分享一个我之前听过的小故事，当年福特工厂里有个电机坏了，然后找了个老师傅，他听了听声音，看了看机器运转情况，最后用粉笔在电机上画了一条线，说这个地方的线圈多绕了多少多少圈，将信将疑的工人们照做，果然问题解决了，然后老师傅开了个1万美元的维修费（当时算是天价），福特的老板问他凭啥画一条线就收那么多钱，老师傅开了个账单：画线1美元，知道在哪画这条线9999美元。