データチームのインシデント管理
インシデント管理が重要な理由
- データ運用における一貫性と信頼性 - GitLab のデータチームは、組織全体のビジネス意思決定を支える重要な分析インフラとデータパイプラインを管理しています。標準化されたインシデント管理プロセスにより、一貫した対応時間と解決品質が確保されます。明確なガイドラインがなければ、チームメンバーごとに異なる方法でインシデントが処理される可能性があり、結果の不整合やステークホルダーへのデータ可用性に影響する長時間のダウンタイムを招くことがあります。
- 対応時間の改善と説明責任 - 標準化されたインシデント管理により、明確なエスカレーションパス、役割と責任の定義、確立されたコミュニケーションプロトコルが生まれます。この構造により、高プレッシャーな状況での混乱が排除され、適切な担当者に迅速に通知されて対応が効果的に調整されます。全員が自分の役割と期待されるプロセスを把握していれば、組織的な摩擦を最小限に抑えてインシデントをより速く解決できます。
- 知識の保存と継続的改善 - 正式なインシデント管理プロセスには、何が問題だったか、どのように解決されたか、何を改善できるかを記録するドキュメント要件が含まれます。これにより、将来の同様のインシデントを防止し、新しいチームメンバーが過去の経験から学べる組織的な知識ベースが作成されます。また、体系的なアプローチはデータインフラとプロセスの継続的改善を推進するポストインシデントレビューも促進します。
- ステークホルダーとのコミュニケーションと信頼 - 明確なインシデント管理基準により、影響を受けるステークホルダーがデータ可用性の問題に関するタイムリーで正確な更新を受け取れるようになります。この透明性は、業務にデータを依存するビジネスユーザーとの信頼を構築し、障害中の期待管理に役立ちます。一貫したコミュニケーションはデータチームのプロフェッショナリズムとサービス信頼性へのコミットメントも示します。
- コンプライアンスとリスク管理 - 機密性の高いビジネス情報を扱うデータチームにとって、文書化されたインシデント対応手順はコンプライアンス要件の充足と組織的リスクの軽減に役立ちます。標準化されたプロセスにより、インシデント中にセキュリティ上の考慮事項が一貫して対処され、データの整合性や機密性が侵害される可能性がある場合に適切なステークホルダーに通知されます。
インシデント管理メカニズムの成果
問題解決の迅速化
- 重要なデータパイプライン、ETL/ELT プロセス、分析ダッシュボードのダウンタイム削減
- データ品質の問題、パイプラインの障害、パフォーマンス低下が発生した場合の明確なエスカレーションパス
- 失敗したデータロード、スキーマ変更、API レート制限などの一般的な問題に対する文書化されたトラブルシューティング手順
データ品質と信頼性の向上
- プロアクティブなモニタリングにより、データの異常、欠損データ、ドリフトを下流ユーザーへの影響前に検出
- 根本原因分析により、データインフラの体系的な問題（例: 繰り返す変換の失敗、ソースシステムの不安定性）を特定
- データの鮮度、完全性、精度に関する**サービスレベル目標（SLO）**が測定可能かつ実施可能になる
コラボレーションの改善
- データ資産とパイプラインの明確なオーナーシップ - 特定のデータソースやモデルが壊れたときに誰に連絡すべきかを正確に把握
- 障害中のデータチームとステークホルダー間のクロスファンクショナルな調整（例: マートが利用できない場合にアナリストへ通知）
- 過去のインシデントの共有知識ベースにより、新しいチームメンバーが一般的な障害パターンを理解できる
I. インシデントの定義、重大度、および作成
1. インシデントの定義
インシデントとは、混乱を防ぐか運用状態を回復するために即座の人的介入を必要とする、サービス低下、データ品質の問題、またはシステム障害につながる、またはその可能性がある異常な状態です。
インシデントは以下の形で現れることがあります。
- 可用性の問題: データ、ダッシュボード、または分析ツールがユーザーにとってアクセスできない、または利用不能になる
- 品質の低下: データの不正確さ、破損、検証の失敗、または予期しないスキーマ変更
- タイムリネス違反: 期待される時間枠内でデータが更新されない、古いメトリクス、または遅延レポート
- 処理の失敗: パイプラインの断絶、ETL/ELT ジョブの失敗、モデルエラー、下流プロセスに影響するインストルメンテーションロジックの失敗
- セキュリティの懸念: 不正なデータ公開、アクセス制御の侵害、またはデータ漏洩
- 収集の混乱: イベントトラッキング、データキャプチャメカニズム、またはソースシステムの失敗への中断
インシデント基準 - すべての問題がインシデントになるわけではありません。インシデントは以下の基準の 1 つ以上を満たす必要があります。
- 下流モデルや依存関係、ビジネス運用、またはデータコンシューマーへの即時の影響があるか
- SLO 違反があるか
- 即時の対応が必要か
- 直ちに対処しない場合、永続的なデータ損失または破損の可能性があるか
2. インシデントの重大度
インシデントの重大度は、3 つの主要な側面を評価することで決定されます。
- ビジネスへの影響と混乱
- データの重要性と影響
- 下流の依存関係
上記の要素に基づき、以下の重大度レベルを定めます。
- Sev1: 本番データパイプラインの失敗、顧客対応チームのブロック、重要なビジネス決定ができない、データ侵害/公開、複数のシステム/メトリクスに影響する差し迫ったまたは実際のデータ損失、またはビジネスクリティカルなメトリクスの中等度から重度の低下。
- Sev2: 手動の回避策を必要とする大幅なワークフローの混乱、下流コンシューマーに影響するデータパイプラインの遅延、潜在的なセキュリティ脆弱性/コンプライアンスの問題、またはシステム/サービスの部分的な低下。
- Sev3: 最小限の影響で作業が継続できる不便さ、重要でないデータパイプラインの遅延、内部専用データへの不適切なアクセス、開発/ステージング環境でのパフォーマンス低下、または既知の回避策がある軽微なデータ品質の問題。
- Sev4: あると便利な機能/改善の欠如、見た目の問題、必要なドキュメントの更新、または即時の運用への影響がない技術的負債の項目。
2 つの重大度レベルの間で迷う場合は、最初は高い方を選択してください。情報が増えて理解が深まるにつれて、重大度を下げるか再分類することができます。
3. インシデントの作成
インシデントを作成することを決めたら、以下の手順に従ってください。
- 適切なプロジェクトフォルダのインシデントテンプレートを使用する
- すべての必須情報を文書化する
incidentとsevラベルを追加する- 適切な DRI に割り当てて関連するチームメンバーにタグを付ける
- Slack でコミュニケーションする
インシデント vs Issue: エスカレーションが必要な場合は /type incident を使用して Issue をインシデントに変換します。
ツール:
インシデントの種類に応じて:
- SRE のオンコールと連携する必要がある場合（例: Postgres パイプラインの問題）、incident.io を使用してインシデントをログ記録・追跡してください。ただし、GitLab 上の Analytics プロジェクト内に対応するインシデントが常に存在する必要があります（データチームメンバーが作成）。
- その他すべての種類のインシデントについては、
incidentラベルを付けて GitLab のこちらに新しい Issue またはインシデントを作成してください。/type incidentを使用して Issue をインシデントに変換できます。
注: データへの影響が最小限で手動の手順や修正が必要な場合は、インシデントではなくバグを作成してください。
II. インシデントの解決
即時対応
- すべてのインシデントは検出後すぐに対応が必要です。
- すべてのインシデントには DRI が割り当てられている必要があります。別のチームメンバーが積極的に解決に関与するまで、トリアージャーまたは作成者が暫定 DRI を務めます。
解決アプローチ
- 長期的な解決策を追求する前に、一時的な回避策であっても修正を実装することを優先してください。
- マネージャーは重大度評価（検出 DRI によって決定）をレビューし、それに応じて作業を優先します。
データインシデントについて、軽減と解決を明確に区別します。
インシデントは、以下のすべてが真である場合にのみ解決済みとして扱われます。
- 根本原因が修正され、検証されている（例: パイプラインが安定している、インフラが低下していない）。
- 影響を受けたデータが完全にバックフィル、再処理、またはその他の方法で修正され、下流のモデル、ダッシュボード、レポートが正確で、タイムリネス SLO を満たしている。
- 影響を受けたステークホルダーのブロックが解除され、データに再度依存できる。インシデントは、作業の一部が完了しただけで、下流のデータが古いまたは不正確なままであるという理由のみで閉じるべきではありません。インシデントは、データが完全に更新され正確になるまで（結果に責任を持つ）オープンのままです。
これにより、「解決までの時間」がコードやインフラの変更がデプロイされるまでの時間だけでなく、ユーザーが低下または信頼できないデータを経験した期間と一致することが保証されます。
複数のチームが関与する場合、例えばデータパイプラインの失敗（データプラットフォームチームがパイプラインの障害を解決）と下流の dbt モデルが影響を受ける場合（アナリティクスエンジニアリングチームがバックフィルを実行する必要がある）、2 つの別々のインシデント（データプラットフォームチームが 1 つ、アナリティクスエンジニアリングチームが 1 つ）を開くことができます。この場合、2 つの子インシデントにリンクする包括的なインシデントを作成できます。包括的なインシデントは両方のインシデントが解決されるまでオープンのままです（解決までの時間を示すため）。一方、2 つの子インシデントは独立してクローズされます。
コミュニケーション
- DRI は、利用可能になり次第、予想される解決タイムラインを含む定期的なステータス更新をインシデントチャンネルで提供する必要があります。
クローズ 以下を確認した後で速やかにインシデントをクローズします。
- 修正が意図どおりに機能していること、かつ
- 影響を受けたデータが完全に更新され、SLO に対して検証されていること、かつ
- 下流コンシューマー（例: 主要なダッシュボードや定期レポート）が一時的な回避策に依存しなくなっていること。
作業の一部が完了しているが、データのバックフィルや再計算がまだ進行中の場合は、インシデントをオープンのままにして、タイムラインとステータス更新にこれを明示的に文書化してください。インシデントは、技術的な修正とデータの状態の両方が正常に戻ったときにのみクローズされます。
- 各インシデントの事後分析を実施して予防措置を特定し、将来の発生を避ける
インシデント SLO
| 重大度 | TTR（対応時間） | TTM（軽減時間） | TTR（解決時間） |
|---|---|---|---|
| Sev1 | 2 時間 | 1 日 | 7 日 |
| Sev2 | 4 時間 | 3 日 | 30 日 |
| Sev3 | 24 時間 | 7 日 | 60 日 |
| Sev4 | 48 時間 | 30 日 | 90 日 |
- 軽減: 即時の原因を素早く調査・対処することで、さらなる影響を軽減することを目的とした一時的な応急処置
- 解決: 根本原因を完全に排除するために標準的な作業プロセスに従う長期的で恒久的な解決策
リソース
- インシデント割り当てに適切な DRI を見つけるには、コードオーナーシップについてこの CODEOWNERS ファイルを参照してください。
- Analytics Instrumentation org のメンバーは、参考としてモニタリングとトラブルシューティングガイドを確認できます。
