根本原因分析

1） RCAとは何であり、なぜそれが必要なのか

根本原因分析は、再発を防ぐために、インシデントの根本原因を特定するための構造化されたプロセスです。センターで-事実、因果関係と体系的な改善（プロセス、アーキテクチャ、テスト）、責任の検索ではありません。
目標：再発防止、MTTR/インシデントレートの削減、SLOの改善、規制当局やパートナーとの信頼の構築。

2）原則（Just Culture）

料金はかかりません。私たちは人を罰するのではなく、危険な行為を罰します。
ファクチュアリティ。検証可能なデータとアーティファクトのみ。
E2Eビュー。お客様からバックエンド、プロバイダまで。
仮説の検証可能性。任意のステートメント-テスト/実験で。
CAPA閉鎖。所有者と期限との是正措置と予防措置。

3）エントランスの工芸品と準備

UTCタイムライン：T0検出→T+アクション→T+回復。
観測データ：ログ、メトリック（コホートによるものを含む）、トレイル、合成、ステータスページ。
変更：リリース、フィーチャーフラグ、コンフィギュレーション、プロバイダイベント。
環境：バージョン、アーティファクトハッシュ、SBOM、インフラストラクチャタグ。
インシデントベース：影響の説明（SLO/SLA、顧客、売上高）、意思決定、回避策。
監護の連鎖：誰が、誰が証拠を収集/修正したか（コンプライアンスに重要）。

4） RCA方法： とき

1.5理由-狭い問題の原因チェーンをすばやく把握します。リスク：複雑なシステムをラインに「ロールアップ」します。
2.Fishbone-要因を人/プロセス/プラットフォーム/ポリシー/パートナー/製品として分類します。最初に役立つ。
3.フォルトツリー解析（FTA）-イベントから原因セット（AND/OR）への控除。インフラおよびツリー障害の場合。
4.因果グラフ/イベントチェーン-確率と寄与重量の依存度グラフ。マイクロサービスや外部プロバイダに適しています。
5.FMEA（故障モードと効果解析）-予防：故障モード、重症度（S）、周波数（O）、検出性（D）、 RPN=S × O × D。
6.Change Analysis-比較（config diff、スキーマ、バージョン）。
7.ヒューマンファクターレビュー-人々の決定のコンテキスト（アラート疲労、悪いプレイブック、過負荷）。

推薦された組合せ：Fishbone→Change Analysis→Causal Graph/FTA→5なぜキーの枝によって。

5）ステップバイステップのRCAプロセス

1.開始：RCAオーナーを任命し、レポートの発行期限（例えば、5営業日）を決定し、チーム（IC、 TL、 Scribe、プロバイダ担当者）を組み立てます。
2.事実を収集する：タイムライン、グラフ、リリース、ログ、アーティファクト；バージョンと金額コントロールを修正しました。
3.マップインパクト：影響を受けたSLI/SLO、コホート（国、プロバイダー、VIP）。
4.仮説を構築する：プライマリ、代替；検証可能なものを確認してください。
5.仮説をテストして下さい：段階の再生/シミュレーション/カナリア、トレース分析、欠陥の注入。
6.根本と貢献の原因を決定する：技術、プロセス、組織。
7.フォームCAPA：是正（正しい）と予防（防止）；サクセスメトリクスとタイムライン。
8.レポートの調整と公開：内部知識ベース+、必要に応じてクライアント/レギュレータの外部バージョン。
9.効果を確認して下さい：14/30日後のチェックポイント；閉じるアクション。

6）「根本原因」とカウントするもの"

• 弱いテスト/フィーチャーフラグ、ミッシングリミット/アラート、あいまいなドキュメント、間違ったデフォルト、脆弱なアーキテクチャ。
• 多くの場合、これは要因の組み合わせです（構成×ゲート×負荷×プロバイダの欠如）。

7） CAPA： 是正措置と予防措置

• コード/config修正、パターンのロールバック、制限/タイムアウトの変更、インデックスの追加、レプリカ/シャーディング、トラフィックの再配布、証明書の更新。

• テスト（コントラクト、カオスケース）、アラート（燃焼速度、合成量）、リリースポリシー（カナリア/ブルーグリーン）、構成用GitOps、トレーニング/チェックリスト、プロバイダの重複、DR演習。

各アクション：所有者、期限、期待される効果、検証メトリック（例えば、変更失敗率のX％の減少、90日の反復なし）。

8）仮説と効果の検証

実験：フォルトインジェクション/カオス、シャドウトラフィック、A/Bコンフィギュレーション、実際のプロファイルとの負荷。
成功指標：SLO回復、p95/p99安定化、エラー率スパイクなし、MTTR削減、バーンレートと30日間のゼロ再オープン傾向。
コントロールポイント：D+7、 D+30、 D+90-CAPAの実装と影響の改訂。

9） RCAレポートテンプレート（内部）

1.短い要約：何が起こったとき、影響を受けた人。
2.影響：SLI/SLO、ユーザー、地域、売上高/罰則（もしあれば）。
3.タイムライン（UTC）：メインイベント（アラート、意思決定、リリース、修正）。
4.オブザベーションとデータ：グラフ、ログ、トレース、configs （diffs）、プロバイダのステータス。
5.仮説とテスト：受け入れ/拒否、実験への参照。
6.根本原因：技術、プロセス、組織。
7.要因：「なぜ気づかなかった/止まらなかった」。
8.CAPAプラン：所有者/期限/メトリックを含むアクションの表。
9.リスクと残存脆弱性：他に監視/テストする必要があるもの。
10.アプリケーション：アーティファクト、リンク、グラフ（リスト）。

10）例（ショート、一般化）

イベント：19：05-19：26 （SEV-1）で35％の支払い成功。
影響：21分e2e-SLO違反、影響を受けた3カ国、返品/補償。
理由1（それら）：カードバリデータの新しいバージョンでは、レイテンシが1に増加しました。2 s→プロバイダへのタイムアウト。
理由2（パーセント）：プロバイダ「A」のためのカナリアがなかった、リリースはすぐに100％でした。
理由3（組織）：ビジネスSLIのアラートしきい値は特定のBIN範囲（VIPコホート）をカバーしていませんでした。
CAPA：バリデータの古いバージョンを返します。カナリア1/5/25％を入力してください。BINコホートによるビジネスSLIの追加；プロバイダ「B」のフェイルオーバー30％に同意します。カオスケース「スローアップストリーム」。

11） RCAプロセス成熟度の指標

CAPA完了時刻（％は30日で終了）。
再開率（事件は90日で再開）。
Change-failure-rate before/after。
全身的な原因が見つかる事件の割合（「ヒューマンエラー」だけではありません）。
RCAからの新しいシナリオのテストカバレッジ。
レポートのリリース時間（公開SLA）。

12）規制対象ドメイン（fintech/iGamingなど）の特徴.)

外部へのレポート：レポートのクライアント/規制バージョンは機密情報なしですが、繰り返しを防ぐ計画があります。
監査ログと不変性：アーティファクトの保存、署名済みレポート、チケットへのリンク、CMDB、リリースログ。
ユーザーデータ：サンプルログの省人化/マスキング。
通知期間：契約および規制（例：最初の通知ごとのN時間）。

13）アンチパターン

「Vasyaは非難することです」-全身的な理由のない人間の要因の停止。
仮説テストの欠如-直観による結論。
あまりにも一般的なRCA（「サービスがオーバーロードされました」）-具体的な変更はありません。
CAPAなしまたは所有者/期限なし-レポートのためのレポート。
情報を隠す-信頼の喪失、組織を訓練することができません。
SLO/Business SLI以外のメトリックでオーバーロード。

14）ツールとプラクティス

RCAリポジトリ（wiki/knowledge base）メタデータ：サービス、SEV、理由、CAPA、ステータス。
テンプレートとボット：インシデント（タイムライン、グラフ、リリース）からレポートフレームを生成します。
因果関係グラフ：イベント因果マップの構築（例えば、ログ/トレースに基づいて）。
カオスカタログ：舞台で過去の出来事を再現するためのスクリプト。
ダッシュボード「RCAの後」：個々のウィジェット、これはCAPA効果を確認します。

15）チェックリスト「出版の準備ができました」

• タイムラインとアーティファクトが完了し、検証されます。
• テスト/実験によって識別され、証明される根本原因。
• 根本原因と寄与原因が分離される。
• CAPAには、所有者、締め切り、測定可能なエフェクトメトリックが含まれています。
• 14/30日に検証プランがあります。
• 外部ステークホルダー向けのバージョンが用意されています（必要に応じて）。
• レポートは技術/パーセントレビューに合格しました。

16）ボトムライン

RCAは形式のための回顧ではなく、システムの学習メカニズムです。事実が収集され、因果関係が証明され、CAPAがメトリクスにロックされて実験によってテストされると、SLOが安定し、再発のリスクが低くなり、ユーザーおよび規制上の信頼性が高くなります。