一种应用于业务系统大平台的可实现自动闭环运营的方法与流程

本发明涉及it应用，特别涉及一种应用于业务系统大平台的可实现自动闭环运营的方法。

背景技术：

1、传统的平台运营一般是通过设置客服电话和配套的运营工具来收集用户的咨询、建议和问题。然后进行等待处理，处理完后，通过系统和电话反馈给用户，需要耗费较多的人力，而且时效性低，不够智能。整体现有运营运维系统信息化水平较低，海量应用的建设、使用、运营、评估缺乏全链路数字化闭环式管理，导致整体运营服务质量不高，体系不全，建设成效难以掌握。主要的问题是：

2、(1)运营运维信息化程度低

3、当前，众多的信息化项目和平台基本处于初建状态，所以运维运营方面存在不少问题，大量的依赖传统的人工处理，如任务未进行电子化、工单化、标准化。人工投入不仅造成工作效率极低；

4、(2)运营运维数据深度分析不足，规划依据不足

5、平台中的大量项目上架，大量应用被使用，平台和应用拥有海量的数据，目前还存在对数据的分析挖掘不够深入，无法深度分析，导致平台后续规划依据不足；

6、(3)考核评估缺乏客观数据依据

7、为了有效管理平台、项目和应用，需要对平台、项目、应用的质量进行考核，但目前还缺乏基于客观引用运营运维数据的考核评估体系，平台考核无法做到客观公正；

8、(4)平台数据分散无法总览

9、目前各信息化综合平台在建设、使用、评估、运营等存在的数据凌乱分散在各系统，由各角色人员分别管理，对于总建设方，无法在一处对平台的各方面信息进行总览；

10、(5)故障处理效率还待提升

11、平台运行过程中，应用上架使用后出现问题，目前依赖人工电话沟通，人工问题咨询、人工逐个检查问题出处等情况，还未有有效的工具处理复杂多变的问题，还无法对问题进行精准定位，快速预警和反馈，问题解决效率还整体较低；

12、(6)沟通协调成本高

13、随着越来越多的项目新生成，参与的企业和企业人员众多，沟通协调成本高，工作错综复杂，没有系统进行统筹规划安排。同时相关的知识文档未进行归档沉淀，经验没有归纳总结，复用难，造成资源浪费。

技术实现思路

1、本发明要解决的技术问题，在于提供一种应用于业务系统大平台的可实现自动闭环运营的方法，依托大数据技术，打造对应的运营框架和多维评估引擎，打造良性自闭合式运营体系，实现自动化运营，降低运营人员投入，节省成本。

2、本发明是这样实现的：

3、一种应用于业务系统大平台的可实现自动闭环运营的方法，包括如下步骤：

4、步骤10、梳理并分析需要的指标，将指标数据来源相关的所有业务系统的数据通过etl工具抽取到运营数据中心，将运营数据中心的原始数据进行过滤和识别，挑选出与运营主题相关的信息，并将不同主题的信息进行分类，形成不同类型的主题库；

5、步骤20、将不同类型的主题库数据进行统计分析，形成不同维度的指标库里面的指标；

6、步骤30、根据指标库里面的指标，按设定组合规则进行封装，形成特定的模型；组合规则根据多个指标的不同权重的组合形成，或者多个指标通过指定的算法组合形成；

7、步骤40、根据形成的模型对指标进行计算分析，并设定对应的标准，若分析结果不符合标准，则会进行自动运营处理或自动预警提醒。

8、进一步地，所述主题库包括平台主题库、应用主题库、运营运维主题库以及微服务主题库，各个主题库之间逻辑结构独立。

9、进一步地，所述指标库包括项目指标库、平台指标库、微服务指标库、运维指标库以及应用指标库；

10、所述项目指标库，用于对项目从立项、验收和结项进行数据分析和统计，提供项目整体情况和项目验收情况的指标；

11、所述平台指标库包括pc端工作指标和移动端工作指标；

12、所述微服务指标库包括微服务上线运行指标和应用微服务指标；

13、所述运维指标库包括保障情况指标、运维情况指标、知识库情况指标；

14、所述应用指标库包括应用建设情况、应用评价情况、应用合规情况、应用报障情况、应用数据情况、应用使用情况。

15、进一步地，所述项目指标库包括项目立项数、项目系统数、项目应用数、人员到位数、项目合同金额数、项目支付金额、临期项目初验/终验数、延期项目初验/终验数、项目合作企业数；

16、所述平台指标库中，pc端工作指标包括pc端工作台登录次数和pc端基础应用打开次数；移动端工作指标包括移动端工作台登录次数和移动端基础应用打开次数；

17、所述微服务指标库中，服务上线运行指标包括微服务注册发布数量、各服务调用次数、各服务调用异常数；应用微服务指标包括移动端工作台登录次数、移动端基础应用打开次数；

18、所述运维指标库中，保障情况指标包括报障数、报障解决率；知识库指标包括资源数量、资源下载数；运维情况指标包括巡检次数、问题故障登记数、问题故障解决数、问题故障未解决数；

19、所述应用指标库中，应用建设情况包括地区应用上线数、业务应用上线数；应用评价情况包括应用意见建议、意见建议采纳数；应用报障情况包括应用报障数、应用已报障解决数；应用数据情况包括数据条数、数据存储量；应用合规情况包括应用上架审核数、应用上架审核通过数、应用上架审核不通过数；应用使用情况包括授权开通数、应用使用次数、各门户打开次数、应用下载次数、应用权限申请数。

20、进一步地，所述步骤30中，所述模型包括：用户平台月活跃天数模型、单位平台日活跃人数模型、单位平台月活跃人数模型、应用日活跃人数模型、应用月活跃人数模型、应用成效模型、好评应用模型、热门应用模型、不活跃应用模型、异常应用模型、报障top应用模型、最新上线应用模型以及异常服务模型；

21、所述用户平台月活跃天数模型用于统计单个用户的平台月活跃天数；所述单位平台日活跃人数模型用于统计某单位用户平台的日活跃人数；所述单位平台月活跃人数模型用于统计某单位用户平台的月活跃人数；用户平台月活跃天数模型、单位平台日活跃人数模型、单位平台月活跃人数模型均通过应用指标库中的应用使用情况指标次数指标和应用下载次数指标以及平台指标库中的pc端工作台登录次数以及移动端工作台登录次数组合封装得到；

22、所述应用日活跃人数模型，用于基于应用使用情况，统计应用的日活跃人数；所述应用月活跃人数模型，用于基于应用日活跃人数模型，统计应用的月活跃人数；两模型均通过应用指标库的应用打开次数指标封装得到；

23、所述应用成效模型，用于计算出各应用成效值，体现应用建设的成效；通过应用使用情况中的应用权限申请数、已授权开通人数、应用月活跃人数指标，应用数据情况中的数据总条数、数据总存储量指标，应用评价情况中的平均星级评价数指标，应用报障情况中的报障数、报障已解决数、意见建议数以及平均报障星级评价数指标封装得到；

24、所述好评应用模型，用于应用根据用户的评价进行排名；通过应用评价情况中的应用评价星级、各应用评价星级总个数指标以及应用使用情况中的已授权开通人数指标封装得到；

25、所述热门应用模型用于对应用根据用户的使用热度进行计分统计；通过应用评价情况中的应用评价星级、各应用评价星级总个数指标，应用使用情况中的已授权开通人数指标，应用数据情况中的数据总条数、数据总存储量指标封装得到；

26、所述不活跃应用模型，用于对不活跃的应用进行计分统计；通过应用使用情况中的应用使用数指标封装得到；

27、所述异常应用模型，用于对应用的异常情况进行计分统计；通过微服务上线运行情况中的应用所属服务调用异常数指标，应用使用情况中的应用打开次数指标封装得到；

28、所述报障top应用模型，用于对报障数量高的应用进行计分统计；通过应用报障情况中的应用报障数指标封装得到；

29、所述最新上线应用模型，用于对最新上线的应用进行展示；通过应用建设情况中的应用上线时间指标封装得到；

30、所述异常服务模型，用于对服务的异常情况进行计分统计；通过微服务上线运行情况中的应用各服务调用次数、应用各服务调用异常数指标封装得到；

31、所述异常服务器模型，用于对服务器的异常情况进行计分统计；通过链路分析情况中的应用jvm异常数、应用主机异常指标封装得到。

32、进一步地，所述步骤40中，自动预警提醒包括故障短信、站内信息、发送邮件。

33、本发明具有如下优点：

34、可实现自动闭环的运营，只需要较少的人工处理，有时不需要人工处理，极大的降低了人工投入成本。主要是借助大数据技术，构建运营数据中心和进行指标和模型开发，通过指标和模型的计算结果来提前预警或者实现自动运营处理。