為什麼銀行需要 AIOps 和傘式監控，或是客戶關係基於什麼？

在 Habré 的出版品中，我已經寫過與我的團隊建立夥伴關係的經驗（這裡 討論了在創辦新企業時如何起草合夥協議，以免企業分崩離析）。現在我想談談如何與客戶建立合作關係，因為沒有他們就沒有任何事情會破裂。我希望這篇文章對開始向大企業銷售產品的新創公司有用。

我目前領導一家名為 MONQ Digital 實驗室的新創公司，我和我的團隊正在開發一款產品，用於自動化支援和營運企業 IT 的流程。進入市場並不是一件容易的事，我們從做一些功課開始，透過市場專家、我們的合作夥伴並進行市場區隔。主要問題是了解“我們能最好地治愈誰的痛苦？”

銀行進入前三名。當然，名單上的第一名是 Tinkoff 和 Sberbank。當我們拜訪銀行市場專家時，他們說：把你的產品介紹到那裡，銀行市場的路就打開了。我們試圖在那裡和那裡進入，但在俄羅斯聯邦儲蓄銀行等待著我們的是失敗，事實證明來自 Tinkoff 的人對與俄羅斯新創公司進行富有成效的溝通更加開放（也許是因為當時的儲蓄銀行） 買 我們的西方競爭對手幾乎有十億）。一個月內我們開始了一個試點計畫。這是怎麼發生的，請繼續閱讀。

我們多年來一直在處理營運和監控問題，現在我們正在公共部門、保險、銀行、電信公司實施我們的產品，其中一個實施是與航空公司合作（在該項目之前，我們甚至沒有認為航空業是一個非常依賴IT 的行業，現在我們真的希望，儘管有新冠疫情，該公司能夠崛起並起飛）。

我們製作的產品屬於企業軟體，即AIOps（IT營運人工智慧，或ITOps）部分。隨著公司流程成熟度的提高，實施此類系統的主要目標是：

1. 撲滅火災：辨識故障，清除碎片中的警報流，向責任人員分配任務和事件；
2. 提高IT服務效率：減少解決事件的時間，指出故障原因，增加IT狀態的透明度；
3. 提高業務效率：減少體力勞動量，降低風險，提高客戶忠誠度。

根據我們的經驗，銀行在監控方面與所有大型 IT 基礎設施一樣存在以下「痛點」：

• 「誰知道呢」：技術部門很多，幾乎每個人都至少有一套監控系統，而且大多數都有不只一套；
• 「蚊群」警報：每個系統都會產生數百個警報，並轟炸所有對此負責的人（有時也在部門之間）。很難持續保持對每個通知的控制重點；由於數量眾多，其緊迫性和重要性也被削弱；
• 大型銀行——行業領導者不僅希望持續監控其係統，了解哪裡存在故障，還希望了解人工智慧的真正魔力——使系統能夠自我監控、自我預測和自我糾正。

當我們來到 Tinkoff 的第一次會議時，我們立即被告知他們在監控方面沒有問題，也沒有任何傷害他們，主要問題是：“我們能為那些已經做得很好的人提供什麼？”

談話很長，我們討論了他們的微服務是如何構建的，部門如何工作，哪些基礎設施問題比較敏感，哪些對用戶不太敏感，“盲點”在哪裡，以及他們的目標和SLA是什麼。

順便說一句，銀行的 SLA 確實令人印象深刻。例如，優先順序 XNUMX 的網路可用性事件可能只需幾分鐘即可解決。當然，這裡的錯誤和停機成本是令人印象深刻的。

因此，我們確定了幾個合作領域：

1. 第一階段是傘式監控，以提高事件解決速度
2. 第二階段是流程自動化，以降低風險並降低 IT 部門規模擴展的成本。

只能透過處理多個監控系統的資訊才能將多個“白點”塗上鮮豔的警報顏色，因為無法直接獲取指標；還需要將不同監控系統的數據集中到“一屏”，以便了解正在發生的事情的整體情況。 「雨傘」適合這個任務，我們當時就滿足了這些要求。

我們認為，在與客戶的關係中非常重要的一點是誠實。在第一次交談和計算許可證成本後，有人說，由於成本如此之低，因此可能值得立即購買許可證（與上面有關綠色銀行的文章中的 Dynatrace Klyuch-Astrom 相比，我們的許可證費用不是12 億的三分之一，而是1 GB 每月XNUMX 盧布，對於Sber 來說，費用會便宜幾倍）。但我們立即告訴他們我們有什麼和沒有什麼。也許大型整合商的銷售代表會說“是的，我們可以做一切，當然購買我們的許可證”，但我們決定把所有的牌都攤在桌面上。在發佈時，我們的盒子還沒有與 Prometheus 集成，帶有自動化子系統的新版本即將發布，但我們尚未將其交付給客戶。

試點計畫開始了，邊界也確定了，我們有兩個月的時間。主要任務是：

• 準備新版本的平台並將其部署在銀行的基礎設施中
• 連接2個監控系統（Zabbix和Prometheus）；
• 透過 Slack 和簡訊向負責人發送通知；
• 運行自動修復腳本。

試點計畫的第一個月是為了滿足試點計畫的需要，以超快速模式準備了新版本的平台。新版本立即包括與 Prometheus 的整合和自動修復功能。感謝我們的開發團隊，他們幾個晚上都沒有睡覺，而是在沒有錯過之前做出的其他承諾的最後期限的情況下發布了他們所承諾的內容。

在我們設定試點的過程中，我們遇到了一個可能提前結束專案的新問題：為了透過 SMS 向即時訊息發送警報，我們需要與 Microsoft Azure 伺服器的傳入和傳出連線（當時我們使用這個平台）向Slack 發送警報）和外部發送服務SMS。但在這個專案中，安全是一個特別關注的焦點。依照銀行的政策，這種「漏洞」在任何情況下都不能開啟。一切都必須在閉環中進行。我們被提議使用我們自己的內部服務的 API，透過 SMS 向 Slack 發送警報，但我們沒有機會直接連接此類服務。

與開發團隊進行了一晚的辯論，最終成功找到了解決方案。在翻閱了積壓的工作後，我們發現了一項我們從未有足夠時間和優先順序的任務 - 創建一個插件系統，以便實施團隊或客戶可以自己編寫附加元件，從而擴展平台的功能。

但我們還剩下一個月的時間，在此期間我們必須安裝所有東西、配置和部署自動化。

根據我們的首席架構師Sergei介紹，插件系統的實作至少需要一個月的時間。

我們沒有時間...

只有一種解決方案—去找客戶並按原樣告訴客戶一切。一起討論截止日期的變化。它奏效了。我們得到了額外的兩週。他們也有自己的截止日期和內部義務來展示結果，但他們有 2 週的儲備時間。最後，我們把一切都賭上了。不可能搞砸的。誠實和夥伴關係再次得到了回報。

透過試點，獲得了幾項重要的技術成果和結論：

我們測試了處理警報的新功能

部署的系統開始正確接收來自 Prometheus 的警報並對它們進行分組。來自 Prometheus 用戶端的問題警報每 30 秒就會發出一次（未啟用按時間分組），我們想知道是否可以將它們分組到「傘」本身。事實證明這是可能的——在平台中設置警報的處理是透過腳本實現的。這使得實現幾乎任何處理它們的邏輯成為可能。我們已經以模板的形式在平台中實現了標準邏輯 - 如果您不想提出自己的東西，您可以使用現成的邏輯。

“合成觸發器”介面。設定對來自連接的監控系統的警報的處理

建構了系統的「健康」狀態

根據警報，建立影響配置單元 (CU) 運作狀況的監控事件。我們正在實施資源服務模型 (RSM)，它可以使用內部 CMDB 或連接外部 CMDB - 在試點專案期間，客戶沒有連接自己的 CMDB。

用於使用資源服務模型的介面。飛行員 RSM。

嗯，事實上，客戶端終於有了一個單一的監控螢幕，可以看到來自不同系統的事件。目前，「保護傘」上連接著兩個系統——Zabbix和Prometheus，以及平臺本身的內部監控系統。

分析介面。單一監控畫面。

推出流程自動化

監視事件觸發了預先配置操作的啟動 - 發送警報、運行腳本、註冊/豐富事件 - 未在該特定客戶端上嘗試後者，因為在試點計畫中，沒有與服務台整合。

動作設定介面。向 Slack 發送警報並重新啟動伺服器。

擴展產品功能

在討論自動化腳本時，客戶要求提供 bash 支援以及可以輕鬆配置這些腳本的介面。新版本做了更多的工作（能夠在 Lua 中編寫成熟的邏輯結構，並支援 cURL、SSH 和 SNMP），並實現了允許您管理腳本生命週期的功能（建立、編輯、版本控制） 、刪除並存檔）。

用於使用自動修復腳本的介面。透過 SSH 伺服器重啟腳本。

主要發現

在試點期間，還創建了用戶故事，以改進當前功能並為客戶增加價值，以下是其中一些：

• 實現將變數直接從警報轉發到自動修復腳本的功能；
• 透過Active Directory為平台新增授權。

我們也面臨更多的全球挑戰—用其他功能「建構」產品：

• 基於機器學習而不是規則和代理自動建立資源服務模型（可能是現在的主要挑戰）；
• 支援其他腳本和邏輯語言（這將是 JavaScript）。

在我看來， 最重要的這個試點展示了兩件事：

1. 當有效的溝通建立在誠實和開放的基礎上時，與客戶的合作夥伴關係是有效性的關鍵，並且客戶成為在短時間內取得重大成果的團隊的一部分。
2. 在任何情況下都不需要“定制”和構建“拐杖”——只需係統解決方案。最好多花一點時間，但做出一個可供其他客戶使用的系統解決方案。順便說一句，這就是發生的事情，外掛系統和消除對 Azure 的依賴為其他客戶提供了額外的價值（你好，聯邦法 152）。

來源： www.habr.com