Webアプリ公開後は誰が面倒を見る？保守費と運用の決め方

画面は開くのに、申込みに気づけない

説明用の例として、研修申込みのアプリで、データは保存されるのに担当者への通知メールだけ止まった場面を考えます。利用者は申込みを終えたつもりですが、担当者は申込みがないと思っています。トップページが開くかだけを見ていても、この問題は見つかりません。

運用で最初に決めるのは、止まると困る仕事です。受付できない、資料を見られない、通知だけ届かないでは、代わりの手順が違います。通知の問題なら受付一覧を確認して対応を続けられるかもしれません。すべてを同じ障害として扱わず、事業への影響に応じて連絡と対処を考えます。

停止の影響は、使う時間帯でも変わります。研修の例では、申込締切の直前と募集のない日では、同じ通知障害でも対応の急ぎ方が違うかもしれません。重要な日程を技術担当と共有し、更新を避けたい時期や、確認の頻度を上げたい場面を話します。止まった処理だけを見て一律の緊急度を決めるより、次に誰の仕事が止まるかを考えると、限られた体制でも優先順位を付けやすくなります。

監視の通知は、受け取った後の行動まで決める

GoogleのSRE資料は、遅延、処理量、エラー、資源の逼迫を監視の基本的な観点として挙げています。アプリでは、これらを主要な操作に結び付けます。申込みの保存が失敗している、通知待ちがたまっている、特定の企業だけ遅い、と分かれば、調べる場所を絞れます。

通知が来ても誰も対応できなければ、問題に気づく仕組みだけが残ります。担当者、対応時間、連絡がつかない場合の行き先を決め、通知ごとに最初の確認を用意します。終日使えるサービスと、終日人が対応する契約は別です。時間外に止まったときの案内も、実際に守れる体制に合わせます。

監視のために定期的な申込みを送る場合は、それが本物の申込みや請求に混ざらない設計が必要です。検証用の利用者や対象を用意し、どこまでの処理を通して確認するかを決めます。通知の数を増やすだけでなく、実際に届いて担当者が気づけるかも試しておきます。繰り返す警告に慣れて重要な問題を見落とさないよう、すぐ対応する通知と、後で確認する記録を分けると日常の負担を調整できます。

参考：Google：Monitoring Distributed Systems

技術担当へ任せる仕事と、事業側が決めること

開発会社が復旧操作を担当しても、受付を止めるか、利用者へ何を伝えるかは事業側の判断が必要です。データを前の状態へ戻すなら、失われる更新を確認してから進めます。「保守一式」のままにせず、判断する人と操作する人を組にすると、障害時の相談先が分かりやすくなります。

クラウドの契約や支払いも運用の一部です。容量不足を解消するために契約変更が必要でも、承認できる人が不在なら対処が止まります。管理権限、請求先、契約更新の通知先を共有し、担当交代でも引き継げる状態を保ちます。手順書があることに加え、必要な権限で実行できることが大切です。

表が収まらない場合は横にスクロールできます。

「バックアップあり」で、どこまで戻せるか

昨日のバックアップがあっても、今日受けた申込みや添付資料まで戻せるとは限りません。どこまでの更新を失ってよいかという目標がRPO、業務再開までの目標時間がRTOです。用語より先に、「止まったとき、どの記録が残っていれば仕事を再開できるか」を話すと、必要な方式を選びやすくなります。

PostgreSQLの時点復旧は、基になるバックアップと連続した変更記録の保存を前提とします。こうした機能を使っていても、添付ファイルや外部サービスの状態は別に確認が必要です。別環境で復元し、重要な情報と操作を確かめ、かかった時間を測ります。保存が成功した記録だけでは、業務まで戻せることの確認にはなりません。

復旧訓練では、情報が表示されるだけで終わらせず、利用者が次の処理へ進めるかを確かめます。申込データは戻っても添付資料がない、すでに送った案内をもう一度送ってしまう、といった状態では仕事は元に戻りません。対象の受付番号、ファイル、外部通知の状態を照合して、再開する条件を決めます。別の担当者が手順をたどってみると、口頭でしか伝わっていない設定や権限不足も見つけられます。

参考：PostgreSQL Global Development Group：PostgreSQL Documentation: Continuous Archiving and Point-in-Time Recovery

前の版に戻せば直る、とは限らない

機能を更新した直後に問題が出たら、前の版へ戻したくなります。しかし、データ項目を削除したり意味を変えたりすると、以前のプログラムが新しいデータを扱えない場合があります。更新ごとに、戻せる範囲、公開中の入力の扱い、戻す判断をする人を確認しておきます。

通知障害の説明用の例でも、プログラムを直すだけでは未送信の仕事が残ります。手動対応済みの申込みと未対応を照合し、再送による混乱を避けます。復旧後は、原因だけでなく、発見や連絡が遅れた理由も振り返ります。次に必要なのは、監視の追加かもしれませんし、担当者が一覧を開く権限の整備かもしれません。

月額の数字より、含まれる仕事を比べる

保守には不具合対応のほか、ソフトウェアの更新、外部API変更への対応、復元の確認、利用量の確認などがあります。新機能の追加にすべての作業枠を使うと、維持の仕事が後回しになります。対応時間、含む作業、追加見積もりになる条件を比べ、緊急時の応答と復旧の目標を区別して確認しましょう。

ダンドリの保守・継続開発は月5万円〜で、当社が開発・納品したシステムを対象としています。他社システムの保守のみはお受けしていません。この開始価格だけで常時対応や無制限の改修を約束するものではなく、必要な内容を個別に相談します。サーバーなどの外部利用料も別に見込み、利用が増えたら何の費用が変わるかを把握しておくと予算を組みやすくなります。

利用が増えた後の費用は、ユーザー数だけでは説明できない場合があります。ファイルの保存量、メールの送信量、集計の実行回数など、自社の使い方で増えるものを把握します。定期的に利用量と請求を見て、不要な保存や処理を見直せる担当を置きましょう。保守の相談でも、新機能の要望だけでなく、問い合わせの傾向や運営が手で補っている作業を共有すると、限られた作業枠の中で改善する順番を決めやすくなります。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □止まると困る操作と、代わりの手順が分かる。確認状況・メモ：
• □通知先・対応時間・不在時の連絡先を決めた。確認状況・メモ：
• □技術的な操作と、受付停止・告知の判断を分けた。確認状況・メモ：
• □戻せるデータと、復元に必要な時間を確かめる。確認状況・メモ：
• □更新で問題が出たときの戻し方がある。確認状況・メモ：
• □保守に含む仕事と、別途費用になる作業を確認した。確認状況・メモ：
• □契約・支払い・管理権限を引き継げる。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Monitoring Distributed SystemsGoogle
• PostgreSQL Documentation: Continuous Archiving and Point-in-Time RecoveryPostgreSQL Global Development Group