Knowledge / Column 02
技术验证需要确认什么
目录上看不到的实际运行特性和兼容性。
本页整理技术验证需要关注的观察点与基本流程。
本页整理技术验证需要关注的观察点与基本流程。
约 7 分钟2025.01
Why Validation
为什么需要验证
为避免导入后出现“与预想不同”的情况，事前验证不可或缺。
目录规格 ≠ 现场表现
基准测试值与实际流量模式不一定一致。
与其他厂商产品的互联
多厂商环境下，组合可能产生兼容性问题。
最新固件的陷阱
新功能添加的同时，可能影响稳定性或现有功能。
设计书不等于现实
设计阶段的前提条件与现场不符时，可能无法按预期运行。
Validation Points
验证的主要观察点
性能
不是看目录数值，而是看在实际环境中能发挥到什么程度的性能。
冗余配置
验证切换时的行为和单侧故障时的影响范围。
互联互通性
发生故障或高负载时会呈现怎样的行为。
运维操作性
确认CLI、GUI、日志的易读性等日常运维的便利性。
安全性
确认配置项、认证方式、日志记录等是否能实际维护。
固件/OS更新时的行为
提前确认更新步骤、所需时间、回滚的便利性。
Validation Flow
技术验证的基本流程
1
前期访谈
确认需求、限制条件与现有环境，明确验证目的。
2
制定验证计划
整理测试用例、观察点与优先级，作为计划达成共识。
3
构建测试环境
在可能范围内准备接近生产的配置，备齐必要的设备和工具。
4
测量・复现
就各个观察点进行实测与运行确认。
5
制作报告
汇总结果与分析、推荐配置和注意事项。
1
前期访谈
确认需求、限制条件与现有环境，明确验证目的。
2
制定验证计划
整理测试用例、观察点与优先级，作为计划达成共识。
3
构建测试环境
在可能范围内准备接近生产的配置，备齐必要的设备和工具。
4
测量・复现
就各个观察点进行实测与运行确认。
5
制作报告
汇总结果与分析、推荐配置和注意事项。
Case Study
技术验证中值得确认的代表性例子
Case 01
按推荐配置无法实现冗余的例子
即使按照推荐配置设计，实际也可能存在无法实现冗余配置的限制。
可以确认的内容： 仅靠桌面推演难以判断，需要实机确认。
Case 02
特定组合导致性能下降的例子
单独没问题的设备，在某种组合下吞吐量可能大幅下降。
可以确认的内容： 改变流量模式进行确认，可以定位成为瓶颈的条件。
Case 03
遇到规格书未记载限制的例子
在接近实际运行的并发连接数下测试，可能遇到规格书未明确的限制。
可以确认的内容： 可以基于确认结果重新审视配置值与组网结构。
目录规格上看不到的实际运行行为和兼容性。
在导入前通过验证加以确认，
可以降低运行开始后才发现与前提不符的风险。