2、需求分析：如何梳理业务需求？如何定义技术指标？如何评估团队能力？如何输出选型需求文档？

选型这件事，最怕什么？

最怕「拍脑袋」。我见过太多团队，上来就列一堆工具名字，然后开会吵架。吵到最后，选了个「名气最大」的，结果落地时发现跟业务八竿子打不着。

所以，在打开任何一款工具的官网之前，你得先做一件事——把需求掰开揉碎。

2.1 梳理业务需求：别让技术替业务做决定

业务需求是选型的「锚」。锚没抛对，船就会漂。

我个人习惯，先问三个问题：

• 谁在用？——开发、测试、运维，还是老板要看报表？
• 解决什么问题？——是代码规范、CI/CD 效率、还是线上故障定位？
• 现在怎么做的？——手工操作？脚本？还是压根没做？

举个例子。有一次我去帮一个团队做工具选型，他们说要「上 APM」。我问为什么，他们说「老板觉得慢」。我再问「哪里慢？哪个接口？什么时段？」——没人答得上来。

你看，这就是典型的需求模糊。后来我们花了两周，把线上接口的 p99 延迟拉出来，发现只有三个核心交易链路有问题。最终选型时，我们只关注了这三个链路的监控能力，省了一大笔钱。

梳理业务需求时，我建议用一张表来收口：

2.2 定义技术指标：把「感觉」变成「数字」

业务需求梳理完了，接下来要翻译成技术语言。说白了，就是定指标。

我见过最坑的指标是什么？「高可用」。99.9% 算高可用？99.99% 呢？不同工具对高可用的定义天差地别。

定义技术指标时，我一般分四类：

1. 性能指标：吞吐量、延迟、并发数。比如「单节点支持 1000 TPS」。
2. 可靠性指标：SLA、数据持久性、故障恢复时间。比如「RTO < 5 分钟，RPO = 0」。
3. 扩展性指标：水平扩展能力、API 限流、插件机制。比如「支持 10 节点集群」。
4. 运维指标：部署复杂度、监控对接、日志输出。比如「支持 Prometheus 指标暴露」。

技术指标定义好了，最好能画一张指标雷达图，把候选工具放进去对比。这样一眼就能看出谁强谁弱。

2.3 评估团队能力：工具是给人用的

这一点，很多人会忽略。你想想看，一个工具再牛，团队没人会用，或者学起来成本极高，那它就是废的。

我评估团队能力时，主要看三个维度：

• 技术栈匹配度：团队熟悉 Java 还是 Go？工具是用 Python 写的，团队能二次开发吗？
• 学习曲线：上手需要多久？有没有中文文档？社区活跃吗？
• 运维能力：团队有专职 SRE 吗？能接受自建还是必须买商业版？

举个例子。之前有个团队想上 Service Mesh，选型时看上了 Istio。但团队里没人懂 Envoy，连 Kubernetes 都刚入门。我建议他们先选一个轻量级的方案，比如 Consul Connect，等团队能力上来了再迁移。后来他们听了我的建议，半年后顺利切换到了 Istio。

2.4 输出选型需求文档：把一切写下来

前面三步做完，最后一步就是输出文档。文档不是为了给老板看，而是为了对齐认知。

我习惯用这样的结构：

1. 背景与目标：为什么要做这个选型？期望解决什么问题？
2. 业务需求清单：从 2.1 输出的场景和痛点。
3. 技术指标定义：从 2.2 输出的量化指标。
4. 团队能力评估：从 2.3 输出的团队现状和约束。
5. 候选工具列表：初步筛选的 3-5 个工具，附上理由。
6. 评分标准：每个指标的权重，以及打分方式。
7. 风险与备选：如果首选工具出问题，Plan B 是什么？

文档写完后，一定要拉上开发、测试、运维、业务方一起评审。我见过太多文档写出来就吃灰，因为没人签字确认。评审会上，每个人都要表态：「这个指标我认可，这个权重我同意。」

2.5 知识体系总览：一张图看懂需求分析

说了这么多，我画了一张图，把整个需求分析的流程串起来。你可以把它贴在墙上，每次选型前看一眼。

这张图把整个流程串起来了。你从左边开始，先梳理业务需求，再定义技术指标，同时评估团队能力，最后汇聚成一份需求文档。有了这份文档，后面的工具调研和 POC 才有据可依。

嗯，需求分析这一步，说白了就是「把账算清楚」。账算清楚了，选型就成功了一半。