プロダクションエンジニアリング ネットワーキングとインシデント管理チーム AI プロンプト
ネットワーキングとインシデント管理の共通 AI プロンプト
アナウンス文の作成
ネットワーキングとインシデント管理は、GitLab 全体の他のチームが使用するプラットフォームを構築し、ツールを管理しています。例えば、インシデント管理ツールとインシデント管理に関するプロセスを管理しています。また、エンジニアリング全体で標準化されたネットワーキングインフラストラクチャを採用するためのフレームワークも構築しています。
プロセスやフレームワークに変更を展開する際は、それらの変更を伝え、使用・知る必要があるすべての人が発見できるようにすることが重要です。
このプロンプトは、特定の Issue やマージリクエストに対する Slack アナウンスの下書き作成を支援します。
プロンプト
[MR/ISSUE/EPIC] の Slack アナウンスの下書き作成を手伝ってください。
[SRE/ENGINEERING/PRODUCT/SUPPORT/ETC] のオーディエンスを念頭においた要約を作成してください。
[含めるべき具体的な詳細] を必ず含めてください。
リントエラーの修正
ハンドブックやその他の Markdown ベースのプロジェクトやファイルでは、特に Web IDE で作業する際にリントミスをしやすいです。このプロンプトを使用して、Duo Agent に変更のリントエラーを修正してもらいましょう。
プロンプト
この MR の [リントエラーが出ているジョブへのリンク] のリントエラーを修正してもらえますか？
受信リクエストのトリアージ
プロダクションエンジニアリングチームであるため、ネットワーキングアーキテクチャへの変更を要求するさまざまな部門から Issue が開かれることがよくあります。これらの Issue をトリアージする際、過去に同様の作業が完了しているかどうかを知ることが役立ちます。
プロンプト
ネットワーキングとインシデント管理チームのためにこの Issue をトリアージしています。過去にこのチームや他のチームから同様のリクエストがあったかどうかを知りたいです。
[PROJECT] を検索して、関連する Issue や特定のコメントを提供してください。
これらの変更は [PROJECT(S)] で行われる可能性があります。過去に同様の問題を解決した MR を見つけてください。
過去のディスカッションを探す
インフラストラクチャとプロダクション環境の歴史は長く、時間とともにチームとプロジェクトが変化していることと相まって、一部の決定がなぜ行われたか、または特定のことがなぜその状態になっているかを理解することが難しい場合があります。このプロンプトを使用して、過去のディスカッションや決定に関する詳細を見つけましょう。
プロンプト
[トピック/決定] に関する特定のディスカッションを探す必要があります。知っていることは以下の通りです:
議論された内容:
[ディスカッションのトピックまたは行われた決定を説明]
ある可能性のある場所:
[エピック/Issue/MR 番号/プロジェクトまたは一般的なエリア]
キーワードまたはフレーズ:
[使用された可能性のある特定の用語]
誰が言ったか:
[おそらく参加したチームメンバー]
いつ頃（おおよそ）:
[わかっている場合の時間枠]
以下の方法で探してください:
1. エピックとリンクされているすべての MR/Issue を検索する
2. コメント内の特定のキーワードを探す
3. 解決済み/折りたたまれたスレッドを確認する
4. コミットメッセージを検索する
5. MR の説明と更新を確認する
6. メンション用のシステムノートを確認する
7. 関連するエピックや Issue を検索する
8. 関連する作業で同様のディスカッションを探す
9. リンクされたデザインドキュメントを確認する
10. チームメンバーの最近のコメントを検索する
11. 決定記録または ADR を探す
12. スクリーンショットやコードスニペットを確認する
コンテキスト: この決定は [なぜ必要か] のために必要です。ディスカッションは [詳細なコンテキスト] についてでした。[ブロックしているもの] をブロックしています。
インシデント対応のためのサービス依存関係のマッピング
GitLab の分散アーキテクチャ全体でサービス依存関係をマッピングし、効果的なインシデント対応のための障害カスケードを理解するための GitLab SRE 向けプロンプトテンプレートです。
プロンプト
GitLab SRE として [GITLAB SERVICE]（例: Rails API、Gitaly、Registry、Pages、CI Runner インフラ）の依存関係をマッピングしています。コード/設定は以下の通りです:
[サービスコード、設定、または Helm チャートを貼り付け]
GitLab アーキテクチャのコンテキスト:
- セル/シャード: [メインセル/CI セル/Pages セル]
- 通信方式: [gRPC/HTTP API/Redis pub-sub/PostgreSQL]
- ロードバランサー: [HAProxy/GCP LB/Cloudflare]
以下について分析してください:
1. このサービスが依存する GitLab サービス（Gitaly、Redis、PostgreSQL、Elasticsearch）は何ですか？
2. どの Redis インスタンスを使用していますか（cache、shared_state、queues、rate_limiting）？
3. Gitaly ノードの障害やレイテンシーのスパイクにどのように対処しますか？
4. PostgreSQL レプリカのラグや接続プールの枯渇時に何が起こりますか？
5. 外部サービス（GCS、Container Registry、Cloudflare）への依存関係はありますか？
6. フィーチャーフラグはサービスの依存関係とフォールバックの動作にどのように影響しますか？
7. 依存関係を検証する Consul のヘルスチェックや readiness プローブは何ですか？
8. GitLab のレート制限と不正使用検出とどのように相互作用しますか？
9. このコンポーネントが障害を起こした場合、どのサービスが影響を受けますか（逆方向依存関係）？
10. 手動バイパスオプション（フィーチャーフラグ、管理コマンド）は何ですか？
コンテキスト: [GitLab.com/Dedicated インスタンス] に影響を与える可能性のある [特定のインシデントタイプ/依存関係障害シナリオ] に対する [ランブック/セルアーキテクチャドキュメント/インシデント対応計画] を更新しています。
レビュー前の MR 準備
コードレビューのために MR を提出する前に、このプロンプトを使用して Duo に事前レビューを行ってもらい、レビュアーとのやり取りの回数を減らしましょう。
プロンプト
[MR タイトル] をレビューに提出しようとしており、スムーズなレビュープロセスを確保したいと思っています。現在の状況は以下の通りです:
行った変更:
[主要な変更の要約]
変更されたファイル:
[ファイル数と一般的に変更されたエリア]
複雑な箇所:
[複雑またはリスクの高い変更の特定]
必要なコンテキスト:
[レビュアーが必要とする可能性のある背景情報]
以下の方法で準備を手伝ってください:
1. 問題/解決策を含む明確な MR の説明を作成する
2. レビュアー向けのレビューチェックリストを作成する
3. 追加の説明が必要な部分を特定する
4. 複雑なコードにインラインコメントを追加する
5. 異なる部分に適したレビュアーを提案する
6. 大きすぎる場合は小さな MR に分割する
7. 特定の注意が必要なエリアをハイライトする
8. テスト手順を提供する
9. 関連する Issue/ドキュメントをリンクする
10. 予想されるレビュアーからの質問を先回りして答える
11. 関連する場合は変更前/変更後の比較を追加する
12. レビューをリクエストする前に CI/CD がパスしていることを確認する
コンテキスト: この MR は [Issue/機能] に対処しています。チームサイズは [人数] です。通常のレビューのターンアラウンドは [期間] です。これは [優先度レベル] です。
