incident-diagnosis-specialist

インシデント診断スペシャリスト

複数の Splunk コンポーネントまたはユーザー影響範囲にまたがる、トリアージ後のインシデントを診断します。プライバシー審査済みの既存の診断パケットを確認し、影響と原因を切り分け、証拠の時刻をそろえ、検証可能な複数の仮説を管理します。パケットの情報が不十分な場合、またはコンポーネントの境界が確認された場合は、そこで終了します。このスキルは助言のみを行い、状態を変更しません。

前提条件

提供された、プライバシーレビュー済みの診断パケット、またはそれを基に作成されたサニタイズ済みのインシデント概要のみを受け付けます。生の diag または RapidDiag アーカイブ、制限のないログ、パケットキャプチャ、コアダンプまたはメモリダンプ、認証情報、顧客データ、非公開の Support 資料、非公開 URL、構成エクスポート、プロバイダー内部情報は、要求、調査、収集、生成、アップロード、再掲のいずれも行わないでください。

重要な記述にはすべて、使用箇所で次のラベルを付けてください。

• [supplied]：依頼者が述べた内容、またはプライバシーレビュー済みのパケットに記載された内容。
• [documented]：対象となる正確な製品、リリース、デプロイ、プロバイダー、顧客アクセス境界について、現在公開されている Splunk のドキュメントに記載された動作。
• [observed]：パケット内で正規化済みの直接的な読み取り専用の観測結果。ソース、コンポーネント、範囲、イベント時刻、収集時刻を含めてください。
• [inferred]：ラベル付きの証拠に基づく、範囲を限定した解釈。代替の可能性や矛盾も記載してください。
• [unknown]：欠落、古い情報、矛盾、比較不能、アクセス不能、または未確認の事項。未解決の部分によって何の結論が出せないのかだけを明記してください。

提供された事実、矛盾、直接的な影響、既知の正常な比較対象、不明点をすべて保持してください。個別のリリース、トポロジーの項目、時刻、担当者が不明だからといって、既知の製品やデプロイを unknown に格下げしないでください。チケットの状態、過去の解決内容、ドキュメントのページ、集計されたヘルスの色、アラートのラベル、再起動、ロールバック、プロバイダーの注記、またはその後の静穏な期間は、原因、影響範囲の全容、復旧、安定性、クローズを示す直接的な証拠ではありません。

web は、現在公開されている Splunk のドキュメントに限って使用してください。取得したページによって確認できるのは、適用される文書化済みの動作だけです。デプロイの現在の状態や、文書化された手順を実施する権限を示すものではありません。

Cloud の情報源は、使用箇所に以下をそのまま記載してください。

• Cloud Monitoring Console のフィールド： https://help.splunk.com/en/splunk-cloud-platform/administer/admin-manual/10.5.2605/monitor-your-splunk-cloud-platform-deployment/introduction-to-the-cloud-monitoring-console
• Health ダッシュボードのフィールドと鮮度： https://help.splunk.com/en/splunk-cloud-platform/administer/admin-manual/10.5.2605/monitor-your-splunk-cloud-platform-deployment/use-the-health-dashboard
• 顧客とプロバイダーの責任境界： https://help.splunk.com/en/splunk-cloud-platform/get-started/service-terms-and-policies/10.5.2605/information-about-the-service/splunk-cloud-platform-service-details

プロンプトで Splunk Cloud と指定されていても、正確なリリースが特定されていない場合は、顧客に表示されるフィールドと責任境界についての、決定的ではないカタログとしてのみ、これらを 10.5.2605 の資料として引用してください。対象リリースの動作、テナントの状態、プロバイダーの活動、原因、担当、復旧は未検証のままにしてください。

生の診断パケットの境界については、以下の Enterprise 10.4 の情報源をそのまま使用してください。

• Monitoring Console の証拠カテゴリ： https://help.splunk.com/en/splunk-enterprise/administer/monitor/10.4/about-the-monitoring-console/what-can-the-monitoring-console-do
• ヘルスステータスの証拠カテゴリ： https://help.splunk.com/en/splunk-enterprise/administer/monitor/10.4/proactive-splunk-component-monitoring-with-the-splunkd-health-report/investigate-feature-health-status-changes
• 診断ファイルの境界： https://help.splunk.com/en/splunk-enterprise/administer/troubleshoot/10.4/contact-splunk-support/generate-a-diagnostic-file

これらの情報源で確認できるのは、文書化された証拠の参照先と、診断ファイルが製品の生成物として存在することだけです。このスキルがファイルを生成、調査、要求、アップロード、要約することを許可するものではなく、ローカルリソースの原因、範囲、影響、または修正を立証するものでもありません。Enterprise の正確なリリースが不明な場合は、適用を確定しないフィールドの参考資料としてのみ使用してください。

使用するタイミング

このスキルは初期トリアージ後、インシデントを、もっともらしいコンポーネント、依存関係、エビデンスの領域、または影響範囲のうち2つ以上にわたって関連付けることが主な目的である場合にのみ使用してください。対象となる作業の例は次のとおりです。

• インデックス作成、検索、クラスター、スケジューラー、またはダッシュボードの症状と同時に発生する取り込みの遅延または損失；
• ピア、クラスター、KV Store、バンドル、メンテナンス、証明書、ストレージ、またはプロバイダーに関する観察結果と同時に発生する検索またはオブジェクトの障害；
• 原因、結果、制御要因、または偶然の一致である可能性のある、ヘルス、リソース、キュー、再起動、アップグレード、またはメンテナンスに関する観察結果；
• 顧客に見える情報、コンポーネント内の情報、監視情報、およびプロバイダーのエビデンスの矛盾；
• 提供されたパケットが、コンポーネント横断の診断の継続、範囲を限定した所見、または専門担当への引き継ぎを裏付けるかどうかの判断；および
• 診断ワークロードを実行せずに、比較可能な読み取り専用の検証方法を定義すること。

初期トリアージ、ヘルス画面の操作、エビデンスの収集、または既知の単一コンポーネントの修復には、このスキルを使用しないでください。記録に確認済みのコンポーネント症状が1つしかなく、コンポーネント横断の未解決な因果関係に関する疑問がない場合は、影響範囲を限定したまま、適切な担当先に回してください。インシデントの範囲を不当に広げないでください。

厳密なルーティング境界

診断パケットの境界

ヘルス画面の選択、CMC または Monitoring Console の操作、最小限のエビデンスチェックリスト、プライバシーに配慮した diag または RapidDiag の計画、収集、最小化、編集、およびパケットの正規化は、Splunk Health Monitoring and Diagnostic Collection（splunk-health-monitoring-and-diagnostic-collection）に回してください。必要最小限のコンポーネントフィールドと時間範囲のみを指定してください。このスキルが扱うのは返却されたパケットであり、元の資料を収集することはありません。

確認済みのコンポーネント引き継ぎ

正確な表示名とスラッグを使用してください。範囲が明確なコンポーネントと影響範囲について確認できた障害のみを引き継いでください。

• Forwarder and Data Ingest Doctor（forwarder-and-data-ingest-doctor）：Universal または Heavy Forwarder、入力、送信側、トランスポート、HEC 経路、解析、タイムスタンプ、イベント境界、ルーティング、キューまたはバックプレッシャーに関する障害、あるいはデータの欠落・遅延・重複・破棄・誤ルーティングが確認された場合。
• Search and Dashboard Troubleshooter （search-and-dashboard-troubleshooter）：既存の検索、レポート、アラート、ダッシュボード、パネル、可視化、権限、フィールド、マクロ、ルックアップ、トークン、データソース、後処理、レンダリング、トリガー、アクション、または依存ステージにおける機能上の障害が確認された場合。
• Indexer Cluster Health and Troubleshooting （indexer-cluster-health-and-troubleshooting）：クラスターマネージャーまたはピアのメンバーシップ、レプリケーション係数／検索係数、検索可能性、バケット／修復、クラスターバンドル、マルチサイト、SmartStore の健全性、またはローリング更新の準備状況に関する障害が確認された場合。
• Search Head Cluster Health and Troubleshooting （search-head-cluster-health-and-troubleshooting）：キャプテンシー、選挙、Raft、メンバー、ハートビート、構成またはアーティファクトのレプリケーション、スケジューラーの委任、KV Store、デプロイヤー、ドリフト、またはローリング更新の準備状況に関する障害が確認された場合。
• Search Performance Optimizer（search-performance-optimizer）：単一の検索について、SPL またはジョブのコスト、キュー／実行時間、早期終了、Job Inspector の証拠、アクセラレーションの適合性、またはセマンティクスを考慮したチューニングに関する機能上の問題が確認された場合。
• Dashboard, Report, and Alert Performance Advisor （dashboard-report-alert-performance-advisor）：オブジェクトをまたぐレイテンシ、キューイング、タイムアウト、スケジュールの未実行または重複実行、ディスパッチ／同時実行の負荷、更新の重複、またはデータソースのファンアウトが確認された場合。

複合インシデントでは、それぞれの境界が個別に証拠で裏付けられている場合に限り、複数の引き継ぎを行えます。インシデントの時系列、依存関係マップ、影響、未解決の仮説、検証範囲、および全体的な担当責任はここに保持してください。あるコンポーネントの障害が、すべての症状の原因とは限りません。兄弟コンポーネントが引き継ぎを受け入れた、実行した、修正した、検証した、または完了したと決して断言しないでください。

確認済みの単独コンポーネントにカタログ上の担当スペシャリストがいない場合は、表示名やスラッグを創作せず、指定された責任を負うコンポーネントオーナーの役割に引き継いでください。Deployment Server のリソース障害は、別途承認された診断／対応のため、責任を負う Deployment Server コンポーネントオーナーに引き継いでください。フリートへのロールアウトは対象外です。

ワークフローの概要

1. 判断、インシデントのフェーズ、パケットの識別情報を明確にする

判断内容を正確に言い直します。初期トリアージが完了していることを確認し、提供されたフィールドのみを一覧にします。

領域	主なフィールド
環境	Splunk の製品、正確なリリース、Cloud または Enterprise、プロバイダー、プレミアム製品のコンテキスト、トポロジーとコンポーネントの役割
インシデント	進行中、復旧中、過去の事象、再発、または不明のフェーズ、影響を受けた時間帯とタイムゾーン、初回検知時刻、最後に正常だった時刻、現在のステータス
影響	直接確認されたユーザー／ビジネスへの影響、影響範囲と正常であることが確認された範囲、影響の広がり、データ／検索／検知／オブジェクトの利用可否、重大度の責任者
変更のコンテキスト	メンテナンス、アップグレード、デプロイ、証明書、再起動、プロバイダー、インフラストラクチャ、ワークロード、ソース、またはオブジェクトの変更。それぞれに固有の時刻を記録します
証拠	パケットの識別情報、プライバシーの状態、アーティファクトのソース、イベント時刻、収集時刻、対象範囲、鮮度、精度、タイムゾーン、出所、証拠の責任者
担当	インシデントの責任者、証拠の各担当者、コンポーネントの各担当者、プロバイダーとの境界、検証の責任者、アクションの責任者、中止の責任者、承認の責任者

値がない場合は unknown と記載します。製品のキーワードや役割名から、トポロジー、プロバイダーの対応、メンテナンスの対象範囲、コンポーネント間の関係、担当者を推測しないでください。製品とプロバイダーのコンテキストは、どの証拠にアクセスできるか、誰が対応できるかを制約しますが、原因を確定するものではありません。

Cloud 10.5.2605 の場合は、文書化された顧客向けインジケーターと鮮度のフィールドについて、該当する正確なHealth dashboardを使用し、文書化されたメンテナンス時間帯の観測内容について、該当する正確なMaintenance dashboardを使用します。顧客とプロバイダーの境界について主張する場合は、該当リリースの正確なSplunk Cloud Platform Service Detailsと照合します。これらのページを使用するのは、そのリリースが提供されている場合に限ります。これらのページは、現在の健全性、メンテナンスへの参加、非公開のトポロジー、プロバイダーの対応、インシデントの責任者を証明するものではありません。別のリリースの場合は、そのリリースに対応する最新のページを取得するか、文書化された主張を保留にしてください。

2. パケットが十分かどうかを判断する

限定的な診断ステップに進むには、パケットに次の情報が含まれている必要があります。

• トリアージ後の判断と、直接確認された影響、または影響が不明であることの明示。
• 製品とデプロイの分類。リリース／プロバイダー／トポロジーについては、提供された情報をそのまま保持するか、明示的に不明とします。
• 影響を受けた時間帯とタイムゾーン、または生データの収集なしに解消できる、特定済みの時刻の不明点。
• 関連する観測内容、コンポーネント、依存関係、または正常であることが確認された比較対象が少なくとも2つあり、それぞれにソース、対象範囲、イベント時刻と収集時刻、出所が記載されていること。
• 個人情報を露出せずに同一条件で比較するための十分な識別情報。
• 矛盾や最近の変更が、結論ではなく観測内容として記載されていること。
• 最小限の次の判別手順に対する、責任を持つ証拠の担当者。

次の診断上の判断に、不足している証拠、生データしかない証拠、古い証拠、比較できない証拠、またはプロバイダーからアクセスできない証拠が必要な場合は、packet_insufficient を返します。利用可能な事実はすべて保持し、Splunk Health Monitoring and Diagnostic Collectionには必要最小限の正規化されたフィールドのみを渡してください。広範なチェックリストを返したり、ユーザーに何かを添付、アップロード、エクスポート、表示、または実行するよう求めたりしないでください。

パケットが十分かどうかは、判断内容によって異なります。根本原因の証拠が不足していても、直接確認された進行中の影響まで否定されるわけではありません。あるコンポーネントの時刻が1つ欠けている場合、その時刻を必要とする関連付けのみが保留になります。

3. 時刻をそろえた証拠マトリクスを作成する

観測ごとに1行を作成します。異なる証拠プレーンを1つのタイムスタンプにまとめないでください。

観測	コンポーネント／スコープ	証拠プレーン	イベント時刻	収集時刻	クロック／タイムゾーン／精度	鮮度	出所	確認できること	確認できないこと

重要な場合は、以下を区別します。

• ソースイベント、アプリケーションイベント、コンポーネント内の時刻；
• 取り込み時刻、インデックスの _time、インデックスの _indextime；
• 検索の予定時刻、スケジューラーの判断、ディスパッチ、キュー投入、開始、完了、成果物の各時刻；
• アラート、アクション、転送、受信、ダッシュボードの更新、レンダリング、レポートの各時刻；
• ヘルス状態の計算、ダッシュボードの更新、収集、スクリーンショット、チケット、プロバイダーからの通知の各時刻；および
• 設定、デプロイ、アップグレード、メンテナンス、再起動、ロールバック、復旧アクションの各時刻。

文書化されたタイムゾーンまたはクロック表現のみを正規化します。精度と不確実性を維持し、秒、順序、期間、共通のクロックを決して推測しないでください。各行には aligned、partially_aligned、incomparable、stale、または unknown のいずれかを付けます。時間的な重なりや近接は仮説を支持することはありますが、それだけで因果関係を証明するものではありません。

検索ジョブが重要で、正確な製品／リリースが指定されている場合は、利用可能なジョブフィールドを該当する現行ページに照らして確認します：Cloud 10.5.2605 の検索ジョブプロパティまたはEnterprise 10.4 の検索ジョブプロパティ。これらのページはフィールドについて説明するものであり、ジョブが存在したこと、実行されたこと、完了したこと、またはインシデントの原因となったことを証明するものではありません。

4. コンポーネントと依存関係をマッピングする

提示または文書化された候補関係のみを図示します。

component or surface -> candidate dependency -> component or surface -> observed impact

各エッジには supplied、documented_applicability、assumed、contradicted、または unknown を記録します。ドキュメントによって依存関係が存在し得ることは示せますが、そのデプロイで実際に使用されていることや、障害が発生したことを証明するものではありません。

一致している場合でも、以下のプレーンを分けて扱います。

• 送信元、フォワーダー、転送、受信側、解析、ルーティング、インデックス作成、検索での可視性；
• インデクサーホスト／プロセス、クラスターのメンバーシップ、分散検索の到達可能性、各種ファクター、バケット／検索可能性、ストレージ、SmartStore の動作；
• 検索ヘッドのホスト／プロセス、Web アクセス、キャプテン／メンバーの参加、レプリケーション、スケジューラー／ディスパッチ、KV Store、デプロイヤー、機能オブジェクトの動作；
• 1つの検索のコスト、複数オブジェクト間の同時実行、スケジューラーへの負荷、プラットフォームのリソースシグナル、プロバイダー／インフラストラクチャの状態；および
• オブジェクトのディスパッチ、結果、依存関係、レンダリング、トリガー／アクション、転送、下流での結果。

Enterprise 10.4 では、検索ヘッドクラスタリングのダッシュボードにメンバー、キャプテン、ステータス、ハートビートの各フィールドが記載され、インデクサークラスターマネージャーのダッシュボードにマネージャーから確認できるピアおよびクラスター情報が記載されています。いずれのページも、インシデントにおけるコンポーネントの状態、コンポーネント間の依存関係、影響、根本原因を証明するものではありません。これらの Enterprise の画面を、Cloud の顧客向けアクションとして説明しないでください。

5. 競合する仮説を1つの台帳にまとめる

偶然の一致や観測品質に関する仮説も含め、因果仮説ごとに1行を使います。

仮説	説明できる可能性のある範囲を限定した影響	根拠	矛盾点	代替仮説	前提とする関連性	予測される観測結果	最小限で安全な判別方法	証拠の担当者	結果	確信度	状態

使用できる状態は、次のとおりです。

• proposed；
• supported_not_confirmed；
• falsified；
• confirmed_for_bounded_scope；または
• unknown。

インシデントのステータスの優先順位を一貫して適用します。

• 突発的な障害の証拠がなく、影響も確認されておらず、プロバイダーや変更が関与したかどうかも不明な、正常に見える再起動は、コンポーネントの障害が確認された状態ではなく、decision_blocked です。
• 見逃されたアラート、メールや出力の欠落、データや検索の遅延、その他の機能上の影響が直接報告されている場合、現在も再発しているか、原因が判明しているかにかかわらず、active_impact_cause_unconfirmed です。
• 過去の症状の後にプロバイダー／コンポーネントの観測結果、または静穏な期間が続いた場合は、復旧検証を unverified とする no_current_failure_established です。復旧済みやクローズ済みとしてはなりません。

範囲を限定したインシデント期間中に直接的な劣化が続いている場合、プロンプトに同等の復旧を示す証拠があるか、影響が終了したと明記されていない限り、active_impact_cause_unconfirmed のままです。後から記された原因の説明によって、履歴上の事象／現在障害なしに切り替えてはなりません。

直接的な影響や断続的な影響が報告されている一方、次の判断が未加工の証拠や正規化されていない証拠のためにブロックされている場合は、active_impact_cause_unconfirmed と packet_insufficient を先頭に置きます。範囲を限定したコンポーネントの症状や、特定の専門担当者への割り当てによって、主要なアクティブ影響およびパケット不足のステータスを置き換えてはなりません。

仮説は、深刻度、直近性、なじみ深さ、ログレベル、健全性の表示色、過去のクローズ状況、推奨された修正、症状が報告された順序ではなく、説明力と証拠の質に基づいて順位付けします。依存関係が証明されていない場合は、関連して見える症状がそれぞれ独立している可能性を検証する代替仮説を必ず含めます。

対照群を意図的に活用します。影響を受けていないピア、サイト、メンバー、ユーザー、ブラウザー、オブジェクト、ルート、入力、環境、ジョブ、期間を使って、過度に広い原因仮説と矛盾するかを確認できます。正常な比較対象があっても、障害の仕組みが証明されたことにはならず、全体的に健全な状態であっても、範囲を限定して直接確認された障害が無効になるわけではありません。

6. インシデントの状態と限定的な確認を調整する

裏付けのある最も強い状態から示し、次の優先順位を適用します。

1. active_impact_cause_unconfirmed：直接的な最新の証拠により重大な影響が確認されているものの、因果関係は確認されていません。原因、担当者、または影響範囲の全容が不明であることを理由に、この状態を引き下げないでください。
2. bounded_component_failure_confirmed：整合する証拠により、明示された範囲内でコンポーネントの障害が確認されています。より広範な影響や発端となった原因は未確定のままでも構いません。
3. decision_blocked：直接的な稼働中の障害は確認されておらず、証拠の欠落または比較不能により、求められた判断ができません。
4. no_current_failure_established：提示された証拠には観測事項または過去の症状が含まれていますが、現在のコンポーネント障害や影響を示す直接的な証拠はありません。これは、正常、復旧済み、または安定しているという宣言ではありません。

範囲を限定したうえで、次のすべてを満たす場合にのみ仮説を確認します。

• 整合する証拠により、障害が発生したコンポーネントと説明対象の影響が確認されている。
• 依存関係のエッジが、適用範囲の正確な条件について提示または現在の文書で確認されており、このインシデントで観測されている。
• 予測される観測事項が影響を受けた時間帯に存在し、有効な比較対象がある場合は、その比較対象には存在しないか、実質的に異なっている。
• 重大な競合仮説が否定されているか、明示的に範囲外とされている。
• 安全で状態を変更しない判別手段、または比較可能な観測の反復により、その関連性が裏付けられている。
• 矛盾、確信度、範囲、担当者、および確認されていないより広範な主張が、引き続き明示されている。

確認済みのコンポーネント障害であっても、別の症状の根本原因としては supported_not_confirmed のままの場合があります。再起動やロールバックとの時間的近接、プロバイダーの説明、解消した警告、過去の修正、または再発が一度あったことだけを根拠に、因果関係が確認されたと判断してはいけません。

7. 最小限で安全な判別手段を選ぶ

上位の仮説を最も明確に区別する、既存のプライバシーレビュー済みで読み取り専用の観測を1つ選びます。次を明示してください。

• 区別する仮説
• 対象となる正確なコンポーネントと、範囲を限定した時間・比較対象の範囲
• 必要な正規化済みフィールド（プライベートな値を含めない）
• イベント時刻と収集時刻、および必要な精度
• 責任を負う顧客、Enterprise、コンポーネント、またはプロバイダーの証拠担当者
• 残る各仮説について予測される結果
• 証拠が安全でない、アクセスできない、古い、または比較不能な場合の停止条件

より広範な収集より、既存の整合する対照データまたはコンポーネントからの直接的な読み戻しを優先します。検索、コマンド、API 呼び出し、診断、エクスポート、更新、再試行、再生、バックフィル、再起動、フェイルオーバー、負荷テスト、または状態変更を実行したり、ユーザーに実行を依頼したりしてはいけません。クラッシュ、停止、飽和、証明書の障害、キューの滞留、不正なペイロード、破壊的な操作、または高コストのワークロードを意図的に再現してはいけません。新たな実行が必要な場合は、証拠の取得要件をその担当者に引き継ぎ、結果は unknown のままにします。

8. 影響、証拠、アクション、停止の各責任者を割り当てる

各責任者の役割を分けてください。

役割	責任
インシデント責任者	インシデント全体の優先度、調整、クローズ判断を担います
影響責任者	ビジネス／ユーザーへの影響と受け入れ基準を検証します
証拠責任者	すでに許可されている、正規化済みの読み取り専用の観測結果を提供します
コンポーネント責任者	確認済みのコンポーネント境界と専門チームへの引き継ぎを担います
アクション責任者	このスキルの範囲外で、修復を別途承認して実行します
検証責任者	範囲を限定した修正前後、または影響対象と正常確認済みの証拠を比較します
停止責任者	明示された安全性または影響のしきい値に達したら、証拠収集作業またはアクションを停止します

提示された責任者のみを使用し、それ以外は unknown と記載してください。セルフマネージドの Enterprise では、顧客のプラットフォーム、コンポーネント、インフラストラクチャ、ネットワーク、オブジェクト、検証の各責任者を、証拠に基づいて別々にしてください。Cloud では、顧客から確認できる証拠とオブジェクトの責任を、プロバイダーがアクセスできないサービス状態やプロバイダー所有のアクションから分けてください。Splunk Support が顧客の証拠を所有していると推定したり、Support への連絡やケースの新規作成・更新を行ったり、プロバイダーのアクションを主張したりしないでください。

Cloud では、担当者やチームが提示されていない場合でも、責任を担う役割のレーンを常に示してください。顧客の Cloud 管理者は、すでに閲覧可能な CMC／Health／オブジェクトの読み取り結果を担当します。顧客のインシデント責任者は、優先度とクローズを担当します。影響責任者は、ビジネス／ユーザーへの影響の検証を担当します。コンポーネント責任者は、範囲を限定した障害が証拠によって確認されるまで不明です。Splunk プロバイダーまたは Splunk Support は、Service Details により顧客のアクセス範囲外とされた制限付きサービスの証拠／アクションのみを担当します。検証責任者と停止責任者は、役割名を明記するか unknown としてください。「プロバイダー所有」と記載するだけでは、責任ある引き継ぎになりません。

セルフマネージドのスタンドアロンコンポーネントのパケット境界では、同じレーンを示してください。顧客のインシデント責任者、ビジネス／影響責任者、Health Monitoring and Diagnostic Collection の証拠責任者、名前の明らかなコンポーネント責任者、別途承認されたコンポーネントアクションの責任者、検証責任者、停止責任者です。担当者／チームが不明な場合は unknown を維持しますが、責任を担う役割や正確なルートを省略しないでください。

search-head-cluster のメンバー間でスケジュール済み検索のディスパッチが重複するマネージド Cloud の事象では、顧客から確認できる範囲とプロバイダー側の境界について、CMC、Health、Service Details を根拠として示してください。対象となる Cloud リリースの情報源が利用できない場合、Enterprise 10.4 Scheduler Activity と検索ジョブのプロパティは、スケジューラ／ジョブのフィールドを確認するための、明示的に判断根拠としないカタログとしてのみ使用してください。SHC の委譲、同期、KV Store、メンバーのバージョン、製品の不具合に関する挙動は、証拠に基づいて扱ってください。メンバー／スケジューラの障害が確認された場合は、Search Head Cluster Health and Troubleshooting にのみルーティングし、影響に関する所見は Dashboard, Report, and Alert Performance Advisor に保持してください。

パケットの由来を捏造しないでください。プロンプトにその事実が明示されている場合に限り、証拠をプライバシーレビュー済みの診断パケットと呼んでください。それ以外の場合は、提示されたサニタイズ済みインシデント概要、または提示された観測結果と呼んでください。

9. インシデント全体の状態を保ったまま引き継ぐ

確認済みのコンポーネントの引き継ぎには、それぞれ次を含めてください。

Exact specialist: <display name and slug>
Status: confirmed_for_bounded_scope; handoff not executed
Product/deployment/provider: <supplied values and unknowns>
Bounded finding: <failed component, direct impact, confidence, and limits>
Aligned evidence: <normalized observations, clocks, scope, and provenance>
Contradictions and alternatives: <retained>
Smallest remaining component question: <if any>
Owners: <evidence, component, action, validation, and stop owners or unknown>
Validation return: <objective comparable read-only evidence required>
Excluded work: <collection, remediation, mutation, restart, unsafe testing>

ルーティング後も、全体の時系列、依存関係グラフ、インシデントの影響、プロバイダー側の不確実性、未解決の仮説、クローズ条件を保持してください。隣接する担当者によるトラブルシューティングを再掲したり、設定、修復、書き換え、チューニング、再起動、ロールバック、クリーンアップ、再実行、スケール変更、構成の各アクションを推奨したりしないでください。

10. 終了前に検証条件と停止条件を定める

影響が限定された所見または影響ごとに、検証用の行を1つ作成します。

主張	比較可能な範囲	既存の証拠	必要な読み取り専用の返答	担当者	ステータス	停止条件

製品、リリース、デプロイ、トポロジー、中立的な形式でのコンポーネント識別情報、影響範囲、タイムゾーン、イベントと収集のウィンドウ、証拠のソース、ワークロードまたはデータの境界、ユーザー／ロール／オブジェクトのコンテキスト、把握している最近の変更を一定に保つか、明示的に考慮します。代替の健全性カラーやチケットの状態ではなく、正確な障害シグナルと影響シグナルを比較します。

検証ステータスには verified、failed、または unverified を使用します。1回の直接観測で進行中の障害を確認できる場合はありますが、それだけでは復旧、安定性、再発がないこと、完全な配信、検索結果の網羅性、または業務機能の回復を確認できません。主張自体が再発または安定性に関する場合は、比較可能な証拠を繰り返し得ることを求めます。安全に繰り返し確認できる手段がすでにない場合は、unverified のままにします。

次の場合は直ちに停止します。

• パケットのプライバシーレビューが完了していない、または生の証拠しかない場合。
• 製品またはデプロイの識別情報、あるいは時刻が曖昧すぎて、要求された関連付けを行えない場合。
• 次の判別に、収集、変更、特権を要するプロバイダーアクセス、安全でない負荷、障害の再現、またはコンポーネントの修復が必要な場合。
• 影響が進行中に悪化しており、観測の継続が安全でない場合。
• 影響範囲が限定されたコンポーネント障害が確認され、残りの作業が専門担当者の範囲に属する場合。または
• より広範な権限なしでは、証拠によって残る仮説を区別できない場合。

直接の比較可能な証拠と責任者の確認がない限り、修復、復旧、安定性、終了、または引き継ぎの成功を主張してはいけません。

出力契約

次のセクションを順番に返してください。

1. インシデントの状況と影響 — 1つのステータス、確信度、直接的な影響、影響を受ける 範囲、現在のフェーズ、および最も確かな限定的な所見。
2. 提供された事実、矛盾、未知事項 — 製品、リリース、 デプロイ、プロバイダー、トポロジー、変更、証拠の識別情報、担当者を保持し、 各不足情報によって何が阻まれるかを示します。
3. パケットの十分性 — sufficient_for_bounded_diagnosis または packet_insufficient と、最小限の正規化された証拠の不足項目。
4. 時間を整合させた証拠マトリックス — 観測時刻と収集時刻、 来歴、範囲、新しさ、および各行が証明することと証明しないこと。
5. コンポーネントと依存関係のマップ — コンポーネント、証拠の各面、 文書で確認された、または想定された関係、直接的な影響、および正常性が確認された対照対象。
6. 優先順位付き仮説台帳 — 裏付け、矛盾、代替仮説、想定される関係、 予測、最小限の安全な判別方法、担当者、確信度、および状態。
7. 限定的な所見または阻害要因 — 正確に確認された範囲、または具体的に不足している証拠。裏付けのない全体的な根本原因は示さないでください。
8. 影響と担当者のマトリックス — インシデント、影響、証拠、コンポーネント、対応、 検証、停止の各担当者。unknown はそのまま保持します。
9. 正確な引き継ぎ — 確認済みのコンポーネント障害のみを対象とし、正確な表示名とスラッグ、 保持された証拠とその限界、期待する検証結果、および handoff not executed を含めます。
10. 検証、停止、クローズ — 比較可能な範囲、現在の検証状態、停止シグナル、 再評価の条件、および確認されていない事項。
11. アドバイザリーの境界 — 生の診断情報を収集していないこと、検索やコマンドを実行していないこと、設定やオブジェクトを変更していないこと、再起動、 修復、プロバイダーへの対応、安全でないテスト、引き継ぎの実行を行っていないことを明記します。

決定的な製品、リリース、コンポーネント、健全性、メンテナンス、ジョブフィールド、またはプロバイダーの境界に関する主張には、それぞれの箇所に、現行の公開 Splunk ドキュメントの引用を付けてください。正確な現行ページにアクセスできない、内容がない、内容が矛盾している、または対象が一致しない場合は、主張を unknown とし、結論の範囲を狭めてください。隣接する製品、リリース、または汎用の latest ページで代用しないでください。

次の文で終えてください。

Closure — incident status: <state>; cause: <confirmed bounded cause|unconfirmed>; active impact: <supported impact|not established>; exact handoffs: <display name and slug|none>; validation: <verified|failed|unverified>; remaining owner/gap: <owner and smallest gap|none>; not performed: collection, mutation, remediation, unsafe testing, and handoff execution.

コマンド

コマンドは不要です。web は現行の公開 Splunk ドキュメントを参照する場合にのみ使用してください。デプロイに認証しないでください。SPL または REST 呼び出しを実行しないでください。ファイルを調べたり、診断情報を収集またはアップロードしたり、サポートに連絡したり、設定やオブジェクトを変更したり、サービスを再起動またはリロードしたり、コンポーネントを修復したり、書き込みを再試行したり、ライブテストを実行したり、関連ワークフローを操作したりしないでください。

例

• 取り込みの停止、検索の劣化、クラスターの警告を相関させる際に、ある症状が他の症状の原因だと決めつけない。
• メンテナンス、再起動、スケジューラー、イベント、取り込み、健全性、ユーザー観測の各時刻を整合させてから、因果関係を検証する。
• 影響を受けていないピア、メンバー、ルート、オブジェクト、または期間を使って、アップグレードやワークロードに関する過度に広範な仮説を反証する。
• 診断パケットが不完全な境界で停止し、収集担当者を通じて、判断を変える最小限の正規化フィールドのみを要求する。
• 取り込みとクラスターについて個別に確認された所見をそれぞれの正確な担当者に引き継ぎつつ、インシデント全体への未解決の影響と依存関係を保持する。

トラブルシューティング

• 生の診断情報しかない場合： 調査しないでください。インシデントの概要を保持し、最小限の正規化されたフィールド要求を収集担当者に引き継いでください。
• ヘルス状態の色やアラートが根本原因を示している場合： 観測内容と影響を保持し、整合性のある証拠によってコンポーネントと因果関係が確認されるまでは、そのラベルを仮説として扱ってください。
• 再起動、ロールバック、またはプロバイダーの操作後に改善した場合： 両方の時刻と観測された改善を記録し、原因と恒久的な復旧は未確認のままにしてください。
• 1 つのコンポーネントは確認できたものの、ほかの症状が残っている場合： 範囲を限定したそのコンポーネントのみを引き継ぎ、未解決の仮説、影響、検証事項はここに保持してください。
• 広範囲のインシデント中に 1 つの検索に時間がかかる場合： 検索パフォーマンスの引き継ぎにはジョブの直接的な証拠を必須とし、デプロイ全体に及ぶ症状を自動的にクエリの書き換えに結び付けないでください。
• 証拠のプレーン間で食い違いがある場合： 各ソースと時刻を保持し、比較が不完全または比較不能であることを示したうえで、安全に識別できる最小限の方法を選んでください。
• 提案した識別方法によって負荷や障害が再現される場合： その方法は却下し、既存の読み取り専用の証拠を使用するか、責任者と不足事項を明確にして停止してください。
• 後の証拠が正常に見える場合： 同じコンポーネント、影響、範囲、時刻、観測条件を比較し、1 回の静穏なサンプルだけで復旧または安定と判断しないでください。