本文深入探讨了一站式自助业务运维平台的设计思路与实现方式，旨在通过智能化手段提升运维效率，优化用户体验，并确保数据安全。

一、现状背景分析

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

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

或是用户进行中的业务单据出现异常，需要运维同事协助在后台排查定位并解决等。

为保障业务正常运转，需要上下游众多系统能力的协调配合。由于各个系统分属在不同部门甚至不同公司，导致数据查询类运维问题大概率仅涉及到单个系统。

异常解决类运维问题较大概率会涉及到多个相互关联的系统，当在单个系统排查定位之后，需要上下游系统同步排查定位及配合修复。

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

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

• 业务系统前端页面所展示信息为什么不能满足用户业务正常开展？
• 运维工作是服务于用户的，但在运维过程中为什么需要用户作为链接的“桥梁”在不同系统运维方间传递信息？
• 运维同事对后台数据库直接操作增删改查的行为是否合适、安全以及是否有更好的运维支持方法？
• 业务开展过程中涉及到需修改业务数据场景的，根据过往经验现有支持途径可分为线上系统或线下纸质工单走完相应审批流程，然后用户将审批结果及需修改的数据信息交付系统运维同事来操作数据变。

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

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

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

因研发资源受限、业务不断发展且业务逻辑足够复杂、产品经理综合能力有限、需求/项目上线时间节点紧迫及上下游系统配合程度有限等等因素，都导致无法在业务系统功能设计、建设中做到尽善尽美。

因此，我们要置身于现实背景情况来思考如何解决用户业务运维所遇到的痛点。

现有业务运维逻辑对用户而言类似于互联网电商行业经常提到的“人找货”模式，这种方式在互联网行业初期由于受限于基础设施、技术水平等条件限制当时是适用的，后来随着基础设施的不断完善，技术水平的持续提升，不断有很多更好的模式来为用户提供更好的服务。

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

“货找人”模式不仅减少了用户检索成本，同时为用户尽可能提供了一站式服务。

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

答案是肯定的。

二、平台产品能力设计

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

• 运维系统与业务系统是相辅相成的，运维系统作为业务系统的补充，在满足用户业务正常开展诉求的前提下可以作为用户需求的收集窗口，对于呼声强烈的运维功能逐步将其向业务系统迁移，助推业务系统的不断完善、健壮。
• 运维问题无论涉及到单个还是多个系统运维方，都支持用户在一站式自助业务运维系统内实现运维问题的提问、排查定位、审批及消除解决等全流程动作
  闭环。
• 系统运维同事无需直接对数据库操作增删改查动作，在保证数据安全的前提下降低了运维同事重复作业的难度，并提高用户业务运维协助排查定位、解决的便捷性。

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

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

2.1 产品架构图

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

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

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

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

2.2 场景化运维能力

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

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

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

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

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

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

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

图2 场景化运维能力设计

2.3 自助应答能力

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

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

图3 自助应答能力设计

2.4 配置化能力

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

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

图4 配置化能力设计

三、总结

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