1、技術創新，變革未來民生銀行數據庫智能運維實踐運維數據中臺運用ES，Hadoop，Flink, KAFKA，Redis，關系數據庫，時序數據庫等技術，整合各種監控數據，日志文檔數據， 配置數據，關系數據，知識庫等數據來源，結合AIOPS分析資產，建立運維數據中臺，為運維決策提供數據支 撐。實時計算引擎采用分布式計算框架，緩存數據庫等實現實時數 據處理，運用人工智能技術實現運維數據價值挖 掘。智能算法庫集成Sklearn、statsmodels 、tensorflow、pytorch、 prophet等AI算法庫，利用pandas，numpy，sycipy、 matplotlib等數據分析工具，自

2、研智能運維相關算法并 落地。智能運維服務實現軟硬件各類產品智能深度運維。同時對外提供自助服務， 通過自定義指標，關系和服務的方式，用戶可以實現個性化智 能運維。實時計算引擎智能算法庫智能運維服務運維數據中臺集中監控AIOPS監控PAAS監控天眼日志CMDBAIOPS發現天旦系統應用調用鏈產品文檔AIOPS問題產品缺陷庫智能場景流計算異常檢測實時告警圖計算告警聚類根因分析大數據分析模型訓練相關性分析智能算法指標異常檢測關系異常檢測智能場景聚類容量預測日志異常檢測故障預測告警收斂根因定位系統畫像監控數據集中監控AIOPS監控PAAS監控天眼日志CMDB元數據知識庫AIOPS發現產品文檔AIOPS問

3、題天旦系統應用調用鏈產品缺陷庫智能場景數據采集實時告警DB2自助服務定義指標定義關系定義服務自助推送基礎軟件深度運維OracleMysqlRedisJVMKAFKAWeblogicTomcatOS搽智能調度產品深度智能運維異常檢測，根因分析，智能場景，故 障預測監控告警優化使用動態閾值，提高告警準確性和相 關意義日志異常檢測通過比對日志和知識庫來報告問題和 分析解決問題智能告警分析實時分析相關告警，定位核心問題民生銀行數據庫智能運維實踐產品深度運維1應急“雙十”底線最長十分鐘分析時間 最長十分鐘救急時間2運維數據“價值”海量運維數據價值如何挖掘支撐海量運維指標.需要采用無監督學習方法，減少人工

4、標注成本異常檢測根因分析一步定位到問題sql.問題SQL執行詳情分析，定位問題原因.智能場景指標告警收斂.便于普通用戶使用，提供告警場景解釋和對應的解決方案.民生銀行數據庫智能運維實踐數據庫深度運維應用效果民生銀行數據庫智能運維實踐數據庫深度運維實現方法對象選擇數據庫全局指標作為檢測對象數據庫的事務，SQL等作為根因定位對象性能訓練性能如何保證 實時處理性能如何保證T算法采用無監督學習算法，多種算法合成集成算法 可選時間序列算法，提升周期性檢測能力展示指標聚合層次化展示，基于智能場景告警5前臺匯總異常總數曲線圖4Delta數據基于模型檢測，保存結 果3歷史數據定期進行訓練，保存異 常模型6點擊

5、異常時間點展示樹形異常分 布圖7點擊異常指標展示相關SQL排序。 可查看當前指標歷史趨勢圖1采集DB SNAPSHOT全部指標數據。 發送到kafka。2從kafka獲取數據，加工delta數據在正態分布中代表標準差,代表均值x=即為圖像的對稱軸 三原則即為數值分布在（,+)中的概率為0.6526 數值分布在（2,+2)中的概率為0.9544 數值分布在（3,+3)中的概率為0.9974利用一種名為孤立樹iTree的二叉搜索樹 結構來孤立樣本。由于異常值的數量較少且與大部分樣本 的疏離性，因此，異常值會被更早的孤 立出來.異常值會距離iTree的根節點更近，而正 常值則會距離根節點有更遠的距離

6、。場景名稱日志寫盤異常場景字段名logdisk_abnormal相關字段LOG_DISK_WAITS_TOTALLOG_DISK_WAIT_TIMETOTAL_COMMIT_PROC_TIMETOTAL_COMMIT_TIME解決方案當前異常表示數據庫寫活動日志到磁盤出現異常。異常分析：一種原 因是IO延時高，需要警惕。建議結合操作系統，存儲信息來一起判斷。另一種原因是出現臨時大量INSERT|UPDATE|DELETE操作，寫日志 成 為 瓶 頸 。 可 以 參 考 當 前 時 間 的 ROWS_MODIFIED， ROWS_DELETED，ROWS_INSERTED，ROWS_UPDATE

7、D判斷是否發生突變。解決方案：找到寫數據的原因，分析是否是正常業務。如 果伴隨著LOG_BUFFER_WAIT_TIME，NUM_LOG_BUFFER_FULL異常，可以考慮增加數據庫參數Logbufsz的設置。排除是否是磁盤IO緩慢 原因，如有問題請聯系系統組分析解決。提升度表示含有Y的條件下，同時含有X的概率，與X總體發生的 概率之比置信度體現了一個數據出現后，另一個數據出現的概率，或者 說數據的條件概率。支持度就是幾個關聯的數據在數據集中出現的次數占總數據集 的比重Apriori算法民生銀行數據庫智能運維實踐案例分享某系統反饋在日終集中挪大量已核銷訂單的時候，在線交易受到了影響，當時平

8、均交易響應時間1秒左右。最近問題比較突出的時間是2020年3月10日凌晨。當時的cpu使用率最高是03分，也只有3.54%。因此硬件資源應該不是問題。從AIOPS平臺檢查當時的時間點數據庫有什么異常表現。從當時的時間點看，確 實有多個指標同時發生了異常。點擊智能分析命中場景發現有日志寫磁盤的告警，其中第一個關聯sql是影響最大 的sql。經檢查發現當時很多的DDL都發生了等待日志寫盤的行為。可見當時對日志寫盤 壓力是比較大的。繼續查看轉訂單SQL的執行詳情，等待時間占比很高，并且在等待事務寫入日志 緩存上。看一下受到影響的業務語句，在這個時間點出現等待日志緩存，而其他 時間點是沒有的。從圖中可以看到，業務sql當時出現了日志緩存等待，而其他時間沒有。另外的latch等待是次生產 物。分析結論：最終的分析結果是大量的ddl語句但是產生了大量日志，造成日志寫盤繁忙。同一時間內，大量訂單轉表語句執行，對日志緩存需求較高，導致業務語句使用日志緩存 也受到影響，因此造成了業務sql抖動。優化建議：數據庫參數調整： 建議本次維護窗口調整數據庫日志緩存為64M。 應用優化建議：1.2.建表建索引等語句建議和跑批錯開，減少資源競爭建議跑批語句拆分為更細粒度事務。減少跑批并發，錯峰跑批。智能運維與DBA的工作經驗運維裝機，變更監控，應急巡