一站式自助营业运维平台设计

一、现状背景剖析

业务系统功能研发上线后，用户在利用过程中会碰着各种各样的问题。

或是用户在前端页面能够查看的数据字段范围有限，无法知足用户业务开展所需信息清单，必需运维同事帮忙从后台理解到更多字段信息；

或是用户进行中的业务单据涌现非常，须要运维同事帮忙在后台排查定位并办理等。

为保障业务正常运转，须要高下游浩瀚系统能力的折衷合营。
由于各个别系分属在不同部门乃至不同公司，导致数据查询类运维问题大概率仅涉及到单个别系。

非常办理类运维问题较大概率会涉及到多个相互关联的系统，当在单个别系排查定位之后，须要高下游系统同步排查定位及合营修复。

而“官本位”思维作祟导致运维同事在所卖力系统排查定位好问题后将查询结果反馈给用户，用户拿着自己实际一知半解的结果信息连续向其他相应系统运维方连续咨询，直至问题办理。

如果深入剖析业务运维现状我们至少会问四个问题：

业务系统前端页面所展示信息为什么不能知足用户业务正常开展？运维事情是做事于用户的，但在运维过程中为什么须要用户作为链接的“桥梁”在不同系统运维方间通报信息？运维同事对后台数据库直接操作增编削查的行为是否得当、安全以及是否有更好的运维支持方法？业务开展过程中涉及到需修正业务数据场景的，根据过往履历现有支持路子可分为线上系统或线下纸质工单走完相应审批流程，然后用户将审批结果及需修正的数据信息交付系统运维同事来操作数据变。

这个过程中常常会涌现由于用户对需修正业务数据范围理解不敷，导致运维同事在实际操作时还须要与用户往来来往沟通，乃至须要用户根据多次沟通的结果重新提交数据修正单据并发起新的审批流程。

针对这种情形我们会问：业务数据修正诉求的提交及审批过程是否可以在同个别系内完成，并且是在完全定位需修正业务数据范围后再进行呢？

大家可能会问：是否可以把业务系统功能培植的足够健壮、足够完善，不涌现任何运维问题呢？这种理解思路是否具备可行性？我只能说空想很丰满，现实却不敷以达成。

因研发资源受限、业务不断发展且业务逻辑足够繁芜、产品经理综合能力有限、需求/项目上线韶光节点紧迫及高下游系统合营程度有限等等成分，都导致无法在业务系统功能设计、培植中做到尽善尽美。

因此，我们要置身于现实背景情形来思考如何办理用户业务运维所碰着的痛点。

现有业务运维逻辑对用户而言类似于互联网电商行业常常提到的“人找货”模式，这种办法在互联网行业初期由于受限于根本举动步伐、技能水平等条件限定当时是适用的，后来随着根本举动步伐的不断完善，技能水平的持续提升，不断有很多更好的模式来为用户供应更好的做事。

当前互联网行业已经发展到“货找人”模式阶段，“货找人”模式追求的是基于用户诉求来从浩瀚的商品库中自动匹配用户最须要的物品，并展现给用户来决策。

“货找人”模式不仅减少了用户检索本钱，同时为用户尽可能供应了一站式做事。

那么在办理用户业务运维过程所遭遇的痛点中，是否可以利用类似“货找人”思维来构建一站式自助业务运维能力呢？

答案是肯定的。

二、平台产品能力设计

一站式自助业务运维的产品设计思路可以在如下几方面彰显其上风：

运维系统与业务系统是相辅相成的，运维系统作为业务系统的补充，在知足用户业务正常开展诉求的条件下可以作为用户需求的网络窗口，对付呼声强烈的运维功能逐步将其向业务系统迁移，助推业务系统的不断完善、健壮。
运维问题无论涉及到单个还是多个别系运维方，都支持用户在一站式自助业务运维系统内实现运维问题的提问、排查定位、审批及肃清办理等全流程动作闭环。
系统运维同事无需直接对数据库操作增编削查动作，在担保数据安全的条件低落低了运维同事重复作业的难度，并提高用户业务运维帮忙排查定位、办理的便捷性。

回归到用户业务运维提出问题的形式，大致存在三种类型：

清楚地理解运维问题关键信息，例如订单编码、问题类型及须要达到的目的等。
大致理解运维问题，能够从业务层面给出自己理解的问题描述。
有干系运维问题的系统截图，由于对系统理解程度不深，以截图形式来提问。

2.1 产品架构图

一站式自助业务运维平台能力可以办理用户运维过程中所碰着的痛点，并且可以根据用户提出问题形式的不同来对应分配相应产品能力。

以数据库资源为根本，搭建包括场景化运维及机器人应答能力，并且业务运维平台与高下游系统实现账号体系打通并联动，设计的赞助模块功能紧张是从数据安全层面实现用户可查看、操作数据的隔离。
（如图1）

图1 一站式自助业务运维平台产品架构图设计

聚焦办理用户业务运维问题痛点，如下会分别对一站式自助业务运维平台关键产品模块进行先容。

2.2 场景化运维能力

如果用户清楚地理解运维问题关键信息，场景化运维能力可供应支持，实现运维问题”提出->定位->审批（如需）->办理”的闭环办理。
假设订单已到货但无法验收。

用户在场景化运维能力中输入相应订单号，选择查非常，就可以看到按照订单全生命周期信息流转轨迹所呈现的最新状态及非常定位点，和需操作动作“重推ERP”，用户点击“重推ERP”按钮即可办理此问题。

比拟原来在系统运维方排查定位好问题后，用户登录到业务系统并找到对应页面中可操作按钮进行操作的流程，极大简化了运维问题办理的难度，并且处理效率也有极大提升。

假设在排查定位好运维后须要修正业务数据，则在当前页面展示将要修正的数据范围清单，用户提交审批后，各节点审批方都可以看到待修正数据范围清单，并且在审批通过后系统自动完成数据修正。

在前端所展示的信息全生命周期信息中包含业务节点清单和运维节点清单：

1）业务节点是用户在业务系统中可以看到的状态节点信息；

2）运维节点在业务正常开展过程中对用户是不可见的，仅是系统运维方在数据库维度对数据流转轨迹的跟踪。
（如图2）

图2 场景化运维能力设计

2.3 自助应答能力

如果用户大致理解运维问题或有干系运维问题的系统截图，提问的运维问题信息先由OCR技能及NLP对其解析语义，然后根据运维问题类型由RPA机器人决定调用知识库或场景化运维能力排查定位问题并给出下一步应实行动作，同样极大简化问题办理的难度并提升了处理效率。

一站式自助业务运维平台前端页面所展示信息该当对用户是可理解的，例如数据库字段名应转化为中文名呈现等。
（如图3）

图3 自助应答能力设计

2.4 配置化能力

随着业务的快速发展，运维系统也须要合营支持快速迭代更新。
当前系统迭代办法更常见的为固定时间停机、发版、上线的模式，此种模式不仅会导致系统在某段韶光内不可用，并且新功能开拓周期较长，进一步降落了系统的可用性。

为办理系统迭代过程中此类不敷，可通过前端可配置模块来实现，配置化能力支持场景化能力逻辑、知识库、审批流、数据字典及账号权限等在担保系统始终可用的条件下实现了新能力/旧能力更新等无需发版快速上线。
（如图4）

图4 配置化能力设计

三、总结

屈服“以用户为中央，以做事用户为核心，以办理用户痛点为重心”的原则，一站式自助业务运维平台的搭建不仅可以很好地办理用户现存运维过程中碰着的的各种痛点、难点，在保障安全的根本上，通过一站式自助业务运维及配置化敏捷迭代的双轮驱动模式，加持智能化技能手段提高效能的同时助力用户产品体验的极大提升。

本文由@践行知行合一 原创发布于大家都是产品经理。
未经容许，禁止转载。

题图来自Unsplash，基于 CC0 协议

该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。