Architecture Review
Challenge a design without owning the team’s roadmap: clarify forces (scale, money, people, regulation), surface risks, and leave decisions traceable—usually as an ADR or review notes.
Inputs you need (ask early)
- - Goal and non-goals; users and SLAs; constraints (budget, deadline, org skills).
- Current pain—latency, incidents, cost, velocity—not buzzwords.
- Alternatives considered, even if rough.
Review lens (pick what fits)
- - Failure: blast radius, partial outages, data loss, replay.
- Ops: deploy model, rollbacks, observability, on-call load.
- Change: team size, Conway’s law, long-term ownership.
- Security: trust boundaries, secrets, supply chain—at architecture depth, not a full pentest.
Output shape
- - Summary of the proposal in your own words (catches misunderstandings).
- Top risks with severity; mitigations or experiments.
- Open questions for the team—not a pretend-final design.
Not this
- - Replacing the team’s product judgment; rubber-stamping; 20-page templates nobody reads.
Done when
- - The team can explain what they decided, why, and what would falsify the choice later.
架构评审
挑战一个设计但不接管团队路线图：澄清驱动力（规模、资金、人员、法规），暴露风险，并让决策可追溯——通常以ADR或评审记录的形式呈现。
你需要的信息（尽早询问）
- - 目标及非目标；用户及SLA；约束条件（预算、截止日期、团队技能）。
- 当前痛点——延迟、故障、成本、开发速度——而非空泛术语。
- 已考虑的备选方案，即使只是粗略想法。
评审视角（选择适用的）
- - 故障：爆炸半径、部分宕机、数据丢失、回放。
- 运维：部署模式、回滚、可观测性、值班负载。
- 变更：团队规模、康威定律、长期所有权。
- 安全：信任边界、密钥、供应链——仅限架构层面，非全面渗透测试。
输出形式
- - 用你自己的话总结提案内容（可发现理解偏差）。
- 最高风险及严重程度；缓解措施或实验方案。
- 待团队解决的开放问题——而非假装已成定稿的设计。
不应做的事
- - 替代团队的产品判断；走过场式审批；无人阅读的20页模板。
完成标准
- - 团队能够说明他们决定了什么、为什么，以及未来什么情况会推翻当前选择。
