Knowledge / Column 03
设计阶段必查的判断要点
仅按图纸制作，运维也难以稳定。整理了设计阶段应确认的要点。
约 6 分钟2025.01
设计决定结果的理由
系统和网络的质量，更多取决于设计阶段的判断而非构建作业。
8成在设计时决定
故障应对和运维便利性，几乎由设计时的前提和判断决定。
制作后往往为时已晚
布线和冗余化的前提，越到后期变更成本和风险越高。
"功能"不如"运维"成为瓶颈
即使满足功能需求，运维过于复杂也会导致系统最终无人使用。
Design Checklist
设计检查清单
故障时如何表现
停在哪里会影响到哪里，能否具体想到恢复步骤。
运维步骤是否现实
以现场人员、技能和时间而言，是否是可执行的运维设计。
是否留有扩展余地
是否能从容应对据点或用户数的增加。
性价比是否合适
不仅初期费用，包含运维成本和更新是否合理。
是否满足安全要求
是否符合策略、审计要求、零信任方针等实际要求。
更新步骤是否合理
更新或更换时，能否以现实可行的步骤进行停机和恢复。
Common Mistakes
常见设计错误及其原因
以为做了冗余却无法切换
单侧故障时的切换条件未纳入设计。
原因： 未进行实机确认，仅凭假设就判断已实现冗余。
现场运维过于复杂最终无法触碰
图纸上看似正确，但配置变更和故障应对流程与现场技能脱节。
原因： 被回避操作，结果形成黑箱化。
削减成本反而总成本增加
过度优先初期费用，导致运维工时和故障处理增加。
原因： 需要追加投资或重新设计。
意外的单点故障
未能发现负载集中在特定设备或链路的配置。
原因： 停机后才发现单点故障的存在。
Review Process
设计评审的推进方式
1
需求对齐
共享目标、限制、现有环境和内部规则，统一前提条件。
2
确认预期运维
具体确认由谁负责哪些范围、以何种步骤运维。
3
提示多个设计方案
不局限于单一方案，比较成本、灵活性和风险不同的多个方案。
4
风险梳理
梳理单点故障、运维负荷以及对未来变化的耐受性。
5
决定采用方案
明确判断标准后确定采用方案，推进到构建与验证。
1
需求对齐
共享目标、限制、现有环境和内部规则，统一前提条件。
2
确认预期运维
具体确认由谁负责哪些范围、以何种步骤运维。
3
提示多个设计方案
不局限于单一方案，比较成本、灵活性和风险不同的多个方案。
4
风险梳理
梳理单点故障、运维负荷以及对未来变化的耐受性。
5
决定采用方案
明确判断标准后确定采用方案，推进到构建与验证。