コンテンツにスキップ

システム保守ガイド

概要

リツビ BtoB ECサイトのシステム保守・運用ガイドです。

この文書の役割

本書は、保守運用担当が日常的に参照する 運用 runbook です。契約条件、サポート窓口、料金体系は 保守・サポート計画書（窓口情報は未確定項目あり） を参照してください。

最初に確認すること

[!IMPORTANT] Storefront の公開停止や緊急メンテナンス切替が必要な場合は、まず Storefront メンテナンス運用 Runbook を開いてください。

役割分担の目安

作業 主担当 補助 / 連携先
日次・週次・月次の定期点検 運用担当者 システム管理者
Dashboard 上の設定変更 システム管理者 運用責任者
障害の一次切り分け 運用担当者 システム管理者
バックアップ検証 / restore drill システム管理者 運用担当者
保守窓口への正式連絡 システム管理者 / 運用責任者 運用担当者

定期保守作業の見方

以下のチェックリストは「何を確認するか」の一覧です。実際の運用では、各項目ごとに 確認先 / 結果 / 次アクション を記録してください。

項目例 主な確認先 異常時の次アクション
CPU / メモリ / ディスク / DB接続 監視システムのインフラ監視 閾値超過の継続有無を確認し、継続時は障害対応フローへ進む
エラーログ アプリケーションログ監視 同一エラーの継続発生と影響範囲を確認する
SMILE連携ログ Vendure Dashboard操作ガイド の SMILE連携履歴 失敗件数・対象データを確認し、再実行可否を判断する
バックアップ検証 バックアップとリストア restore drill の結果と所要時間を記録する

保守の基本方針

  1. 予防保守: 定期的な点検とメンテナンスによる障害予防
  2. 監視: 24時間365日のシステム監視
  3. 迅速な対応: 障害発生時の迅速な復旧対応
  4. 継続改善: 運用データに基づく継続的なシステム改善

定期保守作業

日次作業

システム監視

  • CPU使用率チェック
  • メモリ使用率チェック
  • ディスク使用量チェック
  • データベース接続状況チェック
  • エラーログ確認

データ確認

  • 注文データの整合性確認
  • SMILE連携ログの確認
  • 決済処理状況の確認

週次作業

パフォーマンス確認

  • レスポンス時間測定
  • スループット確認
  • データベース最適化
  • ログローテーション

セキュリティ確認

  • アクセスログ分析
  • 不正アクセス検知
  • セキュリティパッチ確認

月次作業

データベース保守

  • インデックス再構築
  • 統計情報更新
  • 古いデータのアーカイブ
  • バックアップ検証（RESTORE_DRILL_DRY_RUN=true just restore-drill all staging latest → just restore-drill all staging latest restore-drill-staging を実行し、所要時間と backup file を記録）

システム最適化

  • パフォーマンス分析
  • 容量計画見直し
  • 監視閾値調整

システム監視

監視項目

インフラ監視

  • CPU使用率（閾値: 80%）
  • メモリ使用率（閾値: 85%）
  • ディスク使用率（閾値: 85%）
  • ネットワーク帯域（閾値: 80%）

アプリケーション監視

  • レスポンス時間（閾値: 3秒）
  • エラー率（閾値: 1%）
  • 同時接続数（閾値: 1000）
  • データベース接続数（閾値: 100）

ビジネス監視

  • 注文処理件数
  • 決済成功率
  • SMILE連携成功率
  • ユーザーセッション数

アラート設定

緊急アラート（即座に対応）

  • システムダウン
  • データベース接続エラー
  • 決済処理エラー
  • セキュリティインシデント

警告アラート（1時間以内に対応）

  • パフォーマンス劣化
  • リソース使用率上昇
  • エラー率上昇

監視ツール

Vendure/Storefront監視

  • アプリケーションログ監視
  • パフォーマンスメトリクス
  • エラートラッキング

インフラ監視

  • サーバーリソース監視
  • ネットワーク監視
  • データベース監視

バックアップ・復旧

バックアップ方針

データベースバックアップ

  • 頻度: 毎時
  • 保存期間: 30日間（720時間）
  • 方式: R2 へのフル dump 保持

ファイルバックアップ

  • 頻度: 週次（日曜日）
  • 対象: アプリケーションファイル、設定ファイル
  • 保存期間: 12週間

設定バックアップ

  • 頻度: 変更時
  • 対象: システム設定、Vendure設定
  • 保存場所: Git リポジトリ

復旧手順

データベース復旧

  1. 障害状況の確認
  2. 最新バックアップの特定
  3. データベースの停止
  4. バックアップからの復元
  5. 整合性チェック
  6. サービス再開

[!NOTE] 定期的な restore drill は just restore-drill all staging latest restore-drill-staging を正本とします。事前 rehearsal は RESTORE_DRILL_DRY_RUN=true just restore-drill all staging latest を使い、actual 実行前に取得対象と上書き先を確認してください。

2026-04-10 の初回 actual では、Postgres 24 秒 / WordPress 31 秒で完了しました。 以後も同じ形式で所要時間と使用 backup file を月次記録してください。

アプリケーション復旧

  1. 障害原因の特定
  2. 前バージョンへのロールバック
  3. 設定の復元
  4. 動作確認
  5. サービス再開

セキュリティ保守

セキュリティパッチ適用

優先度高（即座に適用）

  • 脆弱性修正パッチ
  • セキュリティホール対応

優先度中（1週間以内）

  • 機能改善パッチ
  • パフォーマンス改善

ログ分析

アクセスログ分析

  • 不正アクセス検知
  • 攻撃パターン分析
  • 異常なトラフィック検知

セキュリティログ分析

  • ログイン試行回数
  • 権限昇格の検知
  • データアクセス監査

パフォーマンス最適化

定期最適化作業

データベース最適化

  • インデックス使用状況分析
  • スロークエリ分析
  • 統計情報の更新

アプリケーション最適化

  • キャッシュ効率の確認
  • メモリリーク検知
  • 不要なプロセスの削除

障害対応

障害対応フロー

  1. 検知: 監視システムからのアラート
  2. 分析: 障害の原因と影響範囲の特定
  3. 対応: 復旧作業の実施
  4. 確認: 復旧の確認と動作テスト
  5. 報告: 関係者への復旧報告

障害時に最初に記録すること

  • 発生日時
  • 検知経路（監視アラート / 利用者報告 / 定期点検）
  • 影響範囲
  • 暫定対応の有無
  • 保守窓口へ連絡した時刻

[!NOTE] 本書の レベル1〜3 は復旧対応のエスカレーション目安です。 保守・サポート計画書（窓口情報は未確定項目あり） の Critical / High / Medium / Low は、サポート窓口へ伝える障害 severity の分類として使い分けてください。

Storefront 緊急メンテナンス切替

  • Storefront のメンテナンス正本は Cloudflare KV にある。
  • Vendure 停止時でも Cloudflare KV を直接更新して Storefront を停止できる。
  • 手順は Storefront メンテナンス運用 Runbook を参照する。

WordPress 編集が Storefront に反映されない

  • 通常は WordPress の保存と同時に ritsubi-ec-plugin の hook が Storefront /api/revalidate/cms を非同期に叩き、メニュー・お知らせ・ ストア設定が即時反映される。
  • 反映されない場合の切り分け順:
  • WordPress 管理画面で対象を 公開状態に保ったまま もう一度「更新」する （draft → draft の保存では webhook が発火しない）。
  • WordPress コンテナの error log に [ritsubi] storefront revalidate failed が出ていないか確認する。 出ている場合は STOREFRONT_REVALIDATE_URL / CMS_REVALIDATE_SECRET の 設定を疑い、Secrets Manager の b2b-ecommerce/{env}/shared を確認する。
  • Storefront 側 Sentry / Cloudflare Workers ログで POST /api/revalidate/cms の到達を確認する。

  • 緊急対応として手動で revalidate を叩くこともできる:

    curl -X POST https://<storefront-host>/api/revalidate/cms \
  -H 'content-type: application/json' \
  -H "x-cms-revalidate-secret: <secret>" \
  -d '{"event":"all"}'

  • event は menu.updated / announcement.updated / campaign.updated / page.updated / settings.updated / all のいずれか。

  • 仕様の正本: WordPress CMS統合ガイド「即時反映 (WP-to-Storefront Webhook)」。

エスカレーション基準

  • レベル1: 1時間以内に自動復旧
  • レベル2: 4時間以内に手動復旧要
  • レベル3: 8時間以上の復旧時間が予想

保守作業記録

記録項目

  • 作業日時
  • 作業者
  • 作業内容
  • 作業結果
  • 問題・改善点

保守レポート

  • 月次保守レポート
  • 四半期システム分析レポート
  • 年次保守計画レビュー

関連資料