監視・障害対応・保守

第29講 / 全32講読了目安約65分

このページで学ぶこと

運用、監視、保守、サポート、障害対応の違い
利用者視点とシステム視点の監視、SLI・SLO・SLA
ログ、メトリクス、トレース、アラートの役割
インシデントの検知、指揮、復旧、連絡、事後検証
バックアップ、アップデート、権限、外部サービスを含む保守範囲と費用

まず全体像

Webサイトは公開した時点で完成ではありません。

利用者・コンテンツ・アクセス・ブラウザ・外部サービス・セキュリティ状況が変化するため、観測し、問題へ対応し、更新し続ける必要があります。

flowchart LR
    R[公開] --> M[監視・問い合わせ]
    M --> D{問題・変化}
    D -->|障害| I[切り分け・復旧]
    D -->|更新必要| U[保守・改善]
    I --> P[事後検証]
    U --> R
    P --> U

運用を「問い合わせが来たら直すこと」だけにすると、検知が利用者任せになり、影響・原因・復旧目標を管理できません。

用語を分ける

運用

日常的にサービスを利用・維持する活動です。

コンテンツ更新
アカウント管理
公開作業
問い合わせ
定期確認
障害対応
レポート
改善

保守

正常な状態を維持し、環境変化へ追従する技術的な活動です。

CMS・ライブラリ更新
OS・ランタイム更新
証明書・ドメイン
バックアップ
設定変更
不具合修正
外部API変更
セキュリティ対応

監視

状態を継続的に観測し、異常・傾向・目標との差を把握する活動です。

サポート

利用者・運用担当からの質問や問題を受け付け、案内・調査・対応する活動です。

インシデント対応

サービスへ重大な影響を与える出来事を検知し、影響を抑え、復旧する活動です。

契約では、これらを「保守一式」とまとめず、対象・時間・担当・費用を明記します。

何を監視するか

監視は、サーバーが動いているかだけでは不十分です。

flowchart TD
    U[利用者視点] --> A[ページ・主要フロー]
    S[サービス視点] --> B[API・ビルド・外部連携]
    I[基盤視点] --> C[CPU・容量・ネットワーク]
    BIZ[業務視点] --> D[予約・送信・公開件数]
    SEC[安全視点] --> E[ログイン・WAF・権限]

利用者視点

トップ・主要ページを開ける
検索できる
ログインできる
フォームを送信できる
予約・購入できる
表示が十分速い
正しい内容が表示される

システム視点

HTTPステータス
API成功率
応答時間
ビルド・Webhook
キュー
DB接続
メール送信
キャッシュ
外部サービス

基盤視点

CPU
メモリ
ストレージ
接続数
データ転送
証明書期限
ドメイン期限
料金・クォータ

業務視点

技術上は成功でも、業務上異常なことがあります。

問い合わせが突然0件
予約完了だけ急減
CMS公開件数とサイト表示件数が不一致
決済成功と注文登録が不一致
検索結果が0件ばかり
メール送信成功だが担当者へ届かない

事業KPI・業務件数も監視対象にします。

ブラックボックスとホワイトボックス

ブラックボックス監視

利用者のように外部からサービスを確認します。

URLへアクセス
フォーム操作
DNS・HTTPS
応答時間
表示内容

システム内部が正常と報告していても、利用者から使えない問題を検知できます。

ホワイトボックス監視

内部のメトリクス・ログ・状態を確認します。

エラー率
CPU・メモリ
DB
キュー
API
キャッシュ
ビルド

原因・予兆を詳しく調べやすくなります。

両方を組み合わせます。

メトリクス・ログ・トレース

メトリクス

時間ごとの数値です。

応答時間
リクエスト数
エラー率
CPU
成功件数

傾向・閾値・比較に向きます。

ログ

個々の出来事の記録です。

エラー
API呼び出し
ログイン
公開
デプロイ
設定変更

詳細調査に向きます。

トレース

一つのリクエストが複数サービスを通る流れを追跡します。

sequenceDiagram
    participant W as Web
    participant A as API
    participant D as DB
    participant E as 外部サービス

    W->>A: trace-id付き要求
    A->>D: 同じ処理を追跡
    A->>E: 外部連携
    D-->>A: 結果
    E-->>A: 結果
    A-->>W: 応答

マイクロサービス・外部APIが多い構成では、どこで遅延・失敗したか調べる助けになります。

四つのゴールデンシグナル

Google SRE Bookでは、利用者向けシステムの主要な監視として、次の四つを挙げています。

シグナル	意味	Web制作の例
Latency	応答にかかる時間	ページ・API・検索の所要時間
Traffic	利用量	PV、リクエスト、送信件数
Errors	失敗	5xx、API失敗、フォーム失敗
Saturation	容量への近さ	CPU、接続数、クォータ、ビルド待ち

これだけで業務・セキュリティ・コンテンツのすべてを監視できるわけではありません。

基本として使い、サイトの目的に合う指標を追加します。

SLI・SLO・SLA

SLI

Service Level Indicator。サービス品質を測る指標です。

例：

正常に完了したフォーム送信の割合
2秒以内に応答したAPIの割合
利用可能だった時間の割合

SLO

Service Level Objective。SLIについて目標とする水準です。

例：

月間99.9%のリクエストが成功
検索APIの95%が2秒以内
予約完了フローの成功率99.5%

SLA

Service Level Agreement。提供者と利用者間の契約上の約束で、対象、測定、除外、補償等を含む場合があります。

flowchart LR
    M[実測するSLI] --> O[目標SLO]
    O --> A[契約・約束SLA]

SLOを決めず「できるだけ止めない」とすると、監視・冗長化・当番体制・費用を決められません。

SLAはSLOと同じ数値・意味とは限りません。

可用性の数値を過信しない

月間99.9%の可用性でも、停止時間がどの時間帯・機能に発生したかで影響は異なります。

決算発表時
チケット販売開始
TV放映後
締切直前
社内営業時間外

また、トップページは開けても予約ができなければ、事業上は利用不能です。

重要な利用者フローを対象にします。

アラート

アラートは、担当者の行動が必要な状態を通知するものです。

良いアラート

利用者・SLOへ影響する
担当者が行動できる
緊急度が分かる
対象・状況・確認先がある
重複を抑える
解消が分かる
手順書へつながる

悪いアラート

CPUが少し高いだけで毎回通知
同じ障害で数百件通知
対応方法がない
夜中に起こす必要がない
通知先が退職者
復旧後も鳴り続ける

flowchart TD
    E[異常・目標逸脱] --> A{人が今行動すべきか}
    A -->|はい| P[ページ・電話等の緊急通知]
    A -->|営業時間内でよい| T[チケット・チャット]
    A -->|傾向把握| D[ダッシュボード・レポート]

アラート疲れが起きると、本当に重要な通知を見落とします。

定期的に有効性を見直します。

合成監視と実利用者監視

合成監視

定期的に決めた操作を自動実行します。

ページ表示
ログイン
検索
フォームのテスト送信

利用者が少ない時間でも問題を検知できます。

テストデータ、実送信、Bot対策、外部課金に注意します。

RUM

Real User Monitoring。実際の利用者のブラウザで、性能・エラー等を測定します。

端末・通信・地域の実態を把握できます。

プライバシー、同意、サンプリング、個人情報を確認します。

ラボ測定・合成監視・RUMを目的で使い分けます。

ログ設計

ログは後から増やせない情報があります。

障害前に何を記録するか決めます。

必要な要素

時刻・タイムゾーン
環境
サービス
リクエスト・処理ID
結果
エラー分類
対象の匿名化された識別子
デプロイ版
外部API
処理時間

記録しない・保護するもの

パスワード
APIシークレット
カード情報
不要な個人情報
フォーム本文全文
認証トークン

ログ閲覧権限、保存期間、削除、改ざん防止、費用を管理します。

大量ログで料金・検索性能が問題になることもあります。

ダッシュボード

ダッシュボードは、状態を理解・判断するために作ります。

役割別

経営・事業：利用・コンバージョン・重大障害
PM・運用：主要フロー、エラー、外部連携
エンジニア：サービス・基盤の詳細
セキュリティ：認証、WAF、権限、異常

すべてのグラフを一画面に並べると、判断できません。

平常値・目標・期間比較・リリース時点を分かるようにします。

インシデントのライフサイクル

flowchart LR
    D[検知] --> A[影響評価・宣言]
    A --> C[指揮・役割分担]
    C --> M[緩和・封じ込め]
    M --> R[復旧]
    R --> V[確認・監視]
    V --> P[事後検証・改善]

検知

監視、問い合わせ、SNS、クライアント、外部事業者等から発見します。

影響評価

何が使えないか
誰に影響するか
いつからか
データ影響
拡大中か
セキュリティ事故か

を整理します。

緩和

根本原因の解決より先に、影響を小さくすることがあります。

機能停止
旧版へ戻す
外部連携を切る
キャッシュ表示
メンテナンス表示
アクセス制限
キー失効

復旧・確認

表示だけでなく、滞留処理、二重送信、データ整合、監視、利用者案内を確認します。

インシデントの役割

重大障害では、一人が調査・判断・連絡をすべて行うと混乱します。

役割	主な責任
Incident Commander	全体判断、優先順位、役割分担
技術対応	調査、緩和、復旧
連絡担当	クライアント・利用者・社内への更新
記録担当	時系列、判断、操作、結果
専門担当	API、インフラ、セキュリティ、業務等

小規模体制では兼任しますが、誰が最終判断するかは明確にします。

チャット、会議、電話が分散すると情報が食い違うため、指揮・記録の場所を決めます。

重大度

障害を影響に応じて分類します。

例：

重大度	影響	対応例
Sev1	全体停止、漏えい、重大な金銭・安全影響	即時招集、経営・広報・法務連携
Sev2	主要機能停止、多数利用者	緊急対応、定期報告
Sev3	一部機能、回避策あり	営業時間内の優先対応
Sev4	軽微、改善	通常バックログ

名称・基準は組織ごとに決めます。

技術エラーの種類ではなく、利用者・業務・データへの影響で判定します。

障害コミュニケーション

「調査中です」だけでなく、分かっている事実と次回更新を伝えます。

内部・クライアント向け

発生・検知時刻
影響
現在の状態
実施した対応
次の確認
暫定回避
次回報告時刻
確定・推測の区別

利用者向け

利用できない機能
代替手段
データ・申込への影響
復旧状況
必要な再操作
問い合わせ

原因が確定する前に断定しません。

情報がない時間でも、次回更新予定を伝えると関係者の混乱を減らせます。

切り分け

障害時は、変更・範囲・時刻を手掛かりにします。

flowchart TD
    A[何が失敗しているか] --> B{全利用者か}
    B -->|一部| C[端末・地域・権限・データ]
    B -->|全体| D{直前の変更があるか}
    D -->|あり| E[デプロイ・設定・CMS・DNS]
    D -->|なし| F[外部サービス・基盤・証明書]
    C --> G[ログ・メトリクス・再現]
    E --> G
    F --> G

確認例：

いつから
どのURL・機能
どの利用者
直前のデプロイ
CMS公開
DNS・証明書
API・外部サービス
WAF・レート制限
データ
ブラウザ
ログ・メトリクス

原因究明より先に影響を抑える判断も必要です。

Runbook

Runbookは、定型的な確認・対応手順です。

アラートの意味
影響確認
ダッシュボード
ログ検索
連絡先
再起動・再実行
キャッシュ削除
キー失効
切戻し
エスカレーション
禁止事項

手順は実際に使い、古い画面・権限・URLを更新します。

Runbookがあっても、想定外の判断を完全には置き換えません。

バックアップと復元

バックアップは、取得しているだけでは不十分です。

RPO

Recovery Point Objective。どの時点までのデータ損失を許容するか。

例：最大24時間分、最大5分分。

RTO

Recovery Time Objective。どの程度の時間で復旧するか。

例：4時間以内、翌営業日。

flowchart LR
    A[最後の正常バックアップ] -->|失われ得る期間 RPO| I[障害]
    I -->|復旧に必要な時間 RTO| R[サービス復旧]

確認対象

CMSコンテンツ
データベース
画像・PDF
ソース
設定
DNS
シークレット
検索インデックス
外部サービス
監査ログ

復元試験

誰が実施できるか
何分かかるか
どこへ復元するか
データ整合
権限
利用者への影響

を実際に確認します。

サービス事業者のバックアップ仕様が、自社のRPO・RTOを満たすとは限りません。

アップデート・パッチ

公開後には次が更新されます。

CMS
プラグイン
Node.js・PHP等
フレームワーク
npm等の依存物
OS・DB
GitHub Actions
ブラウザ
API
証明書
外部タグ

更新フロー

更新情報・脆弱性を把握
影響を評価
検証環境で更新
自動・手動テスト
本番公開
監視
記録

重大な脆弱性は通常更新を待たず緊急対応する場合があります。

更新を永遠に延期すると、複数バージョンを一度に上げる大規模改修になります。

Renovate・Dependabot

依存パッケージの更新Pull Requestを自動作成するツールです。

利点

更新を早く把握
小さな差分で継続更新
脆弱性・保守終了へ追従
変更履歴を残す

注意点

自動マージの条件
テスト不足
大量通知
互換性
メジャー更新
ロックファイル
間接依存
担当不在

「自動でPRが作られる」ことと「安全に更新される」ことは別です。

レビュー・CI・定期作業時間を用意します。

証明書・ドメイン・契約期限

自動更新されるものでも、次を監視します。

ドメイン
HTTPS証明書
SaaS契約
クレジットカード
APIトークン
Apple・Google等の証明書
外部サービスのプラン
サポート契約

担当者個人のメール・カードに依存しないようにします。

期限通知、更新権限、請求先、退職時引継ぎを管理します。

容量・クォータ・費用監視

サービス停止は技術障害だけでなく、上限超過・支払失敗でも起こります。

API呼び出し
CMS件数
ストレージ
データ転送
ビルド時間
ログ
メール
検索レコード
利用者数
予算

通常値・増加率・上限を監視し、余裕を持って対応します。

従量課金では、攻撃・ループ・設定ミスによる費用急増も検知します。

外部サービス障害

サービス事業者が復旧するまで、自社で根本修正できない場合があります。

それでも次は設計できます。

ステータスページ確認
キャッシュ・旧データ
機能停止
タイムアウト
代替手段
利用者案内
再試行
復旧後の整合
契約・SLA
複数事業者への分散

すべてを冗長化すると費用・複雑性が増えます。

事業影響に応じて判断します。

夜間・休日対応

24時間公開のWebサイトでも、24時間有人対応が必須とは限りません。

決めること

受付時間
自動監視
緊急通知の対象
オンコール担当
交代・休息
対応開始目標
エスカレーション
連絡費用
対象外
翌営業日対応
サービス自動停止

夜間に通知するなら、担当者が実際に行動できる権限・手順・支援を用意します。

通知だけして「気づいた人が対応」では継続できません。

ポストモーテム

重大な障害後に、時系列、影響、原因、対応、学び、再発防止を記録します。

含める内容

概要
利用者・業務影響
検知・復旧時間
時系列
技術的・組織的要因
良かった点
改善点
再発防止
担当・期限
類似箇所
残存リスク

個人を責めるためではなく、当時の情報・仕組みでなぜ起きたかを学びます。

「担当者が注意する」で終わらせず、設計、テスト、監視、権限、手順を改善します。

保守範囲と見積

保守費用は、サーバー代だけではありません。

定常作業

監視
月次確認
アップデート
バックアップ
権限棚卸し
ログ・容量
証明書・契約
レポート
問い合わせ

障害対応

受付
一次切り分け
復旧
外部問い合わせ
緊急公開
報告
ポストモーテム

改修との境界

不具合修正
環境変化対応
文言・デザイン変更
新機能
API仕様変更
CMSモデル変更

「保守に含む」「別見積」を具体例で明記します。

見積方法

月額固定
時間枠
都度見積
監視基本料＋対応従量
24時間オンコール
SLAプラン

対象・対応時間・上限・未使用時間・緊急加算を合意します。

実案件ではどう考えるか

静的コーポレートサイト

サーバー処理が少なくても、

DNS・CDN
CMS
Git・CI/CD
外部フォーム
ライブラリ
証明書
ビルド
アクセシビリティ・リンク
SEO・計測

の監視・更新が必要です。

予約・会員サービス

SLO
主要フローの合成監視
API・DB・決済
オンコール
インシデント指揮
データ整合
RPO・RTO
負荷・容量

を高い優先度で設計します。

CMSの公開障害

CMS自体は正常でも、Webhook・ビルド・CDN・検索が失敗することがあります。

CMS公開件数とWeb表示を照合する業務監視が有効です。

PMチェックリスト

よくある誤解・失敗

「サーバーが200を返しているので正常」

主要機能、正しいデータ、外部連携、業務件数が失敗している場合があります。利用者フローを監視します。

「監視ツールを導入すれば障害対応できる」

通知を受けて判断・操作する担当、権限、Runbook、連絡体制が必要です。

「バックアップがあるので復旧できる」

対象・保持期間・復元手順・所要時間・整合性を試験していなければ、要件を満たすか分かりません。

「自動アップデートなら保守担当は不要」

互換性、不具合、テスト、公開判断が必要です。自動化は担当者の作業を置き換えるのではなく支援します。

「障害原因が担当者のミスなら注意すれば再発しない」

権限、レビュー、確認、UI、手順、監視等、ミスが重大事故にならない仕組みを改善します。

理解度チェック

Q1. SLI、SLO、SLAの違いは何ですか。

回答と解説

SLIは実測する品質指標、SLOはその目標水準、SLAは提供者と利用者の契約上の約束です。対象・計算・除外が異なる場合があります。

Q2. 四つのゴールデンシグナルを挙げてください。

回答と解説

Latency（遅延）、Traffic（トラフィック）、Errors（エラー）、Saturation（飽和・容量への近さ）です。

Q3. 良いアラートの条件は何ですか。

回答と解説

利用者・SLOへ影響し、担当者が今行動でき、緊急度・対象・確認先・手順が分かり、重複が抑えられていることです。

Q4. RPOとRTOの違いは何ですか。

回答と解説

RPOはどの時点までのデータ損失を許容するか、RTOは障害からどの程度の時間で復旧するかの目標です。

Q5. ポストモーテムの目的は何ですか。

回答と解説

個人を責めることではなく、影響、時系列、複数の要因、対応を理解し、再発可能性・影響を下げる具体的な改善を実施することです。

参考資料

サイバーエージェント「2024年度新卒研修システム運用の基本と戦略」
https://speakerdeck.com/mokopoi/2024nian-du-saibaeziento-xin-zu-yan-xiu-sisutemuyun-yong-noji-ben-tozhan-lue
運用、監視、障害対応等を体系的に学ぶ参考資料。
Google SRE Book「Monitoring Distributed Systems」
https://sre.google/sre-book/monitoring-distributed-systems/
四つのゴールデンシグナル等、利用者向けサービスの監視を考える一次資料。
Google SRE Book「Managing Incidents」
https://sre.google/sre-book/managing-incidents/
インシデントの指揮・役割分担・連絡の考え方。
Google SRE Book「Postmortem Culture」
https://sre.google/sre-book/postmortem-culture/
非難ではなく学習と再発防止を重視する事後検証の考え方。