三个客户实际应用案例，教你用云端运维报告助力系统稳定、高效运行！

信息化时代，IT/信息部门在一个企业中所承担的角色越来越重要，因此加快IT/信息部门的转型是保证企业在新一轮竞争中弥补差距、扩大优势的重中之重。

在传统模式下，IT/信息部门更多是被动承接业务部门的需求，对遇到的性能问题做事后分析。这样的现状是无法满足企业信息系统稳定、高效的要求的，两个方面急需转型：

稳定：亡羊补牢到未雨绸缪——预判性能风险，前置解决问题

效率：被动响应到主动服务——提高开发人效，提升产出价值

想要实现这样的转变，需要信息人员对系统的配置信息、运行数据、访问情况、留存数据等都了然于胸，然而这些信息、数据的获取也需花相当可观的成本。

为了帮助大家解决上述问题，我们推出了云端运维报告功能，只需10秒操作即可一键上传日志信息，等待15分钟左右即可获得云端运维报告，包含上面提到的全部运维信息。

但有了运维报告之后，信息人员应该如何改进才能实现转型呢

今天我们给大家分享三个客户的真实使用场景案例，教您用好报告数据！

场景一：系统硬件风险规避

为了确保系统硬件配置足以支撑企业的稳定使用，需持续关注两个方面的数据：

1、当前总体性能占用情况是否到达瓶颈；

2、历史访问量增长速度预判超负荷风险。

根据两方面的情况做好风险预判，提前升级，前置解决。

实例：

都邦财险从19年11月第一次使用云端运维，至今已有9个月的时间。这期间信息系统处于较快的增长阶段，访问总次数增长了75%，访问总人数增长了60%。将每月的访问量监控及云端运维其他模块的趋势变化作为升级硬件的合理依据，服务器内存由原本的32G升级为现在的128GB。通过云端运维的阶段性月数据回看，一定程度上保障了系统的稳定运行，避免因内存溢出等性能问题导致宕机。

特殊地，都邦财险为双节点集群配置，两个节点配置相同，且负载均衡权重也相同，两个节点的负载应该是均衡的。但通过内存及CPU占用情况部分可发现，实际上严重失衡，长此以往可能会导致单节点宕机而增加整体系统稳定风险，运维人员通过报告及时发现了这一问题并找到帆软技术支持及时处理，规避了风险。

场景二：模板访问情况数据应用

模板是信息系统中开发者与使用者的交互载体，而模板访问数据反映使用者用的多不多，对开发者的工作有很多指导意义：

1、更合理的模板开发人力资源分配

2、更有针对性地模板推广活动

在模板开发人力有限而业务需求膨胀的情况下，只有将其用在高价值需求上，通过推广手段确保小应用，方可提高开发人效、提升产出价值

实例1：

永辉超市总体的系统报表是按照架构、根据每个层级去设计的，因为永辉的用户规模极大，有20000之巨，因而这样会更加符合用户的使用习惯（比如管理线路：总裁-省总-区域总-店长-课长，每个层级关注的数据维度是不一样的），所以永辉在设计的时候就给每个层级都定义了该层级的视角。

核心目标是要关注实际使用与预期差距大的模板，所以会从访问量低的模板入手，进而主动定位原因并采取动作优化：

模板既定开放人员有限

因条件改变，模板业务价值降低

其中第二种很多是一些临时想法，后面由于各种原因就未有后续；或者为了验证业务人员的想法而做的一次性模板。针对这部分永辉会定期做一次优化：

提取报表、开发者、近60天访问次数（部分报表设计初衷就是一个月只需看一次，所以取近60天）、服务人数

通过近60天访问次数和服务人数，大致判断这个报表的价值（访问量层面）

找作者了解这种报表背景

case1：比如比赛成绩，一个一般就看几次，门店及以上管理者人数也在个位，所以访问量不高是合理的，且必须要有，那么这种表会继续保留

case2：对于原本就设计给门店层级使用但访问量低的情况，需进一步寻找原因（如权限开放问题，模板推广问题等）定位后进行进一步对策，并观察下个月的数据是否改善，以此闭环持续提升模板使用率

实例2

都邦财险每月会直接通过模板访问量排名监控异常差异

模板1为当月新增模板，会重点关注其首月访问情况；

模板2是在当月有业务上的清理应收动作，所以访问量增加较多，此类和业务活动相关的变更有助于信息人员进一步掌握相应模板访问规律；

模板3是移动端报表，且已经稳定使用了1年多了，访问量在当月下降了60%，属于严重的问题，都邦会记录在案，并做出相应的分析——主要原因是模板所展现的意健险保费收入下降，将此问题反馈给业务部门后得到妥善处置。

通过该功能对访问量的监控，能协助确定报表权重，为报表的更新迭代提供基础，也可以反映一些业务问题提供给行营团队。

需特别说明的是，此应用场景在都邦对接人员反馈给云端运维团队后，经确认此应用价值据有普遍性，故对模板就行了优化，增加了访问量变化率的指标，并突出显示异常数据，便于此场景更好地直接应用，云端运维欢迎大家有这样的功能建议多和我们反馈，进而提升报告的易用性。

场景三：建议优化模板列表应用

信息部门除了关注模板用得多不多，还关心模板用得好不好，最直接地体现在模板耗时上，定位到耗时异常环节方可有的放矢地优化：

1、报表计算耗时

2、SQL耗时

耗时是表象，所反映出的性能隐患才是关键，通过耗时异常预判潜在问题模板、在未引起严重后果前调优，前置解决问题。

实例

珠海水务目前的新报表开发任务由三名工程师承接，经验与水平有一定差异。但是受限于人力问题，所有模板开发完成后都经由经验更丰富的工程师一个个验收是不现实的。

此时建议优化模板列表就起到一个自动检验、暴露潜在问题模板的作用：如表中反映的部分执行时间较长的报表，经排查是一名并不太熟悉SQL语句的工程师所开发，编写了大量低效查询语句导致SQL耗时过长，在发现问题后及时对相关模板的SQL数据集语句进行了优化，最终这些报表加载速度明显提升。

对其他操作次数多、且响应时间超过5秒的报表，珠海水务的信息团队会组织讨论与优化、对于因页面上计算元素过多导致的响应慢问题，也会从数据库内优化存储，或与业务部门商议改善制表方式等形式，综合提升报表使用者的用户体验。

场景四：宕机卡顿协助排查

宕机问题虽然对很多企业来说可能并不常见，但一旦发生可以说对企业的影响是极其严重的。宕机问题发生后除了需要尽快恢复正常使用外，还需追溯导致宕机的原因，进而避免后续再次发生。

实例

某央企8月19日早晨8点半左右集群环境一节点宕机，联系帆软技术支持进行了排查：

1、通过对应目录下寻找hs_err_pid 开头的文件、kill 相关内容、dump文件、session opened for user xxx等条件，结合其GC情况及客户人员手动重启的信息，可判断此宕机为堆内原因导致，且内存突变时间拐点为08:24:58及08:25:04

2、通过云端运维直接内存判断来看，未有宕机记录；接着看内存负载：在系统卡顿的两个时间点与gc日志中出现内存较高的两个时间点，时间完全一致；

3、钻取该时间点详情，发现正在使用的大模板是report/xxx.cpt

4、经客户确认，这个时间段确实有用户查看了这个报表，因而定位到此次宕机是由于这个大模板导致，后续针对 reportxxx.cpt 这个模板进行单独分析优化。

目前云端运维已有超过1600家企业用户，欢迎对信息系统运维有更高要求的企业加入云端运维的大家庭，也希望更多的云端运维老用户能和大家一起分享云端运维更多的使用场景，参与云端运维标杆客户计划，更有丰富的F币奖励和云端运维绿色通道特权哦~

比如，目前市面上很流行的帆软公司的软件——finereport，功能算是前沿的，可做BI报表和大屏，包括数据整合、建模、分析、可视化制作图表，很适合企业使用。难度不算太大，而效果也不错。