クラウド着手・運用引き継ぎ点検表

何を運用するのかを一覧にすることから始めます。クラウドのアカウントとプロジェクト、サーバーとデータベース、ドメインと証明書、DNSの管理場所、外部連携サービスとその契約主体を一行ずつ書きます。開発と検証、本番の環境を分けて書いておけば、後でどの環境を触る作業なのか迷いません。アカウント名義と支払い手段、請求経路も同じ表に入れます。前月の請求書をアカウント別に一部受け取っておけば、後で費用が上がったときに比べる場所ができます。

一覧で持ち主が空いている項目が初週の課題です。退職者の個人アカウントで発行された証明書や、担当者だけが知る外部サービスがここで表に出ます。一覧になかったリソースが後から出てくると、そこからは事故対応になります。

リソースごとになぜあるのかも一行で書きます。検証用なのか災害復旧用なのか、どの業務周期のために点けているのかが分からなければ、後で費用を下げるとき何を止めてよいか誰も判断できません。

アカウントをまるごと渡しません。参照権限と運用権限、リソースを作成し削除する権限を分け、それぞれの役割に誰が入るのかを名前で書きます。最上位の管理者アカウントは顧客側が保管し、接続記録が残るようにします。障害時だけ開く一時権限を別に用意すれば、平時の権限を広げずに復旧を遅らせません。

サーバー接続鍵とデータベースのパスワードは保管場所を決めてから移します。引き継ぎが終わったら前任者の権限を回収し、回収した日付を表に記します。共用アカウントを複数人で使っていた場合は、この時点で個人アカウントに分けます。

監査ログが顧客のアカウントに貯まるかを確認し、保管期間を決めます。誰がいつ何をしたかが残ってはじめて、最初の障害で直前の変更を見つけられます。

障害が起きたとき誰が誰にどの経路で知らせるかを決めます。夜間と休日の窓口、等級別の通知先、経過共有の周期、等級を上げられる人を書きます。担当者一人の携帯番号だけにつながる経路は、その人が席を外した瞬間に切れます。等級の定義は自社のサービスで何が止まった状態かで書きます。サーバーが生きていても決済やログインができなければ最上位の等級です。

初週に連絡経路を一度試します。実際に通知を送り受け取る人が受け取るか確認しなければ、深夜に初めて試すことになります。

バックアップが回っているという事実だけでは足りません。初週に一件を実際に復元し、かかった時間を記します。どこまで戻せるのか、戻したデータが健全か、復旧を誰が行うのかがその試験で表れます。バックアップの保管期間と保存場所が契約要件を満たすかも併せて見ます。

定期作業枠と動かせない予定もカレンダーに載せます。締めと精算、対外機関との連携日程は作業枠から外しておきます。切り戻し条件と許容停止時間もこのとき一度合意しておけば、作業ごとに決め直しません。

終了条件を着手会議で決めておけば、後で交渉しません。ランブックと変更履歴、ダッシュボードとアラート規則、指標履歴、スクリプトをどの形式で渡すのかを書きます。監視ツールを実施チームの契約で使う場合、契約が終わる日に監視も一緒に消えるため、所有アカウントを今のうちに決めます。アカウント権限の移管を誰がいつ行うのか、並行運用の期間も同じ場で決めます。

初週が終わったら、この五つのまとまりが文書として残っているはずです。資産一覧と権限表、連絡体系、復旧確認の記録、終了条件の五つが、以後すべての運用判断の土台になります。