monitoring-alert-designlisted

## Purpose 「知らない間にフローが止まっていた」「気づいたら大量のエラーが出ていた」を防ぐ。 監視すべき指標・アラート閾値・通知先・対応手順を設計し、障害を検知できる状態にする。 ## Use When - 自動化フローのリリース前 - 新しいシステム統合（Stripe Webhook 等）を設計する場合 - failure-point-review の後に、検知手段を設計したい場合 - 「このシステム、止まったらすぐ気づけるか」を確認したい場合 ## Inputs - **対象システム**: 監視するフロー・サービス・APIの説明 - **許容障害時間**: 何時間まで気づかなくてよいか - **通知先**: Slack / メール / ダッシュボード 等 - **既存の監視**: 現在どのような監視が存在するか（ない場合は「なし」） ## Output Contract 1. **論点**: このシステムで最も監視が重要な箇所 2. **根拠**: その論点をそう判断した理由 3. **監視設計シート**: 監視項目・閾値・通知先の定義 4. **含意**: 監視設計が示す運用負荷・アラート疲労リスク 5. **改善案**: 監視コスト・アラート精度を改善する工夫 6. **代替案**: 別の監視方式・ツールの可能性 7. **判断材料**: 監視設計の確定に必要な人間の意思決定事項 ### 監視設計シート フォーマット | 監視項目 | 正常値 | 警告閾値 | 危険閾値 | 通知先 | 対応手順 | |---|---|---|---|---|---| | （指標名） | | | | Slack #channel | | ## Review Lens - **目的妥当性**: 監視項目が実際の障害検知に対して有効か - **範囲の過不足**: 重要なシステムが監視対象から漏れていないか - **中長期リスク**: アラートが多すぎて無視されるリスク（アラート疲労） - **LAB全体との整合性**: 通知仕様（チャネル・重大度・宛先・初動手順）が定義されているか - **非エンジニア理解可能性**: 「何かおかしい時に通知が来る」を説明できるか - **他LLM移植耐性**: 設計が Slack 固有に過度に依存していないか ## Instructions 1. 監視対象を「フロー実行結果 / レスポンスタイム / エラーレート / データ整合性」に分類する 2. 各項目の正常値・警告閾値・危険閾値を定義する 3. 通知先（Slack チャンネル）と通知タイミングを設計する 4. 「通知が来たら誰が何をするか」の初動対応手順を簡潔に定義する 5. 自動復旧できる場合はその条件と手順を含める 6. アラートの抑制条件（メンテナンス時間等）を定義する 7. ヘルスチェックエンドポイントの有無を確認する ## Guardrails - アラートを「通知するだけ」で終わらせない。初動対応手順をセットにする - 全エラーを同じ重要度で通知しない（警告と危険を区別する） - ダッシュボードを「作って終わり」にしない。誰が・いつ・何を確認するかを明示する - 「24時間気づかなくてもいい」障害でも記録は残す ## LAB Cross-Check | 観点 | 状態 | 備考 | |---|---|---| | 自動化フロー | — | n8n / Webhook の実行結果を監視しているか | | データ /