> オープンソースアプリケーション、通信分野の実環境をシミュレートしたアプリケーション、2つの実世界アプリケーションの4つのアプリケーションで実験を行った。IBM Cloud ServiceアプリケーションとIBM Enterpriseアプリケーション（CIO）です。 > オープンソースのマイクロサービス・アプリケーション 公開されているベンチマーク[[TrainTicket]][10]マイクロサービスシステムを使用し、Kubernetesクラスタ上に展開します。このアプリケーションには41のマイクロサービスが含まれています。サービスts-ui-dashboardは、各受信および送信サービスの状態を記録するゲートウェイ・サービスとして機能します。このサービスから発せられるエラーシグナルは、エラーゴールデンシグナルとみなされます。我々は、様々なマイクロサービスに故障を注入し、ログデータを収集し、我々のアプローチの有効性を評価する。故障の種類としては，パケットロスやCPUホッグなど，最新の故障検出手法[4]や[21]でよく利用されているものを注入した．これらの故障は、Train Ticketアプリケーションの主要なフローをカバーする17のサービスに注入されました。故障が注入された後、ユーザーフローが実行され、ログが収集されます。故障の観測可能性を測定するために、故障を注入した後、ユーザフローを20回実行した。CPU-Hog(Packet-loss)故障の場合，各サービスの20回の平均実行時間は32分（30分），平均ログ行数は180k（162k）であった．CPU-Hog(Packet-loss)障害では，1サービスあたりの平均エラーメッセージ数は76(46)件，エラーメッセージ数の最小値と最大値はそれぞれ12(12), 192(132) 件であることが分かりました．その結果、ts-station-サービスの故障が最も多くのエラーを発生させることが分かりました。これは，ゲートウェイノード ts-ui-dashboard から最も遠いノードの 1 つであることと，経路上のすべてのノードがエラーを発生させたためである． ![[Pasted image 20220912143709.png]] > IBMのクラウドベースのサービス。我々は、多くのマイクロサービスで構成され、いくつかの地域の複数の地理上で実行されるIBMクラウドベースのサービスからの実世界のアプリケーションデータセットを使用しました。インシデントが発生した場合、SREは原因を特定するために複数のデータソースを分析します。ログデータソースは、分析に使用される主要なデータソースの1つです。今回の故障の特定手法では、ログを活用して故障のあるサービスを特定しました。インシデントが最初に報告された時間帯の2〜10分間のログを抽出します。我々は13の異なるインシデントについてログデータを収集しました。これらのインシデントで報告された故障は、[22]で説明されているように、22の産業故障（F1、F2...、F12、F22）のいずれかに分類することができます。これらの故障は、さらに次のように分類することができる。 a) 機能的故障：システムサービスの誤動作が原因で、エラーが発生したり、正しい結果が得られないもの b) 非機能的故障：パフォーマンスや信頼性などのサービス品質に影響するもの。これらの故障は、根本的な原因によって、内部故障、相互作用故障、環境故障に分類される。実験では，表 I に示すように，F3, F8, F10, F15, F18, F19 の 13 のインシデントシナリオを構成する故障ケースを対象とした．