数据库运维产品调研分析小结

一、概述

数据库运维产品定位是一款to B数据库运维管理工具，产品功能主要发力在数据库运维上，这是由产品经理经过初步分析与调研，从众多组件运维方向中，选择了在手工运维中难度较高且更为重要的数据库方向，通过对运维部门进行问题与需求调研，并结合产品分析而制定了初步的规划内容，再经过一系列评审讨论后落地，后续持续规划与推广通过内外部反馈与产品分析推进。

二、内部产品调研分析

2.1 后端运维部门调研

运维部门的定位是面向公司的提供标准的运维方案与运维支持，由运维部门直接反馈出来的问题，都是具有代表性、有一定操作门槛、按照运维经验识别的优先级的问题，符合产品规划中尽量满足80%的业务需求的原则。所以在产品的MVP版本内容的制定中，首选调研对象为运维部门。

向运维部门调研数据库部分的整体结论，是围绕数据库的日常运维操作和可靠性延伸出来的需求，主要为主备切换、主从修复、数据备份恢复、参数变更等一些基础运维操作，此部分可参考各友商与业界的通用方法实现。

在此基础之上，根据运维人员多年经验提出需要着重关注主备、集群架构下的各组件状态，原则上运维操作不能影响数据库运行，备份需关注备份数据完整性。这部分可延伸出在各个运维操作中的操作顺序、状态预判断、状态预提醒等，都需融入整体的产品设计中。

2.2. 工单分析

工单是各实施无法独立解决的运维问题，以工单的形式向运维部门申请帮助。可将运维部门的工单进行汇总分析，使用此份作为持续规划的需求来源之一。

工单是直接由实施提出的原始内容，不同实施运维能力良莠不齐，首先就需要对工单进行分类整理，按问题数量进行排序。绝大多数内容会集中在比较基础的运维操作，如重启、参数修改等，可见这部分功能虽简单但必须包含在产品功能之中，满足最基本的运维场景；其余问题覆盖在主备管理、数据恢复中，这部分操作步骤较多，面对的场景也较多，如重建库与主备修复，都是数据恢复的范畴中，但所使用的方案却截然不同。

面对这类的问题，需要把所有场景都拉取出来，首先抽取最通用的操作，数据备份和恢复即为数据恢复的最基本操作，区别在于的是备份的方式（物理或逻辑）、备份的粒度（全库或部分库）、恢复的方式（全量、增量）面对不同场景时方案的选取与搭配。

运维产品本身就是一个较为标准化通用化的产品，需要将这些通用操作都拆解出来，根据不同场景下制定不同的方案，再将这些操作都灵活搭配起来去满足不同的场景，尽量做到最大通用的去满足各种业务场景。

2.3 用户反馈

用户的反馈是先通过产品的使用，检验产品是否满足自身需求，再对产品提出优化改进建议，是产品打磨的重要途径。

用户提出的问题都比较深入实际使用场景，产品经理首先需理解场景，去辨别该场景是否是涵盖在自身产品边界内的，如数据库运维产品定位是在运维，像业务方的数据脱敏并不涵盖在产品边界内，则暂时不考虑该场景；若在产品边界内，则先去分析此场景的通用程度，如某用户提出数据库需要在执行完某个操作后自动还原，此类操作就属于业务定制操作，可在通用的产品功能内部分满足，如定时数据还原功能，并开放出相应接口，让业务方进行对接，做到既满足业务场景又相对通用；产品边界内且通用的功能，就需深入场景寻找产品解决方案，并根据当前问题优先级与产品的节奏，从中筛选出优先级较高的问题纳入产品设计中。

2.4 前端调研

调研主要内容为与分公司前端实施人员、售前面对面沟通。

面向实施人员主要了解其日常工作内容，从日常运维场景出发提炼需求；前端实施是最频繁面向用户的人，经常受到用户的质疑和挑战。对于运维平台来说，实际使用的用户是客户方的运维人员，是深度的使用者，更关注产品细节。用户会提出质疑的原因有很多，如：产品没能解决一些关键问题，即当前用户的使用场景未覆盖、产品不稳定、操作体验不友好等等；从中可以收集到更多的业务场景和业务外的操作体验、可靠性、安全等需求，也可收集到实施在实际维护中的经验，将其与产品经验转化为解决方案。

面向售前人员主要了解产品在客户前讲方案时的反馈，可根据反馈进一步完善产品介绍材料、场景、话术，收集客户反馈的需求，完善客户画像等。

售前面向的客户通常是决策层，这部分客户更关注产品的整体而非细节，如产品技术架构、产品功能架构、与友商对标、产品收费等方面。从中我们可以收集到一些平时较难收集的友商信息、对整个产品技术体系的要求、汇报性方面的需求等，这部分其实非常重要，毕竟面向的对象是是否购买你产品的人，针对这部分需求，不停地补充友商产品对标的分析和能力、产品介绍材料编写，增强产品的竞争力。

2.5 现有客户分析

现有客户分析是根据现有产品的销售情况，提炼出有价值的信息，辅助产品推广策略。可将历史客户订单，按照区域、季度进行统计分析，筛选出销售量较高的区域与主要销售人员，作为产品推广的优先区域；结合季度销售情况，去安排产品推广时间节点；进一步可分析每个区域的客户情况，按照客户性质（互联网、私企、国企等）、客户规模（大、中、小）结合用户画像进一步完善产品推广策略。

三、外部产品调研分析

3.1 市场

随着数据库技术的发展，数据库运维管理也经历多个阶段的发展，从手动写脚本，到使用单点工具，走向构建云化服务化平台，未来可走向智能化自治进一步演进。

从需求侧看，企业需要统一的入口对数据库进行统一的管理，现阶段主要由数据库厂商、数据库生态厂商、云厂商三种厂商构成。数据库厂商主要投入在自身的数据库产品中，基本不提供跨自身产品以外的统一管理；云厂商一般需要与自身云资源进行深度绑定；数据库生态厂商累积了多年数据库服务经验，也正在从人工服务+工具，到云平台+服务模式进行转变。

3.2 友商

3.2.1 Qfusion

QFusion是一款基于Docker容器和k8s编排技术，提供MySQL、Oracle、MSSQL、PostgreSQL等关系型数据库服务的私有云平台，并且通过kubernetes官方社区的软件一致性认证。

功能清单如下：

Qfusion数据库运维功能较全面，基本覆盖了数据库运维的通用功能。功能设计上和其他友商也比较类似，国产数据库部分官网显示兼容了达梦。

3.2.2 Bytebase

Bytebase 是一款聚焦在团队协作场景下的数据库结构变更和版本管理的开源工具，主要解决研发工程师和 DBA在变更数据库结构时的协同问题。

功能清单：

（1）数据库托管

以数据库连接信息进行托管，支持以下数据库。

（2）环境管理

不同环境下绑定不同数据库，按环境指定备份策略、回滚策略等。

（3）数据备份

支持逻辑备份，可设置备份策略（每周、每天、保留时长）、支持立即备份。

（4）支持慢查询

（5）支持SQL编辑器

类似与Navicat：

（6）工单流程

Bytebase内置了一系列的业务概念和角色，如工作空间，开发者等，每个都有对应的管理员，在查询数据或导出数据时，有一系列的工作流程，需要不同角色的管理员进行审批。

Bytebase功能覆盖在开发和运维，偏向于开发运维的整体协作。

3.3 外部产品分析结论

• 友商产品功能已经趋近完整，数据库运维工具整体竞争力是会在于运维实施经验+业务场景的转化。
• 由于政策指向，信创数据库市场比重将越来越大，各信创厂商都有自己的运维工具生态，后续可聚焦于智能化运维，打出差异点。
• 产品分析需持续在整个产品生命周期，辅助产品规划。

四、 产品小结

从产品工作内容上看，从产品方向选择、MVP版本功能制定、持续迭代优化、产品推广等都需产品经理主导或参与推进。

• 产品方向的选择大多数都是承接公司产品战略的方式，从中再去分析出发力的点，没到产品总监级别都谈不上产品战略方向的制定；
• MVP版本功能很关键，是产品试水的突破口，需要进行上述一系列调研分析加上产品直觉；
• to B产品很重要的一点是，使用用户与购买决策者，往往是两批人，所以两者的需求都需兼顾到；
• to B产品推广大多两个途径，线上或线下的产品宣发，推广策略上首先要明确产品的用户画像，结合可收集到的各种产品、销售数据分析，并根据每个公司不同的组织架构和商务方式，去选择合适的渠道和方式进行产品推广，这个说起来就比较纸上谈兵，笔者自己也没闹明白，还在摸索中。

从产品规划上看，数据库运维功能都已较为成熟，信创数据库也需如目前主流数据库一样纳入整合；差异点会在业务场景的转化和智能运维上，业务场景的转化上需要深入场景，基于通用的操作适配出满足业务的解决方案；智能运维部分，现在AI风口正盛，利用AI进行智能运维与调优，包装成运维值守机器人，能说会道还可汇报，24-hour on call也挺酷的。

本文作者 @vivi 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！