公開後も、誰かがアプリケーションとそのデータ、使っているサービスの面倒を見る必要があります。どんな作業が必要かは、人々が何に頼っているかで変わります。情報発信のためのサイトと、お客様の注文を受けるアプリケーションでは、必要なチェックも復旧計画も異なります。
保守を依頼する前に、何に気を配る必要があるか、それぞれの責任者は誰か、どんな形で報告を受けるかを決めておきましょう。ここでは、私が一緒に確認していく質問を紹介します。
ホスティング、保守、新規開発を分けて考える
ホスティングは、ソフトウェアを動かすためのインフラを提供します。サービスによっては、セキュリティや証明書、バックアップの一部も管理してくれます。ただし、それは決済やログイン、通知がきちんと動いているかを誰かが確認している、という意味ではありません。
保守は、今のプロダクトを動かし続けるために合意した作業です。新規開発は、プロダクトのできることを変えます。保守契約に両方の時間を含めることもできますが、デザインの刷新や新しい決済フロー、大がかりな連携には、それぞれ独自の範囲設定が必要です。作業を始める前に、その線引きを書面にしておきましょう。
最初の引き渡し後にどんなサポートが含まれるのか、期間はどれくらいで、何が対象なのかも確認してください。サポートの範囲がわかっていると、その後の作業を計画しやすくなります。
依存関係をサポート期間内に保ち、アップデートを確認する
アプリケーションは、時間とともに変化するライブラリやフレームワーク、外部サービスに依存しています。セキュリティ修正やサポート終了の時期には注意が必要です。アップデートは、自分たちのアプリケーションへの影響を評価し、重要な操作の流れで確認してから本番に反映するべきです。
どのくらいの頻度で行うかは、リスクとプロダクトによって決まります。影響のある緊急のセキュリティ問題は、毎月の定期アップデートを待つべきではありません。こうした問題をどう報告し、どう対応するか、契約の範囲外の作業も含めて決めておきましょう。
何がバックアップされ、どう復元するかを把握する
リポジトリにあるコードは、復旧に必要なものの一部にすぎません。プロダクトは、顧客データ、アップロードされたファイル、各サービスの設定にも依存しています。何をバックアップしているか、頻度、保存期間、そして誰が復元できるのかを確認してください。
バックアップの頻度は、どれだけのデータなら失っても許容できるかで決めます。たとえば、最後に成功したバックアップが午前0時で、データベースが17時に故障した場合、そのバックアップを戻すだけではその日の変更が失われます。注文を受けるプロダクトと、週に一度しか内容が変わらないサイトとでは、適した復旧方法が違うでしょう。
それとは別に、復元のあいだプロダクトがどれくらい止まっていてよいかも決めておきましょう。どれだけのデータを取り戻せるかと、取り戻すのにどれだけ時間がかかるかは、別の問題です。
バックアップ成功の通知だけでは、アプリケーションを復元できる証明にはなりません。適切な別環境で復元を試し、手順を記録してください。NCSC のバックアップに関するガイダンスでも、重要なデータがバックアップに含まれているか、復元の方法を把握しているかを確認するよう勧めています。
お客様が必要とするものを監視する
死活監視で確認できるのは、ページが応答しているかどうかです。メールが届いていない、バックグラウンド処理が止まっている、お客様が購入を完了できない、といった問題まではわからないことがあります。プロダクトにとって重要なチェックは何か、障害の通知をどこに送るかを決めましょう。
アプリケーションと重要なサービスの稼働状況。
ログイン、決済、予約など、重要な操作の流れでのエラー。
失敗したバックグラウンド処理、通知、外部サービスとの連携。
ドメインの更新、証明書の状態、ストレージの上限、各サービスの利用量。
どのアラートにも、受け取る人と、合意した対応方法が必要です。誰がどの時間帯に対応するのか、緊急の問題をどう連絡するのか、その人が対応できないときは誰に連絡するのかを決めてください。月額の保守プランに、24時間の障害対応が含まれているとは限りません。必要なら明確に合意しておく必要があります。
対応の約束が何を意味するのかも確認しましょう。問題を受け付けること、調査を始めること、サービスを復旧させることは、それぞれ別の段階です。どの段階までを約束しているのか、その後どうなるのかが、文面からわかるべきです。
プロダクトの変化に合わせて性能とアクセス権を見直す
データは増え、新しい機能が加わり、実際の利用者はテスト用アカウントとは違う使い方をします。問題の兆候が見えたら、遅いページや負荷の高い処理を見直してください。まず利用者への影響から考え、原因を調べましょう。習慣的にインフラを増強するのは避けるべきです。
メンバーの加入や離任のたびに、アカウントへのアクセス権を見直してください。所有者や更新に関する情報を最新に保ち、重要なサービスがどこにあるかを記録しておきましょう。チームの誰も復旧できない、忘れられたアカウント一つにプロダクトが依存している状態は避けるべきです。
内容を理解できる保守計画を求める
継続的な作業を依頼する前に、次の点を確認してください。
対象となるアプリケーション、サービス、環境はどれか。
実際にどんなチェックや定期作業が行われるのか。
バックアップ、復元テスト、各種更新、サービスの請求は誰の担当か。
対応時間帯はいつで、緊急の問題はどう連絡すればよいか。
修正や改善のための時間はどう使われ、何が別見積もりになるのか。
完了した作業と残っているリスクについて、どんな記録を受け取れるのか。
契約を終えるとき、アクセス権やドキュメントはどうなるのか。
完了した作業と未解決の課題を、書面で記録してもらいましょう。たとえば、保守の報告は次のようになります。
完了：アプリケーションの依存関係を更新し、リリース前にステージング環境で、ログイン、パスワード再設定、主要な予約の流れを確認しました。
復元の確認：最新のデータベースのバックアップを別環境に復元し、一部のレコードを抽出して確認しました。アップロードされたファイルは、今回の復元テストにはまだ含めていません。
判断が必要な事項：ストレージの使用量が増えています。変更を加える前に検討いただけるよう、選択肢と想定される影響をまとめました。
これは、求めるべき詳しさの例であって、特定の月間スケジュールを約束するものではありません。保守計画には、プロダクトにどのチェックをどのくらいの頻度で行うかを書いておくべきです。
今あるプロダクトから始める
公開されている Web サイトをまず確認したいなら、私のWebサイト健康診断やサイト監査を使ってみてください。調べる価値のある問題が見つかることがあります。ただし、非公開のアプリケーションコードは確認できず、バックアップや顧客向けの業務の流れが機能していることを証明するものでもありません。
継続的なサポートをご希望なら、プロダクトについて教えてください。使っているサービスや、カバーしてほしい範囲もあわせてお知らせください。そのニーズに合わせて保守プランを決めることも、まず特定の改善項目から範囲を決めることもできます。