維運平台場景案例

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、單機/叢集、容器化部署/非容器化部署等