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、单机/集群、容器化部署/非容器化部署等工程，不同情况下的最佳升级方案。