以下文章来源于韩锋频道 ，作者韩锋频道
数据库调研工作，是很多DBA都会参与的一项工作。其目的不一而足，可能是系统升级改造需要选型？可能是性能存在瓶颈需要优化？可能是为了节约成本考虑资源整合等等。无论出于什么目的，如何做好数据库调研工作做到信息详实非常重要。近期参与到多个项目迁移改造工作，需要了解各项目数据库运行情况，特整理了此调研模板。通过下发模板，收集调研数据，可以快速掌握数据库现状，为做出最佳技术方案做好准备工作。
1. 调研模板：基本信息
l被调研者
被调研者，可能是某个具体的个人或者某部门。
l被调研角色
被调研者角色很关键，不同角色视角也有所不同。有时为了全面了解一个系统，需要针对不同角色分别做调研后，将结果合并才能得到相对完整的视图。如果可能的话，最好是将相关人员拉到一起做沟通访谈，可以相对高效。
l调研形式
形式上可以采用多种，或者组合使用都可。
l调研时间
l调研目的
下面调研的内容很多，根据调研目的不同，其实是有所侧重的。在调研之初就明确目的，可以更好地圈定后面填写重点。
2. 调研模板：业务系统
（1）业务概述
业务情况是调研中第一位需要关注的。经常有一个误区就是只注重对技术侧的调研，而忽略了业务侧。很多业务系统都有一段“悠久”的历史，这些隐秘的信息其实对我们后期决策大有帮助。在这里可由业务方填写下，对业务系统的概述。
（2）业务说明
l使用者
这里填写业务系统的使用方，可能是某一部门或者是某一系统。
l交互方式
这里说的交互方式，是指使用这一业务系统的方式，可能是人来使用，也可能来自某应用系统或仅仅作为数据交互使用。不同的使用方式，对应后面使用特征差异较大。
l使用终端
不同使用终端，其使用行为也有所不同。例如APP的使用时长更加宽泛且可能热点集中于晚上等等。
l使用特征
这里可以更明确的标识出可用时长及热点时长，这有助于判断工作负载。下面三个选型，则从用户角度做了更进一步收集。
l重要级别
重要级别，主要是对业务可用性的判断很重要。后续在容灾、备份策略等都会参照这一指标。一般情况下，对于A/A+类系统，是要提供多活、至少双活的能力才可以。
l可用时长
可用时长，可针对业务使用时间简单做个分类，常见的可划分为上面几种。
l关联业务
如果此业务与其他业务系统有上下游关联，可在此一并写出。这里重点强调的是业务数据的关联性。这样有助于判断当业务出现问题时，波及影响的范围等。
（3）业务痛点
业务痛点这部分，会直击调研诉求本身，抓住核心痛点。对痛点更为详细的描述，有助于更好了解现有系统情况。
（4）未来发展
业务都是在不断发展演变中的，在调研评估中需要具备一定的前瞻性。这里包括对数据规模、访问量等变化的预估。
3. 调研模板：应用系统
（1）应用概述
此部分是描述数据库对应的应用系统情况。很多数据库在转型、优化等方面，是与应用有非常紧密的结合，甚至受制于应用的情况。因此，对应用的调研也非常重要。
（2）应用情况
l系统来源
系统来源是优先考虑的问题。因为底层数据库的变化，难免会影响到上层应用。如果应用是自研还好，如果是外采或云等除了考虑改造成本，还需考虑改造可行性。
l基础技术
栈针对基础技术栈，可简单描述于此。
l开发语言
开发语言与数据库也有着非常紧密的关系。当前很多数据库都做了兼容性策略，不需要应用在连接数据库上做什么改变。但还是有些重度绑定的问题，如在Oracle中使用Pro*C，就会面临比较头疼的迁移问题。
l语言版本
开发语言的版本。
l应用拓扑
可在此处描述应用部署的拓扑结构，这也有助于理解整个数据库之上的访问链路。
l交互方式
这里描述应用通过何种方式访问数据库，是通过IP、域名还是什么。此外是否启用了读写分离等策略。
l国产化诉求
应用系统的国产化诉求，例如芯片、操作系统、中间件及是否依赖其他（如加密机）等。
（3）特征分析
l系统来源
系统来源是优先考虑的问题。因为底层数据库的变化，难免会影响到上层应用。如果应用是自研还好，如果是外采或云等除了考虑改造成本，还需考虑改造可行性。
l基础技术栈
针对基础技术栈，可简单描述于此。
l开发语言
开发语言与数据库也有着非常紧密的关系。当前很多数据库都做了兼容性策略，不需要应用在连接数据库上做什么改变。但还是有些重度绑定的问题，如在Oracle中使用Pro*C，就会面临比较头疼的迁移问题。
l语言版本
开发语言的版本。
l应用拓扑
可在此处描述应用部署的拓扑结构，这也有助于理解整个数据库之上的访问链路。
l交互方式
这里描述应用通过何种方式访问数据库，是通过IP、域名还是什么。此外是否启用了读写分离等策略。
l国产化诉求
应用系统的国产化诉求，例如芯片、操作系统、中间件及是否依赖其他（如加密机）等。
4. 调研模板：数据库系统
（1）数据库概述
简要描述当前数据库的情况。
（2）数据库情况
l数据库产品
被调研数据库产品名称。
l数据库版本
被调研数据库的版本。
l数据库架构
数据库当前架构是什么？这里简单分类为单机、集中式、主从、分布式及其他。此部分的情况比较复杂，各数据库有差异，故下面增加说明部分，可填写文字补充。常见的Oracle RAC为集中式、MySQL Master/Slave为主从、TiDB为分布式等。
l部署拓扑
描述下当前的部署拓扑结构，最好能附加上拓扑图会更为直观。
l硬件环境
数据库硬件环境，这有助于判断资源的投入情况。如CPU、MEM、DISK的情况。
l软件环境
数据库软件环境。
l国产化诉求
数据库是否有国产化诉求。这点很重要，对于很多新兴数据库来说，国产化适配做得尚不完善，这里需要明确需求。此外，国产化还可能带来诸如稳定性、性能下降等问题，对未来的评估都会有一定影响。
l管理需求/组件
当前管理类的需求，此部分是很容易忽视的。例如当前数据库在管理、监控、告警、备份、转储等方面当前的能力如何。若考虑潜在的选型时，上述能力也是需要要求待选产品同步提供的。
（3）特征分析
l数据存量
数据存量有多少，这里需要考虑副本问题。如数据库改型，其副本数可能是有变化的，因此需要考虑单副本的大小，这是真实需求大小。
l数据增量
以月为间隔的增量数据大小。考虑到未来3~5年的需求，很容易估算出未来总大小。
l数据特征
数据特征比较宽泛，这里罗列了几种常见的。如数据分层、压缩、转储及热点情况。
l计算场景
对数据计算做个简单分类，可分为TP/AP/混合情况。这里的情况可能比较复杂，因此设置说明字段辅助说明。
l计算指标
常见的计算指标，如QPS、TPS、RT（上述主要是按峰值来考虑）及读写比。
l日志规模
以日为单位的日志规模，从中可大致判断出数据变化的总体情况。
l日志峰值
高峰时的日志情况，可评估出高峰压力及可能带来的副本延迟情况。
l数据库热点
如数据库有明显的热点，可在此说明。如热点的对象或热点的业务等。
l一致性要求
对于一致性来说，情况较为复杂，可简单划分为强一致和弱一致两类情况。这部分还需详细说明。
l扩展性要求
扩展方面，是按照自上而下的顺序，从接入层、计算层、存储层角度考虑扩展问题。每一层的扩展又可细分为Scale Up、Scale Out及组合情况。
l高可用要求
此部分特指对数据库的高可用要求，可按上面大致分类。
l高可用指标
具体指标上，就是常见的RTO、RPO的诉求，当然还需考虑同城异地问题。
l高可用方案
当前的高可用方案，可以在此描述。
l数据库特性
数据库特性，是指使用到了哪些数据库较为特殊的地方。常见的有特殊对象（如Oracle 的AQ）、计算过程（如存储过程等）或其他。这些部分都是在迁移改造过程中较难处理的，往往没有对应在数据库的解决方法，需要在应用侧解决。
l数据集成要求
数据集成类需求，需考虑数据上下游系统如何对接。如需要将上游数据导入到本数据库及还需按何种方式提供给下游数据消费等。
l数据消费要求
此部分是按照消费领域简单分类，如应用系统如何使用数据库、消费方如何使用、数据分析及可视化如何使用等。
l数据库报告
眼见为实，还是希望被调研方能提供类似数据库报告（也可报告如系统性能报告等）一手信息会更为直观。这些信息会包含更为丰富的内容，可供决策。
5. 调研模板：其他信息
（1）潜在方案
l技术选型说明
如有潜在的数据库技术选型方案，可在此说明。
l应用改造方案
如有潜在的应用改造方案，可在此说明。
l实施交付方案
若有潜在的实施交付方案，可在此说明。
l核心技术难点
如有疑难问题，可集中这里说明。
l风险性说明
可能潜在的风险说明。
（2）其他说明
【END】
最后，感兴趣的公众号后台回复“资料”，我们整理了6个G数据平台、数据仓库、数据仓库、数据治理、企业数据化管理案例，供大家免费领取！
| 
