一点拙见-如何写好一个技术预研报告? - Mohuishou

最近做了一些预研的工作，主要是一些技术调研，报告呈现的过程当中收到了许多建设性的建议，同时包含一点自己的拙见，如果能给你带来一些思考，那最好不过。

明确面向对象

一篇好的文章，一份好的报告一定要考虑一下的你面向对象，如何能够让他可以随着你的思路快速简要的理解你想要传达的内容。那么，技术预研报告一般是给谁看的呢？请注意，我们这里说的报告是内部的调研报告，而不是例如一些专门做咨询的公司，提供给外部公司购买使用。这种报告的面向对象一般而言是你的上级，或者是上上级，或者是更高层级的领导。
这个时候分为两种情况，他懂技术，但是可能不了解细节，需要一些数据帮助他做决策，还有一种是他没有太多的技术背景，不是特别了解。

• 如果是不太了解技术的领导，要注意不能用过多的专业术语，在报告里面可以适当的添加一些说明，类比辅助理解，这个篇幅需要注意，也不能过长。
• 如果是比较了解的，可以更多的从技术方面进行分析，可以添加一些技术指标的对比。对于技术预研这种情况，一般还是这种情况居多。

接下来我就会从技术预研报告的一个最基础的模板说明每个部分需要有哪些内容，这个不是标准答案，这是我认为的一个报告当中必要的一些元素。

预研报告模板

技术预研一般是用来解决当下我们需要解决的一些问题的，可能这些问题用已有的系统或者技术暂时无法解决，或者是解决方法不够优雅，不够简洁等等。所以首先我们需要的是从现状出发，理清需求找准目标。问题来了怎么描述现状呢？我们先来看一个例子（注意本文所有示例数据均来源于虚构）:

一个例子:

• 反面教材: 集群内应用的资源设置不合理
• 正面教材: 最近一个月某区域集群节点 NotReady 告警次数超过 200 次，导致 30 多个应用 POD 漂移。其原因是由于应用超配比例过高，配置不合理
  • 数据说话: 最近一个月某区域集群节点 NotReady 告警次数超过 200 次
  • 影响范围: 导致 30 多个应用 POD 漂移
  • 原因: 应用超配比例过高，配置不合理

上面这个示例是一个最常见的错误案例，在现状分析当中，经常喜欢直接说问题的原因，不说这个问题导致的现象，以及影响范围。我们需要明白查看我们调研报告的观看对象是谁？往往是我们的上级或者是上上级领导，他们管理的产品比较多，不一定能够理解到十分细节。所以我们要从场景触发，首先降低沟通成本，罗列历史数据，增强说服力的同时可以帮助他们了解当前产品的现状。

如何说明现状?

• 从实际的场景出发，简明扼要的说明曾今出现过或者当前存在着的问题
• 用数据说话，统计历史数据，包含但不限于，影响范围，出现的次数，反馈用户人次等等

了解了现状之后，我们需要有一个心理预期的结果，我们期望理想状态下，能够达到什么程度，这一部分可以脑洞大一些，期望高一点，不要局限在眼前。

• 反面教材: 集群内应用随意漂移，可以减少集群中节点故障次数
• 正面教材: 为业务应用提供安全、可靠、稳定、舒心的服务，业务高峰时资源及时扩容，洪峰来临时，优先确保核心应用稳定，力争做到让开发早下班，运维不加班，周末无告警，假期无负担。

这两个例子里面，反面教材太过于务实了，这个只能说是居于现状的改进，不能说是对未来场景的想象，另一个是一个常见的场景加上一些形而上的想象。

如何畅享未来？

• 从场景出发，描绘理想状态下可以达到的状态
• 结合现状，切忌跑题，这是展望未来的时候，我最容易犯的一个错误，共勉。

站在巨人的肩膀上可以让我们看的更远，绝大部分的情况下调研时候的需求都会有一些业界的实践案例，甚至有一些开源的社区方案，例如 Google、亚马逊、阿里、腾讯等，这是说他们的方案是否适合我们，能否落地。
对于行业的实践这一块的内容，建议采用表格的方式进行对比，如果可以的话还可以做一些现场演示，或者是录制视频。

如上表所示，就是一个十分常见的一个对比表格，这里需要注意的是，一定不要忘记我们当前的现状是什么，最后可以有一个总结，说明不同方案的优劣之处，如果采用某个方案，后续是否需要更加深入的调研等等。

调研一定要有结论!
这里结论不是决策，也不是一定是方案，由于时间、精力以及了解到的信息等等限制，可能导致我们当下是无法得出一个决策，是否采用某个方案，但是一定要有结论，这个结论，既可以是一个方向上的建议，也可以是需要继续深入调研。切记不能仅为了调研而调研。

“没有反思和进步的人生不值得一过”，最近挺喜欢这句 Slogan，我觉得反思和总结可以进步更快，我的一点拙见或许由于我的视野原因，会比较狭隘，但是如果你如果看了这篇文章能有一些思考，无论认同与否，那都很值得。