architecture架构判断
约束堆到一定厚度，能选的结构反而没几种。我习惯先把边界和扩展路径摊在纸上，风险藏在哪儿也就露出来了。
boot / init jice --quiet
[ OK ] 加载判断顺序：问题 → 边界 → 失败场景
[ SKIP ] 跳过项目清单
[ WARN ] 技术选型排在最后
$ whoami jice 系统架构 / 工程效率
这页只回答一个问题：一套系统凭什么能撑很久。剩下的，写信问。
01
focus.log
关注什么reliability稳定运行
能跑不算数。看不看得懂日志、故障能不能退回去，这些才算。
automation效率工具
重复的活儿能脚本化就脚本化。省下来的注意力，留给真要拍板的地方。
02
man jice
怎么做事NAME
jice — 系统架构 / 工程效率
DESCRIPTION
我一般先把失败场景写下来。系统会在哪儿塌、塌了谁接、接不住怎么办，这些想不明白，选什么框架都差不多。
后面接手的人要能看懂，这比我这周写得快重要。这法子笨，但管用。
SEE ALSO
03