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

Habré に関する出版物で、私はすでにチームとのパートナーシップを構築した経験について書きました (ここで 新規事業を立ち上げる際に事業が破綻しないようにパートナーシップ契約をどのように作成するかについてお話します）。ここで、クライアントとのパートナーシップを構築する方法について話したいと思います。クライアントなしでは何も崩れることはありません。この記事が、自社製品を大企業に販売し始めているスタートアップ企業にとって役立つことを願っています。

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

銀行がトップ 3 セグメントにランクインしました。そしてもちろん、リストの最初にいたのはティンコフとズベルバンクでした。私たちが銀行市場の専門家を訪問したとき、彼らはこう言いました。「そこに製品を導入すれば、銀行市場への道は開かれます。」私たちはあちこちに参入しようとしましたが、ズベルバンクでは失敗が待っていました。ティンコフの人たちは、ロシアの新興企業との生産的なコミュニケーションにはるかにオープンであることが判明しました（おそらく当時のズベルバンクの事実のせいでしょう） 買った 西側の競合他社は約 10 億社）。 1 か月以内にパイロット プロジェクトを開始しました。それがどのように起こったのか、読んでください。

当社は長年にわたり運用と監視の問題に取り組んできました。現在では、公共部門、保険、銀行、通信会社に製品を導入しています。導入例の 1 つは航空会社でした (プロジェクト前は、導入さえしていませんでした)。航空業界はそれほど IT に依存した業界だったと思います。そして今、私たちはコロナにもかかわらず、この会社が台頭し、飛躍することを心から願っています。)

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

1. 火災の消火: 障害を特定し、瓦礫からの警告の流れを取り除き、責任者にタスクとインシデントを割り当てます。
2. IT サービスの効率を向上します。インシデントの解決にかかる時間を短縮し、障害の原因を示し、IT ステータスの透明性を高めます。
3. ビジネス効率の向上: 手作業の量を削減し、リスクを軽減し、顧客ロイヤルティを高めます。

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

• 「誰にも分からない」: 技術部門が多数あり、ほぼ全員が少なくとも 1 つの監視システムを持っており、ほとんどが複数の監視システムを持っています。
• アラートの「蚊の群れ」: 各システムが何百ものアラートを生成し、責任者全員にアラートを送りつけます (場合によっては部門間でも)。各通知の制御の焦点を常に維持することは困難です。通知の数が多いため、緊急性と重要性が平準化されます。
• 大手銀行 - セクターのリーダーは、システムを継続的に監視してどこに障害があるかを把握するだけでなく、システムを自己監視、自己予測、自己修正できるようにする AI の真の魔法も望んでいます。

私たちがティンコフでの最初のミーティングに来たとき、すぐに彼らはモニタリングに問題はなく、害を及ぼすものは何もないと言われました。主な質問は、「すでにうまくいっている人々に何を提供できるでしょうか?」ということでした。

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

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

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

1. 最初の段階は、インシデント解決の速度を上げるための包括的な監視です。
2. 第 2 段階はプロセスの自動化で、リスクを軽減し、IT 部門を拡大するためのコストを削減します。

複数の監視システムからの情報を処理することによってのみ、いくつかの「白い点」をアラートの明るい色で描くことができました。これは、さまざまな監視システムからのデータを順番に「1 つの画面」に集中管理する必要もあったためです。何が起こっているかの全体像を理解するために。それには「傘」が適しており、その条件を満たしました。

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

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

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

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

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

開発チームとの討論の夜は、解決策の探索が成功裏に終わりました。バックログを調べたところ、時間も優先度も決して足りなかったタスクが 1 つ見つかりました。それは、実装チームまたはクライアントが自分でアドオンを記述して、プラットフォームの機能を拡張できるようにするプラグイン システムを作成することです。

しかし、残りはちょうど 1 か月で、その間にすべてをインストールし、自動化を構成し、展開する必要がありました。

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

時間がありませんでした...

解決策は 2 つだけです。クライアントのところに行って、すべてをありのままに伝えます。締め切りの変更について一緒に話し合ってください。そしてそれはうまくいきました。 2週間の追加猶予が与えられました。彼らには独自の期限と結果を示すという社内義務もありましたが、XNUMX 週間の予備期間がありました。結局のところ、私たちはすべてを賭けています。台無しにすることは不可能でした。正直さとパートナーシップによるアプローチが再び功を奏しました。

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

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

導入されたシステムは、Prometheus からアラートを正しく受信し、それらをグループ化するようになりました。 Prometheus クライアントからの問題に関するアラートは 30 秒ごとに送られてきました (時間によるグループ化は有効になっていません)。私たちは、それらを「アンブレラ」自体でグループ化できないかどうか疑問に思っていました。プラットフォームでのアラート処理の設定はスクリプトによって実装されるため、可能であることがわかりました。これにより、それらを処理するためのほぼすべてのロジックを実装することが可能になります。プラットフォームにはテンプレートの形式で標準ロジックがすでに実装されています。独自のものを考え出したくない場合は、既製のものを使用できます。

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

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

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

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

実際、クライアントには最終的に単一の監視画面があり、さまざまなシステムからのイベントが表示されます。現在、2 つのシステム、Zabbix と Prometheus、およびプラットフォーム自体の内部監視システムが「アンブレラ」に接続されています。

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

プロセスオートメーションを開始

イベントの監視により、事前構成されたアクション (アラートの送信、スクリプトの実行、インシデントの登録/強化) の起動がトリガーされました。後者は、この特定のクライアントでは試行されませんでした。パイロット プロジェクトでは、サービス デスクとの統合はありませんでした。

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

拡張された製品機能

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

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

主な調査結果

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

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

そして、他の機能を備えた製品を「構築」するという、さらなるグローバルな課題も受けました。

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

私の考えでは、 一番大切なものこのパイロット版が示しているのは 2 つのことです。

1. クライアントとのパートナーシップが有効性の鍵となります。誠実さと率直さに基づいて効果的なコミュニケーションが構築され、クライアントは短期間で大きな成果を達成するチームの一員となります。
2. いかなる状況でも、「カスタマイズ」して「松葉杖」を構築する必要はありません。システム ソリューションのみを必要とします。もう少し時間をかけて、他のクライアントが使用できるシステム ソリューションを作成することをお勧めします。ちなみに、プラグイン システムと Azure への依存の排除により、他のクライアントに付加価値が提供されました (こんにちは、連邦法 152)。

出所： habr.com