なぜ銀行は AIOps と包括的なモニタリングを必要とするのでしょうか?また、顧客関係は何に基づいているのでしょうか?

Habrの出版物では、チームとのパートナーシップを構築した経験についてすでに書いています（ここで 新規事業を立ち上げる際に事業が破綻しないようパートナーシップ契約書を作成する方法について解説します。さて、ここでクライアントとのパートナーシップを構築する方法についてお話ししたいと思います。なぜなら、クライアントがいなければ何も崩れてしまうことはないからです。この記事が、大企業に製品を販売し始めたスタートアップ企業にとって役立つことを願っています。

私は現在、そのようなスタートアップである MONQ Digital lab を率いており、チームと一緒に企業の IT のサポートと運用のプロセスを自動化する製品を開発しています。市場参入は簡単な作業ではありません。私たちは少しの下調べから始め、市場の専門家やパートナーに相談し、市場の細分化を実施しました。重要な質問は、「誰の痛みを最もよく癒すことができるのか？」を理解することでした。

銀行はTOP3セグメントにランクインしました。そしてもちろん、リストの先頭にいたのはティンコフとズベルバンクでした。私たちが銀行市場の専門家を訪問したとき、彼らは「そこにあなたの製品を紹介すれば、銀行市場への道が開かれるでしょう」と言いました。私たちは両方に参入しようとしましたが、ズベルバンクは失敗し、ティンコフの人たちはロシアのスタートアップとの生産的なコミュニケーションにはるかにオープンであることがわかりました（おそらく、当時のズベルが 買った 西側の競合企業ではほぼ 10 億ドルです。 1か月以内に、私たちはすでにパイロットプロジェクトを開始していました。それがどのように起こったのかを知るには、読み続けてください。

当社は長年にわたり運用と監視の問題に取り組んでおり、現在は公共部門、保険会社、銀行、通信会社に当社の製品を導入しています。 1つの実装は航空会社向けでした（プロジェクトの前は、航空業界がこれほどITに依存する業界だとは考えてもいませんでしたが、今ではCOVID-19にもかかわらず、この会社が出現して飛躍することを心から願っています）。

当社が製造する製品は、企業向けソフトウェア、AIOps セグメント (IT 運用向け人工知能、ITOps) に属します。企業内のプロセスの成熟度が高まるにつれてこのようなシステムを実装する主な目標は次のとおりです。

1. 問題を解消する: 障害を特定し、アラートフローを不要なものからクリアし、担当者にタスクとインシデントを割り当てます。
2. IT サービスの効率を向上: インシデントの解決にかかる時間を短縮し、障害の原因を特定し、IT ステータスの透明性を高めます。
3. ビジネス効率の向上：手作業を減らし、リスクを軽減し、顧客ロイヤルティを高めます。

私たちの経験では、銀行はすべての大規模 IT インフラストラクチャに共通する次のような監視の「悩み」を抱えています。

• 「各人が自分のことを行う」: 多くの技術部門があり、ほぼ全員が少なくとも 1 つの独自の監視システムを所有しており、ほとんどの企業が複数のシステムを所有しています。
• 大量のアラート: 各システムが数百のアラートを生成し、すべての責任者に（場合によっては部門間でも）集中攻撃します。各通知に常に焦点を合わせるのは困難であり、通知の数が多いと緊急性と重要性が損なわれます。
• 業界のリーダーである大手銀行は、システムを継続的に監視して障害の発生箇所を把握するだけでなく、真の AI マジック、つまりシステムの自己監視、自己予測、自己修正を実現したいと考えています。

ティンコフでの最初のミーティングに出席した際、彼らはすぐに、モニタリングに問題はなく、何も問題がないと話してくれました。そこで主な質問は、「すでにうまくいっている人々に私たちは何を提供できるのか？」でした。

会話は長く続き、マイクロサービスがどのように構築されているか、各部門がどのように機能しているか、ユーザーにとってどのインフラストラクチャの問題がより敏感で、どの問題がそれほど敏感でないか、「盲点」はどこにあるのか、そして目標と SLA は何かなどについて話し合いました。

ちなみに、銀行の SLA は本当に素晴らしいです。たとえば、ネットワークの可用性に関連する優先度 1 のインシデントを解決するには、わずか数分しかかかりません。もちろん、ここでのエラーとダウンタイムのコストは相当なものになります。

その結果、いくつかの協力分野を特定しました。

1. 第一段階は、インシデント解決のスピードを上げるための包括的な監視です。
2. 2 番目の段階は、プロセスを自動化して、IT 部門の拡張に伴うリスクとコストを削減することです。

直接メトリクスを取得することは不可能であったため、複数の監視システムからの情報を処理することによってのみ、いくつかの「白い点」を明るい警告色で塗ることができ、また、何が起こっているかの全体像を把握するために、さまざまな監視システムからのデータを「1つの画面」に一元化する必要もありました。 「傘」はこの作業に適しており、当時の要件を満たしていました。

私たちの意見では、顧客との関係において非常に重要なことは誠実さです。最初の会話とライセンスのコストの計算の後、コストが非常に低いため、すぐにライセンスを購入する価値があると言われました (上記のグリーン バンクに関する記事の Dynatrace Key-Astrom と比較すると、当社のライセンスのコストは 12 億ではなく、1 ギガバイトあたり月額 XNUMX ルーブルですが、Sber の場合はその数倍安くなります)。しかし、私たちはすぐに自分たちが何を持っているか、何を持っていないかを彼らに伝えました。おそらく、大手インテグレーターの営業担当者は「はい、もちろんすべて対応できますので、ライセンスを購入してください」と答えたかもしれませんが、私たちはすべてをテーブルに出すことにしました。発売時点では、当社のボックスには Prometheus との統合がなく、自動化サブシステムを備えた新しいバージョンがリリースされる予定でしたが、まだクライアントに出荷されていませんでした。

パイロット プロジェクトが開始され、その境界が定義され、2 か月が与えられました。主な目的は次のとおりです。

• プラットフォームの新しいバージョンを準備し、銀行のインフラに導入する
• 2 つの監視システム (Zabbix と Prometheus) を接続します。
• Slack と SMS 経由で担当者に通知を送信します。
• 自動修復スクリプトを実行します。

パイロット プロジェクトの最初の 1 か月は、パイロット プロジェクトのニーズに合わせて、超高速モードでプラットフォームの新しいバージョンを準備することに費やされました。新しいバージョンには、Prometheus との統合と自動修復機能がすぐに組み込まれました。開発チームのおかげで、彼らは数晩眠らずに、以前に約束した他の期限を守らずに約束どおりにリリースすることができました。

パイロットを設定しているときに、プロジェクトを早期に終了させる可能性のある新たな問題が発生しました。メッセンジャーや SMS 経由で通知を送信するには、Microsoft Azure サーバーへの受信および送信接続 (当時、このプラットフォームを使用して Slack に通知を送信していました) と外部の SMS 送信サービスが必要でした。しかし、このプロジェクトでは安全性が特に重視されました。銀行の方針により、いかなる状況でもそのような「穴」を開けることはできない。すべてが閉ループで機能する必要がありました。 Slack や SMS 経由で通知を送信する独自​​の内部サービスの API を使用するように提案されましたが、そのようなサービスをすぐに接続する機会はありませんでした。

開発チームとの議論の夜は、うまく解決できる解決策が見つかることで終わりました。バックログを徹底的に調査した結果、これまで時間も優先順位もなかったタスクが 1 つ見つかりました。それは、実装チームやクライアントが自分でアドオンを作成してプラットフォームの機能を拡張できるように、プラグイン システムを作成することです。

しかし、自動化をインストール、構成、展開する時間は、残り 1 か月しかありませんでした。

当社のチーフアーキテクトであるセルゲイによると、プラグイン システムの実装には少なくとも 1 か月かかるとのことです。

時間がなかったんです…

解決策はただ一つ、クライアントのところへ行き、すべてをありのままに伝えることだけだった。延期について一緒に話し合ってください。そしてそれはうまくいきました。私たちには2週間の延長が与えられました。彼らにも結果を示す期限と社内義務がありましたが、2 週間の余裕がありました。結局、私たちはすべてを賭けました。馬鹿げたことをする方法はなかった。誠実さとパートナーシップのアプローチが再び成果を上げました。

パイロットの結果、いくつかの重要な技術的成果と結論が得られました。

アラート処理の新しい機能をテストしました

展開されたシステムは、Prometheus からアラートを正しく受信し、グループ化するようになりました。 Prometheus クライアントからの問題に関するアラートが 30 秒ごとに飛び交っていたため (時間のグループ化は有効になっていませんでした)、これを「アンブレラ」自体にグループ化できるかどうか疑問に思っていました。それは可能であることが判明しました - プラットフォーム内のアラート処理の構成はスクリプトによって実装されます。これにより、処理用のほぼあらゆるロジックを実装することが可能になります。標準ロジックはすでにテンプレートの形でプラットフォームに実装されています。独自のロジックを作成したくない場合は、既製のロジックを使用できます。

合成トリガー インターフェース。接続された監視システムからのアラートの処理の設定

システムの「健全性」状態を構築

アラートは、構成ユニット (CU) の正常性に影響を与える監視イベントを作成するために使用されました。当社では、内部 CMDB を使用することも、外部 CMDB に接続することもできるリソース サービス モデル (RSM) を実装しています。パイロット プロジェクトでは、クライアントは CMDB に接続していませんでした。

リソース サービス モデルを操作するためのインターフェイス。パイロットRSM。

実は、クライアントは最終的に、さまざまなシステムからのイベントを確認できる単一の監視画面を手に入れました。現在、「アンブレラ」には、Zabbix と Prometheus の 2 つのシステムと、プラットフォーム自体の内部監視システムが接続されています。

分析インターフェース。単一の監視画面。

プロセス自動化を開始

イベントの監視により、事前設定されたアクション (通知の送信、スクリプトの実行、インシデントの登録/強化) が開始されましたが、インシデントの登録/強化はこの特定のクライアントでは試行されませんでした。その理由は、パイロット プロジェクトにサービス デスクとの統合が含まれていなかったためです。

アクション設定インターフェース。 Slack に通知を送信し、サーバーを再起動します。

製品の機能を拡張しました

自動化スクリプトについて話し合ったとき、クライアントは bаsh のサポートと、これらのスクリプトを簡単に構成できるインターフェースを求めました。新しいバージョンでは、さらにいくつかの機能が追加され（cURL、SSH、SNMP をサポートする Lua で本格的な論理構造を記述する機能）、スクリプトのライフ サイクル（作成、編集、バージョン管理、削除、アーカイブ）を管理できる機能が実装されました。

自動修復スクリプトを操作するためのインターフェース。 SSH 経由でサーバーを再起動するためのスクリプト。

主な調査結果

パイロット中には、現在の機能を改善し、クライアントにとっての価値を高めるユーザー ストーリーも作成されました。その一部を以下に示します。

• アラートから自動修復スクリプトに変数を直接渡す機能を実装します。
• Active Directory 経由でプラットフォームに認証を追加します。

そして、私たちは他の機能を使って製品を「成長させる」という、よりグローバルな課題に直面しました。

• ルールやエージェントではなく、ML に基づくリソース サービス モデルの自動構築 (おそらく現在の主な課題)。
• 追加のスクリプトおよびロジック言語のサポート（これは JavaScript になります）。

私の考えでは、 一番大切なものこのパイロットが示すのは次の 2 つです。

1. 顧客とのパートナーシップは効率性の鍵であり、誠実さとオープンさを基盤とした効果的なコミュニケーションが構築され、顧客は短期間で大きな成果を達成するチームの一員となります。
2. いかなる状況でも、「カスタマイズ」や「チート」を作成しないでください。体系的なソリューションのみを実行してください。もう少し時間をかけて、他のクライアントが使用できる体系的なソリューションを作成することをお勧めします。ちなみに、まさにそれが起こりました。プラグイン システムと Azure への依存を拒否することで、他のクライアントにさらなる価値が提供されました (連邦法 152 号、こんにちは)。

出所： habr.com