http://dubbo.apache.org/zh-cn/docs/dev/principals/robustness.html

这一篇中的日志规则可以有效的借鉴：
日志
日志是发现问题、查看问题一个最常用的手段。日志质量往往被忽视，没有日志使用上的明确约定。重视 Log 的使用，提高 Log 的信息浓度。日志过多、过于混乱，会导致有用的信息被淹没。

要有效利用这个工具要注意：

严格约定WARN、ERROR级别记录的内容
WARN 表示可以恢复的问题，无需人工介入。
ERROR 表示需要人工介入问题。
有了这样的约定，监管系统发现日志文件的中出现 ERROR 字串就报警，又尽量减少了发生。过多的报警会让人疲倦，使人对报警失去警惕性，使 ERROR 日志失去意义。再辅以人工定期查看 WARN 级别信息，以评估系统的“亚健康”程度。

日志中，尽量多的收集关键信息
哪些是关键信息呢？

出问题时的现场信息，即排查问题要用到的信息。如服务调用失败时，要给出使用 Dubbo 的版本、服务提供者的 IP、使用的是哪个注册中心；调用的是哪个服务、哪个方法等等。这些信息如果不给出，那么事后人工收集的，问题过后现场可能已经不能复原，加大排查问题的难度。
如果可能，给出问题的原因和解决方法。这让维护和问题解决变得简单，而不是寻求精通者（往往是实现者）的帮助。
同一个或是一类问题不要重复记录多次
同一个或是一类异常日志连续出现几十遍的情况，还是常常能看到的。人眼很容易漏掉淹没在其中不一样的重要日志信息。要尽量避免这种情况。在可以预见会出现的情况，有必要加一些逻辑来避免。

如为一个问题准备一个标志，出问题后打日志后设置标志，避免重复打日志。问题恢复后清除标志。

虽然有点麻烦，但是这样做保证日志信息浓度，让监控更有效。

发现一个介绍 PyTorch 的playlist，动画效果属实不错，缺点是废话有点多。。建议1.25或1.5倍速 https://www.youtube.com/playlist?list=PLZbbT5o_s2xrfNyHZsM6ufI0iZENK9xgG

真正的思考技术：来自德国社会学 Niklas Luhmann 的 Zettelkasten 方法
https://mp.weixin.qq.com/s/XveXTT8GDjFv2rt9iMU2RQ

Devonthink擅长整理本地资料库，Evernote擅长搜集现有信息，GTD擅长项目管理，Roam Research 则擅长笔记写作，而他们都希望能够提高使用者的「生产效率」。

这段时间看了很多推 RR 的文章，我来唱个反调。我认为这个工具对于绝大多数人来说都是不适用的，理由是(1)我们现存的绝大多数知识并不是编译成网状结构的，(2)只有足够大量的信息才能让网状结构产生明显的效率提升。
对于第(1)点，目前绝大多数的知识都是以书本这种树状结构，或者课程这种线性结构记录下来的，如果你要用 RR 做网状的知识管理，意味着你必须要先理解这些知识，然后自行编译成网状结构，相当于人工进行了一次数据结构的转换。且不说这种转换的成本，传统的树状或线性结构的知识是学术界数十甚至上百年打磨而成的，是基于经验做过高度优化的，你自己编译出来的很可能并不能够比这些传统的更加优异，除非你能够召集一个学术界专门做这种结构转换。事实上，string theory 学术界曾经做过类似的尝试，几年了没啥起色。
对于第(2)点，神经网络的基本原理之一就是必须有足够的数据集才能让算法起作用，否则大概率过拟合。这一点对于RR 的信息管理功能非常重要。对于绝大多数普通人而言，我们日常处理的信息量应该是远远达不到让网状结构产生效率提升的地步的。
所以我认为 RR 这种模式最终会是小众的，因为绝大多数人手里的信息并不适合被以这种网状结构储存或分析，在做了一段时间的尝试以后最终会回归传统的结构。并不是说这种网状结构有什么问题，只是它不适合绝大多数人的需求罢了。我们在判断一个工具是否好用的时候，一定要注意不能仅仅看它提出的概念有多吸引人。每个工具都有自己适用的范围。超出这个范围，再好的工具也会很鸡肋的。