インシデントフォローアップ Issue

このページでは、インシデントからのフォローアップアイテムを管理するプロセスについて説明します。

用語

プライバシー要件とチーム構成に基づいて、インシデントフォローアップ Issue に異なるデフォルトプロジェクトを使用します。

インシデントリードはフォローアップアイテムの管理において以下の責任があります。

インシデント中：
- すべてのフォローアップアイテムが適切にドキュメント化されていることを確認する。
- 可能な場合は各フォローアップアイテムに初期オーナーをアサインする。
インシデント後：
- 1営業日以内に自動作成されたすべてのフォローアップ Issue をレビューする。
- 各 Issue にインシデントからの適切なコンテキストがあることを確認する。
- 各 Issue が対処するチームの正しいプロジェクトに移動されていることを確認する。
- チームとグループラベルを含む適切なラベルを適用する。
- トリアージのために適切なチームメンバーまたはマネージャーに Issue をアサインする。

フォローアップアイテムは gitlab-com/gl-infra/incident-follow-ups に自動的に作成されます。
新規作成の代わりに既存の GitLab Issue をインシデントのフォローアップとして添付するには、Issue の URL を Slack チャンネルに貼り付けてください。
インシデントリードは各 Issue をレビューします：
- インフラストラクチャ Issue の場合：適切なインフラストラクチャチームラベルを適用する。
- アプリケーション Issue の場合：/move コマンドを使用して gitlab-org/gitlab に移動する。
- サービス固有の Issue の場合：適切なサービスプロジェクトに移動する（例：Gitaly Issue は gitlab-org/gitaly）。
適切なグループ/チームラベルを適用する：
- エンジニアリングチームの Issue にはグループラベルを含める（例：group::database）。
- インフラストラクチャチームの Issue にはチームラベルを含める（例：team::database）。
Issue を移動する際は、Issue 上で infradev ラベルが維持されていることを確認する。

フォローアップアイテムは gitlab-com/gl-infra/dedicated-follow-ups に自動的に作成されます。
新規作成の代わりに既存の GitLab Issue をインシデントのフォローアップとして添付するには、Issue の URL を Slack チャンネルに貼り付けてください。
インシデントリードは各 Issue をレビューします：
- 適切なチームラベルを適用する。
- Issue に明確なオーナーがいることを確認する。
- プライベートリポジトリに顧客固有の情報を保持することで機密性を維持する。
Dedicated チームが別の場所を必要とする場合にのみ Issue を移動する（例：Dedicated 組織外のチームが対処する必要がある Issue の場合）。

フォローアップアイテムがこぼれ落ちないようにするために：

週次トリアージ：Production Engineering チームはインシデントフォローアップリポジトリ内のすべてのオープン Issue の週次トリアージを実施して、未トリアージのアイテムを識別します。
SaaS 可用性レビュー：重要なインシデントフォローアップアイテムのステータスは SaaS 可用性ミーティングでレビューされます。
エンジニアリングチーム：エンジニアリングディレクターとマネージャーは、チームにアサインされた infradev Issue を定期的にトリアージすることが期待されます。

以下のラベルは両リポジトリのすべてのインシデントフォローアップ Issue に自動的に適用されます。

手動で適用すべき追加ラベル：

フォローアップ Issue には以下が含まれます。

インシデントリードは各 Issue に以下が含まれていることを確認する必要があります。