Brendaは、マシンラーニングした人工知能を使用して、インフラストラクチャの監視、品質保証チェックとトラブルシュートのサポート、警告の処理と重大な問題の通知、自動修復を行うシステムだ。
SwisscomのSree Rama Murthy Pakkala氏とCollin Mendons氏は、Swiss Testing Day 2020で、自社の品質向上を支援するBrendaという名のAI/MLフレームワークについて講演する予定である。カンファレンスは8月26日、オンラインで開催される。
Brendaの朝は午前6時(中央ヨーロッパ標準時)、アプリケーションをヘルスチェックすることから始まる。次に、基本的なビジネスプロセスのQAをチェックして、レポートや警告を送信する。その後はテスト環境の監視とメンテナンス、QAチェックを実施し、1時間毎にレポートを送信し続ける。
テストインフラストラクチャのサポートは複雑なテーマだ。テスト環境であるから、環境は不安定である。チームが世界規模で活動していれば、長時間のサポートも必要になる。予算の観点からリソース容量が不足する場合は、どうすればよいのだろうか？
Pakkala氏によると、Brendaは、テスト環境の状態を24x7、透過的に共有することによって、この問題を解決する。通常のインフラストラクチャ問題であれば修正も行う。チームは単調な監視やアクティビティの再スタートなどから開放され、よりイノベーティブなタスクに時間を投入できるようになる。
Brendaはステークホルダに対する、インフラストラクチャの可用性と機能に対する透過性の生成を継続的手法で支援する。Mendons氏によれば、サポートの第1レベルは完全にBrendaが行っており、リソースの有効利用を可能にしている。MTTIとMTTRの低減にも有効だ。
InfoQはSree Rama Murthy Pakkala、Collin Mendons両氏にインタビューして、人工知能とマシンラーニングの品質保証への適用、Brendaの技術的側面と心理的なつながり、Brendaが実際に作業する様子、品質保証にAIとMLを使用して分かったこと、などを聞いた。
InfoQ: 品質保証に人工知能やマシンラーニングを採用しようと決めた理由は何だったのですか？
Sree Rama Murthy Pakkala: 最初の頃は、AIやMLをソリューションの一部にするという考えはありませんでした。品質保証に対する私たちのサポート活動は、もっと対応的(reactive)なアプローチだったのです。監視ソリューションを実装したことで、対応的から積極的(proactive)なアプローチへと移行しました。それをさらに予測的(predictive)なものに拡張しようと決めた時に、監視ソリューションから収集したデータが、マシンラーニングやAIの採用に私たちを導いてくれたのです。
ですから、課題とソリューションがテクノロジの採用を決断させた、ということになります。
Collin Mendons: 開発は"旅"そのものでした。過去私たちが運用していた監視ソリューションは、実行するとマシンやアプリケーション、コンポーネントの状態をEメール送信で警告してくれるようなスクリプトの集まりでした。その後、継続的監視を取り入れて、時系列データベースでのデータ保持と監視、警告の生成を行うようになったのですが、その時、このデータを使ってリアクティブに監視や警告を行うだけでなく、予測も可能になるのではないか、と考え始めたのです。そこで、障害を予測するために、これらのデータを使ってMLを採用しました。
InfoQ: Brendaとは何なのでしょう？
Pakkala: AIを使用したマシンラーニング能力を備える、統合型の監視フレームワークがBrendaです。
Mendons: Brendaの誕生には逸話があります。Brendaには２つの側面があります。すなわち、1) 技術的側面と 2) 心理的結合です。
技術的には:
移行の一環として、私たちは、ソフトウェアとインフラストラクチャの品質向上を目的とした、多数の監視ソリューションと自動化フレームワークを構築しました。すべてが価値あるものでしたが、しばらくして私たちは、これらのソリューションがサイロとして動作していることに気付いたのです。
例えば、サービスのダウンを監視システムが通知した場合、そのサービスに関連したシナリオを使って、QAオートメーションが自動テストを試みることになります。このギャップを埋めるために、Brendaは開発されました。Brendaはこれらすべてのピース(自動化、監視、トラブルシュート、MLモデルなど)をひとつにまとめて、相互のコミュニケーションを可能にし、さまざまなモジュールの状態に応じた判断を行います。これにより、フレームワークが意味のあるコンテキストを外部に提供できるようになり、さらなる価値を生み出すのです。
心理的には:
フレームワークの開発中、自動化や監視、トラブルシュート、MLモデルといった個々のツールを使用していた人たちにインタビューしました。それぞれのデータを結合して、どのように意思決定をしているのかを聞いたのです。その結果から、社員が日々、これらのツールをどのように使っているのかを分析しました。このフレームワークは、人々がツールを使って行っている実際の作業を、まったく同じ方法で再現することができるように開発されています。まさに、仮想チームメンバそのものです。
そのこともあって、皆が愛着を持てるような名前にしたい、と強く思っていました。当時の私たちには、Branという名前の、単純なチャットを通じて障害分析を支援するチャットボットがありました。そこからの連想で、人の名前を付けようと思い立ち、Brendaと命名したのです。人と直接つながる部分として、名前は非常に重要なものだと思っています。今ではユーザの方が、開発者よりもBrendaについて詳しく知っています :-)
InfoQ: Brendaはどのように動作するのでしょうか？
Mendons: Brendaはまず、朝のモジュールを通じてシステムのヘルスチェックを行います。その上で、状態に応じて、重要なビジネスプロセスのQAチェックを開始します。QAチェックで異常があれば、トラブルシュート用のスクリプトを使って自動回復を試み、問題が解決すれば先に進みます。
QAが完了すると、全ステークホルダに詳細なレポートが送信されます。テスタが作業を開始する頃には、基本的な機能のアベイラビリティはすでに確認済になっているという訳です。それ以降のBrendaは、さまざまなモジュールからの警告に対する自動回復を開始します。最初のステップとして自動回復をトライし、問題が解決しなければ実際の作業者にそれを通知して、詳細な分析とさらなる対応を行います。
Brendaは一定周期でQAチェックを実施して、その結果に応じたアクションを実行します。さらに対処が必要な場合は、それぞれに対応するチームが関与します。
InfoQ: 品質保証にAIとMLを使用したことで、どのようなことが分かりましたか？
Pakkala: 運用と資金の両面で、大きなメリットがありました。
特に重要なのは、AIとMLがどのような場面で、どのように利用できるのか、明確なアイデアが必要であることが分かった点です。
実装プロセス全体では多くの時間とコストを費やすことになるのですから、計画段階における事前のリスク評価と投資利益率の算出が必要です。最初の側面は運用、つまり、MTTR(Mean Time to Repair)とMTTI(Mean Time to Identify)をどこまで小さくできるのか？これにより、顧客エクスペリエンスと顧客満足度を向上させることができます。第２の側面は財務、つまり、Brendaによるテスト環境監視やサポートがある場合とない場合とでは、容量消費にどのような違いがあるのか？
Mendons: MLとAIは今日のバズワードです。BrendaのモジュールすべてがMLとAIなのではありません。フレームワークとしては、従来的なプログラミングとML/AIモデルを組み合わせたものなのです。
ML/AI実装の最も重要な部分は、ニーズを理解し、データを理解した上で、ML/AIの最も適切なユースケースをピックアップすることです。
もっと単純なプログラムで同じ成果を達成できるのならば、そちらにするべきです。MLを誤ったユースケースで採用すると、非常に高価なものになる可能性があります。