「システムが動いているのは当たり前」——。ユーザーからも、そして時には経営層からもそう思われがちなシステム運用。しかし、その「当たり前」を維持するための難易度は、ここ数年で劇的に跳ね上がっています。かつての「死活監視」だけで事足りた時代は終わり、私たちは今、 「ビジネスの成長を止めないための運用」 という新しいフェーズに立たされています。第1回では、現代のシステム運用においてなぜ従来の監視スタイルが通用しなくなっているのか、その背景にある「DevOpsの原点」と「運用の真の目的」を再定義します。
DevOpsの原点：対立から協力へ
「DevOps」という言葉が一般化して久しいですが、その真の目的を忘れてはいないでしょうか。
この概念が世界に衝撃を与えたのは、2009年のVelocity Conference。Flickrが発表した 「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」 というプレゼンテーションでした。
当時の常識では、「開発（Dev）は変更を加えたい」「運用（Ops）は安定のために変更を拒みたい」という、構造的な対立がありました。しかしFlickrは、 「ビジネスの目的は、新しい価値（コード）を素早く、安定してユーザーに届けることである」 と定義し、両者が協力する文化を提示したのです。
ここで重要なのは、DevOpsの本質はツール（CI/CDなど）を入れることではなく、 「ビジネスのアジリティ（敏捷性）を高めるための協力体制」 であるという点です。
運用のゴールを再定義する
では、DevOpsの文脈において、運用の「成功」とは何を指すのでしょうか？
単に「アラートが鳴らないこと」ではありません。資料では、運用のゴールを以下の3つの指標の最適化として整理しています。
MTTD / MTTR / MTBF の関係性
エンジニアリングとして追いかけるべきは、この3つの時間軸です。
-
MTTD (Mean Time To Detect): 平均検出時間
異常が発生してから「気づく」までの時間。 -
MTTR (Mean Time To Recovery): 平均復旧時間
気づいてから「直す（サービスを戻す）」までの時間。 -
MTBF (Mean Time Between Failures): 平均故障間隔
次の故障までの時間。つまり「壊れにくさ」。
現代の複雑なシステムでは、故障（Failure）をゼロにすることは不可能です。だからこそ、 「いかに早く気づき（MTTD短縮）」「いかに早く戻すか（MTTR短縮）」 に注力することが、結果としてユーザー体験を守る最善策となります。
なぜ「これまでの監視」では足りないのか？
「サーバーの死活監視もリソース監視もやっている。それで十分ではないか？」という疑問を持つかもしれません。しかし、現代のシステム構造がその前提を崩しています。
モノリスからマイクロサービスへ
かつての「1つの大きなアプリケーション（モノリス）」であれば、サーバーが生きているか死んでいるかで状況が把握できました。しかし、現在の分散システムでは、「サーバーは動いているが、特定の機能（決済だけ、検索だけ）が動かない」というグレー障害が頻発します。
「何のため」の監視か？
システムがビジネスと直結してきたいま、監視の目的は以下の3つに分類できます。
- ビジネスのため： PV、MAU、売上などのKPIを守る。
- ユーザーのため： レスポンス速度やエラー率など、ユーザー体験（UX）を守る。
- エンジニアのため： どこに原因があるかを即座に特定し、疲弊を防ぐ。
これまでの監視は、主に「インフラが壊れていないか」というエンジニア側の視点に偏りすぎていました。しかし、ビジネスを支える運用であるためには、「ユーザーに価値が届いているか」を起点とした監視へのパラダイムシフトが必要なのです。
監視は「健康診断」から「攻めの戦略」へ
これからの監視は、単なる事後報告のツールではありません。
-
開発を加速させるための「安心材料」
-
ビジネスの損失を最小限に抑える「防波堤」
-
組織の意思決定を支える「客観的なデータ」
これらを実現するためには、適切なフレームワークの選択と、システムの内部をより深く知るための技術（オブザーバビリティ）が必要になります。
次回予告：ユーザー体験を可視化する「監視デザインパターン」
「よし、監視を強化しよう！」と思ったとき、陥りがちなのが「とりあえず全部のアラートをSlackに飛ばす」という罠です。それは運用崩壊への第一歩かもしれません。
次回は、USEメソッドやREDメソッドといった具体的なフレームワークを使い、どのように「意味のある監視」を設計していくべきか、その具体的な実践法について解説します。
今回のまとめ：
- 運用の目的は、開発速度と安定性の両立（DevOps）にある。
- 追うべき指標は「気づく速さ（MTTD）」と「直す速さ（MTTR）」。
- 監視はインフラ視点から「ユーザー/ビジネス視点」へと転換すべき。
その他
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！
New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
