说几个支撑业务到现在学到的经验：

1. 在有三年运维经验之前，记录各种日志导致日志清理配置错误/忘记删日志爆炸的概率比你救火的时候需要看日志的概率更大。（实际上，如果你的服务器没爆炸，你不需要管他，如果你服务器down了，你不需要日志就能看到现场）
2. 绝不要重构能用的代码，如果有任何问题，只做非常小步的迭代逐步替换过去。
3. 如果一个框架/工具需要看文档才知道怎么用，那么你最好还是自己写一个，救火的时候不会望着黑盒无从下手。
4. 多执行，少设计：除非你有120IQ以上，否则任何架构和代码设计都会沦为纸上谈兵，写不出三天就会改的面目全非；最好的办法是顺着用户交互的执行路径开始一路把需要的代码写出来。（从第一个窗口需要的代码开始写吧！）
5. 数据库是用来存数据的，别在上面玩触发器/数据库函数和其他插件花活。
6. 没有把握的时候，拉长release的间隔，观察发布的版本有没有用户在叫，一定要避免同时发布2个没有把握的变更！小心组合爆炸！
7. 在绝大部分情况下都不要使用自动化测试，这只会让你分不清到底是测试还是项目代码有bug。

https://x.com/llennchan2003/status/1927544463490003220?s=46

via Memos