运维平台场景案例

1）没有收集宕机信息

发生了内存宕机类问题，由于生产环境，必须要第一时间恢复环境，没有来得及登录到后台输入命令收集宕机信息，导致问题无法定位。

2）无法24h值班监守

夜间发生了宕机，由于没有人24h监控，或者由于没有办法触碰到内网环境，导致第二天才能够恢复，导致发生了生产事故。

运维平台自动识别宕机情况，并且自动采集宕机信息，采集完信息后，自动重启工程，保证工程持久运行。

1）宕机前的预防

为了防止宕机时无人值守，需要开启宕机处理策略，确保运维平台可以自动重启工程。

2）宕机时的采集

宕机时，自动导出内存堆栈日志信息

3）采集后的恢复

宕机信息采集完成后，运维平台帮助管理员自动重启工程、恢复进程。

4）恢复后的分析

宕机时，运维平台会自动导出内存堆栈，可以给出针对宕机的原因分析和解决方案，可以自动对宕机堆栈进行分析。

1）组件配置修改麻烦

组件配置在运维过程中经常需要修改，每种组件修改位置和方法不完全相同，容易修改错误，因此修改成本高

对于FR/BI项目组件。管理员常常需要对Nginx/Redis/配置库进行配置修改

对于FR/BI工程，管理员常常需要修改工程配置，确保工程平稳运行

2）修改后重启组件麻烦

组件的配置修改，一般都需要配合组件的重启

重启组件一般都需要登录到后台操作，操作成本高

配置修改万一出错，需要反复重启，成本加倍

针对Nginx/Redis/配置库、FR/BI工程，

运维平台分别提供界面化组件修改和组件启停功能

1）工程节点多，管理麻烦

一个FR/BI集群项目，在多台服务器上分布着各个节点，管理员需要监控每一个节点正常运行

2）集群组件多，管理麻烦

一个FR/BI项目，不仅只有FR/BI组件，还有外接数据库、负载转发、状态服务器、文件服务器等组件，管理员需要监控每一个组件正常运行

3）监测组件配置异常

除了确保以上服务器、工程、组件的正常运行，管理员需要监控他们的配置是否正常，是否有异常现象

当出现异常之后，类似于负载异常或组件连接异常，管理员需要能及时收到相关通知信息，而不是事后补救

4）日志获取困难，分析门槛高

为了分析这些异常，管理员需要登录到这些服务器后台去拿对应的日志，获取很困难

通过一个运维平台可以对接多个节点/应用，同时能够监控多个环境，任意一个节点/应用出现问题都可以统一预警，也能够通过运维平台方便的获取到信息。

1）监控项目正常运行

项目是否可用、节点是否正常、组件是否启动

2）界面化查看项目配置

服务器监控、应用监控、组件监控

3）项目出现异常时预警

企业微信预警、邮件预警、webhook预警

4）获取日志分析异常

支持在线查看日志分析结果，支持下载日志到本地自行分析

用户向管理员反馈，感觉系统使用卡慢

用户使用某种仪表板/模板时，感觉卡慢

2）管理员排查难：

无法衡量和定位问题

需要被动的等待用户反馈问题

需要自行拿日志、打堆栈，排查问题，门槛高

FineOps运维平台提供健康观测与链路追踪功能，帮助管理员定位用户查看、分析仪表板/报表的性能卡慢问题。

1）提前预警

管理员可以自行查看系统健康观测，在用户反馈前主动发现系统出现了卡慢，无需被动等待

2）数据还原

将用户实际体验，以数据形式准确展示出来

3）快速定位

还原用户真实体验，并将定位时间从缩短至10分钟内

FineReport/FineBI提供了「备份还原」功能，但是存在一些不足。

1）无法异地备份

工程部署在A服务器上，备份的内容也在A服务器上，结果小明误删除的时候，把工程和备份都删除了。

2）备份速度缓慢

随着工程中的模板、数据越来越多，应用备份的速度越来越慢了。

3）还原逻辑复杂

JAR包、模板、配置都是分开备份的，但是大多时候需要将这些内容按照时间点统一备份还原。

4）备份内容不全

一些重要内容不在备份还原范围内，会影响工程的正常运行，例如classes、resources等。

为满足客户的新需求以及完善之前版本某些功能的不足之处，FineReport/FineBI在不断地更新迭代。

无论何种场景，在对FineReport/FineBI进行升级之前，都必须对工程进行备份，尽量对除了状态服务器和负载均衡服务以外的工程进行完整备份。

因为可能存在一些意外情况，导致更新对配置库进行了更改，或部分资源文件出现问题，必须保证升级失败后可以快速回退。

简单介绍，对于内网/外网、FineReport/FineBI、单机/集群、容器化部署/非容器化部署等工程，不同情况下的最佳升级方案。