有些系统从架构图上看并不复杂，但维护它的人仍然觉得累。
累的来源往往不在组件数量，而在那些没有被系统表达、只能由人记住的关系。
“这个任务显示运行中不一定真的运行中，要再看日志。”
“这个 GUID 在A表里叫 deviceId，在B表里才叫 guid。”
“这个状态字段的0、1、2没有字典存储对应含义，备注里也没有，该问谁呢？”
每句话都不长，合在一起却构成了系统的隐形操作手册。它没有版本，没有测试，通常只存在于几个人的记忆和聊天记录里。
复杂度会转移，但不会消失
为了赶进度省略状态机，复杂度（和绝望一起）会转移给排障的人；不设计失败恢复，复杂度（和崩溃一起）会转移给部署现场。
代码少了，不代表系统简单了。可能只是把逻辑从机器能执行的地方，搬到了人必须记忆的地方。
把记忆还给系统
并非所有知识都值得写成代码。可反复造成事故的隐性规则，应该逐步找到归宿：
| 人脑中的提醒 | 更合适的归宿 |
|---|---|
| 参数不能同时开启 | 配置校验 |
| 操作必须遵循顺序 | 状态机或工作流 |
| 某字段全局唯一 | 数据库约束 |
| 服务异常要重启 | 进程守护与健康检查 |
| 发布前必须执行某命令 | CI/CD |
人的注意力很有限，在设计系统之初应该尽可能保证不要被后续无端消耗，而是把人的注意力留给需要判断的地方。
可靠的知识通常有多层表达：代码负责强制，测试负责举例，日志负责解释，文档负责讲清为什么。
一个系统是否容易维护，可以看新人多久能开始工作；也可以看老成员休假时，团队是否仍然从容。
如果某个人不在线，系统就突然失去一部分能力，那么那部分能力还算不上完全属于系统。