Zenn Trending に 元オンプレ屋が AWS 運用監視設計で最初に間違えたこと — 「正常を定義する」が先だった がランクインしました。「まず CPU・メモリ・ディスクにしきい値アラートを張る」という出発点が、実は順序を間違えているという気づきです。これは単なる監視ツールの話ではありません。「何が正常か」を定義せずにアラートだけ増やすと、鳴りすぎて誰も見なくなり（アラート疲れ）、本当に効くべき障害を見逃す——という、運用設計に共通する落とし穴を突いているからです。
受託開発の現場では、「納品後、監視が無いまま運用が始まり、ユーザーからの連絡で初めて障害に気づく」「アラートが鳴りっぱなしで、もはや誰もミュートを解除しない」という状態が珍しくありません。受託でシステム開発を支える立場では、これは 「監視ツールを入れられるか」ではなく、「正常を定義し、意味のあるアラートだけが鳴り、誰がどう対応するかまで含めて運用に乗せて引き渡せるか」を設計に組み込む課題だと捉えています。これまで Pinterest 「CPU Zombies」に学ぶ受託パフォーマンス SRE 監査（GH Media） で扱った 性能の可視化、Postgres / SQLite による堅牢ワークフローのバックエンド受託（GH Media） で扱った 処理の信頼性、バックエンドのメモリ・コスト最適化受託（GH Media） で扱った リソース最適化と接続して、本記事では 「運用引き渡し監視設計支援」を 受託パッケージとして整理します。
なぜ「正常の定義」が先なのか
| 観点 | しきい値先行（事故る） | 正常定義先行（2026） |
|---|---|---|
| 起点 | CPU 80% で鳴らす | まず正常な状態を言語化 |
| 指標 | リソースばかり見る | ユーザー影響（SLI）を見る |
| アラート | 鳴りすぎて無視 | 意味あるものだけ鳴る |
| 対応 | 誰が出るか曖昧 | エスカレーション明確 |
| 見逃し | 重大障害をスルー | 異常を確実に検知 |
| 成果 | アラート疲れ | 静かで信頼できる監視 |
つまり 「監視が入っている」ことと「異常を確実に検知して対応できる」ことは別物であり、受託でも 「正常を SLI/SLO で定義し、そこからの逸脱だけをアラート化し、対応フローまで整えて引き渡す」ことが品質の前提になりました。これにより 「鳴ったら本当に対応すべき監視」を成果物として保証できます。
監視設計で外してはいけない 3 つの原則
原則 1: リソースより先に「ユーザー影響」を測る
CPU が高くてもユーザーが困っていなければ障害ではありません。受託では 可用性・レイテンシ・エラー率といった SLI を主軸に置き、「ユーザーが困っているか」で異常を判定します。
原則 2: 正常の幅（ベースライン）を決めてから逸脱を鳴らす
固定しきい値は時間帯・季節で外します。受託では 平常時のベースラインを計測し、そこからの逸脱を異常と定義することで、鳴りすぎと見逃しの両方を減らします。
原則 3: アラートは「対応できる人と手順」とセットで作る
対応者と Runbook の無いアラートは、ただのノイズです。受託では アラートごとに対応手順・エスカレーション先を紐付け、鳴ったら動ける状態で引き渡します。
受託で提供する「運用引き渡し監視設計支援」5 フェーズ
フェーズ 1: 現状診断（1 週間）
- 既存アラートの棚卸しとノイズ率の評価
- 監視の空白（測れていない領域）の特定
- 過去インシデントと検知漏れの振り返り
- ステークホルダーの対応体制ヒアリング
フェーズ 2: 正常定義・設計（1〜2 週間）
- 主要ユーザー導線の SLI/SLO の定義
- 平常時ベースラインの計測
- アラート条件（逸脱・持続時間）の設計
- エスカレーション・通知経路の設計
フェーズ 3: 実装（2〜3 週間）
- メトリクス・ログ・トレースの収集整備
- ダッシュボードとアラートの実装
- 各アラートへの Runbook 紐付け
- ノイズアラートの削減・統合
フェーズ 4: 訓練・引き渡し（1 週間）
- アラート発報のリハーサル
- 対応フローのウォークスルー
- オンコール体制と当番表の整備
- 運用ドキュメントの引き渡し
フェーズ 5: 継続運用（継続）
- SLO 達成率の定期レビュー
- 誤報・見逃しの是正
- 新機能追加時の監視拡張
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| 指標 | SLI/SLO（可用性・レイテンシ・エラー） | リソースのみ |
| 収集 | メトリクス + ログ + トレース | メトリクスのみ |
| 可視化 | サービス別ダッシュボード | サーバ別グラフ |
| アラート | 逸脱 + 持続時間条件 | 単純しきい値 |
| 通知 | 重大度別ルーティング | 全部同じ宛先 |
| 対応 | Runbook + オンコール | 口頭・属人 |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| 本番運用する基幹システム | 検証用の使い捨て環境 |
| 障害がユーザーに直結する | 落ちても影響が軽微 |
| アラート疲れが起きている | そもそも監視が無い段階を脱したい |
| 運用を内製チームに引き継ぐ | 開発者が常時張り付ける |
| SLA を顧客に約束している | 可用性の約束が無い |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | 監視するサービス | SLI の対象導線 |
| SLO | 目標水準 | 達成基準と免責 |
| アラート | 条件と通知経路 | 対応時間帯 |
| 対応体制 | オンコール / Runbook | 内製/委託の分担 |
| 引き渡し | ダッシュボード / 手順 | 保守体制 |
| 継続保守 | レビュー / 是正 | 運用費用 |
価格モデル — 運用引き渡し監視設計パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 監視診断 | 30 万円〜 | 1 システム | ノイズ評価 + 設計レポート |
| 標準構築 | 120 万円〜 | 中規模 | SLI/SLO + アラート + Runbook |
| 本格構築 | 240 万円〜 | 中〜大規模 | + トレース + オンコール整備 + 訓練 |
| Lite 保守 | 7 万円〜 / 月 | 小規模 | SLO レビュー + 軽微是正 |
| Standard 保守 | 20 万円〜 / 月 | 中規模 | + 誤報是正 + 監視拡張 |
顧客側 ROI 試算（業務システム想定）
| 項目 | しきい値先行 | 正常定義先行 | 差分 |
|---|---|---|---|
| 検知 | ユーザー連絡で気づく | 自動で先に検知 | 障害時間の短縮 |
| アラート疲れ | 無視される | 鳴れば対応 | 見逃しの抑制 |
| 対応 | 属人・手探り | Runbook で即応 | 復旧時間の短縮 |
| 信頼 | 障害多発で毀損 | 安定運用 | 顧客満足の維持 |
| 年間効果 | — | — | ダウンタイム短縮 + 信頼の維持 |
標準構築（120 万円〜）でも、重大障害の検知が早まり復旧が短縮されるだけで、機会損失と信頼毀損の回避として十分に正当化できます。
ハマりやすい 5 つの落とし穴
落とし穴 1: 正常を定義せずアラートを張る
鳴りすぎて全員が無視します。SLI で正常を先に定義します。
落とし穴 2: リソース指標だけを見る
ユーザーが困っても気づけません。ユーザー影響を主軸にします。
落とし穴 3: 固定しきい値に頼る
時間帯変動で誤報します。ベースラインからの逸脱で判定します。
落とし穴 4: Runbook を用意しない
鳴っても誰も動けません。手順と対応者を紐付けます。
落とし穴 5: 作って終わりにする
誤報と見逃しが蓄積します。定期レビューで是正します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1 | 既存アラート棚卸し + ノイズ率評価 |
| Week 2〜3 | SLI/SLO 定義 + ベースライン計測 |
| Week 4〜6 | 実装 + Runbook 紐付け + ノイズ削減 |
| Week 7 | 発報訓練 + オンコール整備 |
| Week 8〜13 | SLO レビュー + 是正の運用開始 |
まとめ — 「とりあえずアラート」から「正常を定義して引き渡す」へ
監視は、しきい値を張ることではなく「正常を定義し、そこからの逸脱だけを意味あるアラートにする」ことから始まります。受託でシステム開発を支える立場では、SLI/SLO で正常を定義し、対応フローまで整えて運用に乗せて引き渡す 「運用引き渡し監視設計支援」が、鳴ったら本当に対応すべき監視を成果物として届ける新しい主力サービスです。性能面の可視化は Pinterest 「CPU Zombies」受託パフォーマンス SRE 監査（GH Media） を、デプロイ運用の改善は デプロイリードタイム短縮の CI/CD 改善受託（GH Media） を併読してください。
弊社では監視診断 / 標準構築 / 本格構築 / Lite / Standard の各段階で本パッケージを提供しています。「アラートが鳴りすぎて無視している」「障害にユーザー連絡で気づく」「運用を安心して引き継ぎたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
