VTB IT部門多次需要處理系統運作中的緊急情況，系統負載倍增。 因此，需要開發和測試一個模型來預測關鍵系統的尖峰負載。 為此，該銀行的 IT 專家設定了監控、分析數據並學會了自動預測。 我們將在一篇簡短的文章中告訴您哪些工具有助於預測負載以及它們是否有助於優化工作。
幾乎所有行業都會出現高負載服務的問題，但對於金融業來說，這些問題至關重要。 在X小時，所有作戰單位必須做好準備，因此有必要事先知道可能發生的情況，甚至確定負載跳躍的日期以及哪些系統會遇到負載。 需要處理和預防故障，因此甚至沒有討論實施預測分析系統的必要性。 有必要對基於監測數據的系統進行現代化改造。
膝蓋上的分析
薪資項目是萬一失敗最敏感的項目之一。 這是最容易理解的預測方法，所以我們決定從它開始。 由於高連接性，包括遠端銀行服務 (RBS) 在內的其他子系統可能會在高峰負載時遇到問題。 例如，對收到款項的簡訊感到滿意的客戶開始積極使用它。 負載可能會跳躍一個數量級以上。
第一個預測模型是手動建立的。 我們取得了去年的上傳數據，並計算了預計出現最大高峰的日期：例如 1 日、15 日和 25 日，以及該月的最後幾天。 該模型需要大量的勞動力成本，並且無法提供準確的預測。 儘管如此，它還是發現了需要添加硬體的瓶頸，並透過與主力客戶達成一致，優化了轉帳流程：為了不一次性發工資，來自不同地區的交易隨著時間的推移而被間隔開。 現在，我們將它們分成銀行 IT 基礎設施可以「咀嚼」而不會失敗的部分進行處理。
收到第一個正面結果後，我們開始進行自動化預測。還有十幾個關鍵領域正在等待輪到他們。
綜合方法
VTB 實施了 MicroFocus 的監控系統。 從那裡我們收集了用於預測的數據、儲存系統和報告系統。 事實上，監控已經就位，剩下的就是添加指標、預測模組並建立新報告。 這項決定得到了外部承包商 Technoserv 的支持，因此實施該專案的主要工作落在了其專家身上，但我們自己建立了模型。 此預測系統是基於Facebook開發的開源產品Prophet製作的。 它易於使用，並且可以輕鬆與我們安裝的整合監控工具和 Vertica 整合。 粗略地說，系統分析負載圖並根據傅立葉級數進行推斷。 也可以每天加入取自我們模型的某些係數。 無需人工幹預即可獲取指標，每周自動重新計算一次預測，並將新報告發送給收件人。
這種方法確定了主要的周期性，例如每年、每月、每季和每週。 薪資和預付款的支付、假期、假期和銷售——所有這些都會影響系統的呼叫次數。 例如，事實證明，有些週期相互重疊，系統的主要負載（75%）來自中央聯邦區。 法人實體和個人的行為有所不同。 如果「物理學家」的負載相對均勻地分佈在一周中的幾天（這是很多小交易），那麼對於公司來說，99,9%都花在工作時間上，交易可以很短，或者可以在幾個小時內處理完畢。分鐘甚至幾個小時。
根據所獲得的數據，確定長期趨勢。 新系統顯示，人們正在集體轉向遠端銀行服務。 每個人都知道這一點，但我們沒想到會有這樣的規模，一開始也不相信：銀行辦事處的電話數量正在極快地減少，而遠程交易的數量卻以完全相同的數量增長。 相應地，系統的負載也在不斷增長並將繼續增長。 我們現在預測 2020 年 3 月之前的負載。 正常日的預測誤差為 10%，高峰日的預測誤差為 XNUMX%。 這是一個很好的結果。
陷阱
和往常一樣，這並非沒有困難。 使用傅立葉級數的外推機制不能很好地跨越零——我們知道法人實體在周末產生很少的交易，但預測模組產生的值遠離零。 強行糾正是可以的，但拐杖不是我們的方法。 此外，我們還必須解決從來源系統輕鬆檢索資料的問題。 定期收集資訊需要大量的運算資源，因此我們使用複製來建立快速快取並從副本接收業務資料。 在這種情況下，主系統上不存在額外負載是一項阻塞要求。
新挑戰
預測高峰這項簡單的任務得到了解決：自今年30月以來，該銀行沒有發生過與超載相關的故障，新的預測系統在其中發揮了重要作用。 是的，事實證明這還不夠，現在銀行想了解高峰對其來說有多危險。 我們需要使用負載測試中的指標進行預測，對於大約 XNUMX% 的關鍵系統來說，這已經有效，其餘系統正在獲取預測。 在下一階段，我們將不再預測業務事務中的系統負載，而是預測 IT 基礎架構方面的負載，也就是我們將向下一層預測。 此外，我們需要完全自動化收集指標並基於它們建立預測，以免處理下載問題。 這沒什麼特別的——我們只是根據全球最佳實踐交叉監控和負載測試。
來源： www.habr.com