数据库运维产品定位是一款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 原创发布于大家都是产品经理，未经作者容许，禁止转载。
题图来自Unsplash，基于CC0协议。
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。
