この記事はDENSO Advent Calendar 2025の23日目の記事です。
Webアプリ、スマホアプリ、インフラ、そしてバックエンド開発。これら一連の開発・運用を経験する中で、私は一つの確信に至りました。それは 「運用は、作ってから始まるのではない。設計から始まっている」 ということです。
私流ではありますが、リリース初日から迷わず、そして「疲弊しない」ための監視設計のヒントを共有します。
1. はじめに
開発担当者が運用も担う「フルサイクル」の強み
私たちは、開発と運用を同じチームで行う体制をとっています。 開発者が運用を担う最大のメリットは、「知見の断絶」がなくなることです。
通常、開発から運用へ引き継ぐ際には大量のドキュメントや説明会が必要ですが、同一チームならそのコストはゼロです。それ以上に、 「どうログを出せば調査が楽か」「どのメトリクスが異常ならコードの不備か」 を開発段階から織り込めるため、結果としてシステムの信頼性が劇的に向上します。
今回は、以下のAWS構成を例に解説します。
2. 監視設計の思想：「何のために」を定義する
ユーザーの成功体験を監視する「外形監視」
「CPU使用率が80%を超えた」というリソース監視も大切ですが、それだけでは不十分です。CPUが正常でも、アプリがバグで真っ白な画面を返していれば、ユーザーにとっては「システムダウン」と同じだからです。
そこで重要なのが外形監視です。システムの外側からユーザーと同じようにリクエストを送り、「サービスが約束通りの体験を提供できているか」を監視します。
「オオカミ少年」を作らない通知の階層化
運用が始まると陥りがちなのが「通知の洪水」です。 「異常はすべてCritical、1回でも起きたら即通知！」という設計にすると、夜中に無害なアラートで叩き起こされ、次第に重要な通知も見逃すようになります。これを 「アラート疲れ」 と呼びます。
開発段階から「これは本当に今すぐ人間が動くべき事象か？」を自問自答し、通知を階層化することが運用の持続性を左右します。
3. 具体的プラクティス
CloudWatch Synthetics による外形監視
AWSでは CloudWatch Synthetics を活用します。「Canary（カナリア）」と呼ばれるスクリプトを作成し、24時間365日、一定間隔でURLを叩かせます。
チェック内容: ステータスコード 200 OK か？ 応答時間は許容範囲内か？
メリット: ユーザーからの問い合わせが来る前に、開発者が異常を検知できます。
SLA/SLOに基づいた通知設計
通知レベルを以下のように定義し、アラーム（CloudWatch Alarm）を設定します。
| レベル | 定義 | 基準の考え方 |
|---|---|---|
| Critical | サービス停止・壊滅的 | SLA/SLO（目標稼働率） を脅かす状態。即座にエンジニアの介入が必要 |
| Error | 一部機能不全 | SLAに達する前の予兆や、特定の機能のみの不具合。営業時間内の対応 |
| Warning | 想定外の挙動 | 異常ではないが、リクエスト急増など将来的にリスクがある状態 |
| Info | 正常な記録 | 処理時間やリソースの推移。分析時に利用する |
[ポイント] 1回の失敗で騒がない 「1回エラーが出たら通知」ではなく、 「5分間に3回以上失敗したら通知」 のように、統計的に意味のあるしきい値を設定します。このしきい値は「1%のエラーは許容できるか？（SLO）」という観点から算出します。
4. エラー解析を「職人芸」にしない仕組み
誰でも原因がわかるダッシュボード
障害時に「黒い画面でログを叩ける人しか原因がわからない」状態は危険です。 「まずここを見れば8割把握できる」という入り口を用意します。
CloudWatch Dashboard: 構築不要。ALBの5xxエラー数やDBの接続数を一画面にまとめます。
Grafana: DB内の「注文完了数」などのビジネス指標をSQLで可視化でき、システムとビジネス両面から状況を把握できます。
ポストモーテム（事後分析）という文化
インシデントが収束したら、必ずポストモーテムを実施します。 ここで最も大切なのは、 「非難禁止（Blameless）」 です。
「XXさんのミス」で終わらせず、「なぜ人間がミスをする仕組みになっていたのか？」を深掘りします。
操作手順書が複雑すぎたのではないか？
誤操作を防ぐ「ガードレール（バリデーション等）」をどこに設けるべきか？
これを繰り返すことで、チーム全体の運用スキルが「仕組み」として蓄積されていきます。
5. まとめ：運用は開発の一部である
新機能を設計するとき、常に自分に問いかけてみてください。 「この機能はどう監視する？」「どうなれば『壊れた』と定義できる？」「手動作業を減らせるか？」
リリースはゴールではなく、新しい価値をユーザーに届け続ける「運用」のスタート地点です。設計段階から運用を味方につけることで、リリース初日から自信を持ってサービスを世に送り出すことができるはずです。