監視設計の基本と可用性向上の考え方
監視設計の出発点：SLO/SLI/アラート方針
目的と対象の棚卸し
監視は「全部見る」ではなく「落とさないために必要なことだけを見る」が基本です。顧客体験を壊す要因（例：決済不可、APIタイムアウト、管理画面ログイン不能）を列挙し、影響範囲（収益/業務/信頼）と復旧難易度で優先度をつけます。インフラ/アプリ/外部依存（DNS, CDN, 支払ゲートウェイ）の三層で整理し、責任境界を明確にします。
SLIとSLOの数値化
SLIは体験を測る指標、SLOはその目標です。例として「チェックアウト成功率」「API p95レイテンシ」「5xxエラーレート」。月間SLOを99.9%にすると誤差予算（エラーバジェット）は約43分/月です。SLOは「事業が許容できる停止時間」から逆算し、バックエンドの冗長化・当番体制・コストとトレードオフで合意します。
アラート設計の原則
ページャ（即時起床）を鳴らすのは「ユーザー影響が現在進行形で大きいとき」に限定します。推奨は以下です。
- ページャ条件：5分間のp95レイテンシ>400ms かつ 5xx>2%
- チケット条件：ディスク使用率>85%（30分継続）、バッチ遅延<SLA逸脱見込み
- 情報通知：新規デプロイ、オートスケール発火、バックアップ完了
単一メトリクスの瞬間風速ではなく、複合条件と時間窓で誤検知を抑えます。デプロイ中の一時的な変動はサイレンスで回避し、同一原因の重複はグループ化して一件に束ねます。
何をどう監視するか：メトリクス/ログ/トレースと外形監視
ブラックボックスとホワイトボックス
外形（ブラックボックス）は「ユーザー視点で動いているか」を見るもの。内部（ホワイトボックス）は「なぜ遅い/落ちたか」を解く手がかりです。どちらか片方では片手落ちです。SLO達成の判定は外形、原因特定と予兆は内部で捉えます。
具体的な監視項目と閾値例
- 外形監視：TLS証明書期限（30日前で警告/7日前でページャ）、チェックアウト合成テスト（失敗率>1%でページャ）
- アプリ：5xxレート、p95/99レイテンシ、キュー滞留長（滞留>N分でページャ）
- DB：コネクション使用率>80%（15分）、レプリカ遅延>10秒、ロック待ち時間>200ms
- OS/コンテナ：CPUスチール、メモリ圧迫（RSS/ワーキングセット）、ファイルディスクリプタ枯渇>90%
- ネットワーク：SYNエラーレート、eBPFベースのドロップ、AZ間レイテンシ逸脱
- ジョブ/バッチ：遅延の「傾き」を監視（直値ではなく増加速度）
ダッシュボードは「SLOトップ（赤/黄/緑）→レイテンシブレークダウン→資源利用→依存先の健全性」の順に掘れる構成にします。可観測性の3本柱（メトリクス/ログ/トレース）を一つの事実で結び、トレースIDで相互にジャンプできるとMTTRが縮みます。
可用性を上げる運用：ノイズ削減、当番、Runbookと自動化
アラートノイズ削減テクニック
- ダイナミックしきい値：曜日/時間帯のベースラインからの逸脱を検知
- ヒステリシス：回復条件を発火条件より緩めにしチャタリングを防止
- 関連付け：同一AZ障害は一件に集約、根本のネットワーク異常にぶら下げる
- 変更連携：デプロイ/インフラ変更イベントをオーバーレイ表示し誤検知を見分ける
エスカレーションとMTTR短縮
一次当番は「判断不要の手順」を高速実行、難易度が上がる前に二次へエスカレーション。Runbookは「前提→判定→コマンド→期待結果→戻し方」まで1スクリーンで完結させます。生成AI（ChatGPT, Claude, Gemini）で初稿を作り、実機検証で差分を埋めると整備が進みます。IaCの監視ルールや自動修復スクリプトはCopilotで雛形を用意し、レビューを通して標準化します。
キャパシティとリリース連携
可用性は設計だけでなく日々のオペレーションで磨きます。エラーバジェットの消費が早いときはリリースを凍結し信頼性改善に集中、逆に余裕がある月は性能実験や大規模移行の試行に充てます。メンテナンスはSLO対象外時間帯に計画し、ユーザー告知とリハーサルをセットにします。
身近な企業活用例：中規模ECの失敗と改善
オンプレ由来の構成を踏襲しつつコンテナ化したばかり。監視はCPU/メモリとHTTP 200率のみ。ブラックフライデー本番でDB CPU飽和→カートAPIがタイムアウト、多数の誤検知が雪崩れて担当が判断不能に。復旧まで90分、売上に大打撃。翌月、次の施策を実行しました。
- SLOを「注文成功率99.9%」「API p95<400ms」に設定、誤差予算43分/月を明文化。
- 外形の合成チェックアウト（商品検索→カート→決済）を1分間隔で実施、失敗率をSLOに連動。
- アプリは5xx×レイテンシの複合でページャ、DBはコネクション使用率とロック待ちで予兆検知。
- デプロイイベントを監視に連携、10分の自動サイレンスを適用。
- Runbookを整備（フェイルオーバー、接続プール再設定、緊急スロットリング）。初稿はChatGPTで作成し、現場で検証・更新。
- 容量プランニングを週次で可視化、ピーク時は読み取り系を水平スケール。Copilotでアラート定義のIaC化。
結果、ページャは月120件→45件に減少、誤報は70%削減。次の大型セールは合成監視で早期検知→APIの同時接続上限を一時引き上げ、MTTRは18分に短縮。SLO達成率は3カ月連続で目標クリアとなり、施策の可視化により経営合意も取りやすくなりました。運用担当はClaude/Geminiで障害報告のテンプレを即時生成し、顧客広報も迅速化できました。
監視設計はツールの羅列ではなく、事業の許容停止時間から逆算した指標設計、外形×内部の二層監視、ノイズを抑えるアラート方針、Runbookと当番体制の運用がそろって初めて効きます。これらを地道に回すことで、サーバ監視運用事業の現場は「問題が起きる前に気づける組織」に変わっていきます。
