納品後の保守・運用で何が必要か

システムは納品された瞬間がゴールではなく、そこから業務を支える道具として使い続ける段階が始まります。ところが「作るまで」に比べて「動かし続ける」ための準備は後回しにされがちで、停止やデータ消失、脆弱性の放置といった問題の多くは、動かし続けるための設計が抜けていたことに原因があります。この記事では、納品後に必要になる基本として、監視、バックアップと復元テスト、アップデート、本番適用前の検証、契約の範囲を順に整理します。

保守と運用は何をすることか

保守は、システムを正常に動かし続けるための技術的な作業を指します。運用は、日々の業務の中でシステムを使い、管理する活動です。両者は重なる部分もありますが、分けて考えると必要な作業が見えやすくなります。

保守を怠ると、ある日突然システムが止まる、情報漏えいが起きる、といった形で問題が表面化し、復旧にも時間がかかります。保守は「何も起きていないときにこそ行う作業」だと考えてください。保守費が発生する理由は、費用の決まり方の記事でも触れています。

監視：異常に早く気づく仕組み

監視とは、システムが正常に動いているかを自動的に確認し、異常があれば通知する仕組みです。「利用者から連絡が来て初めて止まっていることを知った」という事態を避けるために必要です。

監視の対象は、大きく次の3つに分けられます。

• 死活監視：サーバーやサイトが応答しているか
• リソース監視：CPU、メモリ、ディスク容量に余裕があるか
• ログ監視：エラーや不正アクセスの兆候が記録されていないか

想定例：ディスク容量の監視を入れていなかったため、ログファイルが増え続けてディスクがいっぱいになり、データベースへの書き込みが失敗して受注が登録できなくなった、というケースが考えられます。容量の監視があれば、業務に影響が出る前に対処できます。

監視で重要なのは「誰に通知が届き、誰が対応するか」を決めておくことです。SSL/TLS証明書の有効期限も監視の対象に含めておくと、期限切れによる警告表示を防げます。

バックアップと復元テスト

バックアップは「取ること」より「戻せること」が目的です。取得しているだけで一度も復元を試していないバックアップは、いざというときに使えない可能性があります。

バックアップの設計で決めておきたい項目は次のとおりです。

• 対象：データベース、アップロードされたファイル、設定ファイル、プログラム本体
• 頻度：業務のデータ更新頻度に応じて決める
• 保管場所：本番サーバーとは別の場所に保管する
• 世代数：どこまで遡って戻せるようにするか
• 復元手順：誰が、どの手順で戻すかを文書にしておく

そして、定期的に復元テストを行います。復元テストでは、バックアップからデータを別環境に戻し、実際に画面から確認できるかを確かめます。

想定例：バックアップは定期的に取得していたものの、保管先が本番と同じサーバーだったため、サーバー障害で本番データとバックアップの両方が失われた、というケースは典型的です。保管場所を分けることと、復元テストを行うことは、バックアップの基本として必ず押さえてください。

OS・ミドルウェア・CMS のアップデート

システムは、OS、Web サーバー、データベース、プログラミング言語といった複数のソフトウェアの上で動いています。LAMP/LEMP構成であれば、Linux、Web サーバー、MySQL、PHP のそれぞれに更新が提供されます。これらには定期的にセキュリティ修正が公開され、放置すると既知の脆弱性を突かれる危険があります。

アップデートの対象と注意点を整理します。

とくに CMS のプラグインは脆弱性を狙われやすく、更新を止めているサイトほど危険です。一方で、更新すると既存の機能が動かなくなることもあるため、「更新しない」でも「無条件に更新する」でもなく、「検証してから更新する」という運用が必要です。

ステージング環境での検証

アップデートや改修を本番環境にいきなり適用すると、問題が起きたときに業務が止まります。そこで、本番と同じ構成のステージング環境を用意し、そこで先に検証します。

ステージング環境での検証の流れは次のとおりです。

1. 本番環境の構成とデータ（必要に応じて匿名化したもの）をステージングに複製する
2. アップデートや改修をステージングに適用する
3. 主要な業務の流れを画面から確認する（ログイン、登録、検索、出力など）
4. 問題がなければ、本番への適用日時と手順、失敗時の戻し方を決める
5. 本番に適用し、同じ確認を行う

想定例：CMS のプラグインを本番で直接更新したところ、問い合わせフォームが送信できなくなり、気づくまでの間に問い合わせを取りこぼした、というケースが考えられます。ステージングで確認していれば、事前に不具合を発見し、代替のプラグインを検討できます。

ステージング環境の維持には費用がかかりますが、本番障害による業務停止と比べれば、備えとして合理的な投資です。

保守契約の範囲を決める

保守契約では、「何を、どこまで、誰が」行うかを明確にします。範囲が曖昧だと、障害が起きたときに「それは契約外」という話になり、対応が遅れます。確認したい項目は次のとおりです。

• 監視の範囲：何を監視し、通知先はどこか
• 障害対応：受付時間帯、対応開始までの目安、対応の範囲（調査のみか復旧までか）
• アップデート：対象範囲、検証の有無、適用の判断は誰がするか
• バックアップ：取得の頻度、保管場所、復元テストの有無
• 改修：軽微な修正の範囲と、有償になる基準
• 契約形態：月額の準委任契約が一般的で、作業内容の記録と報告が重要になる

保守契約に含まれない作業は、都度見積になります。「含まれていると思っていた」というずれを防ぐため、契約前に一項目ずつ確認してください。システムサポートのような保守サービスを検討する際も、上記の項目を基準にすると比較しやすくなります。

気づく・戻せる・塞ぐ、そして誰がやるか

納品後の保守・運用では、監視で異常に早く気づき、バックアップと復元テストで万一に備え、アップデートで脆弱性を防ぎ、ステージングで検証してから本番に適用する、という流れが基本です。そして、これらを「誰が行うか」を保守契約で明確にしておくことが欠かせません。保守・運用の体制に不安がある場合は、お問い合わせからご相談ください。