如何做好一次技术调研？

我一般是综合现有资源去考虑，满足需求的情况下尽量不增加系统复杂度，能不加组件就不加。
比如日志我们就没有选 ELK ，因为本身系统没有引入 ES ，但是 Grafana 和 S3 都在用，就自然会选 Loki ，后面如果搜索实在太弱也可以上 OpenObserve 这种比较轻量级的。

我觉得做技术调研，不在于什么技术是最新的，什么技术是最好的，而是在于什么是最适合当前局势和未来发展的。所以，你做技术调研前一定要明确当前公司的局势和痛点。

比如你说的日志收集场景：
1 、请问下当前已有的日志哪里不好？
2 、直接查询机器里的 log 文件存在什么问题呢？
3 、目前公司的服务多吗，日志量大吗，是不是全公司都需要这样的日志收集？

先通过多反问多了解确定背景和目标。

然后再是了解当前业内有哪些解决方案，每个解决方案实施难度如何，优缺点是啥，是否能覆盖当前的背景和痛点，当前方案的意愿消耗如何。如果不能满足自己的需求，那么该方案是否能让人很快速的定制开发？

最后通过这些方面的了解，找到适合当前场景的方案给出结论。
还有最重要的一点，你的调研方案写好后，最好找组内同事一起讨论，看看别人的看法如何。

都写上 都写上, 评审会上让 leader/老板拍板

主要还是别被 “主流”，“经典”，“大厂也在用” 这些词糊弄住了。这些不过是方案的一些特点而已，他还有其它的优点和缺点，都要列出来调查清楚。而不是看见一个吹得好就用。

最最重要的还是要切合你们团队自己的实际情况。

比如你说的 ELK ，它的主要优点是什么，在达成这个优点的时候，需要付出怎样的搭建和维护成本。它的这些优点，对你们来说有多大提升，而成本对你们来说是不是能支付得起。

如果你们压根就不需要什么分析，dashboard ，那是不是只要个 log 定期收集汇总就行了，压根不需要数据库。
如果你们的日志量很少，那云服务厂商自己 log 解决方案给的免费额度是不是就够用了。
如果需要大量收集日志，也需要大量分析统计，那么你预计的数据量下，ELK 和 Clickhouse 都需要多少个节点，每个节点要什么样的配置？
这些节点配成的集群是不是要专人维护，维护需要的技术难度有多少？特别是故障恢复的难度有多大？
如果需要专人维护，那你们团队是不是有这样的人？或者有人对它感兴趣可以转型？没有的话，招人的难度有多大？成本有多高？

还是要从你们团队现有的资源，项目的规模，人员的情况来入手，选择适合你们的，而不是 “最流行” 或者 “最好” 的技术。尤其是当你在技术选型上有所纠结的时候，通常这个领域也没有一个能在所有方面压倒竞品的方案。

技术调研要先实操下，然后找几个关键维度列在一起比较下

能用就行，最少改动原则

首先要找头部的几个产品， 看看他们的是怎么实现的。找这些公司的技术人员，吃吃饭，取取经。

做个 demo 出来 然后跑下压力测试 借鉴下别人的优缺点