はじめに
本記事はNew Relic Advent Calendar 2025 23日目のエントリーです
SREの仕事は「障害を起こさないこと」ではありません。
現場で日々システムと向き合っていると、
本当に重要なのは、失敗を 「なくすこと」ではなく「どう扱うか」 だと感じるようになります。
本記事では、
- 「良い失敗」とは何か
- そしてそれを どう“設計”するか
をテーマに、New Relic を使った実践を交えながら整理します。
SREが目指すべきは「失敗ゼロ」ではない
SREの世界でよく言われることですが、改めて強調したいポイントです。
- 失敗は「避けるもの」ではなく 必ず「起きるもの」として設計に織り込む
- 目指すべきは「壊れないこと」ではなく 壊れても素早く復旧できるように備えること
失敗を完全になくそうとすると、
- 小さな異常が見過ごされる
- 隠蔽体質になる
といった状態を招き、より大きな事故につながるリスクが高まります。
だからこそ 失敗は必ず起きる という前提で、あらかじめ
- 「どう壊れるか」
- 「どう気づくか」
- 「どう学ぶか」
を考え、設計しておく事が重要です。
「悪い失敗」と「良い失敗」
私なりに整理すると 「悪い失敗」 とは次のようなものです。
- 気づいたら壊れていた
- ユーザーからの連絡で初めて発覚する
- 原因がよく分からないまま復旧する
- 同じ原因で何度も再発する
一方で、「良い失敗」 とは次のように定義しています。
- ちゃんと検知される
- ちゃんと記録が残る
- 振り返りの際に、次の失敗を小さくする材料にできる
重要なのは、失敗そのものではなく
「失敗から何が得られるか」 です。
運用を続ける以上、失敗を完全に避けることできません。
だからこそ、失敗を
発生した際に“うまく扱えるように設計する”
という視点が重要だと考えています。
「良い失敗」を作るための3つのポイント
1. 「ちゃんと記録が残る」ようにする
良い失敗の第一条件は、後から事実を辿れることです。
そのためには、普段からあらゆる観点で可観測性（Observability）を高めておく必要があります。
私たちは New Relic を活用し、次のような取り組みを実践しています。
| 取り組み | New Relicでの具体施策 | 目的・得られる効果 |
|---|---|---|
| APM / Browser / Mobile の導入 | アプリケーション、ブラウザ、モバイルそれぞれにNew RelicのAgentを導入して計測 | ユーザー操作からバックエンドまで一気通貫で問題を追跡可能にし、いつどこでどんな問題が起きたかを迅速に特定できる |
| ログ / エラーの集約 | ログやエラーを New Relic に集約、Logs, Errors Inboxの活用 | 問題発生時にエラーやログが既に自動分析されている状態が作れ、原因調査を迅速に行える |
| メトリクス・トレース・ログの相関 | Metrics / Traces / Logs を同一時間軸で確認 | 事象の前後関係を時系列で把握でき、推測ではなく事実ベースで分析できる |
| 変更追跡(Change Tracking)の有効化 | デプロイや設定変更を New Relic 上に記録 | 「いつ・何を変更したか」を後から確認でき、変更起因の問題を素早く切り分けられる |
「原因を突き止めるための材料」を平時から貯めておくことで、いざ問題が起きたときに 推測ではなく事実に基づいた分析 が可能になります。
ただし、データの使用量はコストにも直結するため、不要なデータはそもそも送らないようにしたり、送られてきてもNew Relicに取り込まれる前に除外(Drop)するテクニックも重要です。
▼参考▼
2. 「ちゃんと検知される」ようにする
どれだけ記録が残っていても、発覚が遅ければ良い失敗にはなりません。
一方で、無駄な通知を飛ばしすぎると、アラート疲弊やオオカミ少年状態を招く原因となってしまいます。
そこで重要になるのが アラート設計 です。
私たちが意識しているポイントは次の通りです。
- Critical User Journey（CUJ:重要なユーザー体験）を基準に考える
- 「落ちたら鳴る」「リソースが枯渇したら鳴る」ではなく 「ユーザー体験に支障が出たら鳴る」 ような閾値に調整する
- 本当に対応が必要なシグナルだけを通知する
このあたりは最初から正解を導き出すのは難しく、
定期的に関係者と会話を重ねながら改善していく取り組みが重要 だと感じています。
そのため私たちは、
パフォーマンス定点観測会(通称：パフォ会) を定期的に開催しています。
New Relic のダッシュボードを見ながらパフォーマンスやアラートの挙動を確認し
- 「本当にユーザー体験に影響しているか？」
- 「このアラートは今も必要か？」
といった観点で会話を重ねています。
こうした場を継続的に持つことで、アラート設計や閾値が形骸化せず、
対応が必要な時にのみ「ちゃんと検知される失敗」へ育てられる と考えています。
3. 「振り返り」をして次の失敗を小さくする
良い失敗かどうかを最終的に決めるのは、振り返りです。
インシデントが発生した際は、
- 非難しない（ブレームレス）
- 人ではなく仕組みで解決する
- 事実と意見を分ける
ことを意識しながら、 非難のない振り返り(ポストモーテム) を行います。
New Relic に集約・分析された情報をもとに、
- どの兆候を拾えていなかったのか
- どうすれば未然に防げたか
- 設計やアラートをどう変えるべきか
- この問題の本質的な原因は何なのか
- どう対策をすれば恒久的な再発防止につながるか
を整理し、仕組みとしての再発防止策にむけたアクションに取り組みます。
重要なのは、単に元の状態へ戻すことではなく、
失敗を通じて、以前よりも強い状態へシステムと運用を進化させることです。
また現在、インシデントの発生傾向分析や対応効率化のために、Waroom というSaaSの活用も検討しています。
New Relic は標準では Waroomの連携対象 ではありませんでしたが、
相談したところ迅速にご対応いただき、現在 PoC を実施中です。
正式導入した際には、改めて効果を共有できればと考えています。
まとめ
- 失敗は、うまく扱えるよう設計して対処するもの
- 良い失敗は「ちゃんと記録され」「ちゃんと検知され」「学習され次の失敗を小さくする材料になる」
失敗から学び、次の失敗をより小さくするだけでなく、 以前よりも強いシステムや組織へ進化させていく。
それこそが、SREが目指す真のレジリエンス（回復力）だと考えています。
そして、その実現には、
New Relicを単なるモニタリング（監視）ツールとして使うのではなく、
フルスタックオブザーバビリティの基盤としてフル活用することが不可欠です。
そのヒントとして、本記事がお役に立てば幸いです。
最後にちょっとだけ宣伝
NRUG SRE支部 再始動します！
皆様のご参加を心よりお待ちしています♪
NRUG SRE支部本 大好評発売中です♪
Service Level Managementを活用したCUJ観点でのSLI/SLO設計や、パフォ会に関する取り組みは、こちらに詳しくまとめています。
SREメンバー（ジュニアクラス）若干名募集中です！
本記事で紹介したような
「失敗を学習に変え、システムと組織を強くしていく」
SREの取り組みに興味のある方を対象に、ジュニアクラスのSREを若干名募集しています。
- 失敗を“なくす”のではなく、うまく扱う文化
- Observability を基盤にした改善サイクル
- New Relic をフル活用した実践的なSRE活動
等に関心がある方は、ぜひカジュアル面談させてください♪