01 · 问题
架构问题很少以架构问题的面目出现。它们表现为项目延期、线上故障、不断上升的变更成本，以及招不到人。
从内部很难看清——团队已经习惯了这些限制，并视之为理所当然。需要外部视角，把真正的限制与习惯区分开来。
02 · 适用场景
- 在业务扩张、重大投资或更换技术栈之前
- 变更成本上升，交付速度下降
- 反复出现原因不明的故障
- 新任技术负责人需要一份客观的全景评估
- 在引入 AI 和智能体之前——弄清可以依托的基础
03 · 分析内容
- 架构与业务目标和约束的匹配度
- 系统边界、耦合度、数据流
- 可靠性、可扩展性、可观测性
- 安全与数据处理
- 技术债务及其实际代价
- 架构决策流程
04 · 工作方式
-
步骤 01
业务背景
业务目标、约束条件、发展规划。架构以此为基准来评估，而不是对照抽象的“最佳实践”。
-
步骤 02
调研
代码、基础设施、文档、故障记录、团队访谈。
-
步骤 03
评估
按优先级排列的风险和限制——哪些是关键问题，哪些可以缓一缓，哪些根本不是问题。
-
步骤 04
建议
具体的解决方案，附依据、备选方案和工作量估算。
05 · 交付成果
具体交付内容在诊断之后确定。我不会事先承诺效果数字——它们取决于起点，并作为成果标准写入计划。
- 01现有架构描述——架构图、数据流、依赖关系
- 02按优先级排列的风险与限制清单
- 03附依据和备选方案的建议
- 04变更路线图
- 05与技术团队和管理层的结果解读会