運用改善PDCAの回し方
障害対応を「根性」で乗り切る時代は終わりました。サーバ監視運用で効くのは、手作業をひとつずつ潰しながら、数字で回すPDCAです。見る指標、会議の回し方、アラート設計、改善の出し方を決め打ちにすると、現場の迷いが消えます。以下は、意思決定にそのまま使える型です。
目標を数字に落とす：SLOと「起きてもよい障害」を決める
改善は「期待値の定義」から始まります。まずサービスごとにSLO/SLIを決め、エラーバジェットを数値で持ちます。たとえば以下です。
- 可用性SLO：28日間でAPI成功率99.9%（許容ダウンタイム最大約43分）
- 遅延SLO：p95レイテンシ400ms以下
- 監視SLO：P1のMTTD2分未満、MTTA5分未満、MTTR30分未満
障害の深刻度も先に定義します。
- P1（顧客影響大）：売上直結APIの全リージョン障害など。24/7ページャ、即時エスカレーション。
- P2（部分/予兆）：一部リージョン、遅延劣化。営業時間内対応。
- P3（健全性/運用品質）：バックアップ失敗、ディスク使用率の上昇。翌営業日で十分。
アラートはSLO消費に連動させます。たとえば「エラー率が連続5分でSLOの消費速度を超えたらP1」。静的なしきい値だけでなく、エラーバジェットの消費率を軸にすることで、夜間の誤検知を抑えられます。
Do：監視・運用の型を用意する（アラート設計とプレイブック）
検知→一次対応→復旧までをテンプレ化します。ポイントは3つです。
- アラート設計
- 命名規則：svc.env.region.metric.threshold.severity。これでダッシュボードと連携しやすくなります。
- 抑止と集約：メンテナンスウィンドウ、デプロイタグでの自動サプレッション、同一事象のバースト抑制（例：5分で1件に集約）。
- 種類を分離：SLO違反（P1/P2）と健全性（P3）を別キューに。オンコール疲弊を避けます。
- プレイブック
- 項目の固定：影響範囲、参照ダッシュボードURL、一次確認コマンド、ロールバック手順、タイムボックス、エスカレーション先。
- 判断の自動化：条件分岐をif/thenで明記。例「p95>800msが10分継続→カナリアへ切替→改善なければロールバック」。
- 雛形づくりにはChatGPTを活用。監視メッセージを貼るだけで、初動手順の叩き台が数分でできます。
- 自動化の基準
- 「月5回以上」「1回10分以上」「障害時に発生」の3条件を満たせば自動化候補。Copilotでスクリプトの雛形を素早く作り、レビューで堅牢化します。
- ログ検索やクエリ最適化はGeminiで候補を出して検証。タイムライン再現の工数を減らします。
エスカレーションマトリクスも明文化します。P1は5分でL2、15分でL3へ。L3不在時はディレクターへ。電話/Slack/チケットの優先チャネルも固定します。
Check：毎週“数字でふりかえる”会議のやり方
30分の定例で“事実だけ”を確認します。資料は1枚に圧縮します。
- 運用KPI：MTTD/MTTA/MTTR（中央値とp95）、アラート総数、ノイズ率（手動クローズ÷総数）、SLO消費率。
- トップノイズ10件：件数・原因・是正案・担当・期限。
- 直近のP1/P2ポストモーテム：顧客影響、検知の妥当性、再発防止の進捗。
議論は「感想」ではなく「アクション可能な差分」に絞ります。例：「P1のMTTDが4分→2分に改善、原因はログ基盤の遅延解消」「ノイズ率40%→25%、P3のディスク警告を週次にまとめた効果」。議事要約はChatGPTで下書きし、数値だけ人が確定させるとスピードが出ます。
身近な企業活用例：中堅ECの“アラート地獄”脱出
年商50億のEC運営A社（インフラ3名、アプリ10名）。ブラックフライデーにP1/P2が1日200件を超え、オンコール離脱者が発生。失敗要因は「静的しきい値の乱立」「プレイブック不在」「営業時間外のP3通知」。
改善では、SLOを「注文API成功率99.95%」「カートp95 350ms」に定義し、エラーバジェット連動のP1/P2に集約。P3は日次レポートに回収。プレイブックをChatGPTで草案→現場レビューで即日公開。ログ分析のクエリ例はGeminiで叩き台を作成。よくある手順（キャッシュパージ、ロールバック）はCopilotでスクリプト化。結果として、ノイズ率は52%→14%、MTTDは7分→90秒、MTTRは45分→18分に短縮。売上影響のある障害は四半期でゼロに。
Act：改善案件を継続的にリリースする仕組み
「やると決めた改善」を確実に出すには、運用改善の開発プロセス化が効きます。
- 改善バックログ：種類を3つに限定（ノイズ削減、自動化、検知強化）。各カードは“計測可能な完了条件”を必須化。
- WIP制限：同時進行は1人2件まで。サイズは1週間で終わる粒度に分割。
- 安全なリリース：しきい値変更は段階適用（10%→50%→100%）、ロールバック手順をプレイブックに紐づけ。
- やめることリスト：効果の薄い定例・レポート・P3通知を四半期で棚卸し。足すより先に削る。
- エラーバジェットの使い道を明確化：消費が大なら新機能凍結し、改善へ人員スイッチ。小なら攻めの変更を許容。
改善のROIは「削減できたアラート件数×平均対応時間×人件費」で粗く見積り、四半期で人時を再配置します。数字が出れば、経営との会話も早くなります。
サーバ監視運用は、日々の検知と復旧を回しつつ、SLO・アラート設計・プレイブック・自動化を少しずつ磨く積み重ねです。PDCAをこの型で固定すれば、現場は静かに、障害は短く、プロダクトのスピードは落ちません。監視運用事業としても、こうした型の提供と定着支援こそが価値になり、システムとチームの両輪を安定させます。
