2. 直接原因 :我想弄一个自己从零搭建的新博客了。(才不是因为 xlog 比较卡)
3. TG 不适合 :我也想过在 Telegram 上写这个 TIL 的,不过这里不适合贴任何代码,甚至不适合写任何 500 字以上的内容。也就作罢。
4. 灵感来源 :从最开始 simonw/til 和 jbranchaud/til 这两人的博客我就知道了有 TIL 这种流派,最后一根稻草,其实是 LOTU$ 的 blog ,我看他有在记录之前各种折腾的一些过程。(受到鼓舞了)
---
至于为什么会有流派 TIL 笔记为什么值得写,可以看看这 simonw 的 What to blog about
故障排除(Troubleshooting)的定义与重要性: 故障排除被定义为系统地确定系统中不需要的行为的原因并修复它。文章强调了故障排除作为一项独立技能的重要性,认为它与具体领域无关,并且可以通过刻意练习来提高效率。意识到自己花费大量时间在故障排除上,作者决定提升这项技能。
故障排除的基本步骤:
* 退后一步(Step back): 以耐心、细致和坚持的态度进行故障排除,避免陷入盲目的问题处理。
* 确认调整正确的弦(Make sure you’re tuning the right string): 在开始修复系统之前,确保操作能够产生实际效果,例如通过CSS代码确认文件是否正确运行。
* 确定流程(Determine the flows): 了解“物质”(如电、水、数据)如何在系统中流动和转换,识别输入、输出和转换过程,并将系统划分为不同的子系统。
* 观察现象(Observe the symptoms): 观察系统应该发生什么和实际发生什么之间的差异,缩小受影响的子系统范围。
问题隔离与科学方法: 使用“科学方法”隔离问题,包括:
* 形成假设(Form a hypothesis): 根据症状或观察,对问题进行假设。
* 排除最简单的问题(Rule out the easiest and most likely problem areas first): 优先排除易于维修、曾经出现故障或承受机械应力的区域。
* 二分查找(Binary search): 如果无法确定问题区域,则使用二分查找法。
* 找到最简单的证伪方法(Find the simplest way to falsify my hypothesis): 通过“切割”系统,在怀疑问题所在的上游/下游测试功能。
获取信息与缩短反馈环:
* 从系统获取信息(Get information from the system): 尽可能多地从系统中获取信息,例如使用日志记录或调试器。
* 缩短反馈环(Shorten the feedback loop): 缩短重现问题所需的时间,以便更快地收集数据和测试解决方案。
风险意识与问题理解: 在故障排除前,评估风险(Know the stakes),包括对自身、他人和系统的潜在危害。深入理解问题(Understanding the problem),而不仅仅是替换零件,要找到根本原因,防止问题再次发生。
https://www.autodidacts.io/troubleshooting/
🔖 Melatonin: Much More Than You Wanted To Know — LessWrong #pinboard #sleep TO TREAT DELAYED PHASE SLEEP DISORDER (ie you go to bed too late and wake up too late, and you want it to be earlier) – Take melatonin 9 hours after wake and 7 before sleep, eg…