本番環境のアラートが届くたびに、同じ開発者が作業を止めて調べている。バックアップはあるものの、その人が休んだ日に誰が復旧するかは決まっていない。自社のSaaS・WebサービスをAWSで運用していて、こうした状態に心当たりはないでしょうか。
まず確認したいのは、担当者以外が構成と手順をたどり、必要な判断をできるかです。この記事では、構成、権限、復旧、監視後の対応、リリースの5項目から、どこを先に整えるかを考えます。
運用にソフトウェアエンジニアリングを適用する考え方をSRE（Site Reliability Engineering）と呼びます。Googleの解説も参考に、専任担当がいない場合に現在の運用を確認する項目として、次の5つを提案します。
- 現状の棚卸し（構成図と台帳）
- アカウントと権限の基本
- バックアップと「戻せるか」の確認
- 監視と「通知の後」の設計
- リリース手順の文書化
図1：運用の確認箇所を整理した模式図。実際のシステム構成に合わせて確認します。
担当者が不在の日を想定して確認する
「資料があるか」に加えて、「別の担当者がその資料を使えるか」を確認します。たとえば、直近のアラートを一つ選び、対象システム、最初に見る画面、変更を承認する人までたどってみます。確認できなかった箇所を、改善対象として残します。
本番環境を変更する必要はありません。まず資料と記録で確認し、復元や切り戻しの実行を伴う検証は、対象と影響を決めたうえで分離した検証環境などで行います。
1. 現状の棚卸し：「いま何がどう動いているか」を書き出す
最初の一歩は、新しいツールの導入ではなく、いまの状態を書き出すことです。
- 構成図：どの機能が仮想サーバー（EC2）、データベース（RDS）、ファイル保管（S3）などで動いているか。外部公開経路とデータの保存先はどこか
- アカウント台帳：AWSアカウント、ドメイン、証明書、外部サービスについて、管理者と更新期限が記録されているか
- 運用作業一覧：監視、更新、証明書、バックアップ確認、障害対応を、誰がどの手順で行っているか
資料がない項目は、推測で埋めず「未確認」と記録します。未確認の項目が分かれば、障害対応や改善作業で先に調べる対象を決められます。構成図は完成度よりも、現行環境と一致していることが重要です。
2. アカウントと権限：誰が何を操作できるか
棚卸しの次は、AWSアカウントと権限を確認します。IAMはAWSへのアクセス権限を管理する仕組みで、IAMロールは必要な権限をまとめて設定するものです。
- rootユーザーの保護：日常作業には使わず、多要素認証（MFA）を設定する
- 人のアクセス：利用者のアクセスを一元管理するIAM Identity Centerや、既存の社内認証基盤と連携し、IAMロールの一時的な認証情報でアクセスする
- 最小権限：全員へ管理者権限を付けず、担当作業に必要な権限へ絞る
- 長期認証情報の整理：IAMユーザーやアクセスキーの用途・所有者・最終利用を確認し、不要なものは依存する処理への影響を確かめて無効化する。退職者のアクセスも見直す
AWSのIAMセキュリティベストプラクティスでは、利用者やアプリケーションからのアクセスにIAMロールと一時的な認証情報を使うことが推奨されています。既存環境にIAMユーザーがある場合は、すぐに一括削除するのではなく、利用状況と移行先を確認してから整理します。権限変更によるシステム停止を避けるためです。
3. バックアップと「戻せるか」の確認：取っているだけでは足りない
バックアップの取得状況に加えて、必要なデータを復元し、業務を再開できるかを確認します。
- バックアップの対象は何か（データベースだけか、設定やファイルも含むか）
- どの時点まで戻す必要があるか。現在の取得間隔が、その要件を満たしているか
- どこまでの時間で復旧する必要があるか。復旧手順と担当者が決まっているか
- 本番と分離した場所で、復元結果を確認した記録があるか
障害発生前の何分・何時間分のデータ損失まで許容するかを復旧時点目標（RPO）、どれだけの時間で復旧するかを復旧時間目標（RTO）として整理します。バックアップの取得間隔や復旧手順が、その目標を満たすか確認します。必要な水準はサービスごとに異なります。復元テストの頻度も一律に決めず、データ量、構成変更の頻度、監査要件に合わせます。
AWS Backupの定期的な復元テストは、対応するリソースで利用できます。復元処理の完了だけで業務を再開できるとは限らないため、必要なデータを参照できるか、アプリケーションが動作するかも確認します。AWSには、復元後に独自の検証処理を組み込むための検証機能も用意されています。
4. 監視と「通知の後」の設計：通知が来ても、対応できなければ機能しない
AWSの監視サービスであるCloudWatchなどでアラートを設定していても、通知を受けた後の手順がなければ、原因調査や復旧の開始が遅れるおそれがあります。
- 通知先は現行の担当者・連絡経路になっているか
- アラート名から、対象リソースと判定条件を特定できるか
- 一次確認の手順書（ランブック）へ通知から移動できるか
- 一次対応で解決しない場合の連絡先と判断者が決まっているか
AWS Well-Architected Frameworkでも、運用手順をランブックとして文書化し、状況の変化に合わせて更新することが示されています。通知経路をテストし、担当者変更時に更新する作業も運用手順へ含めます。
5. リリース手順の文書化：手作業を、まず見えるようにする
最後はリリース（デプロイ）の手順です。特定の担当者だけが手順を知っている場合は、その担当者が不在でも作業をたどれる形にします。
まず、現在のリリース手順を実際の作業順に記録します。実行コマンド、必要な権限、確認項目、承認者、作業完了の条件を含めます。手作業や実行順に依存する箇所が分かれば、ビルド・テスト・配布を継続的に行うCI/CDの仕組みで自動化する対象を選べます。
直前の状態へ戻すロールバック手順も必要です。アプリケーションだけでなく、データベース変更や設定変更を元に戻せるかを確認します。自動化する場合も、手順と完了条件が曖昧なままでは、誤った処理を繰り返すおそれがあります。
確認結果から、最初の一つを選ぶ
以下は記録の例です。実際の確認結果と、業務への影響に置き換えて使ってください。
| 確認項目 | 残す記録 | 改善を検討する状態 |
|---|---|---|
| 構成 | 現行構成図、更新日、管理者 | 本番の保存先や接続先を特定できない |
| 権限 | 利用者・用途・権限の一覧 | 所有者不明の認証情報がある |
| 復旧 | 復元した日、対象、結果、所要時間 | バックアップから戻せるか未確認 |
| 監視 | 通知先、確認手順、判断者 | 通知後に何をするか決まっていない |
| リリース | 実行・確認・切り戻しの手順 | 担当者以外が手順をたどれない |
障害時に業務を再開できなくなる項目や、直近の変更に関わる項目から着手します。権限漏えいなど緊急の問題が見つかった場合は、通常の改善計画と分けて対応します。
5つを整えたあと：自社で続けるか、外部の力を借りるか
棚卸しの結果や手順書は、作成した時点の状態を記録したものです。構成変更、担当者変更、障害対応の結果に合わせて更新しないと、実環境と一致しなくなります。更新日と更新責任者を資料に記載します。
自社だけで更新を続けることが難しい場合は、作業の一部を外部へ委託できます。その場合も、本番変更の承認、業務判断、利用者への連絡などについて、自社に残す判断と、条件を定めて委託先に任せる判断を分けます。外部に依頼する際は、対象作業、対応時間、本番変更の承認方法を具体的に伝えます。
まとめ
専任の運用担当がいない場合に確認する項目として、①現状の棚卸し ②アカウントと権限 ③バックアップと復旧 ④監視と一次対応 ⑤リリース手順、の5つを紹介しました。着手する順序は、現在の問題と業務への影響に合わせて決めます。
確認結果は「設定済み／未設定」だけで終わらせず、実際に使えるかで判断します。復元テストの記録があるか、アラートから手順書へ移れるか、担当者以外がリリースとロールバックを実行できるかを確認します。これらの情報は、内製・採用・外部委託のどの体制を選ぶ場合にも引き継げます。
AWS運用の見直しについて相談する
構成や手順が分からず確認が進まない、開発と運用の兼務が続き改善に着手できない、といった場合は、現在の状況をお知らせください。相談時点ですべての資料を揃える必要はありません。
「困っている作業」「現在の担当体制」「対応したい時期」を分かる範囲で記載いただくと、確認する対象を整理できます。環境の調査、手順の整備、移行・運用支援などの対応可否・範囲・費用は、内容を確認して個別にご案内します。
