运维平台场景案例

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）获取日志分析异常

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

1）保障核心业务性能和稳定性

公司中有多个部门，可能存在高并发访问，需要优先确保一些重要业务/用户优先使用资源（例如领导使用，对外大屏，会议使用等）。

2）业务级别故障隔离，避免不同部门业务相互影响

系统中存在几张模板性能不好（大数据量导出/填报/预览），业务部门不希望对模板进行限制，但又不想影响到其他业务。

系统原本的模板正常运行，新增了一些功能业务后，希望先在单独环境中使用一段时间，不要影响到原有业务。

3）开发发布环境统一但互不影响

公司没有测试系统，测试和生产环境在同一个应用中，需要将他们隔离到不同节点，不互相影响。

运维平台提供资源分配相关功能。

1）资源优先级管理

管理员可对系统业务（目录、模板、仪表板、公共链接）和用户（支持按照部门、角色、用户筛选）进行优先级排序，确保高优先级业务优先调用系统资源

2）资源隔离

集群多节点应用，可以根据节点拆分为多个业务组，将不同类型的业务（按照测试/生产、原有/新增、预览/填报）放置到不同业务组中，确保互相不影响。

3）调度管理

使用调度管理功能，可检查系统中不同时段的调度压力，合理设置业务定时任务的触发时间。

4）组件管理

一个FR/BI应用中，有很多组件，运维平台可以限制每个组件对系统CPU和内存的占用，防止某个组件大量占用服务器资源，导致其他组件性能差

1）用户体验差：

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

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

2）管理员排查难：

无法衡量和定位问题

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

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

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

1）提前预警

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

2）数据还原

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

3）快速定位

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

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

1）无法异地备份

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

2）备份速度缓慢

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

3）还原逻辑复杂

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

4）备份内容不全

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

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

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

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

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