agentsclimarketplace
Sign in

Monitoring operations

Skill tdyzzsp47/claude-skills/skills/monitoring-operations

システムの監視設計・アラート設計・障害対応・ポストモーテムをカバーするスキル。リリース後の安定稼働維持や本番障害への対応が必要なときに使う。From its SKILL.md

Install
npx -y skills add tdyzzsp47/claude-skills --skill monitoring-operations

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

9.4 KB, ~3.8k tokens by cl100k_base, as published. Nobody here has run it

運用・監視・障害対応

目的

リリースして終わりにしない。本番稼働中のシステムが「いつ・何が・どこで壊れたか」を素早く把握し、 ユーザー影響を最小化しながら復旧・再発防止まで完結させる手順と成果物を定める。

使うタイミング

  • 新機能リリース前に監視設計・アラート設計を行うとき
  • 本番障害が発生し、対応フローを回すとき
  • 障害後にポストモーテムを書くとき
  • 既存の監視を見直す(アラート疲れが起きている・夜中に何度も起こされる)とき
  • 個人開発でも「最低限の監視」を構築したいとき

観測性の3本柱

1. 構造化ログ

  • JSON形式で出力。timestamp / level / requestId / userId / message / error を標準フィールドとする
  • リクエストIDを全ログに付与し、1リクエストの流れを追跡可能にする
  • レベル運用: ERROR=人手対応要、WARN=劣化の兆候、INFO=正常な主要操作、DEBUG=本番OFF

2. メトリクス(RED指標を中心に)

  • Rate(スループット): 単位時間あたりリクエスト数
  • Errors(エラー率): 5xx / 全リクエスト比率
  • Duration(レイテンシ): p50 / p95 / p99。平均値だけでは外れ値を見落とす
  • リソース(CPU・メモリ・ディスク)は二次的シグナル。RED指標が正常なら深追い不要

3. 分散トレース

  • マイクロサービス構成では必須。サービス間の呼び出しを単一トレースIDで紐付ける
  • モノリスでも「どのミドルウェアで時間がかかっているか」可視化に有効
  • 参照: [[microservices]]

進め方

  1. SLOを決める([[non-functional-requirements]] で定義済みならそれを使う)

    • 例: 可用性 99.9% / 月、p95レイテンシ 500ms 以内、エラー率 0.1% 以下
    • SLOが決まると「何を監視するか」が自動的に決まる。ユーザー影響起点で考える

  2. 監視設計シートを書く(後述テンプレート使用)

    • 監視項目・閾値・重大度・通知先・対応手順を表にまとめる
    • 「これが鳴ったら誰が何をするか」を書けないアラートは設定しない

  3. アラートを設計する

    • 鉄則: アクション可能なものだけ鳴らす
    • 重大度3区分: P1=即時対応(24h)、P2=営業時間内対応、P3=記録のみ
    • P1: ページャー/電話で通知。P2: チャット通知。P3: ダッシュボードのみ
    • アラート疲れ(鳴り続けて誰も見なくなる状態)は最悪。鳴ったら必ず対応 or 閾値見直し

  4. ダッシュボードを1枚作る

    • エラー率・レイテンシ(p95)・スループット・直近デプロイマーカーを1画面に配置
    • 一目で「健全/異常」が分かることが最重要。詳細は別ダッシュボードへ

  5. ランブックを書く

    • 頻出障害シナリオごとに: 症状 / 確認コマンド / 対処手順 / エスカレーション先
    • 「午前3時に眠い目をこすりながら実行できる粒度」 で書く
    • コマンドはコピペ可能な形式で。環境変数や接続先も明記

  6. バックアップ・リストアを検証する

    • 自動バックアップを設定したら必ずリストア訓練を実施する
    • 「リストアしたことのないバックアップは無いのと同じ」
    • 復旧時間(RTO)と復旧時点(RPO)を計測・記録する

  7. 個人開発の最小構成

    • 外形監視: UptimeRobot 無料枠(5分間隔・メール通知)
    • エラートラッキング: Sentry 無料枠(エラー集約・スタックトレース)
    • メトリクス: Railway / Render / Vercel 等のプラットフォーム標準メトリクス
    • 参照: [[solo-development]]

障害対応フロー

検知(アラート/ユーザー報告)
  ↓
[5分以内] インシデント宣言・担当者アサイン
  ↓
[15分以内] 影響範囲の把握(何が・どのくらい・誰に影響しているか)
  ↓
[30分以内] ユーザー・ステークホルダーへの状況告知(「調査中」だけでもよい)
  ↓
復旧を最優先(原因調査より先)
  - 直近デプロイがあればロールバックを第一候補にする([[cicd-deployment]])
  - トラフィック切り替え・機能フラグOFF・スケールアウトなど手段を選ぶ
  ↓
サービス復旧確認・ユーザーへの復旧通知
  ↓
根本原因調査([[debugging]] のフローを適用)
  ↓
[5営業日以内] ポストモーテム作成・共有

成果物テンプレート

ポストモーテム

# ポストモーテム: [インシデント名]

**原則: 非難なし(blameless)。個人でなくシステムと手順に目を向ける。**

## 概要
- 発生日時: YYYY-MM-DD HH:MM (JST)
- 検知方法: [アラート名 / ユーザー報告 / 社内報告]
- 復旧日時: YYYY-MM-DD HH:MM (JST)
- ダウンタイム: X時間Y分

## ユーザーへの影響
- 影響ユーザー数: 約X人
- 影響内容: [例: ログイン不可 / 決済エラー / ページ表示遅延]

## タイムライン
| 時刻 | 出来事 |
|---|---|
| HH:MM | アラート発報 |
| HH:MM | 担当者が確認開始 |
| HH:MM | 原因仮説Aを確認 |
| HH:MM | ロールバック実施 |
| HH:MM | サービス復旧確認 |

## 根本原因
[Why→Why→Why で掘り下げた根本原因を記述]

## うまくいったこと
- [例: アラートが3分以内に発報した]
- [例: ロールバック手順が整備されており10分で完了した]

## 再発防止アクション
| アクション | 担当 | 期限 | 状態 |
|---|---|---|---|
| [具体的な改善策] | @xxx | MM-DD | TODO |
| [監視閾値の調整] | @yyy | MM-DD | TODO |

監視設計シート

| 監視項目 | 閾値(警告) | 閾値(緊急) | 重大度 | 通知先 | 対応ランブック |
|---|---|---|---|---|---|
| エラー率 | 0.5% | 1.0% | P1 | PD/Slack#alert | runbook/error-rate.md |
| p95レイテンシ | 800ms | 2000ms | P1 | PD/Slack#alert | runbook/latency.md |
| 可用性(外形) | - | 1回失敗 | P1 | PD/メール | runbook/downtime.md |
| CPU使用率 | 70% | 90% | P2 | Slack#warn | runbook/cpu.md |
| ディスク使用率 | 80% | 95% | P2 | Slack#warn | runbook/disk.md |

チェックリスト

  • SLOを数値で定義した(可用性・レイテンシ・エラー率)
  • 全アラートに「誰が・何をする」が紐付いている
  • ダッシュボードで30秒以内に健全/異常を判断できる
  • 頻出障害シナリオのランブックが存在する
  • バックアップのリストアを実際に試した
  • ポストモーテムを非難なしで書く文化がある(または個人開発なら自己振り返りの習慣がある)
  • アラートが鳴ったら必ず対応 or 閾値見直しのルールがある

アンチパターン

  • リリース後に監視を後付け: 監視設計はリリース前。本番稼働後に気づいても手遅れになることがある
  • 全アラートをチャットに垂れ流し: 誰も見なくなる。通知先と重大度を必ず区別する
  • 平均レイテンシだけ監視: p95/p99を見ないと遅いユーザーを見逃す
  • ポストモーテムが犯人探しになる: 個人を責めても再発は防げない。システムと手順に目を向ける
  • ランブックなしで属人対応: 担当者が休んでいると何もできない状態になる
  • バックアップのリストア未検証: バックアップが壊れていても気づかない。定期的なリストア訓練が必須
  • SLOなしで「なんとなく監視」: 何が正常で何が異常か分からないため、アラートが多すぎるか少なすぎるかのどちらかになる

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割担当担当する作業
司令塔(メインモデル)最終判断者障害時の影響判断・復旧判断・ステークホルダーへの報告文作成・ポストモーテムの統括
Opus相当深い分析根本原因分析(Why連鎖)・SLO設計の妥当性評価・複雑なシステム全体の障害仮説立案
Sonnet相当実装・構築監視設定の実装・ダッシュボード構築・ランブック作成・アラートルール記述・ポストモーテムドラフト
Haiku相当収集・一次解析ログ・メトリクスの収集・タイムライン整理・エラーカウント集計・コマンド実行と結果転記

関連スキル

  • [[orchestration]] - モデル委譲の共通原則
  • [[non-functional-requirements]] - SLO/SLAの定義
  • [[cicd-deployment]] - ロールバック・デプロイ管理
  • [[debugging]] - 根本原因調査の手順
  • [[microservices]] - 分散トレーシングの設計
  • [[security]] - セキュリティインシデント対応
  • [[solo-development]] - 個人開発での現実的な監視構成
  • [[performance-optimization]] - レイテンシ・スループット改善

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.